WO2012106938A1 - 一种基于北向接口的业务实现方法及装置 - Google Patents

一种基于北向接口的业务实现方法及装置 Download PDF

Info

Publication number
WO2012106938A1
WO2012106938A1 PCT/CN2011/077679 CN2011077679W WO2012106938A1 WO 2012106938 A1 WO2012106938 A1 WO 2012106938A1 CN 2011077679 W CN2011077679 W CN 2011077679W WO 2012106938 A1 WO2012106938 A1 WO 2012106938A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
event
command
odu0
optical data
Prior art date
Application number
PCT/CN2011/077679
Other languages
English (en)
French (fr)
Inventor
武志杰
王真
王勋
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to PCT/CN2011/077679 priority Critical patent/WO2012106938A1/zh
Priority to CN201180001311.4A priority patent/CN102439904B/zh
Publication of WO2012106938A1 publication Critical patent/WO2012106938A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks

Definitions

  • the present invention relates to the field of optical communications, and in particular, to a service implementation method and apparatus based on a northbound interface.
  • optical transport network Optical Transport Network
  • ODU Optical Channel Data Unit
  • the service of G is called the optical data unit ODU1 service
  • the service with the rate of 10G is called the optical data unit ODU2 service
  • the service with the rate of 40G is called the optical data unit ODU3 service
  • the optical data unit ODU1 can only carry one 1.25G service.
  • it carries some other small-rate services, and the network bandwidth utilization is not high.
  • an optical data unit ODU0 (1.25G) rate-level service is generated.
  • One optical data unit ODU1 can accommodate two optical data units ODU0, and the optical data unit ODU1 can simultaneously carry two 1.25. G, improve the bandwidth utilization of the network.
  • industry standard recommendations such as ITU-T, International Telecommunication Union-Telecommunication Standardization Sector, Telecommunication Management Forum (TMF)
  • Telecommunication Management Forum Telecommunication Management Forum
  • OSS Operation Support System
  • EMS element management system
  • NMS network level management system
  • Network Management System Network Management System
  • the embodiment of the invention provides a service implementation method and device based on the northbound interface, which is used to manage the optical data unit ODU0 rate service in the network management system through the northbound interface.
  • the method for implementing a service based on a northbound interface includes: receiving a service event through a northbound interface, and extracting an object model parameter in the service event; according to a preset optical data unit ODU0 service light model level identifier and Extracting object model parameters, determining that the object model is No, it is the optical data unit ODU0 service; if yes, the object model parameters are converted into parameters recognized by the network management system; and the business events including the converted object model parameters are processed.
  • the device for implementing the service based on the northbound interface includes: a receiving unit, configured to receive a service event by using a northbound interface; an extracting unit, configured to extract an object model parameter in the received service event; and a determining unit, configured to: Determining, according to the preset optical data unit ODU0 service light model level identifier and the extracted object model parameter, whether the object model is an optical data unit ODU0 service; and converting unit, if used for an optical data unit ODU0 service, The object model parameter is converted into a parameter recognized by the network management system; and the processing unit is configured to process a business event including the converted object model parameter.
  • the embodiment of the present invention has the following advantages: receiving a service event through a northbound interface, extracting an object model parameter in the received service event, and determining whether the object model is an optical data unit ODU0 service, and if so, Then, the object model parameters are converted, and the business event including the converted object model parameters is processed, so that the processing of the optical data unit ODU0 service can be implemented through the northbound interface.
  • FIG. 1 is a schematic diagram of an embodiment of a method for implementing a service based on a northbound interface according to an embodiment of the present disclosure
  • FIG. 2 is a schematic diagram of another embodiment of a method for implementing a service based on a northbound interface according to an embodiment of the present invention
  • FIG. 3 is a schematic structural diagram of an optical data unit ODU0 service modeling structure according to an embodiment of the present invention
  • FIG. 4 is a schematic diagram of an apparatus for implementing a service based on a northbound interface according to an embodiment of the present invention
  • FIG. 5 is a schematic diagram of another embodiment of an apparatus for implementing a service based on a northbound interface according to an embodiment of the present invention.
  • the embodiment of the invention provides a service implementation method and device based on the northbound interface, which is used to implement the processing of the optical data unit ODU0 service through the northbound interface, and further improve the management of the OTN network by the network management system.
  • the northbound interface is used to provide access and management interfaces to other vendors or operators. Request packets from the upper-layer NMS.
  • the general network management provides a northbound interface based on the following protocols: Extensible Markup Language (XML), Common Object Request Broker Architecture (CORBA), Simple Network Management Protocol (SNMP). , Syslog Protocol.
  • the northbound interface supports the upper-layer network management system to manage the ODU0 service through the corresponding protocol.
  • the northbound interface in the embodiment of the present invention uses the CORBA protocol interface as an example, but is not limited to this interface, and may be other northbound interfaces.
  • the management system is not limited to an Element Management System (EMS) and a Network Management System (NMS).
  • EMS Element Management System
  • NMS Network Management System
  • the implementation of the present invention can be implemented as long as the management system has similar functions based on the northbound interface. The technical solution in the example.
  • an embodiment of a method for implementing a service based on a northbound interface includes:
  • the CORBA architecture it is divided into a client and a server. From the perspective of providing services from the EMS to the NMS, the CORBA client is on the NMS side and the server is on the EMS side, so the upper system is sent through the CORBA client (the NMS side).
  • the business event then the CORBA server (the EMS side) receives the business event and extracts the object model parameters in the business event.
  • the object model parameters are the parameters of the various business rate models.
  • the EMS After extracting the object model parameters in the service event, the EMS determines whether the object model is an ODU0 U.25G service according to the preset ODU0 service model layer identifier and the extracted object model parameters.
  • the EMS converts the parameters of the service into service parameters recognized by the network management system, so that the system can process the ODU0 service.
  • the business events containing the transformed object model parameters are Line processing.
  • the service event is received through the northbound interface, the object model parameter in the received service event is extracted, and the object model is determined to be an ODU0 service. If yes, the object model parameter is converted and converted into a network management system identifier.
  • the ODU0 service can be managed through the northbound interface.
  • the ODU model hierarchy of the ODU0 is first constructed.
  • the identifier, the model hierarchy identifier includes an ODU0 business model layer identifier (ID), a layer identifier string (Layer Identifier), and an object name string (Object Naming String).
  • the ODU0 service model layer identifier is set to 8031, that is, the ID is 8031, the layer identification string is LR_OCH_Data_Unit-0, and the object name string is ODU0, then the constructed ODU0 model hierarchy identifier is constructed.
  • the symbols are as shown in Table 1:
  • the ODU0 is modeled for the port having the optical data unit ODU0 service and the optical data unit ODUk service processing capability, where k is an integer ranging from 1 to 3.
  • this embodiment performs ODU0 modeling on a port having an ODU0 service and an ODU1 service processing capability. It can be understood that the ODU0 modeling principle is the same for the port that has the ODU0 service and the optical data unit ODU2 service (ODU3 service) processing capability, and is not described here.
  • the port with the ODU1 service and the ODU0 service processing capability is selected, and the multiple ODU0 services are multiplexed into one ODU1 service.
  • the specific multiplexing process is the existing technology, and the multiplexed ODU1 is not described here.
  • the service is encapsulated by an optical transport unit (OUT, Optical Transport Unit) 1, and finally enters the optical layer for transmission.
  • OUT Optical Transport Unit
  • the data message of the ODU1 service is added with header information (OH, Over Head), and then mapped and multiplexed by similar adding overhead, and finally enters the optical layer for transmission, encapsulation, and
  • the transmission process is prior art and will not be described here.
  • FIG. 3 describes a port hierarchy and upper and lower association relationships.
  • the three square boxes respectively represent three levels of ports, which are physical layer 301, and the physical layer is logical layer 302.
  • the top layer is the CTP (Connection Termination Point) logic layer 303.
  • the direction of the arrow indicates that each level is an inclusion relationship. From bottom to top, the source level of the arrow contains the sink level, and the inverted triangle in each layer Represents the level of subdivision. Characters beginning with "LR-" are used to describe the subdivision level.
  • LR- is used to describe the subdivision level.
  • the level 3011 is represented by the character LR_PHYSICAL_ OPTICAL
  • the level 3012 is represented by the character LR_ OPTICAL_SECTION
  • the level 3021 is represented by the character LR_Optical-Channel
  • the level 3022 is represented by the character LR_DIGITAL_ SIGNAL-RATE
  • the level 3023 is represented by the character LR-OCH_Transport_Unit-1
  • the level 3024 is represented by the character LR-OCH_Data_Unit-1
  • the multiple levels in the CTP logic layer 303 are represented by the character LR-OCH_Data_Unit-0.
  • the dotted line drawn in the CTP logic layer 303 indicates that multiple levels can be included.
  • the character is removed.
  • the embodiment of the present invention implements ODU0 service modeling by adding a character LR-OCH-Data-Unit-0 and multiplexing a plurality of ODU0 into one ODU1.
  • the CORBA client is on the NMS side
  • the server is on the EMS side
  • the upper system sends service events through the CORBA client (NMS side)
  • the CORBA server EMS side
  • Receiving a business event extracting object model parameters in the business event.
  • the object model parameters are the parameters of the service rate models at each level.
  • the service events may be classified into a service release command, a service guarantee command, a service guarantee event, and a resource change event.
  • the service issuing command includes: a service creation command, a service activation command, a service deactivation command, and a service deletion command;
  • the service assurance commands include: a service alarm query command, a service performance query command, a stock query command, and a service query command;
  • the service security event includes: a service alarm reporting event and a service performance reporting event;
  • the resource change events include: a service creation event, a service deletion event, a service route change event, and a service attribute change event.
  • the service parameters in the embodiment of the present invention include: a service object, a service type, and a storage object.
  • the EMS After extracting the object model parameters in the service event, the EMS determines whether the object model is an ODU0 U.25G service according to the preset ODU0 service model layer identifier and the extracted object model parameters.
  • the EMS converts the parameters of the service into service parameters recognized by the network management system, so that the system can process the ODU0 service.
  • the network management system can be divided into a network management background and an upper layer system.
  • the upper layer system sends the service command through the northbound interface, which mainly includes the service issuing command and the service guarantee command, where the service issuing command includes a service creation command, a service activation command, a service deactivation command, and a service deletion command;
  • the service alarm query command, the service performance query command, the inventory query command, and the service query command are included;
  • the network management background reports the service events through the northbound interface, including the service security event and the resource change event.
  • the service security event includes the service alarm reporting event and the service performance reporting event.
  • the resource change event includes: a service creation event, a service deletion event, and Service routing change events and business attribute change events.
  • the method for processing services based on the northbound interface can be specifically classified into the following modes according to the following different service issuance commands:
  • the object model parameters are extracted, for example, one or more of the service model layer identifier, the layer identifier string, and the object name string, as described above.
  • the actual application process is determined and is not limited herein. Determining whether the service is an ODU0 (1.25G) service according to the preset ODU0 service optical model hierarchy identifier and the extracted object model parameter, and if so, converting the parameters related to the 1.25G service, including the object model parameters, into The 1.25G service command is sent to the network management system to identify the inventory objects and service type parameters.
  • the upper-layer NMS can be used to create 1.25G services in the NMS through the northbound interface.
  • the object model parameter is extracted, for example, one or more of the service model layer identifier, the layer identifier string, and the object name string, as described above.
  • the actual application process is determined and is not limited herein. Determining whether the service is an ODU0 (1.25G) service according to the preset ODU0 service optical model hierarchy identifier and the extracted object model parameter, and if so, converting the parameters related to the 1.25G service, including the object model parameters, into The service object and service type parameters that the NMS can identify are used to send 1.25G service commands to the network management system.
  • the upper-layer NMS can support the 1.25G service in the NMS through the northbound interface.
  • the object model parameters therein for example, It may be one or more of the service model layer identifier, the layer identifier string, and the object name string, which are determined according to the actual application process, and are not limited herein. Determining whether the service is an ODU0 (1.25G) service according to the preset ODU0 service optical model hierarchy identifier and the extracted object model parameter, and if so, converting the parameters related to the 1.25G service, including the object model parameters, into a network management
  • the 1.25G service deactivation command is sent to the network management system in the background of the service object and the service type parameter.
  • the upper-layer NMS can be enabled to activate the 1.25G service in the NMS through the northbound interface.
  • extracting the object model parameters therein may be one or more of the service model layer identifier, the layer identification string, and the object name string, as described above.
  • the actual application process is determined and is not limited herein. Determining whether the service is an ODU0 (1.25G) service according to the preset ODU0 service optical model hierarchy identifier and the extracted object model parameter, and if so, converting the parameters related to the 1.25G service, including the object model parameters, into a network management
  • the 1.25G service command is deleted and sent to the network management system in the background of the service object and the service type.
  • the upper-layer NMS can be configured to delete 1.25G services in the NMS through the northbound interface.
  • the method based on the northbound interface processing service can be specifically classified into the following modes according to the following different service guarantee commands:
  • the service alarm query command is implemented by receiving the service alarm query command from the northbound interface, and extracting the object model parameters, for example, the service model layer identifier, the layer identifier string, and the object name string. One or more of them are determined according to the actual application process, and are not limited herein. Determining whether the service is an ODU0 (1.25G) service according to the preset ODU0 service optical model hierarchy identifier and the extracted object model parameter, and if so, converting the parameters related to the 1.25G service, including the object model parameters, into The 1.25G service alarm query command is sent to the network management system, and the parameters in the service alarm query result are converted into standard northbound interface protocol parameters according to the foregoing ODU0 service modeling result. The converted parameters are encapsulated into the northbound interface protocol data packet, and the data packet is sent to the upper layer system to return the service alarm query result.
  • the object model parameters for example, the service model layer identifier, the layer identifier string, and the object name string.
  • the service performance query command is implemented by receiving a service performance query command through the northbound interface.
  • the object model parameters are extracted, for example, one or more of the service model layer identifier, the layer identifier string, and the object name string, which are determined according to the actual application process, and are not used here. limited. Determining whether the service is an ODU0 (1.25G) service according to the preset ODU0 service optical model hierarchy identifier and the extracted object model parameter, and if so, converting the parameters related to the 1.25G service, including the object model parameters, into
  • the 1.25G service performance query command is sent to the network management system in the network management system, and the parameters in the service performance query result are converted into standard northbound interface protocol parameters according to the foregoing ODU0 service modeling result.
  • the converted parameters are encapsulated into the northbound interface protocol data packet, and the data packet is sent to the upper layer system to return the service performance query result.
  • the upper-layer NMS can support 1.25G service-related performance management through the northbound interface
  • extracting the object model parameters therein may be one or more of the service model layer identifier, the layer identifier string, and the object name string, as described above.
  • the actual application process is determined and is not limited herein. Determining whether the service is an ODU0 (1.25G) service according to the preset ODU0 service optical model hierarchy identifier and the extracted object model parameter, and if so, converting the parameters related to the 1.25G service, including the object model parameters, into The service object and service type parameters that can be identified by the network management system are sent to the network management system to deliver 1.25G inventory.
  • the parameters of the inventory query result are converted into standard northbound interface protocol parameters, and the converted parameters are encapsulated.
  • the northbound interface protocol data packet is sent, and the data packet is sent to the upper layer system to return the inventory query result. It can support the upper-layer NMS to implement 1.25G service-related inventory management through the northbound interface.
  • the object model parameters are extracted, for example, one or more of the service model layer identifier, the layer identifier string, and the object name string, as described above.
  • the actual application process is determined and is not limited herein.
  • the northbound interface converts the parameters related to the 1.25G service, including the object model parameters, into service objects and service type parameters that can be identified by the network management background, and the northbound interface.
  • the service query command is sent to the network management system, and the parameters in the service query result are converted into standard northbound interface protocol parameters according to the foregoing ODU0 service modeling result, and the converted parameter is encapsulated.
  • the northbound interface protocol data packet is sent, and the data packet is sent to the upper layer system to return the service query result.
  • the upper-layer NMS can query the 1.25G service through the northbound interface.
  • the method based on the northbound interface processing service can be specifically classified into the following modes according to the following different service guarantee events:
  • the device reports the alarm event to the network management system, and receives the service alarm event reported by the network management system through the northbound interface.
  • the 1.25G alarm service is reported according to the ODU0 service modeling result.
  • the related parameters are converted into standard northbound interface protocol parameters, and the converted parameters are encapsulated into northbound interface protocol data packets and reported to the upper layer system.
  • the parameter conversion process and the packaging process can be completed by the prior art, and will not be described here.
  • the device reports the service performance information to the network management system, and receives the service performance report information sent by the network management system through the northbound interface, and reports the service performance result according to the foregoing ODU0 service modeling result.
  • the 1.25G service-related parameters are converted into standard northbound interface protocol parameters, and the converted parameters are encapsulated into northbound interface protocol data packets and reported to the upper layer system.
  • the method for processing the service based on the northbound interface may be specifically classified into the following manners according to the following different resource change events:
  • the device reports the service creation information to the network management background, and receives the service creation report information sent by the network management system through the northbound interface, and reports the result according to the foregoing ODU0 service modeling result.
  • the 1.25G service-related parameters are converted into standard northbound interface protocol parameters, and the converted parameters are encapsulated into northbound interface protocol data packets and reported to the upper layer system.
  • the device reports the service deletion information to the network management system, and receives the service deletion report information sent by the network management system through the northbound interface. According to the foregoing ODU0 service modeling result, the device reports the 1.25G.
  • the service-related parameters are converted into standard northbound interface protocol parameters, and the converted parameters are encapsulated into northbound interface protocol data packets and reported to the upper layer system.
  • the device reports the service route change information to the network management background, and receives the service route change report information sent by the network management system through the northbound interface, according to the foregoing ODU0 service modeling result.
  • the 1.25G service-related parameters in the report are converted into standard northbound interface protocol parameters, and the converted parameters are encapsulated into northbound interface protocol data packets, and the service routing change event is reported to the upper layer system.
  • the device reports the service route change information to the network management background, and receives the service sent by the network management system through the northbound interface.
  • the attribute change report information according to the foregoing ODU0 service modeling result, the 1.25G service-related parameter in the report is converted into a standard northbound interface protocol parameter, and the converted parameter is encapsulated into a northbound interface protocol data packet, and the service is reported to the upper layer system.
  • Property change event If the 1.25G service attribute changes are generated on the device of the system, for example, the service priority and the service rate change are changed, the device reports the service route change information to the network management background, and receives the service sent by the network management system through the northbound interface.
  • the attribute change report information according to the foregoing ODU0 service modeling result, the 1.25G service-related parameter in the report is converted into a standard northbound interface protocol parameter, and the converted parameter is encapsulated into a northbound interface protocol data packet, and the service is reported to the upper layer system. Property change event.
  • the network management system can implement the management of the 1.25G service, including but not limited to the foregoing services.
  • the network management system can implement the management of the 1.25G service, including but not limited to the foregoing services.
  • the network management system can implement the management of the 1.25G service, including but not limited to the foregoing services.
  • the implementation process of other similar services refer to the related descriptions, and details are not described herein.
  • the network management system can also provide the northbound interface related information to the higher layer network management system while managing the 1.25G service, so that the higher layer network management system can also manage the OTN 1.25G through these northbound interfaces. business.
  • the NMS sends the service command to the EMS through the CORBA interface, and waits for the EMS to return the completion signal.
  • the EMS of the NMS peer completes the corresponding service management operation, and then returns the completion status and related data to the other through the CORBA interface.
  • the 1.25G service is generated in the system, it can be reported to the upper-layer NMS actively and timely through the CORBA interface. In this way, the NMS can monitor the service in real time.
  • the escalation process is accomplished using the CORBA "Notification Service", a relatively mature CORBA standard service in the prior art.
  • the EMS may package the message and then pass the CORBA technology.
  • “notification service” push the message into The service is notified, and the notification service passes this message to the subscriber, such as the NMS, based on the subscriber's status of the message.
  • EMS is the active provider of the message
  • NMS is the passive receiver.
  • the "notification service” also supports the opposite situation, that is, the notification service actively waits for an EMS message, and the NMS actively obtains a message from the notification service.
  • the former message delivery mode is PUSH mode
  • the latter message delivery mode is PULL mode.
  • the embodiment of the present invention can be applied not only to the interface between the EMS and the NMS, but also to the interface between the EMS and the OSS, or the interface between the NMS and the Operation Support System (OSS). And an interface between application management systems for all OTN service management with similar functions. Moreover, it can be applied not only to the CORBA protocol interface, but also to interfaces of other protocol types such as XML, SNMP, ASCII (American Standard Code for Information Interchange).
  • the ODU0 service modeling is performed, and the management system (for example, the EMS and the NMS) services are connected to each other, and the ODU0 (1.25G) service is managed through the northbound interface.
  • the service event received through the northbound interface is a service Create, service activation, service deactivation, service deletion, service alarm query, service performance query, inventory query and service query command, extract the object model parameters.
  • the service is ODU0 (1.25G) service
  • the network management system is backed up.
  • the service event is a service alarm query command, a service performance query command, a stock query command, or a service query command
  • the parameters in the service result are converted into a command to execute the 1.25G service in the background of the network management system.
  • the standard northbound interface protocol parameter encapsulates the converted parameters into the northbound interface protocol data packet, and sends the data packet to the upper layer system to return the service query result.
  • the ODU0 service modeling and conversion service parameters are implemented by the upper layer system through the northbound interface.
  • Business management when the business is received The service alarm report event, the service performance report event, the service creation event, the service deletion event, the service route change event, and the service attribute change event, receive the service event reported by the network management system in the northbound interface, and extract the object model parameter in the service event.
  • the ODU0 service is modeled and converted by the ODU0 service to implement management of the ODU0 service based on the northbound interface.
  • An embodiment of the service implementation device based on the northbound interface in the embodiment of the present invention includes: a receiving unit 401, configured to receive a service event by using a northbound interface;
  • An extracting unit 402 configured to extract an object model parameter in the received service event
  • the determining unit 403 is configured to determine, according to the preset ODU0 service light model level identifier and the extracted object model parameter, whether the object model is an ODU0 service;
  • the converting unit 404 is configured to convert the object model ⁇ : into a service parameter identified by the network management system if the ODU0 service is used;
  • the processing unit 405 is configured to process a service event that includes the converted object model parameters.
  • the receiving unit 401 receives the service event through the northbound interface, and the extracting unit 402 extracts the object model parameter in the received service event, and the determining unit 403 is configured according to the preset.
  • the ODU0 service light model hierarchy identifier and the extracted object model parameters determine whether the object model is
  • the ODU0 service if it is an ODU0 service, the conversion unit 404 converts the object model parameters into service parameters recognized by the network management system, and the processing unit 405 processes the business events including the converted object model parameters. Therefore, the processing of the ODU0 service can be implemented through the northbound interface.
  • FIG. 5 another embodiment of the service implementation apparatus based on the northbound interface in the embodiment of the present invention includes:
  • the receiving unit 501 is configured to receive a service event by using a northbound interface
  • An extracting unit 502, configured to extract an object model parameter in the received service event
  • the determining unit 503 is configured to determine, according to the preset ODU0 service light model level identifier and the extracted object model parameter, whether the object model is an ODU0 service;
  • the converting unit 504 is configured to convert the object model ⁇ : into a service parameter identified by the network management system if the service is an ODU0 service, where the service event is a service creation command, a service activation command, a service deactivation command, and a service deletion command.
  • the unit 504 is further configured to convert the object model parameters into the service parameters identified by the network management system.
  • the service events are the service alarm query command, the service performance query command, the inventory query command, and the service query command
  • the converting unit 504 is further configured to use the ODU0 service.
  • the result of the modeling is to convert the ODU0 service parameter in the service alarm query result, the service performance query result, the inventory query result or the service query result into a standard northbound interface protocol parameter; when the business event is a service guarantee event and a resource change event, the conversion unit 504 is also used to convert object model parameters to standard north Interface protocol parameters;
  • the processing unit 505 is configured to process a service event that includes the converted object model parameters.
  • the processing unit 505 may further include a sending unit 5051, configured to send, to the network management system, a command to execute the ODU0 service, when the service is
  • the sending unit 5051 is further configured to send the query result to the upper layer system;
  • the processing unit 505 may further include: a packaging unit 5052, configured to convert the converted parameter Encapsulating the northbound interface protocol data packet; the service implementation device based on the northbound interface in the embodiment of the present invention may further include:
  • the construction unit 506 is configured to construct an ODU0 service optical channel data unit, and the ODU0 model hierarchy identifier is paid;
  • the modeling unit 507 is configured to perform a port with ODU0 and ODUk service processing capabilities.
  • the reporting unit 508 is configured to report a service event to the upper layer system.
  • modeling unit 507 can further include:
  • the selecting unit 5071 is configured to select a port having ODU0 and ODUk service processing capability, where k is an integer ranging from 1 to 3;
  • the multiplexing unit 5072 is configured to multiplex the multiple ODU0 services of the port into one ODUk service
  • the encapsulating service unit 5073 is configured to encapsulate the multiplexed ODUk service through the optical channel transmission unit OUTk.
  • the device in the embodiment of the present invention has different functions and can include different combinations among the above units, and the above units should not be used as essential technical features of the device embodiment.
  • each unit of the service implementation device based on the northbound interface in the implementation of the present invention is the same as the corresponding steps of the service implementation method based on the northbound interface in the foregoing embodiments, and details are not described herein again.
  • the ODU0 service optical channel data unit is created in advance by the construction unit 506.
  • An ODU0 model hierarchy identifier includes an ODU0 business model layer identifier (ID), a layer identifier string (Layer Identifier), and an object name string (Object Naming String), and the modeling unit 507 pair has an ODU0 and an ODUk.
  • the port of the service processing capability performs the ODU0 service modeling, where the value of k is an integer ranging from 1 to 3.
  • the modeling unit 507 includes a selecting unit 5071, a multiplexing unit 5072, and a packaging unit 5073. Specifically, the selecting unit is selected by the selecting unit 5071.
  • a port having an ODU0 and ODUk service processing capability where k is an integer ranging from 1 to 3, and the multiplexing unit 5072 multiplexes the plurality of ODU0 services of the port into one ODUk service, and the encapsulating service unit 5073 is multiplexed.
  • the ODUk service is encapsulated by the optical channel transmission unit OUTk to enter the optical layer for transmission.
  • the model and standard of the ODU0 service supported by the ODU0 service are added to the system.
  • the extracting unit 502 extracts the object model parameter in the received service event, and the determining unit 503 determines whether the object model is 1.25 supported by the ODU0 according to the preset ODU0 service light model hierarchical identifier. G service, if yes, the conversion unit 504 converts the object model parameters into service parameters identified by the network management system.
  • the converting unit 504 is further configured to convert the object model parameter into a service parameter identified by the network management background; when the service event is a service alarm
  • the query unit 504 is further configured to: in the service alarm query result, the service performance query result, the inventory query result, or the service query result, according to the ODU0 service modeling result, the query command, the service performance query command, the inventory query command, and the service query command
  • the ODU0 service parameter is converted into a standard northbound interface protocol parameter.
  • the converting unit 504 is further configured to convert the object model parameter into a standard northbound interface protocol parameter.
  • the processing unit 505 processes the business events including the transformed object model parameters.
  • the sending unit 5051 may further include a package when the service event is a service alarm query command, a service performance query command, a stock query command, a service query command, a service assurance event, and a resource change event.
  • the unit 5052 is configured to encapsulate the converted parameter into the northbound interface protocol data packet, and then report the service event to the upper layer system by the reporting unit 508, so that the network management system can manage the ODU0 service.
  • a person skilled in the art may understand that all or part of the steps of implementing the above embodiments may be completed by a program to instruct related hardware, and the program may be stored in a computer readable storage medium, the above mentioned storage medium. It can be a read-only memory, a disk or a disc, and the like.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明实施例公开了一种基于北向接口的业务实现方法及装置，用于现在网管系统通过北向接口对光数据单元ODU0速率业务进行管理。本发明实施例方法包括：通过北向接口接收业务事件，提取该业务事件中的对象模型参数，根据预置的光数据单元ODU0业务光模型层次标识符及所提取的对象模型参5数，判断对象模型是否为光数据单元ODU0业务，若是，则将对象模型参数转换为网管系统识别的参数，处理包含转换后的对象模型参数的业务事件。

Description

一种基于北向接口的业务实现方法及装置 技术领域
本发明涉及光通信领域，尤其涉及一种基于北向接口的业务实现方法及装 置。
背景技术
经过不断的发展完善， 光传送网 （OTN, Optical Transport Network )标准 体系已成熟， 形成速率分别为 2.5G、 10G、 40G的光数据单元（ODU , Optical channel Data Unit )业务， 其中， 速率为 2.5G的业务称为光数据单元 ODU1 业务， 速率为 10G的业务称为光数据单元 ODU2业务， 速率为 40G的业务称 为光数据单元 ODU3业务， 由于光数据单元 ODU1只能承载一个 1.25G的业 务， 同时再承载一些其它小速率业务， 网络带宽利用率不高。
后来， 在以上三个速率级别业务的基础上产生光数据单元 ODU0(1.25G) 速率级别业务，一个光数据单元 ODU1可以容纳两个光数据单元 ODU0,光数 据单元 ODU1就可以同时承载两个 1.25G, 提高了网络的带宽利用率。 但业界 标准建议（如国际电联的电信标准组织（ ITU-T, International Telecommunication Union- Telecommunication Standardization Sector )、 电信管理论坛 ( TMF , Telecommunication Management Forum ) )还没有对 1.25G速率级另' J的业务管理 与建模， 特别是在北向接口（Northbound Interface )功能领域均没有解决方案。 运营支撑系统（OSS, Operation Support System ) 不能通过北向接口对光数据 单元 ODU0业务进行管理， 同时各级管理系统之间 （如网元管理系统（ EMS, Element Management System ), 网络级管理系统 ( NMS, Network Management System ) ) 的业务也难以形成对接。
发明内容
本发明实施例提供了一种基于北向接口的业务实现方法及装置，用以实现 在网管系统通过北向接口对光数据单元 ODU0速率业务进行管理。
本发明实施例提供的基于北向接口的业务实现方法， 包括： 通过北向接口 接收业务事件，提取所述业务事件中的对象模型参数；根据预置的光数据单元 ODU0业务光模型层次标识符及所提取的对象模型参数，判断所述对象模型是 否为光数据单元 ODU0 业务； 若是， 则将所述对象模型参数转换为网管系统 识别的参数； 处理包含转换后的对象模型参数的业务事件。
本发明实施例提供的基于北向接口的业务实现装置， 包括： 接收单元， 用 于通过北向接口接收业务事件； 提取单元， 用于提取所接收的业务事件中的对 象模型参数； 判断单元， 用于根据预置的光数据单元 ODU0 业务光模型层次 标识符及所提取的对象模型参数，判断所述对象模型是否为光数据单元 ODU0 业务； 转换单元， 用于若是光数据单元 ODU0 业务， 则将所述对象模型参数 转换为网管系统识别的参数； 处理单元， 用于处理包含转换后的对象模型参数 的业务事件。
从以上技术方案可以看出， 本发明实施例具有以下优点： 通过北向接口接 收业务事件，提取所接收的业务事件中的对象模型参数， 并判断该对象模型是 否为光数据单元 ODU0 业务， 若是， 则将对象模型参数进行转换， 并处理包 含转换后的对象模型参数的业务事件，因此可通过北向接口实现对光数据单元 ODU0业务的处理。
附图说明
图 1 为本发明实施例中一种基于北向接口的业务实现方法的一个实施例 示意图；
图 2 为本发明实施例中一种基于北向接口的业务实现方法的另一个实施 例示意图；
图 3为本发明实施例中光数据单元 ODU0业务建模结构示意图； 图 4 为本发明实施例中一种基于北向接口的业务实现的装置一个实施例 示意图；
图 5 为本发明实施例中一种基于北向接口的业务实现的装置另一个实施 例示意图。
具体实施方式
本发明实施例提供了一种基于北向接口的业务实现方法及装置，用于通过 北向接口实现对光数据单元 ODU0业务的处理， 进一步提高网管系统对 OTN 网络的管理。
北向接口用于提供给其他厂家或运营商进行接入和管理的接口， 负责处 理来自上层网管的请求报文。一般网管提供基于下列协议的北向接口： 可扩展 标记语言 （XML, Extensible Markup Language ), 公共对象请求代理体系结构 ( CORBA, Common Object Request Broker Architecture )、 简单网络管理协议 ( SNMP, Simple Network Management Protocol ), 日志月良务器协议（ Syslog Protocol )。这些北向接口支持上级网管系统通过对应的协议对 ODU0业务进行 管理， 本发明实施例中的北向接口以 CORBA 协议接口为例，但不限于此接 口， 可以是其他北向接口。 同样地， 管理系统也不限于网元管理系统（EMS, Element Management System )和网络级管理系统 ( NMS , Network Management System ) , 只要是基于北向接口的具有相似功能的管理系统都可实现本发明实 施例中的技术方案。
请参阅图 1 , 本发明实施例提供的基于北向接口的业务实现方法的一个实 施例包括：
101、 通过北向接口接收业务事件， 提取其中的对象模型参数；
在 CORBA架构内部， 分为客户端和服务端， 从 EMS向 NMS提供服务 的角度看， CORBA的客户端在 NMS侧， 服务端在 EMS侧， 所以上层系统 是通过 CORBA客户端（ NMS侧 )发送业务事件， 然后 CORBA服务端（ EMS 侧）接收业务事件， 提取该业务事件中的对象模型参数。 对象模型参数即为各 级业务速率模型的参数。
102、 根据预置的光数据单元 ODU0业务光模型层次标识符及所提取的对 象模型参数， 判断该对象模型是否为 ODU0业务；
EMS提取业务事件中的对象模型参数后， 根据预置的 ODU0业务模型层 次标识符及所提取的对象模型参数， 判断该对象模型是否为 ODU0 U.25G ) 业务。
103、 若是， 则将对象模型参数转换为网管系统可识别的参数；
如果对象模型为 ODU0 ( 1.25G )业务，则 EMS将该业务的参数进行转换， 转换为网管系统识别的业务参数， 使得系统可以处理 ODU0业务。
若不是， 则 EMS将忽略该业务命令。
104、 处理包含转换后的对象模型参数的业务事件。
将对象模型参数进行转换后，将包含转换后的对象模型参数的业务事件进 行处理。
本发明实施例中，通过北向接口接收业务事件，提取所接收的业务事件中 的对象模型参数， 并判断该对象模型是否为 ODU0 业务， 若是， 则将对象模 型参数进行转换， 转换为网管系统识别的业务参数， 并处理包含转换后的对象 模型参数的业务事件， 由于先判断业务事件中的业务是否为 ODU0业务， 若 是则将其中的对象模型参数转换为网管系统识别的业务参数，因此网管系统可 通过北向接口对该 ODU0业务进行管理。
为便于理解，下面以另一实施例对本发明实施例中的基于北向接口的业务 实现方法进行详细说明， 请参阅图 2, 本发明实施例中的基于北向接口的业务 实现方法的另一个实施例包括：
201、 构造 ODU0光数据单元模型层次标识符；
由于北向接口领域的业界标准组织， 例如， 电信管理论坛 （TMF , Telecommunication Management Forum )并未对 ODU0 ( 1.25G )业务制定相关 的管理模型和标准， 本实施例中， 首先构造 ODU0的 ODU模型层次标识符，， 该模型层次标识符包括 ODU0 业务模型层标识（ID ), 层标识字符串 （Layer Identifier )及对象名称字符串 （ Object Naming String )。
具体的举例说明， 假设将 ODU0业务模型层标识设置为 8031 , 即 ID为 8031 , 层标识字符串为 LR— OCH— Data— Unit— 0, 对象名称字符串为 ODU0, 则 构造的 ODU0模型层次标识符如表 1所示：
表 1
ID Layer Identifier Object Naming Description String
8031 LR-OCH-Data-Unit-0 ODU0 Optical channel Data Unit 0
( trail and tandem connection monitoring/ termination ) 202、 对具有包括光数据单元 ODU0业务及其他速率业务处理能力的端口 进行 ODU0业务建模；
对具有光数据单元 ODU0业务及光数据单元 ODUk业务处理能力的端口 进行 ODU0建模， 其中， k的取值为 1至 3的整数。 为便于描述， 本实施例以 对具有 ODU0业务及 ODU1业务处理能力的端口进行 ODU0建模。可以理解， 对具有 ODU0业务及光数据单元 ODU2业务（光数据单元 ODU3业务）处理 能力的端口进行 ODU0建模原理相同， 此处不再赘述。
具体的， 首先选取具有 ODU1业务及 ODU0业务处理能力的端口， 将多 个 ODU0业务复用为一个 ODU1业务， 具体的复用过程为现有技术， 此处不 再赘述，将复用后的 ODU1业务经过光通道传送单元（ OUT , Optical Transport Unit ) 1的封装， 最终进入光层进行传输。
需要说明的是， 经 OTU1 封装是将 ODU1 业务的数据报文加上头信息 ( OH, Over Head ), 然后再经过类似的添加开销等方式进行映射和复用， 最 终进入光层进行传输， 封装及传输过程为现有技术， 此处不再赘述。
具体的 ODU0业务建模图， 请参见图 3, 描述一个端口的层次以及上下关 联关系， 三个方形的框分别表示端口的三个层次， 分别为物理层 301 , 物理层 上面的是逻辑层 302,最上层是连接终端点（ CTP, Connection Termination Point ) 逻辑层 303 , 以箭头的方向表示各层次是一种包含关系， 自下而上， 箭头的源 层次包含宿层次， 各层内的倒三角形表示细分的层次。 以 "LR— " 开头的字符 用于描述细分层次， 为符合业界标准的描述方式， 根据信号的处理过程， 划分 了多个层次， 每个层次表示信号处理的不同阶段和所处位置。
具体的， 层次 3011以字符 LR— PHYSICAL— OPTICAL表示， 层次 3012以 字符 LR— OPTICAL— SECTION表示， 层次 3021以字符 LR— Optical— Channel表 示， 层次 3022以字符 LR— DIGITAL— SIGNAL— RATE表示， 层次 3023以字符 LR—OCH— Transport— Unit— 1表示， 层次 3024以字符 LR—OCH— Data— Unit— 1表 示， CTP逻辑层 303中的多个层次以字符 LR—OCH— Data— Unit— 0表示，以 CTP 逻辑层 303中引出的虚线， 表示可以包含多个层次。
需要说明 的是， 在本发明 实施例的技术方案 中 ， 除字符 LR-OCH-Data-Unit-0以外， 均为业界标准描述方式， 因此不再赘述。 本发明 实施例通过增加字符 LR-OCH-Data-Unit-0, 并将多个 ODU0 复用进一个 ODU1从而实现 ODU0业务建模。
203、 通过北向接口接收业务事件， 提取其中的对象模型参数；
在 CORBA架构内部， 从 EMS向 NMS提供服务的角度看， CORBA的客 户端在 NMS侧， 服务端在 EMS侧， 上层系统通过 CORBA客户端 （NMS 侧 )发送业务事件， 然后 CORBA服务端 （EMS侧 )接收业务事件， 提取该 业务事件中的对象模型参数。 对象模型参数即为各级业务速率模型的参数。
本发明实施例中， 业务事件可分为业务发放命令、 业务保障命令、 业务保 障事件及资源改变事件。
其中， 业务发放命令包括： 业务创建命令、 业务激活命令、 业务去激活命 令及业务删除命令；
业务保障命令包括： 业务告警查询命令、 业务性能查询命令， 存量查询命 令及业务查询命令；
业务保障事件包括： 业务告警上报事件及业务性能上报事件；
资源改变事件包括： 业务创建事件、 业务删除事件、 业务路由改变事件及 业务属性改变事件。
进一步的， 本发明实施例中的业务参数包括： 业务对象、 业务类型及存量 对象。
204、根据预置的 ODU0业务光模型层次标识符及所提取的对象模型参数， 判断该对象模型是否为 ODU0业务；
EMS提取业务事件中的对象模型参数后， 根据预置的 ODU0业务模型层 次标识符及所提取的对象模型参数， 判断该对象模型是否为 ODU0 U.25G ) 业务。
205、 若是， 则将对象模型参数转换为网管系统可识别的参数；
如果对象模型为 ODU0业务， 则 EMS将该业务的参数进行转换， 转换为 网管系统识别的业务参数， 使得系统可以处理 ODU0业务。 本发明实施例中， 网管系统可分为网管后台和上层系统。
若不是， 则 EMS将忽略该业务命令。 206、 处理包含转换后的对象模型参数的业务事件。
本实施例中， 上层系统通过北向接口发送业务命令， 主要包括业务发放命 令及业务保障命令， 其中， 业务发放命令包括业务创建命令、 业务激活命令、 业务去激活命令及业务删除命令； 业务保障命令包括业务告警查询命令、业务 性能查询命令， 存量查询命令及业务查询命令；
网管后台通过北向接口上报业务事件，主要包括业务保障事件及资源改变 事件，其中， 包括：业务保障事件包括业务告警上报事件及业务性能上报事件； 资源改变事件包括： 业务创建事件、 业务删除事件、 业务路由改变事件及业务 属性改变事件。
一、 当业务命令为业务发放命令时， 根据以下不同的业务发放命令， 基于 北向接口处理业务的方法可以具体分为以下方式：
(一）业务创建命令：
通过北向接口接收到业务创建命令后， 提取其中的对象模型参数， 例如， 可以是上文所述的业务模型层标识，层标识字符串及对象名称字符串中的一种 或几种， 具体根据实际应用过程确定， 此处不作限定。 根据预置的 ODU0业 务光模型层次标识符以及提取的对象模型参数， 判断该业务是否是 ODU0 ( 1.25G )业务， 如果是， 将与该 1.25G业务相关的参数， 包括对象模型参数， 转换成网管后台可以识别的存量对象和业务类型参数， 向网管后台下发创建 1.25G业务命令。可支持上层网管通过北向接口在网管系统内创建 1.25G业务。
(二）业务激活命令：
通过北向接口接收到业务激活命令后， 提取其中的对象模型参数， 例如， 可以是上文所述的业务模型层标识，层标识字符串及对象名称字符串中的一种 或几种， 具体根据实际应用过程确定， 此处不作限定。 根据预置的 ODU0业 务光模型层次标识符以及提取的对象模型参数， 判断该业务是否是 ODU0 ( 1.25G )业务， 如果是， 将与该 1.25G业务相关的参数， 包括对象模型参数， 转换成网管可以识别的业务对象和业务类型参数， 向网管后台下发激活 1.25G 业务命令。 可支持上层网管通过北向接口在网管系统内激活 1.25G业务。
(三）业务去激活命令：
通过北向接口接收到业务去激活命令后，提取其中的对象模型参数，例如， 可以是上文所述的业务模型层标识，层标识字符串及对象名称字符串中的一种 或几种， 具体根据实际应用过程确定， 此处不作限定。 根据预置的 ODU0业 务光模型层次标识符以及提取的对象模型参数判断该业务是否是 ODU0 ( 1.25G )业务， 如果是， 将与该 1.25G业务相关的参数， 包括对象模型参数， 转换成网管可以识别的业务对象和业务类型参数，向网管后台下发 1.25G业务 去激活命令。 可支持上层网管通过北向接口在网管系统内去激活 1.25G业务。
(四）业务删除命令：
通过北向接口接收到业务删除命令后， 提取其中的对象模型参数， 例如， 可以是上文所述的业务模型层标识，层标识字符串及对象名称字符串中的一种 或几种， 具体根据实际应用过程确定， 此处不作限定。 根据预置的 ODU0业 务光模型层次标识符以及提取的对象模型参数判断该业务是否是 ODU0 ( 1.25G )业务， 如果是， 将与该 1.25G业务相关的参数， 包括对象模型参数， 转换成网管可以识别的业务对象和业务类型参数， 向网管后台下发删除 1.25G 业务命令。 可支持上层网管通过北向接口在网管系统内删除 1.25G业务。
二、 当业务命令为业务保障命令时， 根据以下不同的业务保障命令， 基于 北向接口处理业务的方法可以具体分为以下方式：
(一 )业务告警查询命令：
业务告警查询命令的实现过程为，通过北向接口接收到业务告警查询命令 后， 提取其中的对象模型参数， 例如， 可以是上文所述的业务模型层标识， 层 标识字符串及对象名称字符串中的一种或几种， 具体根据实际应用过程确定， 此处不作限定。 根据预置的 ODU0业务光模型层次标识符以及提取的对象模 型参数， 判断该业务是否是 ODU0 ( 1.25G ) 业务， 如果是， 将与该 1.25G业 务相关的参数， 包括对象模型参数， 转换成网管可以识别的业务对象和业务类 型参数， 向网管后台下发该 1.25G业务告警查询命令， 并根据前述 ODU0业 务建模结果，将业务告警查询结果中的参数转换成标准北向接口协议参数，将 转换后的参数封装入北向接口协议数据报文，并向上层系统发送该数据报文以 返回业务告警查询结果。
(二）业务性能查询命令；
业务性能查询命令的实现过程为，通过北向接口接收到业务性能查询命令 后， 提取其中的对象模型参数， 例如， 可以是上文所述的业务模型层标识， 层 标识字符串及对象名称字符串中的一种或几种， 具体根据实际应用过程确定 , 此处不作限定。 根据预置的 ODU0业务光模型层次标识符以及提取的对象模 型参数， 判断该业务是否是 ODU0 ( 1.25G ) 业务， 如果是， 将与该 1.25G业 务相关的参数， 包括对象模型参数， 转换成网管可以识别的业务对象和业务类 型参数， 向网管后台下发该 1.25G业务性能查询命令， 并根据前述 ODU0业 务建模结果，将业务性能查询结果中的参数转换成标准北向接口协议参数，将 转换后的参数封装入北向接口协议数据报文，并向上层系统发送该数据报文以 返回业务性能查询结果。可支持上层网管通过北向接口实现 1.25G业务相关的 性能管理。
(三）存量查询命令：
通过北向接口接收到存量查询命令后， 提取其中的对象模型参数， 例如， 可以是上文所述的业务模型层标识，层标识字符串及对象名称字符串中的一种 或几种， 具体根据实际应用过程确定， 此处不作限定。 根据预置的 ODU0业 务光模型层次标识符以及提取的对象模型参数， 判断该业务是否是 ODU0 ( 1.25G )业务， 如果是， 将与该 1.25G业务相关的参数， 包括对象模型参数， 转换成网管后台可以识别的业务对象和业务类型参数， 向网管后台下发 1.25G 存量， 并根据前述 ODU0 业务建模结果， 将存量查询结果的参数转换成标准 北向接口协议参数，将转换后的参数封装入北向接口协议数据报文， 并向上层 系统发送该数据报文以返回存量查询结果。可支持上层网管通过北向接口实现 1.25G业务相关的存量管理。
(四 )业务查询命令：
通过北向接口接收到业务查询命令后， 提取其中的对象模型参数， 例如， 可以是上文所述的业务模型层标识，层标识字符串及对象名称字符串中的一种 或几种， 具体根据实际应用过程确定， 此处不作限定。 根据提取的对象模型参 数判断该业务是否是 1.25G业务， 如果是， 北向接口将与 1.25G业务相关的参 数，包括对象模型参数，转换成网管后台可以识别的业务对象和业务类型参数， 北向接口向网管后台下发业务查询命令， 并根据前述 ODU0业务建模结果， 将业务查询结果中的参数转换成标准北向接口协议参数，将转换后的参数封装 入北向接口协议数据报文， 并向上层系统发送该数据报文以返回业务查询结 果。 可支持上层网管通过北向接口实现查询 1.25G业务。
三、 当业务命令为业务保障事件时， 根据以下不同的业务保障事件， 基于 北向接口处理业务的方法可以具体分为以下方式：
(一）业务告警上报事件：
如果业务在系统的设备上产生 1.25G业务告警，则设备将告警事件上报给 网管后台， 通过北向接口接收网管后台上报的业务告警事件， 根据前述 ODU0 业务建模结果，将上报的 1.25G告警业务相关参数转换成标准北向接口协议参 数， 将转换后的参数封装为北向接口协议数据报文， 并向上层系统上报。 参数 转换过程及封装过程为可通过现有技术完成， 此处不再赘述。
(二）业务性能上报事件：
如果业务在系统的设备上产生 1.25G业务的性能相关信息，则设备将业务 性能信息上报给网管后台，通过北向接口接收网管后台发送的业务性能上报信 息， 根据前述 ODU0业务建模结果， 将上报中的 1.25G业务相关参数转换成 标准北向接口协议参数，将转换后的参数封装为北向接口协议数据报文， 并向 上层系统上报。
四、 当业务命令为资源改变事件时， 根据以下不同的资源改变事件， 基于 北向接口处理业务的方法可以具体分为以下方式：
(一）业务创建事件；
如果业务在系统的设备上产生新的 1.25G业务，则设备将业务创建信息上 报给网管后台，通过北向接口接收网管后台发送的业务创建上报信息，根据前 述 ODU0业务建模结果， 将上报中的 1.25G业务相关参数转换成标准北向接 口协议参数，将转换后的参数封装为北向接口协议数据报文， 并向上层系统上 报。
(二）业务删除事件；
如果业务在系统的设备上删除 1.25G业务，则设备将业务删除信息上报给 网管后台， 通过北向接口接收网管后台发送的业务删除上报信息， 根据前述 ODU0业务建模结果，将上报中的 1.25G业务相关参数转换成标准北向接口协 议参数， 将转换后的参数封装为北向接口协议数据报文， 并向上层系统上报。 (三）业务路由改变事件；
如果业务在系统的设备上产生 1.25G业务路由改变的情况，则设备将业务 路由改变信息上报给网管后台，通过北向接口接收网管后台发送的业务路由改 变上报信息， 根据前述 ODU0业务建模结果， 将上报中的 1.25G业务相关参 数转换成标准北向接口协议参数，将转换后的参数封装为北向接口协议数据报 文， 并向上层系统上报业务路由改变事件。
(四）业务属性改变事件：
如果业务在系统的设备上产生 1.25G业务属性改变的情况， 例如， 业务的 优先级、业务速率级别发生改变，则设备将业务路由改变信息上报给网管后台， 通过北向接口接收网管后台发送的业务属性改变上报信息， 根据前述 ODU0 业务建模结果， 将上报中的 1.25G 业务相关参数转换成标准北向接口协议参 数，将转换后的参数封装为北向接口协议数据报文， 并向上层系统上报业务属 性改变事件。
需要说明的是， 所能够实现的网管系统对 1.25G业务的管理， 包括但不限 于以上业务， 其他类似业务的实现过程可参照上述相关描述， 此处不再赘述。
本发明实施例中， 网管系统在管理 1.25G业务的同时，也可以将此北向接 口相关信息提供给更高层的网管系统， 这样， 更高层的网管系统也能够通过这 些北向接口来管理 OTN 1.25G业务。
为便于理解， 下面对基于北向接口完成以上业务管理的过程进行概括描 述， 仍以 CORBA接口为例。 首先由 NMS通过 CORBA接口， 将业务命令下 发给 EMS, 并等候 EMS返回完成信号， NMS对端的 EMS接收到命令后， 完 成相应业务管理操作， 再通过 CORBA接口将完成情况以及相关数据返回给 另一方面， 当系统中产生 1.25G业务时，也能够通过 CORBA接口，主动、 及时上报给上层网管， 这样， NMS就可以对该业务进行实时监控。 具体的， 上报过程是利用 CORBA "通知服务" 这样在现有技术中比较成熟的 CORBA 标准服务来完成的。 当某个 EMS所管辖的 1.25G业务发生某种事件（事件可 包括创建事件、 删除事件、 路由改变事件、 属性改变事件等） 时， 该 EMS可 以将该消息打包， 然后通过 CORBA技术所现有的 "通知服务"， 将消息压入 通知服务， 而通知服务会根据消息的订阅者情况， 将这一消息传递给订阅者， 例如 NMS。 其中， EMS是消息的主动提供者， 而 NMS是被动接收者。 而且， "通知服务" 也支持相反的情况， 即通知服务主动等候 EMS 消息， 而 NMS 主动向通知服务获取消息。前一种消息传递方式为 PUSH模式，后一种消息传 递方式为 PULL模式。
可以理解的， 本发明实施例不但可以应用于 EMS与 NMS之间的接口， 还可以应用于 EMS与 OSS之间的接口， 或者 NMS与运营支撑系统（OSS, Operation Support System )之间的接口， 以及具有类似功能的所有 OTN业务 管理的应用管理系统之间的接口。 并且， 不只应用于 CORBA协议接口， 还可 以应用于 XML , SNMP , ASCII ( American Standard Code for Information Interchange, 美国信息互换标准代码）等其他协议类型的接口。
本发明实施例中， 通过 ODU0业务建模， 管理系统之间 （例如 EMS和 NMS )业务形成对接， 通过北向接口对 ODU0 (1.25G)业务进行管理， 当通过 北向接口收到的业务事件是业务创建、 业务激活、 业务去激活、 业务删除， 业 务告警查询、 业务性能查询， 存量查询及业务查询命令， 提取其中的对象模型 参数， 若判断该业务是 ODU0 (1.25G)业务， 则向网管后台下发业务命令； 当 收到的业务事件为业务告警查询命令、业务性能查询命令、存量查询命令或业 务查询命令时，向网管后台发送执行 1.25G业务的命令之后将业务结果中的参 数转换成标准北向接口协议参数，将转换后的参数封装入北向接口协议数据报 文， 并向上层系统发送该数据 文以返回业务查询结果， 通过 ODU0 业务建 模及转换业务参数实现上层系统通过北向接口进行业务管理；当收到的业务事 件为业务告警上报事件、 业务性能上报事件， 业务创建事件、 业务删除事件、 业务路由改变事件及业务属性改变事件，通过北向接口接收网管后台上报的业 务事件， 提取该业务事件中的对象模型参数， 根据预置的 1.25G业务建模， 判 断所提取的对象模型是否为 1.25G业务， 若是， 则将业对象模型参数转换成标 准北向接口协议参数，将转换后的参数封装入北向接口协议数据报文， 并向上 层系统上报业务事件。 以上述方式， 通过 ODU0业务建模及转换业务参数实 现基于北向接口的 ODU0业务的管理。
下面介绍本发明实施中的基于北向接口的业务实现装置， 请参阅图 4, 本 发明实施例中的基于北向接口的业务实现装置的一个实施例包括： 接收单元 401 , 用于通过北向接口接收业务事件；
提取单元 402, 用于提取所接收的业务事件中的对象模型参数；
判断单元 403 ,用于根据预置的 ODU0业务光模型层次标识符及所提取的 对象模型参数， 判断对象模型是否为 ODU0业务；
转换单元 404, 用于若是 ODU0业务， 则将对象模型 ^：转换为网管系统 识别的业务参数；
处理单元 405, 用于处理包含转换后的对象模型参数的业务事件。
本发明实施例中， 接收单元 401 通过北向接口接收业务事件， 提取单元 402 提取所接收的业务事件中的对象模型参数， 判断单元 403 根据预置的
ODU0业务光模型层次标识符及所提取的对象模型参数，判断对象模型是否为
ODU0业务，若是 ODU0业务，则转换单元 404将对象模型参数转换为网管系 统识别的业务参数， 处理单元 405 处理包含转换后的对象模型参数的业务事 件。 由此， 可通过北向接口实现对 ODU0业务的处理。
为便于理解， 下面介绍本发明实施例中的业务实现装置的另一个实施例， 请参阅图 5, 本发明实施例中的基于北向接口的业务实现装置的另一个实施例 包括：
接收单元 501 , 用于通过北向接口接收业务事件；
提取单元 502, 用于提取所接收的业务事件中的对象模型参数；
判断单元 503 ,用于根据预置的 ODU0业务光模型层次标识符及所提取的 对象模型参数， 判断对象模型是否为 ODU0业务；
转换单元 504, 用于若是 ODU0业务， 则将对象模型 ^：转换为网管系统 识别的业务参数； 其中， 当业务事件为业务创建命令、 业务激活命令、 业务去 激活命令及业务删除命令时，转换单元 504还用于将对象模型参数转换为网管 后台识别的业务参数； 当业务事件为业务告警查询命令、 业务性能查询命令， 存量查询命令及业务查询命令时， 转换单元 504还用于根据 ODU0业务建模 结果， 将业务告警查询结果、 业务性能查询结果、 存量查询结果或业务查询结 果中的 ODU0业务参数转换成标准北向接口协议参数； 当业务事件为业务保 障事件及资源改变事件时，转换单元 504还用于将对象模型参数转换成标准北 向接口协议参数；
处理单元 505, 用于处理包含转换后的对象模型参数的业务事件。
进一步的， 当业务事件为业务创建命令、 业务激活命令、 业务去激活命令 及业务删除命令时， 处理单元 505还可以进一步包括发送单元 5051 , 用于向 网管后台发送执行 ODU0 业务的命令， 当业务事件为业务告警查询命令、 业 务性能查询命令， 存量查询命令及业务查询命令时， 发送单元 5051还用于向 上层系统发送查询结果；
当业务事件为业务告警查询命令、 业务性能查询命令， 存量查询命令、 业 务查询命令、业务保障事件及资源改变事件时， 处理单元 505还可以进一步包 括： 封装单元 5052, 用于将转换后的参数封装入北向接口协议数据报文； 需要说明的是，本发明实施例中的基于北向接口的业务实现装置可以进一 步包括：
构造单元 506,用于构造 ODU0业务光通道数据单元 ODU0模型层次标识 付；
建模单元 507,用于对具有包括 ODU0及 ODUk业务处理能力的端口进行
ODU0业务建模， 其中， k的取值为 1至 3的整数；
上报单元 508, 用于向上层系统上报业务事件。
其中， 建模单元 507可以进一步包括：
选取单元 5071 , 用于选取具有 ODU0及 ODUk业务处理能力的端口， 其 中， k的取值为 1至 3的整数；
复用单元 5072, 用于将端口的多个 ODU0业务复用为一个 ODUk业务； 封装业务单元 5073 ,用于将复用后的 ODUk业务经光通道传送单元 OUTk 封装。
本发明实施例中的装置更具实现的功能不同，可以包括上述各单元中的不 同组合， 不应将上述单元全部作为本装置实施例的必要技术特征。
本发明实施里中基于北向接口的业务实现装置各单元功能的具体实现方 式， 与前述各实施例中的基于北向接口的业务实现方法各对应的步骤内容相 同， 此处不再赘述。
本发明实施例中， 预先由构造单元 506创建 ODU0业务光通道数据单元 ODU0模型层次标识符，该模型层次标识符包括 ODU0业务模型层标识（ ID ), 层标识字符串 （ Layer Identifier )及对象名称字符串 （ Object Naming String ), 建模单元 507对具有包括 ODU0及 ODUk业务处理能力的端口进行 ODU0业 务建模， 其中， k的取值为 1至 3的整数， 建模单元 507包括选取单元 5071 , 复用单元 5072及封装单元 5073 , 具体的， 由选取单元 5071选取具有 ODU0 及 ODUk业务处理能力的端口， 其中， k的取值为 1至 3的整数， 复用单元 5072将该端口的多个 ODU0业务复用为一个 ODUk业务，封装业务单元 5073 将复用后的 ODUk业务经光通道传送单元 OUTk封装， 以进入光层进行传输， 这样， 便在系统中增加了 ODU0业务所支持的 ODU0业务的模型和标准。
接收单元 501通过北向接口接收业务事件后 ,提取单元 502提取所接收的 业务事件中的对象模型参数， 判断单元 503根据预置的 ODU0业务光模型层 次标识符， 判断对象模型是否为 ODU0支持的 1.25G业务， 若是， 则转换单 元 504将对象模型参数转换为网管系统识别的业务参数。
具体的， 当业务事件为业务创建命令、 业务激活命令、 业务去激活命令及 业务删除命令时，转换单元 504还用于将对象模型参数转换为网管后台识别的 业务参数； 当业务事件为业务告警查询命令、 业务性能查询命令， 存量查询命 令及业务查询命令时， 转换单元 504还用于根据 ODU0业务建模结果， 将业 务告警查询结果、 业务性能查询结果、 存量查询结果或业务查询结果中的 ODU0业务参数转换成标准北向接口协议参数， 当业务事件为业务保障事件及 资源改变事件时，转换单元 504还用于将对象模型参数转换成标准北向接口协 议参数。
转换单元 504将对象模型参数转换为网管系统识别的业务参数之后，处理 单元 505处理包含转换后的对象模型参数的业务事件。
具体的， 当业务事件为业务创建命令、 业务激活命令、 业务去激活命令及 业务的命令， 当业务事件为业务告警查询命令、 业务性能查询命令， 存量查询 命令及业务查询命令时， 发送单元 5051还用于向上层系统发送查询结果； 当 业务事件为业务告警查询命令、 业务性能查询命令， 存量查询命令、 业务查询 命令、业务保障事件及资源改变事件时， 处理单元 505还可以进一步包括封装 单元 5052, 用于将转换后的参数封装入北向接口协议数据报文， 之后， 由上 报单元 508向上层系统上报业务事件， 由此可实现网管系统对 ODU0业务的 管理。
本领域技术人员可以理解实现上述实施例方法中的全部或部分步骤是可 以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存 储介质中， 上述提到的存储介质可以是只读存储器， 磁盘或光盘等。
以上对本发明所提供的一种基于北向接口的业务实现方法及装置进行了 详细介绍， 对于本领域的技术人员， 依据本发明实施例的思想， 在具体实施方 式及应用范围上均会有改变之处， 综上所述， 本说明书内容不应理解为对本发 明的限制。

Claims

- 17- 权 利 要 求
1、 一种基于北向接口的业务实现方法， 其特征在于， 包括：
通过北向接口接收业务事件， 提取所述业务事件中的对象模型参数； 根据预置的光数据单元 ODU0业务光模型层次标识符及所提取的对象模 型参数， 判断所述对象模型是否为光数据单元 ODU0业务；
若是， 则将所述对象模型参数转换为网管系统识别的^!史；
处理包含转换后的对象模型参数的业务事件。
2、 根据权利要求 1所述的方法， 其特征在于， 所述接收业务事件之前包 括：
构造光数据单元 ODU0业务光数据单元 ODU0模型层次标识符， 所述模 型层次标识符包括光数据单元 ODU0 业务模型层标识， 层标识字符串及对象 名称字符串；
对具有包括光数据单元 ODU0及光数据单元 ODUk业务处理能力的端口 进行光数据单元 ODU0业务建模， 其中， k的取值为 1至 3的整数。
3、根据权利要求 2所述的方法，其特征在于，所述对具有光数据单元 ODU0 及光数据单元 ODUk业务处理能力的端口进行业务建模包括：
选取具有光数据单元 ODU0及光数据单元 ODUk业务处理能力的端口， 其中， k的取值为 1至 3的整数；
将所述端口的多个光数据单元 ODU0业务复用为一个光数据单元 ODUk 业务；
将所述复用后的光数据单元 ODUk 业务经光通道传送单元光数据单元 OUTk封装。
4、 根据权利要求 3所述的方法， 其特征在于，
所述业务事件至少包括下列其中之一： 业务发放命令、 业务保障命令、 业 务保障事件、 资源改变事件；
所述业务发放命令至少包括下列其中之一：业务创建命令、业务激活命令、 业务去激活命令、 业务删除命令；
所述业务保障命令至少包括下列其中之一： 业务告警查询命令、业务性能 查询命令， 存量查询命令、 业务查询命令； - 18- 所述业务保障事件至少包括下列其中之一： 业务告警上报事件、业务性能 上报事件；
所述资源改变事件至少包括下列其中之一：业务创建事件、业务删除事件、 业务路由改变事件、 业务属性改变事件；
所述业务参数至少包括下列其中之一：
业务对象、 业务类型、 存量对象。
5、 根据权利要求 1至 4任一项所述的方法， 其特征在于， 当所述业务事 件为业务创建命令、 业务激活命令、 业务去激活命令及业务删除命令时，
所述将对象模型参数转换为网管系统可识别的参数包括：将所述对象模型 参数转换为网管后台识别的业务参数；
所述处理包含转换后的对象模型参数的业务事件包括：
向网管后台发送执行所述光数据单元 ODU0业务的命令。
6、 根据权利要求 5所述的方法， 其特征在于， 当所述业务事件为业务告 警查询命令、 业务性能查询命令， 存量查询命令及业务查询命令时， 所述向网 管后台发送执行所述光数据单元 ODU0业务的命令之后包括：
根据光数据单元 ODU0 业务建模结果， 将业务告警查询结果、 业务性能 查询结果、 存量查询结果或业务查询结果中的光数据单元 ODU0 业务参数转 换成标准北向接口协议参数；
将转换后的参数封装入北向接口协议数据报文，并向上层系统发送查询结 果。
7、 根据权利要求 1至 4任一项所述的方法， 其特征在于， 当所述业务事 件为业务保障事件及资源改变事件时，
所述将对象模型参数转换为网管系统可识别的参数包括：将所述对象模型 参数转换成标准北向接口协议参数；
所述处理包含转换后的对象模型参数的业务事件包括：将转换后的参数封 装入北向接口协议数据报文， 并向上层系统上报所述业务事件。
8、 一种基于北向接口的业务实现装置， 其特征在于， 包括：
接收单元， 用于通过北向接口接收业务事件；
提取单元， 用于提取所接收的业务事件中的对象模型参数； - 19- 判断单元， 用于根据预置的光数据单元 ODU0业务光模型层次标识符及 所提取的对象模型参数， 判断所述对象模型是否为光数据单元 ODU0 业务； 转换单元， 用于若是光数据单元 ODU0 业务， 则将所述对象模型参数转 换为网管系统识别的参数；
处理单元， 用于处理包含转换后的对象模型参数的业务事件。
9、 根据权利要求 8所述的装置， 其特征在于， 所述装置还包括： 构造单元， 用于构造光数据单元 ODU0业务光数据单元 ODU0模型层次 标识符；
建模单元， 用于对具有包括光数据单元 ODU0及光数据单元 ODUk业务 处理能力的端口进行光数据单元 ODU0业务建模， 其中， k的取值为 1至 3的 整数。
10、 根据权利要求 9所述的方法， 其特征在于， 所述建模单元包括： 选取单元， 用于选取具有光数据单元 ODU0及光数据单元 ODUk业务处 理能力的端口， 其中， k的取值为 1至 3的整数；
复用单元， 用于将所述端口的多个光数据单元 ODU0业务复用为一个光 数据单元 ODUk业务；
封装业务单元， 用于将所述复用后的光数据单元 ODUk业务经光通道传 送单元 OUTk封装。
11、 根据权利要求 8至 10任一项所述的装置， 其特征在于，
所述业务事件至少包括下列其中之一：
业务发放命令及业务保障命令、 业务保障事件、 资源改变事件；
所述业务发放命令至少包括下列其中之一：业务创建命令、业务激活命令、 业务去激活命令、 业务删除命令；
所述业务保障命令至少包括下列其中之一： 业务告警查询命令、业务性能 查询命令， 存量查询命令、 业务查询命令；
所述业务保障事件至少包括下列其中之一： 业务告警上报事件、业务性能 上报事件；
所述资源改变事件至少包括下列其中之一：业务创建事件、业务删除事件、 业务路由改变事件、 业务属性改变事件； -20- 所述业务参数至少包括下列其中之一：
业务对象、 业务类型、 存量对象。
12、 根据权利要求 11所述的装置， 其特征在于， 当所述业务事件为业务 创建命令、 业务激活命令、 业务去激活命令及业务删除命令时，
所述转换单元，还用于将所述对象模型参数转换为网管后台识别的业务参 数；
所述处理单元还包括：
发送单元， 用于向网管后台发送执行所述光数据单元 ODU0业务的命令。
13、 根据权利要求 12所述的装置， 其特征在于， 当所述业务事件为业务 告警查询命令、 业务性能查询命令， 存量查询命令及业务查询命令时，
所述转换单元， 还用于根据光数据单元 ODU0业务建模结果， 将业务告 警查询结果、业务性能查询结果、存量查询结果或业务查询结果中的光数据单 元 ODU0业务参数转换成标准北向接口协议参数；
所述发送单元， 还用于向上层系统发送查询结果；
所述装置还包括：
封装单元， 用于将转换后的参数封装入北向接口协议数据报文。
14、 根据权利要求 13所述的装置， 其特征在于， 当所述业务事件为业务 保障事件及资源改变事件时，
所述转换单元， 还用于将所述对象模型参数转换成标准北向接口协议参 数；
所述封装单元， 还用于将转换后的参数封装入北向接口协议数据报文； 所述装置还包括：
上报单元， 用于向上层系统上报所述业务事件。
PCT/CN2011/077679 2011-07-27 2011-07-27 一种基于北向接口的业务实现方法及装置 WO2012106938A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/CN2011/077679 WO2012106938A1 (zh) 2011-07-27 2011-07-27 一种基于北向接口的业务实现方法及装置
CN201180001311.4A CN102439904B (zh) 2011-07-27 2011-07-27 一种基于北向接口的业务实现方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2011/077679 WO2012106938A1 (zh) 2011-07-27 2011-07-27 一种基于北向接口的业务实现方法及装置

Publications (1)

Publication Number Publication Date
WO2012106938A1 true WO2012106938A1 (zh) 2012-08-16

Family

ID=45986265

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2011/077679 WO2012106938A1 (zh) 2011-07-27 2011-07-27 一种基于北向接口的业务实现方法及装置

Country Status (2)

Country Link
CN (1) CN102439904B (zh)
WO (1) WO2012106938A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017000678A1 (zh) * 2015-07-01 2017-01-05 中兴通讯股份有限公司 一种网管系统间报文的通信方法及系统
CN114070886A (zh) * 2021-11-17 2022-02-18 深圳壹账通智能科技有限公司 报文转换方法、装置、设备及介质
CN114915533A (zh) * 2022-04-29 2022-08-16 武汉烽火技术服务有限公司 一种基于平台的北向接口实现方法和架构

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105099741A (zh) * 2014-05-19 2015-11-25 中兴通讯股份有限公司 北向接口自动下发业务的方法及装置
CN104202177B (zh) * 2014-07-21 2018-07-06 国家电网公司 一种用于电力通信网中异构网络的数据整合方法
CN106330507B (zh) * 2015-06-30 2020-06-05 中兴通讯股份有限公司 一种ctp生成方法和装置、以及网管服务器
CN105099595B (zh) * 2015-08-04 2018-12-25 瑞斯康达科技发展股份有限公司 一种光传送网otn设备的业务映射方法及装置
CN107294746B (zh) * 2016-03-30 2020-09-11 华为技术有限公司 一种部署业务的方法及设备
CN109150563A (zh) * 2017-06-16 2019-01-04 中兴通讯股份有限公司 一种基于北向接口的数据采集方法、系统及北向接口系统
CN109951748B (zh) * 2017-12-21 2020-11-27 中国移动通信集团公司 一种基于sdn的otn中的业务超发方法及系统
CN110311799B (zh) * 2018-03-27 2022-02-25 华为技术有限公司 一种通信方法及装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1790993A (zh) * 2004-12-14 2006-06-21 华为技术有限公司 在光传送网中传输低速率业务信号的方法
CN101447829A (zh) * 2007-11-27 2009-06-03 华为技术有限公司 处理命令的方法以及北向接口
CN101729933A (zh) * 2008-10-23 2010-06-09 中兴通讯股份有限公司 一种odu0标签交换通道的建立方法及系统
WO2010130076A1 (zh) * 2009-05-11 2010-11-18 华为技术有限公司 光传输网中的数据传送方法、系统及设备

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1790993A (zh) * 2004-12-14 2006-06-21 华为技术有限公司 在光传送网中传输低速率业务信号的方法
CN101447829A (zh) * 2007-11-27 2009-06-03 华为技术有限公司 处理命令的方法以及北向接口
CN101729933A (zh) * 2008-10-23 2010-06-09 中兴通讯股份有限公司 一种odu0标签交换通道的建立方法及系统
WO2010130076A1 (zh) * 2009-05-11 2010-11-18 华为技术有限公司 光传输网中的数据传送方法、系统及设备

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017000678A1 (zh) * 2015-07-01 2017-01-05 中兴通讯股份有限公司 一种网管系统间报文的通信方法及系统
CN106330519A (zh) * 2015-07-01 2017-01-11 中兴通讯股份有限公司 一种网管系统间报文的通信方法及系统
CN106330519B (zh) * 2015-07-01 2019-12-17 中兴通讯股份有限公司 一种网管系统间报文的通信方法及系统
CN114070886A (zh) * 2021-11-17 2022-02-18 深圳壹账通智能科技有限公司 报文转换方法、装置、设备及介质
CN114915533A (zh) * 2022-04-29 2022-08-16 武汉烽火技术服务有限公司 一种基于平台的北向接口实现方法和架构
CN114915533B (zh) * 2022-04-29 2023-05-30 武汉烽火技术服务有限公司 一种基于平台的北向接口实现方法和架构

Also Published As

Publication number Publication date
CN102439904A (zh) 2012-05-02
CN102439904B (zh) 2014-11-19

Similar Documents

Publication Publication Date Title
WO2012106938A1 (zh) 一种基于北向接口的业务实现方法及装置
CN107294753B (zh) 一种sdn/nfv开放接入网系统及管理onu/ont的方法
US9300537B2 (en) Bandwidth-on-demand systems and methods
CN108809672B (zh) 一种虚拟端口的管理方法及装置
US9755936B2 (en) Enabling software-defined control in passive optical networks
CN104604182B (zh) 业务通道配置方法和光线路终端以及无源光网络
US11936520B2 (en) Edge controller with network performance parameter support
CN104468237B (zh) 一种sdh和ptn网络告警联动的方法及应用该方法的系统
CN101150365A (zh) 一种无源光网络终端的管理方法
CN109412877B (zh) 一种基于utn网络的网络能力开放系统
CN102984507A (zh) 一种视频监控系统中的网络协管及兼管装置
CN107888401A (zh) 一种实时监控视联网终端cpu利用率的方法和系统
CN102480319A (zh) 一种对pon终端进行维护管理的方法
US20120163799A1 (en) Method for Transmitting OAM Message and Processing Error in PON System
CN100401684C (zh) 网络管理层通过网元管理层实现信息管理的方法
CN101741592B (zh) 多业务传送网中管理gpon支路的方法、设备及系统
JPH11164013A (ja) 通信システムにおける管理情報通信方法、交換機および管理情報通信のための変換プログラムを記憶した記録媒体
CN101447829B (zh) 处理命令的方法以及北向接口
CN103108347A (zh) 有线网络和无线网络的关联告警方法及装置
CN106301839A (zh) 一种面向传输网的统一网络管理接口适配器
EP4254894A1 (en) Time series data collection for a network management system
WO2011150807A1 (zh) 带宽分配方法及实现带宽分配的设备
CN108683598A (zh) 一种非对称网络流量处理方法和处理装置
CN106330507B (zh) 一种ctp生成方法和装置、以及网管服务器
CN105208091A (zh) 一种多协议存储管理系统

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 201180001311.4

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11858211

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 11858211

Country of ref document: EP

Kind code of ref document: A1