sip in 3g - tietoverkkolaboratorio - · pdf file• 3g network can function fully based on...
TRANSCRIPT
1 © NOKIA Tuomo Sipilä/ 5.4.2001S-38.130 Spring 2001
SIP in 3G
HUT S-38.130 Spring 2001
Tuomo Sipilä
Nokia Research Center
2 © NOKIA Tuomo Sipilä/ 5.4.2001S-38.130 Spring 2001
SIP in 3G: Content
• Background
• 3GPP R5 architecture
• Packet Core Network
• IP Multimedia Subsystem• Requreiments• Architecture• SIP protocol in 3G
• 3G SIP requirements
• Problems
• Conclusions
3 © NOKIA Tuomo Sipilä/ 5.4.2001S-38.130 Spring 2001
Background
• 3G 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 3G.IP
• Targets to standardise the required enhancements for the 3G network so that
• IP telephony and multimedia can be provided with equal user perceived quality as with the current mobile network services
• 3G 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
4 © NOKIA Tuomo Sipilä/ 5.4.2001S-38.130 Spring 2001
NOTE: Not all interfaces are shown !
3GPP Rel5 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, IPv6 based system !
• Service Subsystem for operator specific services (e.g. IN and OSA)
• Subsystem independent evolution and access independency is the principle
5 © NOKIA Tuomo Sipilä/ 5.4.2001S-38.130 Spring 2001
PS CN Architecture
RNC
SGSN GGSN
IP
Internet
HSS
BSC
UTRAN
GERANPS CN domain
Iu
Iu
Gi/GoGnGn
Gr Gc
Services Subsystem
CAP over SS7/IP
Key issues
• Normally Terminal activated the PDP contexts (between GGSN and UE)
• Four QoS classes defined for packet connection
• Primary PDP context activation: issue IP address to the terminal
• Secondary PDP context: new flow with new QoS with same IP address
• Traffic Flow Template: Filters the IP flows to the right PDP context
• Gi and Go interface towards IP Multimedia Subsystem (Go for policy control)
6 © NOKIA Tuomo Sipilä/ 5.4.2001S-38.130 Spring 2001
3G QoS Classes in Packet Core network
Table 1. UMTS traffic classes. [23107]
Traffic Class ConversationalRT
StreamingRT
InteractiveNRT
BackgroundNRT
Fundamentalcharacteristics
Preserve timerelation betweeninformationentities of thestream
Conversationalpattern(stringent andlow delay)
Preserve timerelation betweeninformationentities of thestream
Request-responsepattern
Preservepayloadcontent
Destination isnot expectingthe data withina certain time
Preservepayloadcontent
Example ofthe application
Voice Streaming video Webbrowsing
Backgrounddownload ofemails
7 © NOKIA Tuomo Sipilä/ 5.4.2001S-38.130 Spring 2001
PDP Context activation
3. RAB Assignment Response
2.RAB Assignment Request (RAB QoS Profile)
6. Activate PDP Context Accept(PDP Address, QoS Negotiated)
5.Create PDP Context Response(PDP Address, QoS Negotiated, Charging Id)
4.Create PDP Context Request (PDP Address, APN, QoS Negotiated)
1. Activate PDP Context Request (PDP Address, APN, QoS Requested)
GGSNSGSNUTRAN
Radio Access Bearer Setup
UE
1. Activate PDP Context Request (PDP Address, APN, QoS Requested)
4.Create PDP Context Request (PDP Address, APN, QoS Negotiated)
5.Create PDP Context Response(PDP Address, QoS Negotiated, Charging Id)
6. Activate PDP Context Accept(PDP Address, QoS Negotiated)
2.RAB Assignment Request (RAB QoS Profile)
3. RAB Assignment Response
8 © NOKIA Tuomo Sipilä/ 5.4.2001S-38.130 Spring 2001
• Gi interface from GGSN to external networks is not shown in the figure
Applications& Services
SCP
S-CSCF
I-CSCF
GGSNBGCF
MGCF
R-SGW
HSS
MRF
Cx
Gc
MmMh
PSTN/Legacy /ExternalMGW
T-SGWMc
External IP networks
and other IMSnetworks
Go P-CSCF
BGCF
Mk
MjMg
MiMw
Mw
Mc
Mm
Cx
Gi
Gi
Mw
P/I/S-CSCFSc Ms
Legacy mobilesignallingnetwork
IM SS architecture
9 © NOKIA Tuomo Sipilä/ 5.4.2001S-38.130 Spring 2001
Requirements for IMSS• at least equal end-to-end QoS for voice as in circuit switched (AMR Codec based)
wireless systems
• equal privacy, security or authentication as in GPRS and circuit switched services
• QoS 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 QoS 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
10 © NOKIA Tuomo Sipilä/ 5.4.2001S-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)• First contact point for UE within IM CN subsystem forwards messages to S-
CSCF• 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
11 © NOKIA Tuomo Sipilä/ 5.4.2001S-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)• "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
12 © NOKIA Tuomo Sipilä/ 5.4.2001S-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 3G 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 )• selects the network in which the PSTN interworking should occur• selects the MGCF which will perform the interworking
13 © NOKIA Tuomo Sipilä/ 5.4.2001S-38.130 Spring 2001
Roaming model
P-CSCFI-CSCF
A’s visited networkUser A
User B
B’s visited network
A’s home network
S-CSCF
I-CSCF
I-CSCF
S-CSCF
I-CSCFP-CSCF
B’s home network
Optional
Required onregistration,optional on
sessiion establish
Required onregistration,optional on
sessiion establish
- 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
14 © NOKIA Tuomo Sipilä/ 5.4.2001S-38.130 Spring 2001
SIP in interfaces
UA P-CSCF
I-CSCF
S-CSCF
BCGF MGCF
Gm Mw Mw
SLF
Dx Cx
HSS AS
Cx
MGW
Mc
Mg
Mg
SIP ApplicationServer
CAMEL ServiceEnvironment
SIP+
OSA APICx
IM SSF
SIP+
OSAApplication
Server
S-CSCFOSA Service
Capability Server(SCS)
HSSSIP+
CAP
MAP
• SIP in IMSS interface•Gm: P-CSCF - UE•Mw: P-CSCF - S-CSCF and P-CSCF - I-CSCF•Mm: S/I-CSCF - external IP networks & other IMS networks •Mg: S-CSCF - BCGF•Mk: BCGF - external IP networks & other IMS networks
• SIP+ is used to interface the Application servers:
•S-CSCF- SIP Application server•S-CSCF- Camel Server•S-CSCF-OSA Service Server
15 © NOKIA Tuomo Sipilä/ 5.4.2001S-38.130 Spring 2001
Current 3GPP 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
16 © NOKIA Tuomo Sipilä/ 5.4.2001S-38.130 Spring 2001
Some requirement solutionsKey issues:
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
17 © NOKIA Tuomo Sipilä/ 5.4.2001S-38.130 Spring 2001
Registeration
UE RAN I-CSCF(icscf2)
S-CSCF(scscf1)
Visited Network (visited1.net) Home Network (home1.net)
P-CSCF(pcscf1)
DNSGPRS / DHCP
7. SIP Register
HSS
10. SIP 200 OK
12. SIP 200 OK
1. PDP context Establishment
2. CSCF Discovery
5. SIP Register
11. SIP 200 OK
6. Cx-Selection-Info
8. Cx-Location
9. Cx-Profile
4. DNS-Q
13. SIP NOTIFY
3. SIP Register
14. SIP 200 OK
18 © NOKIA Tuomo Sipilä/ 5.4.2001S-38.130 Spring 2001
1. INVITE
35. 180 Ringing
UE#1 P-CSCF S-CSCF
14. 183 SDP
18. PRACK
19. 200 OK
36. PRACK
48. 200 OK
24. COMET
28. 200 OK
49. ACK
10. 183 SDP
8. INVITE
32. 180 Ringing
44. 200 OK
7. Service Control
Visited Network Home Network
13. Authorize QoS Resources
I-CSCF(Firewall)
3. INVITE4. INVITE
11. 183 SDP12. 183 SDP
33. 180 Ringing34. 180 Ringing
46. 200 OK47. 200 OK
45. Service Control
2. 100 Trying
6. 100 Trying5. 100 Trying
9. 100 Trying
15. PRACK
22. 200 OK
27. COMET
31. 200 OK
39. PRACK
40. 200 OK
43. 200 OK
52. ACK
23. ResourceReservation
16. PRACK17. PRACK
20. 200 OK21. 200 OK
25. COMET26. COMET
29. 200 OK30. 200 OK
37. PRACK38. PRACK
41. 200 OK42. 200 OK
50. ACK51. ACK
Mobile initiated call setup
1-22: Session description exchange
23-31: Resource reservation
32- 43: Alerting
44-52: Answering the call
19 © NOKIA Tuomo Sipilä/ 5.4.2001S-38.130 Spring 2001
Example of INVITE messageINVITE sip:[email protected];user=phone SIP/2.0Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]Supported: 100relRemote-Party-ID: John Doe <tel:+1-212-555-1111>Proxy-Require: privacyAnonymity: OffFrom: “Alien Blaster” <sip:B36(SHA-1(+1-212-555-1111; time=36123E5B; seq=72))@localhost>;
tag=171828To: sip:B36(SHA-1(+1-212-555-2222; time=36123E5B; seq=73))@localhostCall-ID: B36(SHA-1(555-1111;time=36123E5B;seq=72))@localhostCseq: 127 INVITEContact: sip:[5555::aaa:bbb:ccc:ddd]Content-Type: application/sdpContent-length: (…)
v=0o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddds=-c= IN IP6 5555::aaa:bbb:ccc:dddb=AS:64t=907165275 0m=audio 3456 RTP/AVP 97 3 96a=rtpmap:97 AMRa=fmtp:97 mode-set=0,2,5,7; maxframes=2a=rtpmap:96 G726-32/8000a=qos:mandatory sendrecv
20 © NOKIA Tuomo Sipilä/ 5.4.2001S-38.130 Spring 2001
SIP protocol requirements in 3GPP • 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
21 © NOKIA Tuomo Sipilä/ 5.4.2001S-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 QoS• 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 3GPP standardisation co-operation
• Terminal complexity
22 © NOKIA Tuomo Sipilä/ 5.4.2001S-38.130 Spring 2001
Conclusions: 3GPP specifics for SIP• the architecture of the IMSS is defined based on 3G 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 3GPP do not allow different codecs in different directions
• in 3G 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 3G roaming mode there are some requirements to the SIP and SDP protocols
• in 3G SIP is used also to interface the application development elements, they set requirements for SIP and SDP protocols
THUS
• SIP is suitable for 3G if the problems (call delays, SIP length, QoS) can be solved
• Specification work shall take still some time
• 3G and SIP should provide enhaced and rich services NOT be ONLY the replacement for CS