Chapter 27 - Voice Call Continuity

Chia sẻ: Nguyễn Văn Chiến | Ngày: | Loại File: PDF | Số trang:18

Thêm vào BST

Báo xấu

71
lượt xem 5
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

This chapter is devoted to the Voice Call Continuity (VCC) feature in the IMS. VCC, which is speciﬁed in 3GPP TS 23.206 [27] and 24.206 [26], allows smooth transitions of voice calls executed over the IMS and Circuit-Switched (CS) calls and vice versa. The feature allows a double IMS/CS terminal to initiate or receive a voice call in either the IMS or CS domain and move it to the other domain during the duration of the call.

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Chapter 27 - Voice Call Continuity

Chapter 27 Voice Call Continuity This chapter is devoted to the Voice Call Continuity (VCC) feature in the IMS. VCC, which is speciﬁed in 3GPP TS 23.206 [27] and 24.206 [26], allows smooth transitions of voice calls executed over the IMS and Circuit-Switched (CS) calls and vice versa. The feature allows a double IMS/CS terminal to initiate or receive a voice call in either the IMS or CS domain and move it to the other domain during the duration of the call. VCC considers voice calls exclusively. At the time of writing, 3GPP is standardizing an enhanced version of VCC that includes other types of media streams different than audio. This is known as the Multimedia Session Continuity (MMSC), which it is not considered in this chapter. VCC ﬁlls an important gap in the transition of CS to IMS. Consider a user that is accessing the IMS over a narrow bandwidth packet data channel. For example, this narrow bandwidth channel can be a regular GSM cellular access over GPRS. The GPRS connectivity is used for signaling and, thus, for SIP signaling towards the IMS. Voice over IP (e.g., RTP packets) will not have the appropriate quality of service, mostly due to the delays and lack of bandwidth. However, CS connections are available, and working reasonably well. So, with the VCC feature enabled, the user can establish audio communications that use a regular CS bearer. The session is controlled with SIP in the IMS. Assume now that, at a later time, the user initiates another packet data IP-CAN access with higher bandwidth, perhaps Wireless LAN, or perhaps cellular High Speed Packet Access. He can then move the CS audio stream over the packet data IP-CAN, and perhaps enrich the session with video or some other data stream. The goal of VCC is thus: maintain existing audio calls at any cost when the user moves between areas with different connectivity characteristics. This is achieved by handing the audio stream from CS to IMS or vice versa. The feature can be implemented transparently from the point of view of the user. However, the feature requires VCC-enabled dual-mode IMS/CS terminals and network support. Because of the interaction between IMS and CS networks, this chapter assumes that the reader has basic knowledge of the GSM architecture and its evolution into 3G networks. 27.1 Overview of Voice Call Continuity Figure 27.1 presents a high-level overview of the VCC architecture. The ﬁgure shows two VCC-enabled dual-mode IMS/CS terminals. Both can have access to packet-switched accesses, which leads to an IMS core network, and CS accesses, which leads to the CS core The 3G IP Multimedia Subsystem (IMS): Merging the Internet and the Cellular Worlds Third Edition Gonzalo Camarillo and Miguel A . Garc ıa-Mart´n ´ ı © 2008 John Wiley & Sons, Ltd. ISBN: 978-0-470-51662-1
CHAPTER 27. VOICE CALL CONTINUITY 560 network. A PSTN gateway composed of an MGCF and MGW interfaces the IMS domain with the CS domain. While Figure 27.1 shows two VCC-enabled terminals, the feature applies to each terminal in an independent way, so each terminal can use either of the CS or IMS domains in its own call leg without support from the remote terminal. VCC is always implemented in the home network of the served user. VCC introduces the notion of anchoring, which consist of splitting the call into two call legs, and introducing a ﬁxed point in the network where the two legs are anchored. This allows to hand one leg from one domain to the other without creating interferences with the remaining leg. Figure 27.1: Overview of the VCC architecture Figure 27.2 shows a possible usage of a call established between two VCC-enabled terminals. One terminal is using the IMS signaling and media to make the call; the other is using the CS signaling and media. At any point in time, either of the two terminals can transfer its own leg to the other domain without disrupting the communication. Other more complex combinations are also possible. For example, a VCC-enabled terminal can initiate IMS signaling to establish a call that uses CS media. Then, later, the terminal can replace the CS audio stream with an RTP audio stream that uses the IMS. VCC also introduces the notion of routing numbers, which are intermediate telephone numbers that are used to route the call appropriately via the nodes that provide the VCC function. The CS Domain Routing Number (CSRN) is a dynamic routing number that provides routing from the IMS to the CS domain. The IP Multimedia Routing Number (IMRN) is a routable number that points to the IMS from the CS point of view. Effectively, the IMRN is a Tel URL that is considered as a Public Service Identity (PSI) in the IMS. VCC also introduces the notion of a VCC Domain Transfer Number (VDN), which is an E.164 number that the terminal can used to request a domain transfer from IMS to the CS domain. The VDN is not a number that resolves to any of the VCC nodes; it is merely a regular E.164 number whose semantics is “activate a domain transfer”. There is also a counterpart VCC Domain Transfer URI (VDI), which is a SIP URI that the UE can use to perform a domain transfer from the CS domain to the IMS domain. Like the IMRN, the VDI is also a PSI. The VDI has the semantics of “activate a domain transfer”. The VDI and VDN are assumed to be pre-provisioned to the terminal.
27.2. VCC ARCHITECTURE 561 Figure 27.2: Example of signaling and media path with VCC-enabled terminals 27.2 VCC Architecture The VCC feature introduces the concept of a VCC-enabled terminal, which is a terminal that has access to traditional CS voice and IMS applications. The VCC-enabled terminal implements domain selection policies for both originating calls and domain transfers. This policy is used when selecting a domain for originating calls. On the terminating side, it controls the user preferences for terminating calls. The VCC-enabled terminal stores the VDN and VDI to be used for domain transfer execution. In addition, a VCC-enabled terminal implements procedures for transferring a leg from circuit-switched to IMS or vice versa. The VCC-enabled terminal is conﬁgured with an E.164 number, so that it is reachable from the CS domain, as well as a TEL URL and a SIP URI to be reachable from the IMS side. Thus, there is a correlation between these numbers in different domains. VCC also introduces the concepts of the VCC application, which is a collection of functional entities that provide all of the required functionality for selecting the domain (CS or IMS) for terminating calls and to assist the VCC-enabled phone for transferring a leg from one domain to the other. The VCC application also provides the anchoring point to enabling transfer of domains during active calls. Figure 27.3 shows the general architecture of the VCC application and the related interfaces. The VCC application is composed of four main functions: the Domain Transfer Function (DTF), the Domain Selection Function (DSF), the CS Adaptation Function (CSAF), and the service for Customized Applications for Mobile network Enhanced Logic (CAMEL service). The interfaces between these four functions are not standardized, so implementa- tions either implement proprietary interfaces or combine several functions in the same node. The Domain Transfer Function (DTF) is responsible for executing the transfer of an access leg from the CS domain to the IMS domain or vice verse. From the point of view of SIP and IMS, the DTF acts as an Application Server (AS) conﬁgured as a Back-to-Back User Agent (B2BUA) operating as a third-party call controller. In addition, the DTF maintains policies related to the transfer of domains. The DTF interfaces the S-CSCF via the ISC interface, the I-CSCF via the Ma, and the HSS via the Sh interface. The Domain Selection Function (DSF) is involved in terminating calls. The DSF selects the domain over which the terminating leg of an incoming call will be delivered. To take this
CHAPTER 27. VOICE CALL CONTINUITY 562 Figure 27.3: VCC architecture decision, the DSF considers operator policy and user preferences. However, it is also helped by the user’s registration status in the IMS and CS domains, so, for example, if a user is not registered to the IMS but it is to the CS domain, the call will be delivered over the CS domain. The DSF interfaces the S-CSCF via the ISC interface and the HSS via the Sh interface. The CS Adaptation Function (CSAF) is responsible for allocating and de-allocating the IMRN for CS originated calls. The CSAF communicates call related data from CS to IMS (such as called an calling party numbers). The CSAF acts as a SIP proxy for CS originated calls and CS legs established for domain transfer to CS. The CSAF acts as a SIP User Agent towards the IMS. The CSAF interfaces the S-CSCF via the ISC interface and the I-CSCF via the Ma interface. CAMEL is a set of mobile networks standards for providing services in CS networks. CAMEL is based on the Intelligent Networks (IN) standards. One of the nodes of the CAMEL architecture is the gsmSCF, which is able to monitor the status of a call and provide certain services. Well, in VCC, the CAMEL service function provides an alternative for routing calls using CAMEL services. The functions of the CAMEL service overlap those of the CSAF, and include allocating IMRN for routing CS calls to IMS, communicating call related data from CS to IMS (such as called an calling party numbers). However, it also provides unique functions, such as enforcing the CS redirection policy. The CAMEL service interfaces the CAMEL gsmSCF via an unspeciﬁed interface. This mostly indicates that the CAMEL service is essentially an extension to the existing gsmSCF.
27.3. REGISTRATION 563 In addition to the interfaces between the individual functions of the VCC application, a VCC-enabled terminal implements the V3 interface towards the VCC application (or any of the individual functions). The V3 interface is used for conﬁguration settings and uses XCAP. We described XCAP in Chapter 17. Other relevant nodes for the VCC service include a standard PSTN/CS gateway, further composed of an MGCF and MGW. In addition, a visited MSC has also a role when the access leg traverses the circuit-switched domain. In the IMS domain, a P-CSCF is also involved when the access leg uses the IMS. 27.3 Registration There are no requirements for the VCC terminal with respect registrations. The IMS side of a VCC-enabled terminal registers to the IMS as per regular procedures (see Section 5.5). In addition, the CS side of the VCC-enabled terminal performs the regular attachment to the network. The VCC application needs to become aware of the IMS registration of the VCC-enabled terminal. This is done by conﬁguring an initial Filter Criterion that triggers a third-party registration towards the VCC application when the S-CSCF receives a regular REGISTER request from the VCC enabled terminal. In addition, the VCC application can subscribe to the reg event package at the S-CSCF, which keeps the VCC application informed whenever the VCC-enabled terminal re-registers or deregisters (see Section 5.6 for a description of the reg event state package). An alternative to notiﬁcations of the reg event package is to use the Sh interface to subscribe to the user’s registration state at the HSS. 27.4 Call Origination and Anchoring Prior to executing a domain transfer of an ongoing voice call, the call must have been setup (either in the IMS or the CS domain), and it has to be anchored, so that it can be transferred to the other domain at a later stage. This section presents call ﬂows for the originating side indicating the involved entities in the call anchoring and revealing the details of it. The ﬂows only show the relevant nodes involved in the call anchoring for the originating VCC-enabled terminal, so, for example, the originating P-CSCF is never shown, neither are any of the terminating nodes. 27.4.1 IMS Originated Call Leg Figure 27.4 shows the call ﬂow of an IMS originated call anchored in the network for enabling a potential domain transfer at a later stage. When the user initiates the call, the VCC- enabled terminal performs a domain selection that takes into consideration the access network availability and user preferences. In this example, the result of the domain selection leads to setting up the call via the IMS domain. Therefore, the VCC-enabled terminal sends a regular INVITE request (1) that traverses the P-CSCF (not shown in the ﬁgure) and other IMS nodes until it eventually reaches the S-CSCF allocated to the user in the originating home network. This S-CSCF evaluates the initial ﬁlter criteria and as a result of that evaluation, it forwards the INVITE request (3) to the DTF, as per regular procedures over the ISC interface. Of importance, the S-CSCF adds a Route header ﬁeld whose value is a URI that resolves to the same S-CSCF and contains (e.g., in the user part of the URI) a unique identiﬁer of the dialog.
CHAPTER 27. VOICE CALL CONTINUITY 564 The DTF receives the INVITE request (3), decides to anchor the call, and acts as a B2BUA AS, so it ends up the signaling towards the VCC terminal. On the other side, the DTF initiates a new originating call, so it creates an INVITE request (5) where it keeps the received Route header ﬁeld value that contains the dialog identiﬁer. The DTF can, however, modify the [From, To, Call-ID, and CSeq header ﬁelds, since they are new on this leg. Then the DTF sends it to the S-CSCF which is routed according to the originating procedures. This INVITE request (5) is received at the S-CSCF, which evaluates the ﬁlter criteria for providing originating services, continuing from the next trigger point. Eventually, the S-CSCF forwards the INVITE request (7) to its destination. The session setup continues as per regular procedures, and eventually is setup. Note that the signaling is split into two call legs. There is a call leg established between the VCC terminal and the DTF (via the S-CSCF) and another call leg established between the DTF and the called party (via the S-CSCF as well). This anchoring and separation of call legs enables a future domain transfer. 27.4.2 CS Originated Call Leg using CAMEL Services Assume now that a user is placing an audio call. Their VCC-enabled terminal determines, based on the available access technology and user preferences, that the CS domain should be used. This ﬂow sequence is shown in Figure 27.5. The VCC-enabled terminals sends a SETUP message (1) to its VMSC. This message includes the list of supported codecs and the called party number. The VMSC receives the SETUP message (1) and evaluates the origination triggers, resulting in sending a CAMEL IDP message (2) to the gsmSCF. The CAMEL IDP message (2) contains the calling and called party number, among other parameters. The gsmSCF determines whether the call should be feasible of the VCC service, and decides to anchor the call and route it via the IMS. The CAMEL service function allocates an IMRN to be used in the case of a domain transfer and provides it back to the gsmSCF. The IMRN is key to routing the call through the IMS and via the CSAF. Effectively, the IMRN is a PSI that is conﬁgured to be routed to the CSAF. Continuing with the sequence ﬂow, the CAMEL service interacts (3) with the CSAF (via yet another unspeciﬁed interface), so that the CSAF is aware of the call itself and the allocated IMRN. Then the CAMEL service in combination with the gsmSCF replies to the CAMEL IDP message (2) with a CAMEL CONNECT message (4) that includes a Destination Routing Address set to the allocated IMRN. The CAMEL CONNECT message (4) is received at the VMSC, which then routes the call to the received IMRN by performing regular CS routing. The network is conﬁgured so that, from the CS domain, the IMRN is routed to a PSTN Gateway that interfaces the CS domain with the IMS domain. So, the VMSC sends an ISUP IAM message (5) that is routed to an MGCF. The MGCF interacts (6) with the Media Gateway via the H.248 protocol and then creates an INVITE request (7) addressed in the Request-URI and To header ﬁeld to the IMRN. The INVITE request contains a Session Description Protocol whose audio stream points to a connection IP address in the MGW. Then the MGCF sends this INVITE request (7) to the I-CSCF, which applies regular routing procedures for PSI routing and eventually forwards it (9) to the CSAF. The CSAF decides to anchor the call and acts together with the DTF with which it interacts (11) to provide the proper anchoring. The CSAF/DTF acts as a SIP B2BUA. The CSAF/DTF then retrieves, in particular, the called party number that was received in the CAMEL IDP message (2) and later forwarded due to interaction (3) to the CSAF. The CSAF/DTF creates an INVITE request (12) addressed in the Request-URI and To header
27.4. CALL ORIGINATION AND ANCHORING 565 Figure 27.4: VCC anchoring: IMS originated call leg ﬁeld to the called party number. The Contact header of this INVITE request (12) is set to the SIP URI of the DTF. The DTF then forwards the INVITE request (12) to the S-CSCF of the originating user, which applies regular routing procedures and forwards the INVITE request (14) to the next hop towards its destination. The rest of the session setup continues as per regular procedures. When the session is setup, there are two call legs: a CS call leg involving the VCC terminal, the VMSC plus the gsmSSF, the CAMEL service plus the gsmSCF, the CSAF, and the MGCF plus the MGW; and a IMS call leg involving the MGCF plus the MGW, the I-CSCF, S-CSCF, the CSAF, and the DTF. The IMS leg is anchored in the CSAF/DTF which is acting as a SIP B2BUA AS.
CHAPTER 27. VOICE CALL CONTINUITY 566 Figure 27.5: VCC anchoring: CS originated call leg using CAMEL services 27.4.3 CS Originated Call Leg using CAMEL and ISUP Call Diversion The call ﬂow shown in Figure 27.5 has a small variation, which is shown in Figure 27.6. According to Figure 27.6, when the CAMEL service in the VCC application receives the CAMEL IDP message (2), rather than contacting the CSAF that would provide the IMRN, the CAMEL service generates the IMRN. Then the CAMEL service replies to the CAMEL IDP message (2) with a CAMEL CONNECT (3) that contains the destination routing address set to the IMRN (as in the call ﬂow of Figure 27.5) but now also contains the Original Called-Party ID, the redirecting Party ID, and some Redirection information. All of this extra information is conveyed in the ISUP IAM message (4). The MGCF receives the ISUP IAM message (4) and creates an INVITE request (6) which is similar to that in the call ﬂow of Figure 27.5, but now also includes a History-Info header ﬁeld listing the additional redirection data, namely, the original called number and the redirecting number received in the ISUP IAM message (4).
27.5. CALL TERMINATION AND ANCHORING 567 Figure 27.6: VCC anchoring: CS originated call leg using CAMEL services and ISUP call diversion When the CSAF receives the INVITE request (8), it will extract the number included in the History-Info header and pass it to the DTF, so that the INVITE request (11) is addressed to that original destination number and does not include that entry in the History-Info header ﬁeld. 27.5 Call Termination and Anchoring Prior to executing a domain transfer on the terminating access leg, the call has to be anchored, either in the IMS or the CS domain. This section presents the VCC related terminating call ﬂows indicating the involved entities in the call anchoring for call made to VCC-enabled terminals. As in the originating case, the ﬂows only show the relevant nodes involved in the call anchoring, so, for example, the P-CSCF is never shown, neither are any of the terminating nodes.
CHAPTER 27. VOICE CALL CONTINUITY 568 27.5.1 IMS Terminated Call Leg Figure 27.7 presents a terminating call ﬂow when the call is anchored in the IMS. In the terminating home network, the S-CSCF allocated to the called party receives a regular INVITE request (1), whose destination address is included in the Request-URI, so there is no information related to VCC in this request. The S-CSCF evaluates the initial ﬁlter criteria, and as a result of this evaluation, the request is routed to the DTF function that is part of the VCC application. The S-CSCF, as per regular procedures, add a Route header ﬁeld that contains the SIP URI of the S-CSCF, so that the request can be routed back to the S-CSCF. Figure 27.7: VCC anchoring: terminating call leg uses the IMS access leg The DTF receives the INVITE request (3) and takes the decision of anchoring the call based on the local policy. Then the DTF interacts (5) with the DSF over a non-speciﬁed protocol. The DSF decides to use the IMS as the domain for the access network technology, based on local policy, user preferences, and registration state. The DSF then communicates that decision (6) back to the DTF. The DTF acts as a SIP B2BUA in order to anchor the call, so it re-creates a new INVITE request (7) and sends it back to the S-CSCF, honoring the Route header ﬁeld value that was included in the INVITE request (3). The S-CSCF applies regular routing procedures to the INVITE request (7), such as replacing the destination address included in the Request-URI with the contact information learned during registration. Then the S-CSCF forwards the INVITE request (9) to the VCC terminal. The session setup proceeds as per regular procedures. At this point, the call is anchored in the VCC application.
27.5. CALL TERMINATION AND ANCHORING 569 27.5.2 CS Terminated Call Leg Figure 27.8 presents the call ﬂow of a call that arrives at the called party IMS network. The call is routed to the VCC application, which anchors the call and decides to route it via the CS access leg. Figure 27.8: VCC anchoring: terminating call uses the CS access leg At some point in time, the called party’s S-CSCF receives a regular INVITE request (1). The S-CSCF evaluates the initial ﬁlter criteria and as a result of it, the S-CSCF sends INVITE request (3) to the DTF function of the VCC application, not before adding a Route header ﬁeld that contains the S-CSCF own SIP URI, to be used at a later stage. The DTF decides to anchor the call based on local policy. Then it interacts (5) the DSF, which decides to select the CS domain as the access leg for the terminating call, based on local policy, user preferences, and registration status. The DSF also interacts (6) with the CSAF and they determines the CSRN, which is a dynamic routing number that is able to route the call to the VCC terminal. Then the DSF interacts (7) with the DTF. The DTF, acting as a SIP B2BUA re-creates a new INVITE request (8) addressed to the CSRN. Honoring the Route header ﬁeld of the INVITE request (3), the DTF sends the INVITE request (8) back to the S-CSCF, which applies regular routing procedures. Since the destination address included in the Request-URI is effectively a telephone number in the
CHAPTER 27. VOICE CALL CONTINUITY 570 circuit-switched domain, the INVITE request (10) is routed to an MGCF (perhaps via one or more BGCFs, not shown in the Figure 27.8). The MGCF interacts (12) with the MGW and then sends an ISUP IAM message (13) where the called party is the CSRN. The VMSC maps the CSRN to the called party, so it sends a SETUP message (14) to the VCC terminal. This is a regular SETUP message, so it does not contain any information related to VCC. The session setup continues as per regular procedures. At this point in time, there is a circuit-switched bearer established between the VCC terminal and the MGW, and an IMS (RTP) bearer established between the MGW and the originating point. In addition, the call is anchored in the DTF, something that allows a potential domain transfer at a later stage. 27.5.3 CS Originated Call is Terminated in the IMS using CAMEL Figure 27.9 presents the call ﬂow of a call attempt that is received at the terminating home network over the CS domain. The VCC application determines that the call is delivered over the IMS domain, so it is routed to an PSTN/CS gateway that converts it to the IMS domain, where the VCC terminal is eventually contacted. Figure 27.9: Call coming from the CS domain is terminated in the IMS; CAMEL is used The call ﬂow starts when a Gateway Mobile Switching Center (GMSC) receives and ISUP IAM message (1) addressed to the regular phone number (MSISDN) of the user.
27.5. CALL TERMINATION AND ANCHORING 571 The GMSC interrogates the Home Location Register (HLR) using the Mobile Application Part (MAP) protocol, to be precise, a Send Routing Information (SRI) message (2). The HLR returns a MAP SRI RESULT message (3) that contains the Terminating CAMEL Subscription Information (T-CSI). The T-CSI includes all of the required CAMEL information for providing the VCC service, including the address the of the gsmSCF allocated to the user. The GMSC issues a CAMEL IDP message (4) that is received at the gsmSCF and the CAMEL service, which is part of the VCC application. Those interact with the CSAF, which provides the IMRN allocated to the user. The IMRN is returned in a CAMEL CONNECT message (6) back to the GMSC. The GMSC then continues the call by sending an ISUP IAM message (7) now addressed to the IMRN received from the VCC application. Since the IMRN resolves to the IMS, regular CS routing procedures cause the ISUP IAM message (7) be received at an MGCF that interfaces to the IMS. The MGCF interacts with (8) the MGW to select an IP address and port number for media, and creates an INVITE request (9) addressed to the IMRN. The IMRN is effectively a PSI, so the MGCF sends the INVITE request (9) ﬁrst to an I-CSCF (not shown in the ﬁgure), which routes it to the DTF. The DTF decides to anchor the call and interacts with the DSF, which performs the domain selection, and decides to use the IMS for delivering the call. The DTF maps the IMRN with a SIP URI or TEL URL of the user, and then acting as a B2BUA, creates an INVITE request (13) addressed to that identity. The S-CSCF allocated to the user receives it and applies regular procedures, such as evaluating the initial ﬁlter criteria. It also applies regular routing procedures, such as replacing the Request-URI with the contact information of the user. Then the S-CSCF forwards the INVITE request (15) to the VCC terminal via a P-CSCF (not shown in the ﬁgure). The session is then completed as per regular procedures. 27.5.4 CS Originated Call is Terminated in the CS Domain Figure 27.10 presents the call ﬂow of a CS originated call that is routed to the IMS domain and, in particular, to the VCC application for anchoring, and eventually routed via the CS access domain to the VCC terminal. According to Figure 27.10, a Gateway MSC receives an ISUP IAM message (1) address to the regular telephone number of the user. The GMSC queries the HRL with a MAP SRI message (2). The HLR determines the IMRN allocated to that user and returns it in a MAP SRI result message (3). Then the GMSC sends an ISUP IAM message (4) addressed to the IMRN. Since the IMRN is a telephone number in the IMS domain, the CS routes point to an MGCF that interfaces the IMS. The MGCF creates an INVITE request (6) addressed to the IMRN and sends it to the I-CSCF. The IMRN is a PSI, so the I-CSCF applies routing procedures for PSIs and forwards it to the CSAF. The CSAF interacts (8) with the DTF, which decides to anchor the call. Then the DTF interacts (9) with the DSF, which decides to select the CS domain for delivering the call, derives the CSRN, and communicates these decisions back to the DTF (10). The DTF then generates an INVITE request (11) addressed to the CSRN and sends it to a S-CSCF. Since the CSRN is a number exclusively allocated in a CS network, the S-CSCF forwards the INVITE request (13) to an MGCF via a BGCF (not shown in the ﬁgure). Note that this MGCF and its corresponding MGW need not necessarily be the same as those involved with messages 4 to 6. However, for the sake of simplicity, Figure 27.10 shows a single MGCF and a single MGW. After some interaction (15) with its MGW, the MGCF sends an ISUP IAM request (16) addressed to the CSRN. This is routed
CHAPTER 27. VOICE CALL CONTINUITY 572 Figure 27.10: Call coming from the CS domain is routed to the VCC in the IMS and then terminated in the CS domain to the visited MSC allocated to the VCC terminal, which sends the SETUP message (17) to establish the call. The reset of the session setup continues as per regular procedures. Once the session is setup, there is a CS leg established in the core network until an MGCF is reached, the call then gateways to the IMS and is anchored in the DTF, and then it is routed back to the CS domain. 27.6 Domain Transfer So far we have seen how audio calls are anchored and delivered via the CS or IMS domain, either in the originating or terminating side. Let us take a look now at the domain transfer scenarios. These take place when the real VCC service is invoked. 27.6.1 Transfer from the CS Domain to the IMS Domain Figure 27.11 shows the call ﬂow of a call where one of the users is initially anchored to the IMS. At some point in time during the call, the VCC terminal determines that a transfer of domain is needed. This might be caused due to a number of factors, for example, due to the
27.6. DOMAIN TRANSFER 573 availability of a high bandwidth radio bearer, such as Wireless LAN. The VCC terminal sends an INVITE request (1) via the P-CSCF (not shown) to the S-CSCF. This INVITE request is addressed, in the Request-URI to the VDI, which is a PSI that resolves to the DTF. The S-CSCF evaluates the initial ﬁlter criteria and routes the INVITE request (3) to the DTF. Figure 27.11: Domain transfer of an ongoing call from the CS to the IMS domain
CHAPTER 27. VOICE CALL CONTINUITY 574 The DTF is an AS acting as a B2BUA. On the other leg the DTF has an existing SIP dialog established with the remote party. The DTF then sends a re-INVITE request (5) towards the remote party. The idea is to inform the remote party of the change of access leg of the VCC terminal from the CS to the IMS domain. The S-CSCF receives the INVITE request (5) and routes it towards the remote party (7). The session completes as per regular procedures. When the remote party sends its 200 OK response (9), it is propagated backwards until it reaches the VCC terminal, so, for example, the 200 OK response (14) is an answer to the INVITE request (1). When the VCC terminal receives the 200 OK response (14) the session is already setup in the IMS, so the VCC terminal can seamlessly switch to IMS as soon as the ﬁrst RTP packets are received. Then the DTF needs to tear down the initial existing CS call leg, so it sends a BYE request (17) on the initial SIP dialog. This BYE request is routed, following the routing rules for mid-dialog request, to the I-CSCF (not shown in the ﬁgure) and eventually to the MGCF. The MGCF generates an ISUP REL message (18) to the VMSC, which sends a DISCONNECT RELEASE message (19) to the VCC terminal. The VCC terminal then disconnects the CS access leg and retains the IMS access leg. 27.6.2 Transfer from the IMS Domain to the CS Domain Figure 27.12 shows the ﬂow associated with a domain transfer from the IMS to the CS domain. The ﬁgure assumes that there is ongoing audio call established over the IMS. The VCC terminal has its session anchored to the VCC application, thus allowing a domain transfer at any time. At some point in time, perhaps due to a change in the access network conditions, the VCC terminal decides to transfer the domain of the call from the IMS to the CS domain, so it sends a SETUP message (1) address to the VDN, which is a regular E.164 number used for activating a domain transfer. The visited MSC receives the SETUP message (1) and sends a CAMEL IDP message (2) to the gsmSCF, with the purpose of asking for routing information. The gsmSCF interacts (4) with the CSAF to obtain an IMRN and then forwards the IMRN back to the IMRN in a CAMEL CONNECT message (4). Once the VMSC receives the routing information, i.e., the IMRN, the VMSC proceeds with the call setup by sending a CALL PROCEEDING message (5) to the VCC terminal and an ISUP IAM message (5) addressed to that IMRN. Since the IMRN is a telephone number allocated to the IMS, regular CS routing routes the ISUP IAM message (5) eventually to an MGCF that interfaces the IMS. The MGCF ﬁrst interacts (7) with the MGW to obtain, among other things, the IP address and port number of the MGW where RTP packets should be sent. The MGCF then creates an INVITE request that is addressed in the Request-URI to the IMRN, expressed now as a tel URL. Since the IMRN is a PSI, this INVITE request (8) is routed via an I-CSCF (not shown in the ﬁgure) to the CSAF. The CSAF recognizes the IMRN as an associated number to one of the existing ongoing calls anchored in the VCC application. The CSAF then interacts (10) with the DTF, which is acting as a B2BUA, and which already has an established leg towards the destination due to anchoring when the session was initially established. The DTF then generates a re-INVITE request (11) on this existing SIP dialog towards the S-CSCF. The purpose of this re-INVITE is to modify the dialog information, if needed, according to the new access leg. So, for example, the From header can change reﬂecting now the tel URL of the VCC terminal, but still preserving the same tag
27.6. DOMAIN TRANSFER 575 Figure 27.12: Domain transfer of an ongoing call from the IMS to the CS domain value of the original SIP dialog. The S-CSCF further routes the INVITE request (13) to the destination. The re-INVITE proceeds as a regular session setup. At some point in time, the S-CSCF receives a 200 OK response (15) from the remote party acknowledging the new parameters in the session. The S-CSCF forwards the 200 OK response (16) to the DTF, which generates an ACK request (18), which is forwarded (19) to the remote party. In addition, the DTF interacts (19) with the CSAF to indicate the success in the transaction. The CSAF then generates a 200 OK response (20), which acknowledges the received INVITE request (8). The MGCF eventually receives this 200 OK response (20), generates an
CHAPTER 27. VOICE CALL CONTINUITY 576 ACK request (21) and an ISUP ANM message (22) to the VMSC. The VMSC then sends a CONNECT message (23) to the VCC terminal, which provides an acknowledgement to the VMSC with a CONNECT ACK (24) message. At this point in time the MGCF is splitting the signaling session, since it has a CS access leg towards the VCC terminal and an IMS access leg towards the VCC application and the remote party. Similarly, the MGCF is spitting the media into two as well. So, the VCC terminal can start making usage of the CS access leg at any time. The DTF also tears down the IMS access leg by sending a BYE request (25) on the original SIP dialog. This BYE request is received at the S-CSCF, which routes it back (26) to the VCC terminal via a P-CSCF (not shown in the ﬁgure). At this point in time, the IMS access leg has been torn down and only the CS access leg remains.