Techniques for trunk optimization for IMS voice calls between originating UE and terminating UE homed in a circuit switched network

A method and Voice Call Continuity (VCC) application server to perform trunk optimization for an Internet Protocol (IP) Multimedia Subsystem (IMS) voice call between an originating User Equipment (UE) and a terminating UE, which are homed in a CS network, is provided. The method includes receiving a request from the originating UE for an IMS voice call with the terminating UE, determining whether the VCC application server serves both the originating UE and the terminating UE, and, if it is determined that the VCC application server serves both the originating UE and the terminating UE, controlling to establish a bypass bearer for the IMS voice call between the originating UE and the terminating UE that bypasses the CS network.

BACKGROUND OF THE INVENTION

1. Field of the Invention

Aspects of the present invention relate to Internet Protocol (IP) Multimedia Subsystem (IMS) voice calls. More particularly, aspects of the present invention relate to techniques for trunk optimization for IMS voice calls between an originating User Equipment (UE) and a terminating UE that are homed in a Circuit Switched (CS) network.

2. Description of the Related Art

Due to the coexistence of deployed 3rdGeneration (3G) and 4thGeneration (4G) wireless communication networks, it is possible to have 3G and 4G User Equipments (UEs) roaming from the 3G wireless communication network to the 4G wireless communication network and vice a versa. An example of the 3G wireless communication network is the Code Division Multiple Access (CDMA) 1x wireless communication network and an example of the 4G wireless communication network is the Long Term Evolution (LTE) wireless communication network.

The 3G wireless communication network and the 4G wireless communication network employ different types of network communications for voice calls. That is, the 3G wireless communication network employs Circuit Switched (CS) network communications for voice calls, and the 4G wireless communication network employs Packet Switched (PS) network communications for voice calls. However, regardless of whether the 3G and 4G UEs are roaming from one of the 3G and 4G wireless communication networks to the other of the 3G and 4G wireless communication networks, there is a need for voice calls to continue. This is a transitional requirement that remains until all UEs support 4G technologies. Accordingly, there is a need to implement techniques that address this transitional requirement.

SUMMARY OF THE INVENTION

An aspect of the present invention is to address at least the above-mentioned problems and/or disadvantages and to provide at least the advantages described below. Accordingly, an aspect of the present invention is to provide techniques for trunk optimization for Internet Protocol (IP) Multimedia Subsystem (IMS) voice calls between an originating User Equipment (UE) and a terminating UE that are homed in a Circuit Switched (CS) network.

In accordance with an aspect of the present invention, a method for a Voice Call Continuity (VCC) application server to perform trunk optimization for an IMS voice call between an originating UE and a terminating UE, which are homed in a CS network, is provided. The method includes receiving a request from the originating UE for an IMS voice call with the terminating UE, determining whether the VCC application server serves both the originating UE and the terminating UE, and, if it is determined that the VCC application server serves both the originating UE and the terminating UE, controlling to establish a bypass bearer for the IMS voice call between the originating UE and the terminating UE that bypasses the CS network.

In accordance with another aspect of the present invention, at least one non-transitory processor readable medium for storing a computer program of instructions configured to be readable by at least one processor for instructing the at least one processor to execute a computer process for performing the method recited above, is provided.

In accordance with yet another aspect of the present invention, a VCC application server apparatus for performing trunk optimization for an IMS voice call between an originating UE and a terminating UE, which are homed in a CS network, is provided. The apparatus includes a memory for storing code of a VCC function, a processor for executing the code of the VCC function stored in the memory, a communications unit for sending and receiving information for the VCC function, and the VCC function for receiving a request from the originating UE for an IMS voice call with the terminating UE, for determining whether the VCC function serves both the originating UE and the terminating UE, and, if it is determined that the VCC function serves both the originating UE and the terminating UE, for controlling to establish a bypass bearer for the IMS voice call between the originating UE and the terminating UE that bypasses the CS network.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

FIGS. 1 through 8, discussed below, and the various exemplary embodiments used to describe the principles of the present disclosure in this patent document are by way of illustration only and should not be construed in any way that would limit the scope of the disclosure. Those skilled in the art will understand that the principles of the present disclosure may be implemented in any suitably arranged communications system. The terms used to describe various embodiments are exemplary. It should be understood that these are provided to merely aid the understanding of the description, and that their use and definitions in no way limit the scope of the invention. Terms first, second, and the like are used to differentiate between objects having the same terminology and are in no way intended to represent a chronological order, unless where explicitly stated otherwise. A set is defined as a non-empty set including at least one element.

Exemplary embodiments of the present invention described below relate to Internet Protocol (IP) Multimedia Subsystem (IMS) voice calls. More particularly, exemplary embodiments of the present invention described below relate to techniques for trunk optimization for IMS voice calls where both an originating User Equipment (UE) and a terminating UE support IMS. In addition, exemplary embodiments of the present invention are applicable to the scenario where both the originating UE and the terminating UE are operating in a Packet Switched (PS) network and are homed at a Circuit Switched (CS) network; and originating and terminating legs of an IMS voice call are anchored by a Voice Call Continuity (VCC) function.

While certain aspects the trunk optimization for IMS voice calls between an originating User Equipment (UE) and a terminating UE that are homed in a CS network may be described below in the context of a 3rdGeneration (3G) wireless communication network, such as a Code Division Multiple Access (CDMA) 1x wireless communication network, as an example of a CS network, those aspects of the present invention are not limited thereto and are similarly applicable to other CS networks, such as Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), CDMA, Wireless Fidelity (WiFi), Worldwide Interoperability for Microwave Access (WiMAX), etc. Similarly, while certain aspects of the trunk optimization for IMS voice calls between an originating User Equipment (UE) and a terminating UE that are homed in a CS network may be described below in the context of a 4thGeneration (4G) wireless communication network, such as a Long Term Evolution (LTE) wireless communication network, those aspects of the present invention are not limited thereto and are similarly applicable to other PS networks, such as LTE-Advanced (LTE-A), etc.

It should be understood that the following description may refer to terms utilized in various standards merely for simplicity in explanation. For example, the following description may refer to terms utilized in at least one of the 3G Partnership Project (3GPP) standards, such as the CDMA 1x and LTE standards. However, the description herein should not be interpreted as being limited to such standards. Independent of the mechanism used for trunk optimization for IMS voice calls between an originating User Equipment (UE) and a terminating UE that are homed in a CS network, it is advantageous for that ability to conform to a standardized mechanism.

The description of the exemplary embodiments of the present invention may refer to the term “UE.” It is to be understood that this is merely a generic term and that the invention is equally applicable to any type of communications device, such as a Personal Computer (PC), a mobile phone, a palm sized PC, a netbook, a Personal Digital Assistant (PDA), a Hand-held PC (HPC), a smart phone, a wireless Local Area Network (LAN) terminal, etc. Accordingly, use of the term “UE” should not limit application of the present inventive concepts to any certain type of apparatus or device.

As described above, there is a need for a technique that addresses the transitional requirement for voice calls where wireless communication networks coexist that employ different types of network communications for the voice calls. For example, the 3G wireless communication network (e.g., the CDMA 1x wireless communication network), which employs CS network communications for voice calls, and the 4G wireless communication network (e.g., LTE wireless communication network), which employs PS network communications for voice calls.

Related Art IMS Voice Call Scenario

A solution according to the related art that addresses the above mentioned transitional requirement is defined by 3GPP standards which make use of a VCC function. The VCC function may be implemented as an application server that is an IMS application server. Alternatively, the VCC function may be implemented as an application server that is not an IMS application server. The application server which supports the VCC function may be limited to the VCC function, or may include one or more additional functions. An optional aspect of the VCC function is to anchor the call legs to the VCC application server, thereby allowing for a seamless transition between CS and PS wireless communication networks. If this optional function is supported in the operator network, the call legs are anchored to the VCC application server regardless of the type of access network used. In this case, the voice call is persisted, as a UE moves between CS and PS wireless communication network domains.

A 4G standard of the related art defines use of IMS for voice calls, which is implemented as an IMS network. Although both originating and terminating UEs support IMS, as a part of a transitional IMS solution, the transitional IMS solution calls for the IMS UE to be homed at the 3G wireless communication network. In a case where both the originating and terminating UEs of a call support IMS, a CS trunking is established from the IMS network to the 3G wireless communication network, then from the 3G wireless communication network to the IMS network for call delivery. Although the call can be handled without any CS trunking, because of the homing at the 3G wireless communication network, the additional CS trunking through the 3G wireless communication network is required. This is a disadvantage of the IMS-IMS call handled by the same VCC function requiring homing at the 3G wireless communication network.

An example of the IMS voice call scenario described above is described below with reference toFIG. 1. Herein it is noted thatFIG. 1, as well asFIGS. 2-6, only include information that is assistive in describing the exemplary embodiments of the present invention and do not include a comprehensive list of elements, messages or interactions involved in the corresponding IMS call flow.

FIG. 1illustrates an exemplary IMS network diagram for a voice call according to the related art.

Referring toFIG. 1, the network elements involved in the IMS voice call scenario include an originating UE, UE A110; a terminating UE, UE B120; an originating Session Border Controller (SBC), SBC A112; a terminating SBC, SBC B122; an originating Media GateWay (MGW), MGW A114; a terminating MGW, MGW B124; an originating Telephony Application Server (TAS), TAS A116; a terminating TAS, TAS B126; an originating Media Gateway Controller Function (MGCF), MGCF A118, an originating Call Session Controller Function (CSCF) logically representing proxy, serving and interrogating functions, CSCF A117, a terminating MGCF, MGCF B128, a terminating CSCF, logically representing proxy, serving and interrogating functions. CSCF B127; a Home-Mobile Switching Center (H-MSC)100; a Home Location Register (HLR)102; an originating VCC, VCC A131, and a terminating VCC, VCC B132. It is noted that the VCC A131and the VCC B132may be separate VCCs or a common VCC. Also, the VCC A131and the VCC B132may collectively be referred to as VCC130. In addition, it is noted that the H-MSC100and the HLR102are part of the CDMA 1x wireless communication network. Additional and/or different network elements may be included. Similarly, the functionality of two or more network elements may be integrated into a single network element. Herein, while the network elements shown inFIG. 1are substantially identical to the network elements employed in exemplary embodiments of the present invention, a bearer path and signaling may differ.

The bearer path and signaling for the IMS voice call scenario according to the related art between UE A110and UE B120will now be described. The bearer path is shown with a solid line and the signaling is shown with a dashed line.

In operation, the UE A110, while being serviced by the LTE network, initiates a voice call. The originating leg is anchored at the VCC A131and the IMS voice call is also maintained at the TAS A116. The CSCF A117routes the IMS voice call to the MGCF A118for routing to the H-MSC100based on a translation of the calling digits. The H-MSC100retrieves an IMS Routing Number (IMRN) to route the IMS voice call to the VCC B132for anchoring and for voice call delivery.

As can be seen inFIG. 1, in the exemplary IMS voice call scenario according to the related art, despite the UE A110and UE B120operating in the LTE network, the bearer path for the IMS voice call includes CS trunks that traverse through the CDMA 1x wireless communication network (e.g., the H-MSC100).

Given the network environment shown inFIG. 1, exemplary embodiments of the present invention include techniques that minimize trunk resources. That is, instead of using a bearer path that includes CS trunks that traverse through the CDMA 1x wireless communication network, a bearer path that is directly supported between the UE A110and the UE B120that bypasses the CDMA 1x wireless communication network is established. To minimize trunk resources, the VCC130includes a CS trunk optimization function that recognizes call legs belonging to the same IMS voice call and releases CS trunks. Alternatively, the CS trunk optimization function may be implemented in a separate application server.

Herein, exemplary embodiments of the present invention are applicable to the scenario where UE A110and the UE B120utilize the same or different coder-decoders (CODECs) for the IMS voice call. In addition, exemplary embodiments of the present invention are applicable to the scenario where UE A110and the UE B120utilize different CODECs for the IMS voice call that either or do not operate in the same Capacity Operating Points (COPs) at the same rate.

The scenario where the same CODECs are employed is described first with reference toFIGS. 2 and 3, the scenario where the different CODECs are employed that, after consideration of whether the different CODECs operate in the same COPs at the same rate, are found to operate in the same COPs at the same rate, is described thereafter with reference toFIGS. 2 and 4, and the scenario where different CODECs are employed is described thereafter with reference toFIGS. 5 and 6. The scenario described with reference toFIGS. 5 and 6where different CODECs are employed is applicable to the scenario where different CODECs are employed without consideration of whether the different CODECs operate in the same COPs at the same rate, and the scenario where different CODECs are employed that, after consideration of whether the different CODECs operate in the same COPs at the same rate, are found to not operate in the same COPs at the same rate.

IMS Voice Call Scenario where the Same CODECs are Employed

FIG. 2illustrates an IMS network diagram for a voice call in which the same CODECs are employed according to an exemplary embodiment of the present invention.FIG. 3illustrates a message flow of the IMS voice call scenario shown inFIG. 2in which the same CODECs are employed. The network elements shown inFIGS. 2 and 3are substantially the same as the network elements shown inFIG. 1, and thus a description thereof is omitted for brevity.

Referring toFIGS. 2 and 3, in step301, the UE A110, while being serviced by the LTE network, initiates a voice call by sending an INVITE message to VCC A131. The INVITE message sent in step301includes a Uniform Resource Identifier (URI) of UE B120and Session Description Protocol (SDP) information of the UE A110. The SDP information of the UE A110includes codec information of UE A110. In addition, depending on the exemplary implementation, the INVITE message sent in step301may additionally include COPs and/or rate information of UE A110. The VCC A131stores the VCC A context, which includes at least one of a Calling Party Number (CgPN), a Called Party Number (CdPN), a Term Status, and the SDP information of the UE A110. The VCC A context may additionally include COPs and/or rate information. In step302, the VCC A131routes the INVITE message to the MGCF A118. The INVITE message routed in step302may be substantially the same as the INVITE message sent in step301.

In step303, the MGCF A118sends an Initial Address Message (IAM) to the H-MSC100. The IAM sent in step303includes a number of the UE A110as the CgPN, a number of the UE B120as the CdPN, and a first Circuit Identification Code (CIC) CIC1. In step304, the H-MSC100sends an IAM to the MGCF B128. The IAM sent in step304includes the number of the UE A110as the CgPN, the number of the UE B120as the CdPN, and a second CIC CIC2.

In step305, the MGCF B128sends an INVITE message to the VCC B132. The INVITE message sent in step305includes the URI of UE B120and SDP information of the MGW B124. In step306, the VCC B132routes the INVITE message to the UE B120. The INVITE message routed in step306may be substantially the same as the INVITE message sent in step305.

In step307, the UE B120sends a 1xx/200 OK message to the VCC B132. The 1xx/200 OK message sent in step307includes a URI of the UE B120and SDP information of the UE B120. In addition, depending on the exemplary implementation, the 1xx/200 OK message sent in step307may additionally include COPs and/or rate information of UE B120. In step308, the VCC B132routes the 1xx/200 OK message to the MGCF B128. The 1xx/200 OK message routed in step308may be substantially the same as the 1xx/200 OK message sent in step307.

In step309, the MGCF B128sends an ACKnowledgment (ACK) message to the VCC B132. In step310, the VCC B132routes the ACK message to the UE B120. The ACK message routed in step310may be substantially the same as the ACK message sent in step309.

Meanwhile, in step311, the MGCF B128sends an Address Complete Message (ACM)/Address Answer Message (ANM) to the H-MSC100. In step312, the H-MSC100routes the ACM/ANM to the MGCF A118. The ACM/ANM routed in step311may be substantially the same as the ACM/ANM sent in step312.

In step313, the MGCF A118sends a 1xx/200 OK message to the VCC A131. The 1xx/200 OK message sent in step313includes the URI of UE B120and SDP information of the MGW A114. In step314, the VCC A131routes the 1xx/200 OK message to the UE A110. The 1xx/200 OK message routed in step314may be substantially the same as the 1xx/200 OK message sent in step313.

In step315, the UE A110sends an ACK message to the VCC A131. In step316, the VCC A131routes the ACK message to the MGCF A118. The ACK message routed in step316may be substantially the same as the ACK message sent in step315.

It is noted that at this point, the call context maintained at VCC A131for the call between UE A110and UE B120includes the SDP information of UE A110and the SDP information of MGW A114. The call context maintained at VCC A131may additionally include COPs and/or rate information. Similarly, the call context maintained at VCC B132for the call between UE A110and UE B120includes the SDP information of UE B120and the SDP information of MGW B124. The call context maintained at VCC B132may additionally include COPs and/or rate information.

Herein, it is noted that steps301through316are similar to steps for establishing a call according to the related art. That is, once the ACK message is received from the UE A110in step316, the IMS voice call is setup through a bearer path that includes CS trunks that traverse through the CDMA 1x wireless communication network (e.g., the H-MSC100), as shown inFIG. 1. However, VCC A131performs a trunk optimization function for bypassing and releasing the CS trunks that traverse through the CDMA 1x wireless communication network. This operation is described below in steps317through331.

Based on the response from the VCC B132, namely the contents of the 1xx/200 OK message sent in step313, the VCC A131determines whether the VCC A131and the VCC B132are the same VCC, namely VCC130. If the VCC A131determines that the VCC A131and the VCC B132are different VCCs, the VCC A131continues to process the IMS voice call according to the related art (e.g., the VCC A131waits for a Call Release from either UE A110or UE B120). In contrast, if the VCC A131determines that the VCC A131and the VCC B132are the same VCC, namely VCC130, the VCC A131initiates CS trunking optimization once the ACK message is received from the UE A110in step316, which indicates that the IMS call has been setup. Here, it is assumed that the VCC A131determines that the VCC A131and the VCC B132are the same VCC, namely VCC130.

Herein, it is also assumed that the UE A110and the UE B120support the same CODECs. The scenario where the UE A110and the UE B120support different CODECs that operate in the same COPs at the same rate is described below with reference toFIGS. 2 and 4. Also, the scenario where the UE A110and the UE B120support different CODECs without consideration of whether the different CODECs operate in the same COPs at the same rate, and the scenario where the UE A110and the UE B120support different CODECs that, after consideration of whether the different CODECs operate in the same COPs at the same rate, are found to not operate in the same COPs at the same rate, are described below with reference toFIGS. 5 and 6.

At this point the VCC A131has determined that the VCC A131and the VCC B132are the same VCC, namely VCC130. Thus, CS trucking optimization is triggered, which is described in steps317through319.

In step317, to initiate CS trucking optimization, the VCC A131sends an Optimize Request message to the VCC B132. The Optimize Request message sent in step317includes a Called IDentifier (ID), a Call Context of the call between the UE A110and the UE B120, and SDP information of the UE A110. At this point, the VCC B132determines that UE A110and UE B120support the same CODECs.

In step318, the VCC B132sends an Optimize ACK message to the VCC A131. The Optimize ACK message sent in step318includes the Called ID, the Call Context of the call between the UE A110and the UE B120, and SDP information of the UE B120. At this point, the VCC A131determines that UE A110and UE B120support the same CODECs.

In step319, the VCC A131sends an Optimize Confirm message to the VCC B132. The Optimize Confirm message sent in step319includes the Called ID and the Call Context of the call between the UE A110and the UE B120. Here, the triggering of the CS trucking optimization triggers the establishment of a bypass bearer150in steps320through323, and the release of the CS trunks (marked with an ‘X’) in steps324through331.

To establish the bypass bearer150, in step320, the VCC A131sends an INVITE message to the UE A110. The INVITE message in step320includes a URI of UE B120and SDP information of the UE B120. In step321,200OK and ACK messages are exchanged between the UE A110and the VCC A131. Meanwhile, in step322, the VCC B132sends an INVITE message to the UE B120. The INVITE message in step322includes a URI of UE B120and SDP information of the UE A110. In step323,200OK and ACK messages are exchanged between the UE B120and the VCC B132. At this point, the bypass bearer path150shown inFIG. 2is established that bypasses the CS trunks.

It is noted that at this point, the call context maintained at VCC A131for the call between UE A110and UE B120includes the SDP information of UE A110and the SDP information of UE B120. The call context maintained at VCC A131may additionally include COPs and/or rate information. Similarly, the call context maintained at VCC B132for the call between UE A110and UE B120includes the SDP information of UE B120and the SDP information of UE A110. The call context maintained at VCC B132may additionally include COPs and/or rate information.

Meanwhile, to release the CS trunks (marked with an ‘X’), in step324, the VCC A131sends a BYE message to the MGCF A118. The BYE message sent in step324includes the URI of UE B120. In step325, the MGCF A118sends a Release (REL) message to the H-MSC100. The REL message sent in step325includes the number of the UE A110as the CgPN and the number of the UE B120as the CdPN. In step326, the H-MSC100sends a REL message to the MGCF B128. The REL message sent in step326includes the number of the UE A110as the CgPN and an IMS Routing Number (IMRN) as the CdPN. In step327, the MGCF B128sends a BYE message to the VCC B132. The BYE message sent in step327includes the URI of the UE B120and SDP information for UE A110. In step328, the VCC B132sends a 200 OK message to the MGCF B128. In step329, the MGCF B128sends a ReLease Complete (RLC) message to the H-MSC100. In step330, the H-MSC100routes the RLC message to the MGCF A118. In step331, the MGCF A118sends a 200 OK message to the VCC A131.

At this point, the CS trunks (marked with an ‘X’) including CIC1and CIC2for the voice call between UE A110and UE B120are released at the MGW A114and the MGW B124. Herein, it is noted that the CS trunks are released without the VCC B132releasing toward the UE B120.

Regarding call release for when the call is to be terminated, either the UE A110or the UE B120may initiate Call Release. For convenience in explanation, it is assumed herein that the UE A110initiates Call Release. That is, in step332, the UE A110sends a BYE message to the VCC A131. The BYE message sent in step332includes the URI of UE B120. In step334, the VCC A131sends a Release message to VCC B132. The Release message sent in step334includes the Called ID and the Call Context of the call between the UE A110and the UE B120. In step335, the VCC B sends a BYE message to the UE B120. The BYE message includes the URI of UE B120. In step336, the UE B120sends a 200 OK message to the VCC B132. In step337, the VCC B132sends a Release ACK message to the VCC A131. The Release ACK message sent in step337includes the Called ID and the Call Context of the call between the UE A110and the UE B120. In step333, the VCC A sends a 200 OK message to the UE A110. At this point, the voice call is terminated and the bypass bearer path150shown inFIG. 2is released.

In the above scenario, it is assumed that the originating and terminating UEs, UE A110and UE B120, utilize the same CODECs. However, in the case where the CODECs used by the originating and terminating UEs, UE A110and UE B120, are different, the VCC A131may determine whether the different CODECs used operate in the same COPs at the same rate. In this case, if the different CODECs used by UE A110and UE B120operate in the same COPs at the same rate, the bypass bearer may still be established. The scenario where different CODECs are employed that operate in the same COPs at the same rate is described below with reference toFIGS. 2 and 4.

IMS Voice Call Scenario where Different CODECs are Employed that Operate in the Same COPs at the Same Rate

FIG. 2also illustrates an IMS network diagram for a voice call in which different CODECs are employed that operate the same COPs at the same rate according to an exemplary embodiment of the present invention.FIG. 4illustrates a message flow of the IMS voice call scenario shown inFIG. 2in which different CODECs are employed that operate in the same COPs at the same rate. The network elements shown inFIGS. 2 and 4are substantially the same as the network elements shown inFIG. 1, and thus a description thereof is omitted for brevity.

Referring toFIGS. 2 and 4, in step401, the UE A110, while being serviced by the LTE network, initiates a voice call by sending an INVITE message to VCC A131. The INVITE message sent in step401includes a URI of UE B120, SDP information of the UE A110, and COPs and/or rate information of UE A110. The SDP information of the UE A110includes codec information of UE A110. The VCC A131stores the VCC A context, which includes at least one of a Calling Party Number CgPN, a Called Party Number CdPN, a Term Status, and the SDP information of the UE A110. The VCC A context may additionally include COPs and/or rate information. In step402, the VCC A131routes the INVITE message to the MGCF A118. The INVITE message routed in step402may be substantially the same as the INVITE message sent in step401.

In step403, the MGCF A118sends an IAM to the H-MSC100. The IAM sent in step403includes a number of the UE A110as the CgPN, a number of the UE B120as the CdPN, and a first CIC CIC1. In step404, the H-MSC100sends an IAM to the MGCF B128. The IAM sent in step404includes the number of the UE A110as the CgPN, the number of the UE B120as the CdPN, and a second CIC CIC2.

In step405, the MGCF B128sends an INVITE message to the VCC B132. The INVITE message sent in step405includes the URI of UE B120and SDP information of the MGW B124. In step406, the VCC B132routes the INVITE message to the UE B120. The INVITE message routed in step406may be substantially the same as the INVITE message sent in step405.

In step407, the UE B120sends a 1xx/200 OK message to the VCC B132. The 1xx/200 OK message sent in step407includes a URI of the UE B120, SDP information of the UE B120, and COPs and/or rate information of UE B120. In step408, the VCC B132routes the 1xx/200 OK message to the MGCF B128. The 1xx/200 OK message routed in step408may be substantially the same as the 1xx/200 OK message sent in step407.

In step409, the MGCF B128sends an ACK message to the VCC B132. In step410, the VCC B132routes the ACK message to the UE B120. The ACK message routed in step410may be substantially the same as the ACK message sent in step409.

Meanwhile, in step411, the MGCF B128sends an ACM/ANM to the H-MSC100. In step412, the H-MSC100routes the ACM/ANM to the MGCF A118. The ACM/ANM routed in step411may be substantially the same as the ACM/ANM sent in step412.

In step413, the MGCF A118sends a 1xx/200 OK message to the VCC A131. The 1xx/200 OK message sent in step413includes the URI of UE B120and SDP information of the MGW A114. In step414, the VCC A131routes the 1xx/200 OK message to the UE A110. The 1xx/200 OK message routed in step414may be substantially the same as the 1xx/200 OK message sent in step413.

In step415, the UE A110sends an ACK message to the VCC A131. In step416, the VCC A131routes the ACK message to the MGCF A118. The ACK message routed in step416may be substantially the same as the ACK message sent in step415.

It is noted that at this point, the call context maintained at VCC A131for the call between UE A110and UE B120includes the SDP information of UE A110, the SDP information of MGW A114, and the COPs information of UE B120. Similarly, the call context maintained at VCC B132for the call between UE A110and UE B120includes the SDP information of UE B120and the SDP information of MGW B124. In addition, the call context maintained at VCC B132for the call between UE A110and UE B120may include the COPs information of UE A110.

Herein, it is noted that steps401through416are similar to steps for establishing a call according to the related art. That is, once the ACK message is received from the UE A110in step416, the IMS voice call is setup through a bearer path that includes CS trunks that traverse through the CDMA 1x wireless communication network (e.g., the H-MSC100), as shown inFIG. 1. However, VCC A131performs a trunk optimization function for bypassing and releasing the CS trunks that traverse through the CDMA 1x wireless communication network. This operation is described below in steps417through431.

Based on the response from the VCC B132, namely the contents of the 1xx/200 OK message sent in step413, the VCC A131determines whether the VCC A131and the VCC B132are the same VCC, namely VCC130. If the VCC A131determines that the VCC A131and the VCC B132are different VCCs, the VCC A131continues to process the IMS voice call according to the related art (e.g., the VCC A131waits for a Call Release from either UE A110or UE B120). In contrast, if the VCC A131determines that the VCC A131and the VCC B132are the same VCC, namely VCC130, the VCC A131initiates CS trunking optimization once the ACK message is received from the UE A110in step416, which indicates that the IMS call has been setup. Here, it is assumed that the VCC A131determines that the VCC A131and the VCC B132are the same VCC, namely VCC130.

Herein, it is also assumed that the UE A110and the UE B120support different CODECs and that the different CODECs operate in the same COPs at the same rate. The scenario where the UE A110and the UE B120support the same CODECs was described above with reference toFIGS. 2 and 3. Also, the scenario where the UE A110and the UE B120support different CODECs without consideration of whether the different CODECs operate in the same COPs at the same rate, and the scenario where the UE A110and the UE B120support different CODECs that, after consideration of whether the different CODECs operate in the same COPs at the same rate, are found to not operate in the same COPs at the same rate, are described below with reference toFIGS. 5 and 6.

At this point the VCC A131has determined that the VCC A131and the VCC B132are the same VCC, namely VCC130. Thus, CS trucking optimization is triggered, which is described in steps417through419.

In step417, to initiate CS trucking optimization, the VCC A131sends an Optimize Request message to the VCC B132. The Optimize Request message sent in step417includes a Called ID, a Call Context of the call between the UE A110and the UE B120, SDP information of the UE A110, and COPs and/or rate information. At this point, the VCC B132determines that UE A110and UE B120support different CODECs that operate in the same COPs at the same rate.

In step418, the VCC B132sends an Optimize ACK message to the VCC A131. The Optimize ACK message sent in step418includes the Called ID, the Call Context of the call between the UE A110and the UE B120, SDP information of the UE B120, and COPs and/or rate information. At this point, the VCC A131determines that UE A110and UE B120support different CODECs that operate in the same COPs at the same rate.

In step419, the VCC A131sends an Optimize Confirm message to the VCC B132. The Optimize Confirm message sent in step419includes the Called ID and the Call Context of the call between the UE A110and the UE B120. Here, the triggering of the CS trucking optimization triggers the establishment of a bypass bearer150in steps420through423, and the release of the CS trunks (marked with an ‘X’) in steps424through431.

To establish the bypass bearer150, in step420, the VCC A131sends an INVITE message to the UE A110. The INVITE message in step420includes a URI of UE B120, SDP information of the UE B120, and COPs and/or rate information of UE B120. In step421,200OK and ACK messages are exchanged between the UE A110and the VCC A131. Meanwhile, in step422, the VCC B132sends an INVITE message to the UE B120. The INVITE message in step422includes a URI of UE B120, SDP information of the UE A110, and COPs and/or rate information of UE A110. In step423, 200 OK and ACK messages are exchanged between the UE B120and the VCC B132. At this point, the bypass bearer path150shown inFIG. 2is established that bypasses the CS trunks.

It is noted that at this point, the call context maintained at VCC A131for the call between UE A110and UE B120includes the SDP information of UE A110, the SDP information of UE B120, and COPs and/or rate information of UE B120. Similarly, the call context maintained at VCC B132for the call between UE A110and UE B120includes the SDP information of UE B120and the SDP information of UE A110. In addition, the call context maintained at VCC B132may include COPs and/or rate information of UE A110.

Meanwhile, to release the CS trunks (marked with an ‘X’), in step424, the VCC A131sends a BYE message to the MGCF A118. The BYE message sent in step424includes the URI of UE B120. In step425, the MGCF A118sends a REL message to the H-MSC100. The REL message sent in step425includes the number of the UE A110as the CgPN and the number of the UE B120as the CdPN. In step426, the H-MSC100sends a REL message to the MGCF B128. The REL message sent in step426includes the number of the UE A110as the CgPN and an IMRN as the CdPN. In step427, the MGCF B128sends a BYE message to the VCC B132. The BYE message sent in step427includes the URI of the UE B120and SDP information for UE A110. In step428, the VCC B132sends a 200 OK message to the MGCF B128. In step429, the MGCF B128sends a RLC message to the H-MSC100. In step430, the H-MSC100routes the RLC message to the MGCF A118. In step431, the MGCF A118sends a 200 OK message to the VCC A131.

At this point, the CS trunks (marked with an ‘X’) including CIC1and CIC2for the voice call between UE A110and UE B120are released at the MGW A114and the MGW B124. Herein, it is noted that the CS trunks are released without the VCC B132releasing toward the UE B120.

Regarding call release for when the call is to be terminated, either the UE A110or the UE B120may initiate Call Release. For convenience in explanation, it is assumed herein that the UE A110initiates Call Release. That is, in step432, the UE A110sends a BYE message to the VCC A131. The BYE message sent in step432includes the URI of UE B120. In step434, the VCC A131sends a Release message to VCC B132. The Release message sent in step434includes the Called ID and the Call Context of the call between the UE A110and the UE B120. In step435, the VCC B sends a BYE message to the UE B120. The BYE message includes the URI of UE B120. In step436, the UE B120sends a 200 OK message to the VCC B132. In step437, the VCC B132sends a Release ACK message to the VCC A131. The Release ACK message sent in step437includes the Called ID and the Call Context of the call between the UE A110and the UE B120. In step433, the VCC A sends a 200 OK message to the UE A110. At this point, the voice call is terminated and the bypass bearer path150shown inFIG. 2is released.

In the above scenario, it is assumed that the originating and terminating UEs, UE A110and UE B120, utilize different CODECs that operate in the same COPs at the same rate. However, in the case where the CODECs used by the originating and terminating UEs, UE A110and UE B120, are different and do not operate in the same COPs at the same rate, a Media Resource Function (MRF) may be employed in the bypass bearer path to perform transcoding of the IMS voice call. Also, the MRF may be employed in the bypass bearer path to perform transcoding of the IMS voice call for the case where the originating and terminating UEs, UE A110and UE B120, employ different CODECs without consideration of whether the different CODECs operate in the same COPs at the same rate. These scenarios are described below with reference toFIGS. 5 and 6.

IMS Voice Call Scenario where Different CODECs are Employed without Consideration of Whether the Different CODECs Operate in Same COPs at Same Rate or where Different Codecs are Employed that do not Operate in the Same COPs at the Same Rate

FIG. 5illustrates an IMS network diagram for a voice call in which different CODECs are employed according to an exemplary embodiment of the present invention.FIG. 6illustrates a message flow of the IMS voice call scenario shown inFIG. 5in which different CODECs are employed. The network elements shown inFIGS. 5 and 6, other than the MRF A140, are substantially the same as the network elements shown inFIG. 1, and thus a description thereof is omitted for brevity. The MRF A140is employed in the bypass bearer path to perform transcoding of the IMS voice call when the CODECs employed by the UE A110and the UE B120are different. The MRF A140may be implemented in an application server.

As will be described below, the scenario shown inFIG. 5is applicable to the scenario where different CODECs are employed without consideration of whether the different CODECs operate in the same COPs at the same rate, and the scenario where different CODECs are employed that, after consideration of whether the different CODECs operate in the same COPs at the same rate, are found to not operate in the same COPs at the same rate.

Referring toFIGS. 5 and 6, in step601, UE A110while being serviced by the LTE network initiates a voice call by sending an INVITE message to VCC A131. The INVITE message sent in step601includes a URI of UE B120and SDP information of the UE A110. The SDP information of the UE A110includes codec information of UE A110. In addition, depending on the exemplary implementation, the INVITE message sent in step301may additionally include COPs and/or rate information of UE A110. The VCC A131stores the VCC A context, which includes at least one of a CgPN, a CdPN, a Term Status, and the SDP information of the UE A110. The VCC A context may include COPs and/or rate information. In step602, the VCC A131routes the INVITE message to the MGCF A118. The INVITE message routed in step602may be substantially the same as the INVITE message sent in step601.

In step603, the MGCF A118sends an IAM to the H-MSC100. The IAM sent in step603includes a number of the UE A110as the CgPN, a number of the UE B120as the CdPN, and a first CIC CIC1. In step604, the H-MSC100sends an IAM to the MGCF B128. The IAM sent in step604includes the number of the UE A110as the CgPN, the number of the UE B120as the CdPN, and a second CIC CIC2.

In step605, the MGCF B128sends an INVITE message to the VCC B132. The INVITE message sent in step605includes the URI of UE B120and SDP information of the MGW B124. In step606, the VCC B132routes the INVITE message to the UE B120. The INVITE message routed in step606may be substantially the same as the INVITE message sent in step605.

In step607, the UE B120sends a 1xx/200 OK message to the VCC B132. The 1xx/200 OK message sent in step607includes a URI of the UE B120and SDP information of the UE B120. In addition, depending on the exemplary implementation, the 1xx/200 OK message sent in step607may additionally include COPs and/or rate information of UE B120. In step608, the VCC B132routes the 1xx/200 OK message to the MGCF B128. The 1xx/200 OK message routed in step608may be substantially the same as the 1xx/200 OK message sent in step607.

In step609, the MGCF B128sends an ACK message to the VCC B132. In step610, the VCC B132routes the ACK message to the UE B120. The ACK message routed in step610may be substantially the same as the ACK message sent in step609.

Meanwhile, in step611, the MGCF B128sends an ACM/ANM to the H-MSC100. In step612, the H-MSC100routes the ACM/ANM to the MGCF A118. The ACM/ANM routed in step611may be substantially the same as the ACM/ANM sent in step612.

In step613, the MGCF A118sends a 1xx/200 OK message to the VCC A131. The 1xx/200 OK message sent in step613includes the URI of UE B120and SDP information of the MGW A114. In step614, the VCC A131routes the 1xx/200 OK message to the UE A110. The 1xx/200 OK message routed in step614may be substantially the same as the 1xx/200 OK message sent in step613.

In step615, the UE A110sends an ACK message to the VCC A131. In step616, the VCC A131routes the ACK message to the MGCF A118. The ACK message routed in step616may be substantially the same as the ACK message sent in step615.

It is noted that at this point, the call context maintained at VCC A131for the call between UE A110and UE B120includes the SDP information of UE A110and the SDP information of MGW A114. The call context maintained at VCC A131may include COPs and/or rate information. Similarly, the call context maintained at VCC B132for the call between UE A110and UE B120includes the SDP information of UE B120and the SDP information of MGW B124. The call context maintained at VCC B132may include COPs and/or rate information.

Herein, it is noted that steps601through616are similar to steps for establishing a call according to the related art. That is, once the ACK message is received from the UE A110in step616, the IMS voice call is setup through a bearer path that includes CS trunks that traverse through the CDMA 1x wireless communication network (e.g., the H-MSC100), as shown inFIG. 1. However, VCC A131performs a trunk optimization function for bypassing and releasing the CS trunks that traverse through the CDMA 1x wireless communication network. This operation is described below in steps617through639.

Based on the response from the VCC B132, namely the contents of the 1xx/200 OK message sent in step613, the VCC A131determines whether the VCC A131and the VCC B132are the same VCC, namely VCC130. If the VCC A131determines that the VCC A131and the VCC B132are different VCCs, the VCC A131continues to process the IMS voice call according to the related art (e.g., the VCC A131waits for a Call Release from either UE A110or UE B120). In contrast, if the VCC A131determines that the VCC A131and the VCC B132are the same VCC, namely VCC130, the VCC A131initiates CS trunking optimization once the ACK message is received from the UE A110in step616, which indicates that the IMS call has been setup. Here, it is assumed that the VCC A131determines that the VCC A131and the VCC B132are the same VCC, namely VCC130. Accordingly, the CS trucking optimization is triggered.

Herein, it also assumed that the UE A110and the UE B120support different CODECs and it is not considered whether the different CODECs operate in the same COPs at the same rate. Alternatively, it is assumed that that the UE A110and the UE B120support different CODECs, it is considered whether the different CODECs operate in the same COPs at the same rate, and the different CODECs do not operate in the same COPs at the same rate.

The scenario where the UE A110and the UE B120support the same CODECs has been described above with reference toFIGS. 2 and 3, and the scenario where the UE A110and the UE B120support different CODECs that, after consideration of whether different CODECs operate in the same COPs at the same rate, are found to operate in the same COPs at the same rate, is described above with respect toFIGS. 2 and 4.

At this point, the VCC A131determined that the VCC A131and the VCC B132are the same VCC, namely VCC130. Accordingly, the CS trucking optimization is triggered. The CS trucking optimization according the present exemplary implementation is described below in steps617through629. Herein, while it is assumed that the transcoding is supported by the originating network, the transcoding may alternatively be supported by the terminating network.

In step617, to initiate CS trucking optimization, the VCC A131sends an Optimize Request message to the VCC B132. The Optimize Request message sent in step617includes a Called ID, a Call Context of the call between the UE A110and the UE B120, and SDP information of the UE A110. At this point, the VCC B132determines that UE A110and UE B120support different CODECs and waits for an updated SDP from VCC A131. Here, depending on the implementation, the VCC B132may determine that UE A110and UE B120support different CODECs, or the VCC B132may determine that UE A110and UE B120support different CODECs that do not operate in the same COPs at the same rate.

In step618, VCC B132sends an Optimize ACK message to the VCC A131. The Optimize ACK message sent in step618includes the Called ID, the Call Context of the call between the UE A110and the UE B120, and SDP information of the UE B120. At this point, depending on the implementation, the VCC A131determines that UE A110and UE B120support different CODECs, or the VCC A131may determine that UE A110and UE B120support different CODECs that do not operate in the same COPs at the same rate. In either case, the VCC A131acts as a Back-to-Back User Agent (B2BUA) to interwork with MRF A140for transcoding.

To facilitate use of the MRF A140, dialogs for UE A110to MRF A140, and MRF140to UE B120, are established.

The MRF A140to UE B120dialog is established in steps619to621. More specifically, in step619, the VCC A131sends an INVITE message to the MRF A140. The INVITE message sent in step619includes a second URI of UE B120and SDP information of UE B120. In step620, the MRF A140sends a 200 OK message to the VCC A131. The 200 OK message sent in step620includes first SDP information of MRF A140. In step621, the VCC A131sends an ACK message to the MRF A140.

In step622, the VCC A131sends an Optimize Confirm message to the VCC B132. The Optimize Confirm message sent in step622includes the Called ID, the Call Context of the call between the UE A110and the UE B120, and the first SDP information of MRF A140.

In step623, the VCC B132sends an INVITE message to the UE B120. The INVITE message sent in step623includes a URI of UE B120and the first SDP information of the MRF A140. In step624, 200 OK and ACK messages are exchanged between the UE B120and the VCC B132.

The MRF A140to UE A110dialog is established in steps625to627. More specifically, in step625, the VCC A131sends an INVITE message to the MRF A140. The INVITE message sent in step625includes a URI of UE B120and SDP information of UE A110. In step626, the MRF A140sends a 200 OK message to the VCC A131. The 200 OK message sent in step626includes second SDP information of MRF A140. In step627, the VCC A131sends an ACK message to the MRF A140.

In step628, the VCC A628sends an INVITE message to the UE A110. The INVITE message sent in step628includes a URI of UE B120and second SDP information of the MRF A140. In step629, 200 OK and ACK messages are exchanged between the VCC A131and the UE A110.

At this point, the bypass bearer path150through MRF A140shown inFIG. 5is established that bypasses the CS trunks.

It is noted that at this point, the call context maintained at VCC A131for the call between UE A110and UE B120includes the SDP information of UE A110, the SDP information of MRF A140, and session dialog information for MRF A140and UE B120. The call context maintained at VCC A131may include COPs and/or rate information. Similarly, the call context maintained at VCC B132for the call between UE A110and UE B120includes the SDP information of UE B120and the first SDP information of MRF A140. The release of the CS trunks (marked with an ‘X’) is described below in steps630through637. The call context maintained at VCC B132may include COPs and/or rate information.

Meanwhile, to release the CS trunks (marked with an ‘X’), in step630, the VCC A131sends a BYE message to the MGCF A118. The BYE message sent in step630includes the URI of UE B120. In step631the MGCF A118sends a REL message to the H-MSC100. The REL message sent in step631includes the number of the UE A110as the CgPN and the number of the UE B120as the CdPN. In step632, the H-MSC100sends a REL message to the MGCF B128. The REL message sent in step632includes the number of the UE A110as the CgPN and an IMRN as the CdPN. In step633, the MGCF B128sends a BYE message to the VCC B132. The BYE message sent in step633includes the URI of the UE B120and SDP information for UE A110. In step634, the VCC B132sends a 200 OK message to the MGCF B128. In step635, the MGCF B128sends a RLC message to the H-MSC100. In step636, the H-MSC100routes the RLC message to the MGCF A118. In step637, the MGCF A118sends a 200 OK message to the VCC A131.

At this point, the CS trunks (marked with an ‘X’) including CIC1and CIC2for the voice call between UE A110and UE B120are released at the MGW A114and the MGW B124. Herein, it is noted that the CS trunks are released without the VCC B132releasing toward the UE B120.

Regarding call release for when the call is to be terminated, either the UE A110or the UE B120may initiate Call Release. For convenience in explanation, it is assumed herein that the UE A110initiates Call Release. That is, in step638, the UE A110sends a BYE message to the VCC A131. The BYE message sent in step638includes the URI of UE B120. In step639, the VCC A131sends a Release message to VCC B132. The Release message sent in step639includes the Called ID and the Call Context of the call between the UE A110and the UE B120. In step640, the VCC B sends a BYE message to the UE B120. The BYE message sent in step640includes the URI of UE B120. In step641, the UE B120sends a 200 OK message to the VCC B132. In step642, the VCC B132sends a Release ACK message to the VCC A131. The Release ACK message sent in step642includes the Called ID and the Call Context of the call between the UE A110and the UE B120. In step643, the VCC A sends a 200 OK message to the UE A110. In step644, the VCC A131sends a BYE message to the MRF A140. The BYE message sent in step644includes the URI of UE B120. In step645the MRF A140sends a 200 OK message to the VCC A131. In step646, the VCC A131sends a BYE message to the MRF A140. The BYE message sent in step646includes the second URI of UE B120. In step647, the MRF A140sends a 200 OK message to the VCC A131. At this point, the voice call is terminated and the bypass bearer path150through the MRF A140shown inFIG. 5is released.

A method for an enhanced VCC function to optimize trunks for an IMS voice call is described below with reference toFIG. 7.

Method for Enhanced VCC Function

FIG. 7illustrates a flowchart of a method for an enhanced VCC function to optimize trunks for an IMS voice call according to an exemplary embodiment of the present invention.

Referring toFIG. 7, in step700, the enhanced VCC function receives a request from an originating UE for an IMS voice call with a terminating UE. Step700substantially corresponds to step301ofFIG. 3, step401ofFIG. 4, and step601ofFIG. 6. In step702, the enhanced VCC function controls to establish a bearer for the IMS voice call between the terminating UE and the originating UE through the CS network. This bearer is shown as a solid line inFIGS. 1,2, and5. Step702substantially corresponds to steps302,305-310, and313-316ofFIG. 3, steps402,405-410, and413-416ofFIG. 4, and steps602,605-610, and613-616ofFIG. 6.

In step704, the enhanced VCC function determines whether the enhanced VCC function serves both the originating UE and the terminating UE. If the enhanced VCC function determines that the enhanced VCC function does not serve both the originating UE and the terminating UE, the enhanced VCC function, in step706, performs operations according to the related art. In contrast, if the enhanced VCC function determines that the enhanced VCC function serves both the originating UE and the terminating UE, the enhanced VCC function, in step708, determines whether the originating UE and the terminating UE support different CODECs for IMS voice calls. If the enhanced VCC function determines that the originating UE and the terminating UE support the same CODECs for IMS voice calls, the enhanced VCC function, in step710, controls to establish a bypass bearer that bypasses the CS network for the IMS voice call. This bypass bearer is shown as bypass bearer150inFIG. 2. Step710substantially corresponds to steps317-323ofFIG. 3.

In contrast, if the enhanced VCC function determines that the originating UE and the terminating UE support different CODECs for IMS voice calls, the enhanced VCC function, in step712, determines if the different CODECs operate in the same COPs at the same rate. If the enhanced VCC function determines that the different CODECs of the originating UE and the terminating UE operate in the same COPs at the same rate, the enhanced VCC function performs step710. In contrast, if the enhanced VCC function determines that the different CODECs of the originating UE and the terminating UE do not operate in the same COPs at the same rate, the enhanced VCC function proceeds to step714. Herein, step712may be omitted. Step712substantially corresponds to steps417-423ofFIG. 4.

In step714, the enhanced VCC function controls to establish a bypass bearer through an MRF that bypasses the CS network for the IMS voice call. This bypass bearer is shown as bypass bearer150inFIG. 4. Step714substantially corresponds to steps617-629ofFIG. 6.

In step716, the enhanced VCC function controls to release the CS trunks toward the CS network (e.g., the H-MSC). The release is shown as the trunks marked with an ‘X’ inFIGS. 2 and 4. Step716substantially corresponds to steps324,327,328, and331ofFIG. 3, steps424,427,428, and431ofFIG. 4, and steps630,633,634, and637ofFIG. 6.

Thereafter, in step718, the enhanced VCC function controls to terminate the IMS voice calls and release the bypass bearer when a termination request is received from either the originating UE or the terminating UE. Step718substantially corresponds to steps332-337ofFIG. 3, steps432-437ofFIG. 4, and steps638-647ofFIG. 6.

A structure of a VCC application server according to an exemplary embodiment of the present invention will be described below with reference toFIG. 8.

Structure of VCC Application Server

FIG. 8illustrates a VCC application server according to an exemplary embodiment of the present invention.

Herein, it is noted that the VCC application server800is referred to as a VCC application server for convince in explanation and that the VCC application server800may be any application server which supports the VCC function by itself or in addition to one or more additional functions. Also, the VCC application server800may be may be an IMS application server. Alternatively, the VCC application server800may not be an IMS application server.

Referring toFIG. 8, the VCC application server800includes an enhanced VCC function810, a processor820, a memory830, and a communications unit840. The VCC application server800may include any number of additional structural elements. However, a description of additional structural elements of VCC application server800is omitted for brevity.

The enhanced VCC function810may be implemented as code that is executed by the processor820or may be implemented as hardware. The term “code” may be used herein to represent one or more of executable instructions, operand data, configuration parameters, and other information stored in memory830of the VCC application server800. The operations of the enhanced VCC function810include any of the operations explicitly or implicitly described above as being performed by an enhanced VCC function, a VCC function, VCC application server, VCC A131, VCC B132, and VCC130.

The processor820is used to process general operations of the device800and may be used to execute the code of the enhanced VCC function810.

The memory830may store the code of the enhanced VCC function810in addition to one or more of executable instructions, operand data, configuration parameters, and other information stored of the VCC application server800. Depending on the exact configuration and type of VCC application server800, the memory830may be volatile (such as Random Access Memory (RAM)), non-volatile (such as Read Only Memory (ROM), flash memory, etc.) or some combination of thereof.

The communications unit840sends and receives data between the enhanced VCC function810and other entities, such as UE A110, H-MSC100, etc. The communications unit840may include any number of transceivers, receivers, and transmitters of any number of types, such as wired, wireless, etc.

Non-Transitory Processor Readable Medium