WO2017026978A1 - Offload of volte call to wifi in a network supporting srvcc - Google Patents

Abstract

Techniques related to offloading of a VoLTE (Voice over LTE) call to WiFi (Wireless Fidelity) in a network supporting also SRVCC (Single Radio Voice Call Continuity) are described. Briefly, in accordance with one embodiment, an apparatus of a User Equipment (UE) includes circuitry to receive a Single Radio Voice Call Continuity (SRVCC) capability indication from an evolved Node B (eNB). Other embodiments are also disclosed and claimed.

Description

OFFLOAD OF VOLTE CALL TO WIFI ΓΝ A NETWORK SUPPORTING SRVCC

CROSS-REFERENCE TO RELATED APPLICATIONS The present application claims priority and the benefit of U.S. Provisional Application No.

62/204,891 , entitled "OFFLOADING OF A VOLTE CALL TO WIFI," filed August 13, 2015 (Docket No. P87993Z) and US. Provisional Application No. 62/205,268, entitled "PREVENTION OF SRVCC HANDOVER FOR A VOLTE CALL OFFLOADED TO WIFI," filed August 14, 2015 (Docket No. P87995Z), which are hereby incorporated herein by reference for all purposes and in their entirety.

BACKGROUND

When the quality of a voice call over a cellular network degrades, the voice call may be transferred to a Wireless Local Area Network (WLAN) or WiFi (Wireless Fidelity) connection, assuming a WLAN or WiFi connection is available. This call transfer however may take too long and the voice call may be dropped before the transfer can take place, depending on the available features of the cellular network or WLAN/WiFi connection.

BRIEF DESCRIPTION OF THE DRAWINGS

The detailed description is provided with reference to the accompanying figures. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The use of the same reference numbers in different figures indicates similar or identical items.

FIG. 1 shows an exemplary block diagram of the overall architecture of a 3GPP LTE network that includes one or more devices that are capable of implementing techniques for offloading of a VoLTE call to WLAN, or alternatively for handover of the VoLTE call to a circuit-switched (CS) call via GERAN or UTRAN based on SRVCC support, according to the subject matter disclosed herein.

FIG. 2 illustrate a flow diagram to provide offloading of a VoLTE call to WiFi in a network supporting also SRVCC, according to an embodiment.

FIG. 3 is a schematic, block diagram illustration of an information-handling system in accordance with one or more exemplary embodiments disclosed herein. FIG. 4 is an isometric view of an exemplary embodiment of the information-handling system of FIG. 3 that optionally may include a touch screen in accordance with one or more embodiments disclosed herein.

FIG. 5 is a schematic, block diagram illustration of components of a wireless device in accordance with one or more exemplary embodiments disclosed herein.

It will be appreciated that for simplicity and/or clarity of illustration, elements illustrated in the figures have not necessarily been drawn to scale. For example, the dimensions of some of the elements may be exaggerated relative to other elements for clarity. Further, if considered appropriate, reference numerals have been repeated among the figures to indicate corresponding and/or analogous elements.

DETAILED DESCRIPTION

In the following description, numerous specific details are set forth in order to provide a thorough understanding of various embodiments. However, various embodiments may be practiced without the specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to obscure the particular embodiments. Further, various aspects of embodiments may be performed using various means, such as integrated semiconductor circuits ("hardware"), computer-readable instructions organized into one or more programs ("software"), or some combination of hardware and software. For the purposes of this disclosure reference to "logic" shall mean either hardware, software, firmware, or some combination thereof.

As mentioned above in the background section, a voice call transfer may take too long and the call may be dropped before the transfer can take place, depending on the available features of the cellular network or WLANAViFi connection (wherein WLAN and WiFi may be used interchangeably herein). With the support of a cellular PDN (Packet Data Network) connection offload to WiFi, an IMS (Internet Protocol Multimedia Subsystem) call running over a cellular connection can be continued transparently over WiFi (e.g., where the same P (Internet Protocol) address is maintained). Some operators give preference to LTE (Long Term Evolution) or cellular connections in general. Wifi is used when the LTE or cellular coverage degrades or is lost.

An alternative way to continue the voice call when LTE coverage degrades is provided by SRVCC (Single Radio Voice Call Continuity). If an IMS call is ongoing and the LTE quality degrades, a network supporting SRVCC will trigger SRVCC handover and the IMS call will be transferred over a CS (Circuit Switched) network. One problem with this approach is that currently the UE (User Equipment) does not know whether the network is supporting SRVCC. If the network does not support SRVCC, but operator preference is to use a cellular network for voice services (instead of offloading the IMS call to WiFi), the UE may wait too long and drop the call due to loss of LTE coverage, as the offload of the IMS call to WiFi may be triggered too late.

To this end, some embodiments provide offloading of a VoLTE (Voice over LTE) call to

WiFi in a network supporting also SRVCC. More particularly, an embodiment introduces a new SRVCC capability indicator for the network to inform the UE of the SRVCC support. Based on this indication, the UE may then trigger the offload of an IMS call to WiFi earlier, e.g., before the risk of loss of LTE coverage has become too great. A similar capability (called vSRVCC or video SRVCC capability) can also be introduced for IMS video calls in one embodiment. vSRVCC is a separate feature in 3GPP (Third Generation Partnership Project), and a network supporting SRVCC does not necessarily support vSRVCC.

Moreover, if the network notifies the UE that SRVCC (or vSRVCC) is not supported or if the network does not provide any support notification, the UE can offload the IMS PDN connection to WiFi before the loss of LTE coverage even if operator policy is cellular preferred for voice or video service. The IMS call can then be continued over WiFi. This embodiment further reduces the risk of call drops.

Other embodiments provide techniques to prevent SRVCC handover for a VoLTE call offloaded to WiFi/WLAN as will be further discussed below. Hence, the UE may maintain the IMS call over WiFi and prevent the handover of the IMS call over CS. An IMS call over WiFi generally allows for a better user experience (e.g., providing video support, super wideband codec (coder-decoder), etc.) compared to CS voice support.

FIG. 1 shows an exemplary block diagram of the overall architecture of a 3GPP LTE network

100 that includes one or more devices that are capable of implementing techniques for offloading of a VoLTE call to WLAN, or alternatively to handover the VoLTE call to a circuit-switched (CS) call via GERAN or UTRAN based on SRVCC support, according to the subject matter disclosed herein. FIG. 1 also generally shows exemplary network elements and exemplary standardized interfaces. At a high level, network 100 comprises a Core Network (CN) 101 (also referred to as an Evolved Packet System (EPC)), and an air-interface access network E-UTRAN (Evolved Universal Terrestrial Radio Access Network) 102. CN 101 is responsible for the overall control of the various User Equipment (UE) coupled to the network and establishment of the bearers. G

101 may include functional entities, such as a home agent and/or an ANDSF (Access Network Discovery and Selection Function ) server. or entity, although not explicitly depicted. E-UTRAN

102 is responsible for all radio-related functions. Exemplary logical nodes of CN 101 include, but are not limited to, a Serving GPRS Supp Vt Node (SGSN) 103, Mobility Management Entity (MME) 104, a Home Subscriber Server (HSS) 105, a Serving Gateway (SGW) 106, a PDN Gateway (or PDN GW) 107, a Policy and Charging Rules Function (PCRF) Manager logic 108, and a Mobile Switching Centre (MSC) Server 1 15 (which may be part of the CS network and capable of controlling the CS call after the SRVCC handover). The functionality of each of the network elements of CN 101 is generally in accordance with various standards and is not described herein for simplicity. Each of the network elements of CN 101 are interconnected by exemplary standardized interfaces, some of which are indicated in FIG. 1 , such as interfaces S3, S4, S5, etc.

While CN 101 includes many logical nodes, the E-UTRAN access network 102 is formed by at least one node, such as evolved NodeB (Base Station (BS), eNB or eNodeB) 1 10, which couples to one or more UE 1 1 1 , of which only one is depicted in Fig 1 for the sake of simplicity. UE 1 1 1 is also referred to herein as a Wireless Device (WD) and/or a Subscriber Station (SS), and may include an M2M (Machine to Machine) type device. In one example, UE 1 1 1 may be coupled to eNB by an LTE-Uu interface. In one exemplary configuration, a single cell of an E-UTRAN access network 102 provides one substantially localized geographical transmission point (e.g., having multiple antenna devices) that provides access to one or more UEs. In another exemplary configuration, a single cell of an E-UTRAN access network 102 provides multiple geographically substantially isolated transmission points (each having one or more antenna devices) with each transmission point providing access to one or more UEs simultaneously and with the signaling bits defined for the one cell so that all UEs share the same spatial signaling dimensioning.

For normal user traffic (as opposed to broadcast), there is no centralized controller in E- UTRAN; hence the E-UTRAN architecture is said to be flat. The eNBs can be interconnected with each other by an interface known as "X2" and to the EPC by an S I interface. More specifically, an eNB is coupled to MME 104 by an SI MME interface and to SGW 106 by an SI U interface. The protocols that run between the eNBs and the UEs are generally referred to as the "AS protocols." Details of the various interfaces can be in accordance with available standards and are not described herein for the sake of simplicity.

The eNB 1 10 hosts the PHYsical (PHY), Medium Access Control (MAC), Radio Link Control (RLC), and Packet Data Control Protocol (PDCP) layers, which are not shown in FIG. I , and which include the functionality of user-plane header-compression and encryption. The eNB 1 10 also provides Radio Resource Control (RRC) functionality corresponding to the control plane, and performs many functions including radio resource management, admission control, scheduling, enforcement of negotiated Up Link (UL) QoS (Quality of Service), cell information broadcast, ciphering/deciphering of user and control plane data, and compression/decompression of DL UL (Downlink/Uplink) user plane packet headers.

The RRC layer in eNB 1 10 covers all functions related to the radio bearers, such as radio bearer control, radio admission control, radio mobility control, scheduling and dynamic allocation of resources to UEs in both uplink and downlink, header compression for efficient use of the radio interface, security of all data sent over the radio interface, and connectivity to the EPC. The RRC layer makes handover decisions based on neighbor cell measurements sent by UE 1 1 1 , generates pages for UEs 1 1 1 over the air, broadcasts system information, controls UE measurement reporting, such as the periodicity of Channel Quality Information (CQ1) reports, and allocates cell- level temporary identifiers to active UEs 1 1 1. The RRC layer also executes transfer of UE context from a source eNB to a target eNB during handover, and provides integrity protection for RRC messages. Additionally, the RRC layer is responsible for the setting up and maintenance of radio bearers. Lastly, as illustrated in FIG. 1 , UE 1 1 1 may offload a VoLTE call to WLAN 150. Alternatively, the network may initiate the SRVCC handover of the UE to the GERAN or UTRAN. Various types of WLAN may be supported such as any of those discussed herein. Also, the WLAN 150 may be an untrusted 3GPP access (e.g., as described in 3GPP standard) and embodiments discuss herein are limited to handover to WLAN and may be applicable to UE handover to another technology.

Also as shown in FIG. 1 , a trusted 3GPP access logic 160 is coupled to PCRF 108 and PDN GW 107. An ePDG (Evolved Packet Data Gateway) 162 is coupled to the WLAN 150, PDN G W 107, 3GPP AAA server 164, and PCRF 108. 3GPP AAA (Authentication, Authorization, and Account) server 164 is also coupled to the WLAN 150. The features mentioned in this paragraph may be partially based on 3GPP TS 24.302, Figure 4.2.2-1 : Non-Roaming Architecture within EPS using S5, S2a, S2b.

FIG. 2 illustrates a flow diagram to provide offloading of a VoLTE call to WiFi in a network supporting also SRVCC, according to an embodiment. In an embodiment, FIG. 2 shows a modified version of the figure 6.2.2.2- 1 of 3GPP TS (Technical Specification) 23.216 VI 3.0.0 (2015-06) to provide offloading of a VoLTE call to WiFi in a network supporting also SRVCC, according to one embodiment. The cancellation of the SRVCC handover shown in the second part of Fig. 2-js based on a modified version of figure 8.1 .3-1 of 3GPP TS 23.216. Also, one or more of the operations discussed with reference to FIG. 2 may be performed by components discussed herein with reference to the other figures, e.g., having the same labels.

Referring to FIG. 2, at each labeled stage, the following operations are performed in accordance with the above-mentioned standard. Further details regarding the operations may be determined by reference to the above-identified TS. 1. UE sends measurement reports to E-UTRAN.

2. Based on UE measurement reports the source EUTRAN decides to trigger an SRVCC handover to UTRAN or GERAN (GSM/EDGE Radio Access Network).

3. If target is UTRAN, the source E-UTRAN sends a Handover Required (Target ID, generic Source to Target Transparent Container, SRVCC HO (Handover) indication) message to the source MME. SRVCC HO indication indicates to MME that this is for CS+PS HO.

4. Based on the QCI (QoS Class Identifier) associated with the voice bearer (QCI 1 ) and the SRVCC HO Indication, the source MME splits the voice bearer from all other PS bearers and initiates their relocation towards MSC (Mobile Switching Center) Server and SGSN, respectively.

5a) Source MME initiates the PS-CS handover procedure for the voice bearer by sending a SRVCC PS to CS Request (IMSI, Target ID, STN-SR, C MSISDN, Source to Target Transparent Container, MM (Mobility Management) Context, Emergency Indication) message to the MSC Server. If SRVCC with priority is supported, the MME also includes priority indication in SRVCC PS to CS Request if it detects the SRVCC requires priority handling. The detection is based on the ARP (Allocation and Retention Priority) associated with the EPS bearer used for IMS signaling. The priority indication corresponds to the ARP information element. The Emergency Indication and the equipment identifier are included if the ongoing session is emergency session. Authenticated IMSI and C MSISDN shall also be included if available. The message includes information relevant to the CS domain only. MME received STN-SR and C MSISDN from the HSS as part of the subscription profile downloaded during the E-UTRAN attach procedure. MM Context contains security related information. CS security key is derived by the MME from the E- UTRAN/EPS domain key as defined in TS 33.401 [22]. The CS Security key is sent in the MM Context.

5b) MSC Server interworks the PS-CS handover request with a CS inter MSC handover request by sending a Prepare Handover Request message to the target MSC. If SRVCC with priority is supported and the MSC Server receives the priority indication (i.e. ARP) in the SRVCC PS to CS Request, the MSC server MGW sends Prepare Handover Request message to the Target MSC with priority indication mapped from the ARP. The MSC Server maps the ARP to the priority level, pre-emption capability/vulnerability for CS services based on local regulation or operator settings. The priority indication indicates the CS call priority during handover as specified in TS 25.413 [1 1 ] for UMTS and TS 48.008 [23] for GSM/EDGE. If the target system is GERAN, thp MSC Server assigns a default SAI as Source ID on the interface to the target BSS and uses BSSMAP encapsulated for the Prepare Handover Request. If the target system is UTRAN, the MSC Server uses RANAP encapsulated for the Prepare Handover Request. 5c) Target MSC requests resource allocation for the CS relocation by sending the Relocation Request/Handover Request message to the target RNS/BSS. If the MSC Server indicated priority, the RNC BSS allocates the radio resource based on the existing procedures with priority indication, as specified in TS 23.009 [ 1 8] and in TS 25.41 3 [ 1 1 ] for UMTS and TS 48.008 [23] for GSM/EDGE. If the target RAT is UTRAN, Relocation Request/Handover Request message contains the generic Source to Target Transparent Container. If the target RAT is GERAN, Relocation Request/Handover Request message contains the additional Source to Target Transparent Container.

6. In parallel to the previous step the source MME initiates relocation of the PS bearers. The following steps are performed (for details see TS 23.401 [2] clauses 5.5.2.1 and 5.5.2.3):

a) Source MME sends a Forward Relocation Request (generic Source to Target Transparent Container, MM Context, PDN Connections IE) message to the target SGSN. If the target SGSN uses S4 based interaction with S-GW and P-GW, the PDN Connections IE includes bearer information for all bearers except the voice bearer. The handling of security keys for PS handover of the remaining non-voice PS bearers is specified in TS 33.401 [22].

b) Target SGSN requests resource allocation for the PS relocation by sending the Relocation Request/Handover Request (Source to Target Transparent Container) message to the target RNS/BSS.

7. After the target RNS/BSS receives both the CS relocation/handover request with the PS relocation/handover request, it assigns the appropriate CS and PS resources. The following steps are performed:

a) Target RNS BSS acknowledges the prepared PS relocation/handover by sending the Relocation Request Acknowledge/Handover Request Acknowledge (Target to Source Transparent Container) message to the target SGSN.

b) Target SGSN sends a Forward Relocation Response (Target to Source Transparent Container) message to the source MME.

8. In parallel to the previous step the following steps are performed:

a) Target RNS/BSS acknowledges the prepared CS relocation/handover by sending the Relocation Request Acknowledge/Handover Request Acknowledge (Target to Source

Transparent Container) message to the target MSC.

b) Target MSC sends a Prepare Handover Response (Target to Source Transparent Container) message to the MSC Server.

c) Establishment of circuit connection between the target MSC and the MGW associated with the MSC Server e.g. using ISUP IAM and ACM messages. 9. For non-emergency session, the MSC Server initiates the Session Transfer by using the STN-SR e.g. by sending an ISUP I AM (STN-SR) message towards the IMS. If this is a priority session, the MSC Server sends the SIP Session Transfer message with the priority indication to the IMS and the IMS entity handles the session transfer procedure with priority. The priority indication in the SIP Session Transfer message is mapped by the MSC Server from the priority indication (i.e. ARP) in the SRVCC PS to CS Request received in step 5. The mapping of the priority level is based on operator policy and/or local configuration, and the IMS priority indicator should be the same as for the original IMS created over PS. For emergency session, the MSC Server initiates the Session Transfer by using the locally configured E-STN-SR and by including the equipment identifier. IMS Service Continuity or Emergency IMS Service Continuity procedures are applied for execution of the Session Transfer, TS 23.237 [14].

10. During the execution of the Session Transfer procedure the remote end is updated with the SDP of the CS access leg according to TS 23.237 [14]. The downlink flow of VoIP packets is switched towards the CS access leg at this point.

1 1. The source IMS access leg is released according to TS 23.237 [14].

12. The MSC Server sends a SRVCC PS to CS Response (Target to Source Transparent Container) message to the source MME.

13. Source MME synchronizes the two prepared relocations and sends a Handover Command (Target to Source Transparent Container) message to the source E-UTRAN.

14. E-UTRAN sends a Handover from E-UTRAN Command message to the UE.

16. Upon receipt of the RRC Connection Re-establishment Request from the UE, the E-UTRAN decides to cancel the SRVCC handover procedure by sending a Cancel message to the MME.

17. The Source SGSN MME indicates SRVCC PS to CS Cancel Notification to MSC Server.

18. The MSC Server starts the handover cancellation procedure according to TS 23.009.

19. The MSC Server acknowledges the PS to CS Cancel Notification.

20. The source MME confirms the Cancel message provided in step 16.

As shown in FIG. 2 and in accordance with some embodiments, the operations associated with the offloading and handover from LTE to WLAN is performed within (or while a UE is coupled to) the cellular/LTE network. For example, referring to FIG. 2, at xO (e.g., performed at any time while coupled to a cellular LTE network), a decision is made by UE for session transfer to WLAN, as further discussed herein. At x 1 (e.g., any time after xO and before 14), session transfer to WLAN is initiated. At x2 (e.g., after 14), RRC connection re-establishment request is sent (i.e., when MMTEL (Multimedia Telephony) voice/video call over cellular is unavailable, or the new cause may be added in the RRCConnectionReestablishment to indicate to the eNB is it not a normal handover failure but rather a handover rejection due to the call session now being established over WiFi). Moreover, in an embodiment, the RRC Connection re-establishment is triggered as a result of step 14 handover command. The UE will intentionally fail the handover procedure and trigger RRC Connection re-establishment according to 3GPP 36.331. This process may be referred to with different names such as "handover reject," etc. or an RRC Connection Reconfiguration reject message may be introduced. At x3 (e.g., after 9), a request to re-invite to maintain IMS session via WLAN is sent (which may also be used by IMS core network to notify the target MSC that the call session to the MSC is cancelled). Further, as shown in FIG. 2, performance of operation 15 (and any subsequent operations following a successful SRVCC handover) is not necessary and can be skipped if handover to WLAN occurs. However, the resources for this operations may be still maintained in an embodiment for situations when the handover fails. Operations of FIG. 2 not specifically discussed herein may be performed in accordance with the above-identified TS.

In an embodiment, the MME can notify the UE of SRVCC (or vSRVCC) support by extending, for instance, the EPS (Evolved Packet System) network feature support information element (defined under section 9.9.3.12A in 3GPP TS 24.301 VI 3.3.0 (2015-09)) with one additional bit for SRVCC support indicator. As an alternative (or in addition), the SRVCC capability may be provided to UE by introducing a new SRVCC capability indicator in the contact header in the 200O in response to the SIP (Session Initiation Protocol) REGISTER or SIP INVITE initiated by the UE. As another alternative, the SRVCC (or vSRVCC) capability can be signaled in the system information broadcast. In yet another embodiment, the SRVCC (or vSRVCC) may be provided by a Serving-Call Session Control Function (S-CSCF) (according to 3GPP TS 23.228 V I 3.2.0 (201 5-03). If the network does not support SRVCC (vSRVCC) and an IMS call is ongoing, the UE can trigger the IMS PDN offload to WiFi before loss of LTE coverage.

Furthermore, in an embodiment, both the use of the SRVCC indicator (or its absence) by the UE to decide to initiate offload to WLAN and the use of the new reject cause will result in a cancellation of the SRVCC handover. There may also another use case for the SRVCC indicator, where the UE, based on the presence of the indicator decides to not initiate offload to WLAN and rather wait for the network to send an SRVCC handover command. But, in the latter case, the UE would also not perform steps xO ... x3 discussed below, which changes the message flow of FIG. 2 such that the flow would be the same as for a normal SRVCC handover defined under the TS mentioned above, and the one difference would be that at a box xO, based on receipt of the SRVCC indicator, UE decides to not initiate offload to WLAN, but wait for an SRVCC handover command.

If some inter-RAT (inter Radio Access Technology) measurement reports have been configured by the eNB, the UE can trigger the offload of the IMS PDN to WiFi before inter-RAT measurement criteria are met. Otherwise a network not supporting SRVCC may trigger a PS (Packet Switched) handover to another cellular radio access technology not supporting the IMS voice or video call, leading to the drop of the IMS call.

In the UE, the LTE signal quality threshold to trigger IMS PDN offload may then depend on SRVCC capability and operator preference for voice or video services. For example, if voice or video services are preferred over cellular network:

(a) If SRVCC is supported, the signal quality threshold used (provisioned in the UE or configured by the network) for IMS PDN offload can be lower than the threshold used to send the measurement report that triggers SRVCC. Otherwise, the IMS PDN connection and consequently the voice call can be transferred over WiFi before SRVCC is triggered even if the operator or user preference is to have the voice call on cellular. This could be extended to cases where even SRVCC is supported. For instance it can be preferable for a user to perform service offload to WiFi before SRVCC is triggered, so in case of such preference, as a general rule, the threshold to offload to WiFi may be higher than t fc threshold for interRAT handover. This allows a user to keep the call on IMS when LTE coverage is left

(b) If SRVCC is not supported, the signal quality threshold configured for IMS PDN offload can be higher than any of the threshold values configured for inter-RAT mobility, even if the operator/user preference is cellular. Otherwise the voice/video will be dropped if inter-RAT mobility procedure is triggered and IMS voice/video service is not supported in the target RAT. Note, IMS voice/video is not supported over GSM/GPRS. IMS voice could be supported over HSPA (High Speed Packet Access) but VoHSPA (Voice over

HSPA) is currently not deployed.

As mentioned above some embodiments provide techniques for preventing SRVCC handover for a VoLTE call offloaded to WiFi/WLAN. Hence, the UE may maintain the IMS call over WiFi and prevent the handover of the IMS call to CS network. An IMS call over

WiFi generally allows a better user experience (e.g., providing video support, super wideband codec, etc.) compared to a CS voice call.

With the support of a cellular PDN connection offload to WiFi, an IMS call running over a cellular connection can be continued transparently over WiFi (e.g., where the same IP address is maintained). Some operators give preference to LTE compared to WiFi and a preference to WiFi compared to 2G/3G. Wifi is used when the LTE coverage degrades or is lost. If an IMS call is ongoing and the LTE quality degrades, the UE triggers the IMS PDN offload to WiFi (e.g., using an S2b interface) and the IMS can continue over WiFi.

When the LTE quality degrades, a network supporting SRVCC will trigger a SRVCC handover procedure. The SRVCC procedure can happen in parallel or even after the IMS PDN offload to WiFi. The consequence is that the IMS call will be handed over to 2G/3G CS network despite operator preference to maintain the call over WiFi.

To this end, in one embodiment, once the IMS PDN offload over Wifi is successful.]}/ executed, the UE rejects any SRVCC handover command received from the network and maintains the IMS call over WiFi. For this purpose, the following enhancements are made:

(a) IMS client to notify the cellular protocol stack whether or not a MMTEL voice or video service is ongoing over cellular;

(b) Cellular protocol stack to determine to fail the mobilityFromEUTRA procedure when an SRVCC handover command is received (and there is no IMS call on the cellular network);

(c) Cellular protocol stack to indicate a new re-establishment cause in the RRC connection reestablishment procedure to avoid eNB attempting SRVCC handover again ;

(d) Cellular protocol stack to inform the IMS client about the failed SRVCC handover attempt; and/or

(e) IMS client to initiate a SIP re-INVITE procedure towards the network to maintain the call over WiFi.

Compared to some implementations, various embodiments provide one or more of:

1 ) The UE can maintain the IMS call over WiFi and prevent the handover of the IMS call over CS. An IMS call over WiFi allows better user experience (e.g., including video support, super wideband codec, etc.) compared to CS voice.

2) If the UE fails the mobilityFromEUTRA procedure without including a new, specific re-establishment cause in the RRC Connection Reestablishment Request message (e.g., at x2), there is a risk that the eNB immediately starts the network internal signaling for a new SRVCC handover preparation. This can create an unnecessary signaling load within the network. Furthermore, the new re-establishment cause helps operators and network vendors to distinguish between a SRVCC handover failure due to the present scenario and failure due to other reasoiu. Thus, these events can be counted separately, and problems in the SRVCC handover procedure can be detected more easily.

In an embodiment, once the IMS PDN connection has successfully been offloaded to WiFi and the IMS call is running over WiFi, the IMS client can notify the cellular protocol stack that the IMS call is not running over cellular anymore. For this purpose, the interface introduced for the Release feature 12 Smart Congestion Mitigation can be reused (see AT command +CSCM in 3GPP, TS 27.007, section 7.37, Session start and stop for smart congestion mitigation).

The following alternatives are possible: (a) The interface is updated to notify the domain (cellular or WiFi) on which MMTEL Voice call or MMTEL video call is running. In case of offload to WiFi, IMS client will then notify the domain about update from cellular to WiFi; (b) The interface is reused and the IMS client notifies the cellular protocol stack that the MMTEL Voice call or MMTEL video call is stopped once the call has been successfully handed over to WiFi.

The interface introduced in the 3GPP specifications for smart congestion mitigation feature is currently applicable for Mobile Originated cases only. For one embodiment, this interface ("AT + CSCM") can be extended for Mobile Terminated (MT) call as well. The IMS client can notify the cellular protocol stack when an MT MMTEL Voice call or an MT MMTEL video call is started and ended.

If the UE receives a mobilityFromEUTRACommand from the eNB and this command is for

SRVCC, and there is no MO or MT MMTEL Voice or MMTEL video call over cellular (as indicated by the IMS client via AT command +CSCM), then the cellular protocol stack can determine that the mobility from EUTRA procedure fails and initiate an RRC Connection reestablishment procedure.

In accordance with an embodiment, in the RRC Connection reestablishment request, the UE can provide a new reestablishment cause (instead of the existing reestablishment cause "handover failure") to indicate (e.g., via one or more bits) that SRVCC failure is "due to the absence of an MMTEL voice or video call over cellular" (alternatively: "due to the MMTEL voice or video service is over the WLAN link"). This cause can be used by the eNB to prevent any further SRVCC attempts. Also, after the successful offload of the IMS call to WiFi, the network will internally release the bearer for the media of the IMS call. But as this can take some time, the eNB needs to be prevented from starting a new SRVCC handover preparation as long as the DRB for IMS voice or video is not released. The new reestablishment cause can also be used by the eNB to trigger a PS handover if PS bearers have to be moved to 2G/3G, and to distinguish this scenario from other SRVCC handover failure events for traffic measurement and statistics purposes.

In one or more embodiments, the cellular protocol stack can notify the IMS client that a SRVCC procedure has been attempted and failed. The IMS client can then initiate re-INVITE procedure to maintain the call over IMS over WiFi (re-use of an existing procedure which is generally used in case of SRVCC failure). The core network may indeed have already initiated the transfer of the IMS call session to the MSC server. In one embodiment, for this purpose of notifying the IMS client, an existing interface can be re-used or enhanced, e.g., per unsolicited result code +CIREPH in TS 27.007, section 8.64, IS network reporting +CIREP. In another embodiment, it is also possible to re-use an existing codepoint of the <srvcch> parameter "2 PS to CS SRVCC or PS to CS vSRVCC handover cancelled" ("Handover Failure" sent), or to define a new codepoint.

In yet another embodiment, if the MMTEL voice or video call is ongoing over WiFi and a SRVCC is triggered, another alternative is to process the handover command at access stratum level without call session transfer from IMS client to cellular protocol stack NAS (Non Access Stratum). The network may then trigger the CS connection release as there is no CS data being exchanged between the UE and the network. In this case, when the IMS client is informed about the successful completion of the SRVCC handover, the IMS client will respond that no session is to be transferred to the cellular protocol stack NAS. The IMS client can then initiate a SIP re- INVITE procedure to maintain the call over IMS over WiFi.

It is also possible to use the SRVCC procedure to speed up the CSFB (Circuit Switched Fallback) procedure. In case SRVCC procedure is triggered due to CSFB and there an IMS call session which has been offloaded to WiFi, then the same procedure as described in the variant above can be performed. The SRVCC is performed to speed up CSFB procedure but no IMS call session is transferred to CS.

Referring now to FIG. 3, a block diagram of an information handling system capable of user equipment controlled mobility in an evolved radio access network in accordance with one or more embodiments will be discussed. Information handling system 300 of FIG. 3 may tangibly embody any one or more of the network elements described herein, above, including for example the elements of network 100 with greater or fewer components depending on the hardware specifications of the particular device. In one embodiment, information handling system 300 may tangibly embody a user equipment (UE) comprising circuitry to enter into an evolved universal mobile telecommunications system (UMTS) terrestrial radio access (E-UTRAN) Routing Area Paging Channel (ERA_PCH) state, wherein the UE is configured with an E-UTRAN Routing Area (ERA) comprising a collection of cell identifiers, and an Anchor identifier (Anchor ID) to identify an anchor evolved Node B (eNB) for the UE, select to a new cell without performing a handover procedure, and perform a cell update procedure in response to the UE selecting to the new cell, although the scope of the claimed subject matter is not limited in this respect. In another embodiment, information handling system 300 may tangibly embody a user equipment (UE) comprising circuitry to enter into a Cell Update Connected (CU CNCTD) state, wherein the UE is configured with an Anchor identifier (Anchor ID) to identify an anchor evolved Node B (eNB) for the UE, select to a new cell, perform a cell update procedure in response to the UE selecting to the new cell, perform a buffer request procedure in response to the UE selecting to the new cell, and perform a cell update procedure to download buffered data and to perform data transmission with the new cell, although the scope of the claimed subject matter is not limited in this respect. Although information handling system 300 represents one example of several types of computing platforms, information handling system 300 may include more or fewer elements and/or different arrangements of elements than shown in FIG. 3, and the scope of the claimed subject matter is not limited in these respects.

In one or more embodiments, information handling system 300 may include an application processor 310 and a baseband processor 312. Application processor 310 may be utilized as a general-purpose processor to run applications and the various subsystems for information handling system 300. Application processor 310 may include a single core or alternatively may include multiple processing cores. One or more of the cores may comprise a digital signal processor or digital signal processing (DSP) core. Furthermore, application processor 310 may include a graphics processor or coprocessor disposed on the same chip, or alternatively a graphics processor coupled to application processor 310 may comprise a separate, discrete graphics chip. Application processor 310 may include on board memory such as cache memory, and further may be coupled to external memory devices such as synchronous dynamic random access memory (SDRAM) 314 for storing and/or executing applications during operation, and NAND flash 316 for storing applications and/or data even when information handling system 300 is powered off. In one or more embodiments, instructions to operate or configure the information handling system 300 and/or any of its components or subsystems to operate in a manner as described herein may be stored on an article of manufacture comprising a non-transitory storage medium. In one or more embodiments, the storage medium may comprise any of the memory devices shown in and described herein, although the scope of the claimed subject matter is not limited in this respect. Baseband processor 312 may control the broadband radio functions for information handling system 300. Baseband processor 312 may store code for controlling such broadband radio functions in a NOR flash 318. Baseband processor 312 controls a wireless wide area network (WW AN) transceiver 320 which is used for modulating and/or demodulating broadband network signals, for example for communicating via a 3GPP LTE or LTE-Advanced network or the like.

In general, WWAN transceiver 320 may operate according to any one or more of the following radio communication technologies and/or standards including but not limited to: a Global System for Mobile Communications (GSM) radio communication technology, a General Packet Radio Service (GPRS) radio communication technology, an Enhanced Data Rates for GSM Evolution (EDGE) radio communication technology, and/or a Third Generation Partnership Project (3GPP) radio communication technology, for example Universal Mobile Telecommunications System (UMTS), Freedom of Multimedia Access (FOMA), 3GPP Long Term Evolution (LTE), 3GPP Long Term Evolution Advanced (LTE Advanced), Code division multiple access 2000 (CDMA2000), Cellular Digital Packet Data (CDPD), Mobitex, Third Generation (3G), Circuit Switched Data (CSD), High-Speed Circuit-Switched Data (HSCSD), Universal Mobile Telecommunications System (Third Generation) (UMTS (3G)), Wideband Code Division Multiple Access (Universal Mobile Telecommunications System) (W-CDMA (UMTS)), High Speed Packet Access (HSPA), High-Speed Downlink Packet Access (HSDPA), High-Speed Uplink Packet Access (HSUPA), High Speed Packet Access Plus (HSPA+), Universal Mobile Telecommunications System-Time-Division Duplex (UMTS-TDD), Time Division-Code Division Multiple Access (TD-CDMA), Time Division-Synchronous Code Division Multiple Access (TD-CDMA), 3rd Generation Partnership Project Release 8 (Pre-4th Generation) (3GPP Rel. 8 (Pre-4G)), 3GPP Rel. 9 (3rd Generation Partnership Project Release 9), 3 GPP Rel. 10 (3rd Generation Partnership Project Release 10) , 3GPP Rel. 1 1 (3rd Generation Partnership Project Release 1 1 ), 3 GPP Rel. 12 (3rd Generation Partnership Project Release 12), 3GPP Rel. 13 (3rd Generation Partnership Project Release 12), 3GPP Rel. 14 (3rd Generation Partnership Project Release 12), 3 GPP LTE Extra, LTE Licensed-Assisted Access (LAA), UMTS Terrestrial Radio Access (UTRA), Evolved UMTS Terrestrial Radio Access (E-UTRA), Long Term Evolution Advanced (4th Generation) (LTE Advanced (4G)), cdmaOne (2G), Code division multiple access 2000 (Third generation) (CDMA2000 (3G)), Evolution-Data Optimized or Evolution-Data Only (EV-DO), Advanced Mobile Phone System (1 st Generation) (AMPS (1 G)), Total Access Communication System/Extended Total Access Communication System (TACS ETACS), Digital AMPS (2nd Generation) (D-AMPS (2G)), Push-to-talk (PTT), Mobile Telephone System (MTS), Improved Mobile Telephone System (IMTS), Advanced Mobile Telephone System (AMTS), OLT (Norwegian for Offentlig Landmobil Telefoni, Public Land Mobile Telephony), MTD (Swedish abbreviation for Mobiltelefonisystem D, or Mobile telephony system D), Public Automated Land Mobile (Autotel/PALM), ARP (Finnish for Autoradiopuhelin, "car radio phone"), NMT (Nordic Mobile Telephony), High capacity version of NTT (Nippon Telegraph and Telephone) (Hicap), Cellular Digital Packet Data (CDPD), Mobitex, DataTAC, Integrated Digital Enhanced Network (iDEN), Personal Digital Cellular (PDC), Circuit Switched Data (CSD), Personal Handy-phone System (PHS), Wideband Integrated Digital Enhanced Network (WiDEN), iBurst, Unlicensed Mobile Access (UMA), also referred to as also referred to as 3GPP Generic Access Network, or GAN standard), Zigbee, Bluetooth®, Wireless Gigabit Alliance (WiGig) standard, millimeter wave (mm Wave) standards in general for wireless systems operating at 10-90 GHz and above such as WiGig, IEEE 802.1 1 ad, IEEE 802.1 1 ay, and so on, and/or general telemetry transceivers, and in general any type of RF circuit or RFI sensitive circuit. It should be noted that such standards may evolve over time, and/or new standards may be promulgated, and the scope of the claimed subject matter is not limited in this respect.

The WWAN transceiver 320 couples to one or more power amps 342 respectively coupled to one or more antennas 324 for sending and receiving radio-frequency signals via the WWAN broadband network. The baseband processor 312 also may control a wireless local area network (WLAN) transceiver 326 coupled to one or more suitable antennas 328 and which may be capable of communicating via a Wi-Fi, Bluetooth®, and/or an amplitude modulation (AM) or frequency modulation (FM) radio standard including an IEEE 802.1 1 a/b/g/n standard or the like. It should be noted that these are merely example implementations for application processor 310 and baseband processor 312, and the scope of the claimed subject matter is not limited in these respects. For example, any one or more of SDRAM 614, NAND flash 316 and/or NOR flash 318 may comprise other types of memory technology such as magnetic memory, chalcogenide memory, phase change memory, or ovonic memory, and the scope of the claimed subject matter is not limited in this respect.

In one or more embodiments, application processor 310 may drive a display 630 for displaying various information or data, and may further receive touch input from a user via a tou6h screen 332 for example via a finger or a stylus. An ambient light sensor 334 may be utilized to detect an amount of ambient light in which information handling system 300 is operating, for example to control a brightness or contrast value for display 330 as a function of the intensity of ambient light detected by ambient light sensor 334. One or more cameras 336 may be utilized to capture images that are processed by application processor 310 and/or at least temporarily stored in NAND flash 316. Furthermore, application processor may couple to a gyroscope 338, accelerometer 340, magnetometer 342, audio coder/decoder (CODEC) 344, and/or global positioning system (GPS) controller 346 coupled to an appropriate GPS antenna 348, for detection of various environmental properties including location, movement, and/or orientation of information handling system 300. Alternatively, controller 346 may comprise a Global Navigation Satellite System (GNSS) controller. Audio CODEC 344 may be coupled to one or more audio ports 350 to provide microphone input and speaker outputs either via internal devices and/or via external devices coupled to information handling system via the audio ports 350, for example via a headphone and microphone jack. In addition, application processor 310 may couple to one or more input/output (I/O) transceivers 352 to couple to one or more I/O ports 354 such as a universal serial bus (USB) port, a high-definition multimedia interface (HDMI) port, a serial port, and so on. Furthermore, one or more of the I/O transceivers 352 may couple to one or more memory slots 356 for optional removable memory such as secure digital (SD) card or a subscriber identity module (SIM) card, although the scope of the claimed subject matter is not limited in these respects.

Referring now to FIG. 4, an isometric view of an information handling system of FIG. 3 that optionally may include a touch screen in accordance with one or more embodiments will be discussed. FIG. 4 shows an example implementation of information handling system 300 of FIG. 3 tangibly embodied as a cellular telephone, smartphone, or tablet type device or the like. The information handling system 300 may comprise a housing 410 having a display 330 which may include a touch screen 332 for receiving tactile input control and commands via a finger 416 of a user and/or a via stylus 418 to control one or more application processors 310. The housing 410 may house one or more components of information handling system 300, for example one or more application processors 310, one or more of SDRAM 314, NAND flash 316, NOR flash 318, baseband processor 312, and/or WWAN transceiver 320. The information handling system 300 further may optionally include a physical actuator area 420 which may comprise a keyboard or buttons for controlling information handling system via one or more buttons or switches. The information handling system 300 may also include a memory port or slot 356 for receiving nonvolatile memory such as flash memory, for example in the form of a secure digital (SD) card or a subscriber identity module (SIM) card. Optionally, the information handling system 300 may further include one or more speakers and/or microphones 424 and a connection port 354 ftjr connecting the information handling system 300 to another electronic device, dock, display, battery charger, and so on. In addition, information handling system 300 may include a headphone or speaker jack 428 and one or more cameras 336 on one or more sides of the housing 410. It should be noted that the information handling system 300 of FIG. 4 may include more or fewer elements than shown, in various arrangements, and the scope of the claimed subject matter is not limited in this respect.

As used herein, the term "circuitry" may refer to, be part of, or include an Application

Specific Integrated Circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group), and/or memory (shared, dedicated, or group) that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable hardware components that provide the described functionality. In some embodiments, the circuitry may be implemented in, or functions associated with the circuitry may be implemented by, one or more software or firmware modules. In some embodiments, circuitry may include logic, at least partially operable in hardware. Embodiments described herein may be implemented into a system using any suitably configured hardware and/or software.

Referring now to FIG. 5, example components of a wireless device such as User Equipment (UE) device 1 10 in accordance with one or more embodiments will be discussed. User equipment (UE) may correspond, for example, to UE 1 10 of network 100, although the scope of the claimed subject matter is not limited in this respect. In some embodiments, UE device 500 may include application circuitry 502, baseband circuitry 504, Radio Frequency (RF) circuitry 506, front-end module (FEM) circuitry 508 and one or more antennas 510, coupled together at least as shown.

Application circuitry 502 may include one or more application processors. For example, application circuitry 502 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The one or more processors may include any combination of general? purpose processors and dedicated processors, for example graphics processors, application processors, and so on. The processors may be coupled with and/or may include memory and/or storage and may be configured to execute instructions stored in the memory and/or storage to enable various applications and/or operating systems to run on the system.

Baseband circuitry 504 may include circuitry such as, but not limited to, one or more single- core or multi-core processors. Baseband circuitry 504 may include one or more baseband processors and/or control logic to process baseband signals received from a receive signal path of RF circuitry 506 and to generate baseband signals for a transmit signal path of the RF circuitry 506. Baseband processing circuity 504 may interface with the application circuitry 502 for generation and processing of the baseband signals and for controlling operations of the RF circuitry 506. For example, in some embodiments, the baseband circuitry 304 may include a second generation (2G) baseband processor 504a, third generation (3G) baseband processor 504b, fourth generation (4G) baseband processor 504c, and/or one or more other baseband processors 504d for other existing generations, generations in development or to be developed in the future, for example fifth generation (5G), sixth generation (6G), and so on. Baseband circuitry 504, for example one or more of baseband processors 504a through 504d, may handle various radio control functions that enable communication with one or more radio networks via RF circuitry 506. The radio control functions may include, but are not limited to, signal modulation and/or demodulation, encoding and/or decoding, radio frequency shifting, and so on. In some embodiments, modulation and/or demodulation circuitry of baseband circuitry 504 may include Fast-Fourier Transform (FFT), precoding, and/or constellation mapping and/or . demapping functionality. In some embodiments, encoding and/or decoding circuitry of baseband circuitry 304 may include convolution, tail-biting convolution, turbo, Viterbi, and/or Low Density Parity Check (LDPC) encoder and/or decoder functionality. Embodiments of modulation and/or demodulation and encoder and/or decoder functionality are not limited to these examples and may include othe,v suitable functionality in other embodiments.

In some embodiments, baseband circuitry 504 may include elements of a protocol stack such as, for example, elements of an evolved universal terrestrial radio access network (EUTRAN) protocol including, for example, physical (PHY), media access control (MAC), radio link control (RLC), packet data convergence protocol (PDCP), and/or radio resource control (RRC) elements. Processor 504e of the baseband circuitry 504 may be configured to run elements of the protocol stack for signaling of the PHY, MAC, RLC, PDCP and/or RRC layers. In some embodiments, the baseband circuitry may include one or more audio digital signal processors (DSP) 504f. The one or more audio DSPs 504f may include elements for compression and/or decompression and/or echo cancellation and may include other suitable processing elements in other embodiments. Components of the baseband circuitry may be suitably combined in a single chip, a single chipset, or disposed on a same circuit board in some embodiments. In some embodiments, some or alLpf the constituent components of baseband circuitry 504 and application circuitry 502 may be implemented together such as, for example, on a system on a chip (SOC).

In some embodiments, baseband circuitry 504 may provide for communication compatible with one or more radio technologies. For example, in some embodiments, baseband circuitry 504 may support communication with an evolved universal terrestrial radio access network (EUTRAN) and/or other wireless metropolitan area networks (WMAN), a wireless local area network (WLAN), a wireless personal area network (WPAN). Embodiments in which baseband circuitry 304 is configured to support radio communications of more than one wireless protocol may be referred to as multi-mode baseband circuitry.

RF circuitry 506 may enable communication with wireless networks using modulated electromagnetic radiation through a non-solid medium. In various embodiments, RF circuitry 506 may include switches, filters, amplifiers, and so on, to facilitate the communication with the wireless network. RF circuitry 506 may include a receive signal path which may include circuitry to down-convert RF signals received from FEM circuitry 508 and provide baseband signals to baseband circuitry 504. RF circuitry 506 may also include a transmit signal path which may include circuitry to up-convert baseband signals provided by the baseband circuitry 504 and provide RF output signals to FEM circuitry 508 for transmission.

In some embodiments, RF circuitry 506 may include a receive signal path and a transmit signal path. The receive signal path of RF circuitry 506 may include mixer circuitry 506a, amplifier circuitry 506b and filter circuitry 506c. The transmit signal path of RF circuitry 506 may include filter circuitry 506c and mixer circuitry 506a. RF circuitry 506 may also include synthesizer circuitry 506d for synthesizing a frequency for use by the mixer circuitry 506a of the receive signal path and the transmit signal path. In some embodiments, the mixer circuitry 506a of the receive signal path may be configured to down-convert RF signals received from FEM circuitry 508 based on the synthesized frequency provided by synthesizer circuitry 506d. Amplifier circuitry 506b may be configured to amplify the down-converted signals and the filter circuitry 506c may be a low- pass filter (LPF) or band-pass filter (BPF) configured to remove unwanted signals from the down- converted signals to generate output baseband signals. Output baseband signals may be provided to baseband circuitry 504 for further processing. In some embodiments, the output baseband signals may be zero-frequency baseband signals, although this is not a requirement. In some embodiments, mixer circuitry 506a of the receive signal path may comprise passive mixers, although the scope of the embodiments is not limited in this respect.

In some embodiments, mixer circuitry 506a of the transmit signal path may be configured to up-convert input baseband signals based on the synthesized frequency provided by synthesizer circuitry 506d to generate RF output signals for FEM circuitry 508. The baseband signals may be provided by the baseband circuitry 504 and may be filtered by filter circuitry 506c. Filter circuitry 506c may include a low-pass filter (LPF), although the scope of the embodiments is not limited.jp this respect.

In some embodiments, mixer circuitry 506a of the receive signal path and the mixer circuitry 506a of the transmit signal path may include two or more mixers and may be arranged for quadrature down conversion and/or up conversion respectively. In some embodiments, mixer circuitry 506a of the receive signal path and the mixer circuitry 506a of the transmit signal path may include two or more mixers and may be arranged for image rejection, for example Hartley image rejection. In some embodiments, mixer circuitry 306a of the receive signal path and the mixer circuitry 506a may be arranged for direct down conversion and/or direct up conversion, respectively. In some embodiments, mixer circuitry 506a of the receive signal path and mixer circuitry 506a of the transmit signal path may be configured for super-heterodyne operation.

In some embodiments, the output baseband signals and the input baseband signals may be analog baseband signals, although the scope of the embodiments is not limited in this respect. In some alternate embodiments, the output baseband signals and the input baseband signals may be digital baseband signals. In these alternate embodiments, RF circuitry 506 may include analog-to- digital converter (ADC) and digital-to-analog converter (DAC) circuitry, and baseband circuitry 304 may include a digital baseband interface to communicate with RF circuitry 506. In some dual- mode embodiments, separate radio integrated circuit (IC) circuitry may be provided for processing signals for one or more spectra, although the scope of the embodiments is not limited in this respect.

In some embodiments, synthesizer circuitry 506d may be a fractional-N. synthesizer or a fractional N N+l synthesizer, although the scope of the embodiments is not limited in this respect as other types of frequency synthesizers may be suitable. For example, synthesizer circuitry 506d may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer comprising a phas - locked loop with a frequency divider. Synthesizer circuitry 506d may be configured to synthesize an output frequency for use by mixer circuitry 506a of RF circuitry 506 based on a frequency input and a divider control input. In some embodiments, synthesizer circuitry 506d may be a fractional N/N+l synthesizer.

In some embodiments, frequency input may be provided by a voltage controlled oscillator (VCO), although that is not a requirement. Divider control input may be provided by either baseband circuitry 504 or applications processor 502 depending on the desired output frequency. In some embodiments, a divider control input (e.g., N) may be determined from a look-up table based on a channel indicated by applications processor 502.

Synthesizer circuitry 506d of RF circuitry 506 may include a divider, a delay-locked loop (DLL), a multiplexer and a phase accumulator. In some embodiments, the divider may be a dual modulus divider (DMD) and the phase accumulator may be a digital phase accumulator (DP A). In some embodiments, the DMD may be configured to divide the input signal by either N or N+l , for example based on a carry out, to provide a fractional division ratio. In some example embodiments, the DLL may include a set of cascaded, tunable, delay elements, a phase detector, a charge pump and a D-type flip-flop. In these embodiments, the delay elements may be configured to break a VCO period up into Nd equal packets of phase, where Nd is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.

In some embodiments, synthesizer circuitry 506d may be configured to generate a carrier frequency as the output frequency, while in other embodiments, the output frequency may ba a multiple of the carrier frequency, for example twice the carrier frequency, four times the carrier frequency, and so on, and. used in conjunction with quadrature generator and divider circuitry to generate multiple signals at the carrier frequency with multiple different phases with respect to each other. In some embodiments, the output frequency may be a local oscillator (LO) frequency (fLO). In some embodiments, RF circuitry 506 may include an in-phase and quadrature (IQ) and/or polar converter.

FEM circuitry 508 may include a receive signal path which may include circuitry configured to operate on RF signals received from one or more antennas 510, amplify the received signals and provide the amplified versions of the received signals to the RF circuitry 506 for further processing. FEM circuitry 508 may also include a transmit signal path which may include circuitry configured to amplify signals for transmission provided by RF circuitry 506 for transmission by one or more of the one or more antennas 510.

In some embodiments, FEM circuitry 508 may include a transmit/receive (TX/RX) switch to switch between transmit mode and receive mode operation. FEM circuitry 508 may include a receive signal path and a transmit signal path. The receive signal path of FEM circuitry 508 may include a low-noise amplifier (LNA) to amplify received RF signals and to provide the amplified received RF signals as an output, for example to RF circuitry 506. The transmit signal path of FEM circuitry 508 may include a power amplifier (PA) to amplify input RF signals, for example provided by RF circuitry 506, and one or more filters to generate RF signals for subsequent transmission, for example by one or more of antennas 510. In some embodiments, UE device 500 may include additional elements such as, for example, memory and/or storage, display, camera, sensor, and/or input/output (I/O) interface, although the scope of the claimed subject matter is not limited in this respect.

The following examples pertain to further embodiments. Example 1 includes an apparatus of a User Equipment (UE) capable to transfer a service between two networks, the UE comprising circuitry to: receive a Single Radio Voice Call Continuity (SRVCC) capability indication from an evolved Node B (eNB); and initiate handover of an ongoing service from a cellular network to a Wireless Local Area Network (WLAN) based at least in part on the SRVCC capabil ity indication. In example 2, an apparatus as set forth in example 1 optional ly includes an arrangement, wherein the ongoing service is to comprise one or more of: a voice service or a video service. In example 3, an apparatus as set forth in any of examples 1 -2 optionally includes an arrangement, wherein the ongoing service is to comprise a Voice over Long Term Evolution (VoLTE) service. In example 4, an apparatus as set forth in any of examples 1 -3 optionally includes an arrangement, wherein the SRVCC capability indication is to comprise one or more of: an SRVCC voice capabil ity or an SRVCC video capability. In example 5, an apparatus as set forth in any of examples 1 -4 optionally includes an arrangement, wherein the SRVCC capabi l ity indication is to be provided in system information broadcast. In example 6, an apparatus as set forth in any of examples 1 -5 optionally includes an arrangement, wherein the SRVCC capabil ity indication is to be provided in a Radio Resource Control (RRC) signal. In example 7, an apparatus as set forth in any of examples 1 -6 optional ly includes an arrangement, wherein a Mobi lity Management Entity (MME) is to provide the SRVCC capability indication. In example 8, an apparatus as set forth in any of examples 1 -7 optional ly incl udes an arrangement, wherein a Serving-Cal l Session Control Function (S-CSCF) is to provide the SRVCC capabi l ity indication. In example 9, an apparatus as set forth in any of examples 1 -8 optionally includes an arrangement, comprising circuitry to initiate handover of an ongoing service from a cellular network to a WLAN optionally includes an arrangement, wherein the UE is to comprise-, ^ WLAN transceiver to communicate via the WLAN. In example 1 0, an apparatus as set forth in any of examples 1 -9 optionally includes an arrangement, comprising circuitry to initiate handover of an ongoing service from a cel lular network to a WLAN optionally includes an arrangement, wherein the UE is to comprise a cellular transceiver to communicate via the cellular network. In example 1 1 , an apparatus as set forth in any of examples 1 - 10 optionally includes an arrangement, comprising circuitry to initiate handover of an ongoing service from a cellular network to a WLAN based at least in part on a link quality of the cellular network. In example 12, an apparatus as set forth in any of examples 1 -1 1 optionally includes an arrangement, comprising circuitry to initiate handover of an ongoing service from a cellular network to a WLAN based at least in part on a first threshold value for a link quality of the cellular network optionally includes an arrangement, wherein the first threshold value is higher than any configured cellular inter Radio Access Technology (inter-RAT) handover threshold. In example 13, an apparatus as set forth in any of examples 1 - 12 optionally includes an arrangement, comprising circuitry to initiate handover of an ongoing service from a cellular network to a WLAN optionally includes an arrangement, wherein once the handover to the WLAN is complete, the UE is to cause failure of a subsequent SRVCC command. In example 14, an apparatus as set forth in any of examples 1 - 13 optionally includes an arrangement, comprising circuitry to initiate handover of an ongoing service from a cellular network to a WLAN optionally includes an arrangement, wherein once the handover to the WLAN is complete, the UE is to cause failure of a subsequent SRVCC command optionally includes an arrangement, wherein the UE is to notify the eNB that cause of the SRVCC handover failure is absence of a Multimedia Telephony (MMTEL) voice or video service over the cellular network.

Example 1 5 includes one or more computer-readable media having instructions stored thereon that, if executed by an apparatus of a user equipment (UE), result in: receiving, a Single Radio Voice Call Continuity (SRVCC) capability indication from an evolved Node B (eNB); and initiating handover of an ongoing service from a cellular network to a Wireless Local Area Network (WLAN) based at least in part on the SRVCC capability indication. In example 16, the one or more computer-readable media as set forth in example 1 5 optionally includes an arrangement, wherein the instructions, if executed, result in determining the SRVCC capability indication based at least on status of a bit. In example 1 7, the one or more computer-readable media as set forth in any of examples 1 5- 16 optionally includes an arrangement, wherein the instructions, if executed, result in initiating handover of an ongoing service from a cellular network to a WLAN optionally includes an arrangement, wherein the UE is to comprise a WLAN transceiver to communicate via the WLAN.

Example 18 includes an apparatus of a UE capable to transfer a service between two networks, the UE comprising circuitry to: initiate handover of an ongoing service from a cellular network to a WLAN in response to a threshold value, wherein once the handover to the WLAN is complete, the UE is to cause failure of a subsequent SRVCC command. I n example 1 9, an apparatus as set forth in example 1 8 optionally includes an arrangement, wherein the threshold value is to comprise a cellular network link quality threshold. In example 20, an apparatus as set forth in any one of examples 1 8- 1 9 optionally includes an arrangement, wherein the threshold value is to comprise an LTE (Long Term Evolution) \\i\ quality threshold. In example 21 , an apparatus as set forth in any one of examples 1 8-20 optionally includes an arrangement, wherein the handover is to be prioritized based at least in part on a trigger optional ly includes an arrangement, wherein the trigger is to ensure the service is transferred to WLAN prior to an eNB initiates an SRVCC request. In example 22, an apparatus as set forth in any one of examples 1 8-21 optionally includes an arrangement, wherein the ongoing service is to comprise one or more of: a voice service or a video service. In example 23, an apparatus as set forth in any of examples 1 8-22 optionally includes an arrangement, comprising circuitry to initiate handover of an ongoing service from a cellular network to a WLAN based at least in part on a l ink quality of the cellular network. In example 24, an apparatus as set forth in any of examples 1 8-23 optionally includes an arrangement, comprising circuitry to initiate handover of an ongoing service from a cellular network to a WLAN based at least in part on a first threshold value for a link qual ity of the cellular network optionally includes an arrangement, wherein the first threshold value is higher than any configured cellular inter Radio Access Technology (inter-RAT) handover threshold. In example 25, an apparatus as set forth in any of examples 1 8-24 optionally includes an arrangement, comprising circuitry to initiate handover of an ongoing service from a cel lular network to a WLAN optionally includes an arrangement, wherein once the handover to the WLAN is complete, the UE is to cause fai lure of a subsequent SRVCC command. In example 26, an apparatus as set forth in any of examples 1 8-25 optionally includes an arrangement, comprising circuitry to initiate handover of an ongoing service from a cel lular network to a WLAN optionally includes an arrangement, wherein once the handover to the WLAN is complete, the UE is to cause failure of a subsequent SRVCC command optionally includes an arrangement, wherein the UE is to notify the eNB that cause of the SRVCC handover failure is absence of a Multimedia Telephony (MMTEL) voice or video service over the cellular network.

Example 27 includes one or more computer-readable media having i nstructions stored thereon that, if executed by an apparatus of a user equipment (UE), result in : initiating handover of an ongoing service from a cel lular network to a WLAN in response to a threshold value, wherein once the handover to the WLAN is complete, the UE is to cause fai lure of a subsequent SRVCC command.. In example 28, the one or more computer-readable media as set forth in example 27 optionally includes an arrangement, wherein the threshold value is to comprise a cellular network link quality threshold. In example 29, the one or more computer-readable media as set forth in any of examples 27-28 optionally includes an arrangement, wherein the handover is to be prioritized based at least in part on a trigger.

Example 30 includes an apparatus comprising means to perform a method as set forth in any preceding example. Example 3 1 comprises machine-readable storage including machine-readable instructions, when executed, to implement a method or realize an apparatus as set forth in any preceding example.

In various embodiments, the operations discussed herein, e.g., with reference to Figs. 1 -5, may be implemented as hardware (e.g., logic circuitry), software, firmware, c-r combinations thereof, which may be provided as a computer program product, e.g., including a tangible (e.g., non-transitory) machine-readable or computer-readable medium having stored thereon instructions (or software procedures) used to program a computer to perform a process discussed herein. The machine-readable medium may include a storage device such as those discussed with respect to Figs. 1 -5.

Additionally, such computer-readable media may be downloaded as a computer program product, wherein the program may be transferred from a remote computer (e.g., a server) to a requesting computer (e.g., a client) by way of data signals provided in a carrier wave or other propagation medium via a communication l ink (e.g., a bus, a modem, or a network connection).

Reference in the specification to "one embodiment" or "an embodiment" means that a particular feature, structure, and/or characteristic described in connection with the embodiment may be included in at least an implementation. The appearances of the phrase "in one embodiment" in various places in the specification may or may not be all referring to the same embodiment.

Also, in the description and claims, the terms "coupled" and "connected," along with their derivatives, may be used. In some embodiments, "connected" may be used to indicate that two or more elements are in direct physical or electrical contact with each other. "Coupled" may mean that two or more elements are in direct physical or electrical contact. However, "coupled" may also mean that two or more elements may not be in direct contact with each other, but may sti l l cooperate or interact with each other.

Further, in the description and/or claims, the terms "coupled" and/or connected, along with their derivatives, may be used. In particular embodiments, connected may be used ^" > indicate that two or more elements are in direct physical and/or electrical contact with each other. Coupled may mean that two or more elements are in direct physical and/or electrical contact. However, coupled may also mean that two or more elements may not be in direct contact with each other, but yet may sti l l cooperate and/or interact with each other. For example, "coupled" may mean that two or more elements do not contact each other but are indirectly joined together via another element or intermediate elements.

Additionally, the terms "on," "overlying," and "over" may be used in the description and claims. "On," "overlying," and "over" may be used to indicate that two or more elements are in direct physical contact with each other. However, "over" may also mean that two or more elements are not in direct contact with each other. For example, "over" may mean that one element is above another element but not contact each other and may have another element or elements in between the two elements. Furthermore, the term "and/or" may mean "and", it may mean "or", it may mean "exclusive-or", it may mean "one", it may mean "some, biit not all", it may mean "neither", and/or it may mean "both", although the scope of claimed subject matter is not limited in this respect. In the fol lowing description and/or claims, the terms "comprise" and " include," along with their derivatives, may be used and are intended as synonyms for each other.

Thus, although embodiments have been described in language specific to structural features and/or methodological acts, it is to be understood that claimed subject matter may not be limited to the specific features or acts described. Rather, the specific features and acts are disclosed as sample forms of implementing the claimed subject matter.

Claims

An apparatus of a User Equipment (UE) capable to transfer a service between two networks, the UE comprising circuitry to:

receive a Single Radio Voice Call Continuity (SRVCC) capability indication from an evolved Node B (eNB); and

initiate handover of an ongoing service from a cellular network to a Wireless Local Area Network (WLAN) based at least in part on the SRVCC capability indication.

An apparatus as claimed in claim 1 , wherein the ongoing service is to comprise one or more of: a voice service or a video service.

An apparatus as claimed in any of claims 1 -2, wherein the ongoing service is to comprise a Voice over Long Term Evolution (VoLTE) service.

An apparatus as claimed in any of claims 1 -3, wherein the SRVCC capability indication is to comprise one or more of: an SRVCC voice capability or an SRVCC video capability.

An apparatus as claimed in any of claims 1 -4, wherein the SRVCC capability indication is to be provided in system information broadcast.

An apparatus as claimed in any of claims 1 -5, wherein the SRVCC capability indication is to be provided in a Radio Resource Control (RRC) signal.

An apparatus as claimed in any of claims 1 -6, wherein a Mobility Management Entity (MME) is to provide the SRVCC capability indication.

An apparatus as claimed in any of claims 1 -7, wherein a Serving-Cal l Session Control Function (S-CSCF) is to provide the SRVCC capability indication.

An apparatus as claimed in any of claims 1 -8, comprising circuitry to initiate handover of an ongoing service from a cellular network to a WLAN, wherein the UE is to comprise a WLAN transceiver to communicate via the WLAN.

An apparatus as claimed in any of claims 1 -9, comprising circuitry to initiate handover of an ongoing service from a cellular network to a WLAN, wherein the UE is to comprise a cellular transceiver to communicate via the cellular network.

1 1. An apparatus as claimed in any of claims 1 -10, comprising circuitry to initiate handover of an ongoing service from a cellular network to a WLAN based at least in part on a lin^ quality of the cellular network.

12. An apparatus as claimed in any of claims 1 -1 1 , comprising circuitry to initiate handover of an ongoing service from a cellular network to a WLAN based at least in part on a first threshold value for a link quality of the cellular network, wherein the first threshold value is higher than any configured cellular inter Radio Access Technology (inter-RAT) handover threshold.

13. An apparatus as claimed in any of claims 1 -12, comprising circuitry to initiate handover of an ongoing service from a cellular network to a WLAN, wherein once the handover to the WLAN is complete, the UE is to cause failure of a subsequent SRVCC command.

14. An apparatus as claimed in any of claims 1- 13, comprising circuitry to initiate handover¹ ' of an ongoing service from a cellular network to a WLAN, wherein once the handover to the WLAN is complete, the UE is to cause failure of a subsequent SRVCC command, wherein the UE is to notify the eNB that cause of the SRVCC handover failure is absence of a Multimedia Telephony (M TEL) voice or video service over the cellular network.

15. One or more computer-readable media having instructions stored thereon that, if

executed by an apparatus of a user equipment (UE), result in:

receiving a Single Radio Voice Call Continuity (SRVCC) capability indication from an evolved Node B (eNB); and

initiating handover of an ongoing service from a cellular network to a Wireless Local Area Network (WLAN) based at least in part on the SRVCC capability indication.

16. The one or more computer-readable media as claimed in claim 15, wherein the

instructions, if executed, result in determining the SRVCC capability indication based at least on status of a bit.

17. The one or more computer-readable media as claimed in any of claims 15-16, wherein the instructions, if executed, result in initiating handover of an ongoing service from a cellular network to a WLAN, wherein the UE is to comprise a WLAN transceiver to communicate via the WLAN.

18. An apparatus of a UE capable to transfer a service between two networks, the UE comprising circuitry to:

initiate handover of an ongoing service from a cellular network to a WLAN in response to a threshold value,

wherein once the handover to the WLAN is complete, the UE is to cause failure of a subsequent SRVCC command.

19. An apparatus as claimed in claim 18, wherein the threshold value is to comprise a cellular network link quality threshold.

20. An apparatus as claimed in any one of claims 18-19, wherein the threshold value is to comprise an LTE (Long Term Evolution) link quality threshold.

21. An apparatus as claimed in any one of claims 18-20, wherein the handover is to be

prioritized based at least in part on a trigger, wherein the trigger is to ensure the service is transferred to WLAN prior to an eNB initiates an SRVCC request.

22. An apparatus as claimed in any one of claims 18-21 , wherein the ongoing service is to comprise one or more of: a voice service or a video service.

23. One or more computer-readable media having instructions stored thereon that, if

executed by an apparatus of a user equipment (UE), result in:

initiating handover of an ongoing service from a cellular network to a WLAN in response to a threshold value,

wherein once the handover to the WLAN is complete, the UE is to cause failure of a subsequent SRVCC command..

24. The one or more computer-readable media as claimed in claim 23, wherein the threshold value is to comprise a cellular network link quality threshold.

25. The one or more computer-readable media as claimed in any of claims 23-24, wherein the handover is to be prioritized based at least in part on a trigger.