Methods and apparatus relating to fallback or redirection

Abstract

According to an example of the disclosure, there is provided a user equipment (UE) configured to: receive, from a first network, an indication to redirect to a second network, wherein the indication includes information on a carrier frequency of the second network and / or information on a carrier frequency offset; wherein the first network is an Evolved-Universal Terrestrial Radio Access Network (E-UTRAN) terrestrial network (TN) and the second network is a Narrowband Internet of Things (NB-IoT) non-terrestrial network (NTN). According to another example of the disclosure, there is provided an entity in a first network, wherein the first network is an Evolved-Universal Terrestrial Radio Access Network (E-UTRAN) terrestrial network (TN), and the entity configured to: transmit, to a user equipment (UE), an indication to redirect to a second network, wherein the indication includes information on a carrier frequency of the second network and / or information on a carrier frequency offset; wherein the second network is a Narrowband Internet of Things (NB-IoT) non-terrestrial network (NTN).

Description

METHODS AND APPARATUS RELATING TO FALLBACK OR REDIRECTION

[0001] Certain examples of the present disclosure relate to methods, apparatus and / or systems for fallback or redirection to NTN. In various examples, based on determining to fallback, a network signals for a UE to fallback to NTN RAN, such as from a TN RAN to a NTN RAN. In an example, this determination is based on the UE signalling capability to fallback to NTN, and / or the NTN supporting a service relating to a cause for fallback. A cause of fallback may, in some examples, be an emergency service or call situation. Various examples relate to fallback in the case of specific RATs, e.g. falling back from one RAT to another RAT. Certain examples of the present disclosure relate to methods, apparatus and / or systems for priority-based redirection to a NTN. For example, a UE may be MPS redirected from a TN to a NTN based on signalling from a network. In an example, this determination is based on the UE signalling capability for NTN MPS redirection. Various examples relate to UE mobility, UE and / or network capabilities relating to mobility, UE position reporting and / or RAT restrictions. Various examples consider the case of fallback from a NTN to a TN.

[0002] The content of the following documents is referred to below and / or their content provides background information that the following disclosure should be considered in the context of:

[0003] [1] 3GPP RP-202689 - MediaTek Inc., "New Study WID on NB-IoT / eTMC support for NTN"; 3GPP TSG RAN Meeting #90; Electronic Meeting, December 7 - 11, 2020.

[0004] [2] 3GPP RP-211557 - Thales, "Solutions for NR to support non-terrestrial networks (NTN)"; 3GPP TSG RAN meeting #91-e; e-meeting, March 22 - 26th, 2021.

[0005] [3] 3GPP RP-220953 - Thales, "NR NTN (Non-Terrestrial Networks) enhancements"; 3GPP TSG RAN Meeting #95e; Electronic Meeting, March 17 - 23, 2022.

[0006] [4] 3GPP RP-223519 - MediaTek Inc., "Revised WID on IoT NTN enhancements"; 3GPP TSG RAN Meeting #98e; Electronic, 12-16 December 2022.

[0007] [5] 3GPP RP-234077 - Deutsche Telekom (moderator, RAN VC), "New WID: Non-Terrestrial Networks (NTN) for Internet of Things (IoT) Phase 3"; 3GPP TSG RAN Meeting #102 ; Edinburgh, Scotland, December 11-15, 2023.

[0008] Note: indicated version numbers are provided for illustrative purposes, other (including future) versions of these documents are considered also.

[0009] Wireless or mobile (cellular) communications networks in which a mobile terminal (e.g., user equipment (UE), such as a mobile handset) communicates via a radio link with a network of base stations, or other wireless access points or nodes, have undergone rapid development through a number of generations. The 3rd Generation Partnership Project (3GPP) design, specify and standardise technologies for mobile wireless communication networks. Fourth Generation (4G) and Fifth Generation (5G) systems (5GS) are now widely deployed, while beyond 5G (B5G) and 6G systems are being considered.

[0010] 3GPP standards for 4G systems include an Evolved Packet Core (EPC) and an Evolved-UTRAN (E-UTRAN: an Evolved Universal Terrestrial Radio Access Network). The E-UTRAN uses Long Term Evolution (LTE) radio technology. LTE is commonly used to refer to the whole system including both the EPC and the E-UTRAN, and LTE is used in this sense in the remainder of this document. LTE should also be taken to include LTE enhancements such as LTE Advanced and LTE Pro, which offer enhanced data rates compared to LTE.

[0011] In 5G systems a new air interface has been developed, which may be referred to as 5G New Radio (5G NR) or simply NR. NR is designed to support the wide variety of services and use case scenarios envisaged for 5G networks, though builds upon established LTE technologies. B5G systems, such as 6G, are currently being considered and developed, and are expected to at least partly build on 5G systems.

[0012] New frameworks and architectures are being developed as part of 5G network (and beyond, such as 6G networks) in order to increase the range of functionality and use cases available through 5G networks.

[0013] IoT (Internet of Things) NTN (Non-Terrestrial Network) was a 3GPP study and work item in 3GPP release 17 to provide Non-Terrestrial Network access for E-UTRAN IoT devices (NB-IoT (Narrowband-IoT) and LTE-M / eMTC (Long-Term Evolution Machine Type Communication / enhanced machine-type communication)) (RP-202689 [1]].

[0014] NR NTN was a work item in Rel-17 to specify adaptation to allow NR to function over NTN (RP-211557 [2]). Non-Terrestrial Network access may be through Lower Earth Orbit (LEO), Medium Earth Orbit (MEO) and Geostationary Orbit (GEO), as well as through High-Altitude Platform Systems (HAPS).

[0015]

[0016]

[0017]

[0018]

[0019]

[0020] Conventional wireless communication systems do not sufficiently support redirection from a terrestrial network, such as an Evolved-Universal Terrestrial Radio Access Network (E-UTRAN) terrestrial network (TN), to a non-terrestrial network (NTN), such as a Narrowband Internet of Things (NB-IoT) NTN. In particular, existing mechanisms do not clearly provide procedures for indicating carrier frequency information for the NTN and for supporting UE capability related to redirection or fallback to the NB-IoT NTN. As a result, it may be difficult for a UE to efficiently perform redirection from the terrestrial network to the NB-IoT NTN and to establish a connection with a corresponding NTN cell.

[0021] It is an aim of certain examples of the present disclosure to address, solve and / or mitigate, at least partly, at least one of the problems and / or disadvantages associated with the related art, for example at least one of the problems and / or disadvantages described herein. It is an aim of certain examples of the present disclosure to provide at least one advantage over the related art, for example at least one of the advantages described herein.

[0022] According to an aspect of the disclosure, a method performed by a user equipment (UE) in a communication system is provided. The method comprises receiving, from a network entity of an evolved-universal terrestrial radio access network (E-UTRAN), a radio resource control (RRC) message including redirect carrier information, wherein the redirect carrier information indicates carrier information to redirect the UE from a first network to a second network; and performing a cell selection based on the redirect carrier information, wherein the first network is an EUTRAN terrestrial network (TN) and the second network is a narrowband internet of things (NB-IoT) non-terrestrial network (NTN).

[0023] According to an aspect of the disclosure, a method performed by a network entity in a communication system is provided. The method comprises determining a redirection of a user equipment (UE) from a first network to a second network; and transmitting, to the UE, a radio resource control (RRC) message including redirect carrier information, wherein the redirect carrier information indicates carrier information to redirect the UE from the first network to the second network, wherein the first network is an evolved-universal terrestrial radio access network (E-UTRAN) terrestrial network (TN) and the second network is a narrowband internet of things (NB-IoT) non-terrestrial network (NTN).

[0024] According to an aspect of the disclosure, a user equipment (UE) in a communication system is provided. The UE comprises a transceiver; and at least one processor coupled with the transceiver and configured to receive, from a network entity of an evolved-universal terrestrial radio access network (E-UTRAN), a radio resource control (RRC) message including redirect carrier information, wherein the redirect carrier information indicates carrier information to redirect the UE from a first network to a second network, and to perform a cell selection based on the redirect carrier information, wherein the first network is an EUTRAN terrestrial network (TN) and the second network is a narrowband internet of things (NB-IoT) non-terrestrial network (NTN).

[0025] According to an aspect of the disclosure, a network entity in a communication system is provided. The network entity comprises a transceiver; and at least one processor coupled with the transceiver and configured to determine a redirection of a user equipment (UE) from a first network to a second network, and transmit, to the UE, a radio resource control (RRC) message including redirect carrier information, wherein the redirect carrier information indicates carrier information to redirect the UE from the first network to the second network, wherein the first network is an evolved-universal terrestrial radio access network (E-UTRAN) terrestrial network (TN) and the second network is a narrowband internet of things (NB-IoT) non-terrestrial network (NTN).

[0026] According to a first aspect of the disclosure, there is provided a user equipment (UE) configured to: receive, from a first network, an indication to redirect to a second network, wherein the indication includes information on a carrier frequency of the second network and / or information on a carrier frequency offset; wherein the first network is an Evolved-Universal Terrestrial Radio Access Network (E-UTRAN) terrestrial network (TN) and the second network is a Narrowband Internet of Things (NB-IoT) non-terrestrial network (NTN).

[0027] According to an example, the indication is included in a RRC message received by the UE.

[0028] According to an example, the RRC message is a RRCConnectionRelease message.

[0029] According to an example, the UE is further configured to: signal an indication of a capability of the UE to be redirected to an NB-IoT NTN cell.

[0030] According to an example, the UE is further configured to: transmit, to the first network, information on UE capability on redirection or fallback.

[0031] According to an example, the information on UE capability includes an indication of at least one specific frequency band supported by the UE for redirection.

[0032] According to an example, the at least one specific frequency band is at least one NB-IoT frequency band supported by the UE for redirection from an E-UTRAN TN to a NB-IoT NTN.

[0033] According to an example, the redirection is an Evolved Packet System (EPS) fallback.

[0034] According to an example, the redirection is a Multimedia Priority Services (MPS) redirection.

[0035] According to an example, the UE is configured to establish with an NB-IoT NTN cell on the indicated frequency, and indicate a high priority access establishment cause.

[0036] According to a second aspect of the disclosure, there is provided an entity in a first network, wherein the first network is an Evolved-Universal Terrestrial Radio Access Network (E-UTRAN) terrestrial network (TN), and the entity configured to: transmit, to a user equipment (UE), an indication to redirect to a second network, wherein the indication includes information on a carrier frequency of the second network and / or information on a carrier frequency offset; wherein the second network is a Narrowband Internet of Things (NB-IoT) non-terrestrial network (NTN).

[0037] According to an example, the indication is included in a RRC message transmitted to the UE.

[0038] According to an example, the RRC message is a RRCConnectionRelease message.

[0039] According to an example, the entity is further configured to: receive, from the UE, an indication of a capability of the UE to be redirected to an NB-IoT NTN cell.

[0040] According to an example, the entity is further configured to: receive, from the UE, information on UE capability on redirection or fallback.

[0041] According to an example, the information on UE capability includes an indication of at least one specific frequency band supported by the UE for redirection.

[0042] According to an example, the at least one specific frequency band is at least one NB-IoT frequency band supported by the UE for redirection from an E-UTRAN TN to a NB-IoT NTN.

[0043] According to an example, the redirection is an Evolved Packet System (EPS) fallback.

[0044] According to an example, the redirection is a Multimedia Priority Services (MPS) redirection.

[0045] According to a third aspect of the disclosure, there is provided a method of a user equipment, the method comprising: receiving, from a first network, an indication to redirect to a second network, wherein the indication includes information on a carrier frequency of the second network and / or information on a carrier frequency offset; wherein the first network is an Evolved-Universal Terrestrial Radio Access Network (E-UTRAN) terrestrial network (TN) and the second network is a Narrowband Internet of Things (NB-IoT) non-terrestrial network (NTN).

[0046] According to various examples, the method of the third aspect of adapted to include features or steps corresponding to the features or steps of any of the examples relating to the first aspect.

[0047] According to a fourth aspect of the disclosure, there is provided method of an entity in a first network, wherein the first network is an Evolved-Universal Terrestrial Radio Access Network (E-UTRAN) terrestrial network (TN), and wherein the method comprises: transmitting, to a user equipment (UE), an indication to redirect to a second network, wherein the indication includes information on a carrier frequency of the second network and / or information on a carrier frequency offset; wherein the second network is a Narrowband Internet of Things (NB-IoT) non-terrestrial network (NTN).

[0048] According to various examples, the method of the fourth aspect of adapted to include features or steps corresponding to the features or steps of any of the examples relating to the second aspect.

[0049] According to a fifth aspect of the disclosure, there is provided a computer-readable storage medium comprising instructions which, when executed by at least one processor of at least one electronic device, collectively or individually, cause the at least one electronic device to perform a method according to any one of the third aspect, the fourth aspect, or the above-described examples relating to the third aspect or the fourth aspect.

[0050] According to a sixth aspect of the disclosure, there is provided a network comprising a UE according to the first aspect and an entity according to the second aspect.

[0051] Other aspects, advantages, and salient features of the disclosure will become apparent to those skilled in the art from the following detailed description taken in conjunction with the accompanying drawings.

[0052] According to example embodiments of the present disclosure, a UE may receive an indication including carrier frequency information and / or carrier frequency offset information for a second network, such as an NB-IoT NTN, and perform redirection from a first network, such as an E-UTRAN TN, to the second network. In addition, the UE may signal capability information indicating supported frequency bands for redirection. Accordingly, efficient redirection from the terrestrial network to the NB-IoT NTN may be supported, and a connection with an NB-IoT NTN cell may be reliably established, thereby improving service continuity and supporting priority access scenarios such as EPS fallback or MPS redirection.

[0053] Embodiments / examples of the present disclosure are further described hereinafter with reference to the accompanying drawings, in which:

[0054] Figure 1A shows a schematic representation of an example of a NTN transparent architecture, and Figure 1B shows a schematic representation of an example of a NTN regenerative architecture.

[0055] Figure 2 is a call flow diagram showing an initial / random access procedure according to various examples.

[0056] Figure 3 is a call flow diagram showing a RRC (connection) release or redirection according to various examples.

[0057] Figure 4 is a call flow diagram showing EPS fallback for IMS voice according to various examples.

[0058] Figure 5 is a call flow diagram showing emergency service fallback according to various examples.

[0059] Figure 6 is a call flow diagram showing a method for falling back to NTN according to various examples of the present disclosure.

[0060] Figure 7 is a call flow diagram showing a method for MPS redirection according to various examples of the present disclosure.

[0061] Figure 8 is a call flow diagram showing a method for EPS fallback according to various examples of the present disclosure.

[0062] Figure 9 is a call flow diagram showing a method for EPS fallback based on measurement according to various examples of the present disclosure.

[0063] Figure 10 is a call flow diagram showing a method for emergency fallback according to various examples of the present disclosure.

[0064] Figure 11 is a block diagram illustrating an example structure of a network entity according to various examples of the present disclosure.

[0065] Figure 12 is a flow diagram illustrating a method of a UE according to an embodiment of the disclosure.

[0066] Figure 13 is a flow diagram illustrating a method of a network or network entity according to an embodiment of the disclosure.

[0067] Figure 1A illustrates a transparent architecture for a NTN (e.g. NTN Release 17 transparent architecture), and Figure 1B illustrates a regenerative architecture for a NTN (e.g. NTN Release 19 regenerative architecture).

[0068] In Figure 1A, an NTN is shown to comprise NTN cell 101 and a NTN entity 113 associated with (e.g. controlling or configuring) NTN cell 101. The NTN entity 113 is connected to a gateway 103 via feeder link 115. The gateway 103 is connected to eNB / gNB 105, which communicates with core network 107. It will be appreciated that gateway 103 and eNB / gNB 105 may be co-located or implemented together. A UE 109 is located within NTN cell 101. The UE 109 is connected to NTN entity 113 via access link 111. Accordingly, the UE 109 is connected to core network 107 via the NTN entity 113.

[0069] In Figure 1B, an NTN is shown to comprise NTN cell 121 and a NTN entity 131 associated with (e.g. controlling or configuring) NTN cell 121. The NTN entity 131 is connected to a gateway 123 via feeder link 133. A eNB or gNB is implemented in NTN entity 131, e.g. NTN entity 131 provides eNB / gNB functionality. The gateway 123 is connected to core network 125. A UE 127 is located within NTN cell 121. The UE 127 is connected to NTN entity 131 via access link 129. Accordingly, the UE 127 is connected to core network 125 via the NTN entity 131.

[0070] Following the Work items in Release 17 there were work items to enhance NR NTN (RP-220953 [3]) and IoT NTN (RP-223519 [4]) in Release 18.

[0071] The work item description for IoT NTN Rel-19 is the following (RP-234077 [5]):

[0072] - Support of Store&Forward (S&F) satellite operation with full eNB as regenerative payload, therefore:

[0073] > Define the necessary enhancements into E-UTRAN (network & UE) to support S&F operation for delay-tolerant services [RAN3, RAN2, RAN4]

[0074] >> At least specify necessary enhancements e.g. related to S1 protocol, especially to address the feeder link switch over as needed [RAN3]

[0075] Note: Strive to minimise UE impact.

[0076] Note: Coordination with SA2 (Rel-19 SA2 led Sat-Arch ph3 SI) is needed on the detail requirements (e.g. traffic type, or QoS parameters for S&F), network architecture (e.g. whether consider (partial) core network on satellite) etc.; further coordination with CT1 might be required

[0077] - Support of Capacity enhancements for uplink

[0078] > Study then specify, if beneficial, enhancements to enable multiplexing of multiple UEs (e.g. up to the min of 4 and the maximum allowed by the existing UL and DL signalling) in a single 3.75 kHz or 15 kHz subcarrier via orthogonal cover codes (OCC) for NPUSCH format 1 and NPRACH [RAN1, RAN2]

[0079] >> Multi-tone support for 15 kHz SCS should also be considered

[0080] Note: Impact of impairment shall be taken into account

[0081] > Study and specify, if beneficial the following enhancements to reduce the necessary uplink and downlink signaling to complete an EDT transaction [RAN2]:

[0082] >> Msg3 transmission without msg1 / RAR

[0083] >> Efficient delivery (reduced overhead) of msg4 / RRCEarlyDataComplete

[0084] Narrowband Internet of Things and LTE-M

[0085] Narrowband Internet of Things (NB-IoT) is a 3GPP-defined network based on 4G E-UTRAN that supports ultra-low complexity devices with very narrow bandwidth that was introduced in 3GPP Release 13. It supports the massive Machine Type Communication (mMTC) 5G use case for IMT-2020. The use case of NB-IoT is to serve massive IoT application, where requirements for instance are to support enhanced coverage, power-efficient operation and a massive number of devices. Some of the features introduced are:

[0086] Support for enhanced coverage through low bandwidth and extreme amounts of repetitions.

[0087] Power efficient operation by allowing the UE to sleep for very long times, relaxed requirements and more efficient signal to establish with a cell.

[0088] LTE-M (or eMTC) is another technology that serves the mMTC 5G use case. Compared to NB-IoT, an LTE-M device is more like a simplified 4G E-UTRAN device with certain simplifications allowing for easier and cheaper implementation. It addressed a slight wider use case compared to NB-IoT, with higher data rates and is not quite as power efficient as NB-IoT. This type of device may also be referred to as a Cat M1 / 2 device or as Bandwidth Limited (BL) UE and UE in enhanced coverage.

[0089] Both LTE-M and NB-IoT are specified with what is known as User plane and Control plane enhancements for reduced signaling. In user plane solution, the UE supports AS security and Data radio bearers.

[0090] In control plane, the UE does not support AS security and instead relies on NAS for security, which means that all data is routed through MME. Control Plane IoT has several impacts on the radio interface. One of these is that the UE may only be configured once when the UE establishes its connection and may not be reconfigured. The configuration is done via RRCConnectionSetup or RRCConnectionResume message, sometimes known as Msg4. Furthermore, DRBs may not be setup. Control plane is mandatory for NB-IoT and optional for LTE-M.

[0091] Initial / random access procedure in IoT NTN

[0092] An example of an initial access procedure can be seen in Figure 2.

[0093] In operation S210, the UE 210 is in RRC idle mode or RRC inactive mode (or not in RRC connected mode).

[0094] In operation S220, the UE 210 determines the timing advance (TA) pre-compensation using the UE position and the satellite position. The UE position is via GNSS, but other methods that do not rely on the network may also potentially be used, such as using inertial navigation system or similar. The satellite position is acquired via SIB19 or SIB31 and the UE also pre-compensates using TA-Common, which is the common timing advance from the satellite to the ground gate way where the base station resides.

[0095] In operation S230, the UE 210 uses the pre-compensation and sends Msg1 which is the RACH (random access channel) preamble. The RACH preamble will represent a number between 1 and 64. The number selected by the UEis random, but there exists several rules to determine the range of preambles, depending on configurations and conditions - sometimes referred to as preamble division.

[0096] In operation S240, if the network (e.g. eNB or gNB 220, CN etc.) is able to detect and determine the RACH preamble, the eNB 220 responds with Msg1 or RAR (random access response). The RAR is scheduled by PDCCH (physical downlink control channel), which is scrambled based on the resource that the Msg1 was sent in.

[0097] In operations S250 and S260 (note, these may be combined into a single operation of scheduling and sending Msg3), the UE 210 sends Msg3, which is sent using PUSCH (physical uplink shared channel). This message contains the first RRC message, which may be a RRC request. The RRC message depends on the specific reason why the random access procedure was triggered. For example: for initial access it will be RRCSetupRequest; for resuming it is RRCConnectionResumeRequest; for re-establishing RRC it is RRCConnectionReestablishmentRequest; for CP-EDT it is RRCEarlyDataRequest etc. All of the RRC messages will contain an establishment, remove or re-establishment request. This indicates the reason for establishing, removing or re-establishing the connection. This can for instance indication whether the UE has mobile-originated data, or mobile terminated data, or if there is an emergency call on-going.

[0098] In operation S270, since it is possible that two UEs select the same RAPID (random access preamble ID), there is a chance of collision. So in Msg4, sent over PDSCH in operation S270, this contention may be resolved using the Contention Resolution MAC CE. Msg4 also contains an RRC message that is a response to Msg3. This can for instance be RRCConnectionSetup, RRCConnectionResume, RRCConnectionReestablishment, RRCReject, RRCEarlyDataComplete etc. Some of these message may include the UE configuration to use in RRC connected. RRC Connection Setup, for example, configures or establishes SRB1, which can be used for continued configuration

[0099] In operation S280, the UE 210 sends Msg5. Msg5 is a further message that is scheduled uplink message which would consist of the reply to the downlink RRC message in Msg4. Msg5 is sometimes not considered a part of the random access procedure, but a part of any access procedures. The RRC message carried in Msg5 may be RRCConnectionSetupComplete, RRCConnectionResumeComplete, RRCConnectionReestablishmentComplete and so on. The Msg5 can for instance contain a NAS message. For RRC setup, this is can be used for initial establishment or to request service, which is forwarded to the MME or AMF. The Msg5 may also contain various indications, such as existence of UE assistance data etc.

[0100] In some cases, the steps S220, S230 and S240 are not shown for RRC procedures as they are part of lower layer procedures. For 2-step random access, steps S230 and S260 are combined to a MsgA and steps S240 and S270 are combined to MsgB.

[0101] RRC (Connection) Release or redirection

[0102] One way to enter RRC idle or RRC inactive mode is by the network releasing the UE through the RRC release procedures. The RRC release procedures are initiated when the UE receives a RRCRelease message from the gNB or RRCConnectionRelease message in E-UTRAN. An example of this can be seen in Figure 3.

[0103] In step S310a, the network (e.g. eNB / gNB 320, which may more generally be a base station or NG-RAN node, and / or core network, CN, 330) decides (or determines, chooses etc.) whether to release UE 310.

[0104] In step S310b, CN 330 indicates to eNB / gNB 320 to release UE 310, e.g. transmitting a message or signalling to eNB / gNB 320 indicating this.

[0105] In step S320, eNB / gNB 320 releases UE 310, e.g. performs procedures to release UE 310 to RRC idle or inactive.

[0106] In step S330, UE 310 enters RRC idle or RRC inactive (e.g. depending on release).

[0107] In step S340, UE 310 performs cell selection or reselection and camps on a cell and, optionally, accesses the cell.

[0108] The RRCRelease message sent from the gNB may in turn have been triggered by the either the gNB or the AMF. This can be, for example, due to any of the following reasons:

[0109] - Load balancing.

[0110] - Re-direction (both in RRC idle and RRC inactive) to other frequencies or RATs.

[0111] > Redirection is a form of network-controlled mobility procedures. This can often be used for inter-RAT mobility. A UE that is redirected will often attempt to connect to the new cell or frequency that it camps on.

[0112] - UE context release triggered by the AMF (CN).

[0113] - Suspend indication to send the UE to RRC inactive.

[0114] - Failure to retrieve UE context when UE resumes RRC connection from RRC inactive.

[0115] The RRC release message may, for example, include any one or more of the following information elements:

[0116] - redirectedCarrierInfo - Information on carriers to re-direct to, which may be inter or intra-RAT frequencies.

[0117] - cellReselectionPriorities - Cell reselection priorities - these may be specifically configured for the UE in the RRCRelease message.

[0118] - suspendConfig - Configuration for RRC inactive.

[0119] - deprioritisationReq - Indicates whether the current frequency or RAT is to be de-prioritised.

[0120] - waitTime - Waiting time before the UE starts performing cell reselection to find a new cell.

[0121] - measIdleConfig - Measurement configuration for idle mode. Used to measure and store measurement information to be reported to the network when re-connecting.

[0122] - sdtConfig - Configurations for Short Data Transmissions (allows UE to send a usually smaller amount of data in RRC inactive mode).

[0123] - srs-PosRRC-Inactive - SRS configuration to be used for RRC inactive positioning.

[0124] The RRC release message may include any one or more of the following timers:

[0125] - waitTime (T302): Timer to bar the UE from attempting to perform access attempts

[0126] - T320: How long the cell configured cell reselection priorities shall be active

[0127] - T380: This timer triggers the periodic Radio Notification Area Update procedures. In other words, the UE performs the Radio Notification Area Update after expiry of the signalled T380.

[0128] When a UE receives the RRCRelease message, the specification (e.g. 3GPP technical specification) allows for some time before performing the RRCRelease procedures. This is so that the RRCRelease message may be properly acknowledge to ensure that there are no state mismatch between gNB and UE. If this time is not applied the RRCRelease message without waiting, the gNB will not know whether the RRCRelease message has been received or not. The time before applying this is 60 ms in 5G NR, 1.25 seconds in LTE-M and 10 seconds in NB-IoT.

[0129] EPS fallback for IMS voice

[0130] EPS (evolved packet system) fallback allows the network to fallback to EPC to establish or continue voice connectivity. The purpose of this can be, for example, that only EPC is supported for voice services, or that EPC connectivity is more robust. This fallback can either be intra-RAT or inter-RAT.

[0131] An example procedure can be seen in Figure 4.

[0132] In step S410, a MO (mobile originating) or MT (mobile terminating) IMS (IP multimedia subsystem) voice session in 5GS is ongoing, where QoS flow for voice establishment is initiated (e.g. ongoing).

[0133] In step S420, the network initiates PDU (protocol data unit, or packet data unit) session modification to set up QoS flow for IMS voice. That is, step S240 may relate to NW (network) initiated PDU session modification to set up the QoS flow for IMS voice.

[0134] In step S430, NG-RAN 420 detects a trigger for fallback or triggers fallback.

[0135] In step S440, there is rejection of PDU session modification indicating IMS voice fallback is in progress. That is, the PDU session modification is rejected, indicating that IMS voice fallback is in progress (e.g. as a reason for rejection).

[0136] In step S450, redirection or handover to EPS is performed.

[0137] In step S460a, TAU (tracking area update) procedure occurs or is performed.

[0138] In step S460b, there is attach with PDN (packet data network) connectivity request type “handover”.

[0139] In step S470, there is network initiated PDN connection modification to set up dedicated bearer to voice.

[0140] For step S450, there are two options in the example method:

[0141] Option 1: Redirection via RRC release from NR to E-UTRAN. Indicates voiceFallbackIndication in the RRCRelease message, which is used to indicate that the release is for the purpose of EPS fallback.

[0142] Option 2: Handover from NR to E-UTRAN. In this case, the network also indicates the voiceFallbackIndication in the command to perform mobility, i.e. the MobilityFromNRCommand. This can be used in case of a failed mobility attempt, whereby the UE shall search for other suitable E-UTRAN cells and attempt to connect to them.

[0143] Emergency service fallback

[0144] Network support of emergency service fallback is used for falling back to other RATs in case of emergency services. The network indicates the supported falling back options to the UE when establishing the NAS connection. UE starts emergency session and may then be rerouted via Inter-RAT handover or redirection to E-UTRAN and / or EPS. This is done via a message N2 request for Emergency fallback.

[0145] An example of this procedure is shown in Figure 5.

[0146] In step S510, UE 510 camps on 5GS. That is, this step simply describes the situation where UE 510 is camping on 5GS, e.g. a 5G cell.

[0147] In step S520, the user of UE 510 triggers an emergency session.

[0148] In step S530, UE 510 transmits a service request to CN 530 (e.g. 5GS or EPS).

[0149] In step S540, CN 530 transmits to NG-RAN 520 a N2 request for emergency fallback.

[0150] In step S550a, inter-RAT handover of RRC redirection to 5GC-connected E-UTRA is performed.

[0151] In step 550b, inter-system handover or RRC direction to EPS is performed.

[0152] In step 560, IMS procedures for establishment of IMS emergency session is performed.

[0153] MPS (Multimedia Priority Services)

[0154] MPS allows users priority access to system resources, for example during congestion or other types of emergency. This is done by ensuring that the network prioritizes MPS users. The MPS-capable user may be configured with an MPS subscription, which gives the user a special Access Identity.

[0155] For instance, when a UE connects to a network, then the UE will indicate to the base station that it is connecting for the purpose of MPS priority access via an establishment cause in RRCSetup or RRCResume message. This establishment cause is then forwarded from the RAN to the AMF when the connection is established in the INITIAL UE MESSAGE or the UE CONTEXT RESUME REQUEST message.

[0156] NTNs, which are currently being designed / planned, are expected to allow for a more resilient connection by providing connectivity in areas where the coverage or the capacity is insufficient or could be improved. One example of a main use case of this is for emergency purposes. For instance, in upcoming 3GPP releases, it is expected that 3GPP will work on specifying voice over NB-IoT NTN and voice over GEO NTN. One purpose for this is to allow for emergency calls in areas that lack or have poor terrestrial network coverage. It is envisioned that a device may have support for typical terrestrial cellular connectivity (GERAN, UTRAN, E-UTRAN, NR) as well as non-terrestrial connectivity via either NB-IoT NTN, eMTC NTN or NR NTN for emergency cases.

[0157] While the standards (e.g. technical specifications) for mobility from TN (terrestrial network) to NTN are being developed, there are several mobility-types for which NTN has yet to be discussed. This includes EPS fallback from 5GC for IMS voice, emergency services fallback and MPS priority access.

[0158] The following description of examples of the present disclosure, with reference to the accompanying drawings, is provided to assist in a comprehensive understanding of certain examples of the present disclosure. The description includes various specific details to assist in that understanding but these are to be regarded as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the examples described herein can be made without departing from the scope of the invention or disclosure.

[0159] The same or similar components may be designated by the same or similar reference numerals, although they may be illustrated in different drawings.

[0160] Detailed descriptions of techniques, structures, constructions, functions or processes known in the art may be omitted for clarity and conciseness, and to avoid obscuring the subject matter of the present disclosure.

[0161] The terms and words used herein are not limited to the bibliographical or standard meanings, but are merely used to enable a clear and consistent understanding of the disclosure.

[0162] Throughout the description of this specification, the words “comprise”, “include” and “contain” and variations of the words, for example “comprising” and “comprises”, means “including but not limited to”, and is not intended to (and does not) exclude other features, elements, components, integers, steps, processes, operations, functions, characteristics, properties and / or groups thereof.

[0163] Throughout the description of this specification, the singular form, for example “a”, “an” and “the”, encompasses the plural unless the context otherwise requires. For example, reference to “an object” includes reference to one or more of such objects.

[0164] Throughout the description, the expression “at least one of A, B and / or C” (or the like), the expression “and / or”, and the expression “one or more of A, B and / or C” (or the like) should be seen to separately include all possible combinations, for example: A, B, C, A and B, A and C, A and B and C.

[0165] Throughout the description of this specification, language in the general form of “X for Y” (where Y is some action, process, operation, function, activity or step and X is some means for carrying out that action, process, operation, function, activity or step) encompasses means X adapted, configured or arranged specifically, but not necessarily exclusively, to do Y.

[0166] Features, elements, components, integers, steps, processes, operations, functions, characteristics, properties and / or groups thereof described or disclosed in conjunction with a particular aspect, embodiment or example are to be understood to be applicable to any other aspect, embodiment or example described herein unless incompatible therewith.

[0167] Certain examples of the present disclosure relate to methods, apparatus and / or systems for fallback or redirection to NTN. In various examples, based on determining to fallback, a network signals for a UE to fallback to NTN RAN, such as from a TN RAN to a NTN RAN. In an example, this determination is based on the UE signalling capability to fallback to NTN, and / or the NTN supporting a service relating to a cause for fallback. A cause of fallback may, in some examples, be an emergency service or call situation. Various examples relate to fallback in the case of specific RATs, e.g. falling back from one RAT to another RAT. Certain examples of the present disclosure relate to methods, apparatus and / or systems for priority-based redirection to a NTN. For example, a UE may be MPS redirected from a TN to a NTN based on signalling from a network. In an example, this determination is based on the UE signalling capability for NTN MPS redirection. Various examples relate to UE mobility, UE and / or network capabilities relating to mobility, UE position reporting and / or RAT restrictions.

[0168] The following examples are applicable to, and use terminology associated with, 3GPP 5G. However, the skilled person will appreciate that the techniques disclosed herein are not limited to these examples or to 3GPP 5G, and may be applied in any suitable system or standard, for example one or more existing and / or future generation wireless communication systems or standards. The skilled person will appreciate that the techniques disclosed herein may be applied in any existing or future releases of 3GPP 5G NR or any other relevant standard. For example, the functionality of the various network entities and other features disclosed herein may be applied to corresponding or equivalent entities or features in other communication systems or standards. Corresponding or equivalent entities or features may be regarded as entities or features that perform the same or similar role, function, operation or purpose within the network. In particular, the following disclosure should be considered at least in relation to 6G also, which is expected to use at least part of the 5G architecture, or equivalent, and to which the present disclosure also relates.

[0169] A particular network entity may be implemented as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, and / or as a virtualised function instantiated on an appropriate platform, e.g. on a cloud infrastructure.

[0170] The skilled person will appreciate that the present disclosure is not limited to the specific examples disclosed herein. For example:

[0171] - The techniques disclosed herein are not limited to 3GPP LTE, LTE-A, 5G, B5G or 6G.

[0172] - One or more entities in the examples disclosed herein may be replaced with one or more alternative entities performing equivalent or corresponding functions, processes or operations.

[0173] - One or more of the messages in the examples disclosed herein may be replaced with one or more alternative messages, signals or other type of information carriers that communicate equivalent or corresponding information.

[0174] - One or more further elements, entities and / or messages may be added to the examples disclosed herein.

[0175] - One or more non-essential elements, entities and / or messages may be omitted in certain examples.

[0176] - The functions, processes or operations of a particular entity in one example may be divided between two or more separate entities in an alternative example.

[0177] - The functions, processes or operations of two or more separate entities in one example may be performed by a single entity in an alternative example.

[0178] - Information carried by a particular message in one example may be carried by two or more separate messages in an alternative example.

[0179] - Information carried by two or more separate messages in one example may be carried by a single message in an alternative example.

[0180] - The order in which operations are performed may be modified, if possible, in alternative examples.

[0181] - The transmission of information between network entities is not limited to the specific form, type and / or order of messages described in relation to the examples disclosed herein.

[0182] Certain examples of the present disclosure may be provided in the form of an apparatus / device / network entity configured to perform one or more defined network functions and / or a method therefor. Such an apparatus / device / network entity may comprise one or more elements, for example one or more of receivers, transmitters, transceivers, processors, controllers, modules, units, and the like, each element configured to perform one or more corresponding processes, operations and / or method steps for implementing the techniques described herein. For example, an operation / function of X may be performed by a module configured to perform X (or an X-module). Certain examples of the present disclosure may be provided in the form of a system (e.g., a network) comprising one or more such apparatuses / devices / network entities, and / or a method therefor.

[0183] It will be appreciated that examples of the present disclosure may be realized in the form of hardware, software or a combination of hardware and software. Certain examples of the present disclosure may provide a computer program comprising instructions or code which, when executed, implement a method, system and / or apparatus in accordance with any aspect, example and / or embodiment disclosed herein. Certain embodiments of the present disclosure provide a machine-readable storage storing such a program.

[0184] A network according to one or more of the examples disclosed herein may include one or more of a Network Data Analytics Function (NWDAF) entity, an Access and Mobility Management Function (AMF) entity, a Session Management Function (SMF) entity, a Network Slice Selection Function (NSSF) entity, a Network Repository Function (NRF) entity, Application Function (AF) entity, and an Operation and Maintenance (OAM) entity. The network may include one or more Service Consumers (including one or more of the entities mentioned above and / or one or more other entities) that receive analytics from NWDAF. The skilled person will appreciate that a network may omit one or more of the entities mentioned above and / or may comprise one or more additional entities.

[0185] All proposals, embodiments, and examples disclosed herein may also apply for, but are not limited to, NR NTN, LTE-M / eMTC NTN, E-UTRA NTN or even 6G NTN.

[0186] As described above, while the standards for mobility from TN to NTN are being developed, there are several mobility-types for which NTN has yet to be discussed. This includes EPS fallback from 5GC for IMS voice, emergency services fallback and MPS priority access. The present disclosure includes examples, aspects, embodiments etc. which aim to allow for fallback and / or high priority access from TN to NTN for one or more of these different mobility-types.

[0187] An embodiment of the present disclosure is illustrated in Figure 6.

[0188] Figure 6 illustrates a method performed by UE 610, NTN RAN 620 (e.g. a first base station, NTN eNB or gNB, or NTN base station), TN RAN 630 (e.g. a second base station, TN eNB or gNB, or TN base station) and CN 640.

[0189] In step S610a, the network, which may be either RAN, the core network 640 or other network entities, checks (e.g. identifies, determines, verifies, etc.) whether the UE 610 is capable or allowed to fallback to NTN. This may comprise receiving an indication from the UE 610 that the UE 610 supports fallback to NTN. In another example, this may comprise determining whether the UE 610 is capable or allowed to fallback to NTN based on previous behaviour of the UE 610.

[0190] In step S610b, CN 640 determines (or decides, chooses, is caused etc.) to send an indication to fallback (e.g. for the UE 610 to fallback). This may be an explicit indication to fallback to NTN, or may just be a general indication to fallback.

[0191] In step S610c, CN 640 indicates the UE 610 is to fallback. That is, an indication may sent by the CN 640 to RAN 630 to fallback the UE 610.

[0192] In step S620, the TN RAN 630 sends an indication to the UE 610 to fallback to NTN, e.g. NTN RAN 620.

[0193] In step S630, UE 610, as a result of receiving the indication to fallback to NTN, fallbacks to an NTN, e.g. NTN RAN 620.

[0194] The NTN RAN 620 may indicate to the CN 640 or IMS system whether it supports emergency voice call / services over NTN or not. If the NTN RAN 620 or the associated NTN cell(s) that may serve the UE 610 (e.g. if / once fallback is performed, or UE 610 establishes with NTN RAN 620) do not support voice call / services and / or call emergency voice call / services over NTN, the core network / IMS system may not determine to fallback to the corresponding RAN or cells (e.g. NTN RAN 620 or associated NTN cell(s)). The NTN RAN 620 may report the capability on supporting voice call / services and call emergency voice call / services over NTN to the core (e.g. 5GC, EPC) or IMS when establishing or modifying the connection between RAN and core (e.g. NG, S1, X1 connection). Or the CN 640 or IMS may determine to require the capability from RAN (e.g. NTN RAN 620) based on its own decision, e.g. if the CN 640 or IMS determine to re-route the call from TN to NTN, etc. It will be appreciated that various examples of the present disclosure cover the method of NTN RAN 620 reporting its capability to the core network, e.g. separate to, and / or in combination with, the method of FIG. 6 in which a UE (e.g. UE 610) may be directed to fallback.

[0195] While various examples of the present disclosure may focus on fallback from a terrestrial network (TN) to a non-terrestrial network (NTN), other examples of the present disclosure consider the case of fallback from a non-terrestrial network to a terrestrial network. In such examples, a UE may indicate its capability to perform fallback from a non-terrestrial network to a terrestrial network. For example, this indication may be sent to the core network or RAN, e.g. a NTN RAN to which the UE is initially connected.

[0196] Additionally, while various examples of the present disclosure may relate to fallback-related mechanisms, e.g. during emergency or similar, such (or other) examples may also apply to a case where a UE (e.g. UE 610) is only connected to NTN, for instance a NB-IoT NTN, eMTC NTN, NR NTN or any type 6G NTN. That is, cases of fallback from an NTN to another type of network. Fallback from one type of NTN to another type of NTN may also be supported. Various examples are also applicable for general mobility, e.g. to NB-IoT NTN.

[0197] MPS redirection

[0198] According to various embodiments of the present disclosure, a UE may be MPS redirected from a terrestrial network to a non-terrestrial network. This may be done by redirecting a UE, e.g. using RRC release (or other release mechanism) and setting (or providing, configuring etc.) an indication that the redirection is for MPS priority (e.g. such an indication may be provided to or configured in CN or RAN). This may be indicated in the RRCRelease or RRCConnectionRelease message using mpsPriorityIndication (or similar element) when the UE is redirected to an NTN cell. A related specification example of this can be seen in Specification Example #2 (see below). It may also be an NTN-specific MPS priority indication, i.e. an indication that the UE shall perform MPS redirection to an NTN cell.

[0199] An example of the MPS redirection to NTN can be seen in Figure 7.

[0200] In step S710, UE 710 sends or signals an indication of capability of NTN MPS redirection. This is sent to TN eNB or gNB 730 (e.g. TN RAN). It will be appreciated that the indication may be included with other signalling or transmissions or sent separately.

[0201] In step S720, TN eNB / gNB 730, or core network (not shown) determines or decides whether to fallback to NTN (i.e. whether the UE 710 is to fallback).

[0202] In step S730, e.g. based on the decision in S720, TN eNB / gNB 730 indicates MPS redirection to NTN to UE 710. For example, the TN eNB / gNB 730 sends an indication or message to UE710 to redirect (e.g. perform MPS redirection) to NTN.

[0203] In step S740, the UE 710 establishes with NTN eNB / gNB 720 (e.g. NTN RAN). The establishing may be with or based on an establishment cause indicating MPS redirection; e.g. the UE 710 may indicate to NTN eNB / gNB 720 that an establishment cause of MPS redirection. In other words, the NTN eNB / gNB 720 may be aware that the establishment relates to MPS redirection.

[0204] In various examples, upon receiving the redirection to NTN (i.e. following S730), UE 710 will then perform access in the selected NTN cell by setting an indication that the access attempt is for high priority access. For instance, in a case of an NR NTN cell (e.g. associated with NTN eNB / gNB 720), UE 710 may set the establishment or resume cause as mps-PriorityAccess (or another indication of MPS access). In a case of an E-UTRAN NTN, e.g. an eMTC NTN cell, UE 710 may set the establishment or resume cause as highPriorityAccess (or another indication of high priority access). In a case of an NB-IoT NTN cell, since there currently is no true high priority access establishment cause, according to various examples of the present disclosure, the UE indicates a newly introduced indication indicating high priority. A legacy indication may also or alternatively be used, such as mo-ExceptionData. In various examples, UE 710 may use an indication of voice call, which may be used if the access is for voice call, but also for other (i.e. different) types of MPS access. The indication may combine voice calls, emergency and / or fallback indication, which means that the UE 710 would use one (or multiple) indications for one or more of the reasons for connecting: voice calls, emergency, priority access and / or fallback. For example, for voice call and fallback, one type of establishment cause may be signalled, and for emergency and priority access, one value may be signalled. One example of this can be seen in Specification Example #1 (see below). This may be useful for any type of fallback or emergency call initiation.

[0205] If a UE (e.g. UE 710) is configured to redirect to an NTN cell (e.g. associated with NTN eNB / gNB 720) for MPS priority, then the network (e.g. CN) may include any type of NTN information. For example, as a result any type of NTN redirection information element or other information shall be included. The mpsPriorityIndication field may be also be present if the network signals redirection to NTN, e.g. via the fields redirectedCarrierInfo (used for NTN) or ntn-RedirectedCarrierInfo, or similar. A new field specifically to indicate MPS priority redirection to NTN may also be indicated. In various examples, a redirection indication may always need (i.e. be required) to include NTN ephemeris for the redirection to NTN. In another example, for MPS priority redirection, the network may include only a single ephemeris element. This may allow for faster access in the NTN cell by only having the UE needing to search on ephemeris element.

[0206] Whether a UE (e.g. UE 710) is capable of performing MPS redirection to NTN can be signalled as part of radio capabilities to a base station (e.g. to TN eNB / gNB 730), or be part of NAS capabilities signalled to an AMF (e.g. or, more generally, an entity in CN). If the UE indicates that MPS redirection to an NTN cell is supported, then in various examples the UE may indicate, or be required to indicate, that redirection to NTN is supported. It may also be considered that a UE supports MPS redirection to an NTN cell if the UE supports MPS redirection and redirection to an NTN cell, where in this case a separate capability would not be needed. That is, implicit support for MPS redirection to an NTN cell may be understood / determined in the event that the UE has indicated support for MPS redirection and support for redirection to an NTN cell.

[0207] In various examples, a 4G / 5G / 6G network may also indicate to one or more network elements whether a UE (e.g. UE 710) is allowed to be redirected to an NTN cell (e.g. associated with NTN eNB / gNB 720). For example, this may be indicated to a RAN node, or to an AMF or MME. A result of this may be that the UE is allowed to be redirected to an NR NTN, eMTC NTN or NB-IoT cell or RAT. The UE may also be considered to be allowed to be redirected to a 6G cell or RAT. In various examples, this (i.e. that the UE is allowed to be redirected to an NTN cell(s)) is signalled as part of allowed RATs. In various cases this may be useful, as normally the resources in an NTN cell are considerably less compared to a terrestrial cell. This means that only a few users, i.e. a limited number, would be allowed to be redirected to NTN.

[0208] The MPS redirection may be from any RAT to any other RAT, or it may only be intra-RAT. NB-IoT may or may not be considered a separate RAT from E-UTRAN. This may mean that the capability is associated with the specific redirection and or the target RAT or cell redirection. Some examples are:

[0209] - UTRAN TN to NB-IoT NTN;

[0210] - E-UTRAN TN to eMTC NTN;

[0211] - NB-IoT TN to NB-IoT NTN;

[0212] - E-UTRAN TN to NR NTN;

[0213] - NR TN to NR NTN;

[0214] - NR TN to NB-IoT NTN.

[0215] For example, a UE may signal its capability to be redirected to an NB-IoT NTN cell.

[0216] EPS fallback

[0217] According to various embodiments, a UE may fallback from 5GC to EPS which is connected via an NTN RAT, such as NR NTN, eMTC or NB-IoT NTN. An example can be seen in Figure 8.

[0218] In step S810, UE 810 signals capability to fallback to NTN, e.g. to CN 840 (e.g. via TN gNB 830).

[0219] In step S820, the network (e.g. involving either or both of CN 840 and TN gNB 830) determines (or decides, identifies etc.) whether to fallback, i.e. whether UE 810 is to fallback.

[0220] In step S830, e.g. based on determining UE 810 is to fallback, the CN 840 sends an EPS fallback indication to TN gNB 830.

[0221] In step S840, TN gNB 830 sends an EPS fallback to NTN RAN (e.g. NTN eNB 820) to UE 810. This may indicate or be associated with handover or redirection.

[0222] In step S850, UE 810 establishes with NTN eNB 820 (i.e. NTN RAN) using establishment cause indicating EPS fallback.

[0223] In various examples, the EPS fallback to NTN may be configured by or based on a UE (e.g. UE 810) either being configured to handover to an NTN cell or redirected to an NTN cell. In both cases, the UE may need to be configured with NTN assistance information, such as NTN ephemeris or other synchronization-related information.

[0224] In various examples, if the UE (e.g. UE 810) is handed over from TN (e.g. associated with TN gNB 830) to eMTC NTN (e.g. associated with NTN eNB 820), then the UE would receive the MobilityFromNRCommand, which may contain a voiceFallbackIndication. In various examples, if the UE is handed over from TN to NB-IoT NTN, then the target RAT may be indicated to be NB-IoT NTN.

[0225] In various examples, if the UE (e.g. UE 810) is redirected from TN (e.g. associated with TN gNB 830) to NTN (e.g. associated with NTN eNB 820), then a new indication specifically for fallback to NTN may be indicated. If the UE is redirected to NB-IoT NTN, then this may be indicated via new information elements indicating NB-IoT relevant information. For example, this information may include NB-IoT Carrier frequency indication and / or NB-IoT carrier frequency offset. An example of this can be seen in Specification Example #3 (see below). The information for the re-direction to NB-IoT NTN may also be applicable for any type of redirection from E-UTRAN TN to NB-IoT NTN, NR TN to NB-IoT NTN or even 6G TN to NB-IoT NTN.

[0226] In various examples, AMF signals to the RAN that fallback to NTN is supported, that fallback to NTN is requested or that fallback to NTN is allowed. This may be instead of or in addition to a UE (e.g. UE 810) indicating capability to fallback. In various examples, if the RAN has indicated that (or received an indication that) fallback to NTN is supported, the RAN may decide whether to fallback to TN or NTN for EPS fallback. An indication (e.g. a new indication) may be sent from the AMF to the RAN indicating that the UE support redirection from TN to NTN. The AMF may thus include both the already existing Redirection for Voice EPS Fallback along with a new indication Redirection for Voice EPS NTN Fallback. In this case, the RAN may decide whether to fallback to a terrestrial or a non-terrestrial network, cell or frequency. The specific RAT or type of RAT supported may be indicated, for example if the UE supports eMTC NTN or NB-IoT NTN (or other types of RAT). The UE may also indicate support for Control Plane CIoT (cellular internet of things) optimization or User Plane CIoT optimization in the NTN RAT.

[0227] If handover or redirection to NB-IoT is performed, in various examples the network may also indicate to the UE (e.g. UE 810) that target cell (e.g. associated with NTN eNB 820) is using Control plane or User plane CIoT optimization, or that the UE shall connect via Control Plane or User Plane CIoT optimization. This may be indicated by the RAN as part of the redirection message.

[0228] Capability for EPS fallback to NB-IoT or NB-IoT NTN may be signalled as part of radio or NAS capability in a TN. In various examples, the specific bands that are supported, or the specific band that redirection is supported to may be signalled.

[0229] In various examples, EPS fallback is considered to be supported if the UE (e.g. UE 810) supports Voice over E-UTRAN NTN. For instance, if the UE supports voice over NB-IoT (NTN), then the UE may be considered to support EPS fallback from TN to NB-IoT NTN.

[0230] In various examples, EPS fallback is from any supported or relevant RAT, and the specific redirection may be indicated as supported. For example:

[0231] - NR TN (connected to 5GC) to eMTC NTN;

[0232] - NR TN (connected to 5GC) to NB-IoT NTN;

[0233] - E-UTRAN TN (connected to 5GC) to eMTC NTN;

[0234] - E-UTRAN TN (connected to 5GC) to NB-IoT NTN.

[0235] In various embodiments of the present disclosure, e.g. relating to RRC_IDLE or RRC_INACTIVE measurements for EPS fallback, the UE may monitor and measure E-UTRAN, EPS or EPC NTN cells in RRC_IDLE and RRC_INACTIVE and the measurements for the purpose of EPS fallback. An examples of this procedure can be seen in Figure 9.

[0236] In step S910, UE 910 signals capability to fallback to NTN, e.g. to CN 940 (e.g. via TN gNB 930).

[0237] In step S920, UE 910 connects and reports to E-UTRAN NTN cells measured when UE 910 was in RRC idle mode or RRC inactive mode.

[0238] In step S930, the network (e.g. involving either or both of CN 940 and TN gNB 930, and / or other entities) determines (or decides, identifies etc.) whether to fallback, e.g. whether UE 910 is to fallback.

[0239] In step S940, e.g. based on determining the UE 910 is to fallback, CN 940 sends an EPS fallback indication to TN gNB 930 (e.g. TN RAN).

[0240] In step S950, TN gNB 930 determines (or decides, identifies etc.) which NTN cell or frequency the UE 910 is to fallback to. This may be based on the results of step S920.

[0241] In step S960, TN gNB 930 sends EPS fallback to NTN RAN (e.g. NTN eNB 920) to UE 910, e.g. relating to handover or redirection. This may indicate the NTN RAN associated with NTN cell or frequency determined in step S950.

[0242] In step S970, UE 910 establishes with NTN RAN (e.g. NTN eNB 920) using establishment cause indicating EPS fallback.

[0243] In various examples, the UE (e.g. UE 910) is configured to measure E-UTRAN or EPS NTN cells in an NR TN cell. This may mean that the UE is configured to measure NB-IoT NTN cells while the UE is RRC IDLE or RRC INACTIVE, and then report the measurements (e.g. to TN cell, TN RAN or TN base station, e.g. TN gNB 930) once the UE has connected. This may allow for faster fallback to EPS by reporting (e.g. reporting measurements on) potential NTN cells at an early stage. In an example, an alternative is for the UE (e.g. UE 910) to first, or initially, establish to RRC_CONNECTED with the TN cell (e.g. TN gNB 930), and then measure (or be configured to measure) NTN cells, and then performs mobility (or is configured to perform mobility) to the NTN cell (e.g. NTN eNB 920).

[0244] The measurements may be used by the network to determine a cell to handover or redirect to when the network falls back (e.g. decides to fallback) to EPS.

[0245] The UE (e.g. UE 910) may be configured (e.g. specifically configured) by the network (e.g. CN 940, e.g. via signalling) to measure an E-UTRAN NTN cell or frequency, or the UE may be configured to specifically measure an NB-IoT NTN cell or frequency. In various examples, if the UE is configured to measure an NB-IoT NTN cell, then the network may need to configure NB-IoT specific configuration as described elsewhere herein.

[0246] Emergency fallback

[0247] According to various embodiments of the present disclosure, a UE may be configured to fallback to an NTN cell for emergency services fallback. An example of this is shown in Figure 10.

[0248] In step S1010, UE 1010 signals capability of network capable of emergency services fallback to NTN, e.g.to CN 1040 (e.g. via TN gNB 1030).

[0249] In step S1020, UE 1010 requests emergency services fallback to NTN, e.g.to CN 1040 (e.g. via TN gNB 1030).

[0250] In step S1030, the network (e.g. CN 1040, where TN gNB 1030 may be involved also) determines (or decides, identifies etc.) whether to fallback, e.g. whether the UE 1010 is to fallback.

[0251] In step S1040, e.g. based on determining to fallback in step S1030, CN 1040 sends an emergency services fallback indication to TN gNB 1030.

[0252] In step S1050, TN gNB 1030 sends emergency services fallback to NTN RAN (e.g. NTN eNB 1020) to UE 1010, e.g. relating to handover or redirection.

[0253] In step S1060, UE 1010 establishes with NTN RAN (e.g. NTN eNB 1020).

[0254] In various embodiments, a UE (e.g. UE 1010) signals to the network that emergency services fallback to NTN is requested (e.g. as in step S1020). In another example, the UE (e.g. UE 1010) signals that emergency service fallback to TN or NTN is requested. In another example, the UE (e.g. UE 1010) signals that only fallback to TN is requested. The UE may be configured to request this in certain conditions, such as UE having detected NTN cells. In various examples, the network (e.g. CN 1040) may also or alternatively signal the capabilities for emergency services fallback to NTN. This may be a condition to trigger the UE to request fallback to NTN.

[0255] In various embodiments, AMF or MME (e.g. of CN 1040) signals to RAN (e.g. TN gNB 1030) that emergency fallback to NTN is supported, shall be performed and / or can be performed. This can be used by the network to determine whether to fallback to a terrestrial or non-terrestrial network, a terrestrial or non-terrestrial frequency, or a terrestrial or non-terrestrial cell. In various examples, AMF or MME may additionally or alternatively signal the supported or preferred network for emergency service to RAN. For example, AMF may signal that TN, NTN or NTN and TN can be supported for the emergency services fallback. An example of this can be found in Specification Example #4 (see below).

[0256] Mobility from / to NB-IoT NTN

[0257] In various embodiments of the present disclosure, a UE is configured to perform measurements in connected mode (or RRC_IDLE or RRC_INACTIVE) of an NB-IoT NTN cell from a terrestrial network. In other words, the UE in RRC connected may be configured, e.g. by a / the base station, to measure the NB-IoT NTN cell(s). This may be used by the RAN to decide whether to fallback to a non-terrestrial NB-IoT network, frequency or cell.

[0258] In relation to this, e.g. for this purpose, the UE may be configured with NTN assistance information such as ephemeris, or a pointer towards ephemeris (such as satellite ID, which points towards ephemeris in SIB31, SIB32, SIB33 or any other configured information), optionally in addition to relevant information for synchronization such as TA-Common.

[0259] In various examples, the UE may also or alternatively be configured with relevant NB-IoT assistance information. This may include NB-IoT frequency information, such as NB-IoT bandwidth, NB-IoT carrier frequency and / or carrier frequency offsets. In various examples, this, together with any NTN assistance information, may be configured in a new type of Measurement object specifically for NB-IoT which may be named MeasObjectNB or MeasObjectNB-IoT. This can be seen in Specification Example #5 (see below).

[0260] In various examples, the UE may indicate that it is capable of being configured to monitor, detect, measure and / or report NB-IoT cells or frequencies while UE is in RRC connected mode for RRM purposes. The UE may report the specific frequencies that it supports to measure.

[0261] In various examples, the mobility to NB-IoT NTN may only be applicable if the target NB-IoT NTN cell operates or is capable of User Plane CIoT optimization. This may also imply that mobility and / or fallback to NB-IoT Control Plane CIoT optimizations is not allowed. This may be useful as Control Plane CIoT optimizations does not support AS security.

[0262] UE capabilities

[0263] Any type of capabilities mentioned above (that is, in any of the examples disclosed herein) may be signalled per band, e.g. on a per-band basis.

[0264] The network (e.g. CN) may also signal its capability of / for the fallback or redirection to NTN in any of the examples mentioned above (that is, any of the examples disclosed herein). For example, the UE may signal its capability for voice fallback to NB-IoT NTN. One example of this can be seen in specification Example #6. In another example, the UE indicates its support for fallback or redirection to voice over GEO.

[0265] In various examples, the UE may signal its capability of voice call over NB-IoT (NTN), voice call over GEO NTN, emergency calls over NB-IoT (NTN), or emergency calls over GEO NTN. This may be signalled to terrestrial network and / or the non-terrestrial network, and may be signalled over NAS and / or RRC, e.g. sent to MME or AMF and / or the base station. If, for example, the UE indicates that voice calls over NB-IoT (NTN) or voice calls over GEO is supported, it may be considered that (e.g. the network may determine or understand that) the UE can also support fallback to NTN. Similarly, in various examples if the UE indicates support of fallback to NTN, it may also be considered that the UE is considered to support voice call. For example, if the UE signals support of fallback to NB-IoT NTN, then it may also be considered that the UE supports voice call over NB-IoT NTN. In various examples, the fallback that the UE is considered to support may be specific, e.g. that the UE supports Emergency fallback, supports EPS fallback or MPS. These capabilities may be sent to RAN as part of UE RAN capabilities, and / or may be sent to AMF or MME as part of NAS capabilities.

[0266] Network abilities

[0267] In various examples, the network may also (e.g. may be configured to) indicate that it is not possible to redirect or fallback to NTN (e.g. not possible to redirect or fallback UE to NTN). This may not necessarily mean that the network does not support it, but rather that the network currently does not support it. For example, if the NTN is overloaded, then this may be indicated to ensure no fallback to NTN occurs. In an example, the network may be configured to indicate that it is not possible to redirect or fallback to NTN based on current load, a time (e.g. a current time), or a network condition or congestion.

[0268] In various examples, the network may also (e.g. additionally or alternatively) indicate to the UE that it supports NB-IoT NTN or voice call over GEO NTN. This may be indicated from an NB-IoT NTN or a GEO NTN, or indicated from a terrestrial network. This may be indicated over NAS, or indicated over AS. If indicated over AS, then in various examples it is indicated in system information.

[0269] UE position reporting or determination

[0270] In some scenarios / examples, an NTN cell may cover different countries or regions with different regulation, laws or requirements on voice calls over NTN. Therefore, in various examples, different regulations or requirements may be (or need to be) applied to different UEs in the same NTN cell. Here, to support the network to deploy the correct regulations and / or routing the data packets for voice call over NTN to the correct PLMN / operator / country, it may be useful or necessary for the network to be aware of UE location, and in particular examples the UE location when it is establishing the IMS call and / or during the call before the call is ended.

[0271] In various examples, the UE may report its location to the network that serves it for IMS voice all over NTN. The UE may report its location when it is establishing the IMS session / service, register to IMS system, establishing RRC connection / NAS connection / bears for voice call, etc.

[0272] The UE may be required to report the location, if the above connection establishment or registration is for emergency services / calls, due to operators policy or local regulation. In an example, the UE determines to report the location due to it being aware of (e.g. having identified or determined) the above connection establishment or registration is for emergency services / calls, and / or the network may require the UE to report its location during voice call service establishment (e.g. for both NB IoT CP and UP solution) or right after the service establishment (e.g. before the service / data transmission actually starts) (for NB IoT UP solution). In various examples, the UE may also be required to report its location to a terrestrial network before any fallback is initiated. A network may also be required to have determined the location of the UE before any fallback. This can for example be a prerequisite before any fallback is initiated and without it, fallback to NTN may not be allowed. For example, the network may determine to fallback (or initiate fallback) based on identifying a location of the UE or having received a report of a location of the UE.

[0273] The UE location may be reported to the IMS system, EPC and / or 5GC (e.g. AMF). The network may use the UE location information to determine the traffic routing for NTN voice call for normal calls and / or emergency services / calls.

[0274] RAT restrictions

[0275] In various embodiments of the present disclosure, the network and / or the UE can be configured to ignore any type of RAT restrictions when performing any type of fallback or redirection (e.g. any type of fallback or redirection such as described in an example herein). In one example of this, if the UE is configured with RAT restrictions (which may be configured via NAS), then if the UE receives a redirection or fallback, the UE is ignores (e.g. is configured to ignore, or is configured to process but not act upon) any type of RAT restrictions and may perform mobility to the NTN cell. In another example, the network ignores (e.g. is configured to ignore) any type of configured RAT restrictions for fallback or redirection. As such, for example, if the base station has received indications of RAT restrictions, then the base station will ignore them. This may apply to any type of fallback or redirection. Since the RAT restrictions include satellite RAN and non-satellite RAN, it may be such that the UE or network is allowed to ignore RAT restrictions if the RAT restriction is related to a satellite RAN. For example, if the UE or network has RAT restrictions indicating that only terrestrial E-UTRAN is allowed, but not satellite E-UTRAN, then ignoring RAT restrictions may only be applicable to the satellite component. Whether the RAT restrictions can be ignored under these type of conditions or other similar conditions may be configurable, e.g. in the UE and / or the network. For example, another condition may be that emergency voice call is on-going.

[0276] Specification Examples

[0277] There are now provided a number of Examples of changes to standards specification (in this case, TS 36.321 or TS 36.331) to implement various features disclosed herein, e.g. see references to these Examples (or ‘Specification Examples’) found above. The text shown in bold and underlined indicates a change, e.g. addition, to the existing version of the specification.

[0278] Specification Example #1

[0279] -- Start of example based on TS 36.331 V18.4.0 --

[0280] 5.3.3.3 Actions related to transmission ofRRCConnectionRequestmessage

[0281] The UE shall set the contents ofRRCConnectionRequestmessage as follows:

[0282] 1> if the UE is connected to EPC:

[0283] 2> set theue-Identityas follows:

[0284] 3> if upper layers provide an S-TMSI:

[0285] 4> set theue-Identityto the value received from upper layers;

[0286] 3> else:

[0287] 4> draw a random value in the range 0 .. 240-1 and set theue-Identitytothis value;

[0288] NOTE 1: Upper layers provide the S-TMSI if the UE is registered in the TA of the current cell.

[0289] 2> if the establishment of the RRC connection is the result of release with redirect withmpsPriorityIndication(either in NR or E-UTRAN):

[0290] 3> set the establishmentCause tohighPriorityAccess;

[0291] 2> else:

[0292] 3> if the UE supportsmo-VoiceCallestablishment cause and UE is establishing the RRC connection for mobile originating MMTEL voice andSystemInformationBlockType2includesvoiceServiceCauseIndicationand the establishment cause received from upper layers is not set tohighPriorityAccess; or

[0293] 3> if the UE supportsmo-VoiceCallestablishment cause and EPS fallback for IMS voice (see TS 23.502

[0102] ) was triggered in NR viaRRCReleasewithvoiceFallbackIndication(see TS 38.331

[0082] ) andSystemInformationBlockType2includesvoiceServiceCauseIndicationand the establishment cause received from upper layers is not set tohighPriorityAccessoremergency:

[0294] 4> set theestablishmentCauseto mo-VoiceCall;

[0295] 3> else if the UE supportsmo-VoiceCallestablishment cause for mobile originating MMTEL video and UE is establishing the RRC connection for mobile originating MMTEL video andSystemInformationBlockType2includesvideoServiceCauseIndicationand the establishment cause received from upper layers is not set tohighPriorityAccess:

[0296] 4> set theestablishmentCauseto mo-VoiceCall;

[0297] 3>else if the UE is NB-IoT:

[0298] 4> if the UE is establishing the RRC connection for voice or for the UE has been indicated to fallback:

[0299] 5> set the establishmentCause tofallbackVoice;

[0300] 4> else if the UE is establishing the RRC for emergency scenario or for redirection for MPS or other reasons:

[0301] 5> set the establishmentCause toemergencyPriorityAccess;

[0302] 4> else:

[0303] 5> set theestablishmentCausein accordance with the information received from upper layers;

[0304] 3> else:

[0305] 4> set theestablishmentCausein accordance with the information received from upper layers;

[0306] -- End of example based on 36.331 V18.4.0 --

[0307] -- Start of example based on 36.331 V18.4.0 --

[0308] -EstablishmentCause-NB

[0309] The IEEstablishmentCause-NBprovides the establishment cause for the RRC connection request or the RRC connection resume request as provided by the upper layers.

[0310] EstablishmentCause-NBinformationelement

[0311] -- ASN1START

[0312] EstablishmentCause-NB-r13 ::= ENUMERATED {

[0313] mt-Access, mo-Signalling, mo-Data, mo-ExceptionData,

[0314] delayTolerantAccess-v1330, mt-EDT-v1610,emergencyPriorityAccess-v1900, fallbackVoice-v1900}

[0315] -- ASN1STOP

[0316] -- End of example based on TS 36.331 V18.4.0 --

[0317] Specification Example #2

[0318] - Start of example based on R2-2501418, (based on TS 36.331 V18.4.0) -

[0319] RRCConnectionReleasefield descriptions. . .mpsPriorityIndicationIndicates the UE can set the establishment cause to highPriorityAccess oremergencyPriorityAccessfor a new connection following a redirect to E-UTRA or set the resume cause to highPriorityAccess for a resume following a redirect to E-UTRA. If the target RAT is NR, see TS 38.331

[0082] . The eNB / ng-eNB sets the indication only for UEs authorized to receive MPS treatment as indicated by ARP and / or QoS characteristics at the eNB / ng-eNB, and it is applicable only for this instance of release with redirection to carrier / RAT included in the redirectedCarrierInfo fieldor in the field redirectedCarrierInfo-v1900 in ntn-RedirectedCarrierInfoin the RRCConnectionRelease message.

[0320] Conditional presenceExplanation5GCThe field is optionally present, Need ON, if the UE is connected to 5GC; otherwise the field is not present.BLCE-IDLEeDRXThe field is optionally present, Need OR, if the UE is a BL UE or UE in CE and the UE is connected to 5GC and IDLE mode eDRX is configured andran-PagingCycle-r15is absent; otherwise the field is not present.EARFCN-maxThe field is mandatory present if the correspondingcarrierFreq(i.e. without suffix) is set tomaxEARFCN. Otherwise the field is not present.EarlySecWhen the UE is connected to 5GC, the field is mandatory present. When the UE is connected to EPC, the field is optionally present, Need ON, if the UE supports UP-EDT or UP transmission using PUR or early security reactivation andreleaseCauseis set torrc-Suspend; otherwise the field is not present.IdleInfoEUTRAThe field is optionally present, Need OP, if theIdleModeMobilityControlInfo(i.e. without suffix) is included and includesfreqPriorityListEUTRA; otherwise the field is not present.INACTIVEThe field is mandatory present in this release.NoRedirect-r8The field is optionally present, Need OP, if theredirectedCarrierInfo(i.e. without suffix) is not included; otherwise the field is not present.RedirectionThe field is optionally present, Need ON, if theredirectedCarrierInfois included and set togeran,utra-FDD,utra-TDDorutra-TDD-r10; otherwise the field is not present.Redirection2The field is optionally present, Need OR, ifredirectedCarrierInfoor redirectedCarrierInfo-v1900 in ntn-RedirectionCarrierInfois included; otherwise the field is not present.

[0321] -- End of example based on R2-2501418, (based on TS 36.331 V18.4.0) --

[0322] Specification Example #3

[0323] -- Start of example based on TS 36.331 V18.4.0 --

[0324] - RRCRelease

[0325] TheRRCReleasemessage is used to command the release of an RRC connection or the suspension of the RRC connection.

[0326] Signalling radio bearer: SRB1

[0327] RLC-SAP: AM

[0328] Logical channel: DCCH

[0329] Direction: Network to UE

[0330] RRCReleasemessage

[0331] -- ASN1START

[0332] -- TAG-RRCRELEASE-START

[0333] RRCRelease ::= SEQUENCE {

[0334] rrc-TransactionIdentifier RRC-TransactionIdentifier,

[0335] criticalExtensions CHOICE {

[0336] rrcRelease RRCRelease-IEs,

[0337] criticalExtensionsFuture SEQUENCE {}

[0338] }

[0339] }

[0340] RRCRelease-IEs ::= SEQUENCE {

[0341] redirectedCarrierInfo RedirectedCarrierInfo OPTIONAL, -- Need N

[0342] cellReselectionPriorities CellReselectionPriorities OPTIONAL, -- Need R

[0343] suspendConfig SuspendConfig OPTIONAL, -- Need R

[0344] deprioritisationReq SEQUENCE {

[0345] deprioritisationType ENUMERATED {frequency, nr},

[0346] deprioritisationTimer ENUMERATED {min5, min10, min15, min30}

[0347] } OPTIONAL, -- Need N

[0348] lateNonCriticalExtension OCTET STRING OPTIONAL,

[0349] nonCriticalExtension RRCRelease-v1540-IEs OPTIONAL

[0350] }

[0351] ...

[0352] RRCRelease-v1610-IEs ::= SEQUENCE {

[0353] voiceFallbackIndication-r16 ENUMERATED {true} OPTIONAL, -- Need N

[0354] measIdleConfig-r16 SetupRelease {MeasIdleConfigDedicated-r16} OPTIONAL, -- Need M

[0355] nonCriticalExtension RRCRelease-v1650-IEs OPTIONAL

[0356] }

[0357] RRCRelease-v1650-IEs ::= SEQUENCE {

[0358] mpsPriorityIndication-r16 ENUMERATED {true} OPTIONAL, -- Cond Redirection2

[0359] nonCriticalExtension RRCRelease-v1710-IEs OPTIONAL

[0360] }

[0361] ...

[0362] RedirectedCarrierInfo ::= CHOICE {

[0363] nr CarrierInfoNR,

[0364] eutra RedirectedCarrierInfo-EUTRA,

[0365] ...,

[0366] [[

[0367] nb-IOT-r20RedirectedCarrierInfo-NB-r20

[0368] ]]

[0369] }

[0370] RedirectedCarrierInfo-EUTRA ::= SEQUENCE {

[0371] eutraFrequency ARFCN-ValueEUTRA,

[0372] cnType ENUMERATED {epc,fiveGC} OPTIONAL -- Need N

[0373] }

[0374] CarrierInfoNR ::= SEQUENCE {

[0375] carrierFreq ARFCN-ValueNR,

[0376] ssbSubcarrierSpacing SubcarrierSpacing,

[0377] smtc SSB-MTC OPTIONAL, -- Need S

[0378] ...

[0379] }

[0380] RedirectedCarrierInfo-NB-r20 ::= SEQUENCE {

[0381] nbiot-Frequency-r20 CarrierInfo-NB-r20,

[0382] cnType-r20 ENUMERATED {epc,fiveGC} OPTIONAL -- Need N

[0383] }

[0384] CarrierInfo-NB-r20 ::= SEQUENCE {

[0385] carrierFreq-NB-r20 ARFCN-ValueEUTRA,

[0386] carrierFreqOffset-r20 ENUMERATED {v-10, v-9, v-8,v-7, v-6, v-5, v-4, v-3, v-2,v-1, v-0dot5, v0, v1, v2, v3, v4, v5, v6, v7,v8, v9

[0387] } OPTIONAL -- Need N

[0388] }

[0389] ...

[0390] -- TAG-RRCRELEASE-STOP

[0391] -- ASN1STOP

[0392] RRCRelease-IEsfield descriptionscellReselectionPrioritiesDedicated priorities to be used for cell reselection as specified in TS 38.304

[0020] .The maximum number of NR carrier frequencies that the network can configure throughFreqPriorityListNRandFreqPriorityListDedicatedSlicingtogether is eight. If the same frequency is configured in bothFreqPriorityListNRandFreqPriorityListDedicatedSlicing, the frequency is only counted once.cnTypeIndicate that the UE is redirected to EPC or 5GC.deprioritisationReqIndicates whether the current frequency or RAT is to be de-prioritised.deprioritisationTimerIndicates the value for timer T325 (see clause 5.3.8.2 and TS 38.304

[0020] ). ValueminNcorresponds to N minutes.srs-PosRRC-InactiveEnhancedContains the SRS for positioning configuration in RRC_INACTIVE state that is applicable for a validity area. The field also contains bandwidth aggregation (see TS 38.214

[0019] , clause 6.2.1.4.2) and frequency hopping configurations (see TS 38.214

[0019] , clause 6.2.1.4.1) for SRS for positioning in RRC_INACTIVE state.measIdleConfigIndicates measurement configuration to be stored and used by the UE while in RRC_IDLE or RRC_INACTIVE.mpsPriorityIndicationIndicates the UE can set the establishment cause tomps-PriorityAccessfor a new connection following a redirect to NR or set the resume cause tomps-PriorityAccessfor a resume following a redirect to NR. If the target RAT is E-UTRA, see TS 36.331

[0010] . The gNB sets the indication only for UEs authorized to receive MPS treatment as indicated by ARP and / or QoS characteristics at the gNB, and it is applicable only for this instance of release with redirection to carrier / RAT included in theredirectedCarrierInfofield in theRRCReleasemessage.multicastConfigInactiveIndicates whether the UE is configured to receive MBS multicast in RRC_INACTIVE. The presence of this field indicates the UE is configured to receive MBS multicast in RRC_INACTIVE; otherwise, the UE is not configured to receive MBS multicast in RRC_INACTIVE.noLastCellUpdatePresence of the field indicates that the last used cell for PEI shall not be updated. When the field is absent, the PEI-capable UE shall update its last used cell with the current cell. The UE shall not update its last used cell with the current cell if the AS security is not activated.redirectedCarrierInfoIndicates a carrier frequency (downlink for FDD) and is used to redirect the UE to an NR or an inter-RAT carrier frequency, by means of cell selection at transition to RRC_IDLE or RRC_INACTIVE as specified in TS 38.304

[0020] . Based on UE capability, the network may includeredirectedCarrierInfoinRRCReleasemessage withsuspendConfigif this message is sent in response to anRRCResumeRequestor anRRCResumeRequest1which is triggered by the NAS layer (see 5.3.1.4 in TS 24.501

[0023] ).srs-PosRRC-InactiveContains the SRS for positioning configuration in RRC_INACTIVE state.suspendConfigIndicates configuration for the RRC_INACTIVE state. The network does not configuresuspendConfigwhen the network redirect the UE to an inter-RAT carrier frequency or if the UE is configured with a DAPS bearer.voiceFallbackIndicationIndicates the RRC release is triggered by EPS fallback for IMS voice as specified in TS 23.502

[0043] .

[0393] ...

[0394] Conditional PresenceExplanationL2RemoteUEThe field is mandatory present for L2 U2N Remote UE's RNAU; otherwise it is absent.RANPagingThis field is optionally present, Need R, if the UE is configured with IDLE eDRX, see TS 24.501

[0023] ; otherwise the field is not present.Redirection2The field is optionally present, Need R, ifredirectedCarrierInfois included; otherwise the field is not present.

[0395] -- End of example based on TS 36.331 V18.4.0 --

[0396] Specification Example #4

[0397] -- Start of example based on TS 36.413 V18.4.0 --

[0398] 9.3.1.26 Emergency Fallback Indicator

[0399] The IE indicates emergency service fallback.

[0400] IE / Group NamePresenceRangeIE type and referenceSemantics descriptionEmergency Fallback Request IndicatorMENUMERATED (emergency fallback requested, ...)Emergency Service Target CNOENUMERATED (5GC, EPC, ...)Emergency Service Target networkOENUMERATED (TN, NTN, NTN-TN, ...)

[0401] -- End of example based on TS 36.413 V18.4.0 --

[0402] Specification Example #5

[0403] -- Start of example based on TS 38.331 V18.4.0 --

[0404] -MeasObjectNB-IoT

[0405] The IE MeasObjectEUTRA specifies information applicable for E-UTRA cells.

[0406] MeasObjectEUTRA information element

[0407] -- ASN1START

[0408] -- TAG-MEASOBJECTEUTRA-START

[0409] MeasObjectNB-IoT-r20 ::= SEQUENCE {

[0410] carrierFreq-r20 CarrierFreq-NB-r13,

[0411] cellsToRemoveListNBIOT-r20 EUTRA-CellIndexList OPTIONAL, -- Need N

[0412] cellsToAddModListNBIOT-r20 SEQUENCE (SIZE (1..maxCellMeasEUTRA)) OF EUTRA-Cell OPTIONAL, -- Need N

[0413] excludedCellsToRemoveListNBIOT-r20 EUTRA-CellIndexList OPTIONAL, -- Need N

[0414] excludedCellsToAddModListNBIOT-r20 SEQUENCE (SIZE (1..maxCellMeasEUTRA)) OF EUTRA-ExcludedCell OPTIONAL, -- Need N

[0415] q-OffsetRangeNBIOT-r20 EUTRA-Q-OffsetRange OPTIONAL, -- Need R

[0416] ...

[0417] }

[0418] NBIoT-CellIndexList ::= SEQUENCE (SIZE (1..maxCellMeasEUTRA)) OF NBIoT-CellIndex

[0419] NBIoT-CellIndex ::= INTEGER (1..maxCellMeasEUTRA)

[0420] NBIoT-Cell ::= SEQUENCE {

[0421] cellIndexEUTRA-r20 EUTRA-CellIndex,

[0422] physCellId-r20 EUTRA-PhysCellId,

[0423] cellIndividualOffset-r20 EUTRA-Q-OffsetRange,

[0424] ntn-Config-r20 NTN-Config-r17 OPTIONAL -- Need R

[0425] }

[0426] NBIoT-ExcludedCell ::= SEQUENCE {

[0427] cellIndexEUTRA EUTRA-CellIndex,

[0428] physCellIdRange EUTRA-PhysCellIdRange

[0429] }

[0430] -- TAG-MEASOBJECTEUTRA-STOP

[0431] -- ASN1STOP

[0432]

[0433] EUTRAN-ExcludedCellfield descriptionscellIndexEUTRAEntry index in the cell list.physicalCellIdRangePhysical cell identity or a range of physical cell identities.

[0434] EUTRAN-Cellfield descriptionsphysicalCellIdPhysical cell identity of a cell in the cell list.cellIndividualOffsetCell individual offset applicable to a specific cell. ValuedB-24corresponds to -24 dB,dB-22corresponds to -22 dB and so on.

[0435] MeasObjectEUTRAfield descriptionsallowedMeasBandwidthThe maximum allowed measurement bandwidth on a carrier frequency as defined by the parameter Transmission Bandwidth Configuration "NRB" TS 36.104

[0033] .associatedMeasGapIndicates the associated measurement gap for measuring this EUTRA frequency. If this field is absent, the associated meaurment gap is the gap configured viagapFR1orgapUE.carrierFreqIdentifies E-UTRA carrier frequency for which this configuration is valid. Network does not configure more than oneMeasObjectEUTRAfor the samephysical frequency, regardless of the E-ARFCN used to indicate this.cellsToAddModListEUTRANList of cells to add / modify in the cell list.cellsToRemoveListEUTRANList of cells to remove from the cell list.eutra-Q-OffsetRangeUsed to indicate a cell, or frequency specific offset to be applied when evaluating triggering conditions for measurement reporting. The value is in dB. ValuedB-24corresponds to -24 dB, valuedB-22corresponds to -22 dB and so on.excludedCellsToAddModListEUTRANList of cells to add / modify in the exclude-list of cells.excludedCellsToRemoveListEUTRANList of cells to remove from the exclude-list of cells.measSequenceIndicates the recommended sequence for intra / inter-RAT intra / inter-frequency measurement. Value 1 means the corresponding frequency is measured firstly. Value 2 means the corresponding frequency is measured secondly and so on. If more than one frequency is configured with the same value, it means no recommended sequence among these frequencies. If not configured, it means there is no recommended sequence for the corresponding frequency. This field is only configured for NR standalone or if themeasObjectis associated to the MCG.widebandRSRQ-MeasIf set totrue, the UE shall, when performing RSRQ measurements, use a wider bandwidth in accordance with TS 36.133

[0040] . The network may set the field totrueif the measurement bandwidth indicated byallowedMeasBandwidthis 50 resource blocks or larger; otherwise the network sets this field tofalse.

[0436] -- End of example based on TS 38.331 V18.4.0 --

[0437] Specification Example #6

[0438] -- Start of example based on TS 38.306 V18.4.0 --

[0439] 4.2.13 IMS Parameters

[0440] Definitions for parametersPerMFDD-TDDDIFFFR1-FR2DIFFvoiceFallbackIndicationEPS-r16Indicates whether the UE supportsvoiceFallbackIndicationinRRCReleaseandMobilityFromNRCommand. If this field is included, the UE shall support IMS voice over NR and IMS voice over E-UTRA via EPC.UENoNoNovoiceFallbackIndicationNB-IoT-NTN-r20Indicates whether the UE supportsvoiceFallbackIndicationinRRCReleaseto an NB-IoT NTN cell. If this field is included, the UE shall support IMS voice over NB-IoT NTN.UENoNoNovoiceOverEUTRA-5GCIndicates whether the UE supports IMS voice over E-UTRA via 5GC. It is mandated to the UE if the UE is capable of IMS voice over E-UTRA via 5GC. Otherwise, the UE does not include this field. If this field is included and the UE is capable of E-UTRA with EPC, the UE shall support IMS voice over E-UTRA via EPC.UENoNoNovoiceOverNR, voiceOverNR-r17Indicates whether the UE supports IMS voice over NR. It is mandated to the UE if the UE is capable of IMS voice over NR (including SNPN if the UE is SNPN capable). Otherwise, the UE does not include this field. If this field is included and the UE is capable of E-UTRA with EPC, the UE shall support IMS voice over E-UTRA via EPC.UENoNoYes(Incl FR2-2 DIFF)voiceOverSCG-BearerEUTRA-5GCIndicates whether the UE supports IMS voice over SCG bearer of NE-DC.UENoNoN / A

[0441] -- End of example based on TS 38.306 V18.4.0 --

[0442] Figure 11 is a block diagram of an exemplary apparatus, or network entity,that may be used in examples of the present disclosure. The skilled person will appreciate said entity may be implemented, for example, as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, and / or as a virtualised function instantiated on an appropriate platform, e.g. on a cloud infrastructure.

[0443] The entity 1100 comprises a processor (or controller) 1101, a transmitter 1103 and a receiver 1105. The receiver 1105 is configured for receiving one or more messages from one or more other network entities, for example as described above. The transmitter 1103 is configured for transmitting one or more messages to one or more other network entities, for example as described above. The processor 1101 is configured for performing one or more operations, for example according to the operations as described above. It will be appreciated that an entity as described herein may be a virtual or logical entity, which may be implemented using or in an apparatus which comprises a processor, an antenna, a receiver and / or a transmitter etc. but which does not itself have a physical form (i.e. would not be said to comprise a processor, an antenna, a receiver and / or a transmitter etc.).

[0444] Figure 12 illustrates a method of a UE according to an example of the disclosure.

[0445] In S1210, the UE receives, from a first network, an indication to redirect to a second network, wherein the indication includes information on a carrier frequency of the second network and / or information on a carrier frequency offset. The first network is a Evolved-Universal Terrestrial Radio Access Network (E-UTRAN) terrestrial network (TN) and the second network is a Narrowband Internet of Things (NB-IoT) non-terrestrial network (NTN).

[0446] Figure 13 illustrates a method of an entity in a first network, wherein the first network is an Evolved-Universal Terrestrial Radio Access Network (E-UTRAN) terrestrial network (TN).

[0447] In S1310, the entity transmits, to a user equipment (UE), an indication to redirect to a second network, wherein the indication includes information on a carrier frequency of the second network and / or information on a carrier frequency offset. The second network is a Narrowband Internet of Things (NB-IoT) non-terrestrial network (NTN).

[0448] According to an embodiment, there is provided a network entity in a network, the network entity configured to: determine whether a user equipment (UE) is capable or allowed to fallback or redirect to non-terrestrial network (NTN); and if so, transmit an indication for the UE to fallback or redirect to a NTN.

[0449] According to an embodiment, the network entity is configured to: determine whether the UE is capable or allowed to fallback or redirect to NTN based on a first indication received from the UE, wherein the first indication indicates that the UE supports fallback or redirection to NTN.

[0450] According to an embodiment, the network entity is configured to: determine whether the UE is capable or allowed to fallback or redirect to the NTN based on a second indication received from the NTN, wherein the second indication indicates support for one or more services or functions in the NTN.

[0451] According to an embodiment, the one or more services or functions include a service or function relating to a reason for the fallback.

[0452] According to an embodiment, the service or function includes emergency voice call, emergency services, voice call / services.

[0453] According to an embodiment, the network entity is configured to: determine whether the UE is capable or allowed to fallback or redirect to NTN based on a third indication received from the UE, wherein the third indication indicates that the UE is capable of performing multimedia priority services (MPS) redirection to NTN.

[0454] According to an embodiment, the third indication is received by an access and mobility function (AMF) included in the network or is received by the entity via a base station.

[0455] According to an embodiment, the MPS redirection is from a terrestrial network (TN) corresponding to a first radio access technology (RAT) to the NTN, the NTN corresponding to a second RAT; or wherein the MPS redirection is from a TN corresponding to a RAT to the NTN, the NTN corresponding to the RAT; and optionally, wherein the third indication indicates that the UE is capable of being redirected to a cell on specific one or more RAT.

[0456] According to an embodiment, the fallback or redirection is from 5G core (5GC) to evolved packet system (EPS), wherein the NTN connects to the EPS.

[0457] According to an embodiment, the network entity is configured to: configure the UE with NTN information for establishing with the NTN.

[0458] According to an embodiment, the NTN information includes one or more of NTN assistance information, NTN ephemeris and synchronization-related information.

[0459] According to an embodiment, the network entity is configured to: transmit an indication to the UE that a target cell of the NTN is using control plane (CP) or user plane (UP) cellular internet of things (CIoT) optimization or that the UE is to connect to the NTN via CP or UP CIoT optimization.

[0460] According to an embodiment, the indication for the UE to fallback or redirect to the NTN indicates a specific cell or frequency associated with the NTN.

[0461] According to an embodiment, the indication for the UE to fallback or redirect to the NTN is transmitted to a TN for communicating to the UE connected to the TN.

[0462] According to an embodiment, there is provided a user equipment (UE) configured to: transmit a first indication to a network entity, the first indication indicating that the UE supports fallback or redirection to non-terrestrial network (NTN) or is capable of performing multimedia priority services (MPS) redirection to NTN; receive, from the network entity, an indication to fallback or redirect to an NTN; and based on the received indication, establish with the NTN.

[0463] According to an embodiment, the UE is configured to: establish with the NTN with an establishment cause indicating MPS redirection or EPS fallback.

[0464] According to an embodiment, the first indication is transmitted based on use of emergency services or the first indication is included in a request for emergency services fallback to NTN; or wherein the UE is further configured to request emergency services fallback to NTN from the network entity.

[0465] According to an embodiment, the UE is configured to: measure one or more NTN cell and report cell measurements to a base station in a terrestrial network (TN); wherein the received indication indicates a NTN cell, among the one or more NTN cell, to establish with, the NTN cell being associated with the NTN.

[0466] According to an embodiment, the UE is configured to: report a location of the UE to the network entity.

[0467] According to an embodiment, the MPS redirection is from a terrestrial network (TN) corresponding to a first radio access technology (RAT) to the NTN, the NTN corresponding to a second RAT; or wherein the MPS redirection is from a TN corresponding to a RAT to the NTN, the NTN corresponding to the RAT; and optionally, wherein the first indication indicates that the UE is capable of being redirected to a cell on specific one or more RAT.

[0468] According to an embodiment, the first indication is signalled as part of radio capabilities to a base station or as part of non-access stratum (NAS) capabilities to an access and mobility function (AMF).

[0469] According to an embodiment, there is provided a method of an entity in a network, the method comprising: determining whether a user equipment (UE) is capable or allowed to fallback or redirect to non-terrestrial network (NTN); and if so, transmitting an indication for the UE to fallback or redirect to a NTN.

[0470] According to an embodiment, there is provided a method of a user equipment (UE), the method comprising: transmitting a first indication to a network entity, the first indication indicating that the UE supports fallback or redirection to non-terrestrial network (NTN) or is capable of performing multimedia priority services (MPS) redirection to NTN; receiving, from the network entity, an indication to fallback or redirect to an NTN; and based on the received indication, establishing with the NTN.

[0471] According to an embodiment, there is provided a computer-readable storage medium comprising instructions which, when executed by at least one processor of an electronic device, cause the electronic device to perform a method according to any one of the above embodiments.

[0472] It will be appreciated that, in each example / embodiment / aspect etc. described above, one or more features or operations may be omitted, modified or moved (e.g., to change the order of the features or the operations), if desired and appropriate. For example, referring to the method shown by the call flow diagram of any of the figures, it will be understood that one or more of the operations of these methods may be omitted. Additionally, one or more features or operations from any example / embodiment may be combined with features or operations from any other example / embodiment. In particular, regardless of whether or not a pointer towards a combination of features / examples is found herein, the present disclosure should be considered to include all combinations of two or more of the embodiments, examples etc. disclosed herein, and all combinations of two or more of the features disclosed herein.

[0473] The techniques described herein may be implemented using any suitably configured apparatus and / or system. Such an apparatus and / or system may be configured to perform a method according to any aspect, embodiment or example disclosed herein. Such an apparatus may comprise one or more elements, for example one or more of receivers, transmitters, transceivers, processors, controllers, modules, units, and the like, each element configured to perform one or more corresponding processes, operations and / or method steps for implementing the techniques described herein. For example, an operation / function of X may be performed by a module configured to perform X (or an X-module). The one or more elements may be implemented in the form of hardware, software, or any combination of hardware and software.

[0474] It will be appreciated that examples of the present disclosure may be implemented in the form of hardware, software or any combination of hardware and software. Any such software may be stored in the form of volatile or non-volatile storage, for example a storage device like a ROM, whether erasable or rewritable or not, or in the form of memory such as, for example, RAM, memory chips, device or integrated circuits or on an optically or magnetically readable medium such as, for example, a CD, DVD, magnetic disk or magnetic tape or the like.

[0475] It will be appreciated that the storage devices and storage media are embodiments of machine-readable storage that are suitable for storing a program or programs comprising instructions that, when executed, implement certain examples of the present disclosure. Accordingly, certain examples provide a program comprising code for implementing a method, apparatus or system according to any example, embodiment and / or aspect disclosed herein, and / or a machine-readable storage storing such a program. Still further, such programs may be conveyed electronically via any medium, for example a communication signal carried over a wired or wireless connection.

[0476] While the present disclosure has been shown, illustrated and described with reference to certain examples, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the scope of the disclosure.

[0477] The reader's attention is directed to all papers and documents which are filed concurrently with or previous to this specification in connection with this application and which are open to public inspection with this specification, and the contents of all such papers and documents are incorporated herein by reference.

[0478] The disclosure includes examples according to the following numbered clauses:

[0479] Clause 1. A network entity in a network, the network entity configured to:

[0480] determine whether a user equipment (UE) is capable or allowed to fallback or redirect to non-terrestrial network (NTN); and

[0481] if so, transmit an indication for the UE to fallback or redirect to a NTN.

[0482] Clause 2. The network entity of Clause 1, configured to:

[0483] determine whether the UE is capable or allowed to fallback or redirect to NTN based on a first indication received from the UE, wherein the first indication indicates that the UE supports fallback or redirection to NTN.

[0484] Clause 3. The network entity of Clause 1 or Clause 2, configured to:

[0485] determine whether the UE is capable or allowed to fallback or redirect to the NTN based on a second indication received from the NTN, wherein the second indication indicates support for one or more services or functions in the NTN.

[0486] Clause 4. The entity of Clause 3, wherein the one or more services or functions include a service or function relating to a reason for the fallback.

[0487] Clause 5. The network entity of Clause 4, wherein the service or function includes emergency voice call, emergency services, voice call / services.

[0488] Clause 6. The network entity of Clause 1, configured to:

[0489] determine whether the UE is capable or allowed to fallback or redirect to NTN based on a third indication received from the UE, wherein the third indication indicates that the UE is capable of performing multimedia priority services (MPS) redirection to NTN.

[0490] Clause 7. The network entity of Clause 6, wherein the third indication is received by an access and mobility function (AMF) included in the network or is received by the entity via a base station.

[0491] Clause 8. The network entity of Clause 6 or Clause 7, wherein the MPS redirection is from a terrestrial network (TN) corresponding to a first radio access technology (RAT) to the NTN, the NTN corresponding to a second RAT; or

[0492] wherein the MPS redirection is from a TN corresponding to a RAT to the NTN, the NTN corresponding to the RAT; and

[0493] optionally, wherein the third indication indicates that the UE is capable of being redirected to a cell on specific one or more RAT.

[0494] Clause 9. The network entity of any one of Clauses 1 to 4, wherein the fallback or redirection is from 5G core (5GC) to evolved packet system (EPS), wherein the NTN connects to the EPS.

[0495] Clause 10. The network entity of Clause 9, further configured to:

[0496] configure the UE with NTN information for establishing with the NTN.

[0497] Clause 11. The network entity of Clause 10, wherein the NTN information includes one or more of NTN assistance information, NTN ephemeris and synchronization-related information.

[0498] Clause 12. The network entity of any one of Clauses 9 to 11, further configured to:

[0499] transmit an indication to the UE that a target cell of the NTN is using control plane (CP) or user plane (UP) cellular internet of things (CIoT) optimization or that the UE is to connect to the NTN via CP or UP CIoT optimization.

[0500] Clause 13. The network entity of any one of the previous Clauses, wherein the indication for the UE to fallback or redirect to the NTN indicates a specific cell or frequency associated with the NTN.

[0501] Clause 14. The network entity of any one of the previous Clauses, wherein the indication for the UE to fallback or redirect to the NTN is transmitted to a TN for communicating to the UE connected to the TN.

[0502] Clause 15. A user equipment (UE) configured to:

[0503] transmit a first indication to a network entity, the first indication indicating that the UE supports fallback or redirection to non-terrestrial network (NTN) or is capable of performing multimedia priority services (MPS) redirection to NTN;

[0504] receive, from the network entity, an indication to fallback or redirect to an NTN; and

[0505] based on the received indication, establish with the NTN.

[0506] Clause 16. The UE of Clause 15, configured to:

[0507] establish with the NTN with an establishment cause indicating MPS redirection or EPS fallback.

[0508] Clause 17. The UE of Clause 15 or Clause 16, wherein the first indication is transmitted based on use of emergency services or the first indication is included in a request for emergency services fallback to NTN; or

[0509] wherein the UE is further configured to request emergency services fallback to NTN from the network entity.

[0510] Clause 18. The UE of Clause 15 or Clause 16, configured to:

[0511] measure one or more NTN cell and report cell measurements to a base station in a terrestrial network (TN);

[0512] wherein the received indication indicates a NTN cell, among the one or more NTN cell, to establish with, the NTN cell being associated with the NTN.

[0513] Clause 19. The UE of any one of Clauses 15 to 18, configured to:

[0514] report a location of the UE to the network entity.

[0515] Clause 20. The UE of any one of Clauses 15 to 17, wherein the MPS redirection is from a terrestrial network (TN) corresponding to a first radio access technology (RAT) to the NTN, the NTN corresponding to a second RAT; or

[0516] wherein the MPS redirection is from a TN corresponding to a RAT to the NTN, the NTN corresponding to the RAT; and

[0517] optionally, wherein the first indication indicates that the UE is capable of being redirected to a cell on specific one or more RAT.

[0518] Clause 21. The UE of any one of Clauses 15 to 20, wherein the first indication is signalled as part of radio capabilities to a base station or as part of non-access stratum (NAS) capabilities to an access and mobility function (AMF).

[0519] Clause 22. A method of an entity in a network, the method comprising:

[0520] determining whether a user equipment (UE) is capable or allowed to fallback or redirect to non-terrestrial network (NTN); and

[0521] if so, transmitting an indication for the UE to fallback or redirect to a NTN.

[0522] Clause 23. A method of a user equipment (UE), the method comprising:

[0523] transmitting a first indication to a network entity, the first indication indicating that the UE supports fallback or redirection to non-terrestrial network (NTN) or is capable of performing multimedia priority services (MPS) redirection to NTN;

[0524] receiving, from the network entity, an indication to fallback or redirect to an NTN; and

[0525] based on the received indication, establishing with the NTN.

[0526] Clause 24. A user equipment (UE) configured to:

[0527] receive, from a first network, an indication to redirect to a second network, wherein the indication includes information on a carrier frequency of the second network and / or information on a carrier frequency offset;

[0528] wherein the first network is an Evolved-Universal Terrestrial Radio Access Network (E-UTRAN) terrestrial network (TN) and the second network is a Narrowband Internet of Things (NB-IoT) non-terrestrial network (NTN).

[0529] Clause 25. The UE of Clause 24, wherein the indication is included in a RRC message received by the UE.

[0530] Clause 26. The UE of Clause 25, wherein the RRC message is a RRCConnectionRelease message.

[0531] Clause 27. The UE of any one of Clauses 24 to 26, further configured to:

[0532] signal an indication of a capability of the UE to be redirected to an NB-IoT NTN cell.

[0533] Clause 28. The UE of any one of Clauses 24 to 27, further configured to:

[0534] transmit, to the first network, information on UE capability on redirection or fallback.

[0535] Clause 29. The UE of Clause 28, wherein the information on UE capability includes an indication of at least one specific frequency band supported by the UE for redirection.

[0536] Clause 30. The UE of Clause 29, wherein the at least one specific frequency band is at least one NB-IoT frequency band supported by the UE for redirection from an E-UTRAN TN to a NB-IoT NTN.

[0537] Clause 31. The UE of any one of Clauses 24 to 30, wherein the redirection is an Evolved Packet System (EPS) fallback.

[0538] Clause 32. The UE of Clause 24, wherein the redirection is a Multimedia Priority Services (MPS) redirection.

[0539] Clause 33. The UE of Clause 32, wherein the UE is configured to establish with an NB-IoT NTN cell on the indicated frequency, and indicate a high priority access establishment cause.

[0540] Clause 34. An entity in a first network, wherein the first network is an Evolved-Universal Terrestrial Radio Access Network (E-UTRAN) terrestrial network (TN), and the entity configured to:

[0541] transmit, to a user equipment (UE), an indication to redirect to a second network, wherein the indication includes information on a carrier frequency of the second network and / or information on a carrier frequency offset;

[0542] wherein the second network is a Narrowband Internet of Things (NB-IoT) non-terrestrial network (NTN).

[0543] Clause 35. The entity of Clause 34, wherein the indication is included in a RRC message transmitted to the UE.

[0544] Clause 36. The entity of Clause 35, wherein the RRC message is a RRCConnectionRelease message.

[0545] Clause 37. The entity of any one of Clauses 34 to 36, further configured to:

[0546] receive, from the UE, an indication of a capability of the UE to be redirected to an NB-IoT NTN cell.

[0547] Clause 38. The entity of any one of Clauses 34 to 37, further configured to:

[0548] receive, from the UE, information on UE capability on redirection or fallback.

[0549] Clause 39. The entity of any one of Clauses 34 to 38, wherein the information on UE capability includes an indication of at least one specific frequency band supported by the UE for redirection.

[0550] Clause 40. The entity of Clause 39, wherein the at least one specific frequency band is at least one NB-IoT frequency band supported by the UE for redirection from an E-UTRAN TN to a NB-IoT NTN.

[0551] Clause 41. The entity of any one of Clauses 34 to 40, wherein the redirection is an Evolved Packet System (EPS) fallback.

[0552] Clause 42. The entity of Clause 41, wherein the redirection is a Multimedia Priority Services (MPS) redirection.

[0553] Clause 43. A method of a user equipment (UE), the method comprising:

[0554] receiving, from a first network, an indication to redirect to a second network, wherein the indication includes information on a carrier frequency of the second network and / or information on a carrier frequency offset;

[0555] wherein the first network is Evolved-Universal Terrestrial Radio Access Network (E-UTRAN) terrestrial network (TN) and the second network is a Narrowband Internet of Things (NB-IoT) non-terrestrial network (NTN).

[0556] Clause 44. A method of an entity in a first network, wherein the first network is an Evolved-Universal Terrestrial Radio Access Network (E-UTRAN) terrestrial network (TN), and wherein the method comprises:

[0557] transmitting, to a user equipment (UE), an indication to redirect to a second network, wherein the indication includes information on a carrier frequency of the second network and / or information on a carrier frequency offset;

[0558] wherein the second network is a Narrowband Internet of Things (NB-IoT) non-terrestrial network (NTN).

[0559] Clause 45. A computer-readable storage medium comprising instructions which, when executed by at least one processor of an electronic device, cause the electronic device to perform a method according to any one of Clauses 22, 23, 43 or 44.

[0560] Acronyms and Definitions (as may be used herein)

[0561] 3GPP 3rdGeneration Partnership Project

[0562] 5G 5thGeneration

[0563] 5GC 5G Core

[0564] 5QI 5G QoS Identifier

[0565] 5GS 5G System

[0566] 5GSM 5G System Session Management

[0567] 5GMM 5G System Mobility Management

[0568] AF Application Function

[0569] AI Artificial Intelligence

[0570] AIML Artificial Intelligence / Machine Learning

[0571] AM Acknowledged Mode

[0572] AMF Access and Mobility Management Function

[0573] AS Application Server

[0574] AS RAI Access Stratum Release Assistance Information

[0575] ASP Application Service Provider

[0576] ATSSS Access Traffic Steering Switching & Splitting

[0577] AUSF Authentication Server Function

[0578] CIoT Cellular Internet of Things

[0579] CP Control Plane

[0580] CQI Channel Quality Indicator

[0581] CSI Channel Status Information

[0582] DCQR Downlink Channel Quality Report

[0583] DNAI Data Network Access Identifier

[0584] DNN Data Network Name

[0585] DNS Domain Name Server

[0586] DRB Data Radio Bearer

[0587] EDT Early Data Transmission

[0588] eMTC enhanced Machine-Type Communication

[0589] eNB Evolved Node B

[0590] EPS Evolved Packet System

[0591] FQDN Fully Qualified Domain Name

[0592] GBR Guaranteed Bit Rate

[0593] GMLC Gateway Mobile Location Centre

[0594] gNB Next generation Node B

[0595] GPSI Generic Public Subscription Identifier

[0596] IAB Integrated Access and Backhaul

[0597] ID Identity / Identifier

[0598] IIoT Industrial Internet of Things

[0599] IMEI International Mobile Equipment Identities

[0600] IMS IP Multimedia Subsystem

[0601] IP Internet Protocol

[0602] I-SMF Intermediate SMF

[0603] LMF Location Management Function

[0604] MA-PDU Multiple Access PDU

[0605] ML Machine Learning

[0606] MME Mobility Management Entity

[0607] MN Master Node

[0608] MO Mobile Originating

[0609] MNO Mobile Network Operator

[0610] MPS Multimedia Priority Services

[0611] MT Mobile Termination

[0612] NAS Non-Access Stratum

[0613] NB-IoT Narrowband (NB) Internet of Things (IoT)

[0614] NEF Network Exposure Function

[0615] NRF Network Repository Function

[0616] NG-RAN Next Generation Radio Access Network

[0617] NG-eNB Next Generation eNB

[0618] NSA Non-Standalone

[0619] NTN Non-Terrestrial Network

[0620] NW Network

[0621] NWDAF Network Data Analytics Function

[0622] OAM Operations and Management

[0623] OS Operating System

[0624] PCF Policy Control Function

[0625] PCC Policy and Charging Control

[0626] PCO Protocol Configuration Options

[0627] PDCCH Physical Downlink Control Channel

[0628] PDR Packet Detection Rule

[0629] PDU Protocol Data Unit

[0630] PMF Performance Measurement Function

[0631] PRS Positioning Reference Signal

[0632] PRU Positioning Reference Unit

[0633] PUR Preconfigured Uplink Resources

[0634] PUSCH Physical Uplink Shared Channel

[0635] QFI QoS Flow Identifier (ID)

[0636] QoE Quality of Experience

[0637] QoS Quality of Service

[0638] RACH Random Access Channel

[0639] RAN Radio Access Network

[0640] RAT Radio Access Technology

[0641] RLC-AM Radio Link Control Acknowledge Mode

[0642] RLC-UM Radio Link Control Unacknowledge Mode

[0643] RSD Route Selection Descriptor

[0644] SA Standalone

[0645] SBA Service-Based Architecture

[0646] SBI Service-Based Interface

[0647] SCEF Service Capability Exposure Function

[0648] SCP Service-Based Communication Proxy

[0649] SCTP Stream Control Transmission Protocol

[0650] SDAP Service Data Adaptation Protocol

[0651] SDU Service Data Unit

[0652] SIM Subscriber Identity Module

[0653] SLA Service Level Agreement

[0654] SM Session Management

[0655] SMF Session Management Function

[0656] SN Secondary Node

[0657] S-NSSAI Single Network Slice Selection Assistance Information

[0658] SRS Sounding Reference Signal

[0659] SSC Session and Service Continuity

[0660] SUPI Subscription Permanent Identifier

[0661] TAI Tracking Area Identity

[0662] TE Terminal Equipment

[0663] TN Terrestrial Network

[0664] TS Technical Specification

[0665] UDM Unified Data Manager

[0666] UDR Unified Data Repository

[0667] UE User Equipment

[0668] UL Uplink

[0669] UM Unacknowledged Mode

[0670] UP User Plane

[0671] UPF User Plane Function

[0672] URLLC Ultra-Reliable and Low-Latency Communication

[0673] URSP UE Route Selection Policy

[0674] XRM Extended Reality and Media

Claims

1.A method performed by a user equipment (UE) in a communication system, the method comprising:receiving, from a network entity of an evolved-universal terrestrial radio access network (E-UTRAN), a radio resource control (RRC) message including redirect carrier information, wherein the redirect carrier information indicates carrier information to redirect the UE from a first network to a second network; andperforming a cell selection based on the redirect carrier information,wherein the first network is an EUTRAN terrestrial network (TN) and the second network is a narrowband internet of things (NB-IoT) non-terrestrial network (NTN).2.The method of claim 1, further comprising:transmitting, to the network entity, capability information including band information,wherein the band information indicates NB-IoT frequency bands supported by the UE for redirection from the first network to the second network.3.The method of claim 1,wherein the RRC message corresponds to an RRC connection release message, andwherein the redirect carrier information includes carrier frequency information of the second network and carrier frequency offset information of the second network.4.The method of claim 1, further comprising:establishing a connection with a cell of the NB-IoT NTN based on the redirect carrier information,wherein the redirect carrier information is used for a redirection, andwherein the redirection is one of an evolved packet system (EPS) fallback or a multimedia priority services (MPS) redirection.5.A method performed by a network entity in a communication system, the method comprising:determining a redirection of a user equipment (UE) from a first network to a second network; andtransmitting, to the UE, a radio resource control (RRC) message including redirect carrier information, wherein the redirect carrier information indicates carrier information to redirect the UE from the first network to the second network,wherein the first network is an evolved-universal terrestrial radio access network (E-UTRAN) terrestrial network (TN) and the second network is a narrowband internet of things (NB-IoT) non-terrestrial network (NTN).6.The method of claim 5, further comprising:receiving, from the UE, capability information including band information,wherein the band information indicates NB-IoT frequency bands supported by the UE for redirection from the first network to the second network.7.The method of claim 5,wherein the RRC message corresponds to an RRC connection release message, andwherein the redirect carrier information includes carrier frequency information of the second network and carrier frequency offset information of the second network.8.The method of claim 5,wherein a cell selection and a connection with a cell of the NB-IoT NTN are performed based on the redirect carrier information,wherein the redirect carrier information is used for the redirection, andwherein the redirection is one of an evolved packet system (EPS) fallback or a multimedia priority services (MPS) redirection.9.A user equipment (UE) in a communication system, the UE comprising:a transceiver; andat least one processor coupled with the transceiver and configured to:receive, from a network entity of an evolved-universal terrestrial radio access network (E-UTRAN), a radio resource control (RRC) message including redirect carrier information, wherein the redirect carrier information indicates carrier information to redirect the UE from a first network to a second network, andperform a cell selection based on the redirect carrier information,wherein the first network is an EUTRAN terrestrial network (TN) and the second network is a narrowband internet of things (NB-IoT) non-terrestrial network (NTN).10.The UE of claim 9,wherein the at least one processor is further configured to transmit, to the network entity, capability information including band information, andwherein the band information indicates NB-IoT frequency bands supported by the UE for redirection from the first network to the second network.11.The UE of claim 9,wherein the RRC message corresponds to an RRC connection release message, andwherein the redirect carrier information includes carrier frequency information of the second network and carrier frequency offset information of the second network.12.The UE of claim 9,wherein the at least one processor is further configured to establish a connection with a cell of the NB-IoT NTN based on the redirect carrier information,wherein the redirect carrier information is used for a redirection, andwherein the redirection is one of an evolved packet system (EPS) fallback or a multimedia priority services (MPS) redirection.13.A network entity in a communication system, the network entity comprising:a transceiver; andat least one processor coupled with the transceiver and configured to:determine a redirection of a user equipment (UE) from a first network to a second network, andtransmit, to the UE, a radio resource control (RRC) message including redirect carrier information, wherein the redirect carrier information indicates carrier information to redirect the UE from the first network to the second network,wherein the first network is an evolved-universal terrestrial radio access network (E-UTRAN) terrestrial network (TN) and the second network is a narrowband internet of things (NB-IoT) non-terrestrial network (NTN).14.The network entity of claim 13,wherein the at least one processor is further configured to receive, from the UE, capability information including band information, andwherein the band information indicates NB-IoT frequency bands supported by the UE for redirection from the first network to the second network.15.The network entity of claim 13,wherein the RRC message corresponds to an RRC connection release message,wherein the redirect carrier information includes carrier frequency information of the second network and carrier frequency offset information of the second network,wherein a cell selection and a connection with a cell of the NB-IoT NTN are performed based on the redirect carrier information,wherein the redirect carrier information is used for the redirection, andwherein the redirection is one of an evolved packet system (EPS) fallback or a multimedia priority services (MPS) redirection.

Images