Device and method for fallback assistance information

Abstract

The present invention relates to fallback assistance information. Apparatus, methods, and systems for providing fallback assistance information to a RAN node are disclosed. One apparatus includes a transceiver that transmits a service request, where the service request requests fallback to at least one of the following: a different radio access technology and a different generation of system, where the service request indicates that service fallback is required and receives a connection release message, where the connection release message includes redirection information for service fallback, and the redirection information includes a target RAT cell and a target system. The apparatus includes a processor that selects a NAS protocol from a plurality of NAS protocols supported by a remote unit based on the target system and uses the selected NAS protocol to connect to the target RAT and the target system.

Description

[0001] This application is a divisional application of the application with the title "Back-off Assistance Information", PCT application number PCT / IB2018 / 001507, international filing date November 20, 2018, and Chinese application number 201880074489.3, which entered the Chinese national phase on May 18, 2020.

[0002] Cross-reference to related applications

[0003] This application claims priority to U.S. Provisional Patent Application No. 62 / 588,846, titled "Back-off Assistance Information", filed on November 20, 2017, by Genadi Velev, Prateek Basu Mallick, Joachim Lohr, and Ravi Kuchibhotla, the entire content of which is incorporated herein by reference. Technical Field

[0004] The subject matter disclosed herein generally relates to wireless communication and, more particularly, to providing back-off assistance information to a RAN node. Background Art

[0005] The following abbreviations are defined herein, at least some of which are referred to in the following description: 3rd Generation Partnership Project (“3GPP”), Acknowledgement (“ACK”), Autonomous Uplink (“AUL”), AUL Downlink Feedback Information (“AUL-DFI”), Binary Phase Shift Keying (“BPSK”), Clear Channel Assessment (“CCA”), Cyclic Prefix (“CP”), Cyclic Redundancy Check (“CRC”), Channel State Information (“CSI”), Common Search Space (“CSS”), Discrete Fourier Transform Spread (“DFTS”), Downlink Control Information (“DCI”), Downlink (“DL”), Downlink Pilot Time Slot (“DwPTS”), Enhanced Clear Channel Assessment (“eCCA”), Enhanced Licensed-Assisted Access (“eLAA”), Enhanced Mobile Broadband (“eMBB”), evolved Node B (“eNB”), European Telecommunications Standards Institute (“ETSI”), Frame-based Device (“FBE”), Frequency Division Duplexing (“FDD”), Frequency Division Multiple Access (“FDMA”), Frequency Division Orthogonal Cover Code (“FD-OCC”), Guard Period (“GP”), Hybrid Automatic Repeat reQuest (“HARQ”), Internet of Things (“IoT”), Licensed-Assisted Access (“LAA”), Load-based Device (“LBE”), Listen Before Talk (“LBT”), Long Term Evolution (“LTE”), Multiple Access (“MA”), Modulation and Coding Scheme (“MCS”), Machine-Type Communication (“MTC”), Multiple-Input Multiple-Output (“MIMO”), Multi-User Shared Access (“MUSA”), NarrowBand (“NB”), Negative Acknowledgement (“NACK” or “NAK”), next-generation Node B (“gNB”), New Data Indicator (“NDI”), Non-Orthogonal Multiple Access (“NOMA”), Orthogonal Frequency Division Multiplexing (“OFDM”), Primary Cell (“PCell”), Physical Broadcast Channel (“PBCH”), Physical Downlink Control Channel (“PDCCH”), Physical Downlink Shared Channel (“PDSCH”), Pattern Division Multiple Access (“PDMA”), Physical Hybrid ARQ Indicator Channel (“PHICH”), Physical Random Access Channel (“PRACH”), Physical Resource Block (“PRB”), Physical Uplink Control Channel (“PUCCH”), Physical Uplink Shared Channel (“PUSCH”), Quality of Service (“QoS”), Quadrature Phase Shift Keying (“QPSK”), Radio Resource Control (“RRC”), Random Access Procedure (“RACH”), Random Access Response (“RAR”), Radio Network Temporary Identifier (“RNTI”), Reference Signal (“RS”), Remaining Minimum System Information (“RMSI”), Resource Block Assignment (“RBA”), Resource Spreading Multiple Access (“RSMA”), Round-Trip Time (“RTT”), Receive (“RX”), Sparse Code Multiple Access (“SCMA”).Scheduling Request (“SR”), Single Carrier Frequency Division Multiple Access (“SC-FDMA”), Secondary Cell (“SCell”), Shared Channel (“SCH”), Signal-to-Interference plus Noise Ratio (“SINR”), System Information Block (“SIB”), Synchronization Signal (“SS”), Transport Block (“TB”), Transport Block Size (“TBS”), Time Division Duplex (“TDD”), Time Division Multiplexing (“TDM”), Time Division Orthogonal Cover Code (“TD-OCC”), Transmission Time Interval (“TTI”), Transmit (“TX”), Uplink Control Information (“UCI”), User Entity / Equipment (Mobile Terminal) (“UE”), Uplink (“UL”), Universal Mobile Telecommunications System (“UMTS”), Uplink Pilot Time Slot (“UpPTS”), Ultra-Reliable and Low-Latency Communication (“URLLC”), and Worldwide Interoperability for Microwave Access (“WiMAX”). As used herein, “HARQ-ACK” may collectively represent an Acknowledgment (“ACK”) and a Negative Acknowledgment (“NACK”). ACK means correct reception of the TB, while NACK (or NAK) means incorrect reception of the TB.

[0006] In some wireless communication networks, a UE operating in a mobile communication network needs to change to a different system, such as a different network core (e.g., system-generated) and / or radio access technology, in order to receive services in the mobile communication network. A fallback process is typically used to allow interoperability of various services used by the remote unit 105. Traditional fallback processes involve a handover from the Packet Switching Domain (“PS domain”) to the Circuit Switching Domain (“CS domain”). Additionally, traditional fallback processes fail to notify the RAN and UE of the target system and the RATs, resulting in a situation where the UE may connect to the wrong system during the fallback process. Summary of the Invention

[0007] Methods for providing fallback assistance information to a RAN node are disclosed. Apparatus and systems also perform the functions of the methods.

[0008] A method for providing fallback assistance information to a RAN node (e.g., a method of a UE) includes sending a service request, where the service request requests a fallback to at least one of: a different RAT and a different CN. The method includes receiving, at the remote unit, a connection release message, where the connection release message includes redirection information for service fallback, and the redirection information includes a target CN. The method includes selecting a NAS procedure based on the target CN and using the selected NAS procedure to connect to the target CN.

[0009] Another method for providing fallback assistance information (e.g., a method for a RAN node) includes receiving a first message from a network function in a first core network, where the first message indicates a service fallback of a remote unit connected to the RAN node and indicates a target CN. The method includes determining service fallback parameters of the remote unit. The method includes sending a connection release message to the remote unit, where the connection release message includes redirection information for service fallback, and the redirection information includes the target CN.

[0010] Another method for providing fallback assistance information (e.g., a method for an AMF in a first core network) includes receiving a service request from a remote unit, where the service request is for a service that requests fallback to at least one of the following: a different RAT and a different CN. The method includes identifying at least one of a target RAT and a target CN at a network function based on at least one of the requested service, remote unit capabilities, and network configuration. The method includes indicating at least one of the target RAT and the target CN to a RAN node based on the requested service, where the RAN node performs fallback via the remote unit based on at least one of the following: the target RAT and the target CN. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] A more specific description of the embodiments briefly described above will be presented by reference to specific embodiments illustrated in the drawings. It should be understood that these drawings only depict some embodiments and are not thus considered to limit the scope. By using the drawings, the embodiments will be described and explained with additional features and details, where:

[0012] Figure 1 is a schematic block diagram illustrating an embodiment of a wireless communication system for providing fallback assistance information to a RAN node;

[0013] Figure 2 is a block diagram illustrating an embodiment of a process for providing fallback assistance information to a RAN node;

[0014] Figure 3 is a block diagram illustrating another process for providing fallback assistance information to a RAN node;

[0015] Figure 4 is a diagram illustrating an embodiment of a connection release message that can be used to provide fallback assistance information to a RAN node;

[0016] Figure 5 is a schematic block diagram illustrating an embodiment of a user equipment device that can be used to provide fallback assistance information to a RAN node;

[0017] Figure 6FIG. 0 is a schematic block diagram of an embodiment of a RAN device that can be used to provide fallback assistance information to a RAN node;

[0018] Figure 7 FIG. 4 is a schematic block diagram of an embodiment of a network function device that can be used to provide fallback assistance information to a RAN node;

[0019] Figure 8 FIG. 8 is a schematic block diagram of a first embodiment of a method for providing fallback assistance information to a RAN node;

[0020] Figure 9 FIG. 12 is a schematic block diagram of a second embodiment of a method for providing fallback assistance information to a RAN node; and

[0021] Figure 10 FIG. 16 is a schematic block diagram of a third embodiment of a method for providing fallback assistance information to a RAN node. DETAILED DESCRIPTION

[0022] As will be understood by those skilled in the art, aspects of the embodiments may be embodied as a system, apparatus, method, or program product. Accordingly, the embodiments may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects, which software and hardware aspects are generally referred to herein as "circuitry", "module", or "system". In addition, the embodiments may take the form of a program product embodied in one or more computer-readable storage devices storing machine-readable code, computer-readable code, and / or program code hereinafter referred to as code. The storage device may be tangible, non-transitory, and / or non-transmissive. The storage device may not embody a signal. In certain embodiments, the storage device merely takes the form of a signal for accessing the code.

[0023] Any combination of one or more computer-readable media may be utilized. The computer-readable medium may be a computer-readable storage medium. The computer-readable storage medium may be a storage device storing the code. The storage device may be, by way of example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, holographic, micro-mechanical, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing.

[0024] More specific examples (non-exhaustive list) of storage devices will include the following: electrical connections with one or more wires, portable computer disks, hard disks, random access memory ("RAM"), read-only memory ("ROM"), erasable programmable read-only memory ("EPROM" or flash memory), portable compact disc read-only memory ("CD-ROM"), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing. In the context of this document, a computer-readable storage medium can be any tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device.

[0025] The code for performing the operations of the embodiments can be any number of lines and can be written in any combination of one or more programming languages including object-oriented programming languages such as Python, Ruby, Java, Smalltalk, C++, etc., traditional procedural programming languages such as the "C" programming language, and / or machine languages such as assembly language. The code can execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer can be connected to the user's computer through any type of network connection, including a local area network ("LAN") or a wide area network ("WAN"), or can be connected to an external computer (e.g., through the Internet using an Internet service provider).

[0026] References in this specification to "one embodiment", "an embodiment", or similar language mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. Thus, unless otherwise explicitly stated, the phrases "in one embodiment", "in an embodiment", and similar language in this specification can, but do not necessarily, all refer to the same embodiment, but rather mean "one or more but not all embodiments". Unless otherwise explicitly stated, the terms "comprises", "comprising", "has", and their variants mean "including but not limited to". Unless otherwise explicitly stated, a list of enumerated items does not imply that any or all of the items are mutually exclusive. Unless otherwise explicitly stated, the terms "a", "an", and "the" also refer to "one or more".

[0027] In addition, the features, structures, or characteristics of the described embodiments may be combined in any suitable manner. In the following description, numerous specific details are provided, such as examples of programming, software modules, user selections, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., to provide a thorough understanding of the embodiments. However, those skilled in the relevant art will recognize that the embodiments may be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the embodiments.

[0028] Aspects of the embodiments are described below with reference to the schematic flowcharts and / or schematic block diagrams of methods, apparatuses, systems, and program products according to the embodiments. It will be understood that each block of the schematic flowcharts and / or schematic block diagrams, and combinations of blocks in the schematic flowcharts and / or schematic block diagrams, can be implemented by code. The code can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions executed by the processor of the computer or other programmable data processing apparatus create means for implementing the functions / operations specified in the blocks of the schematic flowchart and / or schematic block diagram or some of the blocks.

[0029] The code can also be stored in a storage device that can direct a computer, other programmable data processing apparatus, or other device to operate in a particular manner, such that the instructions stored in the storage device produce an article of manufacture including instructions that implement the functions / operations specified in the blocks of the schematic flowchart and / or schematic block diagram or some of the blocks.

[0030] The code can also be loaded onto a computer, other programmable data processing apparatus, or other device, such that a series of operational steps are performed on the computer, other programmable apparatus, or other device to produce a computer-implemented process, such that the code executed on the computer or other programmable apparatus provides a process for implementing the functions / operations specified in the blocks of the flowchart and / or block diagram or some of the blocks.

[0031] The schematic flowcharts and / or schematic block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of apparatuses, systems, methods, and program products according to various embodiments. In this regard, each block in the schematic flowcharts and / or schematic block diagrams may represent a module, segment, or portion of code that includes one or more executable instructions for implementing the specified logical function.

[0032] It should also be noted that, in some alternative embodiments, the functions of the annotations in the blocks may not occur in the order of the annotations in the figures. For example, two consecutively shown blocks may actually be executed substantially simultaneously, or these blocks may sometimes be executed in the reverse order, depending on the functions involved. Other steps and methods may be envisioned that are equivalent in function, logic, or effect to one or more blocks or portions of the illustrated figures.

[0033] Although various arrow types and line types may be employed in the flowcharts and / or block diagrams, it should be understood that they do not limit the scope of the corresponding embodiments. In fact, some arrows or other connectors may be used only to indicate the logical flow of the depicted embodiments. For example, an arrow may indicate a waiting or monitoring period of unspecified duration between the enumerated steps of the depicted embodiment. It will also be noted that each block of the block diagram and / or flowchart, and combinations of blocks in the block diagram and / or flowchart, can be implemented by a system based on dedicated hardware that performs a particular function or action, or a combination of dedicated hardware and code.

[0034] The description of the elements in each figure may refer to the elements of the foregoing figures. The same numerals refer to the same elements in all figures, including alternative embodiments of the same element.

[0035] A method for a service fallback procedure is disclosed herein, the method including the steps of: the CN providing fallback assistance information to a RAN node (e.g., a gNB), and the RAN node determining (1) the mobility mechanism (idle or connected mode mobility) and (2) the target RAT, and, if needed, the target CN for the fallback procedure. Herein, the fallback assistance information may include the type of mobility (e.g., based on the configuration in the CN, whether connected mode or idle mode mobility is preferred) and / or the target core network and / or critical requirements. Note that if the RAN node performs idle state mobility, the UE considers the indicated target core network when initiating a NAS procedure in the target cell. In various embodiments, the NAS procedure in the target CN may be: 1) implicitly also include a request for a specific service; or 2) be an independent NAS procedure for the requested service.

[0036] In one example, the UE has a pending IMS emergency session request (e.g., voice) from an upper layer. If the AMF has indicated support for emergency services using a fallback indication in the registration acceptance message for the current RAT, the UE sends a service request message indicating its requirement for emergency service fallback.

[0037] After receiving a service request for an emergency fallback, the AMF triggers an N2 procedure, which depending on factors such as N26 availability, network configuration, and radio conditions results in a connection state mobility (handover procedure) or idle state mobility (redirection) to E-UTRA / 5GC or E-UTRAN / EPC. Here, the 5GC triggers a request for an emergency service fallback by performing an NG-AP procedure, in which it indicates to the NG-RAN that this is a fallback for an emergency service. In the N2 procedure, based on the support of the emergency service in the EPC or 5GC, the AMF can indicate to the target CN of the RAN node whether an inter-RAT fallback or an inter-system fallback is to be performed. The target CN indicated in the N2 procedure is also communicated to the UE so that the appropriate NAS procedure (S1 or N1 mode) can be performed. When the AMF initiates a redirection for a successfully authenticated UE, the AMF includes the security context in the request to trigger a fallback to the NG-RAN.

[0038] Based on the target CN indicated in the N2 request for an emergency fallback, the NG-RAN performs one of the following procedures: (1) If the UE is currently camped on NR, the NG-RAN performs a fallback to an E-UTRAN cell connected to the 5GC (e.g., initiates a handover or redirection); or (2) The NG-RAN initiates a handover or redirection to an E-UTRAN connected to the EPS. Here, the NG-RAN uses the security context provided by the AMF to protect the redirection procedure. An example of performing a fallback includes the NG-RAN initiating a handover or redirection to the E-UTRAN.

[0039] Note that if the redirection procedure is used, the target CN is also communicated to the UE so that the appropriate NAS procedure (S1 or N1 mode) can be performed. After switching to the target cell, the UE establishes a PDU session / PDN connection for the IMS emergency service and performs the IMS procedure for establishing an IMS emergency session (e.g., voice).

[0040] Figure 1 An embodiment of a wireless communication system 100 for providing fallback assistance information to a RAN node is depicted. In one embodiment, the wireless communication system 100 includes at least one remote unit 105, a first access network 120 including at least one base station unit 110, a second access network 125 including at least one base station unit 110, a wireless communication link 115 between the remote unit 105 and the base station unit 110, a first core network 130, and a second core network 140. Although Figure 1A specific number of remote units 105, access networks 120, 125, base station units 110, wireless communication links 115, and core networks 130, 140 are depicted, but those skilled in the art will recognize that any number of remote units 105, access networks 120, 125, base station units 110, wireless communication links 115, and core networks 130, 140 can be included in the wireless communication system 100. In various embodiments, the access networks 120, 125 can include one or more WLANs (e.g., Wi-Fi TM ) access points (“APs”). Here, the first access network 120, the second access network 125, the first core network 130, and the second core network 140 belong to the same mobile communication network (e.g., the same PLMN).

[0041] In one embodiment, the wireless communication system 100 complies with the 5G system and the LTE system specified in the 3GPP specifications. However, more generally, the wireless communication system 100 can implement some other open or proprietary communication networks in other networks, such as WiMAX. The present disclosure is not intended to be limited to the implementation of any specific wireless communication system architecture or protocol.

[0042] In one embodiment, the remote unit 105 can include computing devices such as desktop computers, laptop computers, personal digital assistants (“PDAs”), tablet computers, smart phones, smart TVs (e.g., Internet-connected TVs), smart home appliances (e.g., Internet-connected home appliances), set-top boxes, game consoles, security systems (including security cameras), in-vehicle computers, network devices (e.g., routers, switches, modems), etc. In some embodiments, the remote unit 105 includes wearable devices such as smart watches, fitness bands, optical head-mounted displays, etc. Additionally, the remote unit 105 can be referred to as a subscriber unit, mobile device, mobile station, user, terminal, mobile terminal, fixed terminal, subscriber station, UE, user terminal, device, or other terms used in the art. The remote unit 105 can communicate directly with one or more base station units 110 via uplink (“UL”) and downlink (“DL”) communication signals. Further, the UL and DL communication signals can be carried on the wireless communication link 115.

[0043] In some embodiments, the remote unit 105 communicates with a remote host 180 (e.g., an application server) via a data path through one of the core networks 130 and 140 and also through the data network 175. For example, the remote unit 105 may establish a PDU session (or a similar data connection) to the data network 175 via the first core network 130. Then, the first core network 130 uses the PDU session to relay traffic between the remote unit 105 and the remote host 180. As another example, the remote unit 105 may establish a PDN connection to the data network 175 via the second core network 140. Then, the second core network 140 uses the PDN connection to relay traffic between the remote unit 105 and the remote host 180.

[0044] The base station units 110 may be distributed over a geographical area. In certain embodiments, the base station units 110 may also be referred to as access terminals, access points, bases, base stations, Node Bs, eNBs, gNBs, home Node Bs, relay nodes, devices, or any other term used in the art. The base station units 110 are generally part of a radio access network (“RAN”), such as the first access network 120 (e.g., NG-RAN) and / or the second access network 125 (e.g., E-UTRAN), which may include one or more controllers communicatively coupled to one or more corresponding base station units 110. These and other elements in the radio access network are not illustrated, but are generally well known to those of ordinary skill in the art.

[0045] The base station unit 110 may serve multiple remote units 105 within a service area, such as a cell or a cell sector, via a wireless communication link 115. The base station unit 110 may communicate directly with one or more remote units 105 via communication signals. Generally, the base station unit 110 transmits downlink (“DL”) communication signals in the time domain, frequency domain, and / or spatial domain to serve the remote units 105. Additionally, the DL communication signals may be carried on the wireless communication link 115. The wireless communication link 115 may be any suitable carrier in licensed or unlicensed radio spectrum. The wireless communication link 115 facilitates communication between one or more remote units 105 and / or one or more base station units 110.

[0046] As depicted, wireless communication system 100 includes both a first core network 130 and a second core network 140. Here, the first core network 130 and the second core network 140 are part of the same PLMN. Each of the first core network 130 and the second core network 140 is associated with a different "system generation" of the mobile communication network. Additionally, some services are available in the first core network 130 but not in the second core network 140, and vice versa. Thus, in some cases, the remote unit 105 may need to fallback from the first core network 130 to the second core network 140 to access certain services.

[0047] The first core network 130 includes an Access and Mobility Management Function ("AMF") 131, SMF 133, UPF 135, and UDM 137. Additionally, the second core network 140 includes a Mobility Management Entity ("MME") 141, a Serving Gateway ("SGW") 143, a Packet Gateway ("PGW") 145, and a Home Subscriber Server ("HSS") 147. In some embodiments, the UDM 137 and the HSS 147 may be collocated and / or may be a single entity shared by the first core network 130 and the second core network 140. Although Figure 1 a specific number and type of network functions are described, those skilled in the art will recognize that any number and type of network functions may be included in the mobile core networks 130 and 140. Although the second core network 140 is depicted as including an IP Multimedia Subsystem ("IMS") 150, in other embodiments, the IMS 150 may be separate from the second core network 140.

[0048] In one embodiment, the first core network 130 is a fifth generation core network ("5GC"). Such a first core network 130 may be accessed using a New Radio ("NR") Radio Access Technology ("RAT") or an LTE RAT. In one embodiment, the second core network 140 is an Evolved Packet Core ("EPC") or a similar fourth generation core network. Such a second core network 140 may be accessed using an LTE RAT. In another embodiment, the second core network 140 is a UMTS core network or a similar third generation core network. Such a core network 140 may be accessed using an LTE RAT or a UTRA RAT.

[0049] While the fallback process is generally used to allow interoperability of various services used by the remote unit 105, traditional fallback processes involve a handover from the Packet Switched Domain ("PS domain") to the Circuit Switched Domain ("CS domain"). In some embodiments, the fallback process may involve a handover of one or more Packet Switched Sessions ("PS sessions"). In other embodiments, the fallback process does not handover PS sessions.

[0050] In a mobile communication network having a fifth generation core network (“5GC”) and supporting fifth generation radio access technology, there are many possible scenarios for the mobility of remote unit 105 between various radio access technologies and / or core networks. For example, the remote unit may switch from 5GC via NR RAT to 5GC via LTE RAT, which is referred to as RAT fallback. In another example, the remote unit 105 may switch from 5GC via LTE RAT to 5GC via NR RAT, which is referred to as inter-RAT handover. In a third example, the remote unit 105 may switch from 5GC via LTE RAT to EPC via LTE RAT, which is referred to as system (or CN) fallback. In a fourth example, the remote unit 105 may switch from 5GC via NR RAT to EPC via LTE RAT, which is also referred to as system (or CN) fallback. In a fifth example, the remote unit 105 may switch from 5GC via NR RAT to UMTS via UTRA, which is also referred to as system fallback. The following refers to Figures 2 - 4 Describe a process for facilitating RAT and / or CN mobility.

[0051] Previously, a fallback process was used to transfer the remote unit 105 from 4G (EPS) to the CS domain. However, when considering 5G systems, fallback for PS services is also possible, i.e., the fallback is from the PS domain to the PS domain. However, when following the conventional fallback process, the RAN node (e.g., base station unit 110) does not have available information to direct the remote unit 105 to the appropriate target RAT or target system (CN).

[0052] As known from the LTE specification (e.g., TS23.272), the RRC release process with a redirection indication is used to indicate information such as frequencies to be measured, location area ID (LAI), etc. to the remote unit 105. However, in a 5G scenario, this information may not be sufficient to direct the remote unit 105 to the appropriate target RAT or target system (CN). Additionally, it is important for the remote unit 105 to distinguish which target CN will be used, especially in the case of RAT fallback and inter-RAT handover, in order to initiate the correct NAS process in the target RAT.

[0053] To overcome the above limitations of the traditional fallback process, system 100 implements a new process that provides core network (CN) assistance information to the RAN node (e.g., gNB or base station unit 110) to allow the RAN node to make appropriate decisions regarding (1) the mobility mechanism (idle or connected mode mobility) and (2) the target RAT. In some embodiments, the CN assistance information also includes the target CN for the fallback if needed.

[0054] Specifically, the first core network 130 (e.g., AMF 131) provides the supported "mobility type" and the target CN (the latter in the case where the target RAT is E-UTRAN). In various embodiments, the target CN type is also provided to the remote unit 105 (e.g., via RRC signaling). In one alternative, the RAN node passes the target CN information to the UE. In another alternative, the target CN type can be provided from the AMF 131 to the remote unit 105 directly using NAS signaling.

[0055] In some embodiments, when requesting a service for possible RAT / system fallback (e.g., an emergency service), the remote unit 105 can additionally indicate to the first core network 130 (e.g., indicate to the AMF 131 in the NAS service request) whether the remote unit 105 operates in SR mode or DR mode.

[0056] Based on 1) a request from the remote unit 105 (e.g., a NAS service request message) and / or 2) based on network configuration (e.g., whether the N26 interface for 5GC / EPC interworking is deployed), and / or 3) based on service priority / latency requirements, the AMF 131 determines whether connected mode mobility (e.g., handover) or whether idle mode mobility (e.g., RRC release with redirection) is desirable.

[0057] As used herein, "idle mode mobility" refers to the RRC release procedure with a redirection IE. Idle mode mobility can be inter-RAT idle mobility (e.g., within the same CN) or inter-system idle mobility (e.g., changed CN). Similarly, as used herein, the term "connected mode mobility" is used to denote a handover procedure that can be inter-RAT handover (e.g., within the same CN) (e.g., based on Xn or based on N2 or based on S1, etc.) or inter-system handover (e.g., changing CN).

[0058] In response to determining the mobility mode, the AMF 131 indicates to the RAN node (e.g., the base station unit 110) in the N2 signaling message at least the following: the target CN (or a list of target CNs, including priorities), whether to use HO or IDLE mode mobility, and, optionally, the target RAT (e.g., a list, including priorities of different RATs).

[0059] The base station unit 110 sends the target CN (or a list of target CNs, including priorities) to the remote unit 105. In an alternative embodiment, the AMF 131 can indicate the target CN to the remote unit 105 in the NAS service accept message to the remote unit 105.

[0060] The RAN node (e.g., base station unit 110) makes a final decision on the target RAT for the fallback process considering the radio topology, radio conditions of the remote unit 105, and the indication received from the CN (e.g., from the AMF 131).

[0061] When it is decided not to perform radio handover because it cannot be executed (e.g., when there is no handover preparation through the target cell) or when it is inefficient (it will take longer than the time acceptable for some latency-critical services), the RAN node (e.g., base station unit 110) needs to indicate the target RAT and the target CN to the remote unit 105 in an RRC release message with a redirect IE. It should be noted that in some cases, RRC connection release with redirection may be faster than the handover process, especially if redirection can be blindly triggered, i.e., based on coverage information rather than on UE measurement reports.

[0062] Based on the information received by the remote unit 105 (e.g., information such as the target CN type and / or target RAT cell identifier, frequency, etc. in the NAS message or RRC message), the remote unit 105 initiates a NAS process using the NAS protocol according to the target CN indication and initiates an access stratum process to complete radio mobility in the target cell.

[0063] Figure 2 Depict a first fallback process 200 according to an embodiment of the present disclosure. The first fallback process 200 involves a UE 205, a RAN node 210, an AMF 131, an SMF 133, a UPF 135, and a second domain 215 of a PLMN. Here, the UE 205 falls back to the second domain 215. In one embodiment, the second domain includes IMS. In another embodiment, the second domain includes a circuit-switched network. The second domain 215 is located in a core network different from the AMF 131, SMF 133, and UPF 135 (although in the same PLMN).

[0064] A key aspect of the first fallback process 200 is that the serving core network (e.g., containing the AMF 131) provides auxiliary information to the RAN node 210 to allow the RAN NODE 210 to make appropriate decisions regarding the mobility mechanism (e.g., idle mode mobility versus connected mode mobility) and the target radio access technology (“RAT”) of the fallback process. The auxiliary information includes the target CN and optionally includes target cell information indicating at least one RAT. The target cell information may include frequency band, RAT, etc.

[0065] The UE 205 may be an embodiment of the remote unit 105 discussed above. The RAN node 210 may be an embodiment of the base station unit 110 discussed above. In some embodiments, the RAN node 210 is a gNB or an eNB. The second domain 215 may be an embodiment of the second core network 140 and / or the IMS 150.

[0066] The first fallback procedure 200 starts at step 0, where the UE 205 determines to initiate a service (MO service initiation) (see block 220). In one embodiment, the service to be initiated is an emergency service.

[0067] In step 1, the UE 205 sends a NAS service request to the AMF 131 (see the messaging 225). The UE 205 includes at least the following information in the NAS message: UE ID, the type of service requested (e.g., emergency, voice, PS voice (e.g., IMS voice) or CS voice), a request to fallback / move to another target system. In certain embodiments, the NAS service request message also indicates the SR / DR mode of operation of the UE 205.

[0068] Optionally, the UE 205 may indicate radio capabilities to the AMF 131, e.g., whether the UE 205 is capable of one-way transmission or capable of two-way transmission. Based on this UE 205 radio capability, the AMF 131 determines whether connected-mode mobility (e.g., handover procedure) is advisable or idle-mode mobility (e.g., RRC release with redirection) is advisable. Note that the term idle-mode mobility is used to denote the RRC release procedure with a redirection IE.

[0069] For example, the "request to fallback / move to another target system" may indicate to the network (e.g., the AMF 131 or the SMF 133) what the target system will be, e.g., EPS (if the UE 205 is currently connected to 5GS) or 5GS (if the UE 205 is currently connected to EPS).

[0070] In step 2, the AMF 131 can determine the target RAT (e.g., E-UTRAN, UTRAN, GERAN) and the target CN (e.g., in the case where the target RAT is E-UTRAN, the target CN can be EPC or 5GC) that support the requested service (see block 230). Additionally, the AMF 131 considers the network deployment (e.g., whether the N26 interface is supported) to facilitate the determination of whether connected mode mobility can be supported, or whether idle mode mobility is preferred. The AMF 131 indicates this information as the "mobility type" to the RAN node 210. For example, if a fallback to EPC and support for the N26 interface are required, connected mode mobility is preferred. However, if a fallback to EPC is required and the N26 is not supported, the AMF 131 can indicate that idle mode mobility is preferred.

[0071] In one embodiment, the target CN is indicated to the RAN node 210 or the UE 205 only when there may be ambiguity at the UE 205. For example, if the target RAT can be connected to multiple CNs, the target CN is indicated to the RAN / UE. In a specific example, if the target RAT is E-UTRAN (or referred to as LTE) and the LTE cell is connected to both EPC and 5GC, redirecting the UE 205 in the idle state to the LTE cell will cause ambiguity. One suggestion is that the AMF 131 decides to indicate the target CN type to the RAN node 210 or the UE 205 only when there is ambiguity about the CN to be used. In another example, if the target RAT is UTRAN (e.g., 3G), since the CN type is GPRS, there is no ambiguity about the target CN.

[0072] Since the AMF 131 generally does not know the exact coverage conditions of the potential target RAT, the AMF 131 can create a list of target RAT / CN based on preferences or a selection order. This preference list will guide the RAN node 210 (e.g., gNB) to make a decision about the target RAT based on the coverage conditions at the location of the UE 205 (e.g., depending on the radio measurements reported by the UE 205 to the source RAN node 210).

[0073] In addition, if the UE 205 is in the connected state, the AMF 131 may consider the service priority / delay requirements of the PDU session used by the UE 205 when creating fallback information to be sent to the RAN node 210. To this end, the AMF 131 may send information about the importance of the fallback procedure (e.g., priority or delay requirements) to the RAN node 210. For example, if the UE 205 is using a PDU session with packet delivery requirements for latency (e.g., UE 205 resources are activated), the AMF 131 may indicate to the RAN node 210 that the mobility procedure should meet the latency / priority requirements.

[0074] In step 3a, the AMF 131 sends an N2 request signaling message to the RAN node 210 (e.g., gNB) to request a fallback procedure for the UE 205. The AMF 131 additionally indicates at least one target CN type to which the UE 205 must fallback. The RAN node 210 obtains the target CN information to facilitate the selection of the correct cell on which to perform idle mode or connected mode procedures. The AMF 131 may indicate to the RAN node 210 at least one of the following fallback information: target RAT, target tracking area (TA), requested service, mobility type, and / or criticality requirements.

[0075] As used herein, "target RAT" refers to an indication that the UE 205 must be moved to at least one RAT to perform the requested service. "Target tracking area (TA)" refers to information that helps the RAN node 210 find an appropriate target cell that is part of the TA indicated by the CN. "Requested service" refers to the service that the UE 205 wants to use and that triggers the fallback or RAT / system change procedure. "Mobility type" refers to an indication that based on the configuration in the CN, connected mode mobility or idle mode mobility is preferred. For example, if the N26 interface is deployed, the AMF 131 may indicate that connected state mobility is desirable, and based on this, the AMF 131 may include the AS context to the gNB (e.g., AS security, MM context, radio capabilities, etc.). If, for example, the N26 interface is not deployed, the CN may indicate "idle mode mobility" or "RRC release similar with redirection" or a similar indication. "Criticality requirement" refers to an indication of the service priority / delay requirements of the PDU session currently used by the UE 205.

[0076] The RAN node 210 decides whether to perform idle mode mobility (e.g., perform an RRC release procedure with a redirection IE) or perform connected mode mobility (e.g., perform a handover procedure) based on the radio coverage of the UE 205 and based on the indication received from the AMF 131.

[0077] Step 3b shows the case where the RAN node 210 decides to perform idle mode mobility. The RAN node 210 performs an RRC release procedure and sends an RRC connection release message including target CN information to the UE 205 (see message transfer 235). In one embodiment, the RRC connection release message includes redirection information, which includes target CN information and optionally includes target RAN information.

[0078] Alternatively, when possible, regardless of whether measurements on the UE 205 are configured, the RAN node 210 initiates a handover procedure to the target RAT / CN. The latter case is a blind handover case. In the former case, the actual handover execution will be delayed until the UE 205 performs measurements and provides the results to the source RAT, which in turn prepares / notifies the target RAT. The target RAT is ready with a handover command and sends it to the UE 205 via the source RAT.

[0079] Step 3c shows the case where the RAN node 210 decides to perform connected mode mobility. The RAN node 210 may perform an RRC connection reconfiguration procedure to configure the UE 205 with measurements on the desired target cell (see message transfer 240). Next, the RAN node 210 initiates a handover procedure to the target RAT cell.

[0080] In step 4, the RAN node 210 sends an N2 request response message to the AMF 131 (see message transfer 245). If the RAN node 210 has decided to perform idle mode mobility, the RAN node 210 includes corresponding information indicating that the UE 205 has been redirected to a specific RAT to the AMF 131. However, if the RAN node 210 has decided to perform connected mode mobility, the RAN node 210 performs actions according to an Xn-based or N2-based handover procedure.

[0081] Based on whether the RAN node 210 selects idle mode mobility or connected mode mobility, the RAN 210 performs one of the following:

[0082] Step 5a: If the RAN node 210 has performed idle mode mobility, the AMF 131 determines whether to release the existing PDU session or retain the PDU session context in the CN but deactivate the UP resources (in the case where the UE 205 is already in a connected state and the UP resources have been activated; see block 250). For example, the AMF 131 may initiate an N11 exchange with the SMF 133 to release the PDU session UP resources. If the AMF 131 decides to retain the PDU session context in the 5GC, the AMF 131 may also indicate to the SMF 133 that the PDU session is temporarily suspended to avoid the SMF 133 initiating a paging procedure.

[0083] Step 5b: If the RAN node 210 has already performed connected mode mobility (e.g., handover procedure), the AMF 131 continues with the handover procedure (see block 255).

[0084] In step 6, the UE 205 initiates a NAS procedure in the target RAT using the NAS protocol based on the target CN indication received in the RRC message (e.g., EPC NAS or 5GCNAS) (see block 260). In some embodiments, the RRC message may indicate to the UE 205 that redirection may be performed for a specific CN type (e.g., 5GS or EPS) and in the target RAT cell. In such embodiments, the UE 205 uses the corresponding NAS protocol accordingly.

[0085] Furthermore, following the radio procedure that moves the UE 205 in the target RAT cell using, for example, the RRC idle or RRC inactive state cell redirection principle, the NAS protocol corresponding to the indicated CN type should be used. Figure 4 Shows the ASN.1 encoding of the CN type (e.g., 5GS or EPS) included in the RRC message that releases the RRC connection.

[0086] In step 7, the UE 205 emulates a service call in the target RAT and / or target CN (“target system”), herein described as the second domain 215 (see block 265). If idle mode mobility is performed and after the UE 205 completes the RRC procedure establishment in the target cell and performs NAS registration (or attachment) using the target CN, the UE 205 initiates the requested service (see block 270). Alternatively, the requested service may also be indicated during the NAS registration (or attachment) procedure. The first fallback procedure 200 ends.

[0087] Figure 3 Depicts a second fallback procedure 300 according to an embodiment of the present disclosure. The second fallback procedure 300 involves the UE 205, the RAN node 210, the AMF 131, the SMF 133, the UPF 135, and the second domain 215 of the PLMN. Herein, the UE 205 falls back to the second domain 215.

[0088] A key aspect of the second fallback procedure 300 is that the serving core network (e.g., including the AMF 131) provides the RAN node 210 with assistance information to allow the RAN node 210 to make appropriate decisions regarding mobility mechanisms (e.g., idle mode mobility versus connected mode mobility) and the target radio access technology (“RAT”) of the fallback procedure. The assistance information includes the target CN and optionally includes target cell information indicating at least one RAT. The target cell information may include frequency band, RAT, etc.

[0089] The second fallback procedure 300 starts at step 0, where the UE 205 determines to initiate a service (MO service initiation) (see block 305). In one embodiment, the service to be started is an emergency service.

[0090] In step 1, the UE 205 sends a NAS service request to the AMF 131 (see messaging 310). The UE 205 includes at least the following information in the NAS message: UE ID, the type of service requested (e.g., emergency, voice, PS voice (e.g., IMS voice) or CS voice), a request for fallback / movement to another target system. In some embodiments, the NAS service request message also indicates the SR / DR mode of operation of the UE 205.

[0091] Optionally, the UE 205 may indicate radio capabilities to the AMF 131, e.g., whether the UE 205 is capable of one-way transmission or capable of two-way transmission. Based on this UE 205 radio capability, the AMF 131 determines whether connection mode mobility (e.g., handover procedure) is advisable or idle mode mobility (e.g., RRC release with redirection) is advisable. Note that the term idle mode mobility is used to denote the RRC release procedure with a redirection IE.

[0092] The "request for fallback / movement to another target system" may indicate to the network (e.g., AMF 131 or SMF 133) which will be the target system, e.g., EPS (if the UE 205 is currently connected to 5GS) or 5GS (if the UE 205 is currently connected to EPS).

[0093] In step 2, the AMF 131 may determine the target RAT (e.g., E-UTRAN, UTRAN, GERAN) and the target CN (e.g., in the case where the target RAT is E-UTRAN, the target CN may be EPC or 5GC) that supports the requested service (see block 315). Additionally, the AMF 131 considers the network deployment (e.g., whether the N26 interface is supported) in order to determine whether connection mode mobility can be supported or whether idle mode mobility is preferred. The AMF 131 indicates this information as a "mobility type" to the RAN node 210. For example, if fallback to EPC is required and the N26 interface is supported, connection mode mobility is preferred. However, if fallback to EPC is required and the N26 is not supported, the AMF 131 may indicate that idle mode mobility is preferred.

[0094] In step 3a, the AMF 131 sends a NAS service request message containing the correct rejection cause value to the UE 205 (see message 320). For example, the rejection cause may indicate that the requested service is not supported. The AMF 131 may also indicate a list of possible RAT / CNs in which the requested service can be used. If the AMF 131 has detected that the target RAT can be connected to multiple CNs (e.g., in the case of E-UTRA), the AMF 131 may include an indication to the target CN of the UE 205. The target CN indicates which NAS protocol stack the UE 205 will use after the fallback process.

[0095] In step 3b, the AMF 131 sends an N2 request signaling message to the RAN node 210 (e.g., gNB) to request the fallback process of the UE 205 (see message transfer 325). The AMF 131 may indicate at least one of the following fallback information to the RAN node 210: target RAT, target tracking area (TA), requested service, mobility type, and / or criticality requirements. Note that the NAS service request message from step 3a can be encapsulated and sent in the same N2 message as step 3b. The RAN node 210 should process it accordingly and first deliver the encapsulated NAS message to the UE 205 before releasing the RRC connection.

[0096] The RAN node 210 decides whether to perform idle mode mobility (e.g., perform an RRC release process with a redirect IE) or connection mode mobility (e.g., perform a handover process) based on the radio coverage of the UE 205 and the indication received from the AMF 131.

[0097] Step 3c shows the case where the RAN node 210 decides to perform idle mode mobility. The RAN node 210 performs an RRC release process (see message transfer 330). Alternatively, if possible, regardless of whether measurements on the UE 205 are configured, the RAN node 210 initiates a handover process to the target RAT / CN.. The latter case is a blind handover case. In the former case, the actual handover execution will be delayed until the UE 205 performs measurements and provides the results to the source RAT, which in turn prepares / informs the target RAT. The target RAT is ready with a handover command and sends it to the UE 205 via the source RAT.

[0098] Step 3d shows the case where the RAN node 210 decides to perform connection mode mobility. The RAN node 210 may perform an RRC connection reconfiguration process to configure the UE 205 with measurements on the desired target cell (see message transfer 335). Next, the RAN node 210 initiates a handover process to the target RAT cell.

[0099] In step 4, the RAN node 210 sends an N2 request response message to the AMF 131 (see message transfer 340). If the RAN node 210 has decided to perform idle mode mobility, the RAN node 210 includes corresponding information indicating that the UE 205 has been redirected to a specific RAT to the AMF 131. However, if the RAN node 210 has decided to perform connected mode mobility, the RAN node 210 performs actions according to the Xn-based or N2-based handover procedure.

[0100] Based on whether the RAN node 210 selects idle mode mobility or connected mode mobility, the RAN 210 performs one of the following:

[0101] Step 5a: If the RAN node 210 has performed idle mode mobility, the AMF 131 determines whether to release the existing PDU session or retain the PDU session context in the CN, but deactivate the UP resources (in the case where the UE 205 is already in the connected state and the UP resources have been activated; see block 345). For example, the AMF 131 initiates an N11 exchange with the SMF 133 to release the PDU session UP resources. If the AMF 131 decides to retain the PDU session context in the 5GC, the AMF 131 may also indicate to the SMF 133 that the PDU session is temporarily suspended to avoid the SMF 133 initiating a paging procedure.

[0102] Step 5b: If the RAN node 210 has performed connected mode mobility (e.g., handover procedure), the AMF 131 continues with the handover procedure (see block 350).

[0103] In step 6, the UE 205 initiates a NAS procedure in the target RAT using the NAS protocol according to the target CN indication received in the NAS message (e.g., EPC NAS or 5GCNAS) (see block 355). In one possible option, the NAS message may indicate to the UE 205 that redirection can be performed for a specific CN type (e.g., 5GS or EPS) and in the target RAT cell, and the UE205 will use the corresponding NAS protocol accordingly.

[0104] In step 7, the UE 205 emulates a service call in the target RAT and / or target CN (“target system”), which is depicted here as the second domain 215 (see block 360). If idle mode mobility is performed and after the UE 205 completes the RRC procedure establishment in the target cell and performs NAS registration (or attachment) using the target CN, the UE 205 initiates the requested service. Alternatively, the requested service may also be indicated during the NAS registration (or attachment) procedure.

[0105] Figure 4 Depicts the RRC connection message 400 according to an embodiment of the present disclosure. The elements / parameters for conveying CN assistance information, such as those used in the fallback procedure described above, are shown in bold and italic.

[0106] Figure 5 Depicts an embodiment of a user equipment device 500 that can be used to provide fallback assistance information to a RAN node. The user equipment device 500 can be an embodiment of the remote unit 105. Additionally, the user equipment device 500 can include a processor 505, a memory 510, an input device 515, an output device 520, and a transceiver 525. In some embodiments, the input device 515 and the output device 520 are combined into a single device, such as a touch screen. In certain embodiments, the user equipment device 500 may not include any input device 515 and / or output device 520. In various embodiments, the user equipment device 500 can include one or more of the processor 505, the memory 510, and the transceiver 525, and may not include the input device 515 and / or the output device 520.

[0107] In one embodiment, the processor 505 can include any known controller capable of executing computer-readable instructions and / or capable of performing logical operations. For example, the processor 505 can be a microcontroller, a microprocessor, a central processing unit (“CPU”), a graphics processing unit (“GPU”), an auxiliary processing unit, a field programmable gate array (“FPGA”), or a similar programmable controller. In some embodiments, the processor 505 executes instructions stored in the memory 510 to perform the methods and routines described herein. The processor 505 is communicatively coupled to the memory 510, the input device 515, the output device 520, and the transceiver 525.

[0108] In some embodiments, the transceiver 525 sends a service request and receives a connection release message. Here, the service request requires a fallback to at least one of the following: a different RAT and a different CN. Additionally, the connection release message includes redirection information for service fallback, and the redirection information includes a target CN. The processor 505 selects a NAS procedure based on the target CN and uses the selected NAS procedure to connect to the target CN.

[0109] In some embodiments, the NAS procedure in the target CN is one of the following: an EPC NAS procedure and a 5GC NAS procedure. In various embodiments, the NAS procedure in the target CN includes initiating the requested service via the target CN. In certain embodiments, sending the service request includes indicating at least one of the following: the type of the requested service and the radio capabilities of the remote unit, and the radio capabilities include an indication of whether the remote unit has dual transmission capabilities.

[0110] In some embodiments, the redirection information further includes at least one target cell indicating at least one RAT. In certain embodiments, the indicated RAT is E-UTRAN, where the processor further provides the target CN to one or more upper layers.

[0111] In one embodiment, the memory 510 is a computer-readable storage medium. In some embodiments, the memory 510 includes volatile computer storage media. For example, the memory 510 may include RAM, which includes dynamic RAM ("DRAM"), synchronous dynamic RAM ("SDRAM"), and / or static RAM ("SRAM"). In some embodiments, the memory 510 includes non-volatile computer storage media. For example, the memory 510 may include a hard disk drive, a flash memory, or any other suitable non-volatile computer storage device. In some embodiments, the memory 510 includes both volatile and non-volatile computer storage media.

[0112] In some embodiments, the memory 510 stores data related to providing fallback assistance information to the RAN node. For example, the memory 510 may store target CN information, target RAT information, etc. In certain embodiments, the memory 510 also stores program code and related data, such as an operating system or other controller algorithms operating on the remote unit 105.

[0113] In one embodiment, the input device 515 may include any known computer input device, including a touch panel, buttons, a keyboard, a stylus, a microphone, etc. In some embodiments, the input device 515 may be integrated with the output device 520, for example, as a touch screen or a similar touch-sensitive display. In some embodiments, the input device 515 includes a touch screen such that a virtual keyboard displayed on the touch screen and / or text can be input by handwriting on the touch screen. In some embodiments, the input device 515 includes two or more different devices, such as a keyboard and a touch panel.

[0114] In one embodiment, the output device 520 is designed to output visual, auditory, and / or tactile signals. In some embodiments, the output device 520 includes an electronically controllable display or display device capable of outputting visual data to a user. For example, the output device 520 may include, but is not limited to, an LCD display, an LED display, an OLED display, a projector, or a similar display device capable of outputting images, text, etc. to the user. As another non-limiting example, the output device 520 may include a wearable display that is separate from the remainder of the user equipment device 500, such as a smartwatch, smart glasses, a heads-up display, etc., but is communicatively coupled to the remainder of the user equipment device 500. Additionally, the output device 520 may be a component of a smartphone, a personal digital assistant, a television, a desktop computer, a notebook (laptop) computer, a personal computer, a vehicle dashboard, etc.

[0115] In certain embodiments, the output device 520 includes one or more speakers for generating sound. For example, the output device 520 may generate an auditory alert or notification (e.g., a beep or a chime). In some embodiments, the output device 520 includes one or more haptic devices for generating vibration, movement, or other tactile feedback. In some embodiments, all or part of the output device 520 may be integrated with the input device 515. For example, the input device 515 and the output device 520 may form a touchscreen or a similar touch-sensitive display. In other embodiments, the output device 520 may be located near the input device 515.

[0116] The transceiver 525 includes at least a transmitter 530 and at least one receiver 535. One or more transmitters 530 may be used to communicate with RAN nodes, such as the base station unit 110. Although only one transmitter 530 and one receiver 535 are illustrated, the user equipment device 500 may have any suitable number of transmitters 530 and receivers 535. Additionally, the transceiver 525 may support one or more network interfaces 540. For example, the transceiver 525 may support a Uu interface for communicating with RAN nodes, an N1 interface for communicating with the AMF, etc.

[0117] Figure 6Describes an embodiment of a RAN device 600 that can be used to provide fallback assistance information to a RAN node. The RAN device 600 can be an embodiment of a base station unit 110 and / or a RAN node 210. Additionally, the RAN device 600 can include a processor 605, a memory 610, an input device 615, an output device 620, and a transceiver 625. In some embodiments, the input device 615 and the output device 620 are combined into a single device, such as a touch screen. In certain embodiments, the RAN device 600 may not include any input device 615 and / or output device 620. In various embodiments, the RAN device 600 can include one or more of the following: the processor 605, the memory 610, and the transceiver 625, and may not include the input device 615 and / or the output device 620.

[0118] In one embodiment, the processor 605 can include any known controller capable of executing computer-readable instructions and / or capable of performing logical operations. For example, the processor 605 can be a microcontroller, a microprocessor, a central processing unit (“CPU”), a graphics processing unit (“GPU”), an auxiliary processing unit, a field-programmable gate array (“FPGA”), or a similar programmable controller. In some embodiments, the processor 605 executes instructions stored in the memory 610 to perform the methods and routines described herein. The processor 605 is communicatively coupled to the memory 610, the input device 615, the output device 620, and the transceiver 625.

[0119] In various embodiments, the transceiver 625 receives a first message from a network function in a first core network, where the first message indicates a service fallback of a remote unit connected to the RAN node and indicates a target CN. The processor 605 determines service fallback parameters for the remote unit. Additionally, the transceiver 625 sends a connection release message to the remote unit, the connection release message including redirection information for the service fallback, the redirection information including the target CN.

[0120] In some embodiments, the redirection information further includes a target radio access technology RAT. In certain embodiments, the first message additionally includes RAN node information, where the RAN node information includes at least one of the following: UE security context and UE mobility restrictions.

[0121] In some embodiments, the first message includes a target RAT. In such embodiments, determining the service fallback parameters includes selecting a fallback RAT based on the target RAT and one or more of the radio topology and the radio conditions of the remote unit.

[0122] In some embodiments, the first message includes target fallback information, which includes one or more of the following: target radio access technology (“RAT”), target CN, target mobility type, service request of the remote unit that triggers service fallback, and critical requirements of the remote unit data connection.

[0123] In one embodiment, the memory 610 is a computer-readable storage medium. In some embodiments, the memory 610 includes volatile computer storage media. For example, the memory 610 may include RAM, which includes dynamic RAM (“DRAM”), synchronous dynamic RAM (“SDRAM”), and / or static RAM (“SRAM”). In some embodiments, the memory 610 includes non-volatile computer storage media. For example, the memory 610 may include a hard disk drive, a flash memory, or any other suitable non-volatile computer storage device. In some embodiments, the memory 610 includes both volatile and non-volatile computer storage media.

[0124] In some embodiments, the memory 610 stores data related to providing fallback assistance information to the RAN node. For example, the memory 610 may store target CN information, target RAT information, etc. In certain embodiments, the memory 610 also stores program code and related data, such as an operating system or other controller algorithms operating on the remote unit 105.

[0125] In one embodiment, the input device 615 may include any known computer input device, which includes a touch panel, buttons, a keyboard, a stylus, a microphone, etc. In some embodiments, the input device 615 may be integrated with the output device 620, for example, as a touch screen or a similar touch-sensitive display. In some embodiments, the input device 615 includes a touch screen such that a virtual keyboard displayed on the touch screen and / or text can be input by handwriting on the touch screen. In some embodiments, the input device 615 includes two or more different devices, such as a keyboard and a touch panel.

[0126] In one embodiment, output device 620 is designed to output visual, auditory, and / or tactile signals. In some embodiments, output device 620 includes an electronically controllable display or display device capable of outputting visual data to a user. For example, output device 620 may include, but is not limited to, an LCD display, an LED display, an OLED display, a projector, or a similar display device capable of outputting images, text, etc. to the user. As another non-limiting example, output device 620 may include a wearable display that is separate from the remainder of RAN device 600 but communicatively coupled to the remainder of RAN device 600, such as a smartwatch, smart glasses, a head-up display, and the like. Additionally, output device 620 may be a component of a smartphone, a personal digital assistant, a television, a desktop computer, a notebook (laptop) computer, a personal computer, a vehicle dashboard, etc.

[0127] In certain embodiments, output device 620 includes one or more speakers for generating sound. For example, output device 620 may generate an auditory alarm or notification (e.g., a beep or a chime). In some embodiments, output device 620 includes one or more haptic devices for generating vibration, movement, or other tactile feedback. In some embodiments, all or part of output device 620 may be integrated with input device 615. For example, input device 615 and output device 620 may form a touchscreen or a similar touch-sensitive display. In other embodiments, output device 620 may be located near input device 615.

[0128] Transceiver 625 includes at least one transmitter 630 and at least one receiver 635. One or more transmitters 630 may be used to provide DL communication signals to remote unit 105. Similarly, one or more receivers 635 may be used to receive UL communication signals from remote unit 105, as described herein. Although only one transmitter 630 and one receiver 635 are illustrated, RAN device 600 may have any suitable number of transmitters 630 and receivers 635. Additionally, transmitter 625 and receiver 630 may be any suitable type of transmitter and receiver. In one embodiment, transceiver 625 includes a transmitter / receiver pair for communicating with a mobile communication network including a first core network 130 and a second core network 140. Additionally, transceiver 625 may support one or more network interfaces 640. For example, transceiver 625 may support a Uu interface for communicating with a UE, an N2 interface for communicating with an AMF, etc.

[0129] Figure 7Describes an embodiment of a network function device 700 that can be used to provide fallback assistance information to a RAN node. The network function device 700 can be an embodiment of the remote unit 105. In addition, the network function device 700 can include a processor 705, a memory 710, an input device 715, an output device 720, and a transceiver 725. In some embodiments, the input device 715 and the output device 720 are combined into a single device, such as a touch screen. In certain embodiments, the network function device 700 may not include any input device 715 and / or output device 720. In various embodiments, the network function device 700 can include one or more of the following: the processor 705, the memory 710, and the transceiver 725, and may not include the input device 715 and / or the output device 720.

[0130] In one embodiment, the processor 705 can include any known controller capable of executing computer-readable instructions and / or capable of performing logical operations. For example, the processor 705 can be a microcontroller, a microprocessor, a central processing unit (“CPU”), a graphics processing unit (“GPU”), an auxiliary processing unit, a field-programmable gate array (“FPGA”), or a similar programmable controller. In some embodiments, the processor 705 executes the instructions stored in the memory 710 to perform the methods and routines described herein. The processor 705 is communicatively coupled to the memory 710, the input device 715, the output device 720, and the transceiver 725.

[0131] In some embodiments, the transceiver 725 receives a service request from the remote unit, where the service request requires fallback to at least one of the following: a different RAT and a different CN. The processor 705 identifies at least one of a target RAT and a target CN based on at least one of the requested service, the remote unit capabilities, and the network configuration. In addition, the transceiver 725 indicates to the RAN node at least one of the following: the target RAT and the target CN, where the RAN node performs a fallback process through the remote unit based on at least one of the following: the target RAT and the target CN. Here, performing the fallback process includes one of the following:

[0132] In some embodiments, the service request indicates that the remote unit requests emergency service fallback. In certain embodiments, indicating at least one of the following: the target RAT and the target CN includes sending at least one of the following: a list of optimized target RATs and a list of optimized CNs.

[0133] In some embodiments, the transceiver 725 further sends a signaling message with fallback information to the RAN node, where the fallback information includes at least one of the following: a target RAT, a target tracking area, a requested service, a mobility type, and service requirements for a data connection used by the remote unit. In such an embodiment, the mobility type indicates the idle mode mobility of the remote unit, the transceiver receives an acknowledgment message from the RAN node, and the processor, in response to the acknowledgment message, performs one of the following: releases the data connection used by the remote unit, suspends the data connection used by the remote unit, and switches the data connection used by the remote unit.

[0134] In one embodiment, the memory 710 is a computer-readable storage medium. In some embodiments, the memory 710 includes a volatile computer storage medium. For example, the memory 710 may include RAM, which includes dynamic RAM (“DRAM”), synchronous dynamic RAM (“SDRAM”), and / or static RAM (“SRAM”). In some embodiments, the memory 710 includes a non-volatile computer storage medium. For example, the memory 710 may include a hard disk drive, a flash memory, or any other suitable non-volatile computer storage device. In some embodiments, the memory 710 includes both volatile and non-volatile computer storage media.

[0135] In some embodiments, the memory 710 stores data related to providing fallback assistance information to the RAN node. For example, the memory 710 may store target CN information, target RAT information, etc. In certain embodiments, the memory 710 also stores program code and related data, such as an operating system or other controller algorithms operating on the remote unit 105.

[0136] In one embodiment, the input device 715 may include any known computer input device, which includes a touch panel, buttons, a keyboard, a stylus, a microphone, etc. In some embodiments, the input device 715 may be integrated with the output device 720, for example, as a touch screen or a similar touch-sensitive display. In some embodiments, the input device 715 includes a touch screen such that a virtual keyboard displayed on the touch screen and / or text can be input by handwriting on the touch screen can be used. In some embodiments, the input device 715 includes two or more different devices, such as a keyboard and a touch panel.

[0137] In one embodiment, output device 720 is designed to output visual, auditory, and / or tactile signals. In some embodiments, output device 720 includes an electronically controllable display or display device capable of outputting visual data to a user. For example, output device 720 may include, but is not limited to, an LCD display, an LED display, an OLED display, a projector, or a similar display device capable of outputting images, text, etc. to a user. As another non-limiting example, output device 720 may include a wearable display that is separate from the remainder of network function device 700 but communicatively coupled to the remainder of network function device 700, such as a smartwatch, smart glasses, a heads-up display, etc. Additionally, output device 720 may be a component of a smartphone, a personal digital assistant, a television, a desktop computer, a notebook (laptop) computer, a personal computer, a vehicle dashboard, etc.

[0138] In certain embodiments, output device 720 includes one or more speakers for generating sound. For example, output device 720 may generate an audible alert or notification (e.g., a beep or a chime). In some embodiments, output device 720 includes one or more haptic devices for generating vibration, movement, or other tactile feedback. In some embodiments, all or part of output device 720 may be integrated with input device 715. For example, input device 715 and output device 720 may form a touchscreen or a similar touch-sensitive display. In other embodiments, output device 720 may be located near input device 715.

[0139] Transceiver 725 includes at least one transmitter 730 and at least one receiver 735. One or more transmitters 730 and one or more receivers 735 are used to communicate with a base station unit 110 such as RAN node 210 and / or with other network functions in the core network. Although only one transmitter 730 and one receiver 735 are illustrated, network function device 700 may have any suitable number of transmitters 730 and receivers 735. Additionally, transmitter 725 and receiver 730 may be any suitable type of transmitter and receiver. Additionally, transceiver 725 may support one or more network interfaces 740. For example, transceiver 725 may support an N1 interface for communicating with a UE, an N11 interface for communicating with an SMF, etc.

[0140] Figure 8Depict method 800 for determining the transport block generation timing of uplink transmissions according to embodiments of the present disclosure. In some embodiments, method 1000 is performed by a device such as remote unit 105, UE 205, and / or user equipment device 500. In certain embodiments, method 800 may be performed by a processor executing program code, e.g., a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, an FPGA, etc.

[0141] Method 800 begins and a service request is sent 805 by the remote unit, where the service request requests a fallback to at least one of the following: a different RAT and a different CN. In certain embodiments, sending 805 the service request includes indicating at least one of the following: the type of service requested and the radio capabilities of the remote unit, where the radio capabilities include an indication of whether the remote unit is capable of dual transmission.

[0142] Method 800 includes receiving 810 a connection release message at the remote unit, where the connection release message includes redirection information for service fallback, and the redirection information includes a target CN. In some embodiments, the redirection information further includes target cell information indicating at least one RAT. In certain embodiments, the indicated RAT is E-UTRAN.

[0143] Method 800 includes selecting 815 a NAS procedure based on the target CN.

[0144] Method 800 includes connecting 820 to the target CN using the selected NAS procedure. Method 800 ends. In some embodiments, the NAS procedure in the target CN may be one of the following: an EPC NAS procedure and a 5GC NAS procedure. In various embodiments, the NAS procedure in the target CN may include initiating the requested service via the target CN.

[0145] Figure 9 Depict method 900 for determining the transport block generation timing of uplink transmissions according to embodiments of the present disclosure. In some embodiments, method 1000 is performed by a device such as base station unit 110, RAN node 210, and / or RAN device 600. In certain embodiments, method 900 may be performed by a processor executing program code, e.g., a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, an FPGA, etc.

[0146] Method 900 begins and at a RAN node receives 905 a first message from a network function in a first core network, where the first message indicates a service fallback of a remote unit connected to the RAN node and indicates a target CN. In some embodiments, the first message additionally includes RAN node information, where the RAN node information includes at least one of the following: UE security context and UE mobility restrictions. In some embodiments, the first message includes target fallback information, which includes one or more of the following: target RAT, target CN, target mobility type, a service request of the remote unit that triggers the service fallback, and critical requirements of the remote unit data connection.

[0147] Method 900 includes determining 910 service fallback parameters for the remote unit. In some embodiments, determining the service fallback parameters includes selecting a fallback RAT based on the target RAT and one or more of the following: radio topology and radio conditions of the remote unit.

[0148] Method 900 includes sending 915 a connection release message to the remote unit, where the connection release message includes redirection information for service fallback. Here, the redirection information includes the target CN. In some embodiments, the redirection information further includes at least the target RAT.

[0149] Figure 10 Disclosed is a method 1000 for determining the transport block generation timing of an uplink transmission according to an embodiment of the present disclosure. In some embodiments, method 1000 is performed by a device such as AMF 131 and / or network function device 700. In some embodiments, method 1000 may be performed by a processor executing program code, such as a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, an FPGA, etc.

[0150] Method 1000 begins and at a network function part of a first core network receives 1005 a service request from a remote unit, where the service request is a service request to fallback to at least one of the following: a different RAT and another CN. In some embodiments, the service request indicates that the remote unit requests an emergency service fallback.

[0151] Method 1000 includes identifying 1010 at least one of a target RAT and a target CN at the network function based on at least one of the requested service, remote unit capabilities, and network configuration.

[0152] Method 1000 includes indicating 1015 to a RAN node at least one of a target RAT and a target CN based on a requested service, wherein the RAN node performs a fallback via a remote unit based on at least one of the following: the target RAT and the target CN. In some embodiments, indicating at least one of the following: the target RAT and the target CN includes sending at least one of the following: an optimized list of target RATs and an optimized list of CNs. In some embodiments, a network function sends a signaling message with fallback information to the RAN node, wherein the fallback information includes at least one of the following: the target RAT, the target tracking area, the requested service, the mobility type, and the service requirements of the data connection used by the remote unit.

[0153] Disclosed herein is a first apparatus for providing fallback assistance information. The first apparatus may be an embodiment of the remote unit 105, the UE 205, and / or the user equipment apparatus 500. The first apparatus includes a transceiver that sends a service request and receives a connection release message. Here, the service request requests a fallback to at least one of the following: a different RAT and a different CN. Further, the connection release message includes redirection information for service fallback, and the redirection information includes the target CN. The first apparatus includes a processor that selects a NAS procedure based on the target CN and uses the selected NAS procedure to connect to the target CN.

[0154] In some embodiments, the NAS procedure in the target CN is one of the following: an EPC NAS procedure and a 5GC NAS procedure. In various embodiments, the NAS procedure in the target CN includes initiating the requested service via the target CN. In some embodiments, sending the service request includes indicating at least one of the following: the type of the requested service of the remote unit and the radio capabilities, and the radio capabilities include an indication of whether the remote unit is capable of dual transmission.

[0155] In some embodiments, the redirection information further includes at least one target cell indicating at least one RAT. In some embodiments, the indicated RAT is E-UTRAN, and the processor further provides the target CN to one or more upper layers.

[0156] Disclosed herein is a first method for providing fallback assistance information. The first method may be implemented by the remote unit 105, the UE 205, and / or the user equipment apparatus 500. The first method includes sending, by the remote unit, a service request, wherein the service request requires a fallback to at least one of the following: a different RAT and a different CN. The first method includes receiving, at the remote unit, a connection release message, wherein the connection release message includes redirection information for service fallback, and the redirection information includes the target CN. The first method includes selecting a NAS procedure based on the target CN. The first method includes using the selected NAS procedure to connect to the target CN.

[0157] In some embodiments, the NAS procedure in the target CN can be one of the following: an EPC NAS procedure and a 5GCNAS procedure. In various embodiments, the NAS procedure in the target CN can include initiating the requested service via the target CN. In certain embodiments, sending a service request includes indicating at least one of the following: the type of the requested service of the remote unit and the radio capabilities, where the radio capabilities include an indication of whether the remote unit is capable of dual transmission.

[0158] In some embodiments, the redirection information further includes target cell information indicating at least one RAT. In certain embodiments, the indicated RAT is E-UTRAN. In such an embodiment, the first method further includes providing the target CN to one or more upper layers in the remote unit.

[0159] Disclosed herein is a second apparatus for providing fallback assistance information. The second apparatus can be an embodiment of the base station unit 110, the RAN node 210, and / or the RAN apparatus 600. The second apparatus includes a transceiver that receives a first message from a network function in a first core network, where the first message indicates a service fallback of a remote unit connected to the RAN node and indicates the target CN. The second apparatus further includes a processor that determines service fallback parameters for the remote unit. In addition, the transceiver sends a connection release message to the remote unit, the connection release message including redirection information for the service fallback, the redirection information including the target CN.

[0160] In some embodiments, the redirection information further includes a target radio access technology (“RAT”). In certain embodiments, the first message additionally includes RAN node information, where the RAN node information includes at least one of the following: UE security context and UE mobility restrictions.

[0161] In some embodiments, the first message includes a target RAT. In such an embodiment, determining the service fallback parameters includes selecting a fallback RAT based on the target RAT and one or more of the radio topology and the radio conditions of the remote unit.

[0162] In some embodiments, the first message includes target fallback information, the target fallback information including one or more of the following: a target radio access technology (“RAT”), a target CN, a target mobility type, a service request of the remote unit that triggers the service fallback, and criticality requirements of the data connection of the remote unit.

[0163] The present disclosure discloses a second method for providing fallback assistance information. The second method may be implemented by the base station unit 110, the RAN node 210, and / or the RAN device 600. The second method includes receiving, at the RAN node, a first message from a network function in a first core network, where the first message indicates a service fallback of a remote unit connected to the RAN node and indicates a target CN. The second method includes determining service fallback parameters for the remote unit and sending a connection release message to the remote unit, where the connection release message includes redirection information for the service fallback. Here, the redirection information includes the target CN.

[0164] In some embodiments of the second method, the redirection information further includes at least a target RAT. In certain embodiments, the first message additionally includes RAN node information, where the RAN node information includes at least one of the following: UE security context and UE mobility restrictions.

[0165] In some embodiments of the second method, the first message includes a target RAT. In such embodiments, determining the service fallback parameters includes selecting a fallback RAT based on the target RAT and one or more of radio topology and radio conditions of the remote unit. In certain embodiments, the first message includes target fallback information, where the target fallback information includes one or more of the following: target RAT, target CN, target mobility type, service request of the remote unit triggering the service fallback, and critical requirements of the remote unit data connection.

[0166] The present disclosure discloses a third device for providing fallback assistance information. The third device may be an embodiment of the AMF 131 and / or the network function device 700. The third device includes a transceiver that receives a service request from a remote unit, where the service request requires a fallback to at least one of the following: a different RAT and a different CN. The third device includes a processor that identifies at least one of a target RAT and a target CN based on at least one of the requested service, remote unit capabilities, and network configuration. Additionally, the transceiver indicates to the RAN node at least one of the following based on the requested service: target RAT and target CN, where the RAN node performs a fallback process through the remote unit based on at least one of the following: target RAT and target CN. Here, performing the fallback process includes one of the following:

[0167] In some embodiments, the service request indicates that the remote unit requires an emergency service fallback. In certain embodiments, indicating at least one of the target RAT and the target CN includes sending at least one of the following: an optimized list of target RATs and an optimized list of CNs.

[0168] In some embodiments, the transceiver also sends a signaling message with fallback information to the RAN node, where the fallback information includes at least one of the following: a target RAT, a target tracking area, a requested service, a mobility type, and service requirements for a data connection used by the remote unit.

[0169] In such an embodiment, the mobility type indicates the idle mode mobility of the remote unit, the transceiver receives an acknowledgment message from the RAN node, and the processor, in response to the acknowledgment message, performs one of the following: releases the data connection used by the remote unit, suspends the data connection used by the remote unit, and switches the data connection used by the remote unit.

[0170] A third method for providing fallback assistance information is disclosed herein. The third method may be implemented by the AMF 131 and / or the network function device 700. The third method includes receiving, at a network function portion of a first core network, a service request from a remote unit, where the service request is a request for a service to fallback to at least one of the following: a different RAT and a different CN. The third method includes identifying, at the network function, at least one of a target RAT and a target CN based on at least one of the requested service, remote unit capabilities, and network configuration. The third method includes indicating, to the RAN node, at least one of the target RAT and the target CN based on the requested service, where the RAN node performs a fallback via the remote unit based on at least one of the following: the target RAT and the target CN.

[0171] In some embodiments, the service request indicates that the remote unit requests an emergency service fallback. In certain embodiments, indicating at least one of the target RAT and the target CN includes sending at least one of the following: an optimized list of target RATs and an optimized list of CNs.

[0172] In some embodiments, the third method includes sending a signaling message with fallback information to the RAN node, where the fallback information includes at least one of the following: a target RAT, a target tracking area, a requested service, a mobility type, and service requirements for a data connection used by the remote unit.

[0173] In such an embodiment, the mobility type indicates the idle mode mobility of the remote unit, where the method further includes receiving an acknowledgment message from the RAN node and performing an action in response to the acknowledgment message, the action being one of the following: releasing the data connection used by the remote unit, suspending the data connection used by the remote unit, and switching the data connection used by the remote unit.

[0174] The embodiments may be practiced in other specific forms. The described embodiments are to be considered in all respects only as illustrative and not restrictive. Thus, the scope of the invention is indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.

Claims

1. A method performed by a user equipment ("UE"), the method comprising: sending a service request, the service request indicating a service type requiring fallback to at least one of the following: different radio access technologies ("RATs") and different generations of systems; receiving a connection release message, the connection release message including redirection information for service fallback, wherein the redirection information indicates a target RAT cell and a target system; performing a NAS procedure from among a plurality of non-access stratum ("NAS") supported by the UE, wherein the NAS procedure is based on the target system; and wherein a connection to the target RAT cell and the target system is established based on the NAS procedure.

2. The method according to claim 1, wherein, the NAS procedure based on the target system is one of the following: an evolved packet core ("EPC") NAS procedure and a fifth generation core ("5GC") NAS procedure.

3. The method according to claim 1, wherein, performing the NAS procedure includes initiating the requested service via the target system.

4. The method according to claim 1, wherein, the redirection information further indicates target cell information of at least one RAT.

5. The method according to claim 1, wherein, the target RAT cell is an evolved universal terrestrial radio access network ("E-UTRAN"), and the method further includes providing the target system to one or more upper layers in the UE.

6. A method performed by a radio access network ("RAN") node, comprising: receiving a first message from a network function, wherein the first message indicates service fallback of a user equipment ("UE") connected to the RAN node and indicates a target system; creating service fallback parameters for the UE, wherein the target system is used to perform one of the following: inter-RAT redirection and inter-system redirection, and if the target system is different from the current system of the UE, then inter-system redirection is triggered; and sending a connection release message to the UE, wherein the connection release message includes redirection information for service fallback, wherein the redirection information indicates a target radio access technology ("RAT") cell and a target system.

7. The method according to claim 6, further comprising: forwarding a service request to the network function, wherein the service request indicates a need for service fallback.

8. The method according to claim 6, wherein, the first message further includes RAN node information, and wherein the RAN node information includes at least one of the following: UE security context and UE mobility restrictions.

9. The method according to claim 6, wherein, the first message indicates the target RAT cell, and wherein creating the service fallback parameters includes selecting a fallback RAT based on the target RAT cell and one or more of radio topology and radio conditions of the UE.

10. The method according to claim 6, wherein, The first message includes target fallback information, where the target fallback information includes one or more of the following: the target RAT cell, the target system, the target core network ("CN"), the target mobility type, the service request of the UE that triggers the service fallback, or the critical requirements of the UE's data connection.

11. A radio access network ("RAN") node, comprising: a transceiver that receives a first message from a network function, where the first message indicates a service fallback of a user equipment ("UE") connected to the RAN node and indicates a target system; a processor that creates service fallback parameters for the UE, where the target system is used to perform one of the following: inter-RAT redirection and inter-system redirection, and where if the target system is different from the UE's current system, an inter-system redirection is triggered; and where the transceiver sends a connection release message to the UE, where the connection release message includes redirection information for service fallback, and where the redirection information indicates a target radio access technology ("RAT") cell and a target system.

12. The RAN node according to claim 11, wherein the first message indicates a target RAT cell, and where, to create the service fallback parameters, the processor selects a fallback RAT based on the target RAT cell and one or more of radio topology and the UE's radio conditions.

13. The RAN node according to claim 11, wherein the first message includes target fallback information, and where the target fallback information includes one or more of the following: a target RAT cell, the target system, the target core network ("CN"), the target mobility type, the service request of the UE that triggers the service fallback, or the critical requirements of the UE's data connection.

14. The RAN node according to claim 11, wherein the first message further includes RAN node information, and where the RAN node information includes at least one of the following: UE security context and UE mobility restrictions.

15. A method performed by a network function, the method comprising: receiving a service request associated with a user equipment ("UE"), where the service request is for a service fallback to at least one of the following: a different radio access technology ("RAT") and a different system; and indicating to a radio access network ("RAN") at least one of the following: a target RAT or a target system, based on the requested type of the service request or based on network configuration, where the fallback is performed based on at least one of the following: the target RAT and the target system.

16. The method according to claim 15, wherein the service request indicates that the UE requires an emergency service fallback.

17. The method according to claim 15, wherein Indicating that at least one of the target RAT or the target system includes transmitting at least one of the following: a prioritized list of the target RAT or a prioritized list of the system.

18. The method according to claim 15, further comprising sending a signaling message to the RAN node using fallback information, where the fallback information includes at least one of the following: the target RAT, the target tracking area, a service request, a mobility type, and service requirements for a data connection of the UE.

19. The method according to claim 18, wherein, the mobility type indicates the idle mode mobility of the UE, and the method further comprises: receiving an acknowledgment message from the RAN node; and performing an action in response to the acknowledgment message, the action being one of the following: releasing the data connection of the UE, suspending the data connection of the UE, or switching the data connection of the UE.

20. A network function device, comprising: a transceiver that receives a service request associated with a user equipment ("UE"), where the service request is for requesting a service to fallback to at least one of the following: a different radio access technology ("RAT") and a different system; and the transceiver indicates to a radio access network ("RAN") at least one of the following based on the requested type of the service request or based on a network configuration: a target RAT or a target system, where the fallback is performed based on at least one of the following: the target RAT and the target system.

21. A user equipment ("UE"), comprising: a transceiver that sends a service request indicating a service type for requesting a fallback to at least one of the following: a different radio access technology ("RAT") and different generations of systems; the transceiver receives a connection release message that includes redirection information for service fallback, where the redirection information indicates a target RAT cell and a target system; and a processor that executes a NAS process from among a plurality of non-access stratum ("NAS") supported by the UE, where the NAS process is based on the target system; where a connection to the target RAT cell and the target system is established based on the NAS process.

Images