4.4 UMTS call control

23.1213GPPArchitectural requirements for Release 1999Release 1999TS

4.4.1 Technical Requirements

The following technical requirements are applied to support multimedia in GSM/UMTS.

P1) GSM/UMTS shall enable the provisioning of multimedia services and multivendor interworking between UE and network.

P2) Basic voice and PDP-context establishment shall be based on GSM CC/SM respectively.

P3) Handover and roaming to and from GSM shall be supported provided GSM is capable of supporting the ongoing media service.

P4) Ideas, concepts and procedures developed by other fora e.g. other standards bodies such as ITU, IETF etc. shall be included or referenced in GSM/UMTS when found suitable.

P5) To ensure multi-vendor inter-working and UE roaming, a single standardised multimedia protocol for CS domain and a single standardised multimedia protocol for PS domain shall be selected for GSM / UMTS R99. This does not preclude the selection of other protocols by UMTS in the future.

H.323 shall be the multimedia call control model for the PS domain in UMTS R99.

P6) For multimedia services the standardized multimedia protocol shall be run transparently via a PDP-context or a circuit-switched connection established using GSM SM/CC . This allows transparent hand-over and roaming between GSM and UMTS provided that GSM supports the QoS requirements.

Figure 4.36 illustrates the realisation of the multimedia service based on P6). ‘Multimedia Protocol’ indicates the functionality either inside the communicating user’s terminal or a gateway (e.g. H.323 Gateway)/GK. It is essentially a control function both for user plane and control plane for the multimedia communication.

Figure 4.36: Support of multimedia making use of GSM SM/CC

Based on the requirements listed above, GSM CC/SM represented by GSM 04.08 forms a solid foundation for UMTS CC/SM for Release 99. UMTS CC/SM for Release 99 is to be developed from GSM CC/SM by introducing some well defined enhancements.

Existing (and future) multimedia protocols can be supported by the UMTS CC/SM as application layer protocols, with no (or in some instances only minor) impact to UMTS CC/SM.

4.4.2 Architecture for Multimedia

In order to include multimedia in release 99 an architecture for multimedia is required. Subclauses 4.4.2.1 and 4.4.2.2 detail the architecture for UMTS multimedia. It is recognised that it may not be possible to include all the functionality included in this architecture in release 99.

4.4.2.1 Packet Switched Domain

Figure 4.37: Multimedia architecture PS Domain

The multimedia C-plane and U-plane are run transparently over a PDP-context between the UE and multimedia gatekeeper and gateway.

The multimedia U-plane runs between the UE and the multimedia gateway. The multimedia gateway maps the multimedia U-plane on to the U plane in the external network eg. Internet, PSTN. In some cases, such as a UMTS to UMTS call this may unnecessary.

The multimedia control protocol is run between the UE and multimedia gatekeeper. The multimedia gatekeeper is responsible for establishing a multimedia C plane connection on the terminating network.

The service capability server is functionally distinct from the multimedia gatekeeper. It is responsible for creating multimedia services. The standardisation of the interface between the service capability server and the multimedia gatekeeper is for further study. The service capability server may require interfaces to the HLR and CSE (Camel Service Environment) in order to enable interactions between multimedia services and the services provided by these platforms. In this case the interfaces X and Y in figure 4.37 will require standardisation, (It is not proposed that this be included in release 99). The handling of MT communications is for further study.

Services can be delivered at two levels:

– bearer level services are those which correspond to the UMTS bearer service and are delivered via the SGSN, HLR and CSE. Examples of bearer level services are pre-paid or barring of PDP context establishment (for the UMTS bearer service);

– multimedia level services are delivered via the multimedia gatekeeper and service capability server possibly in combination with the HLR and CSE. Examples of multimedia services are video conferencing, call forwarding and pre-paid (of the multimedia component).

The multimedia gatekeeper and service capability server may be located within or external to the UMTS PLMN. The implications of the location of the multimedia gatekeeper and service capability server are for further study.

4.4.2.2 Circuit Switched Domain

Figure 4.38: Multimedia architecture CS Domain

The multimedia C-plane and U-plane are run transparently over a bearer between the UE and destination or 45ignalling the multimedia gatekeeper and/or gateway if present.

The multimedia U-plane runs between the UE and destination. Optionaly the multimedia U-plane is terminated at the the multimedia gateway, which interworks with the external network.

The multimedia control protocol is run between the UE and the destination. Optionally the multimedia gatekeeper is responsible for establishing a multimedia C plane connection on the fixed network.

The service capability server is functionally distinct from the multimedia gatekeeper. It is responsible for creating multimedia services. The standardisation of the interface between the service capability server and the multimedia gatekeeper is for further study. The service capability server may require interfaces to the HLR and CSE (Camel Service Environment) in order to enable interactions between multimedia services and the services provided by these platforms. In this case the interfaces X and Y in figure 4.38 will require standardisation, (It is not proposed that this be included in release 99). The handling of MT communications is for further study.

Services can be delivered at two levels:

– bearer level services are those which correspond to the UMTS bearer service and are delivered via the MSC, HLR and CSE. Examples of bearer level services are pre-paid or call barring (for the UMTS bearer service);

– multimedia level services are delivered via the multimedia gatekeeper (if present) and service capability server possibly in combination with the HLR and CSE. Examples of multimedia services are video conferencing, call forwarding and pre-paid (of the multimedia component). If there is no multimedia gatekeeper network level multimedia services can not be provided.

The multimedia gatekeeper and service capability server may be located within or external to the UMTS PLMN. The implications of the location of the multimedia gatekeeper and service capability server are for further study.

4.4.3 Typical Scenarios for Multimedia Control and User Plane

Two typical call scenarios to support multimedia services, H.324 and H.323, respectively, are presented as examples. As an assumption, the calls are between the peer multimedia terminals over an IMT-2000 network. As shown in the following subclauses, the multimedia signalling protocol and data transmission for both call scenarios can be performed end-to-end on the IMT-2000 user plane and is thereby transparent to the IMT-2000 Core Network. The IMT-2000 operators still control the multimedia service towards the end-user by providing the service via a service node (gateway, gatekeeper or application server) inside its own domain. Some other call scenarios e.g. IMT-2000 to ISDN/PSTN and/or IMT-2000 to the IP network can also be illustrated in a similar fashion.

4.4.3.1 H.324M to H.324M Call

In figure 4.39, the H.324M IMT-2000 terminal initiates the call set-up procedure by sending a 04.08 SET-UP message to the originating MSC/VLR.

After the received 04.08 SETUP message, the originating MSC/VLR sends an ISUP Initial Address Message (IAM) to the terminating MSC/VLR. The terminating MSC/VLR performs a 04.08 SETUP procedure towards the H.324M UMTS terminal. The communication link is now established between the two H.324M endpoints.

The logical channels can now be established using the H.245 open logical channel procedure.

No gateway is needed in this case. This case is simple to support and requires little standardization.

The 04.08 Bearer Capability is used to indicate 64 kbits/s bit transparent case described in GSM 07.01 can be used, as well as H.223/H.245.

The 04.08 LLC is used to indicate H.223/H.245. This makes the called IMT-2000 mobile terminal activate its H.324M application when receiving the SETUP (LLC:H.223/H.245).

Table 4.2

Information Transfer Capability

Unrestricted Digital Information

Sync/Async

Synchronous

Connection Element

Transparent

Fixed Network User Rate

64 kbit/s

Figure 4.39: UMTS H.324M – UMTS H.324M call example

4.4.3.2 IMT-2000 H.323 to H.323 call

Figure 4.40 shows a Multimedia Call between two H.323 terminals within an IMT-2000 operator domain. It is assumed that a PDP Context using a Best Effort (BE) Radio Access Bearer (RAB) from terminal A towards the Gatekeeper (GK) and one from terminal B towards GK have already been established for H.323 registration in this figure. Terminal A and B now performs Gatekeeper Identification and Gatekeeper Registration using a BE RAB. Thereafter, the terminal A sets up a Real Time (RT) Radio Access Bearer (RAB) to decrease the time for the H.323 control signalling. This need of a Real Time Radio Access Bearer can be indicated from the terminal application to the mobile terminal through the Application Programming Interface (API). The terminal A performs PDP Context activation (see figure bellow) to set up the Real Time Radio Access Bearer. From now on, the established Real Time Radio Access Bearer can be used for H.225.0 RAS control signalling and Q.931 control signalling. After the Real Time Radio Access Bearer is established, the H.323 terminal A performs an Admission Request (ARQ) towards the Gatekeeper. If the terminal A is admitted the Gatekeeper answers with AdmissionConfirm (ACF) otherwise AdmissionReject (ARJ). Terminal A initiates the H.323 connection by sending a Q.931 Setup message to the Gatekeeper when the ACF has been received. The Gatekeeper answers with a Q.931 Call Proceeding to terminal A and sends a Q.931 Setup message to terminal B on a Best Effort (BE) Radio Access Bearer (RAB). Terminal B performs PDP Context Activation to SGSN and GGSN to set up a Real Time Radio Access Bearer and performs an Admission Request towards the Gatekeeper on this Real Time Radio Access Bearer. After this terminal B answers the received Q.931 Setup message with a Q.931 Alert and Connect message to the Gatekeeper on receipt of the Admission ConFirm (ACF) message. The Gatekeeper forwards these two messages to the terminal A. The Real Time Protocol (RTP) is now established between the terminal A and B for transmission of audio, video or data streams (see figure 4.40). The Gatekeeper relays the data streams but is not always completely transparent. The Gatekeeper can perform interworking functions e.g. Network Address Translation (NAT) etc between different networks. The voice transcoding is performed end-to-end in the H.323 terminal.

Figure 4.40: IMT-2000 H.323 – H.323 call example