<<

. 114
( 132 .)



>>



9.2.1 Call session control function (CSCF)
Data transfer between users of the IMS is organized into sessions. The CSCF is responsible
for session control and is the control point for the following functions:

• user authentication
• call routing
9.2 IP MULTIMEDIA SUBSYSTEM (IMS) 559


• establishing QoS over the IP network
• controlling the generation of call detail records (CDRs) for accounting purposes.

All call/session control signalling in the IMS is performed using the session initiation
protocol (SIP). Three types of CSCF are de¬ned: P-CSCF, S-CSCF and I-CSCF. Each
network will typically provide multiple CSCFs of each type. This allows for load sharing
and supports increased reliability through the use of backup servers.

Proxy CSCF (P-CSCF)
This acts as the ¬rst point of contact for call signalling coming from the UE. The P-CSCF
forwards the call signalling to the serving CSCF (S-CSCF), which is the home network™s
point of control for the call. For a roaming subscriber, the P-CSCF will be located in the
visited network, or more speci¬cally the P-CSCF for a given user will be located in the
same network as the GGSN from which they are receiving service. The P-CSCF is also
responsible for controlling the generation of CDRs for mobile originated calls.

Serving CSCF (S-CSCF)
This carries out the call/session and accounting control for a given subscriber. The S-CSCF
is always located within the subscriber™s home network. This means that all mobile
originated call signalling is routed via the user™s home network. For example, a UK
subscriber roaming in Malaysia who then phones Australia would have their call routed
via the UK. The reason for this is that it allows a network operator to reconcile its
call charging records with its overseas roaming partners for each subscriber. This non-
optimal routing covers only signalling traf¬c; call traf¬c is still forwarded using standard
IP routing between the Australian and Malaysian GGSNs.

Interrogating CSCF (I-CSCF)
The I-CSCF is located at the boundary of the IMS and acts as a point of entry for SIP
signalling coming from outside the operator™s network. This signalling could be:

• a SIP call setup request destined to a subscriber of the operator™s network;
• a SIP call setup request destined to a roaming subscriber within the operator™s network;
• a registration request.

For incoming registration requests the I-CSCF is responsible for assigning an S-CSCF
to the subscriber. The choice of S-CSCF can be made dependent on the identity of the
subscriber (SIP address or international mobile subscriber identify; IMSI), handled on a
load sharing basis or using a main server/backup server arrangement.


9.2.2 Application server (AS)
This provides value-added services to a subscriber. This could be anything from receiving
streaming video service (video on demand) to providing voice and video mail services.
560 RELEASE 5 AND BEYOND (ALL-IP)


9.2.3 Breakout gateway control function (BGCF)
This is used to select the appropriate gateway to forward calls destined for the CS domain
(i.e. the CS breakout point). An S-CSCF will forward all call requests with CS destinations,
which will then forward them to the appropriate MGCF.



9.2.4 Multimedia resource function (MRF)
The MRF is made up of two components, the MRF control and MRF processor, and is
responsible for providing functions such as:

• mixing media for video/voice conferencing (conferencing bridge);
• providing multimedia announcements;
• processing media streams, e.g. audio transcoding.

The MRF functionality is split into a control (MRFC) and a media processing (MRFP)
part, in much the same way as functionality is split between media gateway controller
(mobile switching centre (MSC) Server) and media gateway. The interface between the
two components is controlled using the H.248/MEGACO protocol. The MRFC receives
call control signalling via the SIP protocol (e.g. to establish a Videoconference between
a number of parties).



9.2.5 Media gateway control function and media gateway
(MGCF and MGW)
The MGCF functionality and MGW provide a connection between the IMS and external
CS networks such as ISDN or GSM. The MGCF controls the MGW and interfaces to the
S-SCSF using the SIP protocol. Call signalling (e.g. SS7/ISUP) is forwarded from the
CS network™s signalling gateway to the MGCF using sigtran. The MGCF must translate
messages between SIP and ISUP to provide interworking between the two protocols.
These protocols are explained in the following sections.



9.3 HOME SUBSCRIBER SERVER (HSS)

The HSS contains a master database of all the subscribers on the network and contains
the following information:

• identi¬cation information (user™s telephone number, SIP addresses, IMSI);
• security information (secret authentication keys);
9.3 HOME SUBSCRIBER SERVER (HSS) 561


• location information (current serving GGSN, SRNC, IP address);
• user pro¬le information (subscribed services).

It is also responsible for generating security information such as authentication chal-
lenges and integrity and ciphering keys. The HSS incorporates the home location regis-
ter/authentication centre (HLR/AuC) functionality de¬ned in previous releases and pro-
vides service for three domains, as follows:

• authentication, service pro¬le and location information for IMS (service for CSCF);
• HLR/AuC service for packet switched (PS) domain (service for SGSN and GGSN);
• HLR/AuC service for CS domain (service for R4 MSC server).



9.3.1 HSS Cx interface
The connection between the HSS and CSCF (I-CSCF and S-CSCF) is de¬ned as the
Cx interface. The protocol for the Cx interface is based on DIAMETER and is speci-
¬ed in 3GPP 29.229. For more details of DIAMETER, please refer to Chapter 5. The
protocol uses a query/response approach where queries are sent to the HSS database,
which responds with information about a subscriber. The protocol can also be used by
the I-CSCF or S-CSCF to update values in the HSS database. The following types of
transaction are supported:

1. Registration authorization for subscriber (I-CSCF “ HSS)
2. Query for authentication vectors for subscriber (S-CSCF “ HSS)
3. Registration status noti¬cation (register or de-register) (S-CSCF “ HSS)
4. Network-initiated de-registration (HSS “ S-CSCF)
5. Location query for subscriber (I-CSCF “ HSS)
6. Update of user pro¬le (HSS “ S-CSCF).

The ¬rst three transactions are used in the IMS registration process. The I-CSCF uses
the ¬rst transaction on incoming registration requests to determine if the subscriber can
register. The second and third transactions are used by the S-CSCF when authenticating
the user and update the registration status in the HSS. The details for these procedures
are given in Section 9.7.3.
The network-initiated de-registration allows the HSS to asynchronously de-register a
user. This might be used in the face of a network error due to the fact that the subscriber
has failed to pay their bill or perhaps fraud has been detected on the account.
The location query is used by the I-CSCF to determine how to route incoming calls
destined for subscribers belonging to this network. The HSS responds with the identity
of the S-CSCF with which the user is currently registered. A call ¬‚ow example for this
is show in Section 9.7.5.
562 RELEASE 5 AND BEYOND (ALL-IP)


Table 9.1 Cx protocol to DIAMETER mapping
Transaction DIAMETER message Sent by
header
code = 1, R=1
UAR User authorization request Type I-CSCF
code = 1, R=0
UAA User authorization answer Type HSS
code = 2, R=1
SAR Server assignment request Type S-CSCF
code = 2, R=0
SAA Server assignment answer Type HSS
code = 3, R=1
LIR Location info request Type I-CSCF
code = 3, R=0
LIA Location info answer Type HSS
code = 4, R=1
MAR Multimedia authentication request Type S-CSCF
code = 4, R=0
MAA Multimedia authentication answer Type HSS
code = 5, R=1
RTR Registration termination request Type HSS
code = 5, R=0
RTA Registration termination answer Type S-CSCF
code = 6, R=1
PPR Push pro¬le request Type HSS
code = 6, R=0
PPA Push pro¬le answer Type S-CSCF


The last transaction (update of user pro¬le) can be used by an HSS to update a sub-
scriber™s current service pro¬le. For example, if the user has subscribed to a new video
on demand service, this information would be stored in the service pro¬le and delivered
to the S-CSCF. The S-CSCF will then permit calls for the subscriber destined to the AS
providing that service.
The Cx protocol maps to the DIAMETER base protocol as shown in Table 9.1. This
usage of DIAMETER is de¬ned strictly within UMTS (3GPP 29.229) and is not described
by any IETF draft or RFC documents. All the information elements for the DIAMETER
messages are sent as attribute value pairs (AVPs). Each message will always contain the
user™s public identity, which is used by the HSS to reference the subscription details.
Other elements will include the user™s current S-CSCF and subscription pro¬le.
The UAR and UAA messages are used as part of the registration authorization trans-
action. The UAR (sent from the I-CSCF) contains the user™s public identity as well as
the information about the visited network. The HSS returns with details about the user™s
current registration information (for users already registered) or a decision about the
permission for registration to proceed (reject or accept).
The SAR message is sent to the HSS to update the user™s current S-CSCF. It contains
the identity of the user™s S-CSCF as well as a status value indicating if the user has
recently registered or de-registered at this address. The HSS responds with an SAA
message containing con¬rmation of the user™s status as well as a user pro¬le describing
their current service pro¬le.
The LIR is sent by the I-CSCF to the HSS to locate the current S-CSCF for a given
subscriber. The HSS responds with an LIA message containing the name of the S-CSCF or
a status value indicating that the user is not known at this HSS or is currently unregistered.
The MAR is used to request authentication vectors for a particular subscriber from the
HSS. The request contains both the user™s public and private identity. The MAA message
in reply contains one or more authentication vectors generated for the subscriber.
The network-initiated registration termination procedure is performed using the RTR
and RTA messages. The HSS will send an RTR to the S-CSCF indicating which user it
wants to de-register as well as a reason for the de-registration. The S-CSCF will send
9.4 IP NETWORK DOMAIN SECURITY 563


an RTA in reply con¬rming the de-registration. Finally, the PPR message is used by the
HHS to update a user™s pro¬le at the S-CSCF. The S-CSCF con¬rms this request using
the PPA message.



9.4 IP NETWORK DOMAIN SECURITY
Security within 2G networks has been identi¬ed as a signi¬cant weakness, one factor
being that all signalling within the network is unprotected against snooping and active
attacks such as injecting rogue packets. At the time this was not seen as a signi¬cant issue
since the network was generally controlled by a number of large institutions which could
provide suitable physical protection. With the introduction of 3G this may no longer be
the case and much of the signalling will be carried over IP networks which afford little
protection. Within the RAN, which is the most vulnerable, signalling integrity protection
was introduced to R99, as described in Chapter 6.
TS33.210 speci¬es how the core network signalling carried using IP is to be protected.
The standard security services of con¬dentiality, integrity, authentication and anti-replay
protection are de¬ned. The security model de¬ned for UMTS is based around the con-
cept of a security domain. Each security domain is administered and controlled by one
organization. The architecture for UMTS IP domain security is shown in Figure 9.5.
The connection between two IP network entities on the same operator network or secu-
rity domain is referred to as the Zb interface. Communication between security domains
is controlled by a security gateway (SEG; i.e ¬rewall); the interface between the two
SEGs on different network domains is called Za. 3GPP mandates the use of integrity and
origin authentication using IP security (IPSec) in encapsulating security payload (ESP)
mode for all IP communication over the Za and Zb interfaces. It also states that IPSec
ESP con¬dentiality must be used for all traf¬c over the Za interface but this is optional
for traf¬c over the Zb interface.
The IPSec key exchange algorithm for UMTS is Internet key exchange (IKE). Within a
security domain it would be possible to con¬gure the security associations using manually
pre-shared secrets. However, between domains this would be more problematic since the




IPS
NE-1 NE-1
EC
E IPS E
IKE C Zb Zb IK
IPSEC




IPSEC




IKE
IKE




IKE




<<

. 114
( 132 .)



>>