HK1173600B - Determination of appropriate radio resource to be requested in case of a circuit-switched (cs) fallback procedure - Google Patents

Abstract

A system and method for implementing fallback on a wireless device for circuit switched fallback from a first network that does not provide a circuit switched domain service is presented. A paging message is received from the first network. The paging message instructs the wireless device to implement circuit switched fallback to a circuit switched network. The paging message is inspected for information indicative of a service associated with the paging message, and a channel type suitable for the service is determined from the information indicative of the service. A request message for initiating the establishment of a radio connection is transmitted. The request message identifies the suitable channel type, and the service is used on the circuit switched network.

Description

Determining suitable radio resources to request during a Circuit Switched (CS) fallback procedure

Cross Reference to Related Applications

The present application claims priority from european patent application No.09306075.4 entitled "Determination of application Radio Resource to be Requested in Case of circuit-switch (cs) Fallback Procedure" filed on 9.11.2009 and incorporated herein by reference.

Technical Field

The present invention relates to systems and methods for communicating between a wireless device or User Agent (UA) and a network, and more particularly, to systems and methods for coordinating communication resources between a wireless device and a network, including a circuit-switched network.

Background

As used herein, the term "user agent" or "UA" may refer to mobile devices such as mobile phones, Personal Digital Assistants (PDAs), handheld or laptop computers, and similar devices including Mobile Stations (MSs) or User Equipment (UE) that have communication capabilities. In some embodiments, a UA may refer to a mobile wireless device. The term "UA" may also refer to devices that have similar capabilities but that are not typically portable, such as desktop computers, set-top boxes, or network devices.

UAs may operate in wireless communication networks that provide high-speed data and/or voice communication. Wireless communication networks may implement circuit-switched (CS) and/or packet-switched (PS) communication protocols to provide various services. For example, a UA may operate according to one or more of the following techniques: evolved universal terrestrial radio access network (E-UTRAN), Universal Terrestrial Radio Access Network (UTRAN), global system for mobile communications (GSM) network, evolution data optimized (EV-DO), digital enhanced radio communication (DECT), digital AMPS (IS-136/TDMA), Integrated Digital Enhanced Network (iDEN), Universal Mobile Telecommunications System (UMTS), enhanced data rates for GSM evolution (EDGE), GPRS/EDGE radio access network (GERAN), and General Packet Radio Service (GPRS) technologies. Other wireless networks in which UAs may operate include, but are not limited to, Code Division Multiple Access (CDMA), CDMA2000, CDMA20001xRTT, CDMA2000HRPD, WLAN (e.g., IEEE 802.11), and WRAN (e.g., IEEE 802.22). A UA may also operate in a fixed network environment, such as a digital subscriber line (xDSL) environment, a Data Over Cable Service Interface Specification (DOCSIS) cable network, a wireless Personal Area Network (PAN), bluetooth, ZigBee, a wireless Metropolitan Area Network (MAN) (e.g., WiMAX, IEEE 802.20, IEEE 802.22 ethernet), or an optical network. Some UAs may be capable of multimode operation in which they are capable of operating on more than one access network technology, or on a single access network at a time, or in some devices using multiple access technologies simultaneously.

In a wireless communication system, transmitting devices in a base station transmit signals over an entire geographic area known as a cell. As technology evolved, more advanced devices have been introduced that are capable of providing services that were not previously possible. Such advanced equipment may include, for example: evolved universal terrestrial radio access network (E-UTRAN) Node B (eNB) over base stations, or other systems and devices that are further highly evolved than comparable devices in conventional wireless communication systems. Such advanced or next generation devices may be referred to herein as Long Term Evolution (LTE) devices, and packet-based networks using such devices may be referred to as Evolved Packet Systems (EPS). As used herein, the term "access device" will refer to any component, such as a legacy base station, eNB, or other LTE access device, that is capable of providing a UA with access to other components in a communication system.

The different networks described above provide diverse services to connected UAs. Some networks, for example, provide only PS services and are not capable of providing CS voice or other CS domain services. As such, a UA may be configured to connect to multiple network types to access both PS and CS domain services. For example, if a UA is connected to a first network cell that does not provide CS domain services, the UA may be configured to implement a CS fallback procedure (which may be referred to herein as "CS fallback") to connect to accessible networks such as GERAN or Universal Terrestrial Radio Access Network (UTRAN) to access voice or other CS domain services provided by those networks. As such, the CS fallback procedure allows a UA connected to a network that uses a first Radio Access Technology (RAT) and provides only PS domain services to connect to another network that provides CS domain services. In the case where the UA is associated with a cell of a network that provides only PS domain services when initiating a voice call, CS fallback may be used, for example, to initiate a voice call via a cell of a network that provides CS domain services. A UA originating a voice call may be either idle or connected (active) on a cell of a network that provides PS domain services only. If a UA is idle, it may be said to be camped on a cell and may be monitoring a paging message for a mobile terminated session or call on a paging channel of the cell. If the UA is connected, it may continue to communicate with the cell and transmit data for PS domain services.

Turning to fig. 1, an example of a CS fallback procedure is shown in which a UA10 is handed over from an E-UTRAN network cell 12 to a GERAN or UTRAN cell 14 for initiating a voice call to access CS domain services. As will be described, to facilitate CS fallback, the UA10 may be configured to communicate with both PS-based and CS-based networks. For example, the UA10 may support a combined procedure for EPS/International Mobile Subscriber Identity (IMSI) attachment and tracking area update for registering with a Mobility Management Entity (MME) to access PS domain services (e.g., via an E-UTRAN, or GERAN access network) and for registering with a Mobile Switching Center (MSC) to access CS domain services (e.g., via a UTRAN or GERAN access network or another network supporting CS domain services). The combining procedure also allows the MSC and MME to create an association between each other so that both know that the UA10 is registered to both the MSC and MME, and thus the UA10 is registered to both the PS network and the CS network.

Fig. 2 shows a data flow diagram of an example data flow for a mobile terminated CS fallback procedure, where the UA10 in connected mode is redirected to GERAN or UTRAN. In fig. 1, a UA10 is initially connected to an E-UTRAN cell 12. Because the E-UTRAN cell 12 does not provide CS domain services, the UA10 implements CS fallback to communicate with GERAN or UTRAN cells 14 to access the CS domain services they provide.

As an example, a Network Assisted Cell Change (NACC) in connection with a mobile originated voice call will be described. Referring to fig. 1 and 2, the example procedure begins with the MSC 16 sending a CS page 18 to the MME 20, which in turn prompts the MME 20 to send a CS service notification page 22 to the UA 10. In fig. 1, communications from the E-UTRAN cell 12 are indicated by arrow 23, while communications from the UA10 to the E-UTRAN cell 12 are indicated by arrow 25. In response to the CS service notification page 22, the UA10 sends an extended service request 24 to an eNB 26 of the E-UTRAN cell 12. However, the E-UTRAN cell is not configured to provide CS domain services. Therefore, MME 20 sends an S1 application protocol (S1-AP) message with CS fallback indicator 30 to eNB 26.

To improve the efficiency of the exemplary data flow, fig. 2 indicates some data flows by blocks, which may be, for example, optional measurement reports 32, which may be provided by the UA10 to indicate information such as the signal strength of neighboring cells to which it may be allocated. That is, when performing CS fallback, the UA10 may be in the best position to determine which cell or cells are candidate cells to fallback to. As such, the UA10 is able to detect which cells are in close proximity or have particularly strong received signal strength or quality (or other such parameters), and thus the UA10 will likely have a successful connection with these cells after the CS fallback procedure. Thus, during the CS fallback procedure, the UA10 may take measurement steps to detect and identify cells accessible to the UA 10. In other words, the UA10 may search for available candidate network cells via a measurement procedure before fallback to a cell providing CS domain services.

The enodeb (enb) may trigger an inter-RAT cell change command (optionally triggered with a NACC signal 34 sent to the UA 10), alternatively by signaling a connection release 36 with redirection. eNB 26 indicates UA context release request 38 to MME 20 according to S1-AP. Thereafter, S1UA context release 40 occurs, and a Location Area (LA) update, a combined Routing Area (RA)/LA update, an RA update, or an LA update and an RA update 42 occurs in the new GERAN or UTRAN cell. If the target RAT is GERAN, suspension of PS service may occur if the new cell or UA does not support the current CS and PS services. In this case, a suspend message 44 is sent from the UA10 to a Base Station System (BSS)46, which is then passed from the BSS 46 to a serving GPRS (general packet radio service) support node (SGSN) 48. Thereafter, a suspend request/response 50 is passed between SGSN 48 and MME 20, and an update 52 of the bearer occurs between MME 20 and serving gateway (S-GW) 54.

The UA10 signals the BSS/RNS 46 with a page response 56, which the BSS/RNS 46 then forwards to the MSC 16. If CS fallback requires a change in the MSC 16, additional steps such as passing a connection rejection 60 from the MSC 16 to the BSS/RNS 46, a connection release 62 from the BSS/RNS 46 to the UA10, and a LA update or combined RA/LA update 64 may be performed, as shown in block 58. Finally, a CS call setup procedure 66 occurs such that, as shown in fig. 1, the UA10 can move from communicating with the E-UTRAN cell 12 (as indicated by arrow 68) to communicating with the GERAN or UTRAN cell 14 over a CS channel (as indicated by arrow 70).

Latency may be a concern when implementing CS fallback. If the UA10 is initially camped on an E-UTRAN cell 12 and wishes to access CS domain services in a GERAN or UTRAN cell 14, a CS fallback procedure may be performed. Although the Radio Resource Control (RRC) connection setup procedure of the CS fallback procedure may be short (e.g., the target time for E-UTRA system design is about 150ms), the measurement step and the step for selecting a target cell for CS domain services may take a considerable amount of time. As such, the CS fallback may be delayed, resulting in a delay in the establishment of the CS domain service, possibly delaying the connection establishment for the user, or adversely affecting other services accessed by the UA 10.

In addition to this potential for the user to experience noticeable service delays, CS fallback may also result in inefficient or inappropriate use of network resources. For example, when a UA is paged for a mobile terminated call in a GERAN or UTRAN network, the network passes some information in the paging message. That is, the paging message may provide an indication of the service for which the UA is being paged or an indication of the appropriate radio channel type to support the service. Similarly, in the case of a mobile originated call, the UA indicates to the network an establishment cause reflecting the requested service or channel type. Thus, the network can reasonably allocate channels appropriate for the desired communication.

However, such information is not available on the corresponding E-UTRAN interface used when initiating the CS fallback procedure, or is available but not accessed for requesting/allocating radio channels in GERAN, UTRAN or E-UTRAN. As a result, the network may decide to allocate non-optimal resources, such as a signaling channel for serving voice calls, which may affect CS fallback performance, or a traffic channel for serving signaling procedures, so that radio resources are wasted.

Accordingly, systems and methods that address the problems listed above and allow for optimal resource setting and usage for CS fallback provide a useful improvement over the prior art.

Disclosure of Invention

Drawings

In the drawings, like reference numerals designate like parts or operations.

FIG. 1 is a diagram of an example CS fallback procedure in which a UE transitions from an E-UTRAN cell to a GERAN or UTRAN cell to access CS domain services for the purpose of initiating a voice call;

fig. 2 is a data flow diagram illustrating an example data flow for a mobile terminated CS fallback procedure, wherein the UA10 in connected mode is redirected to GERAN or UTRAN without PS handover;

fig. 3 is a data flow diagram illustrating an example mobile terminated call origination in a GERAN network, wherein the UA is in idle mode;

fig. 4 is a data flow diagram illustrating an example mobile terminated call origination in a UTRAN network, wherein the UA is in idle mode;

FIG. 5 is a data flow diagram illustrating an example Mobile Caller CS fallback procedure for packet switched handover initiation in an E-UTRAN network;

fig. 6 is a diagram illustrating a data flow for implementing an example mobile terminated CS fallback where service related information is passed to a UA in idle mode in a paging message;

FIG. 7 shows a block diagram of a user equipment (UA);

FIG. 8 illustrates a software environment that a processor of a user device may implement; and

fig. 9 illustrates an example of a system including processing components suitable for implementing a method for providing continuity for session transitions between networks.

Detailed Description

The present disclosure provides systems and methods for Circuit Switched (CS) fallback, and in particular, systems and methods that minimize delay, optimize radio resource allocation, and improve CS fallback reliability.

One embodiment of the present invention includes a system and method for implementing fallback on a wireless device for circuit switched fallback from a first network that does not provide circuit switched domain services. The method includes receiving a paging message from a first network. The paging message instructs the wireless device to implement circuit switched fallback to the circuit switched network. The method comprises the following steps: the method comprises examining information in the paging message indicating a service associated with the paging message, determining a channel type suitable for the service based on the information indicating the service, and sending a request message for initiating establishment of a radio connection. The request message identifies the appropriate channel type. The method comprises using the service on a circuit switched network.

Other embodiments of the present invention include a wireless device configured to perform circuit switched fallback from a first network that does not provide circuit switched domain services, the wireless device comprising a processor configured to construct a service request message. The service request message identifies a reason for a Circuit Switched (CS) service to be provided by a circuit switched network. The processor is further configured to send a service request message to the first network. The service request message initiates a fallback procedure. The processor is configured to establish a connection to a circuit-switched network and use the CS service over the circuit-switched network.

Other embodiments include a wireless device configured to perform circuit switched fallback from a first network that does not provide circuit switched domain services, the wireless device comprising a processor configured to receive a paging message from the first network. The paging message instructs the wireless device to implement circuit switched fallback to the circuit switched network. The processor is configured to: the method comprises examining information in the paging message indicating a service associated with the paging message, determining a channel type suitable for the service based on the information indicating the service, and sending a request message for initiating establishment of a radio connection. The request message identifies the appropriate channel type. The processor is configured to use the service over a circuit switched network.

Various aspects of the present disclosure are now described with reference to the drawings, wherein like reference numerals designate like or corresponding elements throughout. It should be understood, however, that the drawings and detailed description relating thereto are not intended to limit the claimed subject matter to the particular form disclosed. On the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the claimed subject matter.

As used herein, the terms "component," "system," and the like are intended to refer to a computer-related entity, either hardware, a combination of hardware and software, or software in execution. For example, a component may be, but is not limited to being, a process running on a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a computer and the computer can be a component. One or more components may reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers.

The word "exemplary" is used herein to mean serving as an example, instance, or illustration. Any aspect or design described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other aspects or designs.

Furthermore, the disclosed subject matter may be implemented as a system, method, apparatus, or article of manufacture using standard programming and/or engineering techniques to produce software, firmware, hardware, or any combination thereof to control a computer or processor-based device to perform various aspects detailed herein. The term "article of manufacture" (or alternatively, "computer program product") as used herein is intended to encompass a computer program accessible from any computer-readable device, carrier, or media. For example, computer-readable media may include, but are not limited to: magnetic storage devices (e.g., hard disk, floppy disk, magnetic tape, etc.), optical disks (e.g., Compact Disk (CD), Digital Versatile Disk (DVD), etc.), smart cards, and flash memory devices (e.g., card, stick, etc.). Additionally, it should be understood that a carrier wave can be employed to carry computer-readable electronic data such as those used in transmitting and receiving electronic mail or in accessing a network such as the Internet or a Local Area Network (LAN). Of course, those skilled in the art will recognize many modifications may be made to this configuration without departing from the scope or spirit of the claimed subject matter.

As noted above, CS fallback is likely to result in non-optimal resource allocation, such as: the signaling channel is used to serve voice calls, which may cause conditions that affect CS fallback performance; or the traffic channel is used for a service signaling process, causing waste of radio resources. For example, turning to fig. 3, in the case of mobile terminated call origination in GERAN, the UA10 is typically provided with a "wanted channel" indication in a paging message 72 sent by the GERAN network 72, which is information informing of a more suitable radio channel, such as a stand-alone dedicated control channel (SDCCH) signaling channel, a Traffic Channel (TCH)/all (F), for supporting the service to which the UA is being paged. The UA10 then sends an appropriate channel request 76 to the GERAN network 72, which allows the BSS to grant the most desirable channel, taking into account the "paging indication" of the "required channel" element received in the paging message 72 and the UA 10's own capabilities (full rate only, dual rate, SDCCH only). For example, table 1 below lists the channel request messages when responding to a page for RR connection establishment.

MS capability paging indication	Full rate only	Double rate	SDCCH only
				Any channel	1OOxxxxx	1OOxxxxx	1OOxxxxx
SDCCH	0001xxxx	0001xxxx	0001xxxx
				TCH/F	1OOxxxxx	0010xxxx	0001xxxx
TCH/H or TCH/F	1OOxxxxx	0011xxxx	0001xxxx

TABLE 1

However, in case of paging the UA for a CS fallback terminating session in E-UTRAN, the page (CS service notification) sent by MME 20 (as described with reference to fig. 2) to UA10 in connected mode in the source (packet only) network does not contain any "paging indication" information. The paging notification may include information about the service to which the mobile station is being paged (e.g., supplementary service code, location services (LCS) indicator). In the case of paging for arriving at a UA10 in idle mode (see, e.g., fig. 6), the paging message sent over the S1 interface and over the radio interface does not even contain any indication of the service to which the mobile station is being paged. Furthermore, the GERAN RR protocol does not specify how the UA should construct a channel request when answering a page triggered by a CS fallback procedure. This means that the existing channel request procedures defined for GERAN cannot be applied equally to CS fallback (absence of "paging indication") to determine the correct and best information in the channel request message that can be sent in the target network.

As a result, CS fallback to GERAN may result in contradictory UA implementations, e.g., requesting a channel type that is not suitable for the activated service, resulting in waste of allocated resources or longer setup time. In particular, the request and initial assignment of the SDCCH in the case of voice call setup will delay the voice path setup compared to the case of requesting and assigning a Traffic Channel (TCH) in the signaling-only mode (the longer the SDCCH reacts to the TCH; the longer the time for assigning a TCH in voice mode when the SDCCH has been assigned compared to the channel mode change procedure when staying on the same TCH channel). Otherwise, if a service (such as location service or supplementary service) can be supported on the SDCCH, the request and initial allocation of the TCH in the signaling-only mode would waste radio resources.

Turning to another exemplary identified problem, fig. 4 illustrates a mobile terminated CS call in a UTRAN network 78, wherein the UA10 is in idle mode. In this example case, the "paging cause" information is typically provided to the UA10 in a paging message sent by the UTRAN network 78, which is information informing the UA of the type of service being paged, such as terminating a session call, terminating high priority signaling, terminating low priority signaling, as shown by "paging type 1" 90. This information is forwarded by the RRC protocol in the UA10 to the upper layers which in turn request establishment of an RRC connection and map the RRC establishment cause to the received paging cause, which will be included in the RRC connection request 82 sent to the UTRAN network 78.

However, in case of paging the UA for a CS fallback terminating session in E-UTRAN, the page (CS service notification) sent by the MME to the UA in connected mode in the source (packet only, e.g. PS only) network does not contain any "paging cause" information. The paging notification may include information about the service to which the mobile station is paged.

In case paging is made for arriving at a UA in idle mode, the paging message sent over the S1 interface and the radio interface does not even contain any indication of the service to which the mobile station is being paged. Further, higher layers do not specify: for the case of the CS fallback procedure, what information should be included in the RRC connection request to the RRC protocol in response to the paging that has occurred in the E-UTRAN. Also, in UTRAN, this may result in contradictory UA implementations and result in significantly suboptimal resource allocation or performance.

In the case of a mobile originated call in GERAN or UTRAN, the UA includes some additional information in the channel request/RRC connection request sent to the network, such as channel type, establishment cause, etc., allowing the network to allocate appropriate resources based on the requested service. Turning now to fig. 5, fig. 5 is a variation of fig. 2, but shows a data flow for a mobile originated call undergoing CS fallback, including operation 24 for handling a service request from the UA10 to the network. The service type information element is included in an extended service request message sent to the network. The service type information element is shown in table 2 below:

TABLE 2

However, this information element does not provide any information to the source network about the requested CS service and therefore does not allow the network to correctly determine the size of the resources to be allocated according to the requested service or, for the case of supporting RAT handover or cell change commands, does not allow the network to determine the optimal conditions for handing over the UA to the target CS network, e.g. based on available channel and load information.

Generally, the present systems and methods have been developed to reduce latency and improve reliability of CS fallback procedures. In particular, CS fallback may be implemented for transitioning from E-UTRAN to GERAN, or more generally, CS fallback may be implemented for transitioning from a first network that does not provide CS domain services to a second network that provides CS domain services. For example, CS fallback may be implemented to allow fallback from an E-UTRAN network to a GERAN, UTRAN, or CDMA2000 network. To this end, the present systems and methods facilitate CS fallback by allowing UAs to identify the most appropriate resources for providing requested services and then request those resources when transitioning to the CS network during CS fallback. In one implementation of the present system, the UA is configured to analyze available paging information received from the network to determine the most appropriate communication channel or radio resource to request for optimal CS fallback performance.

To initiate CS fallback, a UA may first receive a paging message from a source PS network (e.g., an E-UTRAN network). The paging message instructs the UA to implement CS fallback to a CS network (e.g., a GERAN network) to access services. If the relevant service can be determined using the information conveyed in the paging message, the UA configures a channel request message requesting a channel type on the CS network appropriate for the service. Also, based on one or more pieces of information contained in the paging message, the UA is configured to request a specific channel type when implementing CS fallback.

For example, when the paging message is for a voice call or for any call requiring a traffic channel, the UA can be configured to request a "TCH/H or TCH/F" channel, or a "TCH/F" channel. Alternatively, the UA may request the SDCCH when the paging message is for activating a call-independent supplementary service or, for example, a location service. In these examples, the selection of a "TCH/H or TCH/F" channel may not require any specific preference for the selection of a half-rate (H) or full-rate (F) channel. The network may automatically make a determination of a full-rate or half-rate channel based on local conditions (network load status, quality of service preferences, etc.). However, the selection of a TCH/F channel may affect the network decision on whether to select a full-rate channel or a half-rate channel.

In some circumstances, the paging message will contain insufficient information for the UA to determine the service to which the UA is being paged. In this case, the UA may be configured to construct and transmit a channel request reflecting a "default" channel type, e.g., using the value "any channel" or some other indicator identifying a default channel.

Thus, in one example implementation of the present system, in the case of a channel request triggered by a CS fallback procedure, such as described in 3GPP TS 23.272, the channel request message content may be determined based on information about the service to which the mobile station is paged, which may be derived from a paging notification received in the source Radio Access Technology (RAT). If no specific information can be derived from the paging announcement, the channel request message content may be set to a paging indicator value indicating "any channel". For example, the channel request message content may be encoded according to table 3, where the "paging indication" entry is selected according to the description above indicating the associated service.

TABLE 3

Alternatively, the UA may be configured to select the channel "TCH/H or TCH/F" or SDCCH according to whether fast setup or radio resource saving is preferred or according to some other factor that may require a particular default channel (e.g., preferences may be stored as user preferences or determined from network operator measurements).

Depending on the system implementation, a UA may be configured with an explicit mapping between the service indicated by the paging message and the channel type to be requested during fallback. However, in other cases, after determining the service indicated in the paging message, the UA may determine the channel type to request based on other information available to the UA independently. If there is no explicit mapping and the UA is able to independently determine the channel type to request, the UA may have more flexibility and may rely on other available information in identifying the channel type to request. Conversely, an explicit mapping may preclude different interpretations and ensure consistency of the channel selected by the UA in response to a particular paging message.

In one example of the present system, various information elements present in a CS service notification message transmitted between an MME and a UA may be checked to determine the service to which the UA is paged, and thus the UA may be allowed to request the most appropriate channel type for providing the service. For example, a Calling Line (CLI), Supplementary Service (SS) code, LCS indicator, and LCS client identity information element may be included in the CS service notification message, and their presence or absence may indicate the service being requested. Typically, the CLI contains an identification of the calling line for the mobile terminated call in the CS domain that triggered paging via the SG. The SS code information element contains information about supplementary service transactions in the CS domain that triggered paging via the SG. The LCS indicator indicates that paging is triggered by a terminating LCS request in the CS domain. The LCS client identity contains information about the requester of the terminating LCS request in the CS domain. Each information unit is sent by the network if it is initially received via the SG. Table 4 shows the CS service notification message contents.

TABLE 4

These information elements may be initially received from the MSC/Visitor Location Register (VLR) in the SGsAP-PAGING-REQUEST message and continue to be transmitted in the CS service notification message. The presence or absence of information elements in the SGsAP-PAGING-REQUEST message is governed by various rule sets and indicates the type of service for which CS fallback is requested. For example, if the PAGING is due to a network-initiated call-independent SS procedure as defined in 3GPP TS 24.010, the VLR includes the SS code in the SGsAP-PAGING-REQUEST message as defined in 3GPP TS 29.002. However, if the PAGING is due to a mobile terminating location REQUEST as defined in 3GPP TS 24.030, the VLR includes the LCS indicator as defined in 3GPP TS29.002 in the SGsAP-PAGING-REQUEST message. According to these rules, various information elements are included in the SGsAP-PAGING-REQUEST message and forwarded to UA in the CS service notification message content. Also, the presence or absence of one or several of these information elements allows the UA to make a determination regarding the service to which the UA is being paged.

Table 5 shows exemplary SGsAP-PAGING-REQUEST message contents.

Information unit	Type/reference	Presence of	Format	Length of
					Message type	Message type 9.2	M	V	1
IMSI	IMSI 9.4.6	M	TLV	6-10
					Name of VLR	Name of VLR 9.4.22	M	TLV	3-n
Service indicator	Service indicator 9.4.17	M	TLV	3
					TMSI	TMSI 9.4.20	0	TLV	6
CLI	CLI 9.4.1	0	TLV	3-14
					Location area identifier	Location area identifier 9.4.11	0	TLV	7
CN-ld in the world	Global CN-ld 9.4.4	0	TLV	7
					SS code	SS code 9.4.19	0	TLV	3
LCS indicator	LCS indicator 9.4.10	0	TLV	3
					LCS client identification	LCS client identity 9.4.9	0	TLV	3-n
Desired channel	Desired channel 9.4.23	0	TLV	3
					eMLPP priority	eMLPP priority 9.4.24	0	TLV	3

TABLE 5

As shown in table 5, if the paging is due to an SS procedure that is not related to the network-initiated call (see 3GPP TS 24.010), an SS code is included. If the paging is due to a mobile terminating location request (see 3GPP TS 24.030), an LCS indicator is included. If the paging is due to a mobile terminating location request (see 3GPP TS 24.030), the LCS client identity is included. If the VLR intends to indicate which channel the UA should use, the required channel information element is included.

The UA may be further configured to check for additional information to determine the service indicated by the particular paging request. The additional information may include other information elements that may be added in the future, including those identified below.

The present system is further configured to include service-related information available at the MME in a paging message for paging the UA in idle mode. For example, service related information may be added to S1 and the RRC paging message. In one example, the service-related information may include the "SS code", "LCS indicator", and "LCS client identity" information elements described above. The service related information may be transmitted by the MSC/VLR to the MME in an SGsAP-PAGING-REQUEST message over the SG interface. In some cases, these information elements are already present in the CS service notification message for paging the UA in connected mode, and thus may be added to the S1 interface paging message by the MME and to the E-UTRAN RRC radio interface paging message by the E-UTRAN RRC protocol. Thus, in addition to the case of paging a UA in connected mode, additional information present in the paging message may also be used when paging a UA in idle mode.

Table 6 shows an S1 interface paging message modified to include an SS code, an LCS indicator, and an LCS client identity information element.

TABLE 6

Table 7 shows an E-UTRAN RRC protocol paging message modified to include an SS code, an LCS indicator, and an LCS client identity information element.

TABLE 7

Referring to table 7, ss code carries information related to network-initiated assisted service requests. An LCS-Indicator indicates that the origin of the message is due to the LCS request and the type of the request. The coding of the LCS-Indicator is given by the value part of the LCS Indicator information element in TS 24.301. The LCS-Client-Identity carries information about the Client requested by the LCS. The coding of LCS client identity is given in subclause 17.7.13 of 3GPP TS 29.002.

Fig. 6 is a schematic diagram of a data flow for implementing CS fallback, where service related information is passed to the UA10 in a paging message. In steps 100, 102 and 104, the UA terminates the call to the MSC/VLR 140. In step 106, an SGsAP-PAGING-REQUEST message is sent to MME 20. The SGsAP-PAGING-REQUEST may include one or more information elements indicating the type of service requested. In steps 108 and 110, MME 20 forwards the paging message to UA 10. The paging message is modified to include one or more of the information elements described above. The presence or absence of one or more information elements allows the UA to identify the type of service for which the paging message is sent. As a result, in step 112, the UA may request appropriate resources for the service. In step 114, in response to the service request, MME 20 issues an initial UA context setup message. In steps 116, 118 and 120, a PS handover is completed, or alternatively a base station assisted cell change or RRC release with redirection, possibly followed by a location area update. A page response is sent from the UA10 to the RNC/BSC 142 in step 122, and the page response is forwarded to the MSC/VLR 140 in step 124. If the MSC has not changed, the CS connection is established in step 126 and the CS fallback procedure is completed. However, if the MSC changes, the MSC/VLR 140 sends a connection rejection to the RNC/BSC 142 in step 128. In response, the RNC/BSC 142 sends a signaling connection release to the UA10 in step 130. At this point, a location area update and roaming retry are initiated to reattempt CS fallback in step 132.

Optionally, to facilitate CS fallback, a required channel information element (when known to the MME) may be added to a paging message sent to the UA to page the UA in idle mode or in connected mode. For example, the required channel information element may be added to a CS service notification NAS message (as described above) transmitted between the MME and the UA, an S1 interface paging message as described above, or an RRC radio interface protocol as described above. In some cases, the data to fill the required channel information element is transmitted by the MSC/VLR to the MME over the SG interface in an SGsAP-PAGING-REQUEST message, as described above. When the required channel information element is present in the paging message, the UA is allowed to effectively create an appropriate channel request message when it replies to a CS fallback page in GERAN, since the same information will be present in the GERAN paging message (if sent by the MSC/VLR).

In order to enable the UA paging for a mobile terminated CS call with fallback in E-UTRAN to send the appropriate establishment cause when answered in UTRAN, a new mapping entry may be introduced. This would allow the UA to communicate to the network an appropriate establishment cause reflecting the service to which the UA is being paged, if the relevant service can be estimated from the information carried in the paging message. In this case, the UA may include an establishment cause of a mapping transmitted by an upper layer in RRC connection request information when it answers a page received in a source packet network (e.g., E-UTRAN) in UTRAN.

As an example, the establishment cause may be determined as follows: the establishment cause may be a "terminating session call" when the received page is for a voice call or for any other conversational CS call, or a "terminating high priority signaling" when the received page is for activating a supplementary service or a location service not relevant for the call.

The UA may use "termination-cause unknown" as an establishment cause if the service to which the UA is paged cannot be estimated from information available from the network.

Table 8 shows an exemplary mapping of CS NAS procedures to establishment causes.

TABLE 8

The information element may indicate the service to which the mobile device is paged when various information elements including an "SS code", an "LCS indicator", and an "LCS client identity" information element exist in a CS service notification message between the MME and the UA. The various information elements may be received from the MSC/VLR in an SGsAP-PAGING-REQUEST message. Thus, the presence or absence of one or several of these information elements allows the UA to make a determination regarding the service to which the UA is being paged. Any other information that a UA may access or retrieve from a message received from a network or other source may be used to determine the service to which the UA is being paged. This may include new information elements added in the future, including those described above.

When initiating a Mobile Originated (MO) call, the UA may be configured to provide additional information describing the requested CS service to the PS network, where the requested CS service may trigger a CS fallback. In one implementation, the UA includes additional information describing the CS service being requested in an extended service request message sent to the MME of the PS network. Similarly, this additional information may be included in an INITIAL CONTEXT SETUP REQUEST (INITIAL CONTEXT SETUP REQUEST) or UA CONTEXT MODIFICATION REQUEST (UACONTEXT MODIFICATION REQUEST) message sent from the MME to the eNodeB using the S1 interface (see 3GPP TS 36.413).

Tables 9 and 10 show a modified extended service request message including additional information describing a CS service requested by a UA originating an MO call causing a CS fallback.

TABLE 9

Watch 10

As shown in table 9 and table 10, the extended service request message shown in table 9 includes an additional element called "extended service request cause". Table 10 shows the specific contents of the extended service request cause information element. The extended service request cause unit is configured to store an identifier value describing the requested CS service in octet 1. For example, the identifier may be used to refer to a CS service such as a calling session call, calling high priority signaling, or calling low priority signaling. Table 11 shows one exemplary configuration of octet 1 of the extended service request cause information element.

TABLE 11

In some cases, an existing service type information element present in an existing extended service request message may be modified and used to identify the CS service being requested. Optionally, when the UA originates a mobile originated call, an additional information element indicating the originating service (e.g., an "SS code" or "LCS" indicator defined for the service notification message) may be included in the message. In another example, when initiating a mobile originated call that experiences CS fallback, CS service information may be included in an RRC connection request message (see 3GPP TS 36.331) that may be used to turn the UA from idle mode to connected mode.

Fig. 7 illustrates an example block diagram of UA 10. Although various known components of UA10 are described, in embodiments a subset of the listed components and/or additional components not listed may be included in UA 10. The UA10 includes a processor, such as a Digital Signal Processor (DSP)802, and a memory 804. As shown, the UA10 may further include an antenna and front end unit 806, a Radio Frequency (RF) transceiver 808, and an analog baseband processing unit 810. In various configurations, UA10 may include additional optional components, as shown in fig. 7. Additional components may include, for example, a microphone 812, an earpiece speaker 814, a headset port 816, an input/output interface 818, a removable memory card 820, a Universal Serial Bus (USB) port 822, a short-range wireless communication subsystem 824, an alarm 826, a keyboard 828, a Liquid Crystal Display (LCD), which may include a touch-sensitive surface 830, an LCD controller 832, a charge-coupled device (CCD) camera 834, a camera controller 836, and a Global Positioning System (GPS) sensor 838. In embodiments, the UA10 may include another type of display that does not provide a touch sensitive screen. In an embodiment, the DSP802 may communicate directly with the memory 804 without passing through the input/output interface 818.

The DSP802 or some other form of controller or central processing unit operates to control the various components of the UA10 in accordance with embedded software or firmware stored in the memory 804 or in a memory self-contained within the DSP 802. In addition to the embedded software or firmware, the DSP802 may execute other applications stored in the memory 804 or made available via information carrier media such as portable data storage media like the removable memory card 820 or via wired or wireless network communications. The application software may comprise a set of machine-readable instructions that are compiled to configure the DSP802 to provide the desired functionality, or the application software may be high-level software instructions to be processed by an interpreter or compiler to indirectly configure the DSP 802.

The antenna and front end unit 806 may be provided for converting between wireless signals and electronic signals, enabling the UA10 to send information to and receive information from a cellular network or some other available wireless communication network or a peer UA 10. In an embodiment, the communication and front end unit 806 may include multiple antennas to support beamforming and/or multiple-input multiple-output (MIMO) operations. As known to those skilled in the art, MIMO operation may provide spatial diversity, which can be used to overcome difficult channel conditions and/or increase channel throughput. Antenna and front end unit 806 may include antenna tuning and/or impedance matching components, RF power amplifiers, and/or low noise amplifiers.

RF transceiver 808 provides frequency shifting, converts received RF signals to baseband, and converts baseband transmit signals to RF. In some descriptions, a radio transceiver or RF transceiver may be understood to include other signal processing functions such as modulation/demodulation, encoding/decoding, interleaving/deinterleaving, spreading/despreading, Inverse Fast Fourier Transform (IFFT)/Fast Fourier Transform (FFT), cyclic prefix addition/removal, and other signal processing functions. For clarity, the description herein separates the description of the signal processing from the RF and/or radio frequency stages and conceptually dispatches the signal processing to the analog baseband processing unit 810 and/or the DSP802 or other central processing unit. In some embodiments, the RF transceiver 808, portions of the antenna and front end 806, and the analog baseband processing unit 810 may be combined in one or more processing units and/or in an Application Specific Integrated Circuit (ASIC). The analog baseband processing unit 810 may provide various analog processing of inputs and outputs, such as analog processing of inputs from the microphone 812 and the headset 816 and outputs to the earpiece 814 and the headset 816.

The DSP802 may perform modulation/demodulation, encoding/decoding, interleaving/deinterleaving, spreading/despreading, Inverse Fast Fourier Transform (IFFT)/Fast Fourier Transform (FFT), cyclic prefix addition/removal, and other signal processing functions associated with the wireless communication. In an embodiment, for example, in a Code Division Multiple Access (CDMA) technology application, the DSP802 may perform modulation, coding, interleaving, and spreading for transmitter functions and despreading, deinterleaving, decoding, and demodulation for receiver functions. In another embodiment, for example, in an Orthogonal Frequency Division Multiple Access (OFDMA) technology application, for a transmitter function the DSP802 may perform modulation, coding, interleaving, inverse fast fourier transform, and cyclic prefix appending, and for a receiver function the DSP802 may perform cyclic prefix removal, fast fourier transform, deinterleaving, decoding, and demodulation. In other wireless technology applications, the DSP802 may also perform other signal processing functions and combinations of signal processing functions. The DSP802 may communicate with a wireless network via the analog baseband processing unit 810.

Fig. 8 illustrates a software environment 902 that may be implemented in a processor or controller of the UA 10. The software environment 902 includes an operating system driver 904 that is executable by a processor or controller of the UA10 to provide a platform on which the remaining software operates. The operating system driver 904 provides a standardized interface to the driver of the UA hardware that can access application software. The operating system drivers 904 include an application management service ("AMS") 906 that transfers control between applications running on the UA 10. Also shown in FIG. 8 are a web browser application 908, a media player application 910, and a Java applet 912.

The UA10 includes a processing component, such as a DPS, capable of executing instructions related to the actions described above. Fig. 9 illustrates an example of a system 1000, the system 1000 including one or more components that provide the functionality of the UA 10. The system 1000 includes a processing component 1010 suitable for performing one or more embodiments described herein. In addition to the processor 1010, which may be referred to as a central processing unit (CPU or DSP), the system 1000 may include a network connectivity device 1020, a Random Access Memory (RAM)1030, a Read Only Memory (ROM)1040, a secondary storage 1050, and an input/output interface (I/O) device 1060. In some cases, some of these components may not be present, or may be combined in various combinations with each other or with other components not shown. Any action taken by the processor 1010 described herein may be taken by the processor 1010 alone or by the processor 101 in conjunction with one or more components shown or not shown in the figures.

The processor 1010 executes instructions, codes, computer programs, or scripts that are accessible from the network connectivity devices 1020, the RAM 1030, the ROM 1040, or the secondary storage 1050 (which may include various disk-based systems such as hard disk, floppy disk, or optical disk). Although only one processor 1010 is shown, multiple processors may be present. Thus, although instructions are discussed as being executed by one processor, the instructions may be executed simultaneously, sequentially, or otherwise by one or more processors. The processor 1010 may be implemented as one or more CPU chips.

The network connection device 1020 may include one or more transceiver components 1025 capable of wirelessly transmitting and/or receiving data in the form of electromagnetic waves, such as radio frequency signals or signals at microwave frequencies. The transceiver module 1025 may include separate receive and transmit units or a single transceiver. The information transmitted or received by the transceiver may include data that has been processed by processor 1010 or instructions to be executed by processor 1010. Such information may be received from or output to the network, for example, in the form of a computer data baseband signal or signal embedded in a carrier wave. The data may be arranged in a different order as may be desired depending on any of the processing or generation of the data or the transmission or reception of the data. The baseband signal, signal embedded in a carrier wave, or other type of signal currently used or developed in the future may be referred to as a transmission medium and may be generated according to several methods well known to those skilled in the art.

RAM 1030 may be used to store volatile data and may store instructions that are executed by processor 1010. The ROM 1040 is a nonvolatile memory, and its storage capacity is generally smaller than that of the secondary storage device 1050. The ROM 1040 may be used to store instructions and perhaps data that are read during execution of the instructions. Access to RAM 1030 and ROM 1040 is typically faster than to secondary storage 1050.

The I/O devices 1060 may include Liquid Crystal Displays (LCDs), touch screen displays, keyboards, keypads, switches, dials, mice, track balls, voice recognizers, card readers, paper tape readers, printers, video displays, or other known input devices. Transceiver 1025 may also be considered a component of I/O device 1060 instead of, or in addition to, a component of network connection device 1020. Some or all of I/O devices 1060 may be substantially similar to various components of the previously described diagram of UA10 (such as display 702 and input 704).

While several embodiments have been provided in the present disclosure, it should be understood that the disclosed systems and methods may be embodied in many other specific forms without departing from the spirit or scope of the present disclosure. The examples given should be considered as illustrative and not restrictive, and are not intended to be limited to the details given herein. For example, various units or components may be combined or integrated in another system, or certain features may be omitted, or not implemented.

Also, techniques, systems, subsystems, and methods described and illustrated in the various embodiments as discrete or separate may be combined or integrated with other systems, modules, techniques, or methods without departing from the scope of the present disclosure. Other items shown or discussed as coupled or directly coupled or communicating with each other may be indirectly coupled or communicating through some interface, device, or intermediate component, whether electrically, mechanically, or otherwise. Other examples of changes, substitutions, and alterations are ascertainable by one skilled in the art and could be made without departing from the spirit and scope disclosed herein.

To apprise the public of the scope of the present disclosure, the appended claims are made.

Claims (20)

1. A method for implementing fallback on a wireless device for circuit switched fallback from a first network that does not provide circuit switched domain services, the method comprising:

receiving a paging message from a first network, the paging message instructing the wireless device to implement circuit switched fallback to a circuit switched network;

checking the paging message for information indicating a service associated with the paging message;

determining a channel type suitable for the service according to the information indicating the service;

sending a request message for initiating establishment of an initial circuit switched wireless connection to the circuit switched network, the request message identifying a suitable channel type; and

the service is used over a circuit switched network.

2. The method of claim 1, wherein the determining comprises:

identifying whether the service associated with the paging message is one of a first class of service including CS voice calls and CS services requiring traffic channels or session resources, a second class of service including mobile terminated location requests, and a third class of service including supplementary services.

3. The method of claim 2, wherein, if the service is a first class service, a channel type suitable for the service is at least one of a Traffic Channel (TCH)/half (H) or TCH/full (F).

4. The method of claim 2, wherein if the service is at least one of a second class of service or a third class of service, the channel type suitable for the service is a stand-alone dedicated control channel (SDCCH).

5. The method of claim 1, wherein checking the paging message comprises: detecting at least one of a Supplementary Service (SS) code information element, a location service (LCS) indicator information element, or an LCS client identification information element within the paging message; and

when the paging message includes an SS code information element, a channel type suitable for the service is suitable for a supplementary service unrelated to the call; or

The channel type appropriate for the service is appropriate for a mobile terminating location request when the paging message includes at least one of an LCS indicator information element and an LCS client identity information element.

6. The method of claim 1, wherein the paging message comprises a CS service notification message.

7. The method of claim 1, wherein the paging message comprises an E-UTRAN RRC protocol paging message received after a preliminary paging procedure implemented using an S1 interface.

8. A wireless device configured to perform circuit switched fallback from a first network not providing circuit switched domain services, the wireless device comprising:

a processor configured to:

constructing a service request message identifying a cause of a Circuit Switched (CS) service to be provided by a circuit switched network;

sending a service request message to a first network, the service request message initiating a fallback procedure;

establishing an initial CS wireless connection to the circuit-switched network; and

using the CS service over a circuit-switched network.

9. The wireless device of claim 8, wherein the reason for being served by the second network cell comprises at least one of a calling session call, calling high priority signaling, or calling low priority signaling.

10. The wireless device of claim 8, wherein the service request message comprises at least one of a Supplementary Service (SS) code information element, a location service (LCS) indicator information element, or an LCS client identification information element when the cause of the service comprises at least one of a caller high priority signaling or a caller low priority signaling.

11. The wireless device of claim 8, wherein the service request message comprises an extended service request message.

12. The wireless device of claim 8, wherein the service request message includes a service type information element, and the service type information element identifies the Circuit Switched (CS) service.

13. The wireless device of claim 8, wherein the service request message comprises an RRC connection request message.

14. A wireless device configured to perform circuit switched fallback from a first network not providing circuit switched domain services, the wireless device comprising:

a processor configured to:

receiving a paging message from a first network, the paging message instructing the wireless device to implement circuit switched fallback to a circuit switched network;

checking the paging message for information indicating a service associated with the paging message;

determining a channel type suitable for the service according to the information indicating the service;

sending a request message for initiating establishment of an initial circuit switched wireless connection to the circuit switched network, the request message identifying a suitable channel type; and

the service is used over a circuit switched network.

15. The wireless device of claim 11, wherein the processor is configured to: identifying whether a service associated with the paging message is one of a first class of service including CS voice calls and CS services requiring traffic channel or session resources, a second class of service including mobile terminated location requests, and a third class of service including supplementary services.

16. The wireless device of claim 15, wherein if the service is a first class service, then a channel type suitable for the service is at least one of a Traffic Channel (TCH)/half (H) or TCH/full (F).

17. The wireless device of claim 15, wherein if the service is at least one of a second class of service or a third class of service, the channel type suitable for the service is a stand-alone dedicated control channel (SDCCH).

18. The wireless device of claim 14, wherein the processor is configured to: detecting at least one of a Supplementary Service (SS) code information element, a location service (LCS) indicator information element, or an LCS client identification information element within the paging message; and

when the paging message includes an SS code information element, a channel type suitable for the service is suitable for a supplementary service unrelated to the call; or

The channel type appropriate for the service is appropriate for a mobile terminating location request when the paging message includes at least one of an LCS indicator information element and an LCS client identity information element.

19. The wireless device of claim 14, wherein the paging message comprises a CS service notification message.

20. The wireless device of claim 14, wherein the paging message comprises an E-UTRAN RRC protocol paging message received after a preliminary paging procedure implemented using an S1 interface.