GB2352358A - Connection set-up in a telecommunications network - Google Patents

Abstract

A method of defining a call connection at a gateway node of a telecommunication network, where the Call Control (CC) level is independent of the Bearer Control (BC) level at least at the gateway node. The method comprises defining at the BC level a plurality of contexts corresponding to respective data structures, where each data structure contains an identification of at least one call termination and at least two of the data structures contain a common termination. Also disclosed is a telecommunication network or multimedia system node and a Media Gateway.

Description

2352358 CONNECTION SET-UP IN A TELECOMMUNICATIONS NETWORK

Field of the Invention

The present invention relates connection set-up in a telecommunications network and in particular, though not necessarily, to the setting-up of call connections having multiple terminations.

Background to the invention

Telecommunications networks currently rely to a large extent upon the Signalling System no.7 (SS7) as the mechanism for controlling call connections and for handling the transfer of signalling information between signalling points of the networks. Typically, one or more application and user parts at a given signalling point will make use of SS7 to communicate with peer application and user parts at some other signalling point. Examples of user parts are ISUP (ISDN User Part) and TUP (Telephony User Part) whilst examples of application parts are INAP (Intelligent Network Application Part) and MAP (Mobile Application Part). The conventional SS7 protocol stack includes Message Transfer Parts MTP I, MTP2, and MTP3 which handle the formatting of signalling messages for transport over the physical layer as well as various routing functions.

There has been considerable interest of late amongst the telecommunications community in using non-standard (i.e. non-conventional within the telecommunications industry) bearer transport mechanisms in telecommunications networks to carry user data, for example, voice traffic. The reasons for this are related both to improvements in efficiency as well as potential cost savings. Much consideration has been given for example to the use of Internet Protocol (IP) networks to transport user 'information between network nodes. IP networks have the advantage that they make efficient use of transmission resources by using packet switching and are relatively low in cost due to the widespread use, of the technology (as opposed to specialised telecommunication 2 technology). There is also interest in using other transport mechanisms including AALI/2/5, FR etc.

The standard ISUP which deals with the setting-up and control of call connections in a telecommunications network is closely linked to the standard bearer transport mechanism, and does not readily lend itself to use with other non-standard transport technologies such as IP and AAL2. As such, several standardisation bodies including the ITU-T, ETSI, and ANSI, are currently considering the specification of a protocol for the control of calls, which is independent of the underlying transport mechanism. This can be viewed as separating out from the protocol, Bearer Control functions which relate merely to establishing the parameters (including the start and end points) of the 11pipe" via which user plane data is transported between nodes, and which are specific to the bearer transport mechanism. The new protocol, referred to as Transport Independent Call Control (TICC), retains Call Control functions such as the services invoked for a call between given calling and called parties (e.g. call forwarding), and the overall routing of user plane data. Figure la illustrates the conventional integrated Call Control and Bearer Control structure of ISUP whilst Figure lb illustrates the proposed new separated structure.

It is noted that at the junctions between different bearer networks, i.e. between different transport media, a gateway node is present which requires both the CC functions and BC functions. This node is referred to as a gateway node. The splitting of the CC and BC control derives in part from the Gateway Decomposition work which was carried out by the IETF SS71P, SIGTRAN and MEGACO working groups, ETSI Tiphon Project, SG16 Study Group 16, ATM Forum and Multiswitching Service Forum (MSF) on establishing an architecture and requirements for decomposed gateways.

As a result of the CC/BC split, a new interface is exposed between the CC farictions and BC functions. A protocol is required to enable coupling between the CC functions and BC functions when a node is implemented in a separated environment. The common terin for this interface protocol is a 'Media Gateway Control Protocol' (MGCP). This protocol is being developed by the ITU Study Group 16 (H.GCP) and in the IETF 3 MEGACO (MGCP) working group. In ITU Study Group 16 and IETF MEGACO, the CC function is know as 'Media Gateway Controller (MGC)' and the BC function is known as 'Media Gateway (MG)'. The need for the MGCP is illustrated in Figure 2, which illustrates two peer gateway nodes which communicate with one another at both the CCJevel and the BC level.

The MGCP describes resources in the BC functions in terms of "contexts" and "terminations". A context, identified by a context DD, is a logical concept embodied in a data structure stored at the BC and/or CC level which defines a connection over the bearer transport mechanism or within the BC functions using at least one termination. A termination represents a physical endpoint and can be assigned one of a number of physical characteristics, for example transport type (Circuit, IP, ATM), media or codec type (GSM, G.71 1), or a priority level. Figure 3 illustrates a simple context I having two terminations T1 and T2. This could represent, for example, a traditional telecommunications audio call between two parties where TI represents the input port or incoming circuit for the calling party to the BC layer and T2 represents the output port or outgoing circuit for the called party from the BC layer.

Consider the situation where a calling party dials the number of a called party to whom he wishes to be connected. The dialled number is carried from the calling party over the bearer medium to a media gateway. Here the dialled number is transferred from the BC layer to the CC layer. The CC layer determines the tennination points (incoming and outgoing) of the BC layer for the call and uses the MGCP to pass a TRANSACTION message back to the BC layer. This TRANSACTION message includes a transaction message ID, parameters identifying the two termination points and their properties, an ANY CONTEXT parameter which indicates that the BC level should allocate a context to the call, and a context property which specifies the flinction of the context. Once the BC level has allocated a context, the context ID is passed back to the CC level in an ACCEPT message.

A more complex context is required in the case of a conference call, an example of which is illustrated in Figure 4 where five subscribers are connected to one another via 4 an audio mixer M. Ta and Tb are terminations on a Switched Circuit Network (SCN) and which correspond respectively to subscribers A and B. Tc, Td and Te are the terminations on an IP network and which correspond to data streams (eg. Real Time Transport Protocol RTP) to subscribers C, D and E.

The model of Figure 4 assumes that all of the terminations belong to a single context (Context 1). In the Megaco/H.GCP connection model the BC function is modelled as being atomic, i.e. it performs one ftinctionality. This model is not sufficient for the case where several objects or functions are combined in the BC function. For example, consider the situation where a user A resides in an SCN network which uses PCM coding whilst users B and C reside in an IP network using GSM EFR coding, and all three users wish to be in conference with one another. The objects involved in this conference call would be; the SCN termination, a conference device (CCD), two transcoders for the PCM to GSM EFR conversion, and two 1P terminations. These objects could reside in one or more BC functions. It becomes very difficult to model this type of scenario with a single context.

Considering the situation where a subscriber A has set up a conference call between subscribers A, B and C. In this conference call, A is seen as the "controlling subscriber" (the party who set up the conference). After the establishment of this conference call, a subscriber D calls subscriber C, subscriber C having a Call Waiting Service. Subscriber C will then place A and B on hold whilst talking to D. In this new call, subscriber C is seen as the controlling subscriber since he is the subscriber who "owns" the Call Waiting Service. The two separate calls are defined respectively by the contexts 1 and 2 illustrated on the left hand side of Figure 5. Subsequently, subscriber C decides that D must be included in the conference call with subscribers A and B. This new situation is modelled by a new context illustrated on the right hand side of Figure 5.

The Megaco/H.gcp proposal handles the above scenario by "moving" Termination Tc from Context 1 to Context 2 in order to connect subscribers C and D. If subscriber C places D on hold and returns to talking to the A-B conference, Termination Tc will move back, to Context 1. The controlling subscriber (Subscriber Q then links the I conferences together so that all participants receive the data streams (eg. Audio, video, data). This is represented by the one context (Context 1) on the right hand side of Figure 5. The other contexts (i.e. those illustrated on the left hand side of Figure 5) are deleted as they contain no terminations. Thus any pointers to the data structures represented by the contexts on the left hand side are lost. This means that it is not possible to break the new A-B-C-D conference into the two original conferences A-B and C-D as all the state information/data structures are lost. Moreover, the original data structures may contain or identify charging information for the associated conference calls. This charging information cannot be carried forward into the new conference call. The subscribers will therefore be billed separately for each of the conference call components.

Summga of the Present Invention.

It is an object of the present invention to overcome or at least mitigate the disadvantages noted in the preceding paragraph. This and other ob ects are achieved at least in part by j defining a call connection using a plurality of contexts where two or more contexts share a common termination.

According to a first aspect of the present invention there is provided a method of defining a call connection at a node of a telecommunication network or multimedia system where the Call Control (CC) level is independent of the Bearer Control (BC) level, the method comprising defining at the BC level a plurality of contexts corresponding to respective data structures, where each data structure contains an identification of at least call termination and at least two of the data structures contain a common termination.

It will be appreciated that the term "context" as used here represents an association between one or more terminations which can have certain properties associated with it. A context may set-up or reserve call connections at the BC level. Typically, the general structure of each context and/or the nature of the linking together of contexts is known to the CC level.

6 Embodiments of the present invention allow existing contexts to be combined by creating a new context which acts as a link between those existing contexts. This in turn allows the data structures associated with the existing contexts to be retained so that the existing call contexts can subsequently be re-established.

A context may be created upon receipt of an appropriate TRANSACTION message at the BC level, the TRANSACTION message having been sent by the CC level. An existing context may be modified upon receipt of a TRANSACTION message containing a context 11D corresponding to the context to be modified.

According to a second aspect of the present invention there is provided a telecommunications network or multimedia system node for connecting terminations to establish a call, the node comprising: a memory for storing data structures associated with respective contexts, where each data structure contains an identification of at least one call termination and at least two of the data structures contain a common termination; and first processing means for establishing a connection at the bearer level for each context.

According to a third aspect of the present invention there is provided a Media Gateway arranged in use to couple together two transport media of a telecommunications system or multimedia system, the media gateway comprising: a memory for storing data structures associated with respective contexts, where each data structure contains an identification of at least one call termination and at least two of the data structures contain a common termination; first processing means for establishing a connection at the bearer level for each context; and second processing means for communicating with a co-located Media Gateway Controller whereby the Media Gateway Controller is able to cause the Media Gateway to create contexts and to modify existing contexts.

7 Brief Description of the Drawings

Figure la shows in block diagram form the architecture of a conventional telecommunications network; Figure I b shows in block diagram form a network architecture in which the Call Control protocol is independent of the transport mechanism; Figure 2 illustrates the protocol layers at two peer gateway nodes which communicate with one another at both the CC level and the BC level Figure 3 illustrates schematically a simple two termination context; Figure 4 illustrates schematically a context defining a five party conference call; Figure 5 illustrates schematically a two-stage process for creating a single multi-party conference call context according to the prior art;

Figure 6 illustrates schematically a three-party conference call defined using three contexts; and Figure 7 illustrates the scenario of Figure 5 implemented using an embodiment of the present invention.

Detailed Description of Certain Embodiments

The proposed separation of the Call Control (CC) protocol and the Bearer Control (BC) protocol in future telecommunications standards, such as the Universal Mobile Telecommunications Standard (UMTS), has been described above with reference to Figures I a, lb, and 2. The proposed use of contexts to define two-party and multi-party calls has been described with reference to Figures 3 to 5.

To model complex systems additional concepts needs to be defined over and above the current ITU and IETF proposals. One concept is that any one termination may exist in several contexts. A second concept is that a call may be represented by multiple contexts. When coupled with the prior art capabilities, i.e. that a context can model a physical device (for example a Conference Device (CCD) can be modelled by a Context having a CCD property and with each of the device's ports represented by a termination, or a transcoder may be modelled by a context haying several terminations), this means that the connection path through the entire BC functions can be modelled by several contexts and terminations for a call or session.

Figure 6 illustrates these principles which allow a complex system such as multiple conference bridges to be modelled and implemented in a telecommunications system. Context CB I has the property of a mixer(m) [CCD]. Each CCD has one context (contexts 1, 2, 3,, x) with a number of terminations equalling the number of ports available. There are thus four contexts defining the connection with termination TCB1.1 being shared between contexts CBI and 1, TCB1.2 being shared between contexts CB 1 and 2, etc. The contexts CB I and 1 to x are set up using respective TRANSACTION messages sent to the BC function by the CC function and respective data structures are maintained at the BC function. In addition, the contexts are known to the CC function, and in particular the CC flanction is aware of the linking of different contexts together.

Assume now that the calling/called party corresponding to termination Te transfers his context 3 to a new conference call defined by context 4 (using a first TRANSACTION message to set-up the context CB2 and a second TRANSACTION message to identifying the transfer to the context CB 1). This is illustrated in Figure 5. This new conference involves a party connected to a termination Td and coupled to the conference call by context 5. It now becomes possible to subsequently link the two conference call together (defined respectively by contexts CB 1 and CB2) using a further context 4. By using extra contexts such as Context 4 it becomes possible to link devices (e.g. CCDs, transcoders, DTIs etc) together in such a way that the original data structures associated which the contexts can be retained. This enables efficient processing in both the MC and BC functions leading to increased capacity, and also allows for efficient use of the H.GCP/MGCP protocols as few commands need to be executed to carry out this linking compared to the large amount of commands required to set-up a new context and move all the terminations (lessening traffic on the signalling link).

9 The Media Gateway Control protocol may be used in many different types of networks including UMTS core networks, H.323 VoIP, and SIP based VoIP networks. The invention may be implemented in a number of different types of network nodes including, but not limited to, Voice over IP gateways, media control units, and announcement machines.

It will be appreciated by the person of skill in the art that various modifications may be made to the above described embodiment without departing from the scope of the present invention.

Claims (5)

CLAIMS:

1. A method of defining a call connection at a node of a telecommunication network or multimedia system, where the Call Control (CC) level is independent of the Bearer Control (BC) level, the method comprising defining at the BC level a plurality of contexts corresponding to respective data structures, where each data structure contains an identification of at least one call termination and at least two of the data structures contain a common termination.

2. A method according to claim 1, wherein a context is created upon receipt of an appropriate TRANSACTION message at the BC level, the TRANSACTION message having been sent by the CC level.

3. A method according to I or 2, wherein an existing context is modified upon receipt of a TRANSACTION message containing a context ID corresponding to the context to be modified.

4. A telecommunications network or multimedia system node for connecting terminations to establish a call, the node comprising: a memory for storing data structures associated with respective contexts, where each data structure contains an identification of at least one call termination and at least two of the data structures contain a common termination; and first processing means for establishing a connection at the bearer level for each context.

5. A Media Gateway arranged in use to couple together two transport media of a telecommunications system or multimedia system, the media gateway comprising: a memory for storing data structures associated with respective contexts, where each data structure contains an identification of at least two different call terminations and at least two of the data structures contain a common termination; first processing means for establishina a connection at the bearer level for each context; and 11 second processing means for communicating with a co-located Media Gateway Controller whereby the Media Gateway Controller is able to cause the Media Gateway to create contexts and to modify existing contexts.