Accurate Packet Switched Voice Supported Indication

CROSS-REFERENCE TO RELATED APPLICATIONS:

[0001] The present application is related to and claims the benefit and/or priority of U.S. Provisional Patent Application No. 61/586,538 filed January 13, 2012, which is hereby incorporated herein by reference in its entirety.

BACKGROUND: Field:

[0002] Any given user equipment may support different radio access technologies (RAT) (frequency bands) and/or frequency division duplex (FDD)-time division duplex (TDD) for inter/intra-RAT handover. Likewise a serving network can have different layers for coverage (for example, packet switched to packet switched handover). Accurate packet switched voice supported indication can permit reliable operation of such systems. Description of the Related Art:

[0003] Long term evolution (LTE) of the 3rd generation partnership project (3GPP) can support voice by such ways as voice over internet protocol (IP) multimedia subsystem (IMS) and circuit switched (CS) fallback (CSFB). If voice over IMS is supported by an evolved packet system (EPS) then a mobility management entity (MME) can indicate this support by providing an "IMS voice over PS Session Supported" indication to a user equipment (UE).

[0004] For example, the serving public land mobile network (PLMN) can provide such an indication based on, for example, local policy, home PLMN (HPLMN), the single radio voice call continuity (SRVCC) capability of the network and user equipment and/or extent of universal terrestrial radio access network (UTRAN)/evolved UTRAN (E-UTRAN) coverage. The serving PLMN can indicate to the user equipment that the user equipment can expect a successful IMS voice over packet switched (PS) session when the mobility management entity is configured to know that the serving PLMN has a roaming agreement for IMS voice with the HPLMN of the user equipment. This indication can be made per a tracking area identity (TAI) list. [0005] Not all conceivable ways of providing this "IMS voice over PS Session Supported" indication to a user equipment are accurate or even possible. For example, if a mobility management entity is to read the user equipment's radio capabilities before sending "IMS voice over PS Session Supported" to the user equipment, while the mobility management entity may be able to read the user equipment's radio capabilities, the mobility management entity may not know the neighboring cell info for packet switched to packet switched (PS-PS) handover (HO), unless radio related configuration is also given to mobility management entity. This creates a lot of radio specific information in the mobility management entity (and more generally in the core network) and tends to make the system less layer independent.

[0006] Moreover, user equipment's radio capabilities information is not always available in the mobility management entity at the time that "IMS voice over PS Session Supported" indication is returned to the user equipment in EPS attach or tracking area update (TAU) procedure. For instance, in case of a tracking area update response right after an inter- MME mobility or first ATTACH response, the user equipment's radio capabilities may not be available in the target mobility management entity.

[0007] Alternatively, the user equipment can indicate global system for mobile communication (GSM) edge radio access network (GERAN)/UTRAN single radio voice call continuity support separately in non-access stratum (NAS) to mobility management entity. Hence, mismatch between access stratum (AS) and NAS level indications can be avoided. CSFB can be used if single radio voice call continuity cannot be supported by the user equipment. This approach, however, may not address a PS-PS handover related to frequency band support situation.

[0008] In another approach, the user equipment may omit indicating that single radio voice call continuity is supported in the NAS level unless the user equipment has at least one supported RAT in the AS level: for example, it has interoperability tested (lOTed) to one of the radio access technologies.

[0009] Another approach is to rely on single radio voice call continuity as backup. For example, when PS-PS handover cannot be performed because the user equipment/Radio network capabilities do not match, then single radio voice call continuity to 2/3G circuit switched can be used for continuing the voice support. SUMMARY:

[0010] According to certain embodiments, a method includes determining whether a user equipment can support voice over packet switched, based on information about the user equipment and the network.

[0011] In certain embodiments, a non-transitory computer readable medium is encoded with instructions that, when executed in hardware, perform a process. The process includes determining whether a user equipment can support voice over packet switched, based on information about the user equipment and the network.

[0012] An apparatus, according to certain embodiments, includes determining means for determining whether a user equipment can support voice over packet switched, based on information about the user equipment and the network.

[0013] An apparatus, in certain embodiments, includes at least one processor and at least one memory including computer program code. The at least one memory and computer program code are configured to, with the at least one processor, cause the apparatus at least to determine whether a user equipment can support voice over packet switched, based on information about the user equipment and the network.

[0014] According to certain embodiments, a method includes receiving from a network element a request for information about whether a user equipment can support voice over packet switched. The method also includes providing a response to the request to the network element, wherein the network element is configured to determine whether the user equipment can support voice over packet switched, based on the response and information about the network.

[0015] In certain embodiments, a non-transitory computer readable medium is encoded with instructions that, when executed in hardware, perform a process. The process includes receiving from a network element a request for information about whether a user equipment can support voice over packet switched. The process also includes providing a response to the request to the network element, wherein the network element is configured to determine whether the user equipment can support voice over packet switched, based on the response and information about the network.

[0016] An apparatus, according to certain embodiments, includes receiving means for receiving from a network element a request for information about whether a user equipment can support voice over packet switched. The apparatus also includes response means for providing a response to the request to the network element, wherein the network element is configured to determine whether the user equipment can support voice over packet switched, based on the response and information about the network.

[0017] An apparatus, in certain embodiments, includes at least one processor and at least one memory including computer program code. The at least one memory and computer program code are configured to, with the at least one processor, cause the apparatus at least to process a request, received from a network element, for information about whether a user equipment can support voice over packet switched. The at least one memory and computer program code are also configured to, with the at least one processor, cause the apparatus at least to provide a response to the request to the network element, wherein the network element is configured to determine whether the user equipment can support voice over packet switched, based on the response and information about the network.

BRIEF DESCRIPTION OF THE DRAWINGS:

[0018] For proper understanding of the invention, reference should be made to the accompanying drawings, wherein:

[0019] Figure 1 illustrates coverage scenarios according to certain embodiments.

[0020] Figure 2 illustrates a method according to a first embodiment.

[0021] Figure 3 illustrates a method according to a second embodiment.

[0022] Figure 4 illustrates a method according to a third embodiment.

[0023] Figure 5 illustrates a method according to a fourth embodiment.

[0024] Figure 6 illustrates high level procedure for long term evolution packet switched voice indication according to certain embodiments.

[0025] Figure 7 illustrates a method according to certain embodiments.

[0026] Figure 8 illustrates a system according to certain embodiments.

DETAILED DESCRIPTION:

[0027] Third generation partnership projection (3GPP) technical specification (TS) 23.401 (which is incorporated herein its entirety) indicates that if voice over internet protocol (IP) multimedia subsystem (IMS) is supported by the evolved packet system (EPS) then a mobility management entity (MME) provides "IMS voice over PS Session Supported" indication to user equipment. And the mobility management entity, in certain embodiments, will expect that single radio voice call continuity or PS-PS handover can be performed by the user equipment for voice call continuity.

[0028] However, the mobility management entity is conventionally not aware of access stratum (AS) level information related to single radio voice call continuity (SRVCC), including to which radio access technology (RAT) that the user equipment has been SRVCC interoperability tested (lOTed). For example, the IOT bit(s) for SRVCC to UMTS and for SRVCC to GSM may be provided in two separate feature group indicators (FGIs). In other words, the mobility management entity is conventionally not aware of information exchanged via access stratum protocols between user equipment and radio access network.

[0029] Moreover, the mobility management entity conventionally receives only non- access stratum (NAS) level information from user equipment that the user equipment supports single radio voice call continuity. The mobility management entity, however, does not receive non-access stratum level information from the user equipment about whether single radio voice call continuity is restricted to single radio voice call continuity to second generation (2G) only or third generation (3G) only. For example, if the user equipment only supports single radio voice call continuity to 3G and not to 2G but the EPS network supports only single radio voice call continuity to 2G (or if 3G coverage is limited compared to 2G coverage) then mobility management entity would not conventionally be able to detect this discrepancy between AS and NAS, and would conventionally falsely indicate "IMS voice over PS Session Supported" to the user equipment. If a voice call is still setup in LTE and UE runs out of the LTE coverage, the voice call will drop and this will bring bad user experience.

[0030] The mobility management entity, moreover, conventionally does not know the radio related information such as surrounding neighbor cell/frequency for packet switched handover determination and the user equipment's inter-RAT capabilities. In other words, the mobility management entity does not know which bands the user equipment can support. Thus, the mobility management entity may assume that the user equipment can support the long term evolution frequency bands that the network is using and so give "IMS voice over PS Session Supported" to the user equipment. However, if the user equipment supports long term evolution with band X and UMTS with band Y but the network only serves voice over IP (VoIP) on long term evolution band X and universal mobile telecommunications system (UMTS) with band Z, then the user equipment will have packet switched voice call dropped when it goes between band X and Z. A similar scenario can also occur for an area covered by multiple long term evolution layers with different frequency bands. Therefore, this issue can also apply to intra-RAT long term evolution as well.

[0031] In short, any given user equipment may support different RAT (and/ or frequency bands) and/or frequency division duplex (FDD)-time division duplex (TDD) for inter/intra-RAT handover. Likewise a serving network can have different layers for coverage (for example, PS-PS handover). Indeed, even a user equipment in its home network may have various capabilities, as a user equipment may not be configured to support all long term evolution bands.

[0032] Additionally, although the issue described above may be described in terms of single radio voice call continuity with FGI/NAS mismatch, the same kind of consequence (for example, voice session is dropped) can also be applied to wherever the network and the radio capabilities are mismatched. For example, there are something like -25 bands defined for FDD and ~1 1 bands for TDD in long term evolution. If the long term evolution voice coverage is based on certain combination of FDD or TDD bands, or a combination of FDD and TDD bands together then the NAS level indication "IMS voice over PS Session Supported" from mobility management entity can, in certain embodiments, be given based on the radio network layer topology and the user equipment's radio capabilities properly matched. Otherwise, the intra-LTE packet switched handover for voice session may not be possible but the user equipment will think that it is safe to use IMS voice over long term evolution. The end result is that the voice session is dropped when the user equipment crosses from one long term evolution band to another.

[0033] Another example is related to inter-RAT packet switched handover to high speed packet access (HSPA) for IMS voice session. It is possible that the user equipment only supports IMS voice over long term evolution but not IMS voice over HSPA. This may be because user equipment which supports IMS voice over HSPA depends on supporting network requested packet data protocol (PDP) context and conversational quality of service (QoS) traffic class PDP context, and such capabilities may not be implemented on early voice over long term evolution (VoLTE) devices. Therefore, if the IMS voice coverage is based on inter-RAT packet switched handover to HSPA then the NAS level indication "IMS voice over PS Session Supported" from mobility management entity can, in certain embodiments, be given based on the user equipment capabilities to perform IMS voice over HSPA and the coverage dependency for overlapping HSPA and long term evolution.

[0034] Figure 1 illustrates coverage scenarios according to certain embodiments. The same mobility management entity (MME) can respond differently to the different illustrated scenarios during a tracking area update or long term evolution attach with respect to the "IMS voice over PS Session Supported" indication for the same user equipment depending on how the voice session coverage is handled. For example, packet switched voice coverage conditions can change in each of the areas. Some of this change may be reflected in a tracking area identity (TAI) list.

[0035] As shown in Figure 1 , the MME may provide a IMS PS voice = Yes when a user equipment (UE) equipped with frequency division duplex (FDD) band A and B is in an area of overlapping coverage with a first network having FDD band A, and a second network having FDD band B. However, when the same user moves to an area where the second network uses time division duplex (TDD) band C or high speed packet access (HSPA), then the MME may provide a response an indication of IMS PS voice = "No".

[0036] In summary, the following variables can be taken into account when determining the correct setting on "IMS voice over PS session Supported indication". User equipment capabilities to be taken into account can include single radio voice call continuity from long term evolution to 3G, single radio voice call continuity from long term evolution to 2G, IMS voice supported over long term evolution, IMS Voice supported over HSPA, and PS-PS handover to 3G/2G. User equipment radio capabilities to be taken into account can include FDD bands, TDD bands, packet switched handover from long term evolution FDD to long term evolution TDD or vice versa, and packet switched handover from long term evolution FDD/TDD to 3G TDD/FDD or vice versa. Radio network topology for the voice coverage at the user equipment location to be taken into consideration can include based on single radio voice call continuity to 2G, based on single radio voice call continuity to 3G (TDD and/or FDD), based on PS-PS handover to other long term evolution band (FDD and/or TDD), or based on PS-PS handover to HSPA (FDD and/or TDD).

[0037] However, conventionally a mobility management entity may be lacking detailed information to ensure voice can be continued in an environment where the user equipment capabilities and network capabilities/policy for voice call continuity may not match. Certain embodiments, therefore, ensure that voice can be continued in an environment where the user equipment capabilities and network capabilities/policy for voice call continuity may not match, taking into account, for example, the characteristics mentioned above.

[0038] Figure 2 illustrates a method according to a first embodiment (herein the terms "first," "second," and so forth as applied to embodiments are to be understood simply as designators for ease of reference, not indicators of order, preference, or the like). As shown in Figure 2, at 210, at an attach or tracking area update procedure, the user equipment and network can follow the existing procedure as defined in release 10 (R10) of 3GPP, except that additionally the mobility management entity can also indicate to the base station eNodeB ("eNb") the "IMS Voice over PS session supported Indication" in InitialContextSetupRequest to the eNodeB or some new S1 AP signaling message to be defined.

[0039] Then, at 220, the eNodeB gets the user equipment's radio capabilities as part of the existing procedure either from mobility management entity or from user equipment.

[0040] Subsequently, at 230, if the received "IMS Voice over PS session supported Indication" from mobility management entity is set to TRUE, eNB can evaluate the user equipment's radio capabilities when the indication is received. The eNB evaluates whether PS-PS handover or single radio voice call continuity can be performed based on such criteria as operator policy, network deployment situation, user equipment's capabilities, or the like. If the eNB decides that the PS-PS handover and/or single radio voice call continuity is not possible so that voice call cannot be continued, then eNB includes "Voice over PS session not possible" flag in a message to the mobility management entity. For example, the message can be an S1 AP message, e.g., Initial Context Setup Response or UE CAPABILITY INFO INDICATION INFO or new S1 AP message.

[0041] Then, at 240, if at 210 mobility management entity indicated to user equipment that "IMS Voice over PS session support Indication" is TRUE and if mobility management entity receives this "Voice over PS session not possible" flag from eNodeB, then the mobility management entity can force the user equipment to perform a re-attachment to long term evolution. The mobility management entity then return "IMS Voice over PS session supported Indication" to FALSE to user equipment at this new ATTACH.

[0042] Moreover, before the MME sends "IMS VoPS session supported Indication" to the eNB the UE can, at 205, provide PS HO possible to 3G and/or PS HO possible to 2G with other existing UE capability parameters. Based on this information plus roaming, policy, and the like, the network can decide "IMS VoPS session supported Indication" in step 210. Other parameters can include, for example, SRVCC support for 2G/3G, UE supporting VoHSPA, Voice centric UE or not, preferred domain, (for example, PS or CS) and the like.

[0043] Figure 3 illustrates a method according to a second embodiment. One difference between the second embodiment and the first embodiment is that in the second embodiment, the mobility management entity can provide the information to the eNB during S1 setup or is delivered by operations, administration, and maintenance (OAM) procedures. A result of evaluation by the eNB can be delivered to the mobility management entity in an S1 AP message.

[0044] In particular, as shown in Figure 3, at 310, the mobility management entity provides the "IMS Voice over PS session supported Indication" or some other indication to notify that the network supports IMS Voice over packet switched to eNB during the S1 setup. This can be characterized more as network capability than as individual per user equipment related information. Thus this information can be provided to the eNB even by operations and maintenance (O&M). Other ways of providing the information to the eNB are also permitted.

[0045] Then, at an attach or tracking area update procedure, the user equipment and network can follow the existing procedure as defined currently in R10 and, at 320, the eNB gets the user equipment's radio capabilities as part of the procedure either from the mobility management entity or from the user equipment.

[0046] If the eNB knows that mobility management entity supports IMS Voice over packet switched, then at 330, eNB evaluates the user equipment's radio capabilities. For example, the eNB evaluates whether PS-PS handover and/or single radio voice call continuity can be performed based on such criteria as operator policy, network deployment situation, user equipment's capabilities, or the like. If the eNB decides that the PS-PS handover and/or single radio voice call continuity are not possible, then eNB includes "Voice over PS session not possible" flag to mobility management entity in an S1 AP message, e.g., Initial Context Setup Response or UE CAPABILITY INFO INDICATION INFO or new S1 AP message.

[0047] If at 310, mobility management entity indicated to user equipment that "IMS Voice over PS session support Indication" is TRUE and if mobility management entity receives this "Voice over PS session not possible" flag from eNb, at 340, the mobility management entity can force the user equipment to perform a re-attachment to long term evolution and mobility management entity returns "IMS Voice over PS session supported Indication" to FALSE to user equipment at this new ATTACH.

[0048] When the mobility management entity set the "IMS Voice over PS session supported Indication" to FALSE during the forced long term evolution attach, the user equipment can then use CSFB as backup, based on its voice preference settings. The above procedures may not impact any conventional long term evolution user equipment.

[0049] The first and second embodiments may operate well when the number of user equipment that would require forced re-attach would be small. However, an AS or NAS procedure can be performed to allow the newer user equipment to behave differently. Thus, in certain embodiments only legacy long term evolution user equipment use the first and/or second embodiments described above, whereas the new long term evolution user equipment use the third and/or fourth embodiments described below.

[0050] The third and fourth embodiments may avoid forced re-attaches by either eNB or mobility management entity forcing the user equipment to perform a tracking area update.

[0051] Moreover, before the MME sends "IMS VoPS session supported Indication" to the eNB the UE can, at 305, provide PS HO possible to 3G and/or PS HO possible to 2G with other existing UE capability parameters. Based on this information plus roaming, policy, and the like, the network can decide "IMS VoPS session supported Indication" in step 310. Other parameters can include, for example, SRVCC support for 2G/3G, UE supporting VoHSPA, Voice centric UE or not, preferred domain, (for example, PS or CS) and the like.

[0052] Figure 4 illustrates a method according to a third embodiment. The method of Figure 4 can include an AS procedure, as explained below.

[0053] At attach or tracking area update procedure, the user equipment and network can follow the existing procedure as defined currently in R10. In addition, at 410, the mobility management entity can also indicate to the eNodeB the "IMS Voice over PS session supported Indication" in InitialContextSetupRequest to eNodeB.

[0054] At 420, the eNodeB can get the user equipment's radio capabilities as described above. If the received "IMS Voice over PS session supported Indication" from mobility management entity is set to TRUE, at 430, the eNB can evaluate the user equipment's radio capabilities when received.

[0055] The eNB can also be aware that this user equipment supports an AS interaction procedure defined by a user equipment's radio capability bit. Hence, the eNB can evaluate whether PS-PS handover and/or single radio voice call continuity can be performed based on operator policy, network deployment situation, user equipment's capabilities or the like. If eNB decides that the PS-PS handover and/or single radio voice call continuity is not possible, then at 440, the eNB can instruct the user equipment to perform a tracking area update with voice preference set to prefer CSFB instead of IMS voice or set to CSFB only.

[0056] Moreover, before the MME sends "IMS VoPS session supported Indication" to the eNB the UE can, at 405, provide PS HO possible to 3G and/or PS HO possible to 2G with other existing UE capability parameters. Based on this information plus roaming, policy, and the like, the network can decide "IMS VoPS session supported Indication" in step 410. Other parameters can include, for example, SRVCC support for 2G/3G, UE supporting VoHSPA, Voice centric UE or not, preferred domain, (for example, PS or CS) and the like.

[0057] Figure 5 illustrates a method according to a fourth embodiment. The method of Figure 5 can include an NAS procedure, as explained below.

[0058] At attach or tracking area update procedure, the user equipment and network follow the existing procedure as defined currently in R10. In addition, at 510, the mobility management entity can also indicate to the eNodeB the "IMS Voice over PS session supported Indication" in InitialContextSetupRequest to the eNodeB.

[0059] At 520, the eNodeB can get the user equipment's radio capabilities as described above.

[0060] If the received "IMS Voice over PS session supported Indication" from mobility management entity is set to TRUE, at 530, the eNB can evaluate the user equipment's radio capabilities. That is, the eNB can evaluate whether PS-PS handover and/or single radio voice call continuity can be performed based on operator policy, network deployment situation, user equipment's capabilities or the like. If eNB decides that the PS-PS handover and/or single radio voice call continuity is not possible, then eNB can include "Voice over PS session not possible" flag to mobility management entity in an S1 AP message, e.g., Initial Context Setup Response or UE CAPABILITY INFO INDICATION INFO or new S1 AP message.

[0061] The mobility management entity can determine, based on the user equipment's capability exchange info, that the user equipment supports the following NAS procedure. Accordingly, at 540, the mobility management entity can send an indication to the user equipment via NAS to instruct the user equipment to perform a tracking area update with voice preference set to prefer CSFB instead of IMS voice or set to CSFB only.

[0062] When the user equipment is entering a new tracking area (TA), its voice setting can be reset to default. The default can be, for example, that IMS voice can be tried again. The network capability of PS-PS handover or single radio voice call continuity to 2/3G can be consistent within the TA list.

[0063] Moreover, before the MME sends "IMS VoPS session supported Indication" to the eNB the UE can, at 505, provide PS HO possible to 3G and/or PS HO possible to 2G with other existing UE capability parameters. Based on this information plus roaming, policy, and the like, the network can decide "IMS VoPS session supported Indication" in step 510. Other parameters can include, for example, SRVCC support for 2G/3G, UE supporting VoHSPA, Voice centric UE or not, preferred domain, (for example, PS or CS) and the like. [0064] Alternatively, this embodiment can be combined with the first or second embodiments described above. That is, the eNB can still indicate "Voice over PS session not possible" to the mobility management entity as in the first and second embodiments, and the eNB or mobility management entity can also indicate to the user equipment to trigger a tracking area update. Then instead of the mobility management entity triggering forced reattachment as in the first and second embodiments, the mobility management entity can wait for a tracking area update from the user equipment and provide "IMS Voice over PS session supported Indication" set to FALSE to user equipment at the time of the new tracking area update.

[0065] In order to support a combination of scenarios as shown in Figure 1 in addition to the single radio voice call continuity issue, several principles can be followed. The system can be modified to take into account non-cooperative legacy long term evolution user equipment as well as cooperative long term evolution user equipment. The user equipment can be configured to support IMS voice support over long term evolution and HSPA separately. The mobility management entity is not required to know about the radio network topology. For example, the mobility management entity is not required to know about Intra- or Inter-RAT packet switched handover band, FDD/TDD, or the like. Moreover, AS and NAS level interaction can be kept independent. The mobility management entity does not have to be aware of radio related parameter to make the proper decision. Moreover, voice-related AS issues can be kept between the user equipment and the eNB.

[0066] In certain embodiments, the radio related task can be handled by the eNodeB and an eNB-MME procedure can allow the mobility management entity to change the "voice over PS session Supported" indication, if appropriate.

[0067] Figure 6 illustrates high level procedure for long term evolution packet switched voice indication according to certain embodiments. As shown in Figure 6, at S1 -S2 the newer user equipment (UE) provides an indication of whether a user equipment supports SR-VCC to 3G, SR-VCC to 2G, packet switched handover to 3G, packet switched handover to 2G, and VoHSPA are supported. In a particular embodiment, the existing user equipment (UE) only provides SR VCC supported indication as one bit. The indication can be provided during a long term evolution attach procedure, so that the mobility management entity can decide whether to set the "voice over PS session Supported" indication based on this information and operator policy for voice call continuity. The additional indications from the newer UE (for example, SR-VCC to 3G, SR-VCC to 2G, packet switched handover to 3G, packet switched handover to 2G, and VoHSPA are supported) can be used to allow the mobility management entity to have a better visibility for setting the "voice over PS session Supported indication" initially; thus, minimizing the chance for adjustment due to eNodeB decision.

[0068] At S3a, the mobility management entity can include the "voice over PS session Supported" indication in S1 -AP: Initial Context Setup to eNodeB so that eNodeB is aware of the decision made by mobility management entity (whether it is Y/N). In this message, a single radio voice call continuity possible indication can also be given as according to 3GPP TS 23.216, which is incorporated herein in its entirety.

[0069] At S3b-S4, attach accept can be provided and the eNB can retrieve the user equipment capabilities if not received from the mobility management entity.

[0070] At S5, if the mobility management entity has indicated to eNB that PS voice is supported for this UE, then the eNB can check the radio level possibility to meet such requirement. That is, the eNB can determine whether the voice session can be continued via single radio voice call continuity and/or PS-PS handover and the underlying FDD/TDD radio topology and operator's policy.

[0071] If the mobility management entity has indicated to eNB that PS voice is not supported for this UE, then no further procedures are required on the eNodeB in connection with this process.

[0072] At S6, after the eNB evaluates its radio topology and the user equipment's radio capabilities, if it determines that the packet switched Voice cannot be supported, then the eNB sends a "PS Voice not possible" indication to the mobility management entity via Initial Context Setup Response or UE CAPABILITY INFO INDICATION INFO or new S1 AP message. If eNB decides that packet switched Voice can be supported, eNB can send a "PS Voice possible" indication explicitly to MME. Alternatively, eNB can omit the indication and MME understands that packet switched Voice can be supported. This signaling can be also the other way around. That is, if eNB can supports packet switched Voice based on user equipment's radio capabilities, topology, operator's policy and/or other information, eNB sends a "PS Voice possible" to MME. And if eNB decides that eNB cannot support packet switched Voice, it does not send anything to MME and MME implicitly understand that eNB cannot support packet switched Voice.

[0073] At S7, when the mobility management entity gets the indication from the eNB or understand the decision in the eNB implicitly, the mobility management entity can send the correct NAS level "voice over PS session Supported" indication to user equipment by either forcing the user equipment to perform reattach to long term evolution and mobility management entity sends the correct "NO" indication in the next Attach Accept message. Alternatively, a NAS procedure can permit the mobility management entity to update the user equipment directly.

[0074] For signaling only procedures, such as a periodic Tracking Area Update, the INITIAL CONTEXT SETUP REQUEST message does not need to be used. Thus, a "voice over PS session Supported" indication for a user equipment may not get corrected until the EPS bearer is invoked. For new user equipment, a NAS procedure can permit the mobility management entity to update the user equipment immediately.

[0075] The NAS signaling can be enhanced (for example, in S1 above) to include the user equipment features (for example, single radio voice call continuity to 3G, single radio voice call continuity to 2G, IMS over HSPA supported, packet switched to packet switched handover to 3G/2G). This allows the mobility management entity to have a better visibility for setting the "voice over PS session Supported indication" initially; thus, minimizing the chance for adjustment due to eNodeB decision.

[0076] If user equipment supports SR-VCC from long term evolution FDD to UMTS but not single radio voice call continuity from long term evolution TDD to UMTS, one approach can be to perform an intra long term evolution TDD to FDD handover as first step and then perform single radio voice call continuity to UMTS as second step. A similar approach can be used for the inverted case, in which the handover is in an opposite direction. This decision can be made by the eNodeB.

[0077] To handle the case when an IDLE mode user equipment is crossing radio coverage areas with different capabilities (for example, a boundary at which packet switched voice cannot be continued if handover is required) then it the user equipment can perform a tracking area update when crossing different areas. Accordingly, the TA list can be set in a way that all TA and target cell radio have the same capabilities required for voice session continuity.

[0078] To support IMS voice to HSPA with packet switched handover from long term evolution, the following indications can be provided from the mobility management entity to the eNodeB. The user equipment that supports IMS Voice over HSPA can indicate this capability to the mobility management entity via NAS. Conventionally, there is no AS level or NAS level indication. Additionally, if the network supports IMS Voice over HSPA then the mobility management entity can send an HSPA packet switched Voice supported indication=TRUE to eNodeB in Initial UE Context Setup message, same as S3a in Figure 6. Moreover, the eNB can use this indication to determine whether a target HSPA cell can be used as evaluation for packet switched voice continuation as in S5 of Figure 6. [0079] Figure 7 illustrates a method according to certain embodiments. The method of Figure 7 can be performed by a user equipment, eNodeB, and mobility management entity, either individually or working in cooperation.

[0080] As shown in Figure 7, at 710, the method can include determining whether a user equipment can support voice over packet switched (for example, whether the user equipment can be provided with VoIP over LTE), based on information about the user equipment and the network. The determining can include evaluating user equipment capabilities at 712, evaluating user equipment radio capabilities at 714, and/or evaluating radio network topology for the voice coverage at the user equipment location at 716.

[0081] The method can also include, at 720, instructing the user equipment to take a disabling action when it is determined that the user equipment cannot support voice over packet switched network as voice over packet switched continuity cannot be guaranteed. The instructing can be instructing the user equipment to perform, at 722, a new attachment or to perform, at 724, a new tracking area update. This new attachment or new tracking area update can be accompanied by setting a flag that was previously "TRUE" to "FALSE". For example, "voice over PS session Supported indication" can be set to "No" or "False".

[0082] The method can include, at 730, determining a correct setting of "IMS voice over PS session Supported indication". The method can further include taking variables regarding the user equipment and/or radio network into account when determining the correct setting on "IMS voice over PS session Supported indication". Taking the variables into account can include taking user equipment capabilities into account, taking user equipment radio capabilities into account, and taking radio network topology for the voice coverage at the user equipment location into account in addition to other information like roaming agreement and/or operator policy and the like.

[0083] Figure 8 illustrates a system according to certain embodiments. In an example embodiment, a system may include three devices, MME 810, eNodeB 820, and UE 830. Each of the devices 810, 820, and 830 may be equipped with at least one processor (respectively 814, 824, and 834), at least one memory (respectively 815, 825, and 835) including computer program instructions or code, a transceiver (respectively 816, 826, and

836), and an antenna (respectively 817, 827, and 837).

[0084] Each transceiver 816, 826, and/or 836 can be a transmitter, a receiver, both a transmitter and a receiver, or a unit that is configured both for transmission and reception. The transceiver 816, 826, and/or 836 can be coupled to one or more respective antenna(s) 817, 827, and/or 837, which may include a directional antenna, or a microwave link. There is no requirement that the MME 810, eNodeB 820, and UE 830 be equipped with an antenna. Instead, for example, the MME 810 can be configured for only wired communication over a network, such as a fiber-optic network and the eNodeB 820 can be equipped for both wired and wireless communication.

[0085] Each at least one processor 814, 824, and/or 834 can be variously embodied by any computational or data processing device, such as a central processing unit (CPU) or application specific integrated circuit (ASIC). The at least one processor 814, 824, and/or 834 can be implemented as one or a plurality of controllers.

[0086] Each at least one memory 815, 825, and/or 835 can be any suitable storage device, such as a non-transitory computer-readable medium. For example, a hard disk drive (HDD) or random access memory (RAM) can be used in the at least one memory 815, 825, and/or 835. The at least one memory 815, 825, and/or 835 can be on a same chip as the corresponding at least one processor 814, 824, and/or 834, or may be separate from the corresponding at least one processor 814, 824, and/or 834.

[0087] The computer program instructions may be any suitable form of computer program code. For example, the computer program instructions may be a compiled or interpreted computer program.

[0088] Each at least one memory 815, 825, and/or 835 and computer program instructions can be configured to, with the corresponding at least one processor 814, 824, and/or 834, cause a hardware apparatus (for example, MME 810, eNodeB 820, and/or UE 830) to perform a process, such as the processes described above.

[0089] Thus, in certain embodiments, a non-transitory computer-readable medium can be encoded with computer instructions that, when executed in hardware perform a process, such as one of the processes described herein. Alternatively, certain embodiments of the present invention may be performed entirely in hardware.

[0090] The devices of the system may also include additional components. For example, each of MME 810, eNodeB 820, and UE 830 can include a user interface that is operable connected to the corresponding processor 814, 824, and/or 834 and corresponding memory 815, 825, and/or 835. That user interface can include a display, such as a liquid crystal display (LCD) or organic electroluminescent display (OELD), as well as speakers or audio outputs. Tactile outputs, such as a haptic feedback system, can also be included. The user interface may have a touch screen to receive user input. User input can also be provided by a keypad, keyboard, microphone, joystick, mouse, trackball, or other input device. However, there is no requirement that any such additional components be provided. For example, each of MME 810 and eNodeB 820 can be implemented as a rack-mounted computer. Although the MME 810 and eNodeB 820 are shown as separate boxes, the devices may, in certain cases, be located within a same physical enclosure.

[0091] A method according to certain embodiments includes determining whether a user equipment can support voice over packet switched (more specifically, for example, whether the user equipment can be provided with VoIP over LTE), based on information about the user equipment and the network.

[0092] The method can also include instructing the user equipment to take a disabling action when it is determined that the user equipment cannot support voice over packet switched.

[0093] The instructing can be performed by a mobility management entity or an eNodeB.

[0094] The instructing can be instructing the user equipment to perform a new attachment or a new tracking area update.

[0095] The determining can include evaluating user equipment capabilities, user equipment radio capabilities, and/or radio network topology for the voice coverage at the user equipment location in addition to other information like roaming agreement and/or operator policy and etc.

[0096] The method can include determining a correct setting of "IMS voice over PS session Supported indication". The method can further include taking variables regarding the user equipment and/or radio network into account when determining the correct setting on "IMS voice over PS session Supported indication". The variables can include user equipment capabilities, user equipment radio capabilities, and radio network topology for the voice coverage at the user equipment location.

[0097] A computer readable medium, such a non-transitory computer readable medium, can in certain embodiments be encoded with instructions that, when executed in hardware, perform a process. The process can include determining whether a user equipment can support voice over packet switched (more specifically, for example, whether the user equipment can be provided with VoIP over LTE), based on information about the user equipment and the network. The process can also include instructing the user equipment to take a disabling action when it is determined that the user equipment cannot support voice over packet switched. The instructing can be performed by a mobility management entity or an eNodeB. The instructing can be instructing the user equipment to perform a new attachment or a new tracking area update. The determining can include evaluating user equipment capabilities, user equipment radio capabilities, and/or radio network topology for the voice coverage at the user equipment location.

[0098] The process can include determining a correct setting of "IMS voice over PS session Supported indication". The process can further include taking variables regarding the user equipment and/or radio network into account when determining the correct setting on "IMS voice over PS session Supported indication". The variables can include user equipment capabilities, user equipment radio capabilities, and radio network topology for the voice coverage at the user equipment location.

[0099] An apparatus (such a mobility management entity or eNodeB or component thereof) according to certain embodiments includes determining means for determining whether a user equipment can support voice over packet switched (more specifically, for example, whether the user equipment can be provided with VoIP over LTE), based on information about the user equipment and the network.

[0100] The apparatus can also include instructing means for instructing the user equipment to take a disabling action when it is determined that the user equipment cannot support voice over packet switched. The instructing means can be for instructing the user equipment to perform a new attachment or a new tracking area update.

[0101] The determining means can comprise evaluating means for evaluating user equipment capabilities, user equipment radio capabilities, and/or radio network topology for the voice coverage at the user equipment location in addition to other information like roaming agreement and/or operator policy and the like.

[0102] The apparatus can include determining means for determining a correct setting of "IMS voice over PS session Supported indication". The determining means can be configured to take variables regarding the user equipment and/or radio network into account when determining the correct setting on "IMS voice over PS session Supported indication". The variables can include user equipment capabilities, user equipment radio capabilities, and radio network topology for the voice coverage at the user equipment location.

[0103] In certain embodiments, an apparatus includes at least one processor and at least one memory including computer program code. The at least one memory and computer program code are configured to, with the at least one processor, cause the apparatus (such as a mobility management entity or eNodeB) at least to determine whether a user equipment can support voice over packet switched (more specifically, for example, whether the user equipment can be provided with VoIP over LTE), based on information about the user equipment and the network. The at least one memory and computer program code can also be configured to, with the at least one processor, cause the apparatus at least to instruct the user equipment to take a disabling action when it is determined that the user equipment cannot support voice over packet switched.

[0104] The at least one memory and computer program code can also be configured to, with the at least one processor, cause the apparatus at least to instruct the user equipment to perform a new attachment or a new tracking area update.

[0105] The at least one memory and computer program code can also be configured to, with the at least one processor, cause the apparatus at least to evaluate user equipment capabilities, user equipment radio capabilities, and/or radio network topology for the voice coverage at the user equipment location.

[0106] The at least one memory and computer program code can also be configured to, with the at least one processor, cause the apparatus at least to determine a correct setting of "IMS voice over PS session Supported indication". The at least one memory and computer program code can further be configured to, with the at least one processor, cause the apparatus at least to take variables regarding the user equipment and/or radio network into account when determining the correct setting on "IMS voice over PS session Supported indication". The variables can include user equipment capabilities, user equipment radio capabilities, and radio network topology for the voice coverage at the user equipment location.

[0107] One having ordinary skill in the art will readily understand that the invention as discussed above may be practiced with steps in a different order, and/or with hardware elements in configurations which are different than those which are disclosed. Therefore, although the invention has been described based upon these preferred embodiments, it would be apparent to those of skill in the art that certain modifications, variations, and alternative constructions would be apparent, while remaining within the spirit and scope of the invention.