WO2007085152A1 - Procédé de gestion pour communication transdomaine et connexion du réseau optique à commutation automatique - Google Patents
Procédé de gestion pour communication transdomaine et connexion du réseau optique à commutation automatique Download PDFInfo
- Publication number
- WO2007085152A1 WO2007085152A1 PCT/CN2006/002444 CN2006002444W WO2007085152A1 WO 2007085152 A1 WO2007085152 A1 WO 2007085152A1 CN 2006002444 W CN2006002444 W CN 2006002444W WO 2007085152 A1 WO2007085152 A1 WO 2007085152A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- domain
- sub
- connection
- processing
- snc
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q11/00—Selecting arrangements for multiplex systems
- H04Q11/0001—Selecting arrangements for multiplex systems using optical switching
- H04Q11/0062—Network aspects
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q11/00—Selecting arrangements for multiplex systems
- H04Q11/0001—Selecting arrangements for multiplex systems using optical switching
- H04Q11/0062—Network aspects
- H04Q2011/0088—Signalling aspects
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q11/00—Selecting arrangements for multiplex systems
- H04Q11/0001—Selecting arrangements for multiplex systems using optical switching
- H04Q11/0062—Network aspects
- H04Q2011/009—Topology aspects
Definitions
- the present invention relates to the field of optical networks, and in particular to a method for controlling cross-domain calls and connections in an automatic switched optical network.
- Optical network such as OTN (Optical Transmission Network), WDM (Wavelength-Division Multiplexing), SDH (Synchronous Digital Hierarchy), or SONET (Synchronous Optical Network)
- OTN Optical Transmission Network
- WDM Widelength-Division Multiplexing
- SDH Synchronous Digital Hierarchy
- SONET Synchronous Optical Network
- ASON Automatic Switched Optical Network
- CP Control Plane
- the series of standards such as ITU-TG.8080 proposes the concept of a domain.
- different manufacturers' equipments build different ASON networks, that is, different domains. These domains are interconnected by an external network interface (ITU-T standard E-NNI for short).
- E-NNI external network interface
- Customers connect to each other through a user network interface (ITU-T standard UNI for short).
- Each ASON device logically sets up control components that perform different functions. Including, the connection controller responsible for connection control (ITU-T standard becomes CC), and the component responsible for completing the call is called the call controller.
- the call controller includes a call controller of the calling or called client equipment (referred to as CCC in the ITU-T standard) and a call controller (referred to as NCC in the ITU-T standard) on the ASON network side.
- the domain border network element is responsible for call processing, and implements NCC. All network elements (including boundaries) in the domain are responsible for connection establishment, that is, CC is implemented.
- CC responsible for the connection process.
- the interconnection requirements of different ASON networks have become more and more call and connection establishment. For example, as shown by the dotted line in Fig. 1, ((0) how the client device and the CCC 4b client device complete the call and connection through each ASON domain, there is no relevant standard and technology at present.
- the technical problem to be solved by the present invention is to provide a control method for automatically switching optical network cross-domain calls and connections, which solves the problem that the current standard and technology cannot realize the cross-domain call and connection control of the ASON network.
- the present invention provides a control method for a cross-domain connection of an switched optical network, which first constructs a multi-layer network structure including a parent domain and a child domain, and at least one network element in the parent domain corresponds to one sub-domain. And communicating with the network element of the sub-domain, the parent domain network element is configured with parameters corresponding to the network element in the sub-domain, and the boundary link of the sub-domain is an input/output link corresponding to the parent domain network element, and no sub-domain light
- the network domain is called the underlying domain.
- Each network element contains the connection controller CC.
- the ingress connection controller CC di of the underlying domain D di receives the call-side connection controller CC cl connection processing request and determines that the cross-domain connection is made, and uploads the request to the 0 ⁇ and called side cc c2 resources.
- CC fi determines the connection route L ft according to the source and destination resource addresses in the request, and sends the connection coordination information to the exit CC f . , CC f .
- the post-received corresponding underlying domain D d is received.
- An outlet cc d connected to the source of the CC c on the called side.
- Send connection indication information, cc d Pass this information to cc c2 ;
- CC d0 receives the CC. After the connection processing of 2 returns the information, it is passed to the exit CC f of the parent domain D ft . , from CC f . Initially, each CC f on the route L ft completes the processing of connecting the SNC to the local subnet in turn, and returns the success information to the CC at the previous level until CCfi;
- step (c) When the step (c) has the parent domain CC f of the corresponding sub-domain for local SNC processing, perform the following steps:
- CCzi determines that the sub-connection processing is triggered by the CC f of the parent domain, returns an SNC confirmation to the CC f , and ends the local SNC processing of the parent domain CC f ;
- the messages between the sub-domains are transmitted layer by layer.
- the CC of each sub-domain judges to be a cross-domain connection, the message is delivered to the CC corresponding to the sub-domain in its parent domain, and the CC of each parent domain is Pass the message to the cc in its corresponding subdomain that is connected to the source or destination resource address.
- the last CC on the connection route in the parent domain or the sub-domain first determines whether the domain is connected to both the calling side CC cl and the called side CC c2 . If yes, The connection indication is passed to the underlying domain D d . The exit CC d connected to the CC c2 resource. Otherwise, the local SNC processing is performed, and the information of the processing result is returned to the previous level CC.
- the ingress CC fi in the parent domain D ft receives the connection processing request, or the ingress CC zi in the subdomain receives the SNC connection processing request, first checks whether the request parameter is legal and whether the local domain can satisfy the parameter description. Condition, if yes, perform subsequent connection processing, otherwise, directly return the information that the connection processing failed.
- the subsequent connection processing is immediately stopped, and the current CC returns the connection processing failure information to the previous one that requests the connection processing.
- Level CC the CC then returns the failure information directly to the previous level CC until the failure information is returned to the calling side C (:.
- connection processing, the sub-connection processing, and the SNC processing are connection establishment, sub-connection establishment, and SNC establishment; or, the connection processing, sub-connection processing, and SNC processing are connection modification, sub-connection modification, and SNC modification; or Connection processing, sub-connection processing, and SNC processing are removed for connection, sub-connection deletion, and SNC deletion.
- the present invention further provides a control method for a cross-domain call and connection of an switched optical network, which first constructs a multi-layer network structure including a parent domain and a child domain, and at least one network element corresponding to the parent domain corresponds to A sub-domain can communicate with the network element of the sub-domain.
- the parent-domain network element is configured with parameters corresponding to the network element in the sub-domain.
- the boundary link of the sub-domain is the input/output link of the corresponding parent domain network element.
- the optical network domain of the domain is called the underlying domain.
- Each network element includes the network side call controller NCC and the connection controller cc.
- the ingress call controller NCC di of the lower layer domain D di receives the call processing request from the calling side call controller CCC cl and determines that the request is a cross-domain call, and uploads the request to the AND. . ( ⁇ and the input NCC fi corresponding to the domain D di in the parent domain D ft connected to the CCC c2 resource on the called side;
- the NCC fi is the export NCC f connected to the destination resource address in the local domain.
- the call coordination information is sent, and the NCC f0 receives the exit NC connected to the corresponding sub-domain D d0 and the called side CCC c2 resource.
- (C) NCC d After receiving the call confirmation of the called side CCC c2 , the exit NCC f through the parent domain D ft . Passed to the ingress NCCfj, the NCC fi sends a connection processing request to the connection controller CC fi of the local network element, carrying the ingress and egress resource addresses of the parent domain D ft ;
- each parent domain CC f of the corresponding sub-domain on the route L ft is locally when subnetwork connections SNC process, complete processing of the sub-domains present between the inlet and outlet connection resource address in the sub-field, and CC f SNC return acknowledgment;
- the step (D) CC f is to complete the local SNC processing by the following steps:
- (D1) CC f sends an SNC processing request to the ingress CC zi of the corresponding sub-domain D z connected to the sub-domain entry resource, carrying the ingress and egress resource address of the sub-domain D z , that is, the entry of the CC f on the connection route Link and egress link;
- CC zi determines the sub-connection process by the CC f is triggered the parent domain, returns to the CC f SNC confirmed, the local end processing SNC parent domain of CC f ;
- the step (D) CC f is to complete the local SNC processing by the following steps:
- SNC processing request carries the inlet and outlet of the resource address subdomain D z, i.e., links connecting the inlet and outlet links of the CC f is routing;
- D2 After receiving the SNC request, the NCQi sends a sub-connection processing request to the corresponding CCd, carrying the ingress and egress resource addresses of the sub-domain 0 2 ;
- the CC zi determines the sub-connection route L z according to the ingress and egress resource addresses and triggers the sub-connection processing procedure of the local domain;
- the NCC determines that the sub-connection process is triggered by the CC f of the parent domain, returns an SNC acknowledgement to the CC f , and ends the local SNC process of the parent domain CC f ;
- the step (D) CC f is to complete the local SNC processing by the following steps:
- (D1) CC f sends an SNC processing request to the ingress NCC zi of the corresponding sub-domain D z connected to the sub-domain entry resource, carrying the ingress and egress resource addresses of the sub-domain D z , that is, the entry of the CC f on the connection route Link and egress link;
- NCC zi After receiving the SNC request, NCC zi sends an exit NCC Z to the export resource of the domain. Send subcall coordination information, NCC Z . Returning the sub-call confirmation to the NCCd, and the NC sends a sub-connection processing request to the corresponding CC zi , carrying the ingress and egress resource addresses of the sub-domain 0 2 ;
- the CC zi determines the sub-connection route L z according to the ingress and egress resource addresses and triggers the sub-connection processing procedure of the local domain;
- the egress NCC in the parent domain or the sub-domain When receiving the coordination information of the call or the sub-call, the egress NCC in the parent domain or the sub-domain first determines whether the domain is connected to the calling side ⁇ ( ⁇ and the called side CCC c2 , and if so, the call indication The information is passed to the exit NCC d of the underlying domain D d . Otherwise, the sub-call confirmation is returned to the entry NCCzi of the domain.
- the entry NCCfi of the parent domain D ft receives the connection processing request, or the entry NCC zi in the sub-domain receives the SNC processing request, first checks whether the request parameter is legal and whether the domain can satisfy the conditions described by the parameter, if Yes, the subsequent connection processing is performed, otherwise, the information that the call fails or the SNC processing fails is directly returned.
- the subsequent call or connection processing is immediately stopped, and the current NCC or CC returns the call or connection processing failure information to The previous level NCC or CC that requests it to make a call or connection process, the NCC or CC then returns the failure information directly to the previous stage NCC or CC until the failure information is returned to the calling side CCC.
- the call processing, sub-call processing, connection processing, sub-connection processing, and SNC processing refer to call setup, sub-call setup, connection establishment, sub-connection establishment, and SNC establishment; or call modification, sub-call modification, connection modification, sub-connection Modification and SNC modification; or call deletion, sub-call deletion, connection deletion, sub-connection deletion and SNC deletion.
- the present invention introduces a parent domain on the basis of an existing ASON domain, and a cross-domain Call and connection control complex problems are decomposed into the control of call and connection for each parent domain and subdomain respectively.
- the ASON network realizes the technical problem of cross-domain call and connection control, which provides a reference for ASON network to realize cross-domain call and connection.
- the technology of the present invention has the advantages of simplicity and reliability.
- FIG. 1 is a schematic diagram of an ASON network composed of multiple ASON domain interconnections
- FIG. 2 is a schematic diagram of introducing a parent domain into each domain of the ASON network shown in FIG. 1;
- FIG. 3 is a component interaction diagram of the ASON network cross-domain call and connection shown in FIG. 1;
- FIG. 4 is a component interaction diagram of a cross-domain call and connection when the sub-domain does not require a call function in the ASON network shown in FIG. 1;
- FIG. 5 is a component interaction diagram of a cross-domain connection when the ASON network shown in FIG. 1 does not require a call function
- FIG. 6 is a flowchart of implementation of a cross-domain call and connection corresponding to the component interaction diagram of FIG. 3
- FIG. 7 is FIG. A cross-domain call and connection implementation flow diagram corresponding to the component interaction diagram when the sub-domain does not require a call function
- Figure 8 is a flow chart showing the implementation of the cross-domain connection when the ASON network does not need the calling function, corresponding to the component interaction diagram of Figure 5;
- FIG. 9 is a schematic diagram of an ASON network shown in FIG. 1 for implementing cross-domain calls and connections;
- FIG. 10 is a schematic diagram of an implementation of a cross-domain call and connection in the ASON network shown in FIG. 1 when the sub-domain does not require a calling function;
- FIG. 11 is a schematic diagram of an implementation of a cross-domain connection when the ASON network shown in FIG. 1 does not require a call function. Preferred embodiment of the invention
- the core idea of the present invention is to introduce a parent domain based on the existing framework structure of the ASON network, and to decompose a cross-domain call and connection control problem into a parent domain and each child. Call and connection control issues within the domain are resolved.
- each of the parent domain and the child domain adopts a call plus connection mode
- the top parent domain adopts a call plus connection mode
- the other domains adopt a non-call only connection mode
- Both the sub-domain and the sub-domain use the method of not calling only to connect, and directly connect to the cross-domain connection when no call is needed.
- the ASON network based on this embodiment includes four interconnected ASON domains (Domain ⁇ 4), and the domain border network element is responsible for call processing and implements NCC. All network elements (including boundaries) in the domain are responsible for connection establishment, that is, CC: is implemented.
- Step 101 Determine a boundary of a domain Domain1, and determine all boundary links of the domain Domain 1, including: CCC la - NCC la , CCCi c -NCC lc , NCC ld -NCC 2a ⁇ NCC lb -NCC 3a ⁇ W ⁇ , these four boundary links are the logical network elements NCC 1234 ⁇ input and output links corresponding to the domain Domain1;
- Step 102 Generate network element NCC 1234 ⁇ configuration parameters according to network domain elements NCC la , NCC lb , NCC lc , and NCC ! ⁇ ⁇ J configuration parameters (including network communication address, protocol type, and the like);
- Step 103 Perform step 101 in sequence for domain Domain2, Domain3, and Domain4.
- Step 104 the domain Domainl, Domain2, Domain3 and Domain4 corresponding to the determined logical network element NCC 1234a, NCC 1234b, NCC 1234c and NCC 1234d are interconnected by a respective input and output links, to form a logical domain Domainl234, 2 .
- the above-mentioned logical domain Domainl234 is called a parent domain, and the original ASON network domains Domainl, Domain2, Domain3, and Domain4 are called subdomains.
- the embodiment is a two-layer structure
- the logical domain Domainl234 as a parent domain can be combined with other ASON domains to form an upper layer logic in the same way.
- the domain that is, the parent domain Domainl 234 can also be a child domain of another parent domain, and can have a multi-layered structure.
- the ASON field without subdomains is referred to as the underlying domain.
- the network element in the parent domain is a logical network element with ASON control plane function, including call and connection control, routing control, link management, etc., but the present invention is concerned with call and connection control.
- Intranet elements have call and connection control functions, including an NCC and a CC.
- the connection between the parent domain network elements is the link between the sub-domains.
- the call and connection control functions between the network elements in the parent domain are the same as those of the existing ASON domain.
- Step 201 The ingress network element call controller NC of the subdomain Domain1 detects the client side network element call controller (: ( 1 : & sent "Call Request” (Call Request),;
- the NCC connected to the CCC on the calling side is the ingress network element of the call in the domain.
- the corresponding network element of the underlying domain in its parent domain is the ingress network element of the parent or the call.
- Step 202 The NCC la 4 determines, according to the parameters in the call setup request (such as the destination resource address, the call type, the protection level, the QoS, etc.), that the call is a cross-domain call at the local domain (subdomain),
- the ingress network element NCC 1234a of the parent domain Domainl 234 passes the "call setup request,;
- Step 203 After detecting the call request, determining that the call is a local domain call, and verifying whether the call parameter is legal and whether the domain satisfies the condition of the call parameter description (such as QoS), if yes, according to the call parameter.
- the destination resource address that is, the logical link between the sub-domain Domain 4 and the client-side network element CCC 4b , can determine that the egress NCC of the local domain is the network element NCCi 2 34d corresponding to the sub-domain Domain 4, and the NCC is located to the egress network element NCC.
- the call (excluding the sub-call of the sub-domain during the establishment of the SNC) is in the exit NCC of each domain, that is, the NCC with a link between the call and the called CCC in the domain.
- the NCC 1234a determines whether it is a cross-domain call, it will continue to pass the "call setup request" to the ingress network element of its parent domain.
- Step 204 The egress network element NCC 1234d determines that the resource of the domain Domain1234 is connected to the calling side 0 ⁇ and the called side CCC 4b (ie, has a direct link association with each other), and generates according to the received call coordination information. "Call Indication" and pass it to the exit NCC 4b of the subdomain Domain 4 , and then continue from the NCC 4b to the called client side network element step 205, the NCC 4b detects the call request return returned by the CCC 4b Information, here is Call Confirmed, which is passed to the egress network element NCC I234d of the parent domain Domain 234 , which passes the call request return information to the portal NCC 1234a ;
- Step 206 When determining that the return information of the call request is Call Confirmed, the NCC 1234a sends a connection establishment request (Connection Request) to the connection controller CC of the local network element, where the request includes the entry and exit resources of the local domain.
- the address is a logical link between the domain Domain 1234 and CCC la , Domainl 234 and CCC 4b ;
- Step 207 After receiving the connection establishment request, the CC corresponding to the NCC 1234a determines the connection route of the local area according to the ingress resource address and the egress resource address, and triggers the connection establishment process.
- the connection route is as shown in FIG. 9 and corresponds to the NCC 1234a .
- the ingress network element NCC 4a corresponding to the subdomain Domain 4 carries the ingress and egress resource addresses of the call in the subdomain;
- the CC corresponding to the NCC 1234a sends the connection coordination information (Connection Coordination) to the CC corresponding to the NCC 1234c .
- the CC sends a Connection Indication to the CC corresponding to the NCC 1234d .
- the invention does not limit the type of message.
- Step 208 After detecting the SNC establishment request of the CC corresponding to the NCC 1234d , the NCC 4a triggers the sub-call, first checks whether the parameter is legal and whether the domain satisfies the condition (such as QoS) described by the parameter. If yes, according to the link of the egress resource address of the sub-domain, that is, the link between the domain 4 and the CCC 4b , determining that the exit NCC of the domain is the NCC 4b , and transmitting the sub-call coordination information (Sub-Call Coordination) to the NCC 4b , The source and destination resource addresses carrying the call;
- the condition such as QoS
- Step 209 After receiving the sub-call coordination information, the NCC 4b determines that the resource of the domain Domain4 belongs to the calling party 0: ( 1& is not connected, and generates corresponding return information, that is, Sub-Call Confirmed to the NCC 4a ;
- the source and destination resource addresses of the entire call may be carried in the SNC establishment request and the sub-call coordination information, but other methods may also be used, such as Step by step and so on.
- Step 210 When determining that the return request of the call request is a sub-call setup confirmation, the NCC 4a sends a Sub-Connection Request to the corresponding CC, including the entry and exit resource addresses of the sub-domain, that is, Domain4's 1 ⁇ (( a link between NCC 3b of Domain3 and NCC 4b and ccc 4b of Domain4;
- Step 211 After receiving the sub-connection establishment request, the CC corresponding to the NCC 4a determines the connection route according to the ingress and egress resource addresses and triggers the sub-connection establishment process, that is, the CC corresponding to the NCC 4a shown in FIG. (There may be no intermediate CC, the same below) - CC of the NCC 4b , the last NCC on the route, that is, the CC corresponding to the NCC 4b receives the sub-connection indication, establishes the local SNC, and sends the SNC setup request to the transmission resource plane.
- the ITU-T standard is referred to as the transport plane, abbreviated as TP);
- this SNC is the cross-connect of the transport plane, which is the smallest subnet connection.
- Step 212 The CC corresponding to the NCC 4b returns a Sub-Connection Confirmed to the CC in the middle of the Domain4. After the CC in the middle of the Domain4 establishes the local SNC, the CC corresponding to the NCC 4a returns a sub-connection establishment confirmation, and the CC completes the local. After the SNC is established, the sub-connection establishment confirmation is returned to the NCC 4a ;
- Step 213 The NCC 4a determines that the trigger condition of the local sub-call is the CC trigger of the Domainl 234, and returns the SNC Confirm (SNC Confirmed) to the corresponding CC of the NCC 1234d ;
- Step 214 NCC 1234d corresponding CC returns connection establishment to determine the corresponding CC NCC 1234c Recognize
- Step 215 The CC corresponding to the NCC 1234e receives the connection establishment confirmation.
- the SNC establishment request is sent to the ingress NCC 3a of the sub-domain 3 corresponding to the CC, and the ingress and egress resource addresses of the sub-domain are carried.
- Step 216 1 ⁇ ( 3 ⁇ 4 3 after detecting the SNC establishment request, completing the call and connection process in the domain Domain3, the processing thereof is the same as the domain Domain4, and is not repeated here;
- Step 217 >10: 3& After receiving the connection establishment confirmation sent by the corresponding CC, it is determined that the trigger condition of the local call is the CC trigger of Domainl 234, and the SNC confirms the return to the NCC 1234c CC; Step 218, NCC 1234c symptomatic CC direction
- the NCC 1234a corresponds to the CC return connection establishment confirmation; Step 219, the CC corresponding to the NCC 1234a receives the connection establishment confirmation, and when the local SNC is established, sends the SNC establishment request to the entry NCC la of the subdomain corresponding to the CC, carrying the call.
- Step 220 After detecting the SNC establishment request, the NCC la completes the call and connection process in the domain Domain1, and the processing thereof is the same as that of the domain Domain4, and is not repeated here;
- Step 221 After confirming the connection establishment sent by the CC, the NCC ⁇ t determines that the trigger condition of the local call is the CC trigger of the Domain1234, and returns the SNC to the 1 ⁇ ( 1234& corresponding CC;
- Step 222 NCC 1234a CC corresponding to the NCC 1234a returns connection establishment confirmation NCC 1234a through ⁇ Domainl (13 returns to the CCC la call establishment acknowledgment, and cross-domain call connection is established.
- an intra-domain link and an underlying domain of the underlying domains Domain1, Domain3, and Domain4 are established between the CC corresponding to CCC la and the CC corresponding to CCC 4b .
- t or intra-call (or sub-call) and connection (or sub-connection) processes are substantially the same as an intra-domain call and connection procedure specified in the prior art. of.
- the parent domain only the SNC establishment process needs to be completed by its subdomain; for the subdomain, the characteristic is that the SNC establishment request of the CC in the parent domain triggers the call and connection process, correspondingly to the parent domain.
- the CC returns the SNC return message.
- the network structure of this embodiment is the same as that of the first embodiment.
- the client side network element (3 ⁇ and CCC 4b creates an inter-domain call and connection as an example, indicating that only the top-level parent domain needs to be called,
- the client side network element (3 ⁇ and CCC 4b creates an inter-domain call and connection as an example, indicating that only the top-level parent domain needs to be called.
- the cross-domain call and the connection only the situation of the call success is described first, including the following steps:
- Steps 301 to 307 are the same as steps 201 to 207 of the first embodiment.
- the NCC 1234a has received the call setup confirmation returned from the called party (0 413 , and sends a connection establishment request to the corresponding CC.
- the CC determines the connection.
- the route is the CC corresponding to the NCC 1234a , the CC corresponding to the NCC 1234c , and the CC corresponding to the NCC 1234d triggers the connection establishment process.
- the SNC is sent to the entry NCC 4a of the subdomain Domain4.
- Step 308 After detecting the SNC establishment request, the NCC 4 ⁇ sends a sub-connection establishment request to the corresponding CC, including the ingress and egress resource addresses of the domain, that is, NCC 4a of Domain4 and NCC 3b of Domain3 and 1 ⁇ of Domain4 (link between 415 and CCC 4b ;
- Step 309 After receiving the sub-connection establishment request, the CC corresponding to the NCC 4a determines the connection route according to the ingress and egress resource addresses, that is, the CC corresponding to the NCC 4a shown in FIG. 10——”the CC1 in the middle of the Domain4” corresponds to the NCC 4b .
- the last NCC on the route that is, the CC corresponding to the NCC 4b receives the sub-connection indication, establishes the local SNC, and sends the SNC establishment request to the transmission resource plane;
- Step 310 The CC corresponding to the NCC 4b returns a sub-connection establishment confirmation to the CC in the middle of the Domain4. After establishing the local SNC, the CC in the middle of the Domain4 returns a sub-connection establishment confirmation to the CC corresponding to the NCC 4a , and the CC establishes a local SNC, and then Sub-connection establishment confirmation returns to NCC 4a ;
- Step 311 The NCC 4a determines that the trigger condition of the local domain connection is the CC trigger of the Domainl 234 , and returns the SNC acknowledgement to the CC corresponding to the NCC 1234d .
- Step 312 NCC 1234d corresponding CC returns connection establishment to determine the corresponding CC NCC 1234c Recognize
- Step 313 After receiving the connection establishment confirmation, the CC corresponding to the NCC 1234e sends a SNC establishment request to the ingress network element NCC 3a of the sub-domain 3 corresponding to the CC, and carries the call at the entrance and exit of the sub-domain.
- Step 314 After the NCC 3 ⁇ 3 ⁇ 4 to the SNC establishment request, the sub-connection process in the domain Domain3 is completed, and the processing is the same as that of the domain Domain4, and is not repeated here;
- Step 315 After the NCC 3 Jt reaches the sub-connection establishment confirmation sent by the CC, it is determined that the local domain connection is triggered by the CC of the Domainl 234, and the SNC acknowledges the CC corresponding to the NCC 1234e ; Step 316, the CC corresponding to the NCC 1234c corresponds to the NCC 1234a. The CC returns the connection establishment confirmation. Step 317: The CC corresponding to the NCC 1234a receives the connection establishment confirmation. When the local SNC is established, the SNC establishment request is sent to the ingress network element NCC la of the subdomain corresponding to the CC. The entry and exit resource addresses of the subdomain;
- Step 318 After detecting the SNC establishment request, the NCC ⁇ completes the sub-connection process in the domain Domain1, and the processing thereof is the same as the domain Domain4, and is not repeated here;
- Step 319 NCC la CC corresponding to the sub-transmission after receiving the connection establishment, and determines the domain of the connection is triggered by CC Domainl234 returns to the NCC 1234a SNC CC corresponding acknowledgment; step 320, NCC 1234a returns the corresponding CC NCC 1234a The connection is established and the NCC 1234a passes through Domain1's ((: 13) to CCC la return call setup confirmation, cross-domain call and connection setup is complete.
- the difference between this embodiment and the first embodiment is that, in the process of establishing the SNC by the parent domain NCC, after receiving the SNC establishment request, the ingress NCC of the sub-domain does not initiate a sub-call, but directly sends a sub-connection to its corresponding CC. The request is established and the other processing is the same.
- the CC corresponding to the entry NCC of the parent domain or the sub-domain may also check whether the connection request parameter is legal and whether the domain satisfies the condition described by the parameter before triggering the connection or sub-connection establishment process. , then perform the connection or sub-connection establishment process.
- the network structure of this embodiment differs in each sub-domain and parent domain.
- the network element of the ASON domain may have no call controller NCC.
- a cross-domain connection is created between the client side network elements 03 1 & and ( 41) as an example, and the specific cross-domain connection is established when the call is not needed in this embodiment.
- the call is successful is described first, including the following steps:
- Step 401 The connection controller CC la of the ingress network element of the subdomain Domain1 detects the connection controller of the client side network element ( 1 ⁇ 4 sent "connection establishment request";
- Step 402 CC la determines, according to the request parameter, that the connection is a cross-domain connection in the domain (subdomain Domain1) layer, and then, the ingress network element of the parent domain Domainl234 (that is, the network element corresponding to the subdomain in the parent domain)
- the connection controller 0 1231 ⁇ 2 passes the connection establishment request;
- Step 403 After detecting the connection establishment request, CC 1234a determines that it is a local domain call, first checks whether the connection request parameter is legal, and whether the local domain (parent domain Domainl234) satisfies the condition described by the parameter, and if so, according to the parameter
- the source resource address carried in the domain ie, the logical link between Domainl 234 and USER CCla
- the destination resource address ie, the logical link between Domainl 234 and USER 0: 4] 3 determine the connection route and trigger the connection establishment process.
- the connection route is shown in Figure 11, which is CCi 2 34a—a CC 123 4c—“ CC picture, CC 1234a generates connection coordination information.
- the network is a three-layer or higher structure and the NCC 1234a determines whether it is a cross-domain connection, it will continue to pass the "connection establishment request" to the ingress network element of its parent domain.
- connection (excluding the sub-connection of the sub-domain in the SNC establishment process) is the CC at the exit CC of each domain, that is, the link between the domain and the called CC.
- Step 404 After receiving the connection coordination information transmitted by the CC 1234a , the CC 1234d determines that the domain (parent domain Domain 234) is connected to the source and destination USER CC (USER (0 ⁇ and USER CC 4b ) related resources, according to Receiving connection coordination information, generating connection indication information (Connection Indication), and transmitting to the user side USER CC 4b through the exit CC 4b of the subdomain Domain4;
- the CC 1234d After receiving the connection coordination information transmitted by the CC 1234a , the CC 1234d determines that the domain (parent domain Domain 234) is connected to the source and destination USER CC (USER (0 ⁇ and USER CC 4b ) related resources, according to Receiving connection coordination information, generating connection indication information (Connection Indication), and transmitting to the user side USER CC 4b through the exit CC 4b of the subdomain Domain4;
- Step 405 CC 4b detects the connection establishment confirmation returned by the user side (Connection After confirming, it is determined that the connection is a cross-domain call at the domain ( Domain 4 ) level, and is transmitted to the corresponding network element CC 123 4d of the parent domain Domain 234;
- Step 406 (3 ( 1234 ⁇ 1) after receiving the connection establishment confirmation, triggering the establishment of the local SNC, and sending the SNC setup request (SNC Request) to the entry CC4a of the corresponding subdomain of the CC, carrying the entry and exit of the subdomain.
- the resource address which is the ingress link (near the calling side) and the egress link (the link near the called side) connected to the CC 1234d on the parent domain connection route;
- Step 407 After receiving, first check whether the connection request parameter is legal and whether the domain satisfies the conditions described in the parameter. If yes, determine the connection route according to the entry and exit resource addresses, that is, CC 4a— " The CC in the middle of Domain4 (may not exist) - CC 4b , and triggers the sub-connection establishment process. After receiving the Sub-Connection Indication, CC 4b judges that the domain is not related to the source and destination CC at the same time. The resources are connected, the local SNC is established, and the SNC setup request is sent to the transmission resource plane;
- CCs connected to the ingress and egress resources of the subdomain are respectively the ingress and egress of the subdomain.
- Step 408 CC 4b returns the subconnection establishment confirmation to the CC in the middle of Domain4.
- Step 409 CC 4a determines that the local sub-connection is triggered by CC 1234d of Domainl 234 , and returns an SNC confirmation to CC 1234 d;
- Step 410 CCi 234d returns Connection Confirmation to the CC 1234c .
- the entry CC 3a , the CC 3a completes the sub-connection establishment process in the domain Domain 3 in the same manner as the domain Domain 4;
- step 412, 0 After receiving the return connection establishment confirmation and completing the local SNC establishment, step 412, 0 determines that the local sub-connection is triggered by CC 1234c of Domainl 234 , and returns an SNC confirmation to CC 1234c ; Step 413, CC 1234c returns a connection establishment confirmation to CC 1234a. ;
- Step 414 The CC 1234 receives the connection establishment confirmation, triggers the establishment of the local SNC, and sends the SNC setup request to the entry CC la of the subdomain corresponding to the CC, the CC la and the domain. Domain4 completes the sub-connection establishment process in domain Domain1 in the same way;
- Step 418 After CC la receives the returned sub-connection establishment confirmation and completes the establishment of the local SNC, it determines that the sub-connection of the domain is triggered by CC 1234a of Domainl 234, and returns an SNC confirmation to CC 1234a ; Step 419, CC 1234a passes 0 ⁇ to USER CC la returns to the connection establishment confirmation, and the cross-domain connection establishment ends.
- the processing of the intra-domain connection of the parent domain or the sub-domain of this embodiment is basically the same as that of the prior art, except that the specific implementation of the local SNC in the parent domain is different.
- the entry of the domain NCC determines that the domain does not satisfy the conditions described by the call (or connection, including SNC) request parameters.
- the failure is not limited to the above situation.
- the current NCC or CC immediately stops subsequent processing, such as connection, call (including sub-connection and sub-call), and the connection processing fails.
- the information is returned to the previous level NCC or CC requesting its call or connection processing, and the CC returns the failure information directly to the previous level network element until the failure information is returned to the calling side CC.
- the NCC or CC of the parent or sub-domain After receiving the failure information, the NCC or CC of the parent or sub-domain returns the failure information directly to the previous level, and does not perform connection or local SNC establishment or other processing.
- the modification and deletion of the cross-domain call and connection are also included.
- Embodiments regarding cross-domain call and connection modification and deletion are substantially the same as the implementation of cross-domain call and connection establishment described above. It is only necessary to change the "establishment" of the call, sub-call, connection, sub-connection and SNC in the above embodiment to "modify” or "delete", which is the implementation of the invention regarding cross-domain call and connection modification or deletion. Program.
- the SNC establishment request may be directly sent to the entry CC of the corresponding sub-domain, and the CC triggers the completion of the sub-domain.
- the connection process instead of sending an SNC request to the ingress NCC of the subdomain, as in the second embodiment, sends a request to the corresponding CC via the NCC.
- the embodiment of the present invention decomposes a cross-domain call and connection control complex problem into a call and a connection in a parent domain and each sub-domain by introducing a parent domain on the basis of the existing ASON domain. Control problems, and finally solve the problem of cross-domain call and connection control, with the advantages of clean and reliable.
- the present invention can be used in an ASON network to decompose a cross-domain call and connection control complex problem into the control of each parent domain and sub-domain to complete call and connection control respectively, and finally the ASON network implements cross-domain call and connection control.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
自动交换光网络跨域呼叫和连接的控制方法
技术领域
本发明涉及光网络领域,具体涉及自动交换光网络中跨域呼叫和连接的 控制方法。
背景技术
光网络,例如 OTN( Optical Transmission Network,光传送网络)、 WDM ( Wavelength-Division Multiplexing, 波分复用 )、 SDH ( Synchronous Digital Hierarchy, 同步数字系列)或 SONET ( Synchronous Optical Network, 同步 光网络)传送网, 在电信领域已经得到广泛应用。
自动交换光网络( Automatic Switched Optical Network, 简称 ASON )是 近年来光网络领域的研究热点。 ITU-TG.8080建议提出了 ASON的概念, 通 过设置专门的控制平面 (Control Plane, 简称 CP )完成 ASON网络的功能。 ITU-TG.7713建议规定了 ASON网络中分布式呼叫与连接的实现框架,为呼 叫、 连接的自动建立、 修改和删除等提供了实现规范。
ITU-TG.8080等系列标准提出了域(Domain )的概念。 一般不同厂家的 设备, 构建不同的 ASON 网络, 即不同的域。 这些域之间通过外部网络接 口 (ITU-T标准简称为 E-NNI )相互连接。 客户通过用户网络接口 (ITU-T 标准简称为 UNI )和这些域相互连接。 每个 ASON设备从逻辑角度讲, 设 置完成不同功能的控制构件。 包括, 负责连接控制的连接控制器( ITU-T标 准成为 CC ) , 负责完成呼叫的构件称为呼叫控制器。 其中, 呼叫控制器包 括主叫或被叫客户设备的呼叫控制器 (ITU-T标准简称为 CCC )和 ASON 网络侧的呼叫控制器(ITU-T标准简称为 NCC ) 。
如图 1所示, 四个互连的 ASON域(Domainl〜4 ) , 域边界网元负责呼 叫处理, 实现了 NCC。 域内所有网元 (包括边界) , 都负责连接建立, 即 实现了 CC。 为了节省篇幅, 在后续图示中将根据描述需求说明负责连接处 理的 CC。
近年来随着 ASON网络的逐步商用, 不同 ASON网络的互连需求越来 域的呼叫和连接建立。例如附图 1中虚线所示,(( 0^所属客户设备和 CCC4b 所属客户设备如何通过各 ASON域完成呼叫和连接, 目前还没有相关的标 准和技术。
发明内容
本发明所要解决的技术问题在于,提供一种自动交换光网络跨域呼叫和 连接的控制方法, 解决目前标准和技术无法实现 ASON 网络跨域的呼叫和 连接控制问题。
为了解决上述技术问题,本发明提供了一种交换光网络跨域连接的控制 方法,先构建一个包括父域和子域的多层网络结构,所述父域中至少有一个 网元对应一个子域且可与该子域的网元通信,父域网元配置有对应子域中网 元的参数,子域的边界链路即为对应父域网元的输入输出链路, 没有子域的 光网络域称为底层域, 各网元中均包含连接控制器 CC, 在一次成功的跨域 连接处理中, 包括如下步骤:
( a )底层域 Ddi的入口连接控制器 CCdi收到主叫侧连接控制器 CCcl 连接处理请求且判断为跨域连接后, 将该请求上传至与 0^和被叫侧 ccc2 资源均相连的父域 Dft中与域 Ddi对应的入口 CCfi;
( b ) CCfi根据该请求中的源和目的资源地址确定连接路由 Lft, 将连接 协调信息发送到出口 CCf。, CC f。收到后向对应底层域 D d。与被叫侧 CCc 源相连的出口 ccd。发送连接指示信息, ccd。将该信息传递至 ccc2;
( c ) CCd0收到 CC。2的连接处理返回信息后, 将其传递到父域 D ft的出 口 CCf。,从 CCf。开始,路由 Lft上每一个 CCf依次完成对本地子网连接 SNC 的处理, 向前一级 CC返回成功信息, 直到 CCfi;
有对应子域的父域 CCf进行本地 SNC处理时, 需在子域 Dz完成对本域 入口和出口资源地址之间的子连接的处理;
( d ) CCfi完成本地 SNC后, 通过底层域 Ddi的入口 CCdi向主叫侧 CCcl
返回连接处理成功的信息, 跨域连接结束。
在一较佳实施例中:
所述步骤(c )有对应子域的父域 CCf进行本地 SNC处理时, 执行以下 步骤:
( cl ) CCf向对应子域 Dz中与该子域入口资源相连的入口 CC^发送子 网连接 SNC处理请求, 携带子域02的入口和出口资源地址, 即父域连接路 由上该 CCf的入口链路和出口链路;
( c2 ) CCzi收到 SNC处理请求后, 根据所述入口和出口资源地址确定 子连接路由 Lz并触发本域的子连接处理过程;
( c3 )完成子域 Dz内的子连接处理后, CCzi判断该子连接处理过程是 由父域的 CCf触发的, 向该 CCf返回 SNC确认, 结束父域 CCf的本地 SNC 处理;
在上述子连接处理过程中, 子连接路由 Lz上的 CC进行本地 SNC处理 时, 如该 CC也有对应子域, 则也将其作为父域 CCf , 按上述步骤(cl )〜 ( c3 )进行本地 SNC处理。
在一较佳实施例中:
父域 Dft和底层域 Ddi之间还有其它的光网络域,所述底层域的入口 CCdi 和父域 Dft中的入口 CCfi之间, 以及底层域的出口 CCd。和父域 Dft中的出口 CC f。之间的消息都是逐层传递的, 其中每一子域的 CC在判断是跨域连接 时, 都将消息传递到其父域中与该子域对应的 CC, 每一父域的 CC都将消 息传递到其对应子域中与源或目的资源地址相连的 cc。
在一较佳实施例中:
所述父域或子域中连接路由上的最后一个 CC在收到连接协调信息或连 接指示信息时,先判断本域是否与主叫侧 CCcl和被叫侧 CCc2都相连,如是, 将连接指示信息传递到底层域 D d。与 CCc2资源相连的出口 CCd。, 否则, 进 行本地 SNC处理, 再向前一级 CC返回处理结果的信息。
在一较佳实施例中:
所述父域 Dft中的入口 CCfi收到连接处理请求,或者子域中的入口 CCzi 收到 SNC连接处理请求时, 先校验请求参数是否合法以及本域是否能够满 足参数所描述的条件, 如果是, 再进行后续的连接处理, 否则, 直接返回连 接处理失败的信息。
在一较佳实施例中:
所述步骤(a ) ~ ( d )的跨域连接处理过程中, 任一操作失败后, 立即 停止后续的连接处理, 并由当前 CC将连接处理失败信息返回到请求其进行 连接处理的前一级 CC, 该 CC再直接向前一级 CC返回失败信息, 直到将 该失败信息返回到主叫侧 C (:。
在一较佳实施例中:
所述连接处理、子连接处理和 SNC处理为连接建立、子连接建立和 SNC 建立; 或者, 所述连接处理、 子连接处理和 SNC处理为连接修改、 子连接 修改和 SNC修改; 或者, 所述连接处理、 子连接处理和 SNC处理为连接删 除, 子连接删除和 SNC删除。
为了解决上述技术问题,本发明又提供了一种交换光网络跨域呼叫和连 接的控制方法,先构建一个包括父域和子域的多层网络结构,所述父域中至 少有一个网元对应一个子域且可与该子域的网元通信,父域网元配置有对应 子域中网元的参数,子域的边界链路即为对应父域网元的输入输出链路,没 有子域的光网络域称为底层域, 各网元中均包含网络侧呼叫控制器 NCC和 连接控制器 cc, 在一次成功的跨域呼叫和连接处理中, 包括如下步骤:
( A )底层域 Ddi的入口呼叫控制器 NCCdi收到主叫侧呼叫控制器 CCCcl 的呼叫处理请求且判断为跨域呼叫后, 将该请求上传至与 。。(^和被叫侧 CCCc2资源均相连的父域 Dft中与域 Ddi对应的入口 NCC fi;
( B ) NCC fi向本域中与所述目的资源地址相连的出口 NCCf。发送呼叫 协调信息, NCC f0收到后向对应子域 D d0与被叫侧 CCCc2资源相连的出口 NC 。发送呼叫指示信息, NCCd。再将该指示信息发送至被叫侧 CCCc2;
( C ) NCCd。收到被叫侧 CCCc2的呼叫确认后,经父域 Dft的出口 NCCf。
传递至入口 NCCfj, NCCfi向本网元的连接控制器 CCfi发送连接处理请求, 携带父域 Dft的入口和出口资源地址;
( D ) CC fi根据 Dft的入口和出口资源地址确定连接路由 Lft并触发本域 的连接处理过程, 在该过程中, 路由 Lft上有对应子域的每一父域 CCf进行 本地子网连接 SNC处理时, 需在该子域完成对本域入口和出口资源地址之 间的子连接的处理, 并向 CCf返回 SNC确认;
( E ) CC fi向 NCCfi返回连接确认, NCCfi通过底层域 Ddi的入口 NCCdi 向主叫侧。。(^返回呼叫确认, 结束。
在一较佳实施例中:
所述步骤(D ) CCf是通过以下步骤完成本地 SNC处理:
( Dl )CCf向对应子域 Dz中与该子域入口资源相连的入口 CCzi发送 SNC 处理请求, 携带该子域 Dz的入口和出口资源地址, 即连接路由上该 CCf的 入口链路和出口链路;
( D2 ) CCd收到 SNC处理请求后, 根据所迷入口和出口资源地址确定 子连接路由 Lz并触发本域的子连接处理过程;
( D3 )完成子域 Dz内的子连接处理后, CCzi判断该子连接处理过程是 由父域的 CCf触发的, 向该 CCf返回 SNC确认, 结束父域 CCf的本地 SNC 处理;
在子连接处理过程中, 子连接路由 Lz上的 CC进行本地 SNC处理时, 如该 CC也有对应子域, 则也将其作为父域 CCf ,按上述步骤( Dl ) ~ ( D3 ) 进行本地 SNC处理。
在一较佳实施例中:
所述步驟(D ) CCf是通过以下步骤完成本地 SNC处理:
( Dl ) CCf向对应子域 Dz中与该子域入口资源相连的入口 NCQi发送
SNC处理请求,携带该子域 Dz的入口和出口资源地址,即连接路由上该 CCf 的入口链路和出口链路;
( D2 ) NCQi收到该 SNC请求后, 向对应的 CCd发送子连接处理请求, 携带子域02的入口和出口资源地址;
( D3 ) CCzi收到子连接处理请求后,根据所述入口和出口资源地址确定 子连接路由 Lz并触发本域的子连接处理过程;
( D4 )完成子域。2内的子连接处理后, ( (^向^^¾返回子连接确认,
NCC 判断该子连接处理过程是由父域的 CCf触发的, 向该 CCf返回 SNC 确认, 结束父域 CCf的本地 SNC处理;
在上述子连接处理过程中, 子连接路由 Lz上的 CC进行本地 SNC处理 时, 如该 CC也有对应子域, 则也将其作为父域 CCf , 按上述步骤(Dl )〜 ( D4 )进行本地 SNC处理。
在一较佳实施例中:
所述步骤(D ) CCf是通过以下步骤完成本地 SNC处理:
( Dl ) CCf向对应子域 Dz中与该子域入口资源相连的入口 NCCzi发送 SNC处理请求,携带该子域 Dz的入口和出口资源地址,即连接路由上该 CCf 的入口链路和出口链路;
( D2 ) NCCzi收到该 SNC请求后,向与本域出口资源相连的出口 NCCZ。 发送子呼叫协调信息, NCCZ。向 NCCd返回子呼叫确认, NC 再向对应的 CCzi发送子连接处理请求, 携带子域02的入口和出口资源地址;
( D3 ) CCzi收到子连接处理请求后,根据所述入口和出口资源地址确定 子连接路由 Lz并触发本域的子连接处理过程;
( D4 )完成子域02内的子连接处理后, 0¾向1^0^返回子连接确认, NC 判断该子连接处理过程是由父域的 CCf触发的, 向该 CCf返回 SNC 确认, 结束父域 CCf的本地 SNC处理;
在上述子连接处理过程中, 子连接路由 Lz上的 CC进行本地 SNC处理 时, 如该 CC也有对应子域, 则也将其作为父域 CCf , 按上述步骤(Dl )〜 ( D4 )进行本地 SNC处理。
在一较佳实施例中:
父域 Dft和底层域 Ddi之间还有其它的光网络域, 所述底层域的入口 NCCdi和父域 Dft中的入口 NCCfi之间, 以及底层域的出口 NCCd。和父域 Dft 中的出口 NCCf。之间的消息都是逐层传递的, 其中每一子域的 NCC在判断 是跨域连接时, 都将消息传递到其父域中与该子域对应的 NCC, 每一父域 的 NCC都将消息传递到其对应子域中与源或目的资源地址相连的 NCC。
在一较佳实施例中:
所述父域或子域中的出口 NCC在收到呼叫或子呼叫的协调信息时, 先 判断本域是否与主叫侧 ^^(^和被叫侧 CCCc2都相连,如是,将呼叫指示信 息传递到底层域 Dd。的出口 NCCd。, 否则, 向本域的入口 NCCzi返回子呼叫 确认。
在一较佳实施例中:
所述父域 Dft的入口 NCCfi收到连接处理请求,或者子域中的入口 NCCzi 收到 SNC处理请求时, 先校验请求参数是否合法以及本域是否能够满足参 数所描述的条件, 如果是, 再进行后续的连接处理, 否则, 直接返回呼叫失 败或 SNC处理失败的信息。
在一较佳实施例中:
所述步骤( A ) ~ ( E )的跨域呼叫和连接处理过程中 , 任一操作失败后, 立即停止后续的呼叫或连接处理, 并由当前 NCC或 CC将呼叫或连接处理 失败信息返回到请求其进行呼叫或连接处理的前一级 NCC或 CC, 该 NCC 或 CC再直接向前一级 NCC或 CC返回失败信息, 直到将该失败信息返回 到主叫侧 CCC。
在一较佳实施例中:
所述呼叫处理、 子呼叫处理、 连接处理、 子连接处理和 SNC处理指呼 叫建立、 子呼叫建立、 连接建立、 子连接建立和 SNC建立; 或者指呼叫修 改、 子呼叫修改、 连接修改、 子连接修改和 SNC修改; 或者指呼叫删除、 子呼叫删除、 连接删除, 子连接删除和 SNC删除。
由上可知, 本发明在已有 ASON域的基础上引入父域, 将一个跨域的
呼叫与连接控制复杂问题分解为各个父域和子域分别完成呼叫和连接的控 制的问题,最终 ASON网络实现跨域呼叫与连接控制的技术问题,为 ASON 网络实现跨域呼叫与连接提供了参考的标准和技术。本发明所述技术具备简 洁、 可靠的优点。 附图概述
图 1是多个 ASON域互连组成的 ASON网络的示意图;
图 2是图 1所示 ASON网络各域引入父域的示意图;
图 3是图 1所示 ASON网络跨域呼叫和连接的构件交互图;
图 4是图 1所示 ASON网络当子域不需要呼叫功能时,跨域呼叫和连接 的构件交互图;
图 5是图 1所示 ASON网络不需要呼叫功能时,跨域连接的构件交互图; 图 6是与图 3构件交互图对应的跨域呼叫和连接的实现流程图; 图 7是与图 4构件交互图对应的,当子域不需要呼叫功能时的跨域呼叫 和连接的实现流程图;
图 8与图 5构件交互图对应的,当 ASON网络不需要呼叫功能时的跨域 连接的实现流程图;
图 9是图 1所示 ASON网络实现跨域呼叫和连接的示意图;
图 10是图 1所示 ASON网络在子域不需要呼叫功能时, 跨域呼叫和连 接的实现示意图;
图 11是图 1所示 ASON网络不需要呼叫功能时, 跨域连接的实现示意 图。 本发明的较佳实施方式
下面结合附图和实施例对本发明作进一步的详细说明。
本发明的核心思想是依据 ASON 网络现有的框架结构, 在已有 ASON 域的基础上引入父域,将一个跨域的呼叫和连接控制问题分解为父域和各子
域内的呼叫和连接的控制问题来解决。
下面根据技术发展的几种情况, 分为三个实施例来加以说明。 第一实施 例中各父域和子域均采用呼叫加连接的方式;第二实施例中顶层父域采用呼 叫加连接的方式, 其它域采用不呼叫只连接的方式; 第三实施例中父域和子 域均采用不呼叫只连接的方式, 在不需要呼叫时直接打通跨域连接。
第一实施例
如图 1所示, 本实施例所基于的 ASON网络包括四个互连的 ASON域 ( Domainl~4 ) ,域边界网元负责呼叫处理,实现了 NCC。域内所有网元(包 括边界)都负责连接建立, 即实现了 CC:。
首先, 结合图 1和图 2, 说明本实施例引入父域的具体实施方案, 包括 如下步骤: 步骤 101、确定域 Domainl的边界,确定域 Domain 1的所有的边界链路, 包括: CCCla-NCCla, CCCic-NCClc, NCCld-NCC2a^ NCClb-NCC3a^W^ 路, 这 4条边界链路即为该域 Domainl对应的逻辑网元 NCC1234 々输入输 出链路;
步骤 102、 根据域 Domainl 内网元 NCCla、 NCClb、 NCClc和 NCC!^^J 配置参数(包括网络通讯地址、 协议类型等), 生成网元 NCC1234 々配置参 数;
步骤 103、 对域 Domain2、 Domain3和 Domain4都依次执行步骤 101、
102;
步骤 104、 将域 Domainl、 Domain2、 Domain3和 Domain4对应确定的 逻辑网元 NCC1234a、 NCC1234b、 NCC1234c和 NCC1234d通过各自的输入输出链 路相互连接, 组成一个逻辑域 Domainl234, 如图 2所示。
根据层次关系, 称上述逻辑域 Domainl234为父域, 称原来的 ASON网 络域 Domainl、 Domain2、 Domain3和 Domain4为子域。
实施例虽然是由二层结构为例, 但本发明中, 作为父域的逻辑域 Domainl234也可以和其它的 ASON域按同样的方法再组成一个上层的逻辑
域,即父域 Domainl234也可以作为另一父域的子域,可以具有多层的结构。 为了说明方便, 文中将没有子域的 ASON域称为底层域。 另外, 在一些特 殊情况下, 父域中也可能存在有不对应于子域的网元。
父域中的网元是具备 ASON控制平面功能的逻辑网元, 包括呼叫和连 接控制、 路由控制、 链路管理等, 不过本发明关注的是呼叫和连接控制。 域 内网元都具有呼叫和连接控制功能, 包括一个 NCC和一个 CC。 实现父域网 元之间的连接是各子域之间的链路, 父域域内各网元间的呼叫、连接控制功 能的实现与现有 ASON域是相同的。
在建立如图 2所示的包含父域的 ASON网络后, 现在结合图 1、 图 2、 图 3和图 9,以在客户侧网元 0:(:13和 0:41)之间建立跨域呼叫和连接为例, 说明本发明实现跨域呼叫和连接的具体实施,先只对呼叫成功的情况进行说 明, 包括如下步骤:
步驟 201、子域 Domainl的入口网元呼叫控制器 NC ^测到客户侧网 元呼叫控制器(:。(:1&发送来的 "呼叫建立请求(Call Request ),, ;
这里, 对底层 ASON域来说, 与主叫侧的 CCC相连的 NCC即为该呼 叫在该域的入口网元。而该底层域在其父域中对应的网元即为该呼叫在该父 i或的入口网元。
步骤 202、 NCCla4艮据呼叫建立请求中的参数(如目的资源地址、 呼叫 类型、 保护级别、 QoS等等)判断出此呼叫在本域 (子域 Domainl )层面是 跨域呼叫后, 向父域 Domainl234的入口网元 NCC1234a传递该 "呼叫建立请 求,, ;
步骤 203、 :^0 123½检测到该呼叫请求后, 判断出是本域呼叫, 再校验 呼叫参数是否合法及本域是否满足呼叫参数描述的条件(如 QoS ) , 如是, 根据呼叫参数中的目的资源地址, 即子域 Domain4与客户侧网元 CCC4b之 间的逻辑链路, 可以确定出本域的出口 NCC是与子域 Domain4对应的网元 NCCi234d , 并向该出 口 网元 NCC1234d发送 "呼叫协调信息 ( Call Coordination ) " ;
呼叫(不包括 SNC建立过程中子域的子呼叫)在各个域的出口 NCC即 该域中与被叫 CCC之间有链路相连的 NCC。
如果网络为三层以上结构且 NCC1234a判断还是跨域呼叫 ,则会继续向其 父域的入口网元传递该 "呼叫建立请求" 。
步骤 204、 该出口网元 NCC1234d判断出所属域 Domainl234的资源与主 叫侧 0 ^及被叫侧 CCC4b相连 (即彼此之间有直接的链路关联) , 根据接 收的呼叫协调信息, 生成 "呼叫指示( Call Indication ) " , 并将其传递到子 域 Domain4的出口 NCC4b, 然后从 NCC4b继续传递至被呼叫的客户侧网元 步骤 205、 NCC4b检测到 CCC4b返回的呼叫请求返回信息, 这里是呼叫 建立确认(Call Confirmed ) , 将其传递到父域 Domainl234 的出口网元 NCCI234d, 该 NCC1234d将呼叫请求返回信息传递至入口 NCC1234a;
步骤 206、 NCC1234a判断呼叫请求的返回信息是呼叫建立确认(Call Confirmed )时, 向本网元的连接控制器 CC发送连接建立请求(Connection Request ) ,该请求中包含本域的入口和出口资源地址,分别为域 Domain 1234 与 CCCla、 Domainl234与 CCC4b之间的逻辑链路;
步骤 207、 NCC1234a对应的 CC在接收到连接建立请求后, 根据入口资 源地址和出口资源地址,确定本域连接路由并触发连接建立过程,该连接路 由如图 9所示,为 NCC1234a对应的 CC——〉〉NCC1234c对应的 CC——》NCC1234d 对应的 CC,路由上最后一个逻辑网元 NCC1234d对应的 CC建立本地 SNC(本 地子网连接)时, 将 SNC建立请求发送至本 CC对应子域 Domain4的入口 网元 NCC4a, 携带呼叫在该子域的入口和出口资源地址;
本实施例在连接过程中, NCC1234a对应的 CC 发送连接协调信息 ( Connection Coordination )到 NCC1234c对应的 CC, 该 CC收到后, 发送连 接指示(Connection Indication )到 NCC1234d对应的 CC。 不过本发明并不限 定消息的类型。
步骤 208、 NCC4a检测到 NCC1234d对应 CC的 SNC建立请求后, 触发子 呼叫,先校验参数是否合法以及本域是否满足参数所描述的条件 (如 QoS ) ,
如是, 再根据呼叫在该子域的出口资源地址, 即 Domain4与 CCC4b之间的 链路, 确定本域的出口 NCC 为 NCC4b, 向 NCC4b发送子呼叫协调信息 ( Sub—Call Coordination ) , 携带呼叫的源和目的资源地址;
步骤 209、 NCC4b收到子呼叫协调信息后, 判断所属域 Domain4的资源 与主叫 0:( 1&不相连, 生成相应返回信息, 即子呼叫建立确认(Sub— Call Confirmed)至 NCC4a;
为了使 NCC4b能够判断所属域 Domain4的资源与主叫或被叫是否有连 接, 可以在上述 SNC建立请求和子呼叫协调信息中携带整个呼叫的源和目 的资源地址, 但也可以采用其他方式, 如逐步查询等。
步骤 210、 NCC4a判断呼叫请求的返回信息是子呼叫建立确认时, 向对 应 CC发送子连接建立请求(Sub— Connection Request ) , 包含子域的入口和 出口资源地址,即 Domain4的 1^( ( 与 Domain3的 NCC3b、Domain4的 NCC4b 与 ccc4b之间的链路;
步骤 211、 NCC4a对应的 CC在接收到子连接建立请求后, 根据入口和 出口资源地址确定连接路由并触发子连接建立过程,即图 9所示 NCC4a对应 的 CC一一》 Domain4中间的 CC (也可能没有中间 CC, 下同)一一》 NCC4b 对应的 CC,路由上最后一个 NCC即 NCC4b对应的 CC收到子连接指示后建 立本地 SNC, 并将 SNC建立请求发送至传送资源平面 (ITU-T标准简称为 传送平面, 缩写为 TP ) ;
对于底层域来说, 这个 SNC就是传送平面的交叉连接, 也就是最小的 子网连接。
步骤 212、 NCC4b对应的 CC向 Domain4中间的 CC返回子连接建立确 认( Sub— Connection Confirmed ) , Domain4中间的 CC建立本地 SNC后, 向 NCC4a对应的 CC返回子连接建立确认,该 CC完成本地 SNC建立后,再 将子连接建立确认返回至 NCC4a;
步驟 213、NCC4a判断出本域子呼叫的触发条件是 Domainl234的 CC触 发, 向 NCC1234d对应 CC返回 SNC确认( SNC Confirmed );
步骤 214、 NCC1234d对应的 CC向 NCC1234c对应的 CC返回连接建立确
认;
步驟 215、 NCC1234e对应的 CC接收该连接建立确认,建立本地 SNC时, 将 SNC建立请求发送至与本 CC对应子域 Domain3的入口 NCC3a, 携带呼 叫在该子域的入口和出口资源地址;
步骤 216, 1^(¾3检测到该 SNC建立请求后,完成在域 Domain3的呼叫 和连接过程, 其处理与域 Domain4是相同的, 这里不再重复;
步骤 217、 >10:3&收到对应 CC发送的连接建立确认后, 判断本域呼叫 的触发条件是 Domainl234的 CC触发,向 NCC1234c对应 CC返回 SNC确认; 步珮 218、 NCC1234c对症的 CC向 NCC1234a对应 CC返回连接建立确认; 步骤 219、 NCC1234a对应的 CC接收到在连接建立确认后,建立本地 SNC 时, 将 SNC建立请求发送至与本 CC对应子域 Domainl的入口 NCCla, 携 带呼叫在该子域的入口和出口资源地址;
步骤 220、 NCCla检测到该 SNC建立请求后,完成在域 Domainl的呼叫 和连接过程, 其处理与域 Domain4是相同的, 这里不再重复;
步骤 221、 NCC^t到对应 CC发送的连接建立确认后, 判断本域呼叫 的触发条件是 Domainl234的 CC触发, 向 1^( 1234&对应的 CC返回 SNC确 认;
步骤 222、 NCC1234a对应的 CC向 NCC1234a返回连接建立确认, NCC1234a 通过 Domainl的 ^^( 13向 CCCla返回呼叫建立确认, 跨域呼叫和连接建立 完成。
如图 9所示, 在完成上述呼叫和连接建立过程后, 在 CCCla对应的 CC 和 CCC4b对应的 CC之间建立了一个由底层域 Domainl、 Domain3和 Domain4 的域内链路和各底层域之间的域间链路构成的业务通道。
上述父或 Domainl 234以及子 i或 Domainl、 Domain3和 Domain4的: t或内 呼叫(或子呼叫)和连接(或子连接)过程与现有技术中规定的一种域内呼 叫和连接过程是基本相同的。 对于父域来说, 只是 SNC的建立过程需由其 子域完成; 而对于子域来说, 特点在于由父域中 CC的 SNC建立请求触发 该呼叫和连接过程, 相应地需向父域的该 CC返回 SNC返回信息。
第二实施例
本实施例的网络结构与第一实施例相同。 下面再结合图 2、 图 4、 图 7 和图 10, 以客户侧网元(:(3<^和 CCC4b之间创建跨域呼叫和连接为例, 说 明只有顶层父域需要呼叫时,建立跨域呼叫和连接的具体实施方案,先只对 呼叫成功的情况进行说明, 包括如下步骤:
步骤 301〜步骤 307与第一实施例的步骤 201~207相同, 此时, NCC1234a 已收到从被叫( 0 413返回的呼叫建立确认,向对应的 CC发送连接建立请求。 该 CC确定连接路由为 NCC1234a对应的 CC——》 NCC1234c †庶的 CC——》 NCC1234d对应的 CC,触发连接建立过程, NCC1234d对应的 CC建立本地 SNC 时, 向子域 Domain4的入口 NCC4a发送 SNC建立请求, 携带呼叫在该子域 的入口和出口资源地址; 步骤 308、 NCC4^ 测到该 SNC建立请求后, 向对应的 CC发送子连接 建立请求,包含域的入口和出口资源地址,即 Domain4的 NCC4a与 Domain3 的 NCC3b、 Domain4的 1^( ( 415与 CCC4b之间的链路;
步骤 309、 NCC4a对应的 CC接收到子连接建立请求后, 根据入口和出 口资源地址确定连接路由, 即图 10所示 NCC4a对应的 CC——》 Domain4 中间的 CC一一》 NCC4b对应的 CC, 并触发子连接建立过程, 路由上最后一 个 NCC即 NCC4b对应的 CC收到子连接指示后建立本地 SNC,并将 SNC建 立请求发送至传送资源平面;
步骤 310、 NCC4b对应的 CC向 Domain4中间的 CC返回子连接建立确 认, 该 Domain4中间的 CC在建立本地 SNC之后, 向 NCC4a对应的 CC返 回子连接建立确认, 该 CC建立本地 SNC, 再将子连接建立确认返回至 NCC4a;
步骤 311、 NCC4a判断本域连接的触发条件是 Domainl234的 CC触发, 向 NCC1234d对应的 CC返回 SNC确认;
步驟 312、 NCC1234d对应的 CC向 NCC1234c对应的 CC返回连接建立确
认;
步骤 313、 NCC1234e对应的 CC收到连接建立确认后,建立本地 SNC时, 将 SNC建立请求发送至与本 CC对应子域 Domain3的入口网元 NCC3a, 携 带呼叫在该子域的入口和出口资源地址;
步骤 314、 NCC3 ^¾到该 SNC建立请求后,完成在域 Domain3的子连 接过程, 其处理与域 Domain4是相同的, 这里不再重复;
步骤 315、 NCC3Jt到对应 CC发送的子连接建立确认后, 判断本域连 接是由 Domainl234的 CC触发, 向 NCC1234e对应的 CC返回 SNC确认; 步骤 316、NCC1234c对应的 CC向 NCC1234a对应的 CC返回连接建立确认; 步骤 317、 NCC1234a对应的 CC收到连接建立确认, 建立本地 SNC时, 将 SNC建立请求发送至与本 CC对应子域 Domainl的入口网元 NCCla, 携 带呼叫在该子域的入口和出口资源地址;
步骤 318、 NCC^ 测到该 SNC建立请求后,完成在域 Domainl的子连 接过程, 其处理与域 Domain4是相同的, 这里不再重复;
步骤 319、 NCCla收到对应 CC发送的子连接建立确认后, 判断本域连 接是由 Domainl234的 CC触发, 向 NCC1234a对应的 CC返回 SNC确认; 步骤 320、 NCC1234a对应的 CC向 NCC1234a返回连接建立确认, NCC1234a 通过 Domainl的 ^( (:13向 CCCla返回呼叫建立确认, 跨域呼叫和连接建立 完成。
本实施例与第一实施例的差别在于, 父域 NCC建立 SNC的过程中, 子 域的入口 NCC收到 SNC建立请求后, 不再发起子呼叫, 而是直接向其对应 的 CC发送子连接建立请求, 其它处理都是一样的。
上述两个实施例中, 父域或子域的入口 NCC对应的 CC在触发连接或 子连接建立过程之前,也可以先校验连接请求参数是否合法以及本域是否满 足参数所描述的条件, 如是, 再执行连接或子连接建立过程。
第三实施例
本实施例的网络结构与笫一实施例相比, 差别在于各子域和父域的
ASON域的网元可以没有呼叫控制器 NCC。
下面, 再结合图 5、 图 8和图 11 , 以客户侧网元 031&和€( 41)之间创建 跨域连接为例,说明本实施例在不需要呼叫时,建立跨域连接的具体实施方 案, 先只对呼叫成功的情况进行说明, 包括如下步骤:
步骤 401、 子域 Domainl的入口网元的连接控制器 CCla检测到客户侧 网元的连接控制器 1¾£1 ( ( ¼发送来的 "连接建立请求" ;
步骤 402、 CCla根据请求参数判断出此连接在本域(子域 Domainl )层 面是跨域连接, 之后, 向父域 Domainl234的入口网元(即该子域在父域对 应的网元)的连接控制器 0 123½传递该连接建立请求;
步骤 403、 CC1234a检测到该连接建立请求后, 判断出是本域呼叫, 先校 验连接请求参数是否合法以及本域(父域 Domainl234 )是否满足参数所描 述的条件,如果是,再根据参数中携带的源资源地址(即 Domainl234与 USER CCla之间的逻辑链路 )和目的资源地址(即 Domainl234与 USER 0:4]3之 间的逻辑链路)确定连接路由并触发连接建立过程, 该连接路由如图 11所 示, 为 CCi234a—一》 CC1234c—―》 CC画, CC1234a生成连接协调信息
( Connection Coordination )经中间的 CC〗234c传递至出口 CC1234d;
如果网络为三层以上结构且 NCC1234a判断还是跨域连接,则会继续向其 父域的入口网元传递该 "连接建立请求" 。
连接(不包括 SNC建立过程中子域的子连接)在各个域的出口 CC即 该域中与被叫 CC之间有链路相连的 CC。
步驟 404、 CC1234d在收到 CC1234a方向传送来的连接协调信息后,判断所 属域(父域 Domainl234 )与源及目的 USER CC ( USER ( 0^和 USER CC4b ) 相关资源都相连, 则根据接收的连接协调信息, 生成连接指示信息 ( Connection Indication ) , 通过子域 Domain4 的出口 CC4b传递到用户侧 USER CC4b;
步骤 405、 CC4b检测到用户侧返回的连接建立确认 ( Connection
Confirmed )后, 判断出该连接在本域( Domain4 )层面是跨域呼叫, 将传递 到父域 Domainl234的对应网元 CC1234d;
步骤 406、(3( 1234<1收到连接建立确认后,触发本地 SNC的建立,将 SNC 建立请求( SNC Request )发送至本 CC对应子域 Domain4的入口 CC4a, 携 带该子域的入口和出口资源地址, 分别为父域连接路由上与该 CC1234d相连 的入口链路(靠近主叫侧)和出口链路(靠近被叫侧的链路);
步骤 407、 。(: 收到后, 先校验连接请求参数是否合法以及本域是否满 足参数所描述的条件,如果是,根据所述入口和出口资源地址确定连接路由, 即图 11所示 CC4a—―》 Domain4中间的 CC (可能不存在)一一》 CC4b, 并 触发子连接建立过程, CC4b在收到子连接指示(Sub— Connection Indication ) 后,判断所属域没有同时与源及目的用户 CC相关资源相连,建立本地 SNC, 并将 SNC建立请求发送至传送资源平面;
连接在该子域的入口和出口资源相连的 CC分别为该子域的入口和出口 步骤 408、 CC4b向 Domain4 中间的 CC 返回子连接建立确认
( Sub— Connection Confirmed ) , 该 CC在建立本地 SNC之后, 将子连接建 立确认传送至 CC4a, 该 3( ¼建立本地 SNC;
步骤 409、 CC4a判断本域子连接是 Domainl234的 CC1234d触发的, 向 CC1234d返回 SNC确认;
步骤 410、 CCi234d向 CC1234c返回连接建立确认( Connection Confirmed ); 步骤 411、 CC1234e接收到连接建立确认后, 触发并完成本地 SNC的建 立,将 SNC建立请求发送至与本 CC对应子域 Domain3的入口 CC3a,该 CC3a 按与域 Domain4相同的方式完成域 Domain3内的子连接建立过程;
步骤 412、 0 收到返回的连接建立确认并完成本地 SNC建立后, 判 断本域子连接是由 Domainl234的 CC1234c触发, 向 CC1234c返回 SNC确认; 步骤 413、 CC1234c向 CC1234a返回连接建立确认;
步驟 414、 CC1234 ~收到连接建立确认,触发本地 SNC的建立,将 SNC 建立请求发送至与本 CC对应子域 Domainl 的入口 CCla, 该 CCla按与域
Domain4相同的方式完成域 Domainl内的子连接建立过程;
步骤 418、 CCla收到返回的子连接建立确认并完成本地 SNC建立后, 判断本域子连接是由 Domainl234的 CC1234a触发,向 CC1234a返回 SNC确认; 步骤 419、 CC1234a通过 0^向 USER CCla返回连接建立确认, 该次跨 域连接建立结束。
这个实施例父域或子域的域内连接的处理与现有技术基本是相同的,只 是父域中 CC建立本地 SNC的具体实现不同。
上述 3个实施例中只提到了呼叫或连接成功的情况,发生以下任一情形 时, 都将导致整个呼叫或连接过程失败:
A, 域的入口 NCC (或 CC )校验呼叫 (或连接, 包括 SNC )请求参数 不合法。
B, 域的入口 NCC (或 CC )判断本域不满足呼叫(或连接, 包括 SNC ) 请求参数描述的条件。
C, 各 CC之间连接建立失败。
D, 各 NCC间呼叫建立失败。
E, 各 CC或 NCC内部处理失败。
失败的情况不并仅限于以上情形,在呼叫或连接过程中的任何一步操作 失败时, 当前的 NCC或 CC立即停止后续处理, 如连接、 呼叫 (包括子连 接和子呼叫)过程,将连接处理失败信息返回到请求其进行呼叫或连接处理 的前一级 NCC或 CC, 该 CC再直接向前一级网元返回失败信息, 直到将该 失败信息返回到主叫侧 CC。 父域或子域的 NCC或 CC收到失败信息后, 直 接向前一级返回失败信息, 不进行连接或本地 SNC的建立或其它处理。
此外, 在本发明中, 除上面已经描述的跨域呼叫与连接的建立外, 还包 括跨域呼叫与连接的修改和删除。 关于跨域呼叫与连接修改、删除的实施方 案, 与上文所述的跨域呼叫和连接建立的实施方案基本相同。只需要将上述 实施方案中的关于呼叫、 子呼叫、 连接、 子连接以及 SNC的 "建立" , 改 为 "修改"或 "删除" , 就是本发明关于跨域呼叫与连接修改或删除的实施
方案。
在另一实施例中, 在第二实施例的基 上, 在父域 CC建立本地 SNC 连接时,也可以直接向对应子域的入口 CC发送 SNC建立请求, 由该 CC触 发完成本域的子连接过程, 而不再象第二实施例那样, 先向该子域的入口 NCC发 SNC请求, 由该 NCC向对应 CC发子连接建立请求。
从上面具体实施方式分析可知, 本发明实施方案通过在已有 ASON域 的基础上引入父域,将一个跨域的呼叫与连接控制的复杂问题分解为父域和 各子域内的呼叫和连接的控制问题, 最终解决跨域呼叫与连接的控制问题, 具备筒洁、 可靠的优点。
工业实用, |·生
本发明可用于 ASON 网络, 将一个跨域的呼叫与连接控制复杂问题分 解为各个父域和子域分别完成呼叫和连接的控制的问题, 最终 ASON 网络 实现跨域呼叫与连接控制。
Claims
1、 一种交换光网络跨域连接的控制方法, 先构建一个包括父域和子域 的多层网络结构,所述父域中至少有一个网元对应一个子域且可与该子域的 网元通信, 父域网元配置有对应子域中网元的参数,子域的边界链路即为对 应父域网元的输入输出链路,没有子域的光网络域称为底层域,各网元中均 包含连接控制器 CC, 在一次成功的跨域连接处理中, 包括如下步骤:
( a )底层域 Ddi的入口连接控制器 CCdi收到主叫侧连接控制器 CCC 连接处理请求且判断为跨域连接后, 将该请求上传至与( ^^和被叫侧 ccc2 资源均相连的父域 Dft中与域 Ddi对应的入口 CC fi;
( b ) CCfi根据该请求中的源和目的资源地址确定连接路由 Lft, 将连接 协调信息发送到出口 CCf。, CC f0收到后向对应底层域 D d。与被叫侧 CCc2资 源相连的出口 CCd。发送连接指示信息, CCd。将该信息传递至 CCc2;
( c ) CCd0收到 CCe2的连接处理返回信息后, 将其传递到父域 D ft的出 口 CCf。,从 CCf。开始,路由 Lft上每一个 CCf依次完成对本地子网连接 SNC 的处理, 向前一级 CC返回成功信息, 直到 CCfi; '
有对应子域的父域 CCf进行本地 SNC处理时, 需在子域 Dz完成对本域 入口和出口资源地址之间的子连接的处理;
( d ) CCfi完成本地 SNC后,通过底层域 Ddi的入口 CCdi向主叫侧 CCcl 返回连接处理成功的信息, 跨域连接结束。
2、 如权利要求 1所述的控制方法, 其特征在于:
所述步骤( c )有对应子域的父域 CCf进行本地 SNC处理时 , 执行以下 步骤:
( cl ) CCf向对应子域 Dz中与该子域入口资源相连的入口 CC 发送子 网连接 SNC处理请求, 携带子域。2的入口和出口资源地址, 即父域连接路 由上该 CCf的入口链路和出口链路;
( c2 ) CCzi收到 SNC处理请求后, 根据所述入口和出口资源地址确定 子连接路由 Lz并触发本域的子连接处理过程;
( c3 )完成子域 Dz内的子连接处理后, CCzi判断该子连接处理过程是 由父域的 CCf触发的, 向该 CCf返回 SNC确认, 结束父域 CCf的本地 SNC 处理;
在上述子连接处理过程中, 子连接路由 Lz上的 CC进行本地 SNC处理 时, 如该 CC也有对应子域, 则也将其作为父域 CCf , 按上述步骤(cl )〜 ( c3 )进行本地 SNC处理。
3、 如权利要求 1所述的方法, 其特征在于:
父域 Dft和底层域 Ddi之间还有其它的光网络域,所述底层域的入口 CCdi 和父域 Dft中的入口 CCfi之间, 以及底层域的出口 CCd。和父域 Dft中的出口 CC f。之间的消息都是逐层传递的, 其中每一子域的 CC在判断是跨域连接 时, 都将消息传递到其父域中与该子域对应的 CC, 每一父域的 CC都将消 息传递到其对应子域中与源或目的资源地址相连的 cc。
4、 如权利要求 2所述的方法, 其特征在于:
所述父域或子域中连接路由上的最后一个 CC在收到连接协调信息或连 接指示信息时,先判断本域是否与主叫侧 CCel和被叫侧 CCc2都相连,如是, 将连接指示信息传递到底层域 D d。与 CCe2资源相连的出口 CCd。, 否则, 进 行本地 SNC处理, 再向前一级 CC返回处理结果的信息。
5、 如权利要求 2所述的方法, 其特征在于:
所述父域 Dft中的入口 CCfi收到连接处理请求, 或者子域中的入口 CCzi 收到 SNC连接处理请求时, 先校验请求参数是否合法以及本域是否能够满 足参数所描述的条件, 如果是, 再进行后续的连接处理, 否则, 直接返回连 接处理失败的信息。
6、 如权利要求 1至 5中任一权利要求所述的方法, 其特征在于, 所述步骤(a ) ~ ( d )的跨域连接处理过程中, 任一操作失败后, 立即 停止后续的连接处理, 并由当前 CC将连接处理失败信息返回到请求其进行 连接处理的前一级 CC, 该 CC再直接向前一级 CC返回失败信息, 直到将 该失败信息返回到主叫侧 CC。
7、 如权利要求 1至 5中任一权利要求所述的方法, 其特征在于:
所述连接处理、子连接处理和 SNC处理为连接建立、子连接建立和 SNC 建立; 或者, 所述连接处理、 子连接处理和 SNC处理为连接修改、 子连接 修改和 SNC修改; 或者, 所述连接处理、 子连接处理和 SNC处理为连接删 除, 子连接删除和 SNC删除。
8、 一种交换光网络跨域呼叫和连接的控制方法, 先构建一个包括父域 和子域的多层网络结构,所述父域中至少有一个网元对应一个子域且可与该 子域的网元通信, 父域网元配置有对应子域中网元的参数,子域的边界链路 即为对应父域网元的输入输出链路,没有子域的光网络域称为底层域,各网 元中均包含网络侧呼叫控制器 NCC和连接控制器 CC,在一次成功的跨域呼 叫和连接处理中, 包括如下步骤:
( A )底层域 Ddi的入口呼叫控制器 NCCdi收到主叫侧呼叫控制器 CCCcl 的呼叫处理请求且判断为跨域呼叫后, 将该请求上传至与 ( ^^和被叫侧 CCCc2资源均相连的父域 Dft中与域 Ddi对应的入口 NCCfi;
( B ) NCC fi向本域中与所述目的资源地址相连的出口 NCCf。发送呼叫 协调信息, NCC f0收到后向对应子域 D d0与被叫侧 CCCc2资源相连的出口
NCCd0发送呼叫指示信息, NCCd。再将该指示信息发送至被叫侧 CCCe2;
( C ) NCCd。收到被叫侧 CCCc2的呼叫确认后,经父域 Dft的出口 NCCf。 传递至入口 NCCfi, NCCfi向本网元的连接控制器 CCfi发送连接处理请求, 携带父域 Dft的入口和出口资源地址;
( D ) CCfi根据 Dft的入口和出口资源地址确定连接路由 Lft并触发本域 的连接处理过程, 在该过程中, 路由 Lft上有对应子域的每一父域 CCf进行 本地子网连接 SNC处理时, 需在该子域完成对本域入口和出口资源地址之 间的子连接的处理, 并向 CCf返回 SNC确认;
• ( E ) CC fi向 NCCfi返回连接确认, NCCfi通过底层域 Ddi的入口 NCCdi 向主叫侧(^(^(^返回呼叫确认, 结束。
9、 如权利要求 8 所述的控制方法, 其特征在于: 所述步骤(D ) CCf 是通过以下步骤完成本地 SNC处理:
( Dl )CCf向对应子域 Dz中与该子域入口资源相连的入口 C ^发送 SNC
处理请求, 携带该子域 Dz的入口和出口资源地址, 即连接路由上该 CCf的 入口链路和出口链路;
( D2 ) CC^收到 SNC处理请求后 , 根据所述入口和出口资源地址确定 子连接路由 Lz并触发本域的子连接处理过程;
( D3 )完成子域 Dz内的子连接处理后, CQi判断该子连接处理过程是 由父域的 CCf触发的, 向该 CCf返回 SNC确认, 结束父域 CCf的本地 SNC 处理;
在子连接处理过程中, 子连接路由 Lz上的 CC进行本地 SNC处理时, 如该 CC也有对应子域, 则也将其作为父域 CCf ,按上述步骤( Dl ) ~ ( D3 ) 进行本地 SNC处理。
10、 如权利要求 8所述的控制方法, 其特征在于: 所述步骤(D ) CCf 是通过以下步骤完成本地 SNC处理:
( Dl ) CCf向对应子域 Dz中与该子域入口资源相连的入口 NCC^发送 SNC处理请求,携带该子域 Dz的入口和出口资源地址,即连接路由上该 CCf 的入口链路和出口链路;
( D2 ) NCCzi收到该 SNC请求后, 向对应的 CQi发送子连接处理请求, 携带子域02的入口和出口资源地址;
( D3 ) CC2i收到子连接处理请求后,根据所述入口和出口资源地址确定 子连接路由 Lz并触发本域的子连接处理过程;
( D4 )完成子域 Dz内的子连接处理后, 0^向 NCCd返回子连接确认,
NCCzi判断该子连接处理过程是由父域的 CCf触发的, 向该 CCf返回 SNC 确认, 结束父域 CCf的本地 SNC处理;
在上述子连接处理过程中, 子连接路由 Lz上的 CC进行本地 SNC处理 时, 如该 CC也有对应子域, 则也将其作为父域 CCf , 按上述步骤(Dl ) ~ ( D4 )进行本地 SNC处理。
11、 如权利要求 8所述的控制方法, 其特征在于: 所述步骤(D ) CCf 是通过以下步骤完成本地 SNC处理:
( Dl ) CCf向对应子域 Dz中与该子域入口资源相连的入口 NCCzi发送
SNC处理请求,携带该子域 Dz的入口和出口资源地址,即连接路由上该 CCf 的入口链路和出口链路;
( D2 )NCCzi收到该 SNC请求后,向与本域出口资源相连的出口 NCCZ。 发送子呼叫协调信息, NCCZ。向 NCQi返回子呼叫确认, NCQi再向对应的 0^发送子连接处理请求, 携带子域。2的入口和出口资源地址;
( D3 ) CCzi收到子连接处理请求后,根据所述入口和出口资源地址确定 子连接路由 Lz并触发本域的子连接处理过程;
( D4 )完成子域02内的子连接处理后, COi向 NCCzi返回子连接确认, NCCri判断该子连接处理过程是由父域的 CCf触发的, 向该 CCf返回 SNC 确认, 结束父域 CCf的本地 SNC处理;
在上述子连接处理过程中, 子连接路由 Lz上的 CC进行本地 SNC处理 时, 如该 CC也有对应子域, 则也将其作为父域 CCf , 按上述步骤(Dl ) ~ ( D4 )进行本地 SNC处理。
12、 如权利要求 8所述的方法, 其特征在于:
父域 Dft和底层域 Ddi之间还有其它的光网络域, 所述底层域的入口
NCCdi和父域 Dft中的入口 NCC fi之间, 以及底层域的出口 NCCd。和父域 Dft 中的出口 NCCf。之间的消息都是逐层传递的, 其中每一子域的 NCC在判断 是跨域连接时, 都将消息传递到其父域中与该子域对应的 NCC, 每一父域 的 NCC都将消息传递到其对应子域中与源或目的资源地址相连的 NCC。
13、 如权利要求 8或 11所述的方法, 其特征在于:
所述父域或子域中的出口 NCC在收到呼叫或子呼叫的协调信息时, 先 判断本域是否与主叫侧(^(^和被叫侧 CCCc2都相连,如是,将呼叫指示信 息传递到底层域 Dd。的出口 NCCd。, 否则, 向本域的入口 NCCzi返回子呼叫 确认。
14、 如权利要求 8、 10或 11所述的方法, 其特征在于:
所述父域 Dft的入口 NCCfi收到连接处理请求,或者子域中的入口 NCCzi 收到 SNC处理请求时, 先校验请求参数是否合法以及本域是否能够满足参 数所描述的条件, 如果是, 再进行后续的连接处理, 否则, 直接返回呼叫失
败或 SNC处理失败的信息。
15、 如权利要求 8至 14中任一权利要求所述的方法, 其特征在于, 所述步骤( A )〜( E )的跨域呼叫和连接处理过程中,任一操作失败后, 立即停止后续的呼叫或连接处理, 并由当前 NCC或 CC将呼叫或连接处理 失败信息返回到请求其进行呼叫或连接处理的前一级 NCC或 CC, 该 NCC 或 CC再直接向前一级 NCC或 CC返回失败信息, 直到将该失败信息返回 到主叫侧 CCC。
16、 如权利要求 8至 14中任一权利要求所述的方法, 其特征在于: 所述呼叫处理、 子呼叫处理、 连接处理、 子连接处理和 SNC处理指呼 叫建立、 子呼叫建立、 连接建立、 子连接建立和 SNC建立; 或者指呼叫修 改、 子呼叫修改、 连接修改、 子连接修改和 SNC修改; 或者指呼叫删除、 子呼叫删除、 连接删除, 子连接删除和 SNC删除。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP06791036.4A EP1983689A4 (en) | 2006-01-28 | 2006-09-19 | MANAGEMENT METHOD FOR TRANSDOMATIC COMMUNICATION AND CONNECTION OF AUTOMATICALLY SWITCHED OPTICAL NETWORK |
US12/161,741 US8050277B2 (en) | 2006-01-28 | 2006-09-19 | Control method for the cross-domain call and the connection of ASON |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNB2006100029236A CN100512192C (zh) | 2006-01-28 | 2006-01-28 | 自动交换光网络跨域呼叫和连接的控制方法 |
CN200610002923.6 | 2006-01-28 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2007085152A1 true WO2007085152A1 (fr) | 2007-08-02 |
Family
ID=38308844
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/CN2006/002444 WO2007085152A1 (fr) | 2006-01-28 | 2006-09-19 | Procédé de gestion pour communication transdomaine et connexion du réseau optique à commutation automatique |
Country Status (4)
Country | Link |
---|---|
US (1) | US8050277B2 (zh) |
EP (1) | EP1983689A4 (zh) |
CN (1) | CN100512192C (zh) |
WO (1) | WO2007085152A1 (zh) |
Families Citing this family (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2008064518A1 (en) * | 2006-11-28 | 2008-06-05 | Zte Corporation | A united route query method in the automatic switched optical network |
CN101668001B (zh) * | 2008-09-05 | 2012-07-04 | 华为技术有限公司 | 一种建立域间呼叫的方法、系统及装置 |
CN101729936B (zh) * | 2008-10-30 | 2014-04-09 | 中兴通讯股份有限公司 | 自动交换光网络连接修复方法及路由域 |
CN101820410B (zh) * | 2009-02-27 | 2014-06-11 | 华为技术有限公司 | 一种呼叫处理方法、系统及装置 |
CN102202247B (zh) * | 2010-03-25 | 2015-07-22 | 中兴通讯股份有限公司 | 一种基于g.709的多级复用的信令控制方法和系统 |
US8553707B2 (en) | 2011-03-01 | 2013-10-08 | Ciena Corporation | Administrative boundaries in single or multiple domain optical networks |
CN103401720B (zh) * | 2013-08-14 | 2016-05-25 | 武汉邮电科学研究院 | 一种自动交换光网络中业务分层的方法 |
US9237090B2 (en) | 2014-05-16 | 2016-01-12 | Ciena Corporation | Network routing systems and methods for validation of paths subsequent to validation failure |
CN118740897A (zh) * | 2023-03-31 | 2024-10-01 | 中兴通讯股份有限公司 | 连接建立方法、通信设备及存储介质 |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1598982A1 (en) * | 2004-05-20 | 2005-11-23 | Alcatel | Architecture for configuration and management of cross-domain services |
CN1710868A (zh) * | 2005-07-14 | 2005-12-21 | 广东省电信有限公司研究院 | 自动交换光网络中主备保护的跨域端到端连接的建立方法 |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6141325A (en) * | 1996-12-18 | 2000-10-31 | International Business Machines Corporation | Paradigm for enabling interoperability between different subnetworks |
JP2003143145A (ja) * | 2001-10-31 | 2003-05-16 | Nec Corp | 障害回復方法およびパス設定方法および通信ネットワーク並びにそれに用いる集中制御装置およびノード装置 |
US20030233456A1 (en) * | 2002-06-14 | 2003-12-18 | Nortel Networks Limited | Communication between call controllers by amending call processing messages |
US7215644B2 (en) * | 2003-03-19 | 2007-05-08 | Alcatel Lucent | Inter-domain constraint-based shortest path first technique for supporting hierarchical routing in interconnected multi-domain optical transport networks |
US7443831B2 (en) * | 2003-10-03 | 2008-10-28 | Nortel Networks Limited | Call control using a layered call model |
-
2006
- 2006-01-28 CN CNB2006100029236A patent/CN100512192C/zh not_active Expired - Fee Related
- 2006-09-19 US US12/161,741 patent/US8050277B2/en not_active Expired - Fee Related
- 2006-09-19 EP EP06791036.4A patent/EP1983689A4/en not_active Withdrawn
- 2006-09-19 WO PCT/CN2006/002444 patent/WO2007085152A1/zh active Application Filing
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1598982A1 (en) * | 2004-05-20 | 2005-11-23 | Alcatel | Architecture for configuration and management of cross-domain services |
CN1710868A (zh) * | 2005-07-14 | 2005-12-21 | 广东省电信有限公司研究院 | 自动交换光网络中主备保护的跨域端到端连接的建立方法 |
Non-Patent Citations (2)
Title |
---|
CHEN Y. AND XU Y.: "CURRENT ADVANCE INTRODUCTION OF ASON STANDARD, TELECOMMUNICATIONS NETWORK TECHNOLOGY", no. 3, 2005, XP008167690 * |
See also references of EP1983689A4 * |
Also Published As
Publication number | Publication date |
---|---|
EP1983689A1 (en) | 2008-10-22 |
US20100226647A1 (en) | 2010-09-09 |
US8050277B2 (en) | 2011-11-01 |
CN100512192C (zh) | 2009-07-08 |
EP1983689A4 (en) | 2016-09-28 |
CN101009626A (zh) | 2007-08-01 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
WO2007085152A1 (fr) | Procédé de gestion pour communication transdomaine et connexion du réseau optique à commutation automatique | |
US9705590B2 (en) | Joint IP/optical layer restoration after a router failure | |
US8300625B2 (en) | Call control using a layered call model | |
WO2007071189A1 (fr) | Procede et dispositif de restauration d'un reseau maille partage | |
JP5200481B2 (ja) | 接続変更のためのシステム及び方法 | |
JP2007500955A (ja) | 伝送ネットワークにおける固定接続及び相手先選択接続間の移行のための方法 | |
CN101176303A (zh) | 一种业务倒换的方法和网络节点 | |
US20110238849A1 (en) | Method and device for establishing network connection service, and automatically switched optical network | |
WO2004032434A9 (ja) | 伝送システム | |
WO2007079649A1 (fr) | Procede et dispositif de decouverte automatique pour liaison de couche client | |
WO2010028586A1 (zh) | 一种有阻边界节点及有阻边界节点间建立连接的方法 | |
CN101572835A (zh) | 层次化有序地址分组网络中数据链路层信息传送和控制管理的方法及装置 | |
WO2008064518A1 (en) | A united route query method in the automatic switched optical network | |
CN101133601B (zh) | 自动交换传送网络中的复杂控制节点及其控制方法 | |
EP2395773B1 (en) | Method and apparatus of sub-network connection protection (sncp) service migration | |
WO2007073618A1 (fr) | Procede et dispositif de commande de connexion utilises dans un service de multidiffusion d'un reseau optique a commutation automatique | |
WO2007115435A1 (fr) | Procédé de détection automatique de topologie d'entité de contrôle dans le réseau optique commuté automatique | |
US20070220085A1 (en) | Control channel discovery protocol | |
KR20140092690A (ko) | 다 계층 네트워크에서의 경로 정보 동기화 방법 및 그 장치 | |
CN117956325A (zh) | 一种自动交换光网络中业务防误删除方法及装置 | |
Aboul-Magd et al. | 1. Document Summary | |
Chen et al. | The research of automatic neighbor discovery in all-optical intelligent network | |
Rico et al. | Policy approach to managing WDM networks |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
WWE | Wipo information: entry into national phase |
Ref document number: 12161741 Country of ref document: US |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2006791036 Country of ref document: EP |
|
NENP | Non-entry into the national phase |
Ref country code: DE |