Olt slicing and traffic management system, control method, management method and medium

Abstract

The application belongs to the field of communication and discloses an OLT slice and service management system, a control method, a management method and a medium. The system runs on an OLT device and comprises a virtual slice controller VSC deployed on a master disk and a plurality of virtual device services VDS. Each VDS serves an OLT slice through a group of independent processes. The VSC responds to an OLT slice management instruction, allocates a unique slice ID and issues a trigger message. A virtual slice controller agent VSCA is deployed on the master disk and each service line card, used to receive the trigger message from the VSC, execute state machine scheduling, realize service component management of a target VDS process and feed back the execution result to the VSC. The OLT slice in the application has good data isolation and low resource consumption.

Description

Technical Field

[0001] This application belongs to the field of communications, and specifically relates to an OLT slicing and service management system, control method, management method, and medium. Background Technology

[0002] Located at the network access and aggregation layer, the OLT is responsible for connecting user broadband equipment to the upper-layer network. As a key component of optical access, it plays a significant role in network simplification and the customization of all-optical networks for government and enterprise offices. The OLT bridges the gap between the upper and lower layers, integrating all the functions of a traditional aggregation switch to provide users with a highly reliable and low-latency service experience.

[0003] With the evolution of 5G / 6G and cloud-network convergence, OLT network slicing technology has emerged. It aims to enable the same OLT hardware infrastructure to simultaneously support multiple types of services with differentiated Service Level Agreement (SLA) requirements, such as industrial internet low-latency slicing, home gigabit broadband slicing, 5G fronthaul / midhaul slicing, and government and enterprise private line slicing, through logical isolation, resource programmability, and on-demand service customization.

[0004] Currently, there are two main solutions for implementing OLT slicing in the industry: Option 1: Multi-instance slicing. This option presents slices externally using software-extended slice IDs, but all slices run in the same software instance, resulting in poor isolation and failing to meet requirements for independent upgrades and independent management (logs, alarms, configuration files).

[0005] Option 2: Container Slicing. This option uses container technologies such as Docker to run a single piece of code in multiple containers, providing good isolation. However, in embedded systems like OLTs, the hardware generally does not support slicing, and the hardware adaptation layer is complex. Furthermore, container operation consumes significant CPU and memory resources, making it unsuitable for resource-constrained embedded devices.

[0006] Therefore, there is an urgent need for an OLT slicing solution with good data isolation and low resource consumption to solve the above-mentioned problems in the existing technology. Summary of the Invention

[0007] To address the aforementioned issues, this application provides an OLT slicing and business management system, control method, management method, and medium, which features good data isolation and low resource consumption in OLT slicing.

[0008] The technical solution is as follows: An OLT slicing and service management system, running on an OLT device, the OLT device including a main control board and at least one service line card, the system comprising: Multiple virtual device services (VDS) are deployed on the main control disk, and each VDS serves an OLT slice through a set of independent processes; The Virtual Slice Controller (VSC), deployed on the main control board, is used to respond to OLT slice management commands, assign unique slice IDs, and send trigger messages. The Virtual Slice Controller (VSCA) is deployed on the main control board and each service line card to receive trigger messages from the VSC, execute state machine scheduling, manage the service components of the target VDS process, and feed back the execution results to the VSC.

[0009] Furthermore, the OLT device itself acts as the management slice VDS0, and has management permissions for other VDSs, including the creation, startup, shutdown, destruction, and resource allocation of VDSs; Among them, VDS0 allocates physical and logical resources to each VDS; The physical resources include boards, uplink ports, PON ports, CPUs, and memory; The logical resources include the maximum number of ONUs, VLAN specifications, routing capacity, and the number of VPN instances.

[0010] Furthermore, VSC and VSCA communicate via asynchronous messages. When VSC sends the trigger message, it starts a slice timer and terminates the slice timer when it receives the execution result from VSCA.

[0011] Furthermore, VSCA executes state machine scheduling to manage the target VDS process's business components, including: Based on the trigger message, VSCA initializes the slice state machine; VSCA performs directory mapping operations to create an independent file directory space for the target VDS; VSCA broadcasts service component control commands to the target VDS to start or stop the service components corresponding to the target VDS.

[0012] Furthermore, the system also includes: The message transmission and reception management module, deployed on the OLT device, is used to identify the VDS to which the management messages from the external network belong, and to distribute the messages to the corresponding VDS for processing based on the source port, VLAN information, or pre-assigned VDS dedicated port number of the login message.

[0013] Furthermore, the OLT slice supports at least one of the following login modes: Independent IP login mode: Each VDS is configured with a unique management IP address, and the login is achieved by directly connecting to the management IP address via SSH / Telnet protocol and determining the target VDS based on the packet sending and receiving management module; Single IP command line to login mode: All VDS share the management IP address of the management slice VDS0. First, log in to VDS0, and then execute the switching command in the command line interface of VDS0 to complete the context switch and redirect the terminal session to the target VDS. Single IP + Port Mapping Login Mode: All VDS share the management IP address of the management slice VDS0, and log in to the target VDS through the management IP address of VDS0 and the pre-assigned dedicated VDS port number.

[0014] An OLT slice lifecycle control method based on the above system includes: VSCA receives a trigger message from VSC and initializes the slice state machine. The trigger message is a message containing a unique slice ID issued by VSC in response to the OLT slice management command. VSCA performs directory mapping operations to create an independent file directory space for the target VDS; VSCA sends service component management commands to the target VDS to start or stop the deployment of service components in the target VDS process, and reports the execution results back to VSC.

[0015] Furthermore, the method also includes: VSCA sends a slice deployment command to the main control disk, which then dynamically loads or unloads business function components according to a preset component deployment configuration file. The main control disk also summarizes the execution results of each VDS process. Once it is confirmed that all components are in the same state, it reports a component loading or unloading completion event to VSCA. Based on the component loading or unloading completion event, VSCA updates the OLT slice status and sends a message to VSC indicating that the slice creation is complete or the slice service has stopped.

[0016] A collaborative management method for ONU identifiers based on the above system includes: The management slice VDS0 issues the initial resource configuration to the newly created service slice VDSi, including the Slot number, PON port number, and the maximum number of pre-allocated ONUs; VDS0 calls the VSC_LIB library through VSC to synchronize the global ONU allocation strategy, mapping rules and basic parameters to the VDSi VSC_LIB library; The VDSi ONU management module actively initiates a scan request to the underlying PON line card to obtain information on all ONU devices that have not been registered or authorized under the current physical PON port, forming a list of ONUs to be authorized. VDSi assigns a local ID, denoted as vds_onuid, to the newly discovered ONU within this slice, and submits a registration request to VDS0 via VSC_LIB. The registration request includes the Slot number, PON port number, vds_onuid, and unique ONU identifier. VDS0 queries the global ONU allocation record table, assigns a unique global ONU ID to the newly discovered ONU, writes the mapping relationship between Slot, PON, vds_onuid and global ONU ID into the global ONU allocation record table, and notifies VDSi of the global ONU ID; VDS0 will use the VSC mechanism to batch synchronize the updated global ONU allocation record table to other running OLT slices.

[0017] Based on the same inventive concept, a computer-readable storage medium is also provided, wherein computer-executable instructions are stored in the computer-readable storage medium, and when the computer-executable instructions are executed, the functions of the above-mentioned OLT slice and business management system or the OLT slice lifecycle control method and ONU identifier collaborative management method are implemented.

[0018] The beneficial effects of this application are as follows: (1) Device-level slicing is achieved by using process-level virtualization technology. All VDS share the kernel space. The virtualization scheduling performance at the operating system level is good and consumes few resources. Furthermore, the data between OLT slices is completely isolated, and independent upgrades and management of slices are supported. (2) The system supports three modes: independent IP login, single IP command line login, and single IP + port mapping login, which are compatible with centralized and decentralized management scenarios; (3) When the PON line card and chip do not support slicing, each OLT slice uses a local ID independently and achieves unified mapping through the global ONU ID to solve the ONU ID conflict problem when multiple slices share the PON port.

[0019] Other features and advantages of this application will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures pointed out in the description, claims and drawings. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a schematic diagram of the structure of the OLT slicing and business management system according to an embodiment of this application; Figure 2 This is a schematic diagram of the software framework of the OLT slicing and business management system according to an embodiment of this application; Figure 3 This is a schematic diagram of the multi-mode login process of the OLT slicing and business management system in an embodiment of this application; Figure 4 This is a flowchart of the OLT slice lifecycle control method according to an embodiment of this application; Figure 5 This is a flowchart illustrating the creation / stopping process of an OLT slice in an embodiment of this application. Figure 6 This is a flowchart of the ONU identifier collaborative management method according to an embodiment of this application; Figure 7 This is a schematic diagram of the ONU identifier collaborative management method in an embodiment of this application. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0023] This application provides a lightweight OLT slicing and service management system running on an OLT device, wherein the OLT device includes a main control board and at least one service line card.

[0024] like Figure 1 As shown, the system includes a Virtual Slice Controller (VSC), a Virtual Slice Controller Agent (VSCA), and multiple Virtual Device Services (VDS).

[0025] Each Virtual Device Service (VDS) is deployed on the main control disk. Each VDS serves an OLT slice through a set of independent processes. That is, a set of independent processes carries the specific functions of an OLT slice, and these functions run in the OLT slice in a multi-instance manner.

[0026] In this embodiment, VDS employs process-level virtualization technology, with all VDSs sharing the Linux kernel. This operating system-level virtualization scheduling offers superior performance and lower resource consumption. Each VDS runs its own independent control protocol process, ensuring mutual independence and non-interference. This supports flexible resource allocation and management, file directory isolation, independent alarm reporting, VDS startup control, and independent service configuration and operation.

[0027] The Virtual Slice Controller (VSC) is deployed on the main control board to respond to OLT slice management commands, assign unique slice IDs, and send trigger messages. As the core unit of slice management, the VSC is responsible for creating and stopping OLT slices and starting slice timers to monitor slice status.

[0028] The Virtual Slice Controller (VSCA) agent is deployed on the main control board and each service line card. It is used to receive trigger messages from the VSC, execute state machine scheduling, realize the service component management of the target VDS process, and feed back the execution results to the VSC.

[0029] By default, the entire OLT device itself is treated as a management slice, called VDS0. VDS0 is the most special virtual device service instance in the system. It corresponds to the entire physical OLT device and has management permissions for all other VDSs, including the creation, startup, stopping, deletion, and resource allocation of VDSs.

[0030] VDS0 allocates independent physical and logical resources to each VDS.

[0031] The physical resources include boards, uplink ports, PON ports, CPUs, and memory.

[0032] Specifically, the board refers to the physical board in the OLT device, including the main control board and service line cards. VDS0 can specify a particular VDS to use specific board resources. The uplink port is the uplink interface of the OLT device, used to connect to the upper-layer network. Each VDS can be assigned an independent uplink port, or share an uplink port with other VDSs (isolated via VLANs, etc.). The PON port is the PON interface of the OLT device, used to connect to the downlink ONU device. In slicing scenarios, a PON port can be shared by multiple VDSs, resolving ID conflict issues through an ONU identifier collaborative management mechanism. VDS0 can also allocate CPU usage limits and independent memory space to each VDS, preventing one VDS from exhausting CPU resources and affecting other VDSs, and ensuring that the service processes of each VDS are isolated at the memory level.

[0033] The logical resources include the maximum number of ONUs, VLAN specifications, routing capacity, and the number of VPN instances.

[0034] Specifically, the maximum number of ONUs is the maximum number of ONUs that can be connected under this VDS. Since the PON port may be shared by multiple VDSs, the sum of the maximum number of ONUs across all VDSs can exceed the maximum ONU capacity of the physical PON port (256), achieved through a mapping mechanism between global ONUIDs and local IDs. The VLAN specification is the range of VLAN IDs that this VDS can use and the maximum number of VLANs. Different VDSs can use the same VLAN ID space, and they do not interfere with each other through a slicing isolation mechanism. The routing capacity is the maximum number of IPv4 / IPv6 routing entries that this VDS can carry, including both IPv4 and IPv6 routing capacity. The VPN instance count is the maximum number of VPN instances that this VDS can create, used to support multi-tenant L3VPN services.

[0035] According to this embodiment, the process of VDS0 allocating resources to each VDS is as follows: The upper-layer network management system sends a VDS creation request to VDS0, along with the required physical and logical resource specifications; VDS0 checks the currently available resource pool to determine whether the allocation request is satisfied; if satisfied, VDS0 deducts the corresponding resources from the available resource pool, creates an independent resource context for the new VDS, and calls VSC to trigger the creation process of the new VDS; if not satisfied, VDS0 returns a resource allocation failure message and informs the specific reason (such as insufficient CPU, excessive ONU quantity, etc.); VDS0 synchronizes the allocated resource information to VSC and VSCA for subsequent resource monitoring and scheduling.

[0036] VDS0 is also responsible for real-time monitoring of the resource usage of each VDS. When the resource usage of a VDS exceeds its allocation specification, VDS0 can trigger an alarm and selectively restrict further resource requests from that VDS, ensuring resource isolation and fairness between each OLT slice.

[0037] In this embodiment, VSC and VSCA communicate asynchronously to collaboratively manage the entire lifecycle of OLT slices, including the creation, startup, shutdown, and destruction of OLT slices.

[0038] The characteristics of the aforementioned asynchronous message communication mechanism are: after sending a trigger message, VSC does not need to wait for VSCA to return a result immediately, and can continue processing other tasks without being blocked by VSCA's execution process; VSCA receives the trigger message sent by VSC, wakes up and executes the corresponding state machine scheduling task; after completing a series of operations such as state machine scheduling, directory mapping, and component deployment, VSCA feeds back the execution result to VSC through asynchronous messages. This asynchronous communication method ensures that the control flow is not blocked, improving the system's throughput and reliability.

[0039] To ensure the reliability of asynchronous communication, VSC starts a slice timer when it sends a trigger message to monitor the execution status of the slice operation, and terminates the slice timer when it receives the execution result from VSCA.

[0040] Specifically, after VSCA completes its operation within the specified time and reports the execution result to VSC, VSC terminates the slice timer. If the slice timer expires without receiving feedback from VSCA, VSC determines that the operation has failed and reports a timeout error to the upper-level network management system. Therefore, when VSCA fails to respond in a timely manner due to faults, insufficient resources, or other reasons, the timer timeout mechanism can promptly detect anomalies, preventing VSC from waiting indefinitely and avoiding control flow freezes. After a timeout, VSC can trigger corresponding fault recovery procedures (such as retry, rollback, alarm reporting, etc.).

[0041] In this embodiment, after receiving the trigger message from the VSC, the VSCA executes state machine scheduling to realize the management of the business components of the target VDS process.

[0042] Specifically, it includes: (1) Based on the trigger message, VSCA initializes the slice state machine; A state machine is a finite state automaton used to manage the state transitions of OLT slices at different lifecycle stages.

[0043] Typical states of a slice state machine include: Creating (the slice is being created, but resources have not yet been fully allocated). Running (the slice is running normally and the business components have started), Stopping (the slice is stopping and the business components are being unloaded), Stopped (the slice has stopped, but the configuration and resources are retained), Deleting (the slice is being destroyed and the resources are being reclaimed), Abnormal (the slice operation failed or the operation is abnormal).

[0044] VSCA sets the state machine to the corresponding initial state (e.g., "creating" for a creation command) based on the type of trigger message (create, start, stop, or delete) and begins state transitions. This slice state machine ensures the orderliness and traceability of OLT slice operations, avoiding state chaos caused by concurrent operations or abnormal conditions.

[0045] (2) VSCA performs directory mapping operations to create an independent file directory space for the target VDS; VSCA performs directory mapping operations to create an independent file directory space for the target VDS, ensuring complete isolation of configuration, logs, alarms, databases, and other data between OLT slices. The specific details of the directory mapping are shown in Table 1.

[0046] Table 1

[0047] The directory mapping is implemented as follows: In the file system of the physical OLT, an independent root directory is created for each VDS, and the process access path of each VDS is redirected to its dedicated directory through an operating system-level directory mapping mechanism (such as chroot, mount namespace, or file system virtualization technology). Processes in each VDS can only see and access their own directory space and cannot access the directories of other VDSs, thereby achieving data isolation between OLT slices.

[0048] (3) VSCA broadcasts service component control instructions to the target VDS to start or stop the service components corresponding to the target VDS.

[0049] Based on the functional requirements of the OLT slice, each VDS can deploy one or more of the following types of service components, including: PON service components are used to manage PON ports and ONUs and handle OMCI protocols; Routing protocol components are used to handle routing protocols such as OSPF, BGP, and IS-IS; MPLS protocol components are used to handle MPLS label distribution and forwarding; A login management component for handling SSH / Telnet login sessions; A log management component for handling the collection and management of system logs; Alarm management components are used to detect and report alarm information; Database component used to store configuration and status data.

[0050] Multiple service components can share a single process. For example, routing protocol components and MPLS protocol components can share a single routing and MPLS process, while login management components, alarm management components, and database components can share a single system management process. The specific mapping relationship between components and processes is flexibly configured through preset component deployment configuration files (such as vdscfg.ini) to balance functional cohesion, fault isolation, and resource consumption.

[0051] VSCA determines which business components need to be started or destroyed based on the preset component deployment configuration file (such as vdscfg.ini). This configuration file predefines the processes contained in each VDS and the components contained in each process, thereby flexibly setting the functions of different VDSs, making the system highly customizable and lightweight.

[0052] In this step, VSCA broadcasts a "service component start" command to all business processes of the target VDS. Each process loads the corresponding business component according to the configuration file, initializes the data structure, registers the service interface, and begins to provide services to the outside world. VSCA also broadcasts a "service component destroy" command to all business processes of the target VDS. Each process stops receiving new requests, completes the tasks it is processing, releases resources, and exits the service.

[0053] In this embodiment, process-level component management results in lower resource consumption, a lightweight and efficient system, and the addition of new business components only requires modification of the configuration file without modifying the core code, making it easy to extend.

[0054] like Figure 2 As shown, the system's software framework is based on the Linux operating system, and the layers from bottom to top are as follows: The system support plane, deployed on OLT devices, includes a system support framework, a virtualization management module, a database module, and a device management module, which provide virtualization management, database slicing, and device management. The general service plane, deployed on OLT devices, includes a general forwarding management module and a general interface management module, which are used to uniformly manage the service forwarding tables and interfaces of all slices; The management plane, deployed on the OLT device, includes a configuration management module, a specification management module, an alarm performance management module, and a northbound service channel management module, which are used to uniformly manage the configuration, specifications, alarm performance, and northbound service channel of the slice. The VDS layer runs on top of the management plane, general business plane, and system support plane, and depends on the services provided by these three planes.

[0055] Service modules (PON services, routing and MPLS protocols, service management, and IP protocol stack) run within each VDS, ensuring that service functions are isolated and operate independently. The system support plane, general service plane, and management plane run on the physical OLT, using message communication to communicate with each VDS to provide services to the VDS.

[0056] Furthermore, the system also includes a message transmission and reception management module. This module, deployed on the OLT device, identifies the VDS to which management messages from the external network belong, and distributes the messages to the corresponding VDS for processing based on the source port, VLAN information, or pre-assigned VDS dedicated port number.

[0057] The message sending and receiving management module is deployed on the system support plane of the OLT device, located at the data plane forwarding layer. Since the underlying hardware does not directly support the slicing function (i.e., the hardware cannot identify which VDS a message belongs to), the actual function of this module is to identify message ownership and intelligently distribute messages. By parsing the feature information of incoming messages, it accurately determines which VDS instance the control message should be delivered to for processing.

[0058] After creating an OLT slice, a single physical OLT device is divided into multiple logical devices. Each OLT slice provides different services, therefore each OLT slice requires independent login and management capabilities. Figure 3 As shown, the OLT slice supports at least one of the following login modes: (1) Independent IP login mode Each OLT slice is configured with a unique management IP address (ip_vds1~ip_vds0n, where ip_vds0 is the IP address of the management slice VDS0). It directly connects to the management IP address via SSH / Telnet protocol and logs in based on the message sending and receiving management module to determine the belonging VDS.

[0059] Specifically, the configuration process for the independent IP login mode is as follows: VSC responds to the upper-layer command to create a new VDS; VDS0 allocates physical and logical resources such as uplink port, PON port, VLAN, and ONU to the new VDS; configures a unique management IP address (such as ip_vdsi) for the new VDS; configures the username and password required to log in to the new VDS; and saves the various configuration information of the new VDS.

[0060] The process of logging into a VDS using the independent IP login mode is as follows: The user initiates a connection using the SSH / Telnet protocol through the uplink port and management IP of the VDS; the message transmission and reception management module receives the login message; the attribution identification module queries the VDS configuration and status information maintained in the VSC / VSCA based on the source characteristics of the message (source port, VLAN, etc.); it determines which slice the message belongs to based on the VDS configuration and status information and establishes communication with the target VDS; the message transmission and reception management module forwards the message to the target VDS; the user enters the username and password of the VDS to complete the authentication; the user enters the command-line management system of the VDS (equivalent to a physical OLT device).

[0061] The independent IP login mode achieves complete isolation of the slice management plane. Each VDS has an independent management IP, an independent authentication system, and an independent management view, which meets the requirements for management independence in multi-user scenarios and is suitable for scenarios with high security isolation requirements, such as government and enterprise dedicated line slices and third-party operation and maintenance scenarios.

[0062] (2) Single IP command line to login mode; In the single IP command-line to login mode, all VDS share the management IP address (ip_vds0) of the management slice VDS0. First, log in to VDS0, and then execute the switching command in the command-line interface of VDS0 to complete the context switch and redirect the terminal session to the target VDS.

[0063] Specifically, the process of logging into VDS using the single IP command-line to login mode is as follows: The user logs into the management slice VDS0 using ip_vds0 (e.g., 10.10.10.1); executes a switching command (e.g., switch tovdsn) in the command-line interface of VDS0; the command-line management system (system support plane) of the entity OLT establishes communication with the target VDS based on the VDS ID in the switching command, and queries the configuration and status information of the VDS in VSC / VSCA; the command-line management system of the entity OLT implements the context switch from VDS0 to the target VDS, and redirects the terminal session to the command-line system of the target VDS; the user enters the command-line interface of the target VDS and begins service configuration and management.

[0064] The single-IP command-line to login mode simplifies the management entry point. Operation and maintenance personnel only need to remember one management IP to manage all slices. Switching via command line improves the ease of operation and is suitable for centralized operation and maintenance by device administrators and environments with limited IP address resources. At the same time, administrators can quickly switch between multiple slices, improving troubleshooting efficiency.

[0065] (3) Single IP + Port Mapping Login Mode In the single IP + port mapping login mode, all VDS share the management IP address of the management slice VDS0. Unlike the single IP command line login mode, it is not necessary to log in to the entity OLT first. Instead, different VDS are identified by pre-assigned dedicated port numbers. You can directly log in to the target VDS through the management IP address of VDS0 and the pre-assigned dedicated port number without having to log in to VDS0 first and then switch.

[0066] Preferably, the management slice VDS0 uses the default port number 22 (standard SSH), and each other VDS is pre-allocated a dedicated Layer 4 port number, forming a one-to-one correspondence between port numbers and VDS IDs. For example, the range of dedicated port numbers is preferably 40001 to 40068, which can support a total of 68 OLT slices. This range avoids commonly used system ports (0-1023) and registration ports (1024-49151), reducing the possibility of port conflicts.

[0067] The login process for VDS using the single IP + port mapping login mode is as follows: The user connects to the uplink port of the OLT device and executes the command "telnet ip vds0 40001"; the message transmission and reception management module receives and parses the login message, determines the target VDS corresponding to the destination port number according to the pre-configured port-VDS mapping table, and establishes communication with the target VDS; the message is forwarded to the target VDS; the user enters the username and password of the target VDS (sharing the same authentication system as the independent IP login mode) and logs directly into the target VDS to perform service configuration and management.

[0068] The single IP + port mapping login mode retains the advantages of a single management IP address while enabling one-step access to the target VDS, making it particularly suitable for automated operation and maintenance, API call scenarios, and third-party network management integration systems.

[0069] In this embodiment, the VSC is deployed in the physical OLT (i.e., VDS0), and the VSCA is distributed across various service disks (including the master control disk). The VSC / VSCA is used to centrally maintain resource configurations, status information, and service mapping relationships for each service disk and VDS within the OLT. This information is primarily obtained and distributed through message transmission mechanisms communicated with the VSC_LIB clients residing in each service slice (VDS). The VDS_LIB client resides within each VDS and is a functional module of the physical OLT that communicates with the VDS via messages. It is responsible for sending various service information, configuration information, and management messages to the functional modules within the VDS for processing. The message transmission and reception management module is located at the data plane forwarding layer and is responsible for identifying the origin of signaling messages. By parsing the TCP / UDP destination port number and the IEEE 802.1Q VLAN Tag field of the incoming message, and combining this with the locally cached port-VDS mapping table, it accurately determines which VDS instance the message should be delivered to for processing. VDS0 has built-in port listening service, session management service, and user security authentication. It is responsible for receiving port login requests, verifying the validity of credentials, and binding slice context. Internally, it is responsible for taking over or forwarding all management (such as command line system) interaction traffic from external users to VDS.

[0070] The three login modes mentioned above are suitable for different operation and maintenance scenarios, providing users with a flexible, secure, and convenient way to manage slices.

[0071] This application's embodiments employ process-level virtualization technology to achieve device-level slicing. All VDSs share the kernel space, and the operating system-level virtualization scheduling has good performance and low resource consumption. Furthermore, data between OLT slices is completely isolated, supporting independent slice upgrades and management. The system supports three modes: independent IP login, single IP command line login, and single IP + port mapping login, compatible with centralized and decentralized management scenarios.

[0072] Another embodiment of this application provides an OLT slice lifecycle control method, which is applied to the above-mentioned OLT slice and business management system.

[0073] like Figure 4 As shown, the OLT slice lifecycle control method includes: S10, VSCA receives a trigger message from VSC and initializes the slice state machine. The trigger message is a message containing a unique slice ID issued by VSC in response to the OLT slice management command. S11, VSCA performs directory mapping operations to create an independent file directory space for the target VDS; S12, VSCA sends service component management commands to the target VDS to start or stop the deployment of service components in the target VDS process, and reports the execution results back to VSC.

[0074] Furthermore, the method also includes: VSCA sending a slice deployment command to the main control disk, causing the main control disk to dynamically load or unload business function components according to a preset component deployment configuration file, and summarizing the execution results of each VDS process. When it is confirmed that the status of all components is consistent, the main control disk reports a component loading or unloading completion event to VSCA; VSCA updates the OLT slice status according to the component loading or unloading completion event, and sends a message to VSC that the slice creation is complete or the slice service has stopped.

[0075] like Figure 5 As shown, taking OLT slice creation / stop as an example, the process is as follows: Step 1: In response to the OLT slice creation / stop request from the upper-layer network management system or management command, the VSC assigns a unique slice ID (VDS ID), generates a trigger message, and sends the trigger message to the VSCA. At the same time, the VSC starts a slice timer to monitor the execution time of this operation. Step 2: After receiving the trigger message, VSCA executes state machine scheduling; Specifically, this includes: initializing the slice state machine and setting the slice status to "creating"; performing directory mapping operations to establish an independent file directory space for the target VDS to store configuration, logs, alarms, and other data; and broadcasting service component start / destroy instructions to the target VDS for starting / stopping the corresponding business components of the target VDS.

[0076] Step 3: VSCA sends a slice deployment command to the main control disk. The slice deployment module on the main control disk dynamically loads / unloads the required business function components according to the preset component deployment configuration file. In steps 2 and 3, in response to the slice deployment instructions from VSCA, the main control disk slice deployment module determines the service function components that the target VDS needs to load or unload according to the preset component deployment configuration file (such as vdscfg.ini). The vdscfg.ini file pre-configures which processes are included in each VDS and which service components are included in each process. After determining the components to be loaded or unloaded, the main control disk slice deployment module issues slice component start / slice component stop (or destroy) control instructions to the corresponding VDS process. Each VDS process executes the control instructions to load or unload the corresponding service function components (such as PON service components, routing protocol components, log components, etc.).

[0077] Step 4: After each VDS process performs the component start / stop operation, it returns the execution result to the main control disk. The main control disk summarizes the feedback from the VDS processes, confirms that the status of all components is consistent, and then reports the component loading / unloading completion event to VSCA. Step 5: VSCA updates the OLT slice status (updates the slice status to "Running") based on the component loading / unloading completion event, and sends a slice creation / stop completion message to VSC via asynchronous message. After receiving the feedback message, VSC terminates the slice timer and reports to the network management system.

[0078] In this embodiment, the processes for starting, stopping, and destroying OLT slices all follow an asynchronous closed-loop control mode: VSC issues a trigger message and starts a timer → VSCA executes state machine scheduling → main control disk collaborative deployment / unloading → result summary and confirmation → VSCA feedback → VSC terminates the timer. The difference between different operations lies in the specific operations performed by VSCA. For example, when creating a slice, VSCA performs directory mapping, service component startup, and resource allocation operations; when starting a slice, it starts the existing VDS process and its business components; when stopping a slice, it stops the VDS process and its business components, retaining configuration and resources; when destroying a slice, it stops the VDS process, releases resources, deletes directory mapping, and reclaims the slice ID.

[0079] This application embodiment uses asynchronous message communication between VSC and VSCA, combined with a slice timer mechanism, to control the lifecycle of OLT slices. The advantages are: VSC can process other tasks without waiting for VSCA to complete, and the control flow is not blocked; the timer mechanism ensures the robustness of the system under abnormal conditions and avoids the control flow from getting stuck; the asynchronous communication between VSC (main control board) and VSCA (main control board + each service line card) is adapted to the distributed environment of OLT multi-line cards; the timer, combined with the state machine, allows the status of each slice operation (in progress, successful, timeout failure) to be tracked and recorded.

[0080] In an OLT device, each PON port can connect up to 256 ONUs (Optical Network Units). Each ONU is identified by a unique ONU ID of the PON port. However, in an OLT slicing scenario, a PON port may be shared by multiple VDS (Virtual Device Services). If each VDS assigns a local ID to its ONU starting from 1, ID conflicts will occur.

[0081] Based on this, another embodiment of this application provides an ONU identifier collaborative management method. This method is applied to the above-mentioned OLT slicing and service management system, and solves the ONU ID conflict problem that may occur when multiple virtual slices share the same PON port in the context that the PON line card and chip do not support slicing function.

[0082] like Figure 6 and Figure 7 As shown, the ONU identifier collaborative management method includes: S20. The management slice VDS0 sends the initial resource configuration to the newly created service slice VDSi (e.g., VDS1, VDS2), including the Slot number, PON port number and the maximum number of pre-allocated ONUs, to complete the slice instantiation preparation. S21, VDS0 calls the VSC_LIB library through VSC to synchronize the global ONU allocation strategy, mapping rules and basic parameters to the VDSi VSC_LIB library and establish a slice-level identifier management context; The global ONU allocation strategy includes the allocation rules for global ONU IDs, such as the allocation range and allocation algorithm. Mapping rules include the conversion rules between local IDs and global ONU IDs. Basic parameters include the ONU capacity of each PON port and the number of allocated ONUs.

[0083] S22 and VDSi's ONU management module actively initiates a scan request to the underlying PON line card to obtain information on all ONU devices that have not been registered or authorized under the current physical PON port, forming a list of ONUs to be authorized; In a PON network, the OLT device is responsible for connecting ONUs to the network. For an ONU to connect to the OLT, the following authentication process is required: The ONU powers on and reports its device information (including MAC address, serial number, etc.) to the OLT; the OLT's PON service line card detects and discovers a new ONU online and reads its device information; the management user configures authentication information (serial number, password, etc.) for the ONU in the OLT, authorizing its access; the ONU passes the authorization and authentication process and goes online. Subsequently, the OLT manages and configures the ONU using the OMCI protocol.

[0084] In a slicing scenario, a physical OLT is divided into multiple logical OLTs (OLT slices), each isolated from the others. However, an ONU does not belong to any VDS before going online, so it needs to be assigned to a corresponding VDS. Taking the assignment of an ONU to VDS1 as an example, the process of VDS1 discovering the ONU is as follows: VDS1's ONU management module actively initiates a scan request to the underlying PON line card to obtain information (including MAC, serial number, etc.) of all ONU devices that have not completed registration / authorization under the current physical PON port, forming a list of ONUs to be authorized.

[0085] S23. VDSi assigns a local ID, denoted as vds_onuid, to the newly discovered ONU within this slice, and submits a registration request to VDS0 through VSC_LIB. Preferably, vds_onuid starts at 1, and so on. The registration request includes the Slot number, PON port number, vds_onuid, and ONU unique identifier (such as SN or MAC).

[0086] S24. VDS0 queries the global ONU allocation record table, assigns a unique global ONU ID to the newly discovered ONU, writes the mapping relationship between Slot, PON, vds_onuid and global ONU ID into the global ONU allocation record table, and notifies VDSi of the global ONU ID; In this step, the global ONU ID is unique across the entire OLT device and does not repeat with different slices; when VDS0 assigns a global ONU ID to a new ONU, the allocation order is incremented according to the PON port order or the ONU discovery order.

[0087] S25 and VDS0 will batch synchronize the updated global ONU allocation record table to other running OLT slices through the VSC mechanism to ensure that all OLT slices maintain consistency in the global ONU identifier status.

[0088] According to this embodiment, after the target slice sends a service instruction to the service line card, the instruction contains a local ID (vds_onuid). The VSC_LIB converts the vds_onuid into a global ONU ID based on the mapping table in the local cache, and then forwards the instruction containing the global ONU ID to the service line card. The service line card identifies the corresponding physical ONU based on the global ONU ID and executes the service configuration.

[0089] In this embodiment, a unified mapping is achieved through a global ONU ID, resolving the ONU ID conflict issue when multiple slices share a PON port. Even when the PON line card and chip do not support slicing, the ONU management function for each slice is implemented through a software mechanism, eliminating the need for hardware upgrades. The global ONU allocation record table is synchronized to all slices in real time, ensuring consistent understanding of ONU resource status across all slices. ONU management for each slice is independent; an ONU failure in one slice does not affect ONUs in other slices.

[0090] Based on the same inventive concept, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed, implement the functions of the aforementioned OLT slice and business management system or the aforementioned OLT slice lifecycle control method and / or ONU identifier collaborative management method.

[0091] It should be noted that, for the sake of simplicity, the foregoing embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to the present invention.

[0092] In the above embodiments, the descriptions of each embodiment have their own emphasis. Parts not described in detail in a certain embodiment can be referred to in the relevant descriptions of other embodiments. Finally, it should be noted that the above descriptions are merely preferred embodiments of this application and are not intended to limit this application. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. An OLT slicing and service management system, running on an OLT device, the OLT device comprising a main control board and at least one service line card, characterized in that, The system includes: Multiple virtual device services (VDS) are deployed on the main control disk, and each VDS serves an OLT slice through a set of independent processes; The Virtual Slice Controller (VSC), deployed on the main control board, is used to respond to OLT slice management commands, assign unique slice IDs, and send trigger messages. The Virtual Slice Controller (VSCA) is deployed on the main control board and each service line card to receive trigger messages from the VSC, execute state machine scheduling, manage the service components of the target VDS process, and feed back the execution results to the VSC.

2. The system according to claim 1, characterized in that, The OLT device itself acts as the management slice VDS0, and has management permissions for other VDSs, including the creation, startup, shutdown, destruction, and resource allocation of VDSs; Among them, VDS0 allocates physical and logical resources to each VDS; The physical resources include boards, uplink ports, PON ports, CPUs, and memory; The logical resources include the maximum number of ONUs, VLAN specifications, routing capacity, and the number of VPN instances.

3. The system according to claim 1, characterized in that, VSC and VSCA communicate via asynchronous messages. When VSC sends the trigger message, it starts a slice timer and terminates the slice timer when it receives the execution result from VSCA.

4. The system according to claim 1, characterized in that, VSCA executes state machine scheduling to manage the target VDS process's business components, including: Based on the trigger message, VSCA initializes the slice state machine; VSCA performs directory mapping operations to create an independent file directory space for the target VDS; VSCA broadcasts service component control commands to the target VDS to start or stop the service components corresponding to the target VDS.

5. The system according to claim 2, characterized in that, The system also includes: The message transmission and reception management module, deployed on the OLT device, is used to identify the VDS to which the management messages from the external network belong, and to distribute the messages to the corresponding VDS for processing based on the source port, VLAN information, or pre-assigned VDS dedicated port number of the login message.

6. The system according to claim 5, characterized in that, The OLT slice supports at least one of the following login modes: Independent IP login mode: Each VDS is configured with a unique management IP address, and the login is achieved by directly connecting to the management IP address via SSH / Telnet protocol and determining the target VDS based on the packet sending and receiving management module; Single IP command line to login mode: All VDS share the management IP address of the management slice VDS0. First, log in to VDS0, and then execute the switching command in the command line interface of VDS0 to complete the context switch and redirect the terminal session to the target VDS. Single IP + Port Mapping Login Mode: All VDS share the management IP address of the management slice VDS0, and log in to the target VDS through the management IP address of VDS0 and the pre-assigned dedicated VDS port number.

7. A method for controlling the lifecycle of an OLT slice based on the system described in any one of claims 1 to 6, characterized in that, The method includes: VSCA receives a trigger message from VSC and initializes the slice state machine. The trigger message is a message containing a unique slice ID issued by VSC in response to the OLT slice management command. VSCA performs directory mapping operations to create an independent file directory space for the target VDS; VSCA sends service component management commands to the target VDS to start or stop the deployment of service components in the target VDS process, and reports the execution results back to VSC.

8. The method according to claim 7, characterized in that, The method further includes: VSCA sends a slice deployment command to the main control disk, which then dynamically loads or unloads business function components according to a preset component deployment configuration file. It also summarizes the execution results of each VDS process. Once it confirms that all component states are consistent, it reports a component loading or unloading completion event to VSCA. Based on the component loading or unloading completion event, VSCA updates the OLT slice status and sends a message to VSC indicating that the slice creation is complete or the slice service has stopped.

9. A collaborative management method for ONU identifiers based on the system described in any one of claims 2 to 6, characterized in that, The method includes: The management slice VDS0 issues the initial resource configuration to the newly created service slice VDSi, including the Slot number, PON port number, and the maximum number of pre-allocated ONUs; VDS0 calls the VSC_LIB library through VSC to synchronize the global ONU allocation strategy, mapping rules and basic parameters to the VDSi VSC_LIB library; The VDSi ONU management module actively initiates a scan request to the underlying PON line card to obtain information on all ONU devices that have not been registered or authorized under the current physical PON port, forming a list of ONUs to be authorized. VDSi assigns a local ID, denoted as vds_onuid, to the newly discovered ONU within this slice, and submits a registration request to VDS0 via VSC_LIB. The registration request includes the Slot number, PON port number, vds_onuid, and unique ONU identifier. VDS0 queries the global ONU allocation record table, assigns a unique global ONU ID to the newly discovered ONU, writes the mapping relationship between Slot, PON, vds_onuid and global ONU ID into the global ONU allocation record table, and notifies VDSi of the global ONU ID; VDS0 will use the VSC mechanism to batch synchronize the updated global ONU allocation record table to other running OLT slices.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed, perform the functions of the system according to any one of claims 1-6 or the method according to any one of claims 7-9.

Images