Transcript SIP in 3G: Content

SIP in 3G
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 3G: Content
• Background
• 3GPP R5 architecture
• Packet Core Network
• IP Multimedia Subsystem
• Requreiments
• Architecture
• SIP protocol in 3G
• 3G SIP requirements
• Problems
• Conclusions
2
© NOKIA
Tuomo Sipilä/ 5.4.2001
S-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
3
© NOKIA
Tuomo Sipilä/ 5.4.2001
S-38.130 Spring 2001
3GPP Rel5 system architecture
4
•
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
© 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)
HSS
• Four QoS classes defined for
packet connection
Services
Subsystem
UTRAN RNC
CAP over SS7/IP
Gr
• Primary PDP context
activation: issue IP address to
the terminal
Iu
• 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)
5
© NOKIA
Tuomo Sipilä/ 5.4.2001
Gc
Gn
IP
Gi/Go
Gn
Internet
GERAN BSC
S-38.130 Spring 2001
SGSN
Iu
GGSN
PS CN domain
3G QoS Classes in Packet Core network
Table 1. UMTS traffic classes. [23107]
Traffic Class
Fundamental
characteristics
Example of
the application
6
© NOKIA
Tuomo Sipilä/ 5.4.2001
Conversational
RT
Preserve time
relation between
information
entities of the
stream
Conversational
pattern
(stringent and
low delay)
Voice
Streaming
RT
Preserve time
relation between
information
entities of the
stream
Streaming video
S-38.130 Spring 2001
Interactive
NRT
Requestresponse
pattern
Background
NRT
Destination is
not expecting
the data within
a certain time
Preserve
payload
content
Preserve
payload
content
Web
browsing
Background
download of
emails
PDP Context activation
UE
UT RAN
SGSN
GGSN
1. Activat e PDP Context Request
(PDP Address, APN, QoS Requested)
2.RAB Assignment Request
(RAB QoS Profile)
Radio Access Bearer Setup
3. RAB Assignment Response
4.Creat e PDP Context Request
(PDP Address, APN, QoS Negotiated)
5.Creat e PDP Context Response
(PDP Address, QoS Negotiated, Charging Id)
6. Activat e PDP Context Accept
(PDP Address, QoS Negotiated)
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
Mm
Mw
Mw
Go
P-CSCF
I-CSCF
Mw
Gi
MGCF
• Gi interface from GGSN to
external networks is not shown in
the figure
Tuomo Sipilä/ 5.4.2001
S-38.130 Spring 2001
Mk
BGCF
Mj
MGW
© NOKIA
Mi
Mg
Mc
8
BGCF
Mm
T-SGW
PSTN/
Legacy /External
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
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 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 )
•
•
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
I-CSCF
Optional
User B
I-CSCF
I-CSCF
P-CSCF
S-CSCF
Required on
registration,
optional on
sessiion establish
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
Cx
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
• SIP+ is used to interface the
Application servers:
•S-CSCF- SIP Application server
•S-CSCF- Camel Server
•S-CSCF-OSA Service Server
Gm
Mw
UA
ICSCF
BCGF
MGCF
Mc
SIP Application
Server
MGW
SIP+
Cx
HSS
S-CSCF
SIP+
CAP
CAMEL Service
Environment
Tuomo Sipilä/ 5.4.2001
Mg
SCSCF
Mg
IM SSF
© NOKIA
Cx
Mw
PCSCF
MAP
14
AS
S-38.130 Spring 2001
SIP+
OSA Service
Capability Server
(SCS)
OSA API
OSA
Application
Server
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
15
© NOKIA
Tuomo Sipilä/ 5.4.2001
S-38.130 Spring 2001
Some requirement solutions
Key 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
16
© NOKIA
Tuomo Sipilä/ 5.4.2001
S-38.130 Spring 2001
Registeration
Home Network (home1.net)
Visited Network (visited1.net)
UE
RAN
GPRS / DHCP
P-CSCF
(pcscf1)
DNS
I-CSCF
(icscf2)
S-CSCF
(scscf1)
1. PDP context Establishment
2. CSCF Discovery
3. SIP Register
4. DNS-Q
5. SIP Register
6. Cx-Selection-Info
7. SIP Register
8. Cx-Location
9. Cx-Profile
10. SIP 200 OK
11. SIP 200 OK
12. SIP 200 OK
13. SIP NOTIFY
14. SIP 200 OK
17
© NOKIA
Tuomo Sipilä/ 5.4.2001
S-38.130 Spring 2001
HSS
Mobile initiated call
setup
V is ite d N e tw o r k
UE#1
H o m e N e tw o r k
I- C S C F
( F ir e w a ll)
P -C S C F
S -C S C F
1 . IN V IT E
2 . 1 0 0 T r y in g
3 . IN V IT E
4 . IN V IT E
5 . 1 0 0 T r y in g
6 . 1 0 0 T r y in g
1-22: Session
description exchange
7 . S e r v ic e C o n t r o l
8 . IN V IT E
9 . 1 0 0 T r y in g
10. 183 SDP
11. 183 SDP
12. 183 SDP
1 3 . A u t h o r iz e Q o S R e s o u r c e s
14. 183 SDP
15. PRACK
16. PRACK
17. PRACK
18. PRACK
19. 200 OK
20. 200 OK
21. 200 OK
22. 200 OK
23-31: Resource
reservation
2 3 . R e so u rce
R e s e r v a t io n
24. C O MET
25. C O MET
26. C O MET
27. C O MET
28. 200 OK
29. 200 OK
30. 200 OK
31. 200 OK
3 2 . 1 8 0 R in g in g
3 3 . 1 8 0 R in g in g
3 4 . 1 8 0 R in g in g
3 5 . 1 8 0 R in g in g
36. PRACK
37. PRACK
38. PRACK
32- 43: Alerting
39. PRACK
40. 200 OK
41. 200 OK
42. 200 OK
43. 200 OK
44. 200 OK
4 5 . S e r v ic e C o n t r o l
46. 200 OK
47. 200 OK
44-52: Answering the
call
18
© NOKIA
Tuomo Sipilä/ 5.4.2001
48. 200 OK
49. ACK
50. ACK
51. ACK
S-38.130 Spring 2001
52. ACK
Example of INVITE message
INVITE sip:[email protected];user=phone SIP/2.0
Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]
Supported: 100rel
Remote-Party-ID: John Doe <tel:+1-212-555-1111>
Proxy-Require: privacy
Anonymity: Off
From: “Alien Blaster” <sip:B36(SHA-1(+1-212-555-1111; time=36123E5B; seq=72))@localhost>;
tag=171828
To: sip:B36(SHA-1(+1-212-555-2222; time=36123E5B; seq=73))@localhost
Call-ID: B36(SHA-1(555-1111;time=36123E5B;seq=72))@localhost
Cseq: 127 INVITE
Contact: sip:[5555::aaa:bbb:ccc:ddd]
Content-Type: application/sdp
Content-length: (…)
v=0
o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd
s=c= IN IP6 5555::aaa:bbb:ccc:ddd
b=AS:64
t=907165275 0
m=audio 3456 RTP/AVP 97 3 96
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; maxframes=2
a=rtpmap:96 G726-32/8000
a=qos:mandatory sendrecv
19
© NOKIA
Tuomo Sipilä/ 5.4.2001
S-38.130 Spring 2001
20
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
© 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 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
21
© NOKIA
Tuomo Sipilä/ 5.4.2001
S-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
22
© NOKIA
Tuomo Sipilä/ 5.4.2001
S-38.130 Spring 2001