You are on page 1of 10

SIP and 3GPP Operations Narayan Parameshwar, Lachu Aravamudhan and Chris Reece

Advanced SIP Series: SIP and 3GPP Operations


Narayan Parameshwar, Lachu Aravamudhan and Chris Reece, Award Solutions, Inc Abstract
The Session Initiation Protocol has been chosen by the 3GPP for establishing multimedia sessions in UMTS Release 5 (R5) networks. This paper discusses the operations of the UMTS R5 IP Multimedia Subsystem (IMS) in great detail. The paper discusses where SIP is used in UMTS IMS and the interaction between the various components of the IMS networks. The changes and enhancements made to the Internet telephony signaling protocols such as SIP, SDP and Megaco are discussed. The interaction between the IMS and the PSTN/legacy wireless networks are outlined to provide the reader a complete view of the IMS operations.

Introduction
Session Initiation Protocol (SIP) has been chosen as the signaling protocol for establishing multimedia sessions in UMTS Release 5 (R5) IP Multimedia Subsystems (IMS). In a previous paper on UMTS IMS2, we presented the rationale for IMS, the basic architecture of IMS and the services architecture of IMS. We also presented a brief overview of where SIP is used in UMTS IMS. In this paper, we describe the operations defined in UMTS IMS for establishing multimedia sessions. We discuss interaction between SIP and other protocols such as the UMTS signaling protocols and the PSTN signaling protocols. We start with a high-level overview of all of the operations in IMS. In the subsequent sections, we explain each operation in more detail. We follow the overview with a discussion of the UMTS data bearer setup using UMTS signaling protocols. Next, we discuss the service registration process and rationale behind it. In next few sections we provide an in-depth discussion of how multimedia sessions are setup using the User Equipment (UE) origination and UE termination operations. In these sections, we explain how SIP is used and enhanced in the IMS networks. The interaction between the IMS and the PSTN/legacy networks is an important issue. The next section addresses this issue and explains how another Internet telephony protocol called Megaco3 is used. In conclusion, we provide a summary of the paper and areas for further specification in UMTS R5 IMS.
1

examine the key steps involved before a UMTS SIP mobile starts a SIP session4. The key steps involved in obtaining access to SIP services are summarized in Fig. 1.

UE

UMTS RAN System Acquisition

PS-CN
SGSN Intra Operator Backbone GGSN

P-CSCF, S-CSCF

IMS

Data Connection Setup

SIP-based IMS procedures

Fig. 1.

High Level Summary of SIP in UMTS

1. System acquisition: The first step is to power on the mobile and lock on to the UMTS system. Once the appropriate cell is selected, the UMTS mobile is ready to communicate signaling messages required to establish a data session. In this paper, we will assume that this function has been performed by the mobile and will not be discussed in detail. 2. Data Connection Setup: Once the system has been acquired, the next step is to establish the data connection or pipe to the SIP and other services. The UE does not know the IP address of the Proxy-CSCF at

A Day in the Life of a IMS UE


The UMTS IMS capable mobile station performs several functions to set up a SIP session. We shall

www.awardsolutions.com

SIP and 3GPP Operations Narayan Parameshwar, Lachu Aravamudhan and Chris Reece
this point to perform a SIP registration. The data connection is completed in a two-step process using Attach and Packet Data Protocol (PDP) Context Activation message sequences. This establishes the path required to carry SIP related signaling messages to the Proxy-CSCF through the GGSN, which is the gateway to the Proxy-CSCF. 3. Therefore, the Attach and the PDP Context Activation are two key steps required to create a data pipe to the Proxy CSCF for SIP services. The response to the PDP Context Activation message also includes the identity of the Proxy-CSCF for the UE to use to perform the registration process. Now, lets explore the process of how the UMTS UE registers with the UMTS SIP network. 4. Service Registration: Before establishing an IP Multimedia session, the UE needs to perform the Service registration operation to let the IMS network know the location of the UE. This registration is an application or SIP registration for various SIP services. The UMTS UE acts as a SIP client and sends a SIP registration message to its home system through the Proxy-CSCF. 5. Session Setup: After a PDP context is activated and Service Registration is finished, the UE can establish a session. We have discussed the key steps in registering for SIP services. Lets step through the details of the key steps such as Attach, PDP Context Activation and SIP registration5. After the UE acquires the system, it needs to setup a data connection in order to use wireless packet data services. The procedures described below exist in Release 99 UMTS. At first, the UE must "attach" itself to a 3G-SGSN.

Attach
The first step in the data connection or creation of the data pipe through the UMTS network is the registration for packet service with the UMTS network. The UMTS UE sends the Attach message to the Serving GPRS Support Node (SGSN), which includes the UEs International Mobile Subscriber Identifier (IMSI). The SGSN uses the IMSI to send a request to the UEs Home Location Register (HLR) for the authentication parameters to help authenticate the subscriber. The HLR provides authentication information to the SGSN, enabling the SGSN to verify the veracity of the subscribers IMSI. The successful completion of authentication procedure triggers the SGSN to send a location update (which provides the UMTS UEs IMSI) to the HLR and this triggers the subscribers profile to be downloaded to the SGSN. This includes information such as the subscribed services, the QoS profile, any static IP addresses allocated and so on. The SGSN completes the Attach procedure by sending an Attach Complete message to the UE. A logical association is now established between the UE and the SGSN and mobility management information or a context now exists between the UE and the SGSN. With this key step, the location of the mobile is known within the UMTS network. This logical connection is maintained as the UE moves within the coverage area controlled by that SGSN. Please note that even though the UE has announced its presence in the UMTS packet network, application packet traffic (for example, SIP signaling etc.) cannot be transferred at this point. This is the first of two critical steps that an UE takes toward packet data access and the UE needs to activate its PDP address (or IP address) to establish a path to the Internet.

Data Connection Setup


l

Attach
Used to establish Mobility Management

contexts at SGSN and UE

PDP Context Activation


Used to establish GGSN connectivity
3G-SGSN UTRAN
Node B

PDP Context Activation


GGSN

UMTS PLMN
Intra PLMN IP Backbone

RNC

3G-SGSN

GGSN

UMTS Attach

IP
PDP Context Activation

Fig. 2.

Setting up a pipe through the UMTS packet network

Once a UE is attached to an SGSN, it must activate a PDP address (in this case, an IP address) when it wishes to begin a packet data communication, including SIP services. Activating a PDP address sets up an association between the UEs current SGSN and the Gateway GPRS Support Node (GGSN) that anchors the PDP address. A record is kept regarding

www.awardsolutions.com

SIP and 3GPP Operations Narayan Parameshwar, Lachu Aravamudhan and Chris Reece
the associations made between the GGSN and SGSN. This record is known as a PDP context. This second and final step is required to establish the data connection or pipe to the Internet. The activation of a PDP context activates an IP address for the UE; the UE may now exchange traffic using that IP address. Context activation creates an association for this IP address between the SGSN and a specific GGSN. The UMTS UE initiates this message and is received by the SGSN. The UMTS UE sends this message transparently, for example, when the user started a SIP service on his or her UE. The PDP Context Activation message contains information such as Access Point Name (APN), which is a logical name referring to a service or a network. In this case, the APN could simply be SIP service. The PDP Context Activation message also contains additional information such as the IP address of the UE, allocated by the wireless provider. All of this information is received by the SGSN, which is crosschecked with the subscriber profile the SGSN received from the HLR. The SGSN proceeds to discover the appropriate GGSN using the APN provided. Since the UE provides an Access Point Name (APN) for establishing the SIP service, the SGSN chooses the appropriate GGSN capable of performing functions required for SIP services. The SGSN and GGSN create special paths or tunnels to transfer packets for this UE. Once the SGSN-GGSN path has been established, the GGSN provides the IP address of the Proxy-CSCF in the PDP context activation accept response message to the UE. This P-CSCF address is the used by the UMTS UE to continue with SIP related activities. The UE may also send a secondary PDP Context Activations, based on the QoS requirements for each address. The SGSN chooses the appropriate GGSN for different contexts and services. The choice of the GGSN by the SGSN is independent of the radio resource allocations. A mobile may initiate secondary PDP contexts and may be connected to more than one GGSN. GGSN is chosen based on the external network and service that the UE requests, i.e. the APN. In the case of a SIP service, a PDP context is activated for primarily SIP signaling initially. This is referred to as Primary PDP Context, which is what we have discussed so far. This PDP context is used to carry all SIP related signaling including registration and invites etc. The reception of SIP Invite message may trigger the creation of secondary contexts that are needed for QoS requirements of the service requested. The secondary contexts use the same IP address as the Primary Context with the exception that it has distinctly different QoS requirements. In this section, we shall discuss the steps leading up to the start of a SIP service. The initial pipe created for SIP signaling will be used for registering with the home SIP server. Once this is completed, secondary contexts may be established for service data transfers.

Why Service Registration?


As shown in Fig. 2, after it has attached to the network and activated a PDP context, the R5 UE needs to perform SIP service registration before it can set up a session.

l Notify

the HSS of current location by the HSS l Send subscriber profile to S-CSCF
l Authorization
Visited Network
S-CSCF Authorization HSS

Home Network

Fig. 3.

The need for service registration

The purpose of service registration is as follows: During the course of service registration, the Home Subscriber Server (HSS) for the UE is notified of the current location of the UE. The HSS updates the subscriber profile accordingly. Authorization needs to be performed before the user can register. The HSS checks whether the user is allowed to register in the network based on the subscriber profile and operator limitations. The UE needs a Serving-CSCF in its home network in order to obtain IMS services. During service registration, the home network selects a suitable Serving-CSCF for the UE and the subscriber profile is sent to the S-CSCF.

www.awardsolutions.com

SIP and 3GPP Operations Narayan Parameshwar, Lachu Aravamudhan and Chris Reece

Service Registration
This section describes the details of a service registration information flow6. As an assumption for this scenario, the UE is located in a visited network and it has completed the Attach and PDP Context Activation operations. It is optional to use the Interrogating-CSCF (I-CSCF), but this scenario assumes that an I-CSCF is used as the entry point to the home network. For scenarios where the UE is located in the home network, the CSCFs will be located in the home network and the registration information flow will remain the same.

checks whether the user is registered already. The HSS indicates whether the user is allowed to register in that visited network according to the user subscription and operator limitations/restrictions (if any). The Cx-Query Response is sent from the HSS to the I-CSCF. 4. The I-CSCF sends the subscriber identity via the UMTS Cx-Select-Pull message to the HSS to request the information related to the required S-CSCF capabilities. This information is needed for selecting a SCSCF. The HSS sends the required S-CSCF capabilities to the I-CSCF via the Cx-SelectPull Response message.

Visited Network
UTRAN 1.Register 3. Cx Query & Resp. Authorization
Key: SIP Message Cx Message

3G-SGSN

GGSN

P-CSCF

Visited Network
UTRAN 2.Register 6. Cx-put & Resp. Update location 5. Register 8. 200 OK 3G-SGSN GGSN P-CSCF

S-CSCF HSS

I-CSCF Locate S-CSCF 4. Cx-Select-pull &Resp.

Home Network

S-CSCF Retrieve profile 7. Cx-pull & Resp. HSS

I-CSCF
Key: SIP Message Cx Message

Fig. 4.

The first four steps of SIP registrations

Home Network

1. To start the Service registration process, the UE sends the SIP Register message to the Proxy-CSCF. This message includes the subscriber identity and home networks domain name. 2. Upon receipt of the Register message, the P-CSCF examines the home domain name (e.g. ims_sprint.com) to discover the entry point to the home network (i.e. the I-CSCF) with help from DNS. The proxy sends the Register message to the I-CSCF with the PCSCFs name, subscriber identity, and visited network contact name. The main job of I-CSCF is to query the HSS and find the location of the Serving CSCF. When the ICSCF receives the Register message from the proxy, it examines the subscriber identity and the home domain name, and uses DNS to determine address of the HSS. 3. The I-CSCF sends a UMTS proprietary message, Cx-Query7, to the HSS with the subscriber identity, the home domain name, and the visited domain name. The HSS

Fig. 5.

SIP registration continued

5. The I-CSCF, using the name of the SCSCF, determines the address of the SCSCF through a name-address resolution mechanism. The I-CSCF also determines the name of a suitable home network contact point, possibly based on information received from the HSS. The home network contact point may either be the S-CSCF itself, or a suitable I-CSCF in case network configuration hiding is desired. If an I-CSCF is chosen as the home network contact point, it may be distinct from the I-CSCF that appears in this service registration flow. ICSCF then sends the Register message to the selected S-CSCF. The flow includes the P-CSCFs name, the subscribers identity, the visited network contact name, and the home network contact point (if needed). The home network contact point will be used by the P-CSCF to forward session initiation signaling to the home network.

www.awardsolutions.com

SIP and 3GPP Operations Narayan Parameshwar, Lachu Aravamudhan and Chris Reece
6. The S-CSCF sends a Cx-Put message with the subscribers identity and the SCSCF name to the HSS. The HSS stores the S-CSCF name for that subscriber. The HSS sends the Cx-Put Response to the S-CSCF to acknowledge the sending of the Cx-Put. 7. On receipt of the Cx-Put Response message, the S-CSCF sends the Cx-Pull message with the subscriber identity to the HSS in order to be able to download the relevant information from the subscriber profile to the S-CSCF. The S-CSCF stores the P-CSCFs name for use in session termination. The HSS sends Cx-Pull Response with the user information to the S-CSCF. The user information passed from the HSS to the SCSCF includes one or more names/addresses information, which can be used to access the service control platform(s) while the user is registered at this S-CSCF. The S-CSCF stores the information for the indicated user (This would be equivalent to the VLR data). Security information may also be sent for use within the S-CSCF. 8. In the 200 OK message, the S-CSCF sends the serving network contact information to the I-CSCF, who forwards it to the P-CSCF. The P-CSCF stores the information, and sends the 200 OK message to the UE. The I-CSCF releases all registration information after sending 200 OK. For example, suppose a subscriber is located in their home network. They want to initiate a session to another subscriber who is also in their home network. The two subscribers have subscriptions with the same network operator. This end-to-end session flow may be constructed with the following procedures: Mobile origination, network, mobile in home and home

S-CSCF-to-S-CSCF, origination termination served by same operator, Mobile termination, network. mobile in

A number of end-to-end session flows may be built from the combinations of origination, serving-toserving, and termination procedures.

I-CSCF/ S-CSCF PSTN BGCF/ MGCF IP

(a) (b) (c) UMTS IMS


UE (R5)

A R5 UE can establish sessions with three types of end parties: (a) Another R5 UE (b) A phone connected to the PSTN (c) A multimedia device connected to the IP network

Fig. 6.

Session Terminating Endpoints

Session Terminating Endpoints


An IMS mobile initiates a session by sending a SIP INVITE message. This message includes the destination address. The destination may be one of the following three types (as shown in Fig. 6): 1. Another IMS mobile: This mobile may or may not be located in the same network as the initiating mobile. The two mobiles can set up a session through their CSCFs. The details of the session setup procedures are discussed in the next section. A phone connected to the PSTN: By going through the Media Gateway Control Function (MGCF) an IMS mobile can set up a session with a traditional PSTN phone. A multimedia device connected to the Internet: The destination address may indicate that the destination party is on the

Originating "Call" setup


Now that we have covered the processes of establishing the PDP context and the process of registration, lets move to the establishment of a voice call. We are starting with a voice call because it is simple and intuitive. This process will remain unchanged if this were a multimedia session establishment.

Basic Session Setup Procedures


In the IP Multimedia Subsystem specifications, an end-to-end session flow consists of three types of procedures: mobile origination, S-CSCF-to-S-CSCF, and mobile termination.

2.

3.

www.awardsolutions.com

SIP and 3GPP Operations Narayan Parameshwar, Lachu Aravamudhan and Chris Reece
Internet. Then the session will be set up through the IMS and the IP network to the destination. A SIP user agent client or a SIP server are examples of a multimedia device connected to the Internet. originating mobile replies with a SIP ACK message to confirm the session setup. 5. Session in progress: After the originating mobile receives the 200 OK response, it starts the media flow and the session is in progress.

Mobile Origination (Overview)


Fig. 7 shows an overview of the mobile origination procedure. This scenario assumes that the mobile is located in a visited network. The sequence is explained below:

Mobile Origination (Detail)


This section presents a detailed description of the process of establishing a session. For this example it is assumed that the mobile is located in a visited network initiates a session. The detailed information flow is described below: 1. The subscriber of the IMS mobile has either dialed digits or used a GUI on the mobile to determine the person that he wants to call. The mobile sends the SIP INVITE request to the P-CSCF. The INVITE message contains three key pieces of information. The first is the called party in the To header. The second key piece of information is the proposed SDP. This SDP may represent one or more media types for a multi-media session. The last piece of information is the From header that contains the calling party. The P-CSCF remembers (from the registration procedure) the next hop CSCF for this mobile. This next hop is either the SCSCF in the home network that is serving the visiting mobile, or an I-CSCF within the home network that is performing the configuration hiding function for the home network operator. This scenario assumes that the home network operator wants to keep its network configuration hidden, so the name/address of an I-CSCF in the home network was provided during service registration, and the INVITE request is forwarded through this I-CSCF to the SCSCF. The P-CSCF will look at the SDP portion of the SIP message and examine the proposed media types that were proposed by the calling party in establishing a session. The P-CSCF has the option at this point to remove some of the proposed media types based on the types of sessions the visited network wants to support. 3. The S-CSCF validates the service profile, and performs any origination service control

P-CSCF UE

I-CSCF

S-CSCF

Destination

INVITE SDP Negotiation Resource Reservation Session Setup Confirmation (OK & ACK) Session in Progress

Fig. 7.

Mobile Origination (Overview)

1.

INVITE: The mobile origination procedure is initiated by a SIP INVITE message sent from the originating mobile. The initial Session Description Protocol (SDP) is included in this message. The message is forwarded from the P-CSCF to the S-CSCF via the I-CSCF, and finally to the destination. SDP negotiation: The two end parties negotiate the media characteristics (e.g. number of media flows, codecs, etc.) for this session and make a decision on the media streams they will support for this session. For the sake of our example, this is assumed to be a basic voice call. Resource Reservation: The network reserves the necessary resources for supporting this session, after the media characteristics for this session have been determined. Session Setup Confirmation: Once resource reservation is completed successfully, the terminating point sends a SIP 200 OK final response and the

2.

2.

3.

4.

www.awardsolutions.com

SIP and 3GPP Operations Narayan Parameshwar, Lachu Aravamudhan and Chris Reece
required for this subscriber. This includes authorization of the requested SDP based on the user's subscription for multi-media services. 4. The S-CSCF also determines the location of the called party based on the information in the To header. As stated before, this could be to another IMS system, to a SIP capable device (a User Agent Client or a SIP proxy server) or to a Media Gateway Controller network to go to the PSTN. Which network is determined by using DNS to translate the address in the To header to an IP address. S-CSCF forwards the INVITE request to the destination. It is not clear from the standards if the SCSCF is a stateless or stateful proxy. It seems logical to assume that it is a stateful proxy since the S-CSCF will support the billing function for the call session. By that same point, the P-CSCF is probably a stateful proxy as well. 5. The called party responds with a provisional response that will include a SDP in the message body. This is the called partys suggestion on the media type. The S-CSCF forwards the SDP information to P-CSCF through I-CSCF. The P-CSCF again looks at the SDP field and removes media types that it does not want to support. The P-CSCF determines the type of resources that are required based on the media type that is requested.
8.SDP UTRAN UE I-CSCF/ S-CSCF PSTN P-CSCF IP Destinations 3. Service Control 4. INVITE BGCF/ MGCF S-CSCF 9. Final SDP 11.Final SDP I-CSCF 10. Final SDP

8.

The P-CSCF then forwards the SDP information to the originating endpoint (i.e. the mobile). The mobile decides the final set of media streams for this session, and sends the Final SDP to P-CSCF. The P-CSCF will then perform the Policy Control Function and determine the resource requirements. There are a number of options that can happen at this point. The P-CSCF can send the policy information using a protocol like Common Open Policy System (COPS)8 to the GGSN. The P-CSCF could also just store this information in a database. The GGSN will send a request to the P-CSCF for permission to setup the requested resources. Please note that the standards have not been completed on the Final SDP message. It is still under development9.

9.

10. The P-CSCF sends the Final SDP message to the S-CSCF (via the I-CSCF if necessary.) 11. The S-CSCF sends the Final SDP message to the called party.

6. 7.

Visited Network
3G-SGSN GGSN P-CSCF

Visited Network
UTRAN UE I-CSCF/ S-CSCF PSTN BGCF/ MGCF S-CSCF IP Destinations 5. SDP 3G-SGSN GGSN 2. INVITE 2. INVITE

7. Authorize QoS Resources

1. INVITE

Home Network

Fig. 9.

Mobile Origination (Part 2)

I-CSCF

Home Network
6. SDP

Fig. 8.

Mobile Origination (Part 1)

12. After determining the final media streams in step #9, the mobile initiates the reservation procedures for the resources needed for this session. The resource reservation takes the form of a secondary PDP context activation or a PDP context modification. At this point the

www.awardsolutions.com

SIP and 3GPP Operations Narayan Parameshwar, Lachu Aravamudhan and Chris Reece
mobile will request to take the current bearer path (that was used to send the signaling messaging) to a bearer that will support the media stream and the signaling. The GGSN will receive this request and either have the permission to establish (that was sent by the P-CSCF earlier) or the GGSN will send a request (via COPS) to the P-CSCF for permission to change the connection. 13. When the resource reservation is completed, the mobile sends the COMET message (to show that the resource reservation has been successful) to the terminating endpoint, via the signaling path established by the INVITE message10. 14. This message is sent to S-CSCF through PCSCF. 15. S-CSCF forwards this message to the terminating endpoint. 16. The destination party may optionally perform alerting. If so, it signals this to the originating party by a provisional response indicating ringing. This message goes through S-CSCF, I-CSCF, and P-CSCF to arrive at the originating mobile.
12. Resources Reservation

20. The P-CSCF indicates the resources reserved for this session should now be committed. 21. P-CSCF sends a SIP 200-OK final response to the session originator 22. The originating mobile starts the media flow(s) for this session
22. Start Media Flow 20. Approval of QoS Commit

21. 200 OK UTRAN

Visited Network
GGSN P-CSCF

3G-SGSN

UE I-CSCF/ S-CSCF PSTN BGCF/ MGCF S-CSCF IP Destinations 17. 200 OK 23. ACK 18. Service Control 19. 200 OK

I-CSCF

Home Network

Fig. 11.

Mobile Origination (Part 4)

Visited Network
UTRAN 3G-SGSN GGSN

13. Reserve Success P-CSCF

23. The mobile responds to the 200 OK with a SIP ACK message, which goes through PCSCF and S-CSCF. S-CSCF forwards the final ACK message to the terminating endpoint.

Mobile Termination (Overview)


Mobile termination is quite similar to the mobile origination except that the signaling is in the reverse direction. This scenario assumes that the mobile is located in a visited network. The use of the I-CSCF is, again, optional. If the originating network operator wants to keep the network configuration private, then the S-CSCF will choose an I-CSCF, who will perform firewall function and pass messages to the PCSCF. Fig. 12 shows an overview of the mobile termination procedure. The sequence is explained below: 1. INVITE: The originating party sends a SIP INVITE message through the network to the destination mobile. SDP negotiation: The two end parties negotiate the media characteristics (e.g. number of media flows, codecs, etc.) for this

UE I-CSCF/ S-CSCF PSTN BGCF/ MGCF

15. Success 16. Ringing

14. Reserve Success

S-CSCF IP Destinations

I-CSCF

Home Network

Fig. 10.

Mobile Origination (Part 3)

17. When the destination party answers, the terminating endpoint sends a SIP 200-OK final response S-CSCF. 18. The S-CSCF performs whatever service control is appropriate for the completed session setup. 19. The S-CSCF sends a SIP 200-OK final response through I-CSCF to P-CSCF.

2.

www.awardsolutions.com

SIP and 3GPP Operations Narayan Parameshwar, Lachu Aravamudhan and Chris Reece
session and make a decision on the media streams they will support for this session. 3. Resource reservation: The network reserves the necessary resources for supporting this session, after the media characteristics for this session have been agreed on. Session setup confirmation: Once resource reservation is completed successfully, the terminating mobile sends a SIP 200 OK final response and the originating point replies with a SIP ACK message to confirm the session setup. Session in progress: Once the P-CSCF approves that the reserved resources can be used, the mobile starts the media flow. After the session setup is confirmed, the session is in progress. the SIP signaling needs to be converted to legacy signaling such as ISDN Signaling User Part (ISUP). The MGCF is responsible for converting SIP signaling to legacy signaling such as ISUP. The MGCF is responsible for transporting ISUP signaling messages to a Trunking Signaling Gateway (T-SGW) over IP transport bearer. The T-SGW transports these ISUP messages over the SS7 bearer to either the PSTN or the legacy wireless networks. Please note that MGCF and T-SGW are logical functions. These functions may be implemented in one physical box.
Legacy Signaling over IP transport

4.

SIP

5.

S - CSCF

MGCF

T - SGW

Legacy Signaling over SS7 transport

Media Packet GGSN

PSTN Megaco

IP Network

UE

P-CSCF

I-CSCF

S-CSCF

Originator

MGW MGW MGW Vocoder Vocoder PCM IP Vocoder PCM IP Stream Stream IP PCM Stream Stream Stream Stream

Legacy Wireless Networks

INVITE SDP Negotiation Resource Reservation Session Setup Confirmation (OK & ACK) Session in Progress
P-CSCF/S-CSCF /BGCF
1. INVITE 2. Creates Context 3. SDP Negotiation 4. Reserve Resources 5. Resource Reservation 7. Ringing 6. Setup PSTN Trunks 8. Answer 9. Start Media Flow 10. Session Setup Confirm (OK + ACK) 11. Session in Progress

Fig. 13.

IMS-PSTN/legacy interworking

The Fig. 14 shows an IMS mobile establishing a session with a phone on the PSTN. An overview of this session setup is described below.
MGCF/ T-SGW MGW PSTN

UE

Fig. 12.

Mobile Termination (Overview)

PSTN/Legacy Networks Interaction


The IMS networks need to interact with PSTN so that IMS users can establish services to PSTN users. The architecture for supporting PSTN and legacy mobile networks is shown in the Fig. 13. The interworking between IMS networks and PSTN/legacy networks occur at two levels: One is the user plane level and the other is the signaling plane level. In the user plane, interworking elements are required to convert IP based media streams on the IMS side to PCM based media streams on the PSTN side. The Media Gateway (MGW) element is responsible for this function. The MGW elements are controlled by the Media Gateway Control Function (MGCF) through the Megaco protocol. On the signaling plane level,

Fig. 14.

Mobile to PSTN session setup

1.

The UE initiates the session by sending a SIP INVITE request, which includes the initial SDP. This request is forwarded all the way to the MGCF. The MGCF initiates a Megaco interaction to pick an outgoing channel and determine the media capabilities (e.g. encoding format) of the MGW.

2.

www.awardsolutions.com

SIP and 3GPP Operations Narayan Parameshwar, Lachu Aravamudhan and Chris Reece
3. The UE and the MGCF negotiate the media characteristics (e.g. number of media flows, codecs, etc.) for this session. The MGCF initiates a Megaco interaction to modify the established connection and instruct the MGW to reserve the resources necessary for this session. After determining the final set of media streams for this session, the UE initiates the reservation procedures for the resources needed for this session. Once the resources have been successfully reserved, the UE informs the MGCF. The MGCF communicates with the PSTN through the T-SGW to set up trunks for this session. The MGCP uses the legacy protocol such as ISUP to setup trunks. MGCF alerts the UE that the destination party has been contacted. The PSTN informs the MGCF that the destination party has answered. MGCF initiates a Megaco interaction to make the connection in the MGW bidirectional. These topics are areas of discussion for another paper when standards are completed.

4.

1 2

5.

6.

7. 8. 9.

RFC 2543 Session Initiation Protocol (SIP) Advanced SIP Series: SIP and 3GPP, Narayan Parameshwar and Chris Reece, www.sipcenter.com 3 RFC 3015 Megaco Protocol Version 1.0 4 3G TS 23.060: General Packet Radio Service (GPRS); Service description; Stage 2 5 3GPP TS 22.228: IP Multimedia (IM) Subsystem Stage 1 6 3GPP TS 23.228: IP Multimedia (IM) Subsystem Stage 2 7 3GPP TS 29.228: IP Multimedia (IM) Subsystem Cx Interface; Signaling Flows and Message Content 8 2748 The COPS (Common Open Policy Service) Protocol 9 3GPP TS 24.228: IP Multimedia (IM) Subsystem Stage 3 10 Advanced SIP Series: Extending SIP, Gary Cote, www.sipcenter.com

About the Authors:


As a Director of Product Management for Award Solutions, Narayan Parameshwar provides consulting and training in areas of cdma2000, UMTS, MPLS and Internet Telephony. As a Senior Consultant for Award Solutions, Lachu Aravamudhan provides consulting and training in UMTS, GPRS, and advanced wireless and Internet applications. As a Senior Consultant for Award Solutions, Chris Reece provides consulting and training in UMTS, Wireless Network Planning, Internet Telephony and Next Generation Networks.

10. MGCF sends a SIP 200 OK final response and the originating UE replies with a SIP ACK message to confirm the session setup. 11. The UE starts the media flow for this session after it receives the SIP 200 OK response.

Conclusion
In this paper, we presented operations of UMTS IP Multimedia Subsystem. We explained the important procedures of the IMS such as service registration, UE origination, UE termination and the interaction with PTSN/legacy wireless networks. We also presented extensions introduced in IMS to SIP and SDP for supporting above operations. This paper has not addressed the handoff and roaming between IMS and legacy wireless networks. The interoperability between IMS and legacy wireless networks are not clearly defined in standards bodies yet. Another area for further study is the interaction of IMS with service elements such as SIP application servers, OSA servers and legacy Intelligent Networks (IN).

About Award Solutions:


Award Solutions, Inc. is a premier provider of training, consulting, and development solutions. We are a "knowledge based" company rooted in the areas of advanced wireless and Internet technologies. Visit us at www.awardsolutions.com.

www.awardsolutions.com

10