A management method, device, system and storage medium for FTTR neutron gateway

Abstract

A method, device, system and storage medium for managing a sub-gateway in an FTTR. The method is applied to a main gateway, wherein the main gateway has at least one sub-gateway including a target sub-gateway connected to it and is connected to an optical line terminal (OLT) on its upper side. The mapping table of the main gateway records the correspondence between the target sub-gateway, the downstream ONU ID and the upstream ONU ID. The method comprises: obtaining a first GEM frame; determining a second frame header of the first GEM frame according to the downstream ONU ID, obtaining a new first GEM frame, and sending the new first GEM frame to the OLT, wherein the new first GEM frame carries the second frame header, the first frame header and a management request message marked by the upstream ONU ID; receiving a second GEM frame returned by the target sub-gateway in response to the new first GEM frame; determining a fourth frame header corresponding to the second GEM frame according to the upstream ONU ID, generating a new second GEM frame, and sending the new second GEM frame to the OLT, thereby achieving the purpose of the OLT managing the target sub-gateway.

Description

Technical Field

[0001] This article relates to network communication technology, and in particular to a management method, device, system and storage medium for an FTTR neutron gateway. Background Art

[0002] Fiber to the Room (FTTR) solutions include FTTR-H (Home FTTR) and FTTR-B (Business FTTR). FTTR technology has rapidly developed in recent years, expanding its applications and placing increasing demands on sub-gateways. This is especially true for FTTR-B, a device used in enterprise scenarios. A single main gateway supports multiple sub-gateways, but sub-gateways can only register with the main gateway's optical line terminal (OLT) and cannot be managed by the main gateway's upstream OLT. Summary of the Invention

[0003] The embodiments of the present application provide a method, device, system, and storage medium for managing an FTTR neutron gateway.

[0004] A method for managing a sub-gateway in an FTTR is applied to a main gateway, wherein the main gateway is connected to at least one sub-gateway including a target sub-gateway and is connected to an optical line terminal (OLT) on the main gateway, wherein a mapping table of the main gateway records the correspondence between the target sub-gateway, the downstream ONU ID, and the upstream ONU ID, wherein the downstream ONU ID is the optical ONU ID assigned to the target sub-gateway after successful registration on the main gateway, and the upstream ONU ID is the ONU ID assigned to the target sub-gateway after successful registration on the OLT, wherein the method comprises:

[0005] Acquire a first GEM frame, wherein the first GEM frame includes a first frame header and a management request message marked by the uplink ONU ID;

[0006] Determine, according to the downlink ONU ID, a second frame header of the first GEM frame, obtain a new first GEM frame, and send the new first GEM frame to the target sub-gateway, wherein the new first GEM frame carries the second frame header, the first frame header, and a management request message marked by the uplink ONU ID, wherein the second frame header and the first frame header in the new first GEM frame jointly instruct the target sub-gateway not to perform a verification operation on the ONU ID in the management request message;

[0007] receiving a second GEM frame returned by the target sub-gateway in response to the new first GEM frame, wherein the second GEM frame carries a third frame header, the first frame header, and a management response message marked by an uplink ONU ID;

[0008] According to the uplink ONU ID, a fourth frame header corresponding to the second GEM frame is determined, a new second GEM frame is generated, and the new second GEM frame is sent to the OLT, wherein the new second GEM frame includes the fourth frame header and a management response message marked by the uplink ONU ID.

[0009] A management system for an FTTR neutron gateway, comprising:

[0010] The main gateway is used to process data using the method described above;

[0011] An OLT, connected to the primary gateway, configured to send a first GEM frame to the primary gateway and receive the new second GEM frame;

[0012] At least one sub-gateway, including a target sub-gateway, is connected to the main gateway, wherein the target sub-gateway is configured to, after receiving the new first GEM frame, determine whether the new first GEM frame has two frame headers; when it is determined that the new first GEM frame has two frame headers, not verify the ONU ID in the management request message, directly respond to the management request message, and send the second GEM frame.

[0013] A storage medium stores a computer program, wherein the computer program is configured to execute the method described above when running.

[0014] A management device for an FTTR neutron gateway includes a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute the method described above.

[0015] In an embodiment of the present application, the main gateway acts as a proxy layer. Through the "single-layer → double-layer → single-layer" GEM frame header conversion mechanism, combined with the correspondence between the ONU IDs maintained by the main gateway, the single-layer GEM frames sent by the OLT are converted into double-layer GEM frames that can be recognized by the sub-gateway, and then the double-layer GEM frames returned by the sub-gateway are restored to single-layer frames that can be processed by the OLT. This implements indirect management of the target sub-gateway by the OLT, solves the problem that the sub-gateway in the FTTR cannot be directly managed by the OLT, and ensures the compatibility and security of the communication path through protocol adaptation.

[0016] Other features and advantages of the present application will be described in the following description, and in part will become apparent from the description, or will be understood by practicing the present application. Other advantages of the present application can be realized and obtained by the solutions described in the description and the drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The accompanying drawings are used to provide an understanding of the technical solution of the present application and constitute a part of the specification. Together with the embodiments of the present application, they are used to explain the technical solution of the present application and do not constitute a limitation on the technical solution of the present application.

[0018] Figure 1 A schematic diagram of the structure of the management system of the FTTR neutron gateway provided in an embodiment of the present application;

[0019] Figure 2 A first flow chart of a method for managing an FTTR neutron gateway provided in an embodiment of the present application;

[0020] Figure 3 This is a second flow chart of the FTTR neutron gateway management method provided in an embodiment of the present application. DETAILED DESCRIPTION

[0021] This application describes multiple embodiments, but this description is exemplary rather than restrictive, and it will be apparent to those skilled in the art that there may be more embodiments and implementations within the scope of the embodiments described herein. Although many possible feature combinations are shown in the drawings and discussed in the detailed description, many other combinations of the disclosed features are also possible. Unless specifically limited, any feature or element of any embodiment may be used in combination with any other feature or element in any other embodiment, or may replace any other feature or element in any other embodiment.

[0022] The present application includes and contemplates combinations of features and elements known to those of ordinary skill in the art. The embodiments, features, and elements disclosed in this application may also be combined with any conventional features or elements to form a unique inventive solution. Any features or elements of any embodiment may also be combined with features or elements from other inventive solutions to form another unique inventive solution. Therefore, it should be understood that any feature shown and / or discussed in this application may be implemented individually or in any appropriate combination. Therefore, except for the limitations made according to the appended claims and their equivalents, the embodiments are not subject to other limitations. In addition, various modifications and changes may be made within the scope of protection of the appended claims.

[0023] In addition, when describing representative embodiments, the specification may have presented the method and / or process as a specific sequence of steps. However, to the extent that the method or process does not rely on the specific order of the steps described herein, the method or process should not be limited to the steps in the specific order described. As will be understood by those skilled in the art, other orders of steps are also possible. Therefore, the specific order of the steps set forth in the specification should not be interpreted as a limitation to the claims. In addition, the claims for the method and / or process should not be limited to performing their steps in the order written, and those skilled in the art can readily understand that these orders can be changed and still remain within the spirit and scope of the embodiments of the present application.

[0024] Figure 1 This is a schematic diagram of the structure of the management system of the FTTR neutron gateway provided in the embodiment of the present application. Figure 1 As shown, the system includes an OLT, a main gateway, and at least one sub-gateway. Each sub-gateway is registered to the downlink passive optical network (PON) interface of the main gateway through its own PON interface, and the uplink PON interface of the main gateway is registered to the OLT.

[0025] Optionally, the system further includes a management platform, wherein the management platform can be connected to the OLT via a management channel.

[0026] exist Figure 1 In the system shown, N sub-gateways are deployed, namely sub-gateway 1, sub-gateway 2, sub-gateway 3, ..., sub-gateway N, wherein any of the N sub-gateways can be used as a target sub-gateway, and N is a positive integer.

[0027] After the target sub-gateway successfully registers on the master gateway, the master gateway allocates a unique identifier, ie, a downlink optical network unit (ONU) identifier ID, to the target sub-gateway and uses it as the local identifier of the target sub-gateway.

[0028] After determining that the target sub-gateway is successfully registered on the OLT, the OLT allocates a unique identifier, ie, an uplink ONU ID, to the target sub-gateway and records the uplink ONU ID as a global identifier of the target sub-gateway.

[0029] After the OLT allocates an uplink ONU ID to the target sub-gateway, the main gateway obtains the uplink ONU ID of the target sub-gateway and records the corresponding relationship between the target sub-gateway, the downlink ONU ID and the uplink ONU ID.

[0030] In an exemplary embodiment, the registration process of the target sub-gateway is as follows:

[0031] Step A1: Obtain the registration information of the target sub-gateway;

[0032] The master gateway collects the target sub-gateway's identity and configuration parameters, providing foundational data for the subsequent registration process. Registration information is the globally unique identifier of the target sub-gateway, including the logical ID (LOID), media access control address (MAC), and serial number (SN). This information is used by the OLT to authenticate and verify the target sub-gateway's identity. The target sub-gateway initiates a registration request to the master gateway via the PON interface, carrying its registration information (such as LOID, MAC, and SN). The master gateway parses the fields in the registration request, extracting and storing the target sub-gateway's registration information.

[0033] Step A2: Record the downstream ONU ID assigned by the primary gateway;

[0034] The target sub-gateway is assigned a locally unique identifier for communication management between the main gateway and the target sub-gateway. The downstream ONU ID is a local identifier (e.g., 0x02) assigned by the main gateway to the target sub-gateway. This identifier is valid only within the main gateway and is used to identify the downstream communication path of the target sub-gateway. After the target sub-gateway successfully registers, the main gateway generates a downstream ONU ID based on a predefined allocation strategy (e.g., sequential allocation or hash mapping). The main gateway binds the downstream ONU ID to the target sub-gateway's registration information (e.g., registration code) and stores it in a local mapping table.

[0035] Among them, before the main gateway assigns the downlink ONU ID to the target sub-gateway, it must first verify the legitimacy of the target sub-gateway's registration information. After the verification passes, the downlink ONU ID is assigned to the target sub-gateway; if the verification fails, the target sub-gateway is notified that the registration has failed.

[0036] Step A3: Send target sub-gateway registration information to the OLT;

[0037] The master gateway passes the acquired registration information of the target sub-gateway to the OLT, triggering the global registration process on the OLT side. Before assigning an uplink ONU ID to the target sub-gateway, the OLT also verifies the validity of the target sub-gateway (for example, whether the LOID is authorized). If the verification passes, the uplink ONU ID is assigned to the target sub-gateway. If the verification fails, the master gateway is notified that the target sub-gateway's registration with the master gateway has been invalidated.

[0038] Step A4: Obtain the upstream ONU ID assigned by the OLT and establish a corresponding relationship;

[0039] Establish a mapping relationship between the target sub-gateway's local identifier (downlink ONU ID) and its global identifier (uplink ONU ID) to enable cross-layer communication. The uplink ONU ID is a global identifier (such as 0x01) assigned by the OLT and used by the OLT to directly manage the target sub-gateway. The master gateway maintains a mapping table to record the binding relationship between the downlink ONU ID and the uplink ONU ID.

[0040] The above process has the following advantages:

[0041] Identity authentication and security management: The OLT verifies the target sub-gateway's registration information (such as the legitimacy of the LOID) to prevent illegal devices from accessing the network and ensure that only authorized devices can join the FTTR system.

[0042] Hierarchical ID management: By separating the downstream ONU ID (local ID) from the upstream ONU ID (global ID), the responsibilities of the master gateway and the OLT are decoupled. The master gateway is responsible for local communication management of the target sub-gateways, while the OLT is responsible for global resource allocation and monitoring, improving system scalability.

[0043] Efficient mapping and query: The corresponding relationship table is based on key-value pairs (the lower link ONU ID The upstream ONU ID design supports fast retrieval, effectively reducing master gateway processing latency. For example, when forwarding data between the OLT and the target sub-gateway, the master gateway can quickly translate the downstream ONU ID to the upstream ONU ID using a hash table or database.

[0044] Take the registration process of a target sub-gateway as an example to illustrate:

[0045] The target sub-gateway initiates registration: The target sub-gateway sends a registration request to the main gateway, carrying the registration code test.

[0046] The main gateway assigns the downstream ONU ID: The main gateway generates the downstream ONU ID = 0x02 and records it in the local table (registration code = test → ONU ID = 0x02).

[0047] The main gateway forwards the registration information to the OLT: the main gateway encapsulates the registration code = test into a GEM frame and sends it to the OLT.

[0048] OLT assigns upstream ONU ID: After verifying the legitimacy of the LOID, the OLT assigns upstream ONU ID = 0x01 and returns it to the main gateway.

[0049] The main gateway establishes a corresponding relationship: the main gateway updates the mapping table, binds the downstream ONU ID = 0x02 and the upstream ONU ID = 0x01, and marks them with the registration code test.

[0050] From the above description, it can be seen that the coordinated registration of the target sub-gateway between the main gateway and the OLT is achieved through hierarchical identification allocation and mapping management.

[0051] Based on the above ONU ID allocation mechanism, the OLT and the master gateway can uniquely identify the target sub-gateway through the upstream ONU ID, and the master gateway and the target sub-gateway can uniquely mark the target sub-gateway through the downstream ONU ID. In addition, the master gateway can forward the management request message issued by the OLT to the target sub-gateway based on the corresponding relationship recorded locally, and can also forward the data uploaded by the target sub-gateway to the OLT.

[0052] Figure 2 This is a first flow chart of the management method of the FTTR neutron gateway provided in the embodiment of the present application. Figure 2 As shown, the method includes:

[0053] Step 201: Acquire a first Gigabit Passive Optical Network Encapsulation Method (GEM) frame sent by an OLT, wherein the first GEM frame includes a first frame header and a management request message marked by the uplink ONU ID;

[0054] The first GEM frame carries only a first frame header, indicating that the first GEM is a single-layer encapsulated data frame sent by the OLT; wherein the first frame header is used to mark the communication path (such as the GEM port identifier Port ID) used by the OLT to send data to the primary gateway to ensure that the data can be correctly routed to the primary gateway;

[0055] The management request message may be generated according to a management instruction issued by a management platform, and the uplink ONU ID therein is used by the OLT to directly locate the target sub-gateway.

[0056] In one implementation, the management request message may be an optical network unit management and control interface (OMCI) message.

[0057] The purpose of this step is for the main gateway to obtain the management request message from the upstream OLT for subsequent processing.

[0058] Specifically, the main gateway monitors the GEM frames from the OLT through the PON interface, filters out the single-layer GEM frames carrying the uplink ONU ID, and extracts the management request message therein.

[0059] Step 202: Determine the second frame header of the first GEM frame according to the downstream ONU ID, obtain a new first GEM frame, and send the new first GEM frame to the downstream ONU.

[0060] The new first GEM frame carries the second frame header, the first frame header, and a management request message marked by an uplink ONU ID, wherein the second frame header and the first frame header in the new first GEM frame jointly indicate that the target sub-gateway does not perform a verification operation on the ONU ID in the management request message;

[0061] In the new first GEM frame, the second frame header is a GEM header added to the outer layer of the single-layer first GEM frame, so that the new first GEM frame has a double-layer frame header structure; wherein the second frame header is used to mark the communication path (such as GEM Port ID) used by the main gateway to send data to the target sub-gateway, so as to ensure that the data can be correctly routed to the target sub-gateway.

[0062] Since the new first GEM frame has a double-layer frame header structure, it can indicate that the target sub-gateway responds to the management request message in the new first GEM. Therefore, there is no need to modify the ONU ID in the management request message to be the downlink ONU ID. The ONU ID can be kept as the uplink ONU ID, thereby reducing the processing pressure of the main gateway.

[0063] The purpose of this step is to adapt the OLT's management request to the sub-gateway's communication protocol level to ensure that the sub-gateway can correctly parse the management request data.

[0064] Specifically, the main gateway queries the pre-stored correspondence according to the uplink ONU ID, obtains the corresponding downlink ONUID, and adds a new GEM header to the first GEM frame of the single-layer frame header as the payload, forming a double-layer GEM frame and sending it to the target sub-gateway.

[0065] Step 203: Receive a second GEM frame returned by the target sub-gateway in response to the new first GEM frame;

[0066] The second GEM frame carries a third frame header, a first frame header, and a management response message marked by an uplink ONU ID; wherein the third frame header is used to mark the communication path (such as GEM Port ID) used by the target sub-gateway to send data to the main gateway to ensure that the data can be correctly routed to the main gateway;

[0067] According to the communication protocol, the ONU ID in the management response message is the same as that in the management request message. Therefore, when the ONU ID in the management request message is the uplink ONU ID of the target sub-gateway, the ONU ID in the management response message is also the uplink ONU ID of the target sub-gateway.

[0068] In one implementation, the management response message may be an OMCI message.

[0069] The function of this step is to receive the management response message returned by the sub-gateway to the management request message, so that the main gateway can use the first GEM frame received before the response.

[0070] Step 204: Determine, based on the upstream ONU ID, a fourth frame header corresponding to the second GEM frame, generate a new second GEM frame, and send the new second GEM frame to the OLT, wherein the new second GEM frame includes the fourth frame header and a management response message marked with the upstream ONU ID.

[0071] The fourth frame header is used to mark the communication path (such as GEM Port ID) used by the main gateway to send data to the OLT, so as to ensure that the data can be correctly routed to the OLT;

[0072] The purpose of this step is to restore the single-layer GEM frame that can be recognized by the OLT and complete the closed-loop transmission of the management response.

[0073] Specifically, the main gateway strips off the outer header of the double-layer GEM frame according to the corresponding relationship, retains the inner header, obtains a single-layer GEM frame including the management response message, and replaces the first frame header with the fourth frame header, so that the new second GEM frame can be sent to the OLT through the upstream PON interface for further processing by the OLT or reporting to the management platform.

[0074] From the above description, it can be seen that the main gateway, as the proxy layer, uses the "single-layer → double-layer → single-layer" GEM frame header conversion mechanism, combined with the correspondence between the ONU IDs maintained by the main gateway, to convert the single-layer GEM frames sent by the OLT into double-layer GEM frames that can be recognized by the sub-gateway, and then restore the double-layer GEM frames returned by the sub-gateway to single-layer frames that can be processed by the OLT. This realizes the indirect management of the target sub-gateway by the OLT, solves the problem that the sub-gateway in FTTR cannot be directly managed by the OLT, and ensures the compatibility and security of the communication path through protocol adaptation.

[0075] In an exemplary embodiment, the first GEM frame and the new second GEM frame share the same GEM port identifier (Port ID), so that the first frame header and the fourth frame header are the same; the new first GEM frame and the second GEM frame share the same GEM port identifier, so that the second frame header and the third frame header are the same.

[0076] In the above exemplary embodiment, the transmission of upstream and downstream data between the OLT and the master gateway shares the same GEMPort ID; the transmission of upstream and downstream data between the master gateway and the target sub-gateway also shares the same GEMPort ID.

[0077] The above exemplary embodiments have the following technical advantages, including:

[0078] Simplified communication path management: In communications between the OLT and the main gateway, both upstream (main gateway → OLT) and downstream (OLT → main gateway) GEM frames are transmitted using the same GEM Port ID. Furthermore, in communications between the main gateway and sub-gateways, both upstream (sub-gateway → main gateway) and downstream (main gateway → sub-gateway) GEM frames use the same GEM Port ID. Using the same GEM Port ID to identify bidirectional communication paths significantly reduces network configuration complexity. For example, when the OLT sends a management request to the main gateway, it is encapsulated using Port ID 100; when the main gateway returns a response to the OLT, it also uses Port ID 100. When the main gateway sends configurations to the sub-gateway, it uses Port ID 200; when the sub-gateway reports data to the main gateway, it also uses Port ID 200.

[0079] Improved protocol compatibility: The master gateway, OLT, and sub-gateways pre-agreed on the Port ID for bidirectional communication. This eliminates the need for the protocol stack to dynamically switch identifiers when processing GEM frames. Furthermore, during GEM frame encapsulation, the master gateway automatically reuses the same Port ID based on the communication direction (uplink / downlink) without additional configuration. This effectively avoids protocol parsing conflicts caused by inconsistent bidirectional Port IDs, significantly enhancing interoperability between devices.

[0080] Optimized resource allocation and scheduling: The master gateway assigns a fixed Port ID to each sub-gateway to handle all bidirectional interactions, such as status query, configuration delivery, and alarm reporting. The OLT and master gateway are managed through a globally unified Port ID pool, effectively preventing identifier conflicts between multiple devices. This fixed Port ID approach reduces resource allocation overhead and improves data transmission efficiency.

[0081] Reduced configuration complexity: There's no need to configure separate port IDs for upstream and downstream communications, significantly reducing manual intervention and the risk of configuration errors. Traditional solutions require separate port IDs for bidirectional communication, such as Port 100 for upstream and Port 101 for downstream. This solution, by sharing the same port ID, simplifies network topology design and management.

[0082] Enhanced system stability: Fixed port IDs reduce the frequency of dynamic routing table updates, minimizing the risk of packet loss or latency due to ID switching. For example, in traffic bursts, such as when a large number of sub-gateways report data simultaneously, fixed port IDs ensure a deterministic communication path and avoid resource contention caused by dynamic allocation.

[0083] Improved compatibility and scalability: The unified Port ID design facilitates integration of OLTs, master gateways, and sub-gateways from different vendors, reducing protocol adaptation costs. For example, when a master gateway needs to connect to a third-party OLT, it only needs to ensure that the agreed-upon Port IDs are consistent, eliminating the need to modify the existing protocol stack or hardware logic.

[0084] Avoiding traffic conflicts: Pre-allocating and fixing port IDs, combined with traffic scheduling mechanisms such as priority tagging, effectively prevents conflicts in bidirectional data flows. For example, the primary gateway can classify and schedule upstream and downstream traffic based on port IDs, such as prioritizing management messages, to ensure that critical services are not affected by congestion.

[0085] Take the status query process as an example to illustrate:

[0086] The OLT sends a query request (downstream): encapsulates a GEM frame using Port ID = 100 and sends it to the primary gateway.

[0087] The main gateway forwards to the sub-gateway (downstream): Use Port ID=200 to encapsulate the GEM frame and send it to the target sub-gateway.

[0088] The sub-gateway returns a response (upstream): It uses Port ID=200 to encapsulate the GEM frame and returns it to the main gateway.

[0089] The main gateway forwards to the OLT (uplink): uses Port ID = 100 to encapsulate the GEM frame and returns it to the OLT.

[0090] From the above example, we can see that during the two-way communication process, the OLT and the main gateway always use Port ID = 100, and the main gateway and the sub-gateway always use Port ID = 200. The entire process does not require dynamic switching.

[0091] Based on the above description, it can be seen that the embodiment of the present application can effectively cope with the management challenges in large-scale sub-gateway scenarios through the design of sharing the same GEM port identifier.

[0092] Figure 3 This is a second flow chart of the management method of the FTTR neutron gateway provided in the embodiment of the present application. Figure 3 As shown, the method includes:

[0093] Step 301: Receive a third GEM frame carrying a fifth frame header and communication data sent by a target sub-gateway;

[0094] The main gateway receives raw data (such as service data or alarm data) reported by the target sub-gateway as input for subsequent processing. The fifth frame header identifies the communication path (such as the GEM Port ID) between the sub-gateway and the main gateway, ensuring that data is correctly routed from the sub-gateway to the main gateway. The communication data contains service information or alarm information (such as optical power anomalies or CPU overload) about the sub-gateway, with the downstream ONU ID identifying the source of the data. The main gateway monitors GEM frames sent by the target sub-gateway through the downstream PON interface, filters out the third GEM frame carrying the fifth frame header (for example, GEM Port ID = 300), and parses the downstream ONU ID in the communication data to confirm the identity of the sub-gateway from which the data originated.

[0095] Step 302: Determine whether the communication data contains alarm data;

[0096] Distinguish normal service data from alarm data, and execute specific processing only for alarm data. Alarm data is abnormal status information (such as excessive optical power or device failure) triggered by a sub-gateway and is typically identified by a specific protocol field (such as the OMCI message type 0x0A). The master gateway parses the communication data in the third GEM frame and checks the message type field in the protocol header (for example, whether the OMCI message type is 0x0A). If an alarm indicator is detected, steps 303 and 304 are executed; otherwise, the data is processed as normal service data.

[0097] Step 303: Replace the downstream ONU ID with the upstream ONU ID according to the corresponding relationship;

[0098] The sub-gateway's local identifier (downlink ONU ID) is converted into a global identifier (uplink ONUID) recognizable by the OLT, ensuring that alarm information can be correctly interpreted by the OLT and reported to the management platform. Using the mapping maintained by the master gateway, it records the binding relationship between the sub-gateway's downlink ONU ID and the uplink ONU ID. The master gateway queries the mapping based on the downlink ONU ID, obtains the required uplink ONU ID, and replaces the downlink ONU ID field in the communication data with the obtained uplink ONU ID (for example, replacing ONU ID = 0x02 with ONU ID = 0x01).

[0099] Step 304: Replace the fifth frame header with the sixth frame header to generate a new third GEM frame;

[0100] To adapt to the OLT's communication protocol requirements, the sub-gateway's local path identifier is converted to the OLT's global path identifier. The sixth frame header is used to identify the communication path between the main gateway and the OLT (for example, GEM Port ID = 100), ensuring correct data routing from the main gateway to the OLT. This is achieved by removing the fifth frame header (GEM Port ID = 300) from the original third GEM frame and adding the sixth frame header (GEM Port ID = 100). For example, the new GEM frame structure is: [Sixth frame header (GEM Port ID = 100)] + [Communication data (including the upstream ONU ID = 0x01)].

[0101] Step 305: Send the new third GEM frame to the OLT;

[0102] This completes the alarm reporting loop, enabling the OLT to synchronize the sub-gateway status with the management platform. The master gateway sends the new third GEM frame to the OLT via the uplink PON port. The OLT parses the uplink ONU ID in the frame, associates it with the specific sub-gateway, and reports the alarm to the management platform.

[0103] The technical advantages of the above process are:

[0104] Improved alarm reporting efficiency: By dynamically replacing the ONU ID and frame header through the master gateway, alarm information can be directly transmitted to the OLT without polling from the management platform, reducing latency. Traditionally, the management platform must actively poll the status of sub-gateways. This solution achieves real-time alarm transmission through active reporting from sub-gateways and protocol adaptation to the master gateway.

[0105] Enhanced data security: The master gateway replaces the ONU ID, hiding the local identity of the sub-gateway, preventing external attackers from tracing the device topology through the downstream ONU ID. The OLT only perceives the global identity (the upstream ONU ID), and the sub-gateway's true network location is invisible to upper layers, reducing security risks.

[0106] Optimize resource allocation: The GEM port ID in the sixth frame header is fixed (e.g., port ID = 100) to avoid resource fragmentation caused by dynamic allocation. Alarm traffic between the OLT and the main gateway is managed through a unified port ID, simplifying traffic scheduling strategies and improving bandwidth utilization.

[0107] Improved system compatibility: The master gateway's frame header replacement mechanism shields protocol differences between sub-gateways and the OLT, supporting mixed networking of heterogeneous devices. Even if the sub-gateway and OLT come from different manufacturers, the master gateway can still achieve seamless integration through mapping tables and frame header reconstruction.

[0108] This article uses the abnormal optical power alarm as an example to illustrate:

[0109] The sub-gateway detects an anomaly: the optical power exceeds the threshold, and generates an alarm message (OMCI type 0x0A), which is encapsulated into the third GEM frame (fifth frame header: Port ID = 300, downstream ONU ID = 0x02).

[0110] The main gateway receives and processes the alarm: it analyzes the alarm type and triggers ONU ID replacement (0x02→0x01) and frame header replacement (Port ID=300→100).

[0111] Sent to OLT: The new GEM frame (Port ID = 100, upstream ONU ID = 0x01) is received and parsed by the OLT.

[0112] Management platform alarm display: OLT reports the alarm information (sub-gateway 0x01 optical power abnormality) to the management platform, triggering an operation and maintenance response.

[0113] Based on the above description, it can be seen that the accurate reporting and protocol adaptation of sub-gateway alarm information are achieved through dynamic identification replacement and frame header reconstruction technology.

[0114] In an exemplary embodiment, at least one of the registration information of the target sub-gateway and the uplink ONU ID is carried in a header of an optical network unit management and control interface OMCI message in a GEM frame.

[0115] Among them, OMCI messages are used for management information interaction between the main gateway and OLT.

[0116] In the above exemplary embodiment, by extending the OMCI protocol, the main gateway encapsulates the registration information (LOID, MAC, SN, etc.) of the target sub-gateway into the OMCI message header of the GEM frame, and then sends the GEM frame to the OLT through the uplink PON port, requesting the OLT to allocate a global identifier for the target sub-gateway.

[0117] After the OLT allocates the uplink ONU ID to the target sub-gateway, it encapsulates the uplink ONU ID into the frame header of the GEM frame through the OMCI message and returns it to the main gateway.

[0118] The main gateway parses the header of the OMCI message in the GEM frame sent by the OLT, extracts the upstream ONU ID, and binds it with the downstream ONU ID recorded locally to form a corresponding relationship.

[0119] The above exemplary embodiment extends the OMCI protocol to transmit registration information, making it compatible with existing GPON equipment and reducing deployment costs. The main gateway and OLT do not need to upgrade their hardware; functionality enhancements can be achieved by simply supporting custom OMCI message types in the protocol stack.

[0120] In an exemplary embodiment, the message header of the OMCI message includes at least a message type field, a data field and a device identification field; wherein:

[0121] The message type field is used to store a value for indicating a registration operation of a sub-gateway;

[0122] The data field is used to store the registration information of the target sub-gateway;

[0123] The device identification field is used to store the uplink ONU ID of the target sub-gateway.

[0124] The above three fields are located in the reserved fields in the OMCI message.

[0125] In the embodiment of the present application, the message format is improved as follows:

[0126] New message type: The OMCI protocol message header now includes a new message type value, 0x17, defined as ProxyReg, which is used to proxy registration requests for sub-gateways. This extension enables sub-gateways to initiate registration with the upstream OLT through the master gateway, resolving the issue of traditional protocols that prevented direct management of sub-gateways.

[0127] Data field expansion: Sub-gateway registration information (such as LOID, MAC, and SN) has been added to the Data field, enabling the upstream OLT to obtain the detailed identity of the sub-gateway and complete authentication and information recording. Structured data encapsulation ensures the integrity and parsability of registration information, supporting unified management of sub-gateways by the OLT.

[0128] Device Identifier Optimization: The DeviceIdentifier field is now explicitly used to carry the ONU ID assigned by the upstream OLT to the master gateway. This improvement makes message routing more accurate, avoids confusion between the master gateway and sub-gateway identifiers, and enhances the OLT's ability to manage hierarchical devices.

[0129] In addition, during the target sub-gateway registration process in the OLT, the message header of the OMCI message may include the following two fields in addition to the message type field, data field, and device identification field:

[0130] Transaction Correlation Identifier (TCI): A key field in the OMCI message header, TCI uniquely identifies a management transaction. Its primary function is to ensure that requests sent by the optical line terminal (OLT) and responses returned by the optical network unit (ONU) are correctly matched, preventing data confusion caused by asynchronous communication or concurrent operations. For example, when the OLT initiates a management request (such as a configuration release or status query), it generates a unique TCI value (typically a 16-bit or 32-bit integer). After processing the request, the ONU returns a response message carrying the same TCI value, enabling the OLT to associate the response with the original request.

[0131] Attribute Mask: This can be a bit mask field used to specify the attributes that need to be operated in the OMCI message. It uses binary bits to mark which attributes need to be read, set, or modified, thereby achieving refined control of ONU parameters. Each bit corresponds to a specific attribute. For example, bit 0 indicates the optical module status, bit 1 indicates CPU utilization, etc. If a position is set to 1, it indicates that the attribute needs to be operated; if it is set to 0, it means it is ignored. For example, Attribute Mask = 0x03 (binary 00000011) indicates that the attributes corresponding to bits 0 and 1 are operated simultaneously.

[0132] In the above exemplary embodiments, efficient registration and management of the sub-gateway on the upstream OLT is achieved through protocol extension and message structure optimization.

[0133] Below Figure 1 The management system of the FTTR Neutron Gateway is described as follows:

[0134] Figure 1 The system includes a main gateway, an OLT, and at least one sub-gateway including a target sub-gateway, wherein the OLT and all sub-gateways are connected to the main gateway;

[0135] In the above system, at least the following two functions can be realized:

[0136] One is to realize the management function of the management platform on the target sub-gateway, including:

[0137] The main gateway is used to process data using the method described above;

[0138] The OLT is configured to send a first GEM frame to the primary gateway, and receive the new second GEM frame;

[0139] The target sub-gateway is configured to, after receiving the new first GEM frame, determine whether the new first GEM frame has two frame headers; when it is determined that the new first GEM frame has two frame headers, not verify the ONU ID in the management request message, directly respond to the management request message, and send the second GEM frame.

[0140] The specific implementation is as follows:

[0141] The OLT generates a management request message based on the management instruction issued by the management platform, and uses the upstream ONU ID to accurately identify the sub-gateway identity and send the first GEM frame, eliminating the need for management platform polling and reducing the processing pressure on the management platform.

[0142] When the master gateway receives the first GEM frame sent by the OLT, it determines the downlink ONU ID corresponding to the uplink ONU ID in the management request message according to the above correspondence, determines that the recipient of the management request message is the target sub-gateway, adds a new frame header to the first GEM frame, obtains a new first GEM frame, and sends the new first GEM frame to the target sub-gateway;

[0143] After receiving the new first GEM frame sent by the master gateway, the target sub-gateway determines whether the new second GEM frame has two frame headers. After determining that the new second GEM frame has two frame headers, the target sub-gateway does not verify the ONU ID in the management request message, directly responds to the management request message, obtains a management response message, and sends the second GEM frame to the master gateway.

[0144] After receiving the second GEM frame sent by the target sub-gateway, the main gateway identifies the ONU ID in the management response message in the second GEM frame, determines that the ONU ID is the uplink ONU ID, generates a new second GEM frame, and sends the new second GEM frame to the OLT;

[0145] After receiving the new second GEM frame sent by the main gateway, the OLT accurately identifies the sub-gateway identity according to the uplink ONU ID in the management response message, and returns the response data in the management response message to the management platform.

[0146] Optionally, after the main gateway receives the GEM frame from the OLT, it can preferentially determine whether the ONUID carried by the received GEM frame is the ONU ID assigned by the OLT to the main gateway. If it is the ONU ID assigned by the OLT to the main gateway, the main gateway processes the message in the received GEM frame; otherwise, it further determines whether it is the ONU ID assigned by the OLT to any sub-gateway. If so, the single-layer GEM frame sent by the OLT is converted into a double-layer GEM frame that can be recognized by the sub-gateway; otherwise, the received GEM frame is discarded.

[0147] Optionally, after the target sub-gateway receives the GEM frame from the master gateway, when it is determined that the received GEM frame has a single-layer frame header, the target sub-gateway directly processes the message in the received GEM frame.

[0148] The other is the function of the target sub-gateway actively reporting alarm data to the management platform, including:

[0149] The target sub-gateway is configured to send the third GEM frame;

[0150] The primary gateway is configured to send the new third GEM frame to the OLT after receiving the third GEM frame;

[0151] The OLT is configured to send the alarm information of the target sub-gateway to the management platform after receiving the new third GEM frame.

[0152] The specific implementation is as follows:

[0153] The target sub-gateway detects an anomaly (such as excessive optical power or CPU overload), generates a third GEM frame carrying the downstream ONU ID and sends it to the master gateway.

[0154] After receiving the third GEM frame sent by the target sub-gateway, the master gateway replaces the downlink ONU ID in the alarm message with the uplink ONU ID according to the corresponding relationship so that the OLT can identify which sub-gateway it comes from. It also replaces the frame header of the third GEM frame to obtain a new third GEM frame and sends the new third GEM frame to the OLT.

[0155] After receiving the new third GEM frame sent by the main gateway, the OLT extracts the ONU ID in the alarm message, determines the sub-gateway information (such as SN, registration code) and alarm content, and reports it to the management platform.

[0156] exist Figure 1 In the system shown, the OLT is used to parse the data of the sub-gateway reported by the main gateway to obtain monitoring data, and report data to the management platform based on the monitoring data, wherein the report content includes:

[0157] Application scenario 1: When detecting that the state information of the target sub-gateway changes, the changed state information of the target sub-gateway is sent to the management platform;

[0158] For example, suppose the target sub-gateway is sub-gateway 1. Sub-gateway 1 is originally in normal working order, with its status information being online. When sub-gateway 1 becomes offline due to a hardware failure or network issue, the OLT detects the change in sub-gateway status information. The OLT sends the changed status information (offline) to the management platform, which then updates the status display of sub-gateway 1 and can trigger corresponding maintenance procedures based on pre-set rules, such as notifying operations and maintenance personnel to conduct an inspection.

[0159] The technical advantage of the above processing method is that the OLT monitors the sub-gateway status information in real time and reports it to the management platform, enabling the management platform to grasp the latest status of the sub-gateway in a timely and accurate manner, facilitating rapid response to network changes, improving the efficiency and accuracy of network management, and reducing operation and maintenance delays caused by delayed status information.

[0160] Application scenario 2: When an alarm is detected on the target sub-gateway, the alarm information of the target sub-gateway is sent to the management platform;

[0161] For example, suppose the target sub-gateway is sub-gateway 2. During operation, sub-gateway 2 detects that the optical power exceeds a preset threshold (e.g., too high or too low), triggering an alarm. Sub-gateway 2 proactively sends the alarm to the master gateway. The master gateway, based on the corresponding relationship with sub-gateway 2, forwards the alarm to the OLT. Upon receiving the alarm, the OLT sends it to the management platform, which records the alarm and displays the alarm details. This helps operations and maintenance personnel promptly understand the sub-gateway's abnormality and take appropriate measures, such as adjusting the optical power and checking the fiber connection.

[0162] The technical advantage of this approach is that alarm information generated by the sub-gateway can be proactively reported to the management platform through the OLT, enabling timely transmission and effective management of alarm information. This helps operations personnel quickly locate and resolve sub-gateway issues, reducing troubleshooting time, ensuring normal network operation, and improving network reliability and stability.

[0163] Application scenario three: If the number of illegal ONU registration operations on the master gateway reaches a preset threshold within a preset unit time, a security risk prompt message is sent to the management platform to indicate that there is a security risk on the master gateway.

[0164] For example, if an illegal ONU registers with the primary gateway more than 50 times within a preset timeframe (e.g., one hour), the OLT detects the anomaly and determines that the primary gateway presents a security risk. The OLT then sends a security risk alert to the management platform, which then takes appropriate action based on the risk level. This can include hardening the primary gateway, restricting some of its functions, or dispatching installation and maintenance personnel for an on-site inspection to eliminate the potential safety hazard.

[0165] The technical advantage of this approach is that the OLT can monitor the frequency of illegal ONU registrations and promptly send security risk alerts to the management platform when the threshold is reached, effectively preventing malicious attacks from illegal devices and protecting network security. This mechanism helps reduce the risk of network failures and data leakage caused by unauthorized access, improves overall network security, and ensures the legitimate use of network resources.

[0166] As can be seen from the above application scenarios and technical advantages, the OLT can effectively parse and report sub-gateway data reported by the main gateway, enabling real-time monitoring and effective management of sub-gateways. This not only enables the management platform to monitor sub-gateways, but also effectively reduces the impact on management platform performance through OLT autonomous management. In addition, when the main gateway frequently receives illegal ONU registration attacks, the OLT autonomous management method of this solution can effectively segment the impact range of flooding attacks, effectively preventing such flooding attacks from causing service anomalies on the management platform, and improving the security, reliability, and operation and maintenance efficiency of the FTTR network.

[0167] An embodiment of the present application further provides a storage medium, wherein the storage medium stores a computer program, wherein the computer program is configured to execute the method described above when running.

[0168] An embodiment of the present application further provides a management device for an FTTR neutron gateway, comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute the method described above.

[0169] Those skilled in the art will appreciate that all or some of the steps, systems, and functional modules / units in the methods, systems, and devices disclosed above may be implemented as software, firmware, hardware, or any combination thereof. In hardware implementations, the division between functional modules / units described above does not necessarily correspond to the division between physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all components may be implemented as software executed by a processor, such as a digital signal processor or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit. Such software may be distributed on computer-readable media, which may include computer storage media (or non-transitory media) and communication media (or transient media). As is well known to those skilled in the art, the term "computer storage media" encompasses volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and can be accessed by a computer. In addition, as is well known to those skilled in the art, communication media typically embodies computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and may include any information delivery media.

Claims

1. A method for managing a sub-gateway in an FTTR, applied to a main gateway, wherein the main gateway is connected to at least one sub-gateway including a target sub-gateway and is connected to an optical line terminal (OLT) on the main gateway, wherein a mapping table of the main gateway records the correspondence between the target sub-gateway, the downstream ONU ID, and the upstream ONU ID, wherein the downstream ONU ID is the ONU ID assigned to the target sub-gateway after successful registration on the main gateway, and the upstream ONU ID is the ONU ID assigned to the target sub-gateway after successful registration on the OLT, wherein the method comprises: Obtaining a first GEM frame, wherein the first GEM frame includes a first frame header and a management request message marked by the uplink ONU ID, wherein the first frame header is used to mark a communication path used by the OLT to send data to the primary gateway; Determine, according to the downlink ONU ID, a second frame header of the first GEM frame, obtain a new first GEM frame, and send the new first GEM frame, wherein the new first GEM frame carries the second frame header, the first frame header, and a management request message marked by the uplink ONU ID, wherein the second frame header and the first frame header in the new first GEM frame jointly instruct the target sub-gateway not to perform a verification operation on the uplink ONU ID in the management request message, and the second frame header is used to mark the communication path used by the master gateway to send data to the target sub-gateway; receiving a second GEM frame returned by the target sub-gateway in response to the new first GEM frame, wherein the second GEM frame carries a third frame header, the first frame header, and a management response message marked by an uplink ONU ID, wherein the third frame header is used to mark a communication path used by the target sub-gateway to send data to the master gateway; Determine, according to the uplink ONU ID, a fourth frame header corresponding to the second GEM frame, generate a new second GEM frame, and send the new second GEM frame to the OLT, wherein the new second GEM frame includes the fourth frame header and a management response message marked by the uplink ONUID, and the fourth frame header is used to mark a communication path used by the primary gateway to send data to the OLT.

2. The method according to claim 1, wherein: The first GEM frame and the new second GEM frame share the same GEM port identifier, so that the first frame header and the fourth frame header are the same; The new first GEM frame and the second GEM frame share the same GEM port identifier, so that the second frame header and the third frame header are the same.

3. The method according to claim 1, characterized in that The method further comprises: Receiving a third GEM frame sent by the target sub-gateway and carrying a fifth frame header and communication data marked by a downlink ONU ID, wherein the fifth frame header is used to identify a communication path used by the target sub-gateway to send data to the main gateway; When the communication data in the third GEM frame includes alarm data, the downstream ONU ID in the communication data is replaced with the upstream ONU ID, and the fifth frame header is replaced with a sixth frame header according to the corresponding relationship to obtain a new third GEM frame. The new third GEM frame is sent to the OLT, and the sixth frame header is used to identify the communication path used by the main gateway to send data to the OLT.

4. The method according to claim 1, wherein The method for obtaining the corresponding relationship includes: Obtaining registration information of the target sub-gateway; After the target sub-gateway is successfully registered on the master gateway, the downlink ONU ID allocated by the master gateway to the target sub-gateway is recorded, and the registration information of the target sub-gateway is sent to the OLT; After the target sub-gateway is successfully registered on the OLT, the uplink ONU ID allocated by the OLT to the target sub-gateway is obtained, and the corresponding relationship is established.

5. The method according to claim 4, characterized in that: At least one of the registration information of the target sub-gateway and the uplink ONU ID is carried by a message header of an optical network unit management and control interface OMCI message in a GEM frame.

6. The method according to claim 5, characterized in that The message header of the OMCI message includes at least a message type field, a data field and a device identification field; wherein: The message type field is used to store a value for indicating a registration operation of a sub-gateway; The data field is used to store the registration information of the target sub-gateway; The device identification field is used to store the uplink ONU ID of the target sub-gateway.

7. A management system for an FTTR neutron gateway, comprising: A main gateway, configured to process data using the method according to any one of claims 1 to 6; An OLT, connected to the primary gateway, configured to send a first GEM frame to the primary gateway and receive the new second GEM frame; At least one sub-gateway, including a target sub-gateway, is connected to the main gateway, wherein the target sub-gateway is configured to, after receiving the new first GEM frame, determine whether the new first GEM frame has two frame headers, and when it is determined that the new first GEM frame has two frame headers, not verify the uplink ONU ID in the management request message, directly respond to the management request message, and send the second GEM frame.

8. The system according to claim 7, characterized in that: The OLT is further configured to parse the sub-gateway data reported by the main gateway to obtain monitoring data, and report the data to the management platform based on the monitoring data.

9. The system according to claim 8, characterized in that: The OLT is configured to send the changed state information of the target sub-gateway to the management platform when detecting that the state information of the target sub-gateway has changed; or when an alarm is detected in the target sub-gateway, sending the alarm information of the target sub-gateway to the management platform; Alternatively, if the number of operations of illegal ONUs registering the master gateway within a preset unit time reaches a preset threshold, a security risk prompt message is sent to the management platform to indicate that there is a security risk in the master gateway.

10. A management device for an FTTR neutron gateway, comprising a memory and a processor, characterized in that: A computer program is stored in the memory, and the processor is configured to run the computer program to perform the method according to any one of claims 1 to 6.

11. A storage medium, characterized in that: The storage medium stores a computer program, wherein the computer program is configured to execute the method according to any one of claims 1 to 6 when executed.

Images