CN108449204B

CN108449204B - ROF equipment management system and method

Info

Publication number: CN108449204B
Application number: CN201810174942.XA
Authority: CN
Inventors: 吴红青; 张继红; 李军成
Original assignee: Fiberhome Telecommunication Technologies Co Ltd
Current assignee: Fiberhome Telecommunication Technologies Co Ltd
Priority date: 2018-03-02
Filing date: 2018-03-02
Publication date: 2020-12-15
Anticipated expiration: 2038-03-02
Also published as: CN108449204A

Abstract

The invention discloses a system and a method for managing ROF equipment, and relates to the technical field of networks. The management system includes: the method comprises the steps that a remote OAM client and a remote OAM entity are created and initialized when a remote BTU is initialized, the remote OAM client is used for enabling and configuring the remote OAM entity, and OAMPDU information is sent and received outwards through the remote OAM entity so as to establish and manage OAM connection; the home terminal OAM client management module is used for creating and managing a home terminal OAM client and a home terminal OAM entity according to OAMPDU information sent by each remote terminal BTU, and the home terminal OAM client is used for enabling and configuring the home terminal OAM entity, and establishing OAM connection with the remote OAM client through the home terminal OAM entity and the remote OAM entity and managing the OAM connection. The invention can reduce the workload of development, test and verification of PON system management software and improve the efficiency.

Description

ROF equipment management system and method

Technical Field

The invention relates to the technical field of communication, in particular to a system and a method for managing ROF equipment.

Background

With the increasing development of wireless technology, wireless transmission technology is more and more accepted by various industries. The wireless transmission mode is adopted in more occasions due to the characteristics of convenience in installation, strong flexibility, high cost performance and the like. The Radio Over Fiber (ROF) technology is a Radio access technology combining optical Fiber communication and wireless communication, which is newly developed in response to the high-speed and high-capacity wireless communication demand. The microwave is modulated to laser at a central station, modulated light waves are transmitted to a base station through a complex optical fiber link, microwave signals are demodulated through photoelectric conversion, and then the demodulated microwave signals are transmitted through an antenna for users to use. The ROF device includes a CS (Central Station), an optical transmission link, a BS (Base Station), and a BTU (Broadband Terminal Unit), uses an optical fiber as a transmission link between the Base Station and the Central Station, and directly uses an optical carrier to transmit a radio frequency signal. The optical fiber only plays a role in transmission, exchange, control and signal regeneration are concentrated in a central station, and the base station only realizes photoelectric conversion, so that complex and expensive equipment can be concentrated in the central station, a plurality of remote base stations can share the equipment, and the power consumption and the cost of the base station are reduced.

A PON (Passive Optical Network) includes an OLT (Optical Line Terminal) of a central office, an ODN (Optical Distribution Network) including a Passive Optical device, and an ONU/ONT (Optical Network Unit/Optical Network Terminal) of a user Terminal. PON technologies include EPON (Ethernet Passive Optical Network) and GPON (Gigabit-capable Passive Optical Network). At present, the OLT has two mature management modes for managing the ONU: OAM (operation Administration and Maintenance) in EPON and ONU Management and Control Interface (OMCI) in GPON.

Because the ROF technology is different from the PON technology, accessing a single disk based on the ROF technology to a PON system generally means that a machine frame, a set of management system, and a new management mode need to be added to the PON system, and a large amount of manpower needs to be invested to develop related management and maintenance modules, which results in that the software code development, maintenance, and test workload is multiplied, and mainly expressed in the following two aspects:

(1) due to the difference between the single-disk and PON system management protocols, different software and multiple versions will be added, and the development and maintenance workload increases.

(2) The added software may not be consistent with the requirements of customers, and the customer requirements need to be combed from the beginning, so that the workload is large. If the combing is not reasonable, the application scene required by the user can not be met.

At present, there is no method for effectively managing a PON system integrated with an ROF device, and therefore how to effectively implement management of related devices is an urgent problem to be solved in the art.

Disclosure of Invention

Aiming at the defects in the prior art, the invention aims to provide a system and a method for managing ROF equipment, which realize the management and maintenance of a local ROF line card on a remote BTU (Business to Unit) by respectively arranging OAM (operation administration and maintenance) client management module at the local end and the remote end of the ROF equipment, reduce the workload of the development, the test and the verification of PON (Passive optical network) system management software and improve the management efficiency.

The invention provides a management system of ROF equipment, the ROF equipment comprises an ROF line card arranged in an OLT and at least one remote end BTU, the management system comprises:

the method comprises the steps that a remote OAM client and a remote OAM entity are created and initialized when a remote BTU is initialized, the remote OAM client is used for enabling and configuring the remote OAM entity, and OAMPDU information of an OAM protocol data unit is sent and received outwards through the remote OAM entity so as to establish and manage OAM connection;

the local OAM client management module is arranged in the ROF line card and used for creating and managing a local OAM client and a local OAM entity according to OAMPDU information sent by each remote BTU, the local OAM client is used for enabling and configuring the local OAM entity and establishing OAM connection with the remote OAM client through the local OAM entity and the remote OAM entity and managing the OAM connection, and the local OAM entity and the remote OAM entity are interacted through the OAMPDU information.

On the basis of the technical scheme, the states of the remote OAM entity and the local OAM entity comprise an error state, an active sending state, a receiving waiting state, a two-party handshake negotiation state, a one-party satisfactory two-party handshake negotiation state and a receiving and sending arbitrary packet state.

On the basis of the technical scheme, both the remote OAM entity and the home OAM entity comprise a control module, a multiplexing module and an analysis module, wherein the control module and the multiplexing module are interacted through a request service interface inside the home OAM, the control module and the analysis module are interacted through an indication service interface inside the home OAM, the analysis module of the remote OAM entity is used for receiving a lower-layer MAC frame through an indication interface of a lower-layer sublayer and directly forwarding a common MAC frame between a lower layer and an MAC client, and the analysis module of the home OAM entity is used for receiving an Ethernet frame forwarded by the home OAM client;

the control module is used for interacting with the local end OAM client through an OAM control interface and an OAMPDU request and indication service interface respectively, receiving and transmitting OAMPDU information and transmitting control and state parameters; establishing a link between the control and a remote OAM client; transmitting OAMPDU information to a multiplexing module and receiving OAMPDU information from an analysis module through a request and indication service interface inside the OAM of the terminal;

the analysis module is used for analyzing the received Ethernet frame to obtain an OAMPDU frame, a loopback frame and a common MAC frame, forwarding the OAMPDU frame to the control module, forwarding the loopback frame to the multiplexing module and forwarding the common MAC frame to an upper MAC layer;

the multiplexing module is used for receiving OAMPDU information from the control module and loopback frames from the analysis module, performing Ethernet packet packing and sending the Ethernet packet to the MAC layer.

On the basis of the technical scheme, the OAMPDU information is a standard OAM data packet or an OMCI data packet.

On the basis of the technical scheme, the control module comprises a packet sending timer and a packet sending counter, and the control module determines whether to send an OAMPDU information sending request or not according to a judgment condition;

wherein the determination condition includes: the OAM entity where the control module is located is in a processing mode of only receiving OAMPDUs, and whether OAMPDU packet sending requests are valid.

On the basis of the technical scheme, the multiplexing module is used for setting the highest bit of the mark field of the OAMPDU information, and expanding the OAMPDU frame so as to carry the OMCI data packet.

The invention also provides an ROF device management method based on the ROF device management system, which comprises the following steps:

the ROF line card and the remote BTU are electrified and initialized;

the remote end BTU creates a remote end OAM client and a remote end OAM entity, the remote end OAM client enables and configures the remote end OAM entity, and OAMPDU information is sent out through the remote end OAM entity;

and after receiving the OAMPDU message, the local end OAM client management module creates and manages a local end OAM client and a local end OAM entity, enables and configures the local end OAM entity by the local end OAM client, and establishes and manages OAM connection with the remote end OAM client through the local end OAM entity and the remote end OAM entity.

On the basis of the technical scheme, establishing the OAM connection comprises the following steps: the working mode of the local OAM client is an active mode, the working mode of the remote OAM client is a passive mode, the local OAM client initiates OAM connection to the remote OAM client through a local OAM entity, and the OAM connection is established through an OAM discovery process.

On the basis of the above technical solution, managing OAM connection includes: the OAMPDU processing method includes that a local end OAM client management module receives OAMPDU information sent by a remote end BTU and forwards the OAMPDU information to other remote end OAM entities matched with the remote end BTU;

the OAM client side of the local end sends OAMPDU information of OAM link events and corresponding OAMPDU response information to the OAM entity of the local end based on OAMPDU response rules;

and the remote OAM client sends OAMPDU information of OAM link events and corresponding OAMPDU response information to the remote OAM entity based on the OAMPDU response rule.

On the basis of the technical scheme, both the remote OAM entity and the home OAM entity comprise a control module, a multiplexing module and an analysis module, wherein the analysis module of the remote OAM entity is used for receiving a lower-layer MAC frame through an indication interface of a lower-layer sublayer and directly forwarding a common MAC frame between a lower layer and an MAC client, and the analysis module of the home OAM entity is used for receiving an Ethernet frame forwarded by the home OAM client;

the OAMPDU information sent out by the local end OAM entity or the remote end OAM entity comprises:

the control module sends an OAMPDU information sending request to the multiplexing module;

and the multiplexing module performs Ethernet packet packing and sends the Ethernet packet to the outside according to the type of the OAMPDU information in the OAMPDU information sending request.

On the basis of the technical scheme, the control module comprises a packet sending timer and a packet sending counter;

after the packet sending timer and the packet sending counter are started, the control module waits for an OAMPDU information sending request;

after the packet sending timer times out, when an OAM entity is in a processing mode of only receiving the OAMPDU or the count of the packet sending counter does not reach a preset maximum numerical value, returning to the request of waiting for the OAMPDU information sending; when the packet sending timer is up, and the OAM entity is not in a processing mode of only receiving the OAMPDU, and the count of the packet sending counter reaches a preset maximum numerical value, sending an OAMPDU information sending request;

and when the packet sending timer does not time up, and the OAMPDU packet sending request is effective and the packet sending counter is not equal to 0, sending the OAMPDU information sending request.

On the basis of the technical scheme, the multiplexing module judges an OAMPDU information sending request, and when OAMPDU information is OAM data, Ethernet packet packing is carried out and the OAMPDU information is sent to the outside; and when the OAMPDU information is OMCI data, setting the highest bit of the flag field of the OAMPDU information, and performing Ethernet group packing and sending the OAMPDU to the outside.

On the basis of the technical scheme, the receiving of the OAMPDU information by the local end OAM entity or the remote end OAM entity comprises the following steps:

the analysis module analyzes the received Ethernet frame to obtain an OAMPDU frame, a loopback frame and a common MAC frame, forwards the OAMPDU frame to the control module, forwards the loopback frame to the multiplexing module, and forwards the common MAC frame to an upper-layer MAC client.

Compared with the prior art, the invention has the following advantages:

(1) through the OAM client management module at the home terminal, OAM connection is established between the ROF line card and the remote BTU, and the management and maintenance of the ROF line card on the BTU are realized through the Ethernet OAM management process, so that the ROF equipment can be managed and maintained by using the OAM process, the workload of development, test and verification of system management software is greatly reduced, the management efficiency of network equipment is improved, and the user requirements are met.

(2) By expanding the OAMPDU frame to bear the OMCI data packet, a virtual OMCI channel is established between the ROF line card and the remote end BTU, so that the ROF equipment can use the GPON OMCI to manage and maintain, and the compatibility of the ROF equipment and the GPON equipment is improved.

(3) The conventional engineering maintenance personnel can directly open and maintain the ROF equipment without additional training, so that the work load of maintenance of the ROF equipment is reduced.

Drawings

Fig. 1 is a schematic diagram of a ROF device management system according to an embodiment of the present invention;

fig. 2 is a schematic diagram of a home OAM entity;

FIG. 3 is a OAMPDU frame structure diagram;

fig. 4 is a flowchart of a method for managing a ROF device according to an embodiment of the present invention;

fig. 5 is a flow diagram of a remote BTU creating a remote OAM client and a remote OAM entity;

fig. 6 is a flowchart of communication interaction between a home OAM entity and a remote OAM entity when an OAM connection is established;

fig. 7 is a state machine of communication interaction between a home OAM entity and a remote OAM entity;

FIG. 8 is a flow chart of a control module;

FIG. 9 is a flow diagram of a multiplexing module;

FIG. 10 is a flow diagram of a parsing module.

Reference numerals:

the system comprises a remote OAM client 11, a remote OAM entity 12, a local OAM client management module 2, a local OAM client 21 and a local OAM entity 22.

Detailed Description

The invention provides an ROF equipment management system, wherein ROF equipment comprises an ROF line card arranged in an OLT and at least one remote BTU (base station unit), and a local end OAM (operation administration and maintenance) client management module 2 is arranged in the ROF line card.

When the remote BTU is powered on and initialized, a remote OAM client 11 and a remote OAM entity 12 are created and initialized, the remote OAM client 11 is used for enabling and configuring the remote OAM entity 12, and sending and receiving OAM Protocol Data unit (OAM Protocol Data unit) information to the outside through the remote OAM entity 12 to establish and manage OAM connection.

The home terminal OAM client management module 2 is configured to create and manage a home terminal OAM client 21 and a home terminal OAM entity 22 according to OAMPDU information sent by each remote BTU, where the home terminal OAM client 21 is configured to enable and configure the home terminal OAM entity 22, and establish and manage OAM connection with the remote terminal OAM client 11 through the home terminal OAM entity 22 and the remote terminal OAM entity 12, where the home terminal OAM entity 22 and the remote terminal OAM entity 12 interact with each other through the OAMPDU information.

The home terminal OAM client management module 2 is responsible for creating, starting, managing and destroying the home terminal OAM entity. In a network topology of a Point-to-Multipoint multi-label distribution protocol (P2 MP), in an OAM discovery process, once receiving an OAM mpdu message sent by a remote BTU, the home OAM client management module 2 creates a home OAM entity 22 to communicate with the remote BTU. The local OAM client management module 2 is responsible for receiving OAMPDU information of the remote BTU and forwarding the OAM information to an OAM entity matched with the remote BTU.

Referring to fig. 1, the ROF device management system according to an embodiment of the present invention includes a plurality of remote BTUs, a remote OAM client 11 and a remote OAM entity 12 are created and initialized when the remote BTUs are initialized, the remote OAM client 11 is configured to enable and configure the remote OAM entity 12, and send and receive OAM protocol data unit OAMPDU information to the outside through the remote OAM entity 12 to create and manage an OAM connection.

Specifically, the home OAM client management module 2 communicates with the home OAM client 21, and mainly performs the following functions:

1) is responsible for creating and initializing the home OAM client 21 and the home OAM entity 22.

At the ROF end, once a new online remote BTU is found, a corresponding home OAM client 21 and a home OAM entity 22 are created to perform the remote OAM entity 12 discovery interactive communication with them, and establish a normal OAM connection. And if the normal OAM connection can not be established, destroying the created home OAM client 21 and the home OAM entity 22.

2) Management and expansion interfaces related to other external modules are completed, such as BTU registration and OMCI forwarding control.

The home OAM client 21 establishes and manages an OAM connection to implement the functions of enabling and configuring an OAM entity, which specifically includes:

1) in the OAM discovery process, the home OAM client 21 monitors the OAMPDU information received from the remote BTU, and establishes an OAM connection with the remote device according to the state and configuration control of the local and remote devices.

2) The home terminal OAM client 21 sends and receives the related link event to the opposite terminal, and adopts the retransmission mechanism to improve the reliability of reception.

3) The local OAM client 21 interacts with the local OAM entity 22 through a request and indication service interface of OAM control and OAMPDU.

Local OAM entity 22 and remote OAM entity 12 implement the ethernet OAM protocol. The local OAM entity 22 of the local ROF interacts with the remote OAM entity 12 of the remote BTU via the ethernet OAM slowness protocol (type 0x8809, subtype 0x 03). The OAM operation mode of the local end is an active mode, and the OAM operation mode of the remote end BTU is a passive mode.

The states of REMOTE OAM entity 12 and home OAM entity 22 include an error state (FAULT), an ACTIVE SEND state (ACTIVE _ SEND _ LOCAL), a WAIT to receive state (standby _ WAIT), a double-side handshake negotiation state (SEND _ LOCAL _ REMOTE), a single-side satisfactory double-side handshake negotiation state (SEND _ LOCAL _ REMOTE _ OK), and a SEND-receive arbitrary packet state (SEND _ ANY).

Each of the local OAM entity 22 and the remote OAM entity 12 includes a control module, a multiplexing module, and an analysis module, and fig. 2 is a schematic diagram of the local OAM entity 22, where the control module and the multiplexing module interact with each other through a request service interface (CTL: oami.request) inside the OAM, and the control module and the analysis module interact with each other through an indication service interface (CTL: oami.indication) inside the local OAM. Remote OAM entity 12 is substantially the same as home OAM entity 22, except that: the parsing module of the remote OAM entity 12 is configured to receive a lower MAC frame through an indication interface (MAC: MA _ data.indication) of a lower sublayer and directly forward a normal MAC frame between the lower layer and the MAC client, and the parsing module of the home OAM entity 22 is configured to receive an ethernet frame forwarded by the home OAM client 21.

The control module is used for:

1) through OAM control interface and OAMPDU request and indication service interface, respectively interact with the local end OAM client 21, receive and transmit OAMPDU information, and transmit control and status parameters.

2) Controlling link establishment with the remote OAM client 11.

3) And interacting with the multiplexing module through a request and an indication service interface inside the OAM at the end, managing OAMPDU information sent to the multiplexing module and receiving OAMPDU information from the analysis module.

The control module comprises a packet sending timer and a packet sending counter, and determines whether to send an OAMPDU information sending request or not according to the judgment condition; wherein the determination conditions include: whether the timing of the packet sending timer is up, the counting value of the packet sending counter, whether the OAM entity where the control module is located is in the processing mode of only receiving the OAMPDU, and whether the OAMPDU packet sending request is valid.

The analysis module is used for analyzing the Ethernet frame received by the MAC and the indication interface (MAC: MA _ DATA.indication) of the lower sublayer to obtain an OAMPDU frame, a Loopback frame and a common MAC frame, forwarding the OAMPDU frame to the control module through a request service interface (CTL: OAMI.indication) in the OAM, forwarding the Loopback frame to the multiplexing module through a Loopback frame interface (LBF: OAMI.request Loopback frames), and forwarding the common MAC frame to the upper MAC client through an 802.3MAC data service interface (MCF: MA _ DATA.indication).

The multiplexing module is used for receiving OAMPDU information from the control module and loopback frames from the analysis module, performing Ethernet packet packing and sending the Ethernet packet to the MAC layer through a request interface (MAC: MA _ DATA.request). And the multiplexing module adopts a message queue mode to process the packet sending request of the OAMPDU.

The local OAM client module 21 implements enabling and configuring of the local OAM entity 22, and sends OAM link event OAMPDU information to the control module of the local OAM entity 22, and sends a corresponding response OAMPDU to the control module. The local OAM client module 21 communicates with the local control module via requested and directed control messages. In the OAM discovery phase, the local OAM client module 21 monitors, through the control module, the OAM mpdu information received from the remote OAM client 11, and performs corresponding control configuration according to the local and remote states and configurations to establish an OAM connection. After the OAM connection is established, the home OAM client module 21 follows the OAM mpdu response rule, and does not respond to an illegal OAM request, such as a variable request and a loopback control request of OAM from a passive mode Data Destination Terminal Equipment (DTE). The local OAM client module 21 communicates with the remote OAM client 11 via packets of requests and indications of the OAMPDUs.

Fig. 3 shows the structure of an OAMPDU frame.

The OAMPDU information is a standard OAM data packet or an OMCI data packet. The multiplexing module is configured to set a highest bit of a flag field of the OAMPDU information to perform OMCI extension on the OAMPDU frame, and specifically, when a value of the highest bit of the flag field in fig. 3 is 1, the OAMPDU information is an OMCI data packet; and when the value of the highest bit of the mark field is 0, the OAMPDU information is an OAMPDU data packet. By carrying out OMCI expansion on the OAMPDU frame, a virtual OMCI channel is established between the ROF line card and the remote end BTU, so that the ROF equipment can use GPON OMCI for management and maintenance, and the compatibility of the ROF equipment and the GPON equipment is improved.

Through the home end OAM client management module 2, OAM connection is established between the ROF line card and the remote end BTU, and the management and maintenance of the ROF line card on the remote end BTU are realized through the Ethernet OAM management process, so that the ROF equipment can be managed and maintained by using the OAM process, the workload of development, test and verification of PON system management software is greatly reduced, the management efficiency of network equipment is improved, and the user requirements are met. The conventional engineering maintenance personnel can directly open and maintain the ROF equipment without additional training, so that the work load of maintenance of the ROF equipment is reduced.

Referring to fig. 4, an embodiment of the present invention further provides an ROF device management method based on the ROF device management system, where the ROF device management method includes the following steps:

and S1, power-on initialization of the ROF line card and the BTU.

S2, the remote end BTU creates a remote end OAM client 11 and a remote end OAM entity 12, the remote end OAM client 11 enables and configures the remote end OAM entity 12, and OAMPDU information is sent out through the remote end OAM entity 12.

And S3, after receiving the OAMPDU message, the home OAM client management module 2 creates and manages the home OAM client 21 and the home OAM entity 22, wherein the home OAM client 21 enables and configures the home OAM entity 22, and OAM connection is established and managed between the home OAM entity 22 and the remote OAM entity 12 and the remote OAM client 11.

Referring to fig. 5, the creating, by the remote BTU, the remote OAM client 11 and the remote OAM entity 12 in step S2 specifically includes:

s201, initializing global variables.

And S202, creating message queues of each module of the remote OAM client 11 and the remote OAM entity 12.

And S203, creating the remote OAM client 11.

S204, the remote OAM entity 12 is created.

S205, a control module is created.

S206, creating a multiplexing module.

And S207, creating a parsing module.

Step S3 specifically includes:

s31, after receiving the OAM mpdu message, the local OAM client management module 2 creates and manages the local OAM client 21 and the local OAM entity 22, which is basically the same as the process of creating the remote OAM client 11 and the remote OAM entity 12 by the remote BTU described above.

The step S31 of establishing the OAM connection includes: the working mode of the local OAM client is an active mode, the working mode of the remote OAM client is a passive mode, the local OAM client initiates OAM connection to the remote OAM client through a local OAM entity, and the OAM connection is established through an OAM discovery process.

See fig. 6 for an illustration: when an OAM connection is established, the communication interaction between the local OAM entity 22 and the remote OAM entity 12 is as follows:

local OAM entity 22 sends OAM mpdu information to remote OAM entity 12, which includes OAM configuration information of local OAM entity 22.

After receiving the OAMPDU message, the remote OAM entity 12 determines whether the OAM configuration message of the local OAM entity 22 matches with the OAM configuration message of the local equipment, and then replies the OAMPDU message to the local OAM entity 22; the replied information contains a BTU local TLV value and a ROF TLV value.

After receiving the OAMPDU information sent by the remote OAM entity 12, the home OAM entity 22 compares the local ROF TLV value with the BTU TLV value, receives the BTU TLV value, and then sends the OAMPDU information to the remote OAM entity 12 again.

After receiving the OAMPDU information, the remote OAM entity 12 compares the local BTU TLV value and the ROF TLV value, accepts the ROF TLV value, and then sends the OAMPDU information to the home OAM entity 22 again.

The local OAM entity 22 establishes an OAM connection with the remote BTU and sends the OAMPDU information again to the remote OAM entity 12.

Remote OAM entity 12 establishes an OAM connection with local OAM entity 22 and resends the OAMPDU information to local OAM entity 22.

Through the above configuration negotiation process, if the OAM configuration information of both parties is matched, the OAM connection is established. After the OAM connection is established, OAM mpdu information is periodically sent between the local OAM entity 22 and the remote OAM entity 12 to check whether the OAM connection is normal.

S32, managing OAM connection comprises:

and the local OAM client management module receives OAMPDU information sent by the remote BTU and forwards the OAMPDU information to other remote OAM entities matched with the remote BTU.

The local OAM client 21 sends OAM link event OAMPDU information and corresponding response OAMPDU information to the local OAM entity 22 based on the OAMPDU response rule.

The remote OAM client 11 sends OAM link event OAMPDU information and corresponding response OAMPDU information to the remote OAM entity 12 based on the OAMPDU response rule.

The states of remote OAM entity 12 and home OAM entity 22 include an error state, an active sending state, a waiting for receiving state, a two-way handshake negotiation state, a one-way satisfactory two-way handshake negotiation state, and a receiving-sending arbitrary packet state.

The error state is:

if the link is faulty, the local _ pdu parameter is set to transmit only OAMPDU with link fault (LF _ INFO). If the link connection is normal, the local _ pdu is set to RX _ INFO, the local _ stable parameter of the local _ state for the remote OAM state is set to FALSE, and the local OAM connection lost timer is closed.

The active sending state is:

at the ROF end, once the link connection is normal, the OAM client 21 sets the OAM entity 22 to ACTIVE mode (ACTIVE). The local OAM entity 22 sends the OAMPDU information only with the local information TLV (Type-Length-Value) through its control module, which is described in detail below, and waits to receive the OAMPDU information of the remote BTU.

The wait receiving state is:

in the remote BTU, the remote OAM client 11 sets the remote OAM entity 12 to a PASSIVE mode (PASSIVE) in a state of waiting to receive the OAMPDU information with local information sent by the ROF end OAM. And after receiving the OAMPDU information of the ROF, sending the OAMPDU information with the local information to the OAM of the ROF end.

The two-party handshake negotiation state is:

after receiving the OAMPDU information with local information sent by the ROF end OAM, the BTU end OAM entity 12 sends the OAMPDU information with local and remote information to the local OAM entity 22. In this state, local _ stable is FALSE.

The state of the one-side satisfactory two-side handshake negotiation is as follows:

after receiving OAMPDU information of remote OAM, the local OAM compares the local and remote configurations, and if the configuration of the opposite side is satisfied, the state is accessed. In this state, local _ stable is set TRUE. And sends corresponding information OAMPDU to the far end. If the local OAM is not satisfied with the configuration of the remote OAM, the handshake negotiation state of the two parties is returned.

The state of any packet is received and transmitted as follows:

after receiving the remote OAMPDU message, the local _ stable is also TRUE, then the local enters the state. In this state, local _ pdu is set to send and receive an arbitrary packet (ANY). An OAM link for normal operation is established between the local end and the remote end OAM. In the subsequent OAM operation process, if the local OAM is not satisfied with the configuration of the remote OAM, the two-party handshake negotiation state is returned. And if the local end OAM is satisfactory to the configuration of the remote end OAM, but the remote end OAM is not satisfactory to the configuration of the local end OAM, returning to the two-party handshake negotiation state which is satisfactorily performed by one party.

Referring to fig. 7, in establishing and managing an OAM connection, the communication interaction state machine between home OAM entity 22 and remote OAM entity 12 is as follows:

beginning: the method comprises the steps that a home terminal (ROF) and a remote end OAM are initialized, after an OAM link is established between the home terminal and the remote end OAM, OAM link interrupt timers of the home terminal and the remote end are started, and meanwhile heartbeat link is kept between the home terminal and the remote end. If the OAM link down timer expires (i.e., local _ link _ timer _ done), an OAM link down is indicated (i.e., local _ link _ status ═ FAIL).

Step A, entering an error state: if the link has errors, the local _ pdu parameter is set to transmit only OAMPDU with link errors (LF _ INFO). If the link connection is normal, the local _ pdu is set to RX _ INFO, the local _ stable parameter of the local-remote OAM state satisfaction is set to FALSE, and the local lost OAM connection timer, local _ link _ timer, is closed. The specific execution code is as follows:

IF(FAIL＝＝local_link_status)THEN

local_pdu＝LF_INFO

ELSE

local_pdu＝RX_INFO

local_stable＝FALSE

Stop lost_link_timer

the step B, ROF side is in active sending state:

at the ROF end, once the link connection is normal, the OAM client 21 sets the OAM entity 22 to ACTIVE mode (ACTIVE). The local OAM entity 22 sends the OAMPDU information only with the local information TLV through its control module packet sending request processing flow, and waits to receive the OAMPDU information of the remote BTU. The OAMPDU may be of various types, such as information OAMPDU, event notification OAMPDU, variable request OAMPDU, and so on. Other types of OAMPDUs are not referred to herein. The OAMPDU information in the application is information OAMPDU. local _ pdu ═ INFO denotes that the OAMPDU information is allowed to be transmitted.

Step B', the remote BTU is in a wait-to-receive state:

in the remote BTU, the remote OAM client 11 sets the remote OAM entity 12 to a PASSIVE mode (PASSIVE) in a state of waiting to receive the OAMPDU information with local information sent by the ROF end OAM. And after receiving the OAMPDU information of the ROF, sending the OAMPDU information with the local information to the OAM of the ROF end. RX _ INFO indicates that only the oadpdu information can be received. When the Remote OAM status is valid (Remote _ state _ valid), step C is entered.

Step C, the handshake negotiation state of the two parties is as follows:

after receiving the OAMPDU information with local information sent by the ROF OAM, the remote OAM entity 12 sends the OAMPDU information with local and remote information to the home OAM entity 22. In this state, local _ pdu is INFO and local _ stable is FALSE.

Step D, the state of the single party satisfying both parties handshake negotiation is as follows:

after receiving OAMPDU information of remote OAM, the local OAM compares the local and remote configurations, and if the configuration of the opposite side is satisfied, the state is accessed. In this state, local _ stable is set TRUE. And sends corresponding information OAMPDU to the far end. If the Local OAM is not satisfactory to the configuration of the remote OAM (Local _ notified is FALSE, the Local OAM does not match the remote OAM parameters), then the two-party handshake negotiation status returns to step C. When the Local OAM configuration of the Local OAM is satisfied with the remote OAM (Local _ specified ═ TRUE, the Local OAM is matched with the remote OAM parameters), step E is entered.

E, the state of any packet receiving and sending is as follows:

after receiving the remote OAMPDU message, the local _ stable is also TRUE, then the local enters the state. In this state, local _ pdu is set to transmit/receive an arbitrary packet (local _ pdu ═ ANY). An OAM link for normal operation is established between the local end and the remote end OAM. In the subsequent OAM operation process, if the Local OAM is not satisfactory to the configuration of the remote OAM (Local _ located ═ FALSE, the Local OAM does not match the remote OAM parameters), then it returns to the two-party handshake negotiation state in step C. If the Local OAM is satisfactory to the configuration of the Remote OAM (Local _ notified, the Local OAM matches the Remote OAM parameters), but the Remote OAM is not satisfactory to the configuration of the Local OAM (Remote _ stable is FALSE), then return to the step D, where the two-party handshake negotiation state is performed satisfactorily.

Sending out the OAMPDU information by the local OAM entity 22 or the remote OAM entity 12 includes:

the control module sends an OAMPDU information sending request to the multiplexing module, and the control module comprises a packet sending timer and a packet sending counter. The packet transmission counter is a down counter, for example, the preset value may be 10, and the packet transmission counter is decremented by 1 every time a packet is transmitted.

And after the packet sending timer and the packet sending counter are started, the control module waits for an OAMPDU information sending request.

After the packet sending timer times out, when the packet sending timer times out, and when the OAM entity is in a processing mode of only receiving the OAMPDU or the count of the packet sending counter does not reach a preset maximum numerical value, returning to the request of waiting for the OAMPDU information sending; the OAM entity is not in a processing mode of only receiving the OAMPDU, and the counting of the packet sending counter reaches a preset maximum value, and sends an OAMPDU information sending request;

and when the packet sending timer is not timed up, and the OAMPDU packet sending request is valid and the packet sending counter is not equal to 0, sending the OAMPDU information sending request.

The specific process is shown in fig. 8:

s3211, the control module starts a packet timer (interval 1 second, pdu _ timer equals 1s), and a packet counter (maximum value may be set as: pdu _ cnt equals 10).

And S3212, the control module waits for an OAMPDU information request to be sent.

S3213, judging whether the packet sending timer is up, if yes, entering step S3214; if not, the process proceeds to step S3218.

S3214, determining whether the OAM entity is in a processing mode (local _ pdu ═ RX _ INFO) for receiving only the OAM mpdu or whether the packet counter count does not reach a preset maximum value (pdu _ cnt | ═ 10), if yes, returning to step S3211; if not, the process proceeds to step S3215.

S3215, judging whether the OAM entity is not in a processing mode of only receiving the OAMPDU and whether the counting of the packet sending counter reaches a preset maximum value, if so, entering a step S3216; if not, the process proceeds to step S3212.

And S3216, sending an OAMPDU information sending request to avoid restarting the OAM discovery process.

S3217, judging whether the packet sending timer is up, if yes, entering step S3211; if not, the process proceeds to step S3212.

S3218, judging whether the OAMPDU packet sending request meets an effective packet sending request condition, if so, entering a step S3219; if not, the process proceeds to step S3212. The effective package sending request conditions are as follows:

(1) the OAMPDU processing mode is to transmit and receive OAMPDU information (local _ pdu ═ INFO) or arbitrary packet (local _ pdu ═ ANY);

(2) the OAM client sends a request packet with 1 or more critical event parameters.

(3)pdu_cnt！＝0。

S3219, determining whether the OAMPDU packet sending request is valid, that is, pdu _ req is NORMAL, if so, entering step S3220; if not, the process proceeds to step S3212.

S3220, the packet sending counter is decremented by 1, and the process advances to step S3216.

And the multiplexing module performs Ethernet packet packing and sends the Ethernet packet to the outside according to the type of the OAMPDU information in the OAMPDU information sending request. The multiplexing module judges the OAMPDU information sending request, and when the OAMPDU information is OAM data, Ethernet packet packing is carried out and the OAMPDU information is sent to the outside; and when the OAMPDU information is OMCI data, setting the highest bit of the flag field of the OAMPDU information, and performing Ethernet group packing and sending the OAMPDU to the outside. The specific process is shown in fig. 9:

s3221, the multiplexing module waits for an Ethernet frame to be sent.

S3222. a request for sending the Ethernet frame is received.

S3223, judging whether the OAMPDU information sending request is an OAM frame request, if so, entering a step S3224; if not, the process proceeds to step S3226.

S3224, Ethernet group packaging is carried out.

If the request is a standard OAM request, OAMPDU packet is packaged and sent, if the request is an OMCI sending request, OMCI information is taken as OAM information, the highest bit of a flag field is set, and OAMPDU packet sending is carried out.

S3225, sending the Ethernet frame.

S3226, judging whether the OAMPDU information sending request is an OMCI frame request, if so, entering a step S3224; if not, the process proceeds to step S3227.

S3227. other frame request processing (forward or loopback packet request).

S3228, judging that the port link is intact, and if so, entering a step S3224; if not, the process proceeds to step S3221.

Receiving the OAMPDU information by the local OAM entity 22 or the remote OAM entity 12 includes: the analysis module analyzes the received ethernet frame to obtain an oadmpdu frame, a loopback frame, and a normal MAC frame, and forwards the oadmpdu frame to the control module, and forwards the loopback frame to the multiplexing module, and the analysis module of the remote OAM entity 12 directly forwards the normal MAC frame between the lower layer and the MAC client. The specific process is shown in fig. 10:

s3231, the multiplexing module waits for sending the Ethernet frame. A request to send an ethernet frame is received.

S3232, judging whether OAMPDU information is an OAM frame, if so, entering a step S3233; if not, the process proceeds to step S3239.

And S3233, analyzing a mark field of the OAMPDU information.

S3234, judging whether the information is OAMPDU information or not, if so, entering a step S3235; if not, the process proceeds to step S3240.

And S3235, analyzing an OAMPDU coding domain.

S3236.oam indicates packet packing.

And S3237, sending an OAM indication packet to the control module.

S3238, start OAM link interrupt timer (local _ link _ timer), return to step S3231. After a normal OAM link is established between the local end and the remote end, an OAM link interruption timer is started. When any end receives the OAMPDU packet of the opposite end, the timer is reset, namely, local _ link _ timer _ done is set to FALSE. Once the timer expires, it indicates that the local end has not received the OAM mpdu packet of the opposite end, i.e. OAM link is interrupted, and at this time, local _ link _ timer _ done is set to TRUE.

And S3239, forwarding the common MAC frame.

S3240, judging whether the packet is an OMCI packet or not, and if so, entering a step S3241; if not, the process returns to step S3231.

And S3241, forwarding the OMCI packet and returning to the step S3231.

The present invention is not limited to the above-described embodiments, and it will be apparent to those skilled in the art that various modifications and improvements can be made without departing from the principle of the present invention, and such modifications and improvements are also considered to be within the scope of the present invention. Those not described in detail in this specification are within the skill of the art.

Claims

1. An ROF device management system, the ROF device including an ROF line card disposed in an OLT and at least one remote BTU, the management system comprising:

2. The ROF device management system of claim 1, wherein: the states of the remote OAM entity and the local OAM entity comprise an error state, an active sending state, a waiting receiving state, a two-party handshake negotiation state, a one-party satisfactory two-party handshake negotiation state and a receiving and sending arbitrary packet state.

3. The ROF device management system according to claim 2, wherein: the remote OAM entity and the local OAM entity comprise a control module, a multiplexing module and an analysis module, wherein the control module and the multiplexing module are interacted through a request service interface inside the OAM of the local end, the control module and the analysis module are interacted through an indication service interface inside the OAM of the local end, the analysis module of the remote OAM entity is used for receiving a lower-layer MAC frame through an indication interface of a lower-layer sublayer and directly forwarding a common MAC frame between the lower layer and an MAC client, and the analysis module of the local OAM entity is used for receiving an Ethernet frame forwarded by the local OAM client;

4. The ROF device management system according to claim 3, wherein: and the OAMPDU information is a standard OAM data packet or an OMCI data packet.

5. The ROF device management system according to claim 3, wherein: the control module comprises a packet sending timer and a packet sending counter, and the control module determines whether to send an OAMPDU information sending request according to a judgment condition;

6. The ROF device management system according to claim 3, wherein: the multiplexing module is used for setting the highest bit of the mark field of OAMPDU information, and expanding an OAMPDU frame so as to bear OMCI data packets.

7. An ROF device management method based on the ROF device management system of claim 1, characterized by comprising the steps of:

the ROF line card and the remote BTU are electrified and initialized;

8. The ROF device management method according to claim 7, wherein: the OAMPDU information is a standard OAM data packet or an OMCI data packet.

9. The ROF device management method of claim 8, wherein establishing the OAM connection includes: the working mode of the local OAM client is an active mode, the working mode of the remote OAM client is a passive mode, the local OAM client initiates OAM connection to the remote OAM client through a local OAM entity, and the OAM connection is established through an OAM discovery process.

10. The ROF device management method of claim 8, wherein managing OAM connections includes: the OAMPDU processing method includes that a local end OAM client management module receives OAMPDU information sent by a remote end BTU and forwards the OAMPDU information to other remote end OAM entities matched with the remote end BTU;

11. The ROF device management method according to claim 10, wherein: the remote OAM entity and the local OAM entity both comprise a control module, a multiplexing module and an analysis module, wherein the analysis module of the remote OAM entity is used for receiving a lower-layer MAC frame through an indication interface of a lower-layer sublayer and directly forwarding a common MAC frame between a lower layer and an MAC client, and the analysis module of the local OAM entity is used for receiving an Ethernet frame forwarded by the local OAM client;

12. The ROF device management method according to claim 11, wherein: the control module comprises a packet sending timer and a packet sending counter;

13. The ROF device management method according to claim 11, wherein: the multiplexing module judges the OAMPDU information sending request, and when the OAMPDU information is OAM data, Ethernet packet packing is carried out and the OAMPDU information is sent to the outside; and when the OAMPDU information is OMCI data, setting the highest bit of the flag field of the OAMPDU information, and performing Ethernet group packing and sending the OAMPDU to the outside.

14. The ROF device management method according to claim 11, wherein: the receiving of OAMPDU information by the local end OAM entity or the remote end OAM entity comprises: