AU5202200A - Multilevel precedence and pre-emption in a call and bearer separated network - Google Patents

Description

WO 00/79742 PCT/AUO0/00695 1 MULTILEVEL PRECEDENCE AND PRE-EMPTION IN A CALL AND BEARER SEPARATED NETWORK FIELD OF INVENTION The present invention relates to signaling in a telecommunications system. 5 More particularly, the invention relates to standardising signalling over multi-vendor telecommunication infrastructures. BACKGROUND TO THE INVENTION For cost-efficiency reasons telecommunication operators are increasingly deploying non-STM transport technologies (e.g. ATM, IP, FR, etc) inside their 10 networks and, therefore, requiring a standardised solution to support existing services of today's public telecommunication networks over multi-vendor non-STM infrastructures. In the current public telecommunication networks the call control (CC) and bearer control (BC) are tightly coupled in the same public network protocol (e.g. 15 ISUP) see figure la. As a result of this trend to run over multi-vendor non-STM infrastructures a new network architecture has been developed that requires the splitting of call control (CC) and bearer control (BC) into separate protocols see figure 1b. Figures 1 a and 1 b show the evolution from current integrated CC/BC public 20 network protocols (e.g. ISUP) (figure 1a) to the separated CC/BC solution (figure 1b). Referring to figure 1a, in current public NNI protocols: call and bearer control are integrated inside the same protocol, i.e. each node in the network must have call and bearer control capabilities. Referring to figure 1 b in separated CC and BC: call and bearer control are performed by different protocols. A single CC protocol is 25 needed for the various transport technologies (e.g. ATM, IP, etc.). Only some nodes (e.g. nodes at the edge of a network) need to couple the CC and BC, for instance for a specific call, other nodes, only need BC capabilities (e.g. transit nodes inside an operator's network). As a result of the split of CC and BC, a new interface is required between 30 the CC function and BC function. A new protocol is also thus required to enable coupling between the CC and BC functions when a node is implemented in a WO 00/79742 PCT/AUOO/00695 2 separated environment. The common term for this protocol is a 'Media Gateway Control Protocol', and which is being developed by ITU Study Group 16 (H.248, previously known as H.GCP) (reference: ITU-T H.248, Gateway Control Protocol) and in IETF MEGACO (MGCP) working group (reference: IETF < RFC2805> 5 Media Gateway Control protocol architecture and requirements). In ITU Study Group 16 and IETF MEGACO, the CC function is known as 'Media Controller (MC)' and the BC function is known as 'Media Gateway (MG)'. Figure 2 shows a Media Gateway Control Protocol in separated CC & BC Architecture. The Media Gateway Control Protocol describes resources in the BC 10 function in terms of contexts and terminations. Terminations can be reserved and used at a later time. A termination represents a physical endpoint and can be assigned different characteristics, for example: the transport type (Circuit, IP, ATM) media or codec type (GSM, G.711) 15 priority A context groups a number of terminations to describe a path or call through the BC function. One of the services that runs in ISUP based public communications networks (figure 1a) is Multilevel Precedence and Pre-emption (MLPP). This 20 service needs to be supported by separated CC & BC networks also. (See reference: ITU-T Q.735.3, Description for Community of Interest Supplementary Services - Multilevel precedence and pre-emption.) In today's public telecommunications networks based on ISUP, the MLPP information, which has two parts - precedence and pre-emption, is signalled in 25 Initial Address Messages (IAM), Release Message (REL), Address Complete Message (ACM) and Call Progress Message (CPG). The Precedence parameter is used to identify the precedence level, the network and MLPP service domain, and whether a path has been reserved or path reservation is allowed. In prior art arrangements, this is handled at the CC level. 30 In the new architecture of separated CC and BC, the MLPP information needs to be also implemented partly at the CC and BC level. If the BC level WO 00/79742 PCT/AUOO/00695 3 implements the functionality that is required for MLPP, the Media Gateway Control Protocol needs to be updated to carry to the MLPP information between the CC and BC functions. Whilst the Media Gateway Control Protocol today allows a termination to be 5 reserved and assigned and a priority given, however, it does not have the capability to: - express that a reserved termination is for 'pre-emption reserved for reuse' - express that a termination belongs to an MLPP service domain - express that a termination belongs to a certain 'Network Identity' 10 Without the ability to express these parameters, the BC function is considered not able to implement the necessary functionality for the MLPP supplementary service to operate in a separated BC and CC network. This may lead to problems like: Resources freed by the MLPP pre-emptive service could be seized by 15 another call process rather than being used by MLPP thus leading to failure of the MLPP service. - Resources not belonging to a MLPP service domain may be freed leading to non-related calls in another domain being terminated, all of which are considered undesirable. 20 An object of the present invention is to alleviate at least one disadvantage of the prior art arrangement. SUMMARY OF THE PRESENT INVENTION To this end, the present invention provides a method of operating a MLPP supplementary service in a separated BC and CC network, in which there is 25 provided in the BC functionality, at least one of the following properties: a) an indication of the termination's membership of a domain or group (i.e. MLPP service domain) b) an indication of why a termination is reserved (e.g. pre-emption - reserved for reuse) 30 c) an indication of which network a termination is assigned (e.g. Network Identity) WO 00/79742 PCT/AUOO/00695 4 Preferably, the properties are additional termination properties. The present invention also provides a separated Call Control (CC) and Bearer Control (BC) network, operating a MLPP supplementary service, which includes a means of implementing BC functionality having context and termination, 5 a first indicating means to indicate membership of a domain or group by the termination, a second indicating means to indicate why the termination is reserved, and a third indicating means to indicate to which network the termination is assigned. 10 Preferably, the network above is used in conjunction with a TICC Transport Independent Call Control or more aptly, BICC Bearer Independent Call Control protocol. In one form, the present invention may be implemented in a UMTS core network. The present invention is based on the realisation that in a new separated 15 architecture, because the CC and BC are split, there is a requirement to provide additional properties, such as termination properties. A further realisation is that in a gateway, the signalling information including protocols can be interworked to a new protocol or the protocol may be transferred through the gateway. Thus, the invention stems from recognising that, in interworking or transferring, a number 20 (one or more), commands can be added to enable provision of certain desired properties. Further, the Media Gateway Control Protocol describes several commands to create, modify, subtract and query the properties associated with a termination and/or context. To ensure correct operation of the MLPP supplementary services additional termination properties such as the following can 25 be added: An indication of the termination's membership of a domain or group (i.e. MLPP service domain) An indication of why a termination is reserved (e.g. pre-emption reserved for reuse) 30 An indication of which network a termination is assigned (e.g. Network Identity) WO 00/79742 PCT/AUOO/00695 5 - Preferably, the invention can be implemented by way of the following Media Gateway Control Protocol API type commands: - Add 5 Modify - Subtract - Move - Audit - Notify 10 ServiceChange In the present specification, we refer to CC and BC being 'separated'. By separated, we mean separating the functionality of the CC and BC. The separation can be physical or logical. BRIEF DESCRIPTION OF DRAWINGS 15 A preferred embodiment of the present invention will now be described with reference to the accompanying drawings, in which: Figure 1a illustrates a public network configuration in which call control (CC) and bearer control (BC) protocols are tightly coupled, Figure 1b illustrates a network configuration that allows for splitting of call 20 control(CC) and bearer control (BC) into separated protocols, Figure 2 illustrates a Media Gateway Control Protocol in a separated CC & BC architecture, and Figure 3 illustrates H.248 connection model highlighting Terminations and Contexts. 25 DETAILED DESCRIPTION OF CERTAIN EMBODIMENTS As previously described, as a result of the split of CC and BC, a new interface is exposed between the CC function and BC function. A protocol is required to enable coupling between the CC and BC functions when a node is implemented in a separated environment. The common term for this protocol is a 30 'Media Gateway Control Protocol'. Figure 2 shows a Media Gateway Control Protocol in separated CC and BC Architecture.

WO 00/79742 PCT/AUOO/00695 6 The Media Gateway Control Protocol describes resources in the BC function in terms of context and termination. Terminations can be reserved and used at a later time. A termination represents a physical endpoint or resource and can be assigned different characteristics, for example: 5 the transport type (Circuit, IP, ATM) - media or codec type (GSM, G.71 1) - priority A context groups a number of terminations to describe a path or call through the BC function. A context is an association between a number of terminations. 10 The context describes the topology (who hears/sees whom) and the media mixing and/or switching parameters if more than two terminations are involved in the association. There is a special context called the null context. It contains terminations that are not associated to any other terminations. Terminations in the null context can have their parameters examined or modified, and may have events 15 detected on them. In general, an Add command is used to add terminations to contexts. If the MGC Media Gateway Controller does not specify an existing context to which the termination is to be added, the MG Media Gateway creates a new context. A termination may be removed from a context with a Subtract command, and a termination may be moved from one context to another with a 20 Move command. A termination exists in one and only one context at a time. The maximum number of terminations in a context is a MG property. Media gateways that offer only point-to-point connectivity might allow at most two terminations per context. Media gateways that support multipoint conferences might allow three or more terminations per context. 25 The attributes of contexts are: - Context ID; - The topology (who hears/sees whom) The topology of a context describes the flow of media between the terminations within a context. In contrast, the mode of a termination 30 (send/receive/...) describes the flow of the media at the ingress/egress of the media gateway.

WO 00/79742 PCT/AUOO/00695 7 - The priority is used for a context in order to provide the MG with information about a certain precedence handling for a context. The MGC can also use the priority to control autonomously the traffic precedence in the MG in a smooth way in certain situations (e.g. restart), when a lot of contexts must 5 be handled simultaneously. - An indicator for an emergency call is also provided to allow a preference handling in the MG. Thus the attributes of a Context may imply certain termination properties. Figure 3 illustrates three possible services of a connection model suitable for 10 the protocol of figure 2 and is not meant to be an all-inclusive illustration. The asterisk box in each of the contexts represents the logical association of terminations implied by the context. The connections illustrated by paths A, B, C represent, for example, a conference with a 3 party communication. The scenario of paths D & E represent, for example, call hold and the scenario of paths F & G 15 represent a 2 party communication. The examples are not the only scenarios applicable to figure 3 as would be understood by those skilled in the art. The Multilevel Precedence and Pre-emption (MLPP) service needs to be supported by separated CC and BC networks also. Reference to ITU-T .735.3, Description for Community of Interest Supplementary Services - Multilevel precedence and pre 20 emption can be made in this regard. The Multilevel Precedence and Pre-emption (MLPP) supplementary service provides a prioritised call handling service. This service has two parts - precedence and pre-emption. Precedence involves assigning a priority level to a call. Pre-emption involves the seizing of resources, which are in use by a call of a lower precedence, by a higher level precedence call 25 in the absence of idle resources. Users in networks that do not support this service will not be affected by this service. The MLPP service is provided as a network provider's option to a domain of a network. The domain can be the whole network or a subset of the network. The MLPP service applies to all network resources in the domain that is in common 30 use. The maximum precedence level of a subscriber is set at the subscription time by the service provider based on the subscriber's need. The subscriber may select WO 00/79742 PCT/AU00/00695 8 a precedence level up to and including the maximum subscribed to precedence level on a per call basis. Precedence calls (MLPP calls that have a higher precedence than the lowest level of precedence) that are not responded to by the called party (e.g. call 5 unanswered and/or unacknowledged, called party busy with call of equal or higher precedence, or called party busy and non-pre-emptable) are diverted to a predetermined alternate party. This alternate party may be another subscriber or a network operating position. Pre-emption may take one of two forms. First, the called party may be busy 10 with a lower precedence call which must be pre-empted in favour of completing the higher precedence all from the calling party. Second, the network resources may be busy with calls some of which are of lower precedence than the call requested by the calling party. One or more of these lower precedence calls must be pre empted to complete the higher precedence call. There are at least three 15 characteristics of pre-emption: - Any party whose connection was terminated (whether that resource is reused of not) must receive a distinctive pre-emption notification. - Any called party of an active call that is being pre-empted by a higher precedence call should be required to acknowledge the pre-emption 20 before being connected to the new calling party. - When there are no idle resources, pre-emption of the lowest lower level of precedence resources shall occur. To ensure correct operation of the MLPP supplementary services additional termination properties are added in accordance with the present invention based 25 on the Media Gateway Control Protocol which describes several commands, such as, to create, modify, subtract and query the properties associated with a termination and/or context. Thus the present invention seeks to incorporate additional termination properties such as: 30 An indication of the termination's membership of a domain or group (i.e. MLPP service domain) WO 00/79742 PCT/AUOO/00695 9 An indication of why a termination is reserved (e.g. pre-emption reserved for reuse) An indication of which network a termination is assigned (e.g. Network Identity) 5 It is contemplated to indicate these properties by adding them to the Media Gateway Control Protocol command application programming interface (API). The updated commands contemplated to enable signalling of these properties are: Add Modify 10 Subtract Move Audit Notify ServiceChange 15 The Media Gateway Control Protocol has a number of network applications including but not limited to: UMTS core network UMTS access network GPRS networks 20 - H.323 Multimedia networks SIP based Multimedia networks Cable based networks ATM networks Circuit Switched Networks 25 And could be realised, for example but not limited to, equipment such as: trunking gateways access gateways access servers base stations 30 Mobile Switching Centres (MSCs) Gateway Mobile Switching Centre (GMSCs) WO 00/79742 PCT/AUOO/00695 10 - residential gateways - transit switches - local switches Specific applications of the invention include a UMTS core network, H.323 5 VoIP and/or SIP (Session Initiation Protocol) based VolP networks. Particularly, the present invention has application to MLPP used with a TICC or BICC protocol in separated CC and BC networks. Example realisations of the present invention are as shown below. The options are exemplary and not expansive. Thus, other realisations are 10 contemplated within the scope of the present invention. EXAMPLE REALISATIONS Option 1 Add (Termination Id, [Local Termination State,]' 15 [Local Termination Descriptor,] [Remote Termination Descriptor,] [Events descriptor,] [Signal Descriptor,] [Service Domain,] 2 20 [Termination Network]) 3 *Note: The new states and parameters could equally apply to other MGCP commands as specified in the present invention. Option 2 Add (Termination Id, 25 [ : ) *Note: There are no parameters. The actual termination Id would be formatted to represent the circumstances of note 4, below, ie. Terminationld = Circuit23/MLPPdomain/N2. Option 3 30 ServiceChange (Termination Id, ServiceChange Method, WO 00/79742 PCT/AUOO/00695 11 ServiceChange Reason, [ServiceChange Delay]) Option 4 Add (Context Id, 5 [Context Attribute,])' Notes: 1 - New states added: Reserved Reserved Pre-emption 2 - New parameter 10 3 - New parameter 4 - Formatted to indicate 2 identities: - MLPP Service Domain - Network Identity 5 - New Reasons: 15 - Reserved - Reserved pre-emption

Claims (15)

1. A method of operating a media gateway in a separated BC and CC network, the method including: providing in the BC functionality, at least one of the following properties: a) an indication of the termination's membership of a domain or group; b) an indication of why a termination is reserved; and c) an indication of which network a termination is assigned.

2. A method as claimed in claim 1, wherein the properties are additional termination properties.

3. A method as claimed in claim 1 or 2 wherein all of the following properties: a) an indication of the termination's membership of a domain or group; b) an indication of why a termination is reserved; and c) an indication of which network a termination is assigned, are provided in the BC functionality.

4. A method as claimed in claim 1, 2 or 3, wherein commands signalling the properties are: Add; Modify; Subtract; Move; Audit; Notify; and/or ServiceChange

5. A method as claimed in any one of claims 1 to 4, implemented in a Media Gateway Control Protocol. WO 00/79742 PCT/AU00/00695 13

6. A method as claimed in any one of claims 1 to 5, used to implement a MLPP supplementary service.

7. A separated Call Control (CC) and Bearer Control (BC) network, operating a service which allows for precedence and pre-emption, including BC functionality means having context and termination, first indicating means to indicate membership of a domain or group by the termination, second indicating means to indicate why the termination is reserved, and third indicating means to indicate to which network the termination is assigned.

8. A network as claimed in claim 7, further including means to implement the following commands: Add Modify Subtract Move Audit Notify, and/or ServiceChange.

9. A network as claimed in claim 7 or 8 used in conjunction with a TICC protocol.

10. A network as claimed in claim 7, 8 or 9 in which the service operated is a MLPP supplementary service.

11. A UMTS core network including the network of any one of claims 7 to 10.

12. A H.323 multimedia network including the network of any one of claims 7 to 10. WO 00/79742 PCT/AUOO/00695 14

13. A SIP based network including the network of any one of claims 7 to 10.

14 A method as herein disclosed.

15. A network, protocol or device as herein disclosed. RCS/MBP/SXH LMF99106/P15638AU00