Advanced SIP Series: SIP and 3GPP · PDF fileAdvanced SIP Series: SIP and 3GPP Operations ......

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

www.awardsolutions.com 1

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)1 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.

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

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.

UMTSRAN

PS-CN IMSP-CSCF, S-CSCF

System Acquisition

Data Connection Setup

SIP-based IMS procedures

UEIntra

Operator Backbone

GGSNSGSN

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



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, let’s 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. Let’s step through the details of the key steps such as Attach, PDP Context Activation and SIP registration5.

Data Connection Setup

� Attach– Used to establish Mobility Management

contexts at SGSN and UE

� PDP Context Activation– Used to establish GGSN connectivity

UTRAN

Node B

IP

Intra PLMN IP Backbone

RNC

GGSN

UMTS PLMN3G-SGSN

GGSN3G-SGSN

UMTS Attach PDP Context Activation

Fig. 2. Setting up a “pipe” through the UMTS packet network

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 UE’s International Mobile Subscriber Identifier (IMSI). The SGSN uses the IMSI to send a request to the UE’s 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 subscriber’s IMSI.

The successful completion of authentication procedure triggers the SGSN to send a location update (which provides the UMTS UE’s IMSI) to the HLR and this triggers the subscriber’s 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.

PDP Context Activation 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 UE’s current SGSN and the Gateway GPRS Support Node (GGSN) that anchors the PDP address. A record is kept regarding



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.

� Notify the HSS of current location� Authorization by the HSS � Send subscriber profile to S-CSCF

Visited Network

Home Network

S-CSCF

HSS

Authorization

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.



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.

Visited Network

Home Network

UTRAN GGSN P-CSCF3G-SGSN

I-CSCFS-CSCF

HSS

1.Register

2.Register3. Cx Query & Resp.

4. Cx-Select-pull &Resp.

Key:

SIP Message

Cx Message

Authorization

Locate S-CSCF

Fig. 4. The first four steps of SIP registrations

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 P-CSCF’s 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 I-CSCF 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

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 S-CSCF. The HSS sends the required S-CSCF capabilities to the I-CSCF via the Cx-Select-Pull Response message.

Visited Network

Home Network

UTRAN GGSN3G-SGSN

S-CSCF

HSS

5. Register

6. Cx-put & Resp.

7. Cx-pull & Resp.

P-CSCF

I-CSCF

8. 200 OK8. 200 OK8. 200 OK

Key:

SIP Message

Cx Message

Update location

Retrieve profile

Fig. 5. SIP registration continued

5. The I-CSCF, using the name of the S-CSCF, determines the address of the S-CSCF 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. I-CSCF then sends the Register message to the selected S-CSCF. The flow includes the P-CSCF’s name, the subscriber’s 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.



6. The S-CSCF sends a Cx-Put message with the subscriber’s identity and the S-CSCF 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-CSCF’s 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 S-CSCF 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.

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.

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, mobile in home network,

• S-CSCF-to-S-CSCF, origination and termination served by same operator,

• Mobile termination, mobile in home network.

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

I-CSCF/S-CSCF

BGCF/MGCF

IP

PSTN UMTS IMS

UE (R5)

(a)

(b)

(c)

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.

2. 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.

3. A multimedia device connected to the Internet: The destination address may indicate that the destination party is on the



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.

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:

UEI-CSCFP-CSCF S-CSCF Destination

SDP Negotiation

Resource Reservation

Session Setup Confirmation (OK & ACK)

INVITE

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.

2. 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.

3. Resource Reservation: The network reserves the necessary resources for supporting this session, after the media characteristics for this session have been determined.

4. Session Setup Confirmation: Once resource reservation is completed successfully, the terminating point sends a SIP 200 OK final response and the

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 (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.

2. The P-CSCF remembers (from the registration procedure) the next hop CSCF for this mobile. This next hop is either the S-CSCF 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 S-CSCF.

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



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 S-CSCF 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 party’s suggestion on the media type.

6. The S-CSCF forwards the SDP information to P-CSCF through I-CSCF.

7. 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.

Visited Network

Home Network

UTRAN GGSN3G-SGSN

S-CSCF

1. INVITE

I-CSCF

UE

4. INVITE

5. SDP

P-CSCF

3. Service Control

7. Authorize QoS Resources

I-CSCF/S-CSCF

BGCF/MGCF

IP

PSTN

Destinations

2. INVITE2. INVITE

6. SDP6. SDP

Fig. 8. Mobile Origination (Part 1)

8. The P-CSCF then forwards the SDP information to the originating endpoint (i.e. the mobile).

9. 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.

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.

Visited Network

Home Network

UTRAN GGSN3G-SGSN

S-CSCF

8.SDP

I-CSCF

UE

11.Final SDP

P-CSCF

I-CSCF/S-CSCF

BGCF/MGCF

IP

PSTN

Destinations

9. Final SDP

10. Final SDP

10. Final SDP


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



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 P-CSCF.

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.

Visited Network

Home Network

UTRAN GGSN3G-SGSN

S-CSCFI-CSCF

UE15. Success

P-CSCF

I-CSCF/S-CSCF

BGCF/MGCF

IP

PSTN

Destinations

13. Reserve Success

12. ResourcesReservation

16. Ringing 16. Ringing 16. Ringing 16. Ringing 14. Reserve

Success14. Reserve

Success


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.

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

Visited Network

Home Network

UTRAN GGSN3G-SGSN

S-CSCFI-CSCF

UE

P-CSCF

I-CSCF/S-CSCF

BGCF/MGCF

IP

PSTN

Destinations

21. 200 OK

18. Service Control

20. Approval of QoS Commit22. Start Media

Flow

17. 200 OK

19. 200 OK 19. 200 OK

23. ACK23. ACK23. ACK


23. The mobile responds to the 200 OK with a SIP ACK message, which goes through P-CSCF 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 P-CSCF.

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.

2. 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.

3. Resource reservation: The network reserves the necessary resources for supporting this session, after the media characteristics for this session have been agreed on.

4. 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.

5. 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.

UE I-CSCFP-CSCF S-CSCF Originator

SDP Negotiation

Resource Reservation

Session in Progress

INVITE

Session Setup Confirmation (OK & ACK)

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,

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.

GGSN

IP Network

MediaPacket

PSTN

LegacyWirelessNetworks

MGW

VocoderIP

StreamPCM

Stream

MGW

VocoderIP

StreamPCM

Stream

MGW

VocoderIP

StreamPCM

Stream

MGCF T - SGW

Megaco

LegacySignaling overSS7 transportS - CSCF

SIPLegacy

Signaling overIP transport

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.

3. SDP Negotiation

5. Resource Reservation

7. Ringing

10. Session Setup Confirm (OK + ACK)

11. Session in Progress

8. Answer

9. Start Media Flow

UE

P-CSCF/S-CSCF/BGCF

MGCF/T-SGW MGW PSTN

6. Setup PSTN Trunks

1. INVITE

2. Creates Context

4. Reserve Resources

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.

2. The MGCF initiates a Megaco interaction to pick an outgoing channel and determine the media capabilities (e.g. encoding format) of the MGW.



3. The UE and the MGCF negotiate the media characteristics (e.g. number of media flows, codecs, etc.) for this session.

4. The MGCF initiates a Megaco interaction to modify the established connection and instruct the MGW to reserve the resources necessary for this session.

5. 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.

6. 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.

7. MGCF alerts the UE that the destination party has been contacted.

8. The PSTN informs the MGCF that the destination party has answered.

9. MGCF initiates a Megaco interaction to make the connection in the MGW bi-directional.

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).

These topics are areas of discussion for another paper when standards are completed.

1 RFC 2543 Session Initiation Protocol (SIP) 2 “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.

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.

Advanced SIP Series: SIP and 3GPP · PDF fileAdvanced SIP Series: SIP and 3GPP Operations ......

Documents

Transcript of Advanced SIP Series: SIP and 3GPP · PDF fileAdvanced SIP Series: SIP and 3GPP Operations ......