End-to-End QoS Support for SIP Sessions in CDMA2000 Networks. M. Ali Siddiqui, Katherine Guo, Sampath Rangarajan and Sanjoy Paul

End-to-End QoS Support for SIP Sessions in CDMA2000 Networks M. Ali Siddiqui, Katherine Guo, Sampath Rangarajan and Sanjoy Paul

M. Ali Siddiqui Lucent Technologies Room 4F-606A 101 Crawfords Corner Road, Holmdel, NJ 07733 732-332-6944 (voice) 732-949-3930 (fax) alisidd@bell-labs.com Katherine Guo (Contact Author) Room 4G-506 101 Crawfords Corner Road, Holmdel, NJ 07733 732-949-8956 (voice) 732-949-4513 (fax) kguo@bell-labs.com Sampath Rangarajan Room 4E-632 101 Crawfords Corner Road, Holmdel, NJ 07733 732-949-5341 (voice) 732-949-3930 (fax) sampath@bell-labs.com Sanjoy Paul Room 4E-622 101 Crawfords Corner Road, Holmdel, NJ 07733 732-949-3344 (voice) 732-949-3930 (fax) sanjoy@bell-labs.com

With the increasing demand for wireless packet data services, 3G wireless carriers today are faced with the challenge of offering multimedia applications with QoS requirements while at the same time effectively utilizing precious wireless bandwidth. According to the IP Multimedia Subsystem (IMS) framework, end-to-end QoS support requires signaling, traffic regulation and resource allocation capabilities. QoS signaling is used to provision and enforce QoS parameters between endpoints and is conducted in the application layer, network layer and link layer. SIP is used as the application level signaling protocol to establish sessions where SDP parameters that are carried as part of the SIP payload contain session specific information. We discuss how QoS parameters are negotiated between endpoints running SIP user agents through the SIP proxy and AAA server. The Policy Decision Point (PDP) is collocated with the SIP proxy to determine the allowed QoS parameters based on SIP negotiation and local policy of the network. We present how session specific QoS parameters are exchanged via SDP or SIP header fields. We discuss how QoS parameters are enforced using the Policy Enforcement Point (PEP) as part of PDSN in CDMA2000. We report a prototype implementation of the QoS control in IMS including implementation of SIP related to QoS negotiation including SIP user agents, SIP proxy, SIP registrar, and an implementation of PEP in Linux to conduct traffic regulation. Abbreviations, Acronyms and Terms: AAA: Authentication, Authorization and Accounting BS: Base Station BSC: Base Station Controller BTS: Base Transceiver Station CDMA: Code Division Multiple Access CSCF: Call Session Control Function I-CSCF: Interrogating-CSCF P-CSCF: Proxy-CSCF S-CSCF: Serving-CSCF DNS: Domain Name Server DSCP: DiffServ Code Points GRE: Generic Routing Encapsulation HDLC: High-level Data Link Control HSS: Home Subscriber Server HTTP: Hypertext Transfer Protocol IMS: IP Multimedia Subsystem MAC: Medium Access Control MS: Mobile Station MT: Mobile Terminal

PCF: Packet Control Function PEP: Policy Enforcement Point PDF: Policy Decision Function PDSN: Packet Data Serving Node PPP: Point-to-Point Protocol QoS: Quality of Service RAN: Radio Access Network RLP: Radio Link Protocol SCP: Service Control Platform SDP: Session Description Protocol SIP: Session Initiation Protocol TCP: Transmission Control Protocol TE: Terminal Equipment UA: User Agent UDP: User Datagram Protocol VoIP: Voice over IP 1. Introduction As the usage of wireless data service increases, 3G wireless carriers are faced with the challenge of offering multimedia applications with various QoS requirements and supporting users with multiple classes of subscription. At the same time, wireless carriers need to utilize their precious wireless bandwidth effectively. Different applications require different QoS parameters. For example, applications such as email or file transfer have variable bandwidth requirements, but relaxed delay or loss requirements because of their non-real time nature. Applications such as multimedia streaming require high bandwidth, moderate delay and jitter because of buffering, whereas applications such as Voice over IP (VoIP) and online gaming require low delay and low jitter. Other applications such as video conferencing require both high bandwidth and low delay / jitter. On top of different QoS requirements for different applications, different users also have different QoS needs. For example, different users can be offered Gold, Silver and Bronze class of services by service providers. When there is network resource contention, traffic for Gold users will be given higher priority than that of Silver and Bronze users. As a result, proper support for end-to-end QoS in wide area 3G networks is becoming increasingly important. In general, QoS means low latency, low delay, low jitter, low loss, adequate bandwidth and above all, good end-user experience. However, all the metrics do not necessarily apply to all applications and all users.

End-to-end QoS requires support at the application layer, network layer, link layer, and medium access control (MAC) layer. 3GPP, the standards body in charge of UMTS standards has recently proposed the IP Multimedia Subsystem (IMS) [4] architecture to provide differentiated services to different classes of traffic. 3GPP2, the standards body in charge of CDMA2000 standards is also adding IMS for CDMA network architecture towards the goal of a harmonized 3GPP/3GPP2 IMS network architecture [11]. This paper discusses the existing CDMA2000 network architecture and the proposed IMS architecture in the context of CDMA2000. It focuses on how QoS signaling should be conducted in the application layer using Session Initiation Protocol (SIP) and Session Description Protocol (SDP). In particular, it presents how QoS parameters for the SIP session are negotiated between SIP endpoints through the control of IMS network components. It discusses how one particular QoS parameter -- bandwidth, is enforced at the Packet Data Serving Node (PDSN) in CDMA2000. Discussions about QoS for SIP sessions in 3GPP-based networks can be found in [16]. The rest of the paper is organized as follows: Section 2 presents the QoS architecture in CDMA2000. Section 3 discusses how SIP and SDP are used for user registration, session setup, QoS negotiation and QoS enforcement within the QoS enabling architecture. Two approaches for QoS negotiation are presented and contrasted. Section 4 describes the prototype test-bed we have built to realize QoS signaling in the application layer in the IMS framework. Performance results are discussed to compare the two design choices of QoS negotiation. Section 5 concludes the paper. 2. CDMA2000 Architecture for QoS Support We first discuss the current CDMA2000 architecture that does not provide support for QoS. We then discuss the QoS enabling CDMA2000 architecture and the support for QoS that is provided in both the data plane and the control plane. The focus of this paper is on the control plane architecture for supporting QoS, and more specifically signaling related to SIP. With this in mind, we describe the data plane only to the extent required to describe the features of the QoS enabling control plane. 2.1 Current CDMA2000 Data Plane Architecture without QoS Support Figure 1 shows the components of the current CDMA2000 architecture [8,10]. The Mobile Station (MS) consists of two components, Terminal Equipment (TE), for example a laptop, and

PPP Session TE Rm Interface MS MT RLP Session BSC GRE Session PCF PDSN GRE Session I N T E R N E T TE BTS Figure 1. CDMA2000 network architecture without QoS support. Mobile Terminal (MT), for example a PCMCIA CDMA2000 card. The Packet Data Serving Node (PDSN) is the gateway between the wireless network and the IP network (Internet). A data connection with the network has to be first established from the MS. This is achieved by setting up a PPP [25] connection between the TE and the PDSN. Data packets are transported from the TE to the PDSN in the form of PPP frames. Packets from the Internet, destined to the TE and received at the PDSN are transported over the same PPP connection to the TE. Between the TE and the MT, a serial link carries traffic in the form of a byte stream. The interface between the TE and the MT is the Rm interface [12]. The CDMA2000 Base Station (BS) consists of two components, Base Transceiver Station (BTS) and Base Station Controller (BSC). The CDMA2000 airlink is between the MT and the BTS both of which have radio interfaces. Normally, multiple BTSs are connected to a BSC through point-to-point links. PPP frames received at the MT (in the reverse direction from TE to PDSN) and at the BSC (in the forward direction from PDSN to TE) are transported over a Radio Link Protocol (RLP) session to the BSC and MT respectively [9]. There is one RLP session per PPP session. Data received at the MT and the BSC are framed into RLP frames before they are sent to the BSC and MT respectively. RLP allows for retransmission of RLP frames thereby ``hiding'' frame errors from the higher layer protocols. There is another component between the BSC and the PDSN which is the Packet Control Function (PCF). The main functionality of the PCF is to direct PPP connection requests from the TE to the appropriate PDSN that should handle the TE. The Radio Access Network (RAN) encompasses the part of the network from the MS to the PCF. Data traffic between the BSC and the PCF is sent over General Route Encapsulation (GRE) [18] tunnels, one per PPP session. The GRE frames between the BSC and the PCF are normally transported over a private network

(could be an IP network). Between the BSC and the PCF, A9 interface is used for signaling control messages and A8 interface is used to transport data packets [10]. Data between the PCF and the PDSN are transported over another set of GRE tunnels, again one per PPP session. The network that connects the PCF with the PDSN could be the public IP network. Between the PCF and the PDSN, A11 interface is used for signaling control messages and A10 interface is used to carry data packets [10]. There are two main points to be noted in the data plane architecture described above. First, there is a single PPP session carrying all data traffic in the form of PPP frames from the TE to the PDSN and from the PDSN to the TE. These PPP frames are transported over the same RLP session between the TE and the BSC and over the same GRE tunnel between the BSC and PCF and between the PCF and the PDSN. Thus, there is one-to-one mapping between a PPP session, an RLP session, a GRE tunnel between the BSC and PCF and a GRE tunnel between the PCF and PDSN. Second, when PPP data frames are sent from the TE as a byte stream to the MT, the PPP frame boundary information is lost. This means, a PPP frame can span multiple RLP frames and GRE frames; RLP and GRE frames may contain full or parts of multiple PPP frames as well. In the reverse direction, in order to enable regeneration of the PPP frames at the PDSN, High-level Data Link Control Protocol (HDLC) framing is performed before the PPP frames are sent from the TE [26]. In the forward direction, when IP packets are received at the PDSN and are put into PPP frames to be sent to the TE, again HDLC framing is performed. The above session establishment procedure is adequate when no quality of service differentiation is required on traffic to and from a single user. But when QoS differentiation is required, mapping all data to and from a TE onto a single RLP session and then onto a single GRE session disables the capability to handle different classes of traffic to and from the same user differently. To illustrate this difficulty, let us first consider the traffic in the reverse direction from the TE to the PDSN. When PPP frames are sent from the TE, class based scheduling (say, based on TCP and IP information) could be performed on the PPP frames. But once the PPP frames are converted to a byte stream and sent over the Rm interface and then as RLP frames to the BSC, these RLP frames are delivered at the BSC in sequence (sequence numbers on the RLP frames ensure this). Further, when the byte stream is framed into GRE frames and sent over the GRE tunnels between the BSC and the PCF and then between the PCF and the PDSN, these GRE frames are also delivered in sequence at the delivery points. Consider a mix of real-time and non real-time traffic being sent

over the same RLP session. Firstly, it is possible that real-time traffic and non real-time traffic form part of the same RLP frame which means there is no way to handle these two classes of traffic differently once they leave the TE. Secondly, each RLP session has parameters such as number of retransmissions that applies to all RLP frames in the session. This means, even though retransmissions may not make sense for real-time traffic there is no way to turn it off just for that class of traffic. Thirdly, because of ordered delivery, if an RLP frame that carries non real-time traffic is lost, until it is retransmitted and is subsequently received at the BSC, real-time RLP frames that follow the lost frame, even if they are received at the BSC, cannot be delivered to the higher layer. Similarly, because GRE frames are delivered in sequence, there is no way to provide service differentiation within the IP networks that carry traffic between the BSC and the PCF and between the PCF and the PDSN. Traffic from the PDSN to the TE faces a similar problem. When IP packets from the Internet are received at the PDSN, some type of class-based scheduling can be performed before they are sent over the PPP session. But once this is done, there is no flexibility to provide differentiated services within the IP network until the frames reach the BSC as all classes of traffic are carried over the same GRE tunnel. At the BSC, there is no way to differentiate the traffic and hence class-based scheduling cannot be implemented. 2.2 CDMA2000 Data Plane Architecture with QoS Support In order to get around the problems illustrated above, a service architecture to support service differentiation will use multiple RLP sessions and multiple GRE tunnels to carry traffic to and from a TE as specified in TIA-IS-835-C [8]. Following the standards, we assume there is a oneto-one correspondence between a TE and a user, and use TE and user interchangeably. There is still a single PPP session carrying traffic from the TE to the PDSN and from the PDSN to the TE. This means there is a single PPP state machine per user at the TE and at the PDSN. But different PPP frames on this PPP session, each carrying a different class of traffic, will go over different service instances between the MT and the BSC. Each service instance is implemented by a separate RLP session. Between the BSC and the PCF and between PCF and PDSN, there are multiple GRE sessions per TE each of which carry a different class of traffic.

IP Packet IP Packet TCP (web) UDP (video) TCP (web) UDP (video) TE Rm Interface MT BSC RLP Session PPP Session PCF PDSN GRE GRE Session Session I N T E R N E T TE Figure 2. CDMA2000 network architecture with QoS support. This example shows two service instances for the same user, one for web traffic using TCP, the other for streaming video traffic using UDP. Figure 2 illustrates, for the same user, traffic for different service instances is carried over a separate RLP session between the MT and the BSC, a separate GRE session between the BSC and the PCF, and a separate GRE session between the PCF and the PDSN. Once a separate RLP session is used to carry a single class of traffic, service classes can be prioritized between the MT and the BSC based on the RLP session. For traffic from the BSC to the MT, class-based scheduling can be used to give priority to RLP frames on specific RLP sessions. Further, the RLP session parameters can be configured to match the traffic class. For example, retransmission can be turned off on a RLP session that carries real-time traffic. Similarly, GRE frames that carry different classes of traffic can be handled differently because they are transported over different GRE sessions. For example, IP packets that encapsulate GRE frames that belong to different GRE tunnels (and hence different service classes) can be marked with DiffServ markings [13] to specify the class of traffic that they carry. This way, if a private IP network is used between the BSC and the PCF, the intermediate routers can handle the different classes differently. Similarly, the routers on the IP network (normally the public IP network) between PCF and PDSN can handle different classes of traffic differently. In addition, packets arriving over different GRE sessions at the PDSN to be sent over the Internet can be DiffServ marked so that DiffServ enabled routers on the Internet can provide differentiated service for these packets. In the next section, we consider the control plane architecture to support QoS.

2.3 CDMA Control Plane Architecture with QoS Support We start by describing the end-to-end QoS architecture in CDMA2000 networks based on IMS [4]. The network entities that are involved in end-to-end QoS signaling and their relevant features are described below. MS (Mobile Station): These are clients that required end-to-end QoS either to another client or to a server. The Session Initiation Protocol (SIP) User Agent (UA) resides on the MS. P-CSCF (Proxy-Call Session Control Function): This is an element in the visited network that regulates the QoS of a visiting MS. This regulation is based on the visited network s local policy. An example of the local policy could be no streaming service during work hours. The P-CSCF may behave as a SIP Proxy or a SIP UA. PDF: The Policy Decision Function within the visited network resides on the P-CSCF according to Release 5 of the IMS. PDF has access to local policies for each visiting MS. The policies could be integrated in PDF or in a separate database that PDF has access to [6]. PDSN: This the gateway between the wireless network and the IP network within the visited network. The PDSN terminates PPP sessions from the MS. PEP: The Policy Enforcement Point resides on the PDSN and receives QoS authorization information from P-CSCF (PDF) in order to perform traffic regulation on the bearer path. S-CSCF (Serving-Call Session Control Function): This is an element within the home network that regulates the QoS for a MS. It may behave as a SIP Registrar, a SIP Proxy or a SIP UA. It shall reject connection attempt to or from users that are barred from establishing IMS connections after completion of registration [4]. For IMS session control entities P/I/S-CSCF, only the S-CSCF has IMS subscription profile data. There are two places where S-CSCF is involved in checking user profile. 1) Regular subscription check (bill-paid or not) is done during user registration process. This is where session control is done. 2) QoS related subscription check and regular subscription check (bill-paid or not) is done during origination/termination session initiation using SDP in SIP messages. Bill

payment status may have changed since the last time a subscriber registered. S-CSCF can catch it during session initiation. I-CSCF (Interrogating-Call Session Control Function): This is an element within the home network that routes SIP requests from another network to S-CSCF. It identifies the S-CSCF to serve a subscriber. It does not request subscriber profile data. HSS (Home Subscriber Server) resides in the Home Network and stores user authentication information and service profile for the user. SCP (Service Control Platform): This network element resides on the S-CSCF in the Home Network. After S-CSCF downloads service profile and registration information from the HSS, it sends this information to the service control platform (SCP) [4]. The SCP checks the user profile against the IMS subscriber profile data received from the HSS. MS Visited Network 8 Home Network 1 7 2 P-CSCF I-CSCF 3 9 HSS PDF 13 4 10 5 11 15 S-CSCF PDSN 14 6 SCP PEP 12 CSCF: Call Session Control Function I-CSCF: Interrogating-CSCF P-CSCF: Proxy-CSCF S-CSCF: Serving-CSCF HSS: Home Subscriber Server MS: Mobile Station PEP: Policy Enforcement Point PDF: Policy Decision Function PDSN: Packet Data Serving Node SCP: Service Control Platform Bearer Signaling Step 1: Registration 1-6 Step 2: SIP Session Initiation 7-14 Step 3: Traffic Regulation at PDSN(PEP) 15 Figure 3. Network entities involved in application layer signaling using SIP and traffic regulation in IMS. Figure 3 illustrates the above network elements and functions specified in the IMS framework for CDMA2000. According to the IMS architecture, QoS signaling and traffic regulation follows three sequential steps: (1) MS or user registration, (2) session initiation, including media and QoS negotiation, and (3) traffic regulation. Each of these steps is an integral part of the QoS signaling and regulation process. MS or user registration is required, because during this step, the QoS profile of the user is

downloaded to various IMS network elements as shown in mini-steps 1 through 6 in Figure 3. Session initiation and QoS negotiation is needed because this is the process where per session QoS requirements are decided as shown in mini-steps 7 through 14 in Figure 3. Traffic regulation is the final component to enforce QoS parameters agreed upon from the first two steps as data traffic flows through PDSN in ministep 15 in Figure 3. The detailed interaction between these elements in order to offer end-to-end QoS is presented in Section 3. 3. Three Steps for QoS Signaling and Traffic Regulation This section describes in detail the three sequential steps for QoS signaling and traffic regulation: (1) MS or user registration, (2) session initiation, including media and QoS negotiation, and (3) traffic regulation. Session Initiation Protocol (SIP) [24] is used for user registration, session management and media and QoS negotiation. Session management covers initiation and termination of a SIP session using a three-way handshake with INVITE, OK and ACK messages. Media and QoS negotiation is conducted using Session Description Protocol (SDP) [17] payload of SIP messages [14]. SDP negotiation contains parameters that are related to QoS, for example, media stream codec and bandwidth requirements. However, there are additional QoS aspects not addressed by SIP and SDP, therefore not addressed by this paper. In particular, the ability to monitor lost packets, to perform Cyclic Redundancy Check (CRC) based on current network conditions and many other QoS aspects are not addressed. SIP is an application layer control and signaling protocol for creating, modifying, and terminating multimedia sessions with one or more participants. The participants could be two MSs or an MS and an application server. SIP invitations (INVITE message) and other type of SIP messages carry session descriptions in SDP that allow participants to agree on a set of compatible media types and QoS requirements. SIP provides a registration function that allows users to upload their current locations with proxy servers, and proxy servers can help route requests to the user's current location. SIP runs on top of different transport protocols such as TCP or UDP. 3.1 Step 1: Registration

Before an MS can get any service from the network, it has to register with its S-CSCF in its home network first. Visited Network Home Network MS (SIP UA) P-CSCF I-CSCF HSS S-CSCF 1. Register 2. Register 3. Cx-Query 4. Cx-Query Resp 5. Cx-Select-Pull 6. Cx-Select-Pull Resp 7. Register 8. Cx-Put 9. Cx-put Resp 10. Cx-Pull 11. Cx-Pull Resp 12. Service Control 15. 200 OK 14. 200 OK 13. 200 OK Figure 4. SIP registration process. The registration process is shown in Figure 4 and the registration steps are as follows [4]. The MS registers with the S-CSCF in its home network. MS sends SIP REGISTER request through P-CSCF and I-CSCF to S-CSCF (Steps1-7). Step 1: The MS sends the SIP REGISTER message to the P-CSCF. Among other things, the SIP REGISTER message includes MS s home domain name. Step 2: Upon receiving SIP REGISTER message, the P-CSCF checks the home domain name for the MS, and discovers the corresponding I-CSCF which is the entry point to the home network for the MS. The P-CSCF then forwards SIP REGISTER message to the I- CSCF. Step 3: The I-CSCF sends the Cx-Query to the HSS that contains information for the HSS to handle registration, retrieve location information for the MS and authorize the user. Step 4: The HSS checks whether the user is registered. It also checks if the user is allowed to register in the P-CSCF network. If either check fails, the HSS rejects the registration attempt. If both checks succeed, the HSS returns Cx-Query Resp containing the name of

the S-CSCF if known and the S-CSCF capabilities in case a new S-CSCF needs to be selected. Step 5: If no name for the S-CSCF is returned, the I-CSCF sends Cx-Select-Pull to the HSS to request more information related to the required S-CSCF capabilities. Step 6: The HSS replies to the I-CSCF with Cx-Select-pull Resp containing the required S-CSCF capabilities. Step 7: After finding the name and address of the S-CSCF, the I-CSCF forwards the SIP REGISTER message to the S-CSCF. S-CSCF sends Cx-Put to the HSS (Step 8). HSS replies with Cx-Put Resp to acknowledge (Step 9). S-CSCF downloads relevant information from user profile from HSS including name, address, security and QoS information. (Steps 10-11). S-CSCF then sends register information to the service control platform (SCP), which is co-located with the S-CSCF and performs whatever service control procedures that are appropriate. (Step 12). S-CSCF returns SIP 200 OK message back to MS through I-CSCF and P-CSCF. (Steps 13-15). Note that service control function is performed at the S-CSCF. Service control refers to the process of checking against IMS subscriber profile data received for the MS from the corresponding HSS. This checking is necessary at registration time because the S-CSCF needs to perform the necessary checking in order to populate charging related information or to make the decision to reject or accept this request or future INVITE requests from this MS. Service control covers all subscription check including QoS subscription. 3.2 Step 2: Session Initiation using SIP/SDP After registration, when an MS needs to establish a SIP session with an application server or with another MS, a session initiation procedure is followed. We discuss the case where two MSs are establishing a session with QoS requirements. The case for session initiation between an MS and an application sever is similar.

Figure 5 displays a simple session setup and termination process between two SIP User Agents UA1 and UA2 involving their respective SIP proxy servers, Proxy1 and Proxy2. Proxy1 is the proxy server in charge of UA1's domain, and similarly, Proxy2 is in charge of UA2's domain. Before a session initiation takes place, we assume that both SIP UAs have registered their current location with their respective SIP proxies. SIP proxies have also registered with some form of Domain Name Server (DNS) so that through inquiries to the DNS, any other SIP proxy can route the request for UA1 to Proxy1 and route the request for UA2 to Proxy2. SIP UA1 SIP Proxy1 SIP Proxy2 SIP UA2 INVITE 100 Trying 180 Ringing 200 OK INVITE 100 Trying 180 Ringing 200 OK INVITE 180 Ringing 200 OK ACK Session in Progress BYE 200 OK Figure 5. Basic session setup and termination using SIP. SIP is based on an HTTP [15]-like request/response transaction model. Each transaction consists of a request and at least one response. When UA1 wants to make a connection to UA2, it sends an INVITE request to Proxy1. Proxy1 replies with a 100 Trying response signifying Proxy1 is working on finding UA2. After consulting the DNS with the domain of UA2, Proxy1 sends the request to Proxy2, which is in charge of UA2's domain and has the current location of UA2. Proxy2 in turn forwards the request to UA2 and returns a 100 Trying response to Proxy1. UA2 returns with a 180 Ringing response reporting UA2 is being ringed, and this response is forwarded to Proxy2, Proxy1, and eventually to UA1. After UA2 decides to accept the call, it sends a 200 OK response to UA1 through Proxy2 and Proxy1. This response contains the IP address of UA2's current location, so UA2 can be directly contacted from now on. After receiving the 200 OK response, UA1 sends an ACK message directly to UA2, bypassing the SIP proxies, and finishes the three-way handshake. A session is now established, and data traffic flows

user1 s visited network user1 s home network user2 s home network user2 s visited network SIP UA1 P-CSCF1 S-CSCF1 S-CSCF2 P-CSCF2 SIP UA2 INVITE SDP1 100 Trying QoS checking (pass) INVITE SDP1 100 Trying QoS checking (pass) INVITE SDP1 100 Trying QoS checking (pass) INVITE SDP1 100 Trying QoS checking (pass) INVITE SDP1 100 Trying 183 Ses. Prog. SDP2 QoS Authorization 183 Ses. Prog. SDP2 183 Ses. Prog. SDP2 QoS Authorization 183 Ses. Prog. SDP2 183 Ses. Prog. SDP2 PRACK SDP2 PRACK SDP2 PRACK SDP2 PRACK SDP2 PRACK SDP2 200 OK (PRACK) 180 Ringing 200 OK 200 OK (PRACK) 180 Ringing 200 OK 200 OK (PRACK) 180 Ringing 200 OK 200 OK (PRACK) 180 Ringing 200 OK 200 OK (PRACK) 180 Ringing 200 OK ACK Session in Progress Figure 6. Session setup with QoS negotiation between UA1 and UA2 where QoS parameter checking at the S-CSCFs and P-CSCFs is successful. directly between UA1 and UA2. Either UA can terminate a session. In this example, UA1 sends a BYE request to terminate the session, and UA2 replies with a 200 OK response. Figure 5 displays the basic session setup process using two SIP proxies. However, there could be multiple proxies on the path between the two UAs. In the IMS architecture, the entity involved in SIP session

setup at the P-CSCF, I-CSCF and S-CSCF is the SIP proxy. For the rest of the paper we use the terms x- CSCF (P/I/S-CSCF) and SIP proxy at x-cscf interchangeably. The basic session setup process can be extended with QoS negotiations by adding SDP to SIP requests and responses. Figure 6 presents a typical example of how a session with QoS is setup in IMS between SIP UAs through their respective P-CSCFs in their visited networks and their respective S-CSCFs in their home networks [1,7,14]. Assume user1 is represented by UA1 and user2 is represented by UA2. User1 and user2 s P-CSCFs are P-CSCF1 and P-CSCF2 respectively. Their S-CSCFs are S-CSCF1 and S-CSCF2 respectively. As per the IMS architecture shown in Figure 3, each S-CSCF in the user s home network is associated with an HSS at which user profiles are stored. During the registration process described in Section 3.1, user1 s profile is downloaded at S-CSCF1 and user2 s profile is downloaded at S-CSCF2. First the initiator UA1 sends an INVITE request towards UA2 to initiate a session. In addition, this request also contains UA1's QoS proposal in SDP1. SDP1 is called the offer SDP according to the offer/answer model of SDP [22]. The INVITE request is forwarded in sequence through P-CSCF1, S- CSCF1, S-CSCF2, P-CSCF2 and reaches UA2. During this process, P-CSCF1 checks SDP1 against its local network policy, S-CSCF1 checks SDP1 against its local network policy and user1 s profile, S- CSCF2 checks SDP1 against its local network policy and user2 s profile, and P-CSCF2 checks SDP1 against its local network policy. Only if all these checks are successful, the INVITE request with SDP1 reaches UA2. After receiving UA1's QoS proposal in SDP1, UA2 replies with a response 183 Session Progress with its QoS proposal in the answer SDP, SDP2. Notice SDP2 could either be identical to SDP1 or be a subset of SDP1 according to the offer/answer model of SDP [22]. Because SDP1 has been successfully checked by the x-cscfs, SDP2 is also allowed by the network and is forwarded to UA2 through the x- CSCFs on the 183 Session Progress response. When the 183 Session Progress message with SDP2 reaches P-CSCF2, P-CSCF2 uses SDP2 parameters in order to define the QoS resource authorization, and the Policy Decision Function (PDF) for P-CSCF2 authorizes every media component negotiated for the session in SDP2, and pushes the authorization information to the Policy Enforcement Point (PEP) in user2 s visited network. The interaction between P-CSCF2 and its PDF is shown as mini-step 13 in Figure 3, and the interaction between the PDF and the PEP is shown as mini-step 14 in Figure 3. Similarly, when the 183 Session Progress message with SDP2 reaches P-CSCF1, P-CSCF1 uses SDP2 parameters in order to define the QoS resource authorization, and the PDF for P-CSCF1 authorizes every

media component negotiated in SDP2, and pushes the authorization information to the PEP in user1 s visited network. Again, the interaction between the P-CSCF2 and its PDF, and between the PDF and the PEP is reflected as mini-steps 13 and 14 respectively in Figure 3. After receiving 183 Session Progress with SDP2, UA1 knows that SDP2 contains the authorized QoS parameters for this session. UA1 sends an acknowledgement using the PRACK message with SDP2 as its payload [23]. Once the PRACK message reaches UA2, UA2 also has the confirmation that SDP2 contains the authorized QoS parameters. UA2 replies with 200 OK for PRACK to acknowledge the receipt of the PRACK message. After this round of offer-answer process [22], both UA1 and UA2 agree on SDP2 to be the set of authorized QoS parameters. And a session can be established. At this point, session establishment resumes and UA2 sends a 180 Ringing response back to UA1. After UA2 decides to accept the call, it sends UA1 a 200 OK response to the INVITE request, and UA1 replies with an ACK message finishing the 3-way handshake, after which the session starts. If any of the QoS checks at any of the P-CSCFs or S-CSCFs is not successful, there are two design choices. The first choice is to allow SIP Proxies at the P-CSCFs and S-CSCFs to modify the SDP carried on SIP messages (SDP1 in Figure 6) to reflect what QoS parameters are allowed by the network based on local network policy and user profile information before forwarding the SDP. However, IETF RFC 3261 [24] explicitly disallows SIP proxies from manipulating the content of SIP message bodies mainly because of the end-to-end security feature offered by SIP. If end-to-end authentication is used, SIP proxies cannot alter the SDP. If end-to-end encryption is used, SIP proxies will not even be able to look at the SDP to modify it. In order to overcome the restriction of SIP proxy, recently there have been several IETF drafts proposing new SIP headers to carry QoS information regarding the session [19,21]. Therefore, to be RFC 3261 compliant, SIP proxies can change SIP headers during the QoS negotiation phase instead of modifying SDPs. The second choice is for the SIP proxies at the S-CSCFs and P-CSCFs to return a rejection message back to the UA where the offer SDP is from, for the example, UA1 in Figure 6. This is also the option used by 3GPP standards [2,7]. To be specific, if a P-CSCF finds any QoS parameters not allowed by the local network policy, it shall return a 488 (Not Acceptable Here) response containing SDP payload specifying the set of allowed QoS parameters by the local policy [2]. Similarly, if a S-CSCF finds any QoS parameters not allowed by user s profile or local policy, it shall return a 488 (Not Acceptable Here) response containing SDP payload specifying the set of allowed QoS parameters by the user profile

user1 s visited network user1 s home network user2 s home network user2 s visited network SIP UA1 P-CSCF1 S-CSCF1 S-CSCF2 P-CSCF2 SIP UA2 INVITE SDP1 100 Trying QoS checking (pass) INVITE SDP1 100 Trying QoS checking (fail) 488 SDP1a INVITE SDP2 100 Trying QoS checking (pass) INVITE SDP2 100 Trying QoS checking (pass) INVITE SDP2 100 Trying QoS checking (fail) INVITE SDP3 183 Ses. Prog. SDP4 183 Ses. Prog. SDP4 QoS Authorization 183 Ses. Prog. SDP4 488 SDP2a 100 Trying QoS checking (pass) INVITE SDP3 100 Trying 183 Ses. Prog. SDP4 QoS Authorization 183 Ses. Prog. SDP4 PRACK SDP4 PRACK SDP4 PRACK SDP4 PRACK SDP4 PRACK SDP4 200 OK (PRACK) 180 Ringing 200 OK 200 OK (PRACK) 180 Ringing 200 OK 200 OK (PRACK) 180 Ringing 200 OK 200 OK (PRACK) 180 Ringing 200 OK 200 OK (PRACK) 180 Ringing 200 OK ACK Session in Progress Figure 7. Session setup with QoS negotiation between UA1 and UA2 where QoS checking at S- CSCF1 and P-CSCF2 is unsuccessful. According to the second design choice, SIP proxies return error code 488 Not Acceptable Here to SIP UAs.

information and local policy. Figure 7 shows the rejection of SIP messages in the scenario where QoS checking fails at S-CSCF1 and P-CSCF2. In this example, when S-CSCF1 receives the INVITE request with SDP1, SDP1 has been checked by P- CSCF1 according to user1 s visited network local policy. However, the checking at S-CSCF1 against user1 s QoS profile fails or the checking against user1 s home network local policy fails. As a result, S- CSCF1 returns a 488 Not Acceptable Here error message back to UA1. This message contains SDP1a as its payload specifying the QoS parameters allowed by user1 s profile and its home network local policy. After receiving SDP1a, UA1 constructs SDP2 within the limit of user1 s QoS profile and its home network local policy, and sends it on another INVITE request to S-CSCF1. After checking SDP2 against user1 s profile and its home network local policy, S-CSCF1 forwards it on an INVITE request towards UA2. When P-CSCF2 receives the INVITE request with SDP2, SDP2 has already been checked by P- CSCF1, S-CSCF1 and S-CSCF2. In this example, the QoS checking by P-CSCF2 against its local network policy fails on SDP2, and P-CSCF2 returns a 488 Not Acceptable Here error message back to UA1. This message contains SDP2a, which specifies the QoS parameters allowed by P-CSCF2. After UA1 receives SDP2a, it constructs SDP3 within the limit of local policy of UA2 s visited network, and sends it on anther INVITE request towards UA2. When UA2 receives the INVITE with SDP3, it knows SDP3 has been successfully checked by the network. UA2 then replies with a 183 Session Progress message towards UA1 with SDP4 as its answer SDP. The rest of the session setup process is the same as in Figure 6 where QoS checking is successful at all the CSCFs. The QoS negotiation process shown in Figure 7 can be illustrated further in a detailed scenario. For simplicity, we assume user profile specifies the same bandwidth in both send and receive directions for a user. Further we assume user1 has 4 Mbps bandwidth in its user profile and allowed by its home network local policy, and 10 Mbps allowed by its visited network local policy. We assume user2 has 5 Mbps bandwidth in its user profile and allowed by its home network local policy, but only 1Mbps allowed by its visited network local policy. In this scenario, UA1 sends INVITE towards UA2 with SDP1 specifying 10 Mbps bandwidth requirement and two supported codecs A and B. The bandwidth requirement for codec A is 3 Mbps, and for codec B, lower than 1 Mbps. When P-CSCF1 receives the INVITE request with SDP1, it checks with its local network policy. Since 10Mbps is allowed for user1, SDP1 is forwarded to S-CSCF1. S-CSCF1 checks its local policy and user1 s profile. Since both allow only 4Mbps, S-CSCF1 returns SDP1a on a 488 Not Acceptable Here message back to UA1 specifying 4Mbps as allowed bandwidth and A and B as allowed codecs. After receiving the feedback from S-CSCF1, UA1 in turn constructs SDP2 specifying

4Mbps bandwidth requirement and two supported codecs A and B. UA1 then sends SDP2 on another INVITE request towards UA2. SDP2 is checked by P-CSCF1 and S-CSCF1 as expected. When S-CSCF2 receives SDP2, it checks with user2 s profile and its home network local policy both of 5Mbps bandwidth limit. SDP2 is successfully checked since only 4Mbps is requested. S-CSCF2 then forwards SDP2 to P- CSCF2. After receiving SDP2, P-CSCF2 checks its local network policy for user2. Since only 1Mbps is allowed, P-CSCF2 rejects the request and sends a 488 Not Acceptable Here message back to UA1 with SDP2a as its payload specifying 1Mbps as the bandwidth limit and one allowed codec B. After UA1 receives this feedback, it constructs a new SDP3 with 1Mbps bandwidth requirement and codec B as the only supported codec. UA1 then sends SDP3 on another INVITE request towards UA2. This time, SDP3 is successfully checked by P-CSCF1, S-CSCF1, S-CSCF2 and P-CSCF2 before reaching UA2. After UA2 receives SDP3, it agrees with the QoS parameter negotiation and copies SDP3 in SPD4 and sends SDP4 in a 183 Session Progress message towards UA1 to acknowledge the receipt of INVITE message as well as to acknowledge SDP4 specifies the agreed QoS parameters. The QoS negotiation phase therefore finishes, and the rest of the session establishment process proceeds. 3.3 Step 3: Traffic Regulation by PDSN(PEP) After the application layer QoS negotiation between two users and the network, network elements need to be configured to provision QoS, and to regulate traffic according to the agreed maximum bandwidth and maximum QoS class for the session. Traffic regulation is conducted at the PDSN of the user s visited network. Policy Enforcement Point (PEP) is a logical element physically located on the PDSN. PEP s function is to police uplink and downlink IP packet flows on the bearer path according to the maximum bandwidth and QoS class specified after QoS negotiation using SIP. PEP has a service-based policy gate function. The gate can be selectively opened or closed based on IP destination address and port [4]. The decision of traffic regulation is made at Policy Decision Function (PDF) at the P-CSCF. In other words, the gate function at the PEP is controlled by the PDF. The PDF makes its decision based on two sources of input information. By default, the PDF always pushes local network policy to the PEP. Examples of local network policy include no streaming traffic during work hour, or maximum bandwidth 1Mbps for users in certain organization. Local network policy is enforced regardless if SIPbased QoS negotiation actually happens. If QoS negotiation for the SIP session is conducted, the P-CSCF sends the SDP agreed by network elements and end users to the PDF, and the PDF pushes this

information to the PEP [6]. As a result, the PEP regulates traffic based on local network policy, combined with the bandwidth negotiated for the session set up by SIP [1]. In addition to bandwidth enforcement at the PEP, because the PEP is co-located with the PDSN, traffic can be separated into different classes by the PEP. Recall from Section 2.2 that at the bearer plane, traffic that belongs to different classes will be sent between the MT (Mobile Terminal) and the PDSN using multiple service instances. Each service instance will be mapped to a different RLP session between the MT and the BSC and to a different GRE session between the BSC and the PCF and between the PCF and the PDSN. The PEP can classify traffic arriving from the Internet and send them on different service instances towards the MT. Similarly, traffic arriving from the PCF on different GRE sessions, destined to the Internet could be DiffServ marked using appropriate DiffServ Code Points (DSCP) [13] so that this traffic could be provided differentiated services by DiffServ capable routers on the Internet. To perform the above-mentioned classification, the PEP requires policy information pertaining to different flows to be downloaded. The signaling required to download this information is in the proposal stage and is beyond the scope of this paper. 4. Prototype Implementation To demonstrate the benefits of QoS negotiation and traffic regulation within the IMS framework in CDMA2000 networks and to experiment with different methods for QoS signaling using SIP and SDP, we have implemented a prototype test-bed. The test-bed allows us to experiment with the control path and the data path. In our prototype, the MS is located in its home network and there is only one CSCF (with the functionalities of both S-CSCF and P-CSCF) in the network. The related IMS network elements are shown in Figure 8. This figure is identical to the SIP signaling related IMS network elements shown in Figure 3 except there is only one network and one CSCF. As a result, MS or user registration happens in mini-steps 1 though 3, session initiation happens in mini-steps 4 through 8, and traffic regulation happens when data traffic starts flowing in mini-step 9. The compwinhough 3, seb k i2 2[(shown in Figurtr)p 9W(we ha )]TT/TT1 1 Tf0 Tc 0 T2521.6011 0 Tm( )TT/TT0 1 T

Home Network MS 9 1 4 CSCF 2 5 7 PDF 3 6 PDSN 8 SCP PEP HSS CSCF: Call Session Control Function HSS: Home Subscriber Server MS: Mobile Station PEP: Policy Enforcement Point PDF: Policy Decision Function PDSN: Packet Data Serving Node SCP: Service Control Platform Bearer Signaling Step 1: Registration 1-3 Step 2: SIP Session Initiation 4-8 Step 3: Traffic Regulation at PDSN(PEP) 9 Figure 8. IMS network elements implemented in the prototype test-bed. CDMA2000 Network AAA Server UA2 CSCF (SIP Proxy&PDF) CDMA2000 Network RAN UA2 UA1 BS PCF PDSN PEP Internet Appl Server Bearer Signaling BS: Base Station CSCF: Call Session Control Function HSS: Home Subscriber Server PCF: Packet Control Function PEP: Policy Enforcement Point PDF: Policy Decision Function PDSN: Packet Data Serving Node RAN: Radio Access Network UA: User Agent Figure 9. Test-bed setup in CDMA2000 networks. On the bearer path, we have set up a CDMA2000 radio access network (RAN) with homegrown prototypes of the PCF and the PDSN. When a MS first powers up, the SIP UA on the MS registers with the CSCF and the CSCF downloads the user s profile from the AAA server. When two MSs try to setup a session with end-to-end QoS, SIP session initiation and QoS negotiation happens between the two SIP

UAs through the CSCF according to the procedures described in Section 3.2. In particular, the QoS requirements are authorized by CSCF against user profiles retrieved from the AAA server. After the session is setup successfully, PDF informs PEP of the agreed-upon QoS parameters specified in the SDP, and PEP regulates traffic according to this QoS policy. Currently, our prototype is limited to the case where the PEP performs the gating function and bandwidth control. We will be extending the prototype to support multiple service instances on the bearer path which will allow the PEP to perform class based routing on different service instances for traffic from the Internet and DiffServ marking for Internet bound packets as referred to in Section 3.3. In Section 3.2, we have discussed two designs for QoS negotiation: (1) allow the SIP Proxy (CSCF) to modify SDP, and (2) do not allow the SIP Proxy to modify SDP. The obvious drawback of the second design is the extra round-trip delay required between CSCFs and the called UA. Figure 6 shows that a typical SIP session setup with QoS negotiation requires three round trips between the two UAs through a number of CSCFs. The connection between a UA and its CSCF has to go through the radio access network (RAN). This delay is in the order of hundreds of milliseconds, whereas the delay between CSCFs inside the core network is in the order of milliseconds. Therefore the three round trips between the two UAs in Figure 6 can be regarded as six round trip delays between a UA and its P-CSCF. With the first design choice where the CSCF is allowed to modify SDP, the session setup time is therefore the same as the successful case in Figure 6 with six round trip delays between a UA and its P-CSCF. With the second design choice where a CSCF is not allowed to modify SDP, any QoS authorization failure at any of the CSCFs will incur an extra round of message exchange between the CSCF and the called UA, which implies roughly an extra round trip delay between a UA and its P-CSCF. In the best case where every QoS authorization at every CSCF is successful, the session initiation time is roughly six times the round trip delay between a UA and its P-CSCF. However, in the worst case where every single QoS authorization fails at every single CSCF, there will be four extra round trip delays added since there are four CSCFs on the path. This will make the total session setup time to be ten times of the round trip delay between a UA and its P-CSCF. This represents a 66% increase in session setup time. Obviously the second design sacrifices protocol performance to be compliant with SIP standards [24]. 5. Conclusion In this paper, we discuss how end-to-end QoS is supported in CDMA2000 networks using the IMS framework. We focus on how SIP and SDP in the application layer are used for QoS negotiation between endpoints. In particular, we present how IMS elements work together to facilitate QoS

negotiation on the control plane and traffic enforcement on the bearer plane. We compare and contrast two design choices regarding how SDP should be handled during QoS negotiation process. We also report a prototype test-bed implementation of the IMS framework for end-to-end QoS negotiation and traffic control. Acknowledgement We would like to thank E-Ling Lou, Peter McCann for insightful discussions and Anne Lee for valuable guidance during this work. References 1. 3rd Generation Partnership Project, End-to-end Quality of Service (QoS) Signaling Flows (Release 5), 3GPP TS 29.208-v5.7.0, Mar, 2004, <http://www.3gpp.org/ftp/specs/2004-03/rel-5/29_series/29208-570.zip>. 2. 3rd Generation Partnership Project, IP Multimedia Call Control Protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP)-Stage 3 (Release 5), 3GPP TS 24.229-v5.8.0, Mar, 2004, <http://www.3gpp.org/ftp/specs/2004-03/rel- 5/24_series/24229-580.zip>. 3. 3rd Generation Partnership Project, IP Multimedia (IM) Session Handling; IM Call Model- Stage 2 (Release 5), 3GPP TS 23.218-v5.7.0, Dec, 2003, <http://www.3gpp.org/ftp/specs/2004-03/rel-5/23_series/23218-570.zip>. 4. 3rd Generation Partnership Project, IP Multimedia Subsystem (IMS)-Stage 2 (Release 5), 3GPP TS 23.228-v5.12.0, Mar, 2004, <http://www.3gpp.org/ftp/specs/2004-03/rel- 5/23_series/23228-5c0.zip>. 5. 3rd Generation Partnership Project, IP Multimedia (IM) Subsystem Cx and Dx Interfaces; Signaling Flows and Message Contents (Release 5), 3GPP TS 29.228-v5.7.0, Mar, 2004, <http://www.3gpp.org/ftp/specs/2004-03/rel-5/29_series/29228-570.zip>. 6. 3rd Generation Partnership Project, Policy Control over Go Interface (Release 5), 3GPP TS 29.207-v5.7.0, Mar, 2004, <http://www.3gpp.org/ftp/specs/2004-03/rel-5/29_series/29207-570.zip>. 7. 3rd Generation Partnership Project, Signaling flows for the IP multimedia Call Control based on SIP and SDP-Stage 3 (Release 5), 3GPP TS 24.228-v5.8.0, Mar, 2004, <http://www.3gpp.org/ftp/specs/2004-03/rel-5/24_series/24228-580.zip> 8. 3rd Generation Partnership Project 2, CDMA2000 Wireless IP Network Standard", 3GPP2 P.S0001-C, Also known as TIA-IS-835.C Aug, 2003, <http://www.3gpp2.org>. 9. 3rd Generation Partnership Project 2, Data Service Options for Spread Spectrum Systems, 3GPP2 C.S0017-0-v5.0, Feb, 2003, <http://www.3gpp2.org/public_html/specs/c.s0017-0_v5.0.pdf>.