8.4 ims network architecture – a closer look 243

243

The anchoring of the media in TrGW also has an implicit topology-hiding effect. Without anchoring, the SDP answer provided to the other network would contain the transport address of, for example, a media-plane entity in the operator’s network, such as A-SBG or IM-MGW. By media anchoring in TrGW, the SDP answer will contain the transport address of the TrGW. During SIP session establishment, it is preferable to negotiate equal codec(s) between users, so as to prevent the necessity for media transcoding at TrGW (or another entity).

Alternatively, IBCF allows the user plane to be established end to end, without traversing the TrGW. In such an example, the user plane may theoretically not traverse the operator’s network at all. That would be the case when the destination subscriber is currently “IMS roaming”, i.e. registered through a P-CSCF in an IMS network other than the Home IMS network (see Figure 8.13 ).

Another group of interworking is formed by calls arriving from the circuit-switched (CS) network, such as the Public Switched Telephony Network (PSTN) or Public Land Mobile Network (PLMN) – see Figure 8.14 .

Operators often restrict interconnection with the IMS network to PSTN or PLMN. Often, the PSTN or PLMN to which the IMS network interconnects is the PSTN or PLMN of

FIGURE 8.13

Transparent end-to-end routing of media.

FIGURE 8.14

Network architecture related to ingress routing from a CS network.

8.4 IMS Network Architecture – A Closer Look

CH008.indd 243CH008.indd 243 6/30/2011 12:17:13 PM6/30/2011 12:17:13 PM

244 CHAPTER 8 Introduction to the IMS Network

the same operator. Even when the operators use both a PSTN and a PLMN, interworking with IMS may be confi ned to PSTN. In that manner, the operator has fewer interworking agreements to arrange. When a call from the operator’s IMS network needs to be routed to a network from another operator, existing PSTN interconnect agreements are then used. Interworking between the IMS and CS networks is done through the media gateway control function (MGCF) and IP multimedia–media gateway (IM-MGW).

MGCF caters for protocol conversion between the control-plane protocol used in the CS network, typically ISUP, and the control-plane protocol used in the IMS network, SIP. Instead of ISUP, the CS network may use BICC or SIP-I. ISUP and SIP are different paradigms, as far as protocol messages are concerned. ISUP and SIP also use different state models. ISUP messages need to be mapped to corresponding SIP request or response messages and vice versa. Not all capability that is defi ned on ISUP can be mapped to SIP, and vice versa.

Figure 8.15 shows a typical message sequence for a call arriving from a CS domain. 3GPP TS 29.163 specifi es the exact mapping between ISUP messages (and parameters)

and SIP messages (including headers, parameters, SDP). Within the IMS network, there is no

FIGURE 8.15

Message sequence for ingress routing from a CS domain.


245

ringback tone generated in the user plane; the SIP terminal establishing a call is responsible for its own ringtone generation to the calling party. When MGCF receives 180 Ringing from the remote party, it instructs the IM-MGW to generate local ringback tone into the CS network.

When MGCF receives ISUP IAM, it creates a SIP INVITE and sends the INVITE to a “SIP server”. MGCFs may have the capability to confi gure SIP profi les . MGCF parses the received ISUP IAM through number analysis (e.g. A-number analysis and B-number analy-sis), resulting in the selection of a SIP profi le. The SIP profi le includes a set of parameters that are used for the SIP signaling from MGCF into the IMS network, such as:

● SIP server address; default will be I-CSCF, for terminating SIP session handling ● Transport protocol (UDP, TCP) ● URI format (tel: URI versus sip: URI) for R-URI and for certain SIP headers.

When ISUP in the CS network is being transported over the SS7 network, the ISUP signaling must fi rst be converted to ISUP over IP. ISUP over IP is done in accordance with 3GPP TS 29.202. Refer to Figure 8.16.

SS7 signalingfunction

Signaling gatewayfunction

Media gatewaycontrol function

SS7

SIP signalingfunction

SIP

IPIP

SCTP

M3UA

ISUP

TCP/UDP/SCTP

IPL1

SCTP

M3UA

MTP2

MTP3

IP

TCP/UDP/SCTP

SIP

L1

MTP2

MTP3

ISUP

IP IP

ISUP SIP

FIGURE 8.16

ISUP SS7-based signaling adaptation to ISUP IP-based signaling. Source: 3GPP™ TS 29.163 v8.13.0, fi gure 2. © 2010 3GPPTM and TRs are the property of ARIB, ATIS, CCSA, ETSI, TTA and TTC who

jointly own the copyright in them. They are subject to further modifi cations and are therefore provided to you “ as is” for information

purposes only. Further use is strictly prohibited.

The conversion between ISUP over SS7 and ISUP over IP is done in a signaling gate-way (SGw). SGw represents a functional entity. Practically, the SGw is often integrated in MGCF.

Besides conversion between ISUP and SIP, there is also conversion between TDM-based media and RTP-based media. It is a common goal that there is no transcoding required for the media. For example, the call in the CS domain may be established with a circuit for 64 kb/s PCM A-law encoding (G.711). The same coding may be used in the packet-switched network. Whereas the media in a CS network is transported through a TDM channel, in E1




links (or STM links) the same media is transported in an IMS network through RTP encap-sulation. The RTP media stream will have an RTCP channel associated with it.

For the CS–IMS interworking case, the media is always traversing the IMS network (via IM-MGW). For the IMS–IMS interworking case, on the other hand, IBCF may decide not to anchor the media in a TrGW. The reason media anchoring is necessary in media gateway CS–IMS interworking is because both control plane and user plane use different protocols in the respective networks.

MGCF may be deployed as a stand-alone node, in which case it is referred to as a media gateway controller (MGC). Alternatively, MGCF may be integrated in mobile softswitch (MSS) or in telephony softswitch (TSS) – see Figure 8.17 .

Also, the IM-MGW may be integrated in circuit-switched mobile MGW (CS-MGW), as used in the mobile network. These integrations of functional entities allow for optimized network deployment, with fewer nodes and fewer interfaces. The MSS that includes MGCF may be a visited MSC, i.e. MSC with connection to radio access network (RAN). The inter-face between MSS with integrated MGCF and combined CS-MGW � IM-MGW is a combi-nation of the Mc reference point (between the MSC server and CS-MGW) and Mn reference point (between MGCF and IM-MGW). Even when integrated, MGCF and IM-MGW remain separate functional entities. However, when functional entities are integrated, signaling between these entities does not have to comply with standardized reference points.

There may be multiple MGCFs in the IMS network, as well as multiple IM-MGWs. These functional entities do not contain user data. Interworking between CS networks may there-fore run through one of a multitude of MGCFs, e.g. nearest MGCF, with other MGCFs as a fallback option. The MGCF will, when handling a call, select an IM-MGW. One IM-MGW is controlled by one MGCF. One MGCF may control one or more IM-MGWs. An IM-MGW may be split into logical MGWs , whereby each logical MGW is controlled by one MGCF.

Egress routing, from an IMS network to other networks, is explained with reference to Figure 8.18 . Only control-plane entities are shown. ViG is short for video gateway.

When S-CSCF handles originating SIP session establishment, one of the steps to be taken by S-CSCF is to determine the destination serving network. The destination serving network

FIGURE 8.17

Integration of IMS border gateway in PLMN nodes.


247

is derived from the R-URI. If a call is established to a phone number, then the S-CSCF may attempt to obtain a SIP URI associated with the phone number. The SIP URI would then be used for egress routing. Obtaining the SIP URI from the phone number is done through ENUM query (see section 8.7 for more details on ENUM). If, however, the ENUM query by the S-CSCF does not render a SIP URI, then the S-CSCF will initiate “break-out”. The rationale of the break-out is that the S-CSCF is a SIP server and can route only on SIP URIs, not on phone numbers. The break-out implies that the call will be routed to another network that is capable of routing on phone numbers. An example of such a network is PSTN or PLMN. This other network may be the network that is determined to be the serving network for the destination subscriber. Alternatively, the network to which the break-out occurs is not determined to be the serving network for the destination subscriber, but will act as an inter-mediate network, routing the call further to the appropriate serving network.

For break-out, the S-CSCF forwards the SIP INVITE (or other request message) to a break-out gateway control function (BGCF). The BGCF is a SIP proxy that forwards the request further, to a break-out gateway. The BGCF may be deployed on a designated host or may be integrated into S-CSCF. BGCF will select the (most) appropriate break-out gateway for this request, which may be based on one or more of the following criteria:

● Originating party (calling party) ● Destination party (called party) ● Destination network ● Number portability information

Note

Indication of destination network or number portability of this call may have been received by S-CSCF from ENUM and included as a parameter in the R-URI.

● Media session type – SDP offer (call type; e.g. voice or voice � video) ● Preferred long-distance carrier.

FIGURE 8.18

Egress routing through BGCF (break-out).




Note Preferred long-distance carrier could form part of the calling subscriber subscription profi le or may be provided by an application server.

The selection of break-out gateway by the BGCF may be based on internal confi guration or may be done with the aid of an external database query. The exact behavior of the BGCF, with respect to selecting break-out gateway, is vendor specifi c.

A common use of the BGCF is the selection of an MGCF, for routing the call into the CS domain, such as PLMN. Within the CS domain, the call would then be routed fur-ther to the appropriate destination, based on techniques like B-number analysis, number portability, and intelligent networks. Routing the break-out call through an MGCF implies that the media of this call will be anchored in an IM-MGW, controlled by the MGCF. Break-out gateway selection based on call type may be done to apply distinctive routing for voice calls and video calls. Whereas voice calls may be routed to a voice-only MGCF, video calls would be routed to a video-capable MGCF, also referred to as video gateway (ViG).

For specifi c interworking cases, the BGCF may select an IBCF for break-out. This method may be applied when the BGCF has determined that a SIP-based network-to-network interworking agreement exists with the destination network. In this case, the desti-nation subscriber may be an IMS subscriber, but the operators have not shared ENUM infor-mation. This case is illustrated in Figure 8.19 . The break-out from BGCF to IBCF is subject to certain conditions, such as:

1. Request URI is a SIP URI. 2. The domain name part of the R-URI points to the network serving the called party; this

would not have to be the case when the R-URI is a phone number with an enterprise-specifi c domain name.

FIGURE 8.19

Break-out to other IMS network.


249

The default action by the IBCF in the receiving IMS network is to forward the INVITE request (or other SIP request) to I-CSCF for further processing, including HSS query and forwarding to S-CSCF.

There may be multiple IBCFs in an IMS network, as well as multiple TrGWs. Neither of these maintains a subscriber state between sessions. Per break-out/break-in case, one of a group of IBCFs may be selected, typically through DNS-based load sharing. DNS-based load sharing implies that DNS returns multiple host names in response to an SRV query. The DNS client uses one of these hosts for IP routing. The multiple host names received from DNS may have a priority or a weight factor associated with them.

8.5 REGISTRATION In this section, we describe the registration process in detail. The goal of registration was briefl y mentioned in Chapter 6, namely to create and maintain binding in a SIP registrar. Such binding allows the establishment of IP communication sessions to the subscriber using a public user identity. The binding is used to forward the IP communication sessions to the subscriber’s current IP address. Before looking into the registration procedure, we consider the subscriber data structure in HSS. An IMS subscriber is provisioned in HSS with one or more of each of the following two identifi cation items:

● IMS public user identity (IMPU). IMPU is used to identify an IMS subscriber over the public communication network, e.g. to establish a communication session with that subscriber. It is also used as identifi cation of the originator of a communication session. The IMPU conforms to the structure of Universal Resource Identifi er (URI). Examples include: ● sip:[email protected] ● tel:�31163279911 ● sip:�[email protected] ● sip:[email protected]

● IMS private user identity (IMPI). IMPI is used together with the IMPU to identify the service profi le of the subscriber and to determine what authentication should be used for the registration. IMPI has the format of Network Access Identifi er (NAI) as defi ned in IETF RFC 4282 (it has the form of a URI, excluding the schema). Examples of IMPI include: ● [email protected] ● �[email protected] ● [email protected]

The IMPU sip:[email protected] and the IMPI [email protected] are temporary IMPU and IMPI respectively. Temporary IMPU and temporary IMPI may be used when IMS registration

8.5 Registration



takes place from a mobile phone (GPRS, UMTS) that is not equipped with an IMS sub-scriber identifi cation module (ISIM). 3GPP TS 23.003 describes how temporary IMPU and temporary IMPI are constructed, based on the International Mobile Subscriber Identity (IMSI).

IMPU and IMPI form part of the subscriber profi le in HSS (see Figure 8.20 ). In the example in Figure 8.20 , IMPU #2 is associated with both IMPI #1 and IMPI #2. IMPUs within one implicit registration set (IRS) may have the same service profi le or may have dif-ferent service profi les. The concept of IRS is explained in a later section.

When an IMS subscriber registers, in other words creates binding in S-CSCF, the IMS subscriber provides his/her IMPU (or one of his/her IMPUs) to the IMS network and option-ally IMPI. By providing IMPU to the IMS network during registration, the subscriber indi-cates which IMPU or group of IMPUs should be registered.

Let’s fi rst look at the registration process, step by step. We will fi rst consider the initial registration . An explanation is given with reference to Figure 8.21 .

Registration includes, among others, the following two procedures:

● Authorization. The HSS determines whether the subscriber trying to register is a sub-scriber to this network.

● Authentication. Authentication is performed jointly by the HSS and S-CSCF. It is veri-fi ed that the person or application attempting to register is entitled to use this subscription (has the right credentials).

A step-by-step description of the registration process follows.

FIGURE 8.20

Relation between IMPU and IMPI in HSS subscriber profi le (example).


251

Step 1. SIP REGISTER from UE to P-CSCF Before the terminal can initiate registration, it has to obtain IP connectivity. The IP connec-tivity may be obtained through corporate LAN, residential WLAN, 3G mobile access, etc. The IP connectivity should allow for communication over (public) IP infrastructure, so the IMS terminal (user equipment, UE) can communicate with the public IMS network. IMS registration would now be initiated by sending a registration request “towards” the IMS net-work. However, the subscriber should fi rst acquire the following information:

● Home IMS realm: this is the domain name of the IMS network that this subscriber belongs to – for example, ims-operator.se

● IMPU: as described ● IMPI: as described ● P-CSCF address: this is the address (IP address or domain name) of the P-CSCF through

which the registration should be done.

The user of the IMS terminal may confi gure these information elements. Alternatively, the IMPU, IMPI, and Home IMS realm may be stored on ISIM. The

FIGURE 8.21

IMS registration message sequence.

8.5 Registration


8.4 ims network architecture – a closer look 243

Documents