SIP in 3 G HUT S38 130 Spring

SIP in 3 G HUT S-38. 130 Spring 2001 Tuomo Sipilä Nokia Research Center 1 © NOKIA Tuomo Sipilä/ 5. 4. 2001 S-38. 130 Spring 2001

SIP in 3 G: Content • Background • 3 GPP R 5 architecture • Packet Core Network • IP Multimedia Subsystem • Requreiments • Architecture • SIP protocol in 3 G • 3 G SIP requirements • Problems • Conclusions 2 © NOKIA Tuomo Sipilä/ 5. 4. 2001 S-38. 130 Spring 2001

Background • 3 G is known as UMTS in Europe, as IMT-2000 in Japan • The standarisation work for IP based multimedia started in Autumn 1999 based on input from 3 G. IP • Targets to standardise the required enhancements for the 3 G network so that • IP telephony and multimedia can be provided with equal user perceived quality as with the current mobile network services • 3 G network can function fully based on packet and IP connections (without traditional circuit switched domain) • IP multimedia would in the future provide via IP a wider and more flexible service set than the current networks • SIP was selected as the signalling protocol for IP Multimedia in Spring 2000 3 © NOKIA Tuomo Sipilä/ 5. 4. 2001 S-38. 130 Spring 2001

3 GPP Rel 5 system architecture • Radio Access Network Domain (RAN) For radio access WCDMA based UTRAN or GSM/EDGE based GERAN • Circuit Switched Core Network Domain (CS CN) for Circuit switched services • Packet Switched Core Network Subsystem (PS CN) for provision of PS connectivity services • IP Multimedia Core Network Subsystem (IMSS) for the IP base multimedia services, IPv 6 based system ! • Service Subsystem for operator specific services (e. g. IN and OSA) 4 • Subsystem independent evolution and access independency is the principle © NOKIA Tuomo Sipilä/ 5. 4. 2001 NOTE: Not all interfaces are shown ! S-38. 130 Spring 2001

PS CN Architecture Key issues • Normally Terminal activated the PDP contexts (between GGSN and UE) • Four Qo. S classes defined for packet connection HSS Services Subsystem UTRAN RNC CAP over SS 7/IP Gr • Primary PDP context activation: issue IP address to the terminal Iu • Secondary PDP context: new flow with new Qo. S with same IP address • Traffic Flow Template: Filters the IP flows to the right PDP context 5 Gn Tuomo Sipilä/ 5. 4. 2001 IP Gi/Go Gn Internet GERAN BSC • Gi and Go interface towards IP Multimedia Subsystem (Go for policy control) S-38. 130 Spring 2001 © NOKIA Gc Iu SGSN GGSN PS CN domain

3 G Qo. S Classes in Packet Core network 6 © NOKIA Tuomo Sipilä/ 5. 4. 2001 S-38. 130 Spring 2001

PDP Context activation 7 © NOKIA Tuomo Sipilä/ 5. 4. 2001 S-38. 130 Spring 2001

IM SS architecture Legacy mobile signalling network Applications & Services SCP External IP networks and other IMS networks P/I/S-CSCF R-SGW Sc Mh Ms MRF Mc S-CSCF Cx Cx HSS Gc Gi GGSN Go Mm Mw Mw P-CSCF I-CSCF Mw Gi Tuomo Sipilä/ 5. 4. 2001 S-38. 130 Spring 2001 Mk BGCF Mj MGCF Mc • Gi interface from GGSN to external networks is not shown in the figure © NOKIA Mi Mg MGW 8 BGCF Mm T-SGW PSTN/ Legacy /External

Requirements for IMSS • at least equal end-to-end Qo. S for voice as in circuit switched (AMR Codec based) wireless systems • equal privacy, security or authentication as in GPRS and circuit switched services • Qo. S negotiation possibility for IP sessions and media components by both ends • access independence i. e. the IP Multimedia network and protocols evolve independently of radio access (WCDMA, EDGE/GSM/GPRS, WLAN etc) • applications shall not be standardised • IP policy control possible i. e the operators shall have the means to control which IP flows use the real-time Qo. S bearers • automated roaming with the services in home and visited network • hide the operator network topology from users and home/visited network • the resources shall be made available before the destination alerts • adressing with SIP URL or E. 164 number • procedures for incoming and outgoing calls, emergency calls, presentation of originator identity, negotiation, accepting or rejecting incoming sessions. , suspending, resuming or modifying the sessions • user shall have the choice to select which session components reject or accept 9 © NOKIA Tuomo Sipilä/ 5. 4. 2001 S-38. 130 Spring 2001

Network Elements (1/3) • HSS (Home Subscriber Server) • • User Identification, Numbering and addressing information. User Security information: Network access control information for authentication and authorization User Location information at inter-system level; HSS handles the user registration, and stores inter-system location information, etc. The User profile (services, service specific information…) • P-CSCF (Proxy Call State Control Function) • • 10 © NOKIA First contact point for UE within IM CN subsystem forwards messages to SCSCF Is like proxy or user agent in RFC 2543 (SIP) Is discovered using DHCP during registration or the address is sent with PDP context activation May perform number analysis (e. g. , detect local service numbers) Detect and forward emergency calls Call monitoring and logging (e. g. , billing verification) Authorization of resource usage Tuomo Sipilä/ 5. 4. 2001 S-38. 130 Spring 2001

Network Elements (2/3) • S-CSCF (Serving Call State Control Function) • • Maintains call state required to provide call related services Interacts with Services Subsystem Controls MRF Monitors sessions for billing purposes • I-CSCF (Interrogating Call State Control Function) • • • 11 © NOKIA "is the contact point within an operator's network for all connections destined to a subscriber of that network operator, or a roaming subscriber currently located within that network operator's service area" can be reagarded as a firewall Routes SIP requests from another networks to S-CSCF and MGCF May hide service provider's network topology Selects S-CSCF during registration Tuomo Sipilä/ 5. 4. 2001 S-38. 130 Spring 2001

Network Elements (3/3) • MGCF (Media Gateway Control Function) • • • Protocol conversion between ISUP and SIP Routes incoming calls to appropriate CSCF Controls MGW resources • MGW (Media Gateway) • • • Transcoding between PSTN and 3 G voice codecs Termination of SCN bearer channels Termination of RTP streams • T-SGW (Transport Signalling Gateway) • • Maps call related signalling from/to PSTN/PLMN on an IP bearer Provides PSTN/PLMN <-> IP transport level address mapping • MRF (Multimedia Resource Function) • Performs multiparty call and multi media conferencing functions • BGCF (Breakout Gateway control function ) • • 12 © NOKIA selects the network in which the PSTN interworking should occur selects the MGCF which will perform the interworking Tuomo Sipilä/ 5. 4. 2001 S-38. 130 Spring 2001

Roaming model User A A’s visited network P-CSCF Required on A’s home network registration, optional on sessiion establish S-CSCF I-CSCF Optional User B I-CSCF S-CSCF Required on registration, optional on sessiion establish P-CSCF B’s visited network B’s home network - P-CSCF - Proxy CSCF (Call Session Control Function). The terminals point of contact in the visited network after registration. - I-CSCF - Interrogating-CSCF. Responsible for finding the S-CSCF at registration. May also perform hiding of the S-CSCF network architecture. - S-CSCF - Serving-CSCF. Responsible for identifying user’s service priveleges. Responsible for selecting access to home network application server (service platform) and for providing access to that server 13 © NOKIA Tuomo Sipilä/ 5. 4. 2001 S-38. 130 Spring 2001

SIP in interfaces SLF HSS Dx • SIP in IMSS interface • Gm: P-CSCF - UE • Mw: P-CSCF - S-CSCF and PCSCF - I-CSCF • Mm: S/I-CSCF - external IP networks & other IMS networks • Mg: S-CSCF - BCGF • Mk: BCGF - external IP networks & other IMS networks UA • SIP+ is used to interface the Application servers: • S-CSCF- SIP Application server • S-CSCF- Camel Server • S-CSCF-OSA Service Server 14 © NOKIA Tuomo Sipilä/ 5. 4. 2001 S-38. 130 Spring 2001 Gm Mw PCSCF Cx AS Cx Mw ICSCF Mg SCSCF Mg BCGF MGCF Mc MGW

Current 3 GPP SIP procedures • Local P-CSCF discovery • Either using DHCP or carrying address in the PDP context • S-CSCF assignment and cancel • S-CSCF registration • S-CSCF re-registration • S-CSCF de-registration (UE or network initiated) • Call establishment procedures separated for • Mobile origination; roaming, home and PSTN • Mobile termination; roaming, home and PSTN • S-CSCF/MGCF - S-CSCF/MGCF; between and within operators, PSTN in the same and different network • Routing information interrogation • Session release, Session hold and resume • Anonymous session establishment • Codec and media flow negotiation (Initial and changes) • Called ID procedures • Session redirect, Session Transfer 15 © NOKIA Tuomo Sipilä/ 5. 4. 2001 S-38. 130 Spring 2001

Key issues: Some requirement solutions A) Mobile terminated calls • 1) have network initiated PDP Context activation (required static IP address) • discussion ongoing on push services • options 1: a new element to link the IMSI with the dynamic IP address allocation • option 2: use SMS to trigger PDP activation in the terminal • 2) provide an always on PDP context (signalling PDP context) • the P-CSCF address to the terminal • either during the PDP context activation or • after PDP activation with DHCP procedures, then with DNS to find the IP address • both options possible with current specs B)avoid alerting before the resources are available • 2 phase call setup C) Should SIP use a signalling channel on Radio interface ? • If yes the capabilities needs to be limited and message compression used • will limite the usage of SIP to signalling protocol only 16 © NOKIA Tuomo Sipilä/ 5. 4. 2001 S-38. 130 Spring 2001

Registeration 17 © NOKIA Tuomo Sipilä/ 5. 4. 2001 S-38. 130 Spring 2001

Mobile initiated call setup 1 -22: Session description exchange 23 -31: Resource reservation 32 - 43: Alerting 44 -52: Answering the call 18 © NOKIA Tuomo Sipilä/ 5. 4. 2001 S-38. 130 Spring 2001

Example of INVITE message 19 © NOKIA Tuomo Sipilä/ 5. 4. 2001 S-38. 130 Spring 2001

SIP protocol requirements in 3 GPP • addition of routing PATH header to the SIP messages to record the signalling path from P-CSCF to S-CSCF • location information in the INVITE message to carry the location of the terminal (for instance Cell ID) • emergency call type is needed to indicate the type of emergency call i. e. is it police, ambulance etc. • filtering of routing information in the IM SS before the SIP message is sent to the terminal to hide the network topology from terminal • refresh mechanism inside IM SS • Network-initiated de-registration • 183 Session Progress provisional response for INVITE to ensure that the altering is not generated before PDP contexts for session are activated • Reliability of provisional responses - PRACK method to acknowledge the 183 message • Usage of session timers to keep the SIP session alive • Indication of resource reservation status - COMET method • Security for privacy • Extensions for caller preferences and callee capabilities • Media authorisation token for the Policy Control function to authorise the PDP context with SIP connection in the UE 20 © NOKIA Tuomo Sipilä/ 5. 4. 2001 S-38. 130 Spring 2001

Problems • architecture complexity • call establishment delay problems due to the signalling taking place on multiple levels (RAN, PS CN, IMSS). • establishing a call there will be 6 round trip times (RTT) end to end on SIP level + PDP context reservations • guarantees of Qo. S • Several elements and several IP based interfaces • lengthy standardisation time • suitability of the SIP protocol for the radio interface, long character based messages, compression needed • IETF and 3 GPP standardisation co-operation • Terminal complexity 21 © NOKIA Tuomo Sipilä/ 5. 4. 2001 S-38. 130 Spring 2001

Conclusions: 3 GPP specifics for SIP • the architecture of the IMSS is defined based on 3 G model (home and visited), messages run always via S-CSCF • Registration is mandatory • The CSCFs interrogate the SIP and SDP flows either actively modifying the messages or reading the data, also the I-CSCF hides the names of CSCF behind it • Codec negotiations in 3 GPP do not allow different codecs in different directions • in 3 G networks there is a separation of UNI and NNI interface • due to radio and packet core functionality there are some change proposals to the SIP and SDP • due to the P-CSCF - S-CSCF interface and the 3 G roaming mode there are some requirements to the SIP and SDP protocols • in 3 G SIP is used also to interface the application development elements, they set requirements for SIP and SDP protocols THUS • SIP is suitable for 3 G if the problems (call delays, SIP length, Qo. S) can be solved • Specification work shall take still some time • 3 G and SIP should provide enhaced and rich services NOT be ONLY the replacement for CS 22 © NOKIA Tuomo Sipilä/ 5. 4. 2001 S-38. 130 Spring 2001