Patent Description:
The following abbreviations are herewith defined, at least some of which are referred to within the following description: Third Generation Partnership Project ("3GPP"), Positive-Acknowledgment ("ACK"), Autonomous Uplink ("AUL"), AUL Downlink Feedback Information ("AUL-DFI"), Binary Phase Shift Keying ("BPSK"), Clear Channel Assessment ("CCA"), Cyclic Prefix ("CP"), Cyclical 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 Equipment ("FBE"), Frequency Division Duplex ("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 Equipment ("LBE"), Listen-Before-Talk ("LBT"), Long Term Evolution ("LTE"), Multiple Access ("MA"), Modulation Coding Scheme ("MCS"), Machine Type Communication ("MTC"), Multiple Input Multiple Output ("MIMO"), Multi User Shared Access ("MUSA"), Narrowband ("NB"), Negative-Acknowledgment ("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 Spread 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 Multiplex ("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-reliability and Low-latency Communications ("URLLC"), and Worldwide Interoperability for Microwave Access ("WiMAX"). As used herein, "HARQ-ACK" may represent collectively the Positive Acknowledge ("ACK") and the Negative Acknowledge ("NACK"). ACK means that a TB is correctly received while NACK (or NAK) means a TB is erroneously received.

In certain wireless communications networks, a UE operating in a mobile communication network requires a change to different system, such as different network core (e.g., system generation) and/or radio access technology in order to receive the service in the mobile communication network. Fallback procedures are commonly used to allow interoperability of various services used by the remote unit <NUM>, conventional fallback procedures involve the switch from a packet-switched domain ("PS-domain") to a circuit-switched domain ("CS-domain"). Moreover, conventional fallback procedures failed to inform the RAN and UE of target systems and RATS, thereby leading to situations where the UE may connect to the wrong system during the fallback procedure.

<CIT> discloses methods, apparatus and systems using Enhanced Dedicated Core Network (DCN) selection. One method includes receiving, by the core network entity from another core network entity, information indicating that a DCN type is new or has changed for a wireless transmit/receive unit (WTRU); and sending a message, by the core network entity to the WTRU, including a new or a changed DCN type. <NPL> defines the Stage <NUM> service description for EPS, and covers both roaming and non-roaming scenarios and covers all aspects, including mobility between E-UTRAN and pre-E-UTRAN 3GPP radio access technologies. <CIT> defines a method performed by a mobility management entity (MME) to redirect a wireless transmit receive unit (WTRU) to a dedicated core network (CN) node; received pushed subscription information may include a CN node type parameter that indicates a dedicated CN node type. <NPL>, and discusses the signaling procedure for intra-cell handover with CN type change. <NPL>; this discusses how the CN type can be determined for intra-LTE handover with CN type change. <CIT> describes enhancing circuit-switched call fallback (CSFB) service for a shared network node.

Claim <NUM> defines a method performed by a user equipment, UE, claim <NUM> defines a UE, claim <NUM> defines a method performed by a radio access network node and claim <NUM> defines a radio access network node.

Code for carrying out operations for embodiments may be any number of lines and may be written in any combination of one or more programming languages including an object-oriented programming language such as Python, Ruby, Java, Smalltalk, C++, or the like, and conventional procedural programming languages, such as the "C" programming language, or the like, and/or machine languages such as assembly languages.

The code may be provided to a processor of a general-purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the schematic flowchart diagrams and/or schematic block diagrams block or blocks.

Disclosed herein are methods for service fallback procedure including the steps of: the CN providing fallback assistance information to the RAN node (e.g., a gNB), and the RAN node deciding about (<NUM>) the mobility mechanism (IDLE or CONNECTED mode mobility) and (<NUM>) the target RAT, and if needed, target CN for the fallback procedure. Here, the fallback assistance information may include type of mobility (e.g., whether CONNECTED mode or IDLE mode mobility is preferred based on the configuration in the CN) and/or target core network(s) and/or Criticality requirements. Note that if the RAN node performs IDLE state mobility, then the UE considers the indicated target core network when initiating NAS procedure in the target cell. In various embodiments, the NAS procedure in the target CN may either <NUM>) implicit include also a request for the particular service; or <NUM>) be an independent NAS procedure for the requested service.

In one example, the UE has a pending IMS emergency session request (e.g., voice) from the upper layers. If the AMF has indicated support for emergency services using fallback via the Registration Accept message for the current RAT, then the UE sends a Service Request message indicating that it requires emergency services fallback.

After receiving the Service Request for Emergency Fallback, the AMF triggers N2 procedure resulting in either CONNECTED state mobility (Handover procedure) or IDLE state mobility (redirection) to either E-UTRA/5GC or to E-UTRAN/EPC depending on factors such as N26 availability, network configuration and radio conditions. Here, the 5GC triggers a request for Emergency Services Fallback by executing an NG-AP procedure in which it indicates to NG-RAN that this is a fallback for emergency services. In the N2 procedure, the AMF, based on the support of Emergency Services in EPC or 5GC, may indicate the target CN for the RAN node to know whether inter-RAT fallback or inter-system fallback is to be performed. The target CN indicated in the N2 procedure is also conveyed to the UE in order to be able to perform the appropriate NAS procedures (S1 or N1 Mode). When AMF initiates Redirection for UE(s) that have been successfully authenticated, AMF includes the security context in the request to trigger fallback towards NG-RAN.

Based on the target CN indicated in the N2 request for Emergency Fallback, one of the following procedures is executed by NG-RAN: (<NUM>) if UE is currently camped on NR, then the NG-RAN performs fallback (e.g., initiates handover or redirection) to a 5GC-connected E-UTRAN cell; or (<NUM>) the NG-RAN initiates handover or redirection to E-UTRAN connected to EPS. Here, the NG-RAN uses the security context provided by the AMF to secure the redirection procedure. One example of performing fallback includes the NG-RAN initiating handover or redirection to E-UTRAN.

Note that if the redirection procedure is used, then the target CN is also conveyed to the UE in order to be able to perform the appropriate NAS procedures (S1 or N1 Mode). After handover to the target cell the UE establishes a PDU Session / PDN connection for IMS emergency services and performs the IMS procedures for establishment of an IMS emergency session (e.g., voice).

<FIG> depicts an embodiment of a wireless communication system <NUM> for providing fallback assistance information to a RAN node. In one embodiment, the wireless communication system <NUM> includes at least one remote unit <NUM>, a first access network <NUM> containing at least one base unit <NUM>, a second access network <NUM> containing at least one base unit <NUM>, wireless communication links <NUM> between remote unit <NUM> and base unit <NUM>, a first core network <NUM>, and a second core network <NUM>. Even though a specific number of remote units <NUM>, access networks <NUM>, <NUM>, base units <NUM>, wireless communication links <NUM>, and core networks <NUM>, <NUM> are depicted in <FIG>, one of skill in the art will recognize that any number of remote units <NUM>, access networks <NUM>, <NUM>, base units <NUM>, wireless communication links <NUM>, and core networks <NUM>, <NUM> may be included in the wireless communication system <NUM>. In various embodiments, the access networks <NUM>, <NUM> may contain one or more WLAN (e.g., Wi-Fi™) access points ("APs"). Here, the first access network <NUM>, second access network <NUM>, first core network <NUM> and second core network <NUM> belong to the same mobile communication network (e.g., the same PLMN).

In one implementation, the wireless communication system <NUM> is compliant with the <NUM> system and the LTE system specified in the 3GPP specifications. More generally, however, the wireless communication system <NUM> may implement some other open or proprietary communication network, for example, WiMAX, among other networks. The present disclosure is not intended to be limited to the implementation of any particular wireless communication system architectures or protocols.

In one embodiment, the remote units <NUM> may include computing devices, such as desktop computers, laptop computers, personal digital assistants ("PDAs"), tablet computers, smart phones, smart televisions (e.g., televisions connected to the Internet), smart appliances (e.g., appliances connected to the Internet), set-top boxes, game consoles, security systems (including security cameras), vehicle on-board computers, network devices (e.g., routers, switches, modems), or the like. Moreover, the remote units <NUM> may be referred to as subscriber units, mobiles, mobile stations, users, terminals, mobile terminals, fixed terminals, subscriber stations, UEs, user terminals, a device, or by other terminology used in the art. The remote units <NUM> may communicate directly with one or more of the base units <NUM> via uplink ("UL") and downlink ("DL") communication signals. Furthermore, the UL and DL communication signals may be carried over the wireless communication links <NUM>.

In some embodiments, the remote units <NUM> communicate with a remote host <NUM> (for example, an application server) via a data path that passes through one of the core networks <NUM> and <NUM> and also passes through the data network <NUM>. For example, a remote unit <NUM> may establish a PDU session (or similar data connection) to the data network <NUM> via the first core network <NUM>. The first core network <NUM> then relays traffic between the remote unit <NUM> and the remote host <NUM> using the PDU session. As another example, a remote unit <NUM> may establish a PDN connection to the data network <NUM> via the second core network <NUM>. The second core network <NUM> then relays traffic between the remote unit <NUM> and the remote host <NUM> using the PDN connection.

The base units <NUM> may be distributed over a geographic region. In certain embodiments, a base unit <NUM> may also be referred to as an access terminal, an access point, a base, a base station, a Node-B, an eNB, a gNB, a Home Node-B, a relay node, a device, or by any other terminology used in the art. The base units <NUM> are generally part of a radio access network ("RAN"), such as the first access network <NUM> (e.g., NG-RAN) and/or the second access network <NUM> (e.g., E-UTRAN), that may include one or more controllers communicably coupled to one or more corresponding base units <NUM>. These and other elements of the radio access network are not illustrated, but are well known generally by those having ordinary skill in the art.

The base units <NUM> may serve a number of remote units <NUM> within a serving area, for example, a cell or a cell sector via a wireless communication link <NUM>. The base units <NUM> may communicate directly with one or more of the remote units <NUM> via communication signals. Generally, the base units <NUM> transmit downlink ("DL") communication signals to serve the remote units <NUM> in the time, frequency, and/or spatial domain. Furthermore, the DL communication signals may be carried over the wireless communication links <NUM>. The wireless communication links <NUM> may be any suitable carrier in licensed or unlicensed radio spectrum. The wireless communication links <NUM> facilitate communication between one or more of the remote units <NUM> and/or one or more of the base units <NUM>.

As depicted, the wireless communication system <NUM> includes both a first core network <NUM> and a second core network <NUM>. Here, the first core network <NUM> and second core network <NUM> are part of the same PLMN. Each of the first core network <NUM> and second core network <NUM> is associated with a different "system generation" of the mobile communication network. Moreover, some services are available in the first core network <NUM> that are not available in the second core network <NUM>, and vice versa. Accordingly, in some situations the remote unit <NUM> may need to fallback from the first core network <NUM> to the second core network <NUM> in order to access certain services.

The first core network <NUM> includes an Access and Mobility Management Function ("AMF") <NUM>, a SMF <NUM>, a UPF <NUM>, and a UDM <NUM>. Additionally, the second core network <NUM> includes a Mobility Management Entity ("MME") <NUM>, a Serving Gateway ("SGW") <NUM>, a Packet Gateway ("PGW") <NUM>, and a Home Subscriber Server ("HSS") <NUM>. In some embodiments, the UDM <NUM> and HSS <NUM> may be co-located and/or may be a single entity shared by the first core network <NUM> and second core network <NUM>. Although specific numbers and types of network functions are depicted in <FIG>, one of skill in the art will recognize that any number and type of network functions may be included in the mobile core networks <NUM> and <NUM>. While the second core network <NUM> is depicted as including an IP multimedia subsystem ("IMS") <NUM>, in other embodiments, the IMS <NUM> may be separate from the second core network <NUM>.

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

While fallback procedures are commonly used to allow interoperability of various services used by the remote unit <NUM>, conventional fallback procedures involve the switch from a packet-switched domain ("PS-domain") to a circuit-switched domain ("CS-domain"). In some embodiments, a fallback procedure may involve a handover of one or more packet-switched sessions ("PS-sessions"). In other embodiments, the fallback procedure does not handover the PS-sessions.

In mobile communication networks having a fifth-generation core network ("5GC") and supporting a fifth-generation radio access technology, there are many possible scenarios for mobility of a remote unit <NUM> between various radio access technologies and/or core networks. For example, the remote unit may switch from the 5GC via NR RAT to 5GC via LTE RAT, referred to as RAT fallback. In another example, the remote unit <NUM> may switch from the 5GC via LTE RAT to 5GC via NR RAT, referred to as inter-RAT handover. In a third example, the remote unit <NUM> may switch from the 5GC via LTE RAT to an EPC via LTE RAT, referred to as a system (or CN) fallback. In a fourth example, the remote unit <NUM> may switch from the 5GC via NR RAT to an EPC via LTE RAT, also referred to as a system (or CN) fallback. In a fifth example, the remote unit <NUM> may switch from the 5GC via NR RAT to UMTS via UTRA, also referred to as a system fallback. Procedures for facilitating RAT and/or CN mobility are described below with reference to Figure 3A-3B.

Previously, the fallback procedure is used to transfer the remote unit <NUM> from <NUM> (EPS) to CS domain. However, when considering <NUM> system, fallback is possible for PS services as well, i.e., the fallback is from PS domain to PS domain. However, when following conventional fallback procedures, the RAN node (e.g., base unit <NUM>) does not have available information to steer the remote unit <NUM> to the appropriate target RAT or target system (CN).

The RRC Release procedure with redirect indication as known from LTE specification (e.g., TS <NUM>) is used to indicate to the remote unit <NUM> the information like frequency to measure, Location Area ID (LAI), etc. However, in the <NUM> scenarios this information may not be sufficient in order to steer the remote unit <NUM> to the appropriate target RAT or target system (CN). Moreover, it is important for the remote unit <NUM> to differentiate which target CN will be used, especially in cases of RAT fallback and inter-RAT handover, in order to initiate the correct NAS procedure in the target RAT.

To overcome the above described limitations of conventional fallback procedures, the system <NUM> implements a new procedure which provides core network (CN) assisted information to the RAN node (e.g., gNB, or base unit <NUM>) to allow the RAN node to take appropriate decision about (<NUM>) the mobility mechanism (IDLE or CONNECTED mode mobility) and (<NUM>) the target RAT. In some embodiments, the CN assisted information also includes the target CN for the fallback, if needed.

In particular, the first core network <NUM> (e.g., the AMF <NUM>) provides supported 'type of mobility' and target CN (the latter in case when the target RAT is E-UTRAN). In various embodiments, the target CN type is also provided to the remote unit <NUM> (e.g., via RRC signaling). In one alternative, the RAN node passes along the target CN information to the UE. In another alternative, the target CN type may be provided from the AMF <NUM> to the remote unit <NUM> directly using NAS signaling.

In some embodiments, when requesting a service for a possible RAT/system fallback (e.g., emergency services), the remote unit <NUM> may additionally indicate to the first core network <NUM> (e.g., to the AMF <NUM> in a NAS Service Request message) whether the remote unit <NUM> uses SR-mode or DR-mode of operation.

Based on <NUM>) request from the remote unit <NUM> (e.g., the NAS Service Request message) and/or <NUM>) based on network configuration (e.g., whether the N26 interface for 5GC/EPC interworking is deployed), and/or <NUM>) based on the service priority/latency requirements, the AMF <NUM> determines whether CONNECTED mode mobility (e.g., handover) or whether IDLE mode mobility (e.g., RRC Release with redirection) is desirable.

As used herein, "IDLE mode mobility" refers to RRC Release procedure with a redirect IE. The IDLE mode mobility may be inter-RAT IDLE mobility (e.g., within the same CN), or inter-system IDLE mobility (e.g., changing CNs). Also, as used herein, term "CONNECTED mode mobility" is used to represent Handover procedure (e.g., Xn-based or N2-based or S1-based, etc.) which may be inter-RAT Handover (e.g., within the same CN), or inter-system Handover (e.g., changing CNs).

In response to determining the mobility mode, the AMF <NUM> indicates in the N2 signaling message to the RAN node (e.g., the base unit <NUM>) at least the following: target CNs (or a list of target CNs, including priorities), whether HO or IDLE mode mobility to be used, and optionally target RATs (e.g., a list, including priorities for different RATs).

The base unit <NUM> transmits the target CNs (or a list of target CNs, including priorities) to the remote unit <NUM>. In an alternate embodiment, the AMF <NUM> may indicate to the remote unit <NUM> the target CNs in a NAS Service Accept message to the remote unit <NUM>.

The RAN node (e.g., base unit <NUM>) makes the final decision about the target RAT of the fallback procedure considering the radio topology, radio conditions of the remote unit <NUM>, and the indications received from the CN (e.g., from AMF <NUM>).

The RAN node (e.g., base unit <NUM>) needs to indicate to the remote unit <NUM> in the RRC release message with redirection IE the target RAT and the target CN when it decides that the radio handover is not to be performed since it cannot be performed (e.g., when there is no handover preparation with the target cell possible) or when it is inefficient (will take longer time than acceptable for some latency critical services). It should be noted that in some cases an RRC connection release with redirection may be faster than a handover procedure, especially if the redirection can be triggered blindly i.e. based on coverage information rather than the UE measurement reports.

Based on the information received by the remote unit <NUM> (according to the invention, target CN type and target RAT cell identifier, and optionally frequency etc., either in NAS message or in RRC message) the remote unit <NUM> initiates NAS procedure using the NAS protocol according to the target CN indication and initiates the Access Stratum procedure to accomplish the radio mobility in the target cell.

<FIG> depicts a first fallback procedure <NUM>, according to embodiments of the disclosure. The first fallback procedure <NUM> involves a UE <NUM>, a RAN node <NUM>, the AMF <NUM>, the SMF <NUM>, the UPF <NUM>, and a second domain <NUM> of the PLMN. Here, the UE <NUM> falls back to the second domain <NUM>. In one embodiment, the second domain includes an IMS. In another embodiment, the second domain includes a circuit-switched network. The second domain <NUM> is located in a different core network than the AMF <NUM>, SMF <NUM>, and UPF <NUM> (though located in the same PLMN).

A key aspects of the first fallback procedure <NUM> is that the serving core network (e.g., containing the AMF <NUM>) provides assistance information to the RAN node <NUM> to allow the RAN NODE <NUM> to make the appropriate decision about the mobility mechanism (e.g., idle mode mobility vs connected mode mobility) and the target radio access technology ("RAT") for the fallback procedure. The assistance information includes a target CN and target cell information indicating at least one RAT. Target cell information may include frequency band, RAT, and the like.

The UE <NUM> may be one embodiment of the remote unit <NUM>, discussed above. The RAN node <NUM> may be one embodiment of the base unit <NUM>, discussed above. In some embodiments, the RAN node <NUM> is a gNB or an eNB. The second domain <NUM> may be one embodiment of the second core network <NUM> and/or IMS <NUM>.

The first fallback procedure <NUM> begins at Step <NUM>, where UE <NUM> determines to initiate a service (MO Service Initiation) (see block <NUM>). In one embodiment, the service to initiate is an emergency service.

In Step <NUM>, the UE <NUM> sends NAS Service Request to the AMF <NUM> (see messaging <NUM>). The UE <NUM> includes in the NAS message at least the following information: UE ID, requested type of service (e.g., Emergency, Voice, Voice over PS (e.g., Voice over IMS) or Voice over CS), request for fallback/move to another target system. In certain embodiments, the NAS Service Request message also indicates SR/DR-mode of operation of the UE <NUM>.

Optionally, the UE <NUM> may indicate radio capability to the AMF <NUM>, e.g., whether the UE <NUM> is single transmission capable, or dual transmission capable. Based on this UE <NUM> radio capability, the AMF <NUM> determines whether a CONNECTED mode (e.g., Handover procedure) or IDLE mode mobility (e.g., RRC Release with redirection) is desirable. Note that the term IDLE mode mobility is used to represent RRC Release procedure with redirect IE.

The 'request for fallback/move to another target system' may for example indicate to the network (e.g., AMF <NUM> or SMF <NUM>) which would be the target system, e.g., EPS (if the UE <NUM> is currently connected to 5GS) or 5GS (if the UE <NUM> is currently connected to EPS).

In Step <NUM>, the AMF <NUM> may determine the target RAT(s) (e.g., E-UTRAN, UTRAN, GERAN) and target CN(s) (e.g., in case of target RAT is E-UTRAN the target CN may be EPC or 5GC) which would support the requested service (see block <NUM>). In addition, the AMF <NUM> considers the network deployment (e.g., whether N26 interface is supported) in order to determine whether CONNECTED mode mobility can be supported, or whether IDLE mode mobility is preferable. The AMF <NUM> indicates this information to the RAN node <NUM> as "type of mobility" indication. For example, if fallback to EPC is required and N26 interface is supported, then CONNECTED mode mobility is preferable. However, if fallback to EPC is required and N26 is not supported, then AMF <NUM> may indicate that IDLE mode mobility is preferable.

In one embodiment, the target CN is indicated to RAN node <NUM> or UE <NUM> only if there may be ambiguity at the UE <NUM>. For example, if the target RAT may be connected to multiple CNs, then the target CN is indicated to the RAN/UE. In a particular example, if the target RAT is E-UTRAN (or known as LTE) and LTE cell is connected to both EPC and 5GC, then redirecting the UE <NUM> in IDLE state to the LTE cell would cause ambiguity. One proposal is that the AMF <NUM> decide to indicate target CN type to RAN node <NUM> or UE <NUM> (in step <NUM> below) only if there is ambiguity of the CN to be used. In another example, if the target RAT is UTRAN (e.g., <NUM>), then there is no ambiguity for the target CN, as the CN type is GPRS.

As the AMF <NUM> usually does not know the exact coverage conditions of the potential target RAT(s), the AMF <NUM> may create a list of target RATs/CNs based on preference or order of selection. This kind of preference list would steer the RAN node <NUM> (e.g., gNB) to take decision about the target RAT based on the coverage condition at the UE <NUM> location (e.g., depending on the radio measurements reported by the UE <NUM> to the source RAN node <NUM>).

Further, if the UE <NUM> is in CONNECTED state, the AMF <NUM> may consider the service priority/latency requirements of the PDU Session used by the UE <NUM> when creating the fallback information to be sent to the RAN node <NUM>. Based on this, the AMF <NUM> may send to the RAN node <NUM> information about the criticality (e.g., priority or latency requirements) of the fallback procedure. For example, if the UE <NUM> is using a PDU Session (e.g., the UE <NUM> resources are activated) having a packet delivery requirement for latency, the AMF <NUM> may indicate to the RAN node <NUM> that the mobility procedure shall meet the latency/priority requirements.

In Step 3a, the AMF <NUM> sends N2 request signaling message to the RAN node <NUM> (e.g., gNB) to request a fallback procedure for the UE <NUM>. The AMF <NUM> indicates in addition at least one target CN type to which the UE <NUM> has to fallback. The RAN node <NUM> takes the target CN information in order to select to the correct cell to which IDLE mode or CONNECTED mode procedure needs to be performed. The AMF <NUM> may indicate at least one of the following fallback information to the RAN node <NUM>: Target RATs, Target Tracking Area (TA), Requested service, Type of mobility, and/or Criticality requirements.

As used herein, the "Target RATs" refers to an indication of at least one RAT to which the UE <NUM> has to be moved in order to perform the requested service. "Target Tracking Area (TA)" refers to information helps the RAN node <NUM> to find proper target cell as part of the TA indicated by the CN. The "Requested service" refers to the service which the UE <NUM> would like to use the and which triggered the procedure for fallback or RAT/System change. The "Type of mobility" refers to an indication of whether CONNECTED mode or IDLE mode mobility is preferred based on the configuration in the CN. For example, if N26 interface is deployed, the AMF <NUM> may indicate CONNECTED state mobility is desirable and the AMF <NUM> based on this may include the AS context (e.g., AS security, MM context, radio capabilities, etc.) to the gNB. If, e.g., the N26 interface is not deployed, the CN may indicate 'IDLE mode mobility' or 'similarly RRC Release with redirect' or similar indication. "Criticality requirements" refers to an indication of the service priority/latency requirements of the PDU Session currently used by the UE <NUM>.

The RAN node <NUM> decides whether to perform IDLE mode mobility (e.g., to execute RRC release procedure with redirection IE) or to perform CONNECTED mode mobility (e.g., to execute a Handover procedure) based on the UE <NUM>'s radio coverage and on the indications received from the AMF <NUM>.

Step 3b shows the case where the RAN node <NUM> decides to perform IDLE mode mobility, the RAN node <NUM> performs RRC release procedure and sends an RRC Connection Release message to the UE <NUM> which includes target CN information (see messaging <NUM>). The RRC Connection Release message includes redirection information, the redirection information including the target CN information and target RAN information.

Alternatively, the RAN node <NUM> initiates handover procedure to the target RAT/ CN, when this is possible, with or without configuring measurements to the UE <NUM>. The latter case is Blind handover case. In the former case, the actual handover execution shall be delayed until the UE <NUM> performs measurements and provides the results to source RAT, the source RAT in turn prepares/ informs the target RAT for the same, the target RAT prepared handover command and sends to the UE <NUM> via the source RAT.

Step 3c shows the case where the RAN node <NUM> decides to perform CONNECTED mode mobility, the RAN node <NUM> may perform RRC Connection Reconfiguration procedure in order to configure the UE <NUM> with measurements to the desired target cell (see messaging <NUM>). In the following a RAN node <NUM> initiates a Handover procedure to the target RAT cell.

In Step <NUM>, the RAN node <NUM> sends N2 request Ack message to the AMF <NUM> (see messaging <NUM>). If the RAN node <NUM> has decided to perform IDLE mode mobility, the RAN node <NUM> includes corresponding information to the AMF <NUM> indicating that the UE <NUM> has been redirected to a particular RAT. However, if the RAN node <NUM> has decided to perform CONNECTED mode mobility, the RAN node <NUM> performs actions according to Xn-based or N2-based Handover procedures.

Based on whether the RAN node <NUM> selects IDLE mode mobility or CONNECTED mode mobility, the RAN <NUM> performs one of the following:.

Step 5a: If the RAN node <NUM> has performed IDLE mode mobility, the AMF <NUM> determines whether to release the existing PDU Sessions, or to preserve the PDU Session context in the CN but deactivate the UP resources (in case the UE <NUM> has been in CONNECTED state and the UP resources have been activated; see block <NUM>). For example, the AMF <NUM> may initiate N11 exchange towards the SMF <NUM> to release the PDU Session UP resources. If the AMF <NUM> decides to preserve the PDU Sessions context in the 5GC, the AMF <NUM> may also indicate to the SMF <NUM> that the PDU Session is temporary suspended in order to avoid the SMF <NUM> initiating paging procedure.

Step 5b: If the RAN node <NUM> has performed CONNECTED mode mobility (e.g., a Handover procedure), then the AMF <NUM> continues with the Handover procedure (see block <NUM>).

In Step <NUM>, the UE <NUM> initiates NAS procedure in the target RAT using the NAS protocol according to the target CN indication (e.g., EPC NAS or 5GC NAS) received in the RRC message (see block <NUM>). The RRC message indicates to the UE <NUM> that the redirection is performed to a particular CN Type (e.g., 5GS or EPS) and in the target RAT cell. The UE <NUM> uses the corresponding NAS protocol accordingly.

Moreover, subsequent to the radio procedure to move the UE <NUM> in the target RAT cell using, e.g., RRC Idle or RRC INACTIVE state cell redirection principles, the NAS protocol corresponding to the indicated CN Type shall be used. <NUM> encoding of including the CN Type (e.g., 5GS or EPS) in the RRC message releasing the RRC Connection is shown <FIG>.

In Step <NUM>, the UE <NUM> initiates a service call in the target RAT and target CN ("target system"), depicted here as the second domain <NUM> (see block <NUM>). If IDLE mode mobility was performed and after the UE <NUM> completes the RRC procedure establishment in the target cell and performs NAS registration (or attach) with the target CN, the UE <NUM> initiates the requested service (see block <NUM>). Alternatively, the requested service may be also indicated during the NAS registration (or attach) procedure. The first fallback procedure <NUM> ends.

<FIG> depicts a second fallback procedure <NUM>, according to embodiments of the disclosure. The second fallback procedure <NUM> involves the UE <NUM>, the RAN node <NUM>, the AMF <NUM>, the SMF <NUM>, the UPF <NUM>, and the second domain <NUM> of the PLMN. Here, the UE <NUM> falls back to the second domain <NUM>.

A key aspects of the second fallback procedure <NUM> is that the serving core network (e.g., containing the AMF <NUM>) provides assistance information to the RAN node <NUM> to allow the RAN NODE <NUM> to make the appropriate decision about the mobility mechanism (e.g., idle mode mobility vs connected mode mobility) and the target radio access technology ("RAT") for the fallback procedure. The assistance information includes a target CN and target cell information indicating at least one RAT. Target cell information may include frequency band, RAT, and the like.

The second fallback procedure <NUM> begins at Step <NUM>, where UE <NUM> determines to initiate a service (MO Service Initiation) (see block <NUM>). In one embodiment, the service to initiate is an emergency service.

In Step <NUM>, the UE <NUM> sends NAS Service Request to the AMF <NUM> (see messaging <NUM>). The UE <NUM> includes in the NAS message at least the following information: UE ID, requested type of service (e.g., Emergency, Voice, Voice over PS (e.g., Voice over IMS) or Voice over CS), request for fallback/move to another target system. In certain embodiments, the NAS Service Request message also indicates a SR/DR-mode of operation of the UE <NUM>.

Optionally, the UE <NUM> may indicate radio capability to the AMF <NUM>, e.g., whether the UE <NUM> is single transmission capable, or dual transmission capable. Based on this UE <NUM> radio capability, the AMF <NUM> may determine whether a CONNECTED mode (e.g., Handover procedure) or IDLE mode mobility (e.g., RRC Release with redirection) is desirable. Note that the term IDLE mode mobility is used to represent RRC Release procedure with redirect IE.

The 'request for fallback/move to another target system' may indicate to the network (e.g., AMF <NUM> or SMF <NUM>) which would be the target system, e.g., EPS (if the UE <NUM> is currently connected to 5GS) or 5GS (if the UE <NUM> is currently connected to EPS).

In Step 3a, the AMF <NUM> sends a NAS Service Request message to the UE <NUM> containing a proper reject cause value (see messaging <NUM>). For example, the reject cause may indicate that the requested service is not supported. The AMF <NUM> may also indicate a list of possible RATs/CNs in which the requested service may be used. If the AMF <NUM> has detected that the target RAT may be connected to multiple CNs (e.g., in case of E-UTRA), the AMF <NUM> may include a target CN indication to the UE <NUM>. The target CN points to the UE <NUM> which NAS protocols stack to be used after the fallback procedure.

In Step 3b, the AMF <NUM> sends a N2 request signaling message to the RAN node <NUM> (e.g., gNB) to request a fallback procedure for the UE <NUM> (see messaging <NUM>). The AMF <NUM> may indicate at least one of the following fallback information to the RAN node <NUM>: Target RATs, Target Tracking Area (TA), Requested service, Type of mobility, and/or Criticality requirements. Note that the NAS Service Request message from Step 3a may be sent encapsulated in the same N2 message as Step 3b. The RAN node <NUM> should correspondingly process and transfer first the encapsulated NAS message to the UE <NUM> before releasing the RRC connection.

Step 3c shows the case where the RAN node <NUM> decides to perform IDLE mode mobility, the RAN node <NUM> performs RRC release procedure (see messaging <NUM>). Alternatively, the RAN node <NUM> initiates handover procedure to the target RAT/ CN, when this is possible, with or without configuring measurements to the UE <NUM>. The latter case is Blind handover case. In the former case, the actual handover execution shall be delayed until the UE <NUM> performs measurements and provides the results to source RAT, the source RAT in turn prepares/ informs the target RAT for the same, the target RAT prepared handover command and sends to the UE <NUM> via the source RAT.

Step 3d shows the case where the RAN node <NUM> decides to perform CONNECTED mode mobility, the RAN node <NUM> may perform RRC Connection Reconfiguration procedure in order to configure the UE <NUM> with measurements to the desired target cell (see messaging <NUM>). In the following a RAN node <NUM> initiates a Handover procedure to the target RAT cell.

Step 5a: If the RAN node <NUM> has performed IDLE mode mobility, the AMF <NUM> determines whether to release the existing PDU Sessions, or to preserve the PDU Session context in the CN but deactivate the UP resources (in case the UE <NUM> has been in CONNECTED state and the UP resources have been activated; see block <NUM>). For example, the AMF <NUM> initiates N11 exchange towards the SMF <NUM> to release the PDU Session UP resources. If the AMF <NUM> decides to preserve the PDU Sessions context in the 5GC, the AMF <NUM> may also indicate to the SMF <NUM> that the PDU Session is temporary suspended in order to avoid the SMF <NUM> to initiate paging procedure.

Step 5b: If the RAN node <NUM> has performed CONNECTED mode mobility (e.g., a Handover procedure), the AMF <NUM> continues with the Handover procedure (see block <NUM>).

In Step <NUM>, the UE <NUM> initiates NAS procedure in the target RAT using the NAS protocol according to the target CN indication (e.g., EPC NAS or 5GC NAS) received in the NAS message (see block <NUM>). The NAS message indicates to the UE <NUM> that the redirection is performed to a particular CN Type (e.g., 5GS or EPS) and in the target RAT cell, the UE <NUM> shall use the corresponding NAS protocol accordingly.

In Step <NUM>, the UE <NUM> initiates a service call in the target RAT and target CN ("target system"), depicted here is the second domain <NUM> (see block <NUM>). If IDLE mode mobility was performed and after the UE <NUM> completes the RRC procedure establishment in the target cell and performs NAS registration (or attach) with the target CN, the UE <NUM> initiates the requested service. Alternatively, the requested service may be also indicated during the NAS registration (or attach) procedure.

<FIG> depicts an RRC connection message <NUM> according to embodiments of the disclosure. Elements/parameters to communicate the CN assisted information, e.g., for use in the above described fallback procedures, are shown in bold and italics.

<FIG> depicts one embodiment of a user equipment apparatus <NUM> that may be used for providing fallback assistance information to a RAN node. In the present invention, the remote unit <NUM> is the user equipment apparatus <NUM>. Furthermore, the user equipment apparatus <NUM> may include a processor <NUM>, a memory <NUM>, an input device <NUM>, an output device <NUM>, and a transceiver <NUM>. In some embodiments, the input device <NUM> and the output device <NUM> are combined into a single device, such as a touchscreen. In certain embodiments, the user equipment apparatus <NUM> may not include any input device <NUM> and/or output device <NUM>. In various embodiments, the user equipment apparatus <NUM> may include one or more of: the processor <NUM>, the memory <NUM>, and the transceiver <NUM>, and may not include the input device <NUM> and/or the output device <NUM>.

In some embodiments, the transceiver <NUM> sends a service request and receives a connection release message. Here, the service request requires fallback to at least one of: a different RAT and a different CN. Moreover, the connection release message includes redirection information for the service fallback, the redirection information including a target CN. The processor <NUM> that selects a NAS procedure based on the target CN and connects to the target CN using the selected NAS procedure.

In some embodiments, the NAS procedure in the target CN is one of: 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: type of the requested service and a radio capability of the remote unit, the radio capability including an indication of whether the remote unit is dual-transmission capable.

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, wherein the processor further provides the target CN to one or more upper layers.

In some embodiments, the memory <NUM> stores data related to providing fallback assistance information to a RAN node. For example, the memory <NUM> may store target CN information, target RAT information, and the like. In certain embodiments, the memory <NUM> also stores program code and related data, such as an operating system or other controller algorithms operating on the remote unit <NUM>.

The transceiver <NUM> includes at least transmitter <NUM> and at least one receiver <NUM>. One or more transmitters <NUM> may be used to communicate with a RAN node, such as the base unit <NUM>, Although only one transmitter <NUM> and one receiver <NUM> are illustrated, the user equipment apparatus <NUM> may have any suitable number of transmitters <NUM> and receivers <NUM>. Moreover, the transceiver <NUM> may support one or more network interfaces <NUM>. For example, the transceiver <NUM> may support a Uu interface for communication with a RAN node, an N1 interface for communication with an AMF, and the like.

<FIG> depicts one embodiment of a RAN apparatus <NUM> that may be used for providing fallback assistance information to a RAN node. The RAN apparatus <NUM> may be one embodiment of the base unit <NUM> and/or RAN node <NUM>. Furthermore, the RAN apparatus <NUM> may include a processor <NUM>, a memory <NUM>, an input device <NUM>, an output device <NUM>, and a transceiver <NUM>. In some embodiments, the input device <NUM> and the output device <NUM> are combined into a single device, such as a touchscreen. In certain embodiments, the RAN apparatus <NUM> may not include any input device <NUM> and/or output device <NUM>. In various embodiments, the RAN apparatus <NUM> may include one or more of: the processor <NUM>, the memory <NUM>, and the transceiver <NUM>, and may not include the input device <NUM> and/or the output device <NUM>.

In various embodiments, the transceiver <NUM> receives a first message from a network function in a first core network, wherein the first message indicates service fallback of a remote unit connected to the RAN node and indicates a target CN. The processor <NUM> determines service fallback parameters for the remote unit. Moreover, the transceiver <NUM> 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.

The redirection information further includes a target radio access technology RAT. In certain embodiments, the first message additionally includes RAN node information, wherein the RAN node information comprises at least one of: UE security context and UE mobility restrictions.

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.

The first message includes target fallback information, the target fallback information including a target radio access technology ("RAT"), the target CN, and optionally one or more of: a target mobility type, a service request by the remote unit that triggered the service fallback, and criticality requirements of a data connection of the remote unit.

As another, non-limiting, example, the output device <NUM> may include a wearable display separate from, but communicatively coupled to, the rest of the RAN apparatus <NUM>, such as a smart watch, smart glasses, a heads-up display, or the like.

The transceiver <NUM> includes at least transmitter <NUM> and at least one receiver <NUM>. One or more transmitters <NUM> may be used to provide DL communication signals to a remote unit <NUM>. Similarly, one or more receivers <NUM> may be used to receive UL communication signals from the remote unit <NUM>, as described herein. Although only one transmitter <NUM> and one receiver <NUM> are illustrated, the RAN apparatus <NUM> may have any suitable number of transmitters <NUM> and receivers <NUM>. Further, the transmitter(s) <NUM> and the receiver(s) <NUM> may be any suitable type of transmitters and receivers. In one embodiment, the transceiver <NUM> includes transmitter/receiver pair(s) to communicate with a mobile communication network, including the first core network <NUM> and second core network <NUM>. Moreover, the transceiver <NUM> may support one or more network interfaces <NUM>. For example, the transceiver <NUM> may support a Uu interface for communication with a UE, an N2 interface for communication with an AMF, and the like.

<FIG> depicts one embodiment of a network function apparatus <NUM> that may be used for providing fallback assistance information to a RAN node. This embodiment is however not covered by the claims. The network function apparatus <NUM> may be one embodiment of the remote unit <NUM>. Furthermore, the network function apparatus <NUM> may include a processor <NUM>, a memory <NUM>, an input device <NUM>, an output device <NUM>, and a transceiver <NUM>. In some embodiments, the input device <NUM> and the output device <NUM> are combined into a single device, such as a touchscreen. In certain embodiments, the network function apparatus <NUM> may not include any input device <NUM> and/or output device <NUM>. In various embodiments, the network function apparatus <NUM> may include one or more of: the processor <NUM>, the memory <NUM>, and the transceiver <NUM>, and may not include the input device <NUM> and/or the output device <NUM>.

In some embodiments, the transceiver <NUM> receives a service request from a remote unit, wherein the service request requires fallback to at least one of: a different RAT and a different CN. The processor <NUM> 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. Moreover, the transceiver <NUM> indicates, to a RAN node, the at least one of: a target RAT and a target CN, based on the requested service, wherein the RAN node performs fallback procedure with the remote unit based on the at least one of: a target RAT and a target CN. Here, performing fallback procedure includes one of:.

In some embodiments, the service request indicates that the remote unit requires emergency services fallback. In certain embodiments, indicating the at least one of: a target RAT and a target CN, includes sending at least one of: a prioritized list of target RATs and a prioritized list of CNs.

In some embodiments, the transceiver <NUM> further sends a signaling message with fallback information to the RAN node, wherein the fallback information includes at least one of: a target RAT, a target tracking area, the request service, a mobility type, and service requirements of a data connection used by the remote unit. In such embodiments, the mobility type indicates 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: releasing a data connection used by the remote unit, suspending a data connection used by the remote unit, and handing over a data connection used by the remote unit.

As another, non-limiting, example, the output device <NUM> may include a wearable display separate from, but communicatively coupled to, the rest of the network function apparatus <NUM>, such as a smart watch, smart glasses, a heads-up display, or the like.

The transceiver <NUM> includes at least transmitter <NUM> and at least one receiver <NUM>. One or more transmitters <NUM> and one or more receivers <NUM> may be used to communicate with a base unit <NUM>, such as the RAN node <NUM>, and/or with other network functions in a core network. Although only one transmitter <NUM> and one receiver <NUM> are illustrated, the network function apparatus <NUM> may have any suitable number of transmitters <NUM> and receivers <NUM>. Further, the transmitter(s) <NUM> and the receiver(s) <NUM> may be any suitable type of transmitters and receivers. Moreover, the transceiver <NUM> may support one or more network interfaces <NUM>. For example, the transceiver <NUM> may support an N1 interface for communication with a UE, an N11 interface for communication with a SMF, and the like.

<FIG> depicts a method <NUM> for determining transport block generation timing of an uplink transmission, according to embodiments of the disclosure. In some embodiments, the method <NUM> is performed by an apparatus, such as the remote unit <NUM>, the UE <NUM>, and/or the user equipment apparatus <NUM>. In certain embodiments, the method <NUM> may be performed by a processor executing program code, for example, a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like.

The method <NUM> begins and sends <NUM>, by a remote unit, a service request, wherein the service request requires fallback to at least one of: a different RAT and a different CN. In certain embodiments, sending <NUM> the service request includes indicating at least one of: type of the requested service and a radio capability of the remote unit, the radio capability including an indication of whether the remote unit is dual-transmission capable.

The method <NUM> includes receiving <NUM>, at the remote unit, a connection release message, where the connection release message includes redirection information for the service fallback, the redirection information including a target CN. The redirection information further includes target cell information indicating at least one RAT. In certain embodiments, the indicated RAT is E-UTRAN.

The method <NUM> includes selecting <NUM> a NAS procedure based on the target CN.

The method <NUM> includes connecting <NUM> to the target CN using the selected NAS procedure. The method <NUM> ends. In some embodiments, the NAS procedure in the target CN may be one of: an EPC NAS procedure and a 5GC NAS procedure. In various embodiment, the NAS procedure in the target CN may include initiating the requested service via the target CN.

<FIG> depicts a method <NUM> for determining transport block generation timing of an uplink transmission, according to embodiments of the disclosure. In some embodiments, the method <NUM> is performed by an apparatus, such as the base unit <NUM>, the RAN node <NUM>, and/or the RAN apparatus <NUM>. In certain embodiments, the method <NUM> may be performed by a processor executing program code, for example, a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like.

The method <NUM> begins and receives <NUM>, at a RAN node, a first message from a network function in a first core network, wherein the first message indicates service fallback of a remote unit connected to the RAN node and indicates a target CN. In certain embodiments, the first message additionally includes RAN node information, wherein the RAN node information includes at least one of: UE security context and UE mobility restrictions. The first message includes target fallback information, the target fallback information including a target RAT, the target CN, and optionally one or more of: a target mobility type, a service request by the remote unit that triggered the service fallback, and criticality requirements of a data connection of the remote unit.

The method <NUM> includes determining <NUM> service fallback parameters for the remote unit. In certain 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.

The method <NUM> includes sending <NUM> 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. In some embodiments, the redirection information further includes at least a target RAT.

<FIG> depicts a method <NUM> for determining transport block generation timing of an uplink transmission, according to embodiments of the disclosure. This embodiment is however not covered by the claims. In some embodiments, the method <NUM> is performed by an apparatus, such as the AMF <NUM> and/or the network function apparatus <NUM>. In certain embodiments, the method <NUM> may be performed by a processor executing program code, for example, a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like.

The method <NUM> begins and receives <NUM>, at a network function part of a first core network, a service request from a remote unit, wherein the service request is for a service which requires fallback to at least one of: a different RAT and a different CN. In some embodiments, the service request indicates that the remote unit requires emergency services fallback.

The method <NUM> includes identifying <NUM>, 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 method <NUM> includes indicating <NUM>, to a RAN node, the at least one of: a target RAT and a target CN, based on the requested service, wherein the RAN node performs fallback with the remote unit based on the at least one of: a target RAT and a target CN. In certain embodiments, indicating the at least one of: a target RAT and a target CN, including sending at least one of: a prioritized list of target RATs and a prioritized list of CNs. In some embodiments, the network function sends a signaling message with fallback information to the RAN node, wherein the fallback information includes at least one of: a target RAT, a target tracking area, the request service, a mobility type, and service requirements of a data connection used by the remote unit.

Disclosed herein is a first apparatus for providing fallback assistance information. The first apparatus may be one embodiment of the remote unit <NUM>, the UE <NUM>, and/or the user equipment apparatus <NUM>. The first apparatus includes a transceiver that sends a service request and receives a connection release message. Here, the service request requires fallback to at least one of: a different RAT and a different CN. Moreover, the connection release message includes redirection information for the service fallback, the redirection information including a target CN. The first apparatus includes a processor that selects a NAS procedure based on the target CN and connects to the target CN using the selected NAS procedure.

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

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

In some embodiments, the NAS procedure in the target CN may be one of: an EPC NAS procedure and a 5GC NAS procedure. In various embodiment, the NAS procedure in the target CN may include initiating the requested service via the target CN. In certain embodiments, sending the service request includes indicating at least one of: type of the requested service and a radio capability of the remote unit, the radio capability including an indication of whether the remote unit is dual-transmission capable.

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

Disclosed herein is a second apparatus for providing fallback assistance information. The second apparatus may be one embodiment of the base unit <NUM>, the RAN node <NUM>, and/or the RAN apparatus <NUM>. The second apparatus includes a transceiver that receives a first message from a network function in a first core network, wherein the first message indicates service fallback of a remote unit connected to the RAN node and indicates a target CN. The second apparatus also includes a processor that determines service fallback parameters for the remote unit. Moreover, 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.

The redirection information further includes a target radio access technology ("RAT"). In certain embodiments, the first message additionally includes RAN node information, wherein the RAN node information comprises at least one of: UE security context and UE mobility restrictions.

The first message includes target fallback information, the target fallback information including a target radio access technology ("RAT"), the target CN, and optionally one or more of:
a target mobility type, a service request by the remote unit that triggered the service fallback, and criticality requirements of a data connection of the remote unit.

Disclosed herein is a second method for providing fallback assistance information. The second method may be implemented by the base unit <NUM>, the RAN node <NUM>, and/or the RAN apparatus <NUM>. The second method includes receiving, at a RAN node, a first message from a network function in a first core network, wherein the first message indicates 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.

The redirection information further includes at least a target RAT. In certain embodiments, the first message additionally includes RAN node information, wherein the RAN node information includes at least one of: UE security context and UE mobility restrictions.

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. The first message includes target fallback information, the target fallback information including a target RAT, the target CN, and optionally one or more of:
a target mobility type, a service request by the remote unit that triggered the service fallback, and criticality requirements of a data connection of the remote unit.

Disclosed herein is a third apparatus for providing fallback assistance information. This third apparatus is however not covered by the claims. The third apparatus may be one embodiment of the AMF <NUM> and/or the network function apparatus <NUM>. The third apparatus includes a transceiver that receives a service request from a remote unit, wherein the service request requires fallback to at least one of: a different RAT and a different CN. The third apparatus 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. Moreover, the transceiver indicates, to a RAN node, the at least one of: a target RAT and a target CN, based on the requested service, wherein the RAN node performs fallback procedure with the remote unit based on the at least one of: a target RAT and a target CN. Here, performing fallback procedure includes one of:.

In some embodiments, the service request indicates that the remote unit requires emergency services fallback. In certain embodiments, indicating the at least one of: a target RAT and a target CN, comprises sending at least one of: a prioritized list of target RATs and a prioritized list of CNs.

In some embodiments, the transceiver further sends a signaling message with fallback information to the RAN node, wherein the fallback information includes at least one of: a target RAT, a target tracking area, the request service, a mobility type, and service requirements of a data connection used by the remote unit.

In such embodiments, the mobility type indicates 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: releasing a data connection used by the remote unit, suspending a data connection used by the remote unit, and handing over a data connection used by the remote unit.

Disclosed herein is a third method for providing fallback assistance information. This third method is however not covered by the claims. The third method may be implemented by the AMF <NUM> and/or the network function apparatus <NUM>. The third method includes receiving, at a network function part of a first core network, a service request from a remote unit, wherein the service request is for a service which requires fallback to at least one of: 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 a RAN node, the at least one of: a target RAT and a target CN, based on the requested service, wherein the RAN node performs fallback with the remote unit based on the at least one of: a target RAT and a target CN.

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

In such embodiments, the mobility type indicates idle mode mobility of the remote unit, wherein 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: releasing a data connection used by the remote unit, suspending a data connection used by the remote unit, and handing over a data connection used by the remote unit.

Claim 1:
A method (<NUM>) performed by a user equipment, UE, (<NUM>, <NUM>), the method (<NUM>) comprising:
sending (<NUM>) a service request, wherein the service request requires a service fallback to at least one of: a different radio access technology, RAT, and a different core network, CN;
receiving (<NUM>) a connection release message, where the connection release message includes redirection information for the service fallback, the redirection information including a target core network, CN, type and a target RAT cell identifier;
initiating (<NUM>) a non-access stratum, NAS, procedure, using a NAS protocol according to the target CN type;
initiating an access stratum, AS, procedure to accomplish radio mobility in a target RAT cell identified by the target RAT cell identifier; and connecting (<NUM>) to the target CN type and the target RAT cell.