Emergency messaging over IoT ntn

Abstract

A user equipment (UE) selects (1101) a cell of a non-terrestrial network (NTN) that supports Internet-of-Things (loT) devices, transmits (1104), to a core network (CN) via the cell, a registration request message indicating that the UE requires an emergency messaging service (EMS), and establishes (1112), with the cell, a protocol data unit (PDU) session for the EMS.

Description

EMERGENCY MESSAGING OVER IOT NTNCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to and the benefit of the filing date of provisional U.S. Patent Application No. 63 / 651,941, entitled “Method of Emergency Texting Over loT NTN,” filed on May 24, 2024 and provisional U.S. Patent Application No. 63 / 681,758, entitled “Method of Emergency Texting Over loT NTN,” filed on August 9, 2024. The entire contents of the provisional applications are hereby expressly incorporated herein by referenceFIELD OF THE DISCLOSURE

[0002] This disclosure relates generally to wireless communication systems such as 3GPP communication systems and, more particularly, to an internet-of-things (loT) non-terrestrial network (NTN).BACKGROUND

[0003] This background description is provided for the purpose of generally presenting the context of the disclosure. Work of the presently named inventors, to the extent it is described in this background section, as well as aspects of the description that may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present disclosure.

[0004] The 5G technology relies primarily on legacy terrestrial networks. However, the 3rd Generation Partnership Project (3GPP) organization has proposed to extend 5G communications to non-terrestrial networks (NTNs) with 5G new radio (NR) technologies, or with the Long- Term-Evolution (LTE) technologies tailored for the Narrowband Internet-of-Thing (NB-ToT) or the enhanced Machine Type Communication (cMTC) scenarios. In an NTN, an RF transceiver is amounted on a satellite, an unmanned aircraft systems (UAS) also called drone, balloon, plane, or another suitable apparatus. For simplicity, the discussion below refers to all such apparatus as satellites. In addition to satellites, an NTN can include the sat-gateways that connect the Non-Terrestrial Network to a public data network, feeder links between sat-gateways and satellites, service links between satellites, and inter- satellite links (ISL) when satellites form constellations.

[0005] A satellite can belong to one of several types based on altitude, orbit, and beam footprint size. The types include Low-Earth Orbit (LEO) satellite, Medium-Earth Orbit (LEO) satellite, Geostationary Earth Orbit (GEO) satellite, UAS platform (including High Altitude Platform Station, HAPS), and High Elliptical Orbit (HEO) satellite. GEO satellites are also known as the Geosynchronous Orbit (GSO) satellites, and LEO / MEO satellites are also known as the non-GSO (NGSO) satellites.

[0006] A GSO satellite can communicate with one or several sat-gateways deployed over a satellite targeted coverage area (e.g. a region or even a continent). A non-GSO satellite at different times can communicate with one or several serving sat-gateways. An NTN is designed to ensure service and feeder link continuity between successive serving sat-gateways, with sufficient time duration to proceed with mobility anchoring and hand-over.

[0007] A satellite can support a transparent or a regenerative (with on board processing) payload, and typically generates several beams for a given service area bounded by the field of view. The footprints of the beams typically have an elliptic shape and depend on the on-board antenna configuration and the elevation angle. For a transparent payload implementation, a satellite can apply RF filtering and frequency conversion and amplification, and not change the waveform signal. For a regenerative payload implementation, a satellite can apply RF filtering, frequency conversion and amplification, demodulation and decoding, routing, and coding / modulation. This approach is effectively equivalent to implementing most of the functions of a base station, e.g., a gNB or an eNB.

[0008] NB-IoT and eMTC technologies are expected to be particularly suitable for loT devices operating in remote areas with limited or no terrestrial connectivity. Such loT devices can be used in a variety of industries including for example transportation (maritime, road, rail, air) and logistics; solar, oil, and gas harvesting; utilities; farming; environmental monitoring; and mining. However, to ensure the required loT connectivity, deployment of these technologiesrequires satellite connectivity to provide coverage beyond terrestrial deployments. Satellite NB- loT or cMTC is defined in a complementary manner to terrestrial deployments.

[0009] An internet-of-things (loT) non-terrestrial network (NTN) generally has broad coverage, which is beneficial for emergency scenarios. Therefore, loT NTN has emerged as the technology of choice for emergency texting.

[0010] The requirements for an emergency service include identification and emergency callback, reliable transmission, and roaming support. It has been proposed for a 3GPP system with satellite access to (i) support an Emergency Texting Service that provides efficient and reliable transmission of non-IP data for emergency texting to and from an loT device; (ii) provide mechanisms to identify an loT device using the Emergency Texting Service; (iii) provide mechanisms for an authorized third party to route the Emergency Texting Service to and from a local emergency response center such as a Public Safety Answering Point (PSAP) that services the location where the loT device is located, and route responses to the loT device, including in roaming cases; (iv) provide mechanisms for an authorized third party to route the Emergency Texting Service to different emergency response centers based on the type of emergency; and (v) support Emergency Texting Service for an loT device regardless of whether the loT device has a Subscriber Identity Module (SIM), a Universal SIM (USIM), or an integrated SIM (IS IM).

[0011] Currently, however, an loT device does not support the emergency service as specified in TS 23.401 V18.5.O (2024-03), for example.SUMMARY

[0012] An example embodiment of the techniques of this disclosure is a method implemented in a user equipment (UE). The method includes selecting a cell of a non-terrestrial network (NTN) that supports Intemet-of-Things (loT) devices; transmitting, to a core network (CN) via the cell, a registration request message indicating that the UE requires an emergency messaging service (EMS); and establishing, with the cell, a protocol data unit (PDU) session for the EMS.

[0013] Another example embodiment of these techniques is an loT device configured to implement the method above.BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Fig. 1 A is a block diagram of an example wireless communication system in which a user device, a base station, and a core network of this disclosure can implement the emergency texting techniques of this disclosure;

[0015] Fig. IB is a block diagram of an example base station in which a centralized unit (CU) and a distributed unit (DU) that can operate in the system of Fig. 1 A;

[0016] Fig. 2A is a block diagram of an example protocol stack according to which the UE of Fig. 1A communicates with base stations;

[0017] Fig. 2B is a block diagram of an example protocol stack according to which the UE of Fig. 1A communicates with a CU and a DU;

[0018] Fig. 3 is a service-based representation of the CN architecture, which the system of Fig. 1A or Fig. IB can implement;

[0019] Fig. 4 is a reference-point based representation of the CN architecture, which the system of Fig. 1 can implement;

[0020] Fig. 5A is a block diagram of an example NTN node with transparent payload implementation ;

[0021] Fig. 5B is a block diagram of an example NTN node with transparent payload implementation, in which a base station connects to multiple satellites via the same sat-gateway;

[0022] Fig. 6A illustrates an exemplary user plane protocol stack for use with the architecture of Fig. 3A;

[0023] Fig. 6B illustrates an exemplary control plane protocol stack for use with the architecture of Fig. 3A;

[0024] Fig. 7 A is a messaging diagram of an example scenario in which an loT NTN cell broadcasts a new (dedicated, specific -purpose) broadcast information indicating Emergency Texting Service Support;

[0025] Fig. 7B is a messaging diagram of a scenario similar to that of Fig. 7 A, but in which the UE transmits a registration request with an emergency texting service request (rather than an emergency request along with an emergency texting service indicator);

[0026] Fig. 7C is a messaging diagram of a scenario similar to that of Fig. 7A, but in which the UE transmits a registration request with an emergency request along with an emergency texting service support indicator (rather than an emergency request along with an emergency texting service indicator);

[0027] Fig. 8A is a messaging diagram of an example scenario in which an loT NTN cell broadcasts Emergency service support and a new broadcast information indicating Cellular Internet-of-Things (CIoT) 5GS Optimizations Support;

[0028] Fig. 8B is a messaging diagram of a scenario similar to that of Fig. 8A, but in which the UE transmits a registration request with an emergency texting service request (rather than an emergency request along with an emergency texting service indicator);

[0029] Fig. 8C is a messaging diagram of a scenario similar to that of Fig. 8A, but in which the UE transmits a registration request with an emergency request along with an emergency texting service support indicator (rather than an emergency request along with an emergency texting service indicator);

[0030] Fig. 9 A is a messaging diagram of an example scenario in which an loT NTN cell broadcasts Emergency service support;

[0031] Fig. 9B is a messaging diagram of a scenario similar to that of Fig. 9A, but in which the UE transmits a registration request with an emergency texting service request (rather than an emergency request along with an emergency texting service indicator);

[0032] Fig. 9C is a messaging diagram of a scenario similar to that of Fig. 9A, but in which the UE transmits a registration request with an emergency request along with an emergency texting service support indicator (rather than an emergency request along with an emergency texting service indicator);

[0033] Fig. 10 is a messaging diagram of an example scenario a UE, implemented as an ToT device, initiates a PDU Session Establishment request procedure for emergency texting services using Non-IP data delivery (NIDD), with certain enhancements; and

[0034] Fig. 11 is a flow diagram of an example method in a UE for using an emergency messaging service in an NTN loT cell.DETAILED DESCRIPTION OF THE DRAWINGSOverview

[0035] The techniques discussed can apply to an Evolved Packet System (EPS), a fifthgeneration system (5GS), or a later-generation system. In the examples discussed below, an loT NTN can support a narrowband (NB) loT (NB-IoT) satellite radio access network (RAN) that can include an NBIoT-LEO, NBIoT-MEO, NBIoT-GEO, NBIoT-OTHERSAT for both EPS and 5GS.

[0036] Generally speaking, the techniques discussed with reference to Figs. 7A-11 pertain to an emergency messaging service (EMS), which can include emergency texting. The term “Satellite-Enabled Emergency Messaging Service (Sat-EMS)” can apply a non-IP-Multimedia- Subsystem (non-IMS) based messaging service provided to a UE that is resource-constrained and restricted to data only, where the non-IMS based messaging services uses satellite access to communicate IP / Non-IP data with certain prioritization treatment, e.g. for emergency events, over a 3GPP system.

[0037] Some of these techniques can be implemented in one or more network functions such as an Access and Mobility Management Function (AMF), a Session Management Function (SMF), a Network Exposure Function (NEF), an Application Function (AF) of a 5GS core (5GC) or in a Mobility Management Entity (MME), a Serving Gateway (SGW), a Service Capability Exposure Function (SCEF), a Services Capability Server (SCS) in an EPS core (EPC).

[0038] The discussion below addresses at least the following issues: whether and how an loT device and a 3GPP system with satellite access negotiate capability with respect to an emergency texting service; and if both the loT device and 3GPP system support the emergency textingservice, how does the 3GPP system with satellite access support efficient and reliable Non-IP data delivery (NIDD) for emergency texting to and from an loT device.

[0039] The discussion below includes, in part, the following solutions: (i) enhancement for broadcasting information with emergency texting service support, (ii) enhancement for broadcasting information with Cellular Intemet-of-Things (CIoT) core network optimization, (iii) support of an emergency texting service with no changes to the broadcasting information, and (iv): a protocol data unit (PDU) session for the NEF-based NIDD.Example use case

[0040] For clarity, an example scenario to which the techniques of this disclosure can pertain is briefly considered next. In an isolated location (c.g., a remote island), a person carries a “simple UE,” which can be a resource-constrained device such the loT device (e.g., the UE 102) of the scenarios below. The UE is capable only of non-IMS emergency messaging, e.g. SMS or IP / Non-IP data, to sustain longer battery life. This simple UE is configured with emergency messaging service settings and equipped with sensors (accelerometer, GPS). The UE can communicate emergency messaging over a 3GPP system with terrestrial access or satellite (more broadly, NTN) access.

[0041] Step 1 in this example scenario is an emergency trigger, such as detecting that the person carrying the simple UE fell. The fall or the impact triggers the simple UE to automatically initiate an emergency messaging procedure.

[0042] Step 2 is network selection. The simple UE assesses terrestrial access availability, but due to to the remote location, there is UE finds no cellular signal. The simple UE then assesses the availability of the 3GPP system with respective satellite access, and selects a network that provides a Sat-EMS service over the 3GPP system with satellite access.

[0043] Step 3 is registration: the simple UE uses the satellite access to register with the selected network for a Sat-EMS Service. Registration with the network operator, the satellite network operator, as well as an authorized third party can involve the unique identifier of the UE, such as an IMSI, a SUPI, or IMEI.

[0044] Step 4 is the emergency messaging data transmission. The simple UE sends emergency messaging data, which can include Global Positioning Service (GPS) coordinates, a timestamp, the emergency type indicator, optional sensor data, and a pre-set SOS text message, for example.

[0045] Step 5 is the emergency messaging data delivery. In particular, based on the identified emergency event included in the emergency messaging data, the network forwards the emergency messaging data to the application server of the authorized third party.

[0046] At step 6, the application server forwards the emergency messaging data. To this end, the application server determines the appropriate Local Emergency Response Center (LERC) based on the location of the simple UE location and then emergency type, and then routes the emergency messaging data to the proper LERC. In addition, the application server can forward the emergency messaging data to the emergency contacts associated with the profile of simple UE.

[0047] Step 7 can involve activity associated with the rescue. The LERC receives the emergency messaging data and provides the location on a map to rescuers. At this time, the LERC can reply with confirmation emergency messaging data the simple UE using satellite access.Example system, scenarios, and methods

[0048] Referring first to Fig. 1A, an example wireless communication system 100 includes a UE 102 (which can be an loT device), a base station (BS) 104, a base station 106, and a core network (CN) 110. The base stations 104 and 106 can operate in a RAN 105 connected to the core network (CN) 110. The CN 110 can be implemented as an evolved packet core (EPC) 111 or a fifth generation (5G) core (5GC) 160, for example. The CN 110 can also be implemented as a sixth generation (6G) core in another example.

[0049] As an loT device, the UE 102 can be dedicated to a set of specific use cases or services and is generally is allowed use only certain features limited to this type of UEs. In the examples below, the UE 102 can a Sat-EMS service. In general, an loT device may be optimized for the specific needs of services and applications the device executes (e.g. smart home / city, smartutilities, e-Health and smart wearables). Some loT devices are not intended for human type communications. When the UE 102 is an loT device able to access a 5G Public Land Mobile Network (PLMN) in a direct network connection mode using a 3GPP RAT, the UE 102 has a 3GPP subscription.

[0050] In some implementations, the CN 110 allows the operator to identify the UE 102 as an loT device based on the characteristics of the UE 102 (e.g. using an equipment identifier or a range of equipment identifiers), subscription data, or some combination of the characteristics and the subscription data.

[0051] In some PLMNs, the UE 102 can make an emergency call without sending the subscriber identity (IMS I) to the network. In this case, the CN 110 can limit the misuse of UE equipment after placing invalid emergency calls using the equipment identity. The network can send, to the UE, a request for the equipment identity after the emergency call has been set up.

[0052] The base station 104 covers a cell 124, and the base station 106 covers a cell 126. If the base station 104 is a gNB, the cell 124 is an NR cell. If the base station 104 is an ng-eNB or eNB, the cell 124 is an evolved universal terrestrial radio access (E-UTRA) cell. Similarly, if the base station 106 is a gNB, the cell 126 is an NR cell, and if the base station 106 is an ng-eNB or eNB, the cell 126 is an E-UTRA cell. The cells 124 and 126 can be in the same Radio Access Network Notification Areas (RNA) or different RNAs. In general, the RAN 105 can include any number of base stations, and each of the base stations can cover one, two, three, or any other suitable number of cells. The UE 102 can support at least a 5G NR (or simply, “NR”) or E- UTRA air interface to communicate with the base stations 104 and 106. Each of the base stations 104, 106 can connect to the CN 110 via an interface (e.g., SI or NG interface). The base stations 104 and 106 also can be interconnected via an interface (e.g., X2 or Xn interface) for interconnecting NG RAN nodes.

[0053] As discussed in more detail below, the RAN 105 can include NTN elements, and at least some of the cells (e.g., the cell 124, the cell 126) can be NTN cells. More specifically, the cells 124 and 126 can be NTN cells that supports loT devices, or loT NTN cells. As a more specific example, the cells 124 and 126 can be NB-IoT NTN cells of an NB-IoT RAN.

[0054] Among other components, the EPC 111 can include a Serving Gateway (SGW) 112, a Mobility Management Entity (MME) 114, and a Packet Data Network Gateway (PGW) 116. The SGW 112 in general is configured to transfer user-plane packets related to audio calls, video calls, Internet traffic, etc., and the MME 114 is configured to manage authentication, registration, paging, and other related functions. The PGW 116 provides connectivity from the UE to one or more external packet data networks, e.g., an Internet network and / or an Internet Protocol (IP) Multimedia Subsystem (IMS) network. The 5GC 160 includes a User Plane Function (UPF) 170 and an Access and Mobility Management Function (AMF) 164, and / or Session Management Function (SMF) 166. Generally speaking, the UPF 170 is configured to transfer user-plane packets related to audio calls, video calls, Internet traffic, etc., the AMF 164 is configured to manage authentication, registration, paging, and other related functions, and the SMF 166 is configured to manage PDU sessions. The CN 110 can connect to a Public Safety Answering Point (PS AP) 182.

[0055] As illustrated in Fig. 1A, the base station 104 supports a cell 124, and the base station 106 supports a cell 126. The cells 124 and 126 can partially overlap, so that the UE 102 can select, reselect, or hand over from one of the cells 124 and 126 to the other. To directly exchange messages or information, the base station 104 and base station 106 in some implementations support an X2 or Xn interface. In general, the CN 110 can connect to any suitable number of base stations supporting NR cells and / or EUTRA cells.

[0056] The base station 104 is equipped with processing hardware 130 that can include one or more general-purpose processors (e.g., CPUs) and a non-transitory computer-readable memory storing instructions that the one or more general-purpose processors execute. Additionally or alternatively, the processing hardware 130 can include special-purpose processing units. The processing hardware 130 in an example implementation includes a processor 132 to process data that the base station 104 will transmit in the downlink direction, or process data received by the base station 104 in the uplink direction. The processing hardware 130 can also include a transmitter 136 configured to transmit data in the downlink direction. The processing hardware further can include a receiver 134 configured to receive data in the uplink direction. The base station 106 can include generally similar components.

[0057] The UE 102 is equipped with processing hardware 150 that can include one or more general-purpose processors such as CPUs and non-transitory computer-readable memory storing machine-readable instructions executable on the one or more general-purpose processors, and / or special-purpose processing units. The processing hardware 150 in an example implementation includes a processor 152 to process data that the UE 102 will transmit in the uplink direction, or process data received by UE 102 in the downlink direction. The processing hardware 150 can also include a transmitter 156 configured to transmit data in the downlink direction. The processing hardware further can include a receiver 154 configured to receive data in the uplink direction.

[0058] Fig. IB depicts an example distributed or disaggregated implementation of any one or more of the base stations 104, 106. In this implementation, the base station 104, 106 includes a central unit (CU) 172 and one or more distributed units (DUs) 174. The CU 172 includes processing hardware, such as one or more general-purpose processors (e.g., CPUs) and a computer-readable memory storing machine-readable instructions executable on the general- purpose processor(s), and / or special-purpose processing units. For example, the CU 172 can include a PDCP controller, an RRC controller and / or an RRC inactive controller. In some implementations, the CU 172 can include a radio link control (RLC) controller configured to manage or control one or more RLC operations or procedures. In further implementations, the CU 172 does not include an RLC controller.

[0059] Each of the DUs 174 also includes processing hardware that can include one or more general-purpose processors (e.g., CPUs) and computer-readable memory storing machine- readable instructions executable on the one or more general-purpose processors, and / or specialpurpose processing units. For example, the processing hardware can include a MAC controller configured to manage or control one or more MAC operations or procedures (e.g., a random access procedure), and / or an RLC controller configured to manage or control one or more RLC operations or procedures. The process hardware can also include a physical layer controller configured to manage or control one or more physical layer operations or procedures.

[0060] In some embodiments, the RAN 105 supports Integrated Access and Backhaul (IAB) functionality. In some implementations, the DU 174 operates as an lAB-node, and the CU 172operates as an TAB-donor. In some embodiments, the RAN 105 supports Non-Terrestrial Network (NTN) functionality.

[0061] In some implementations, the CU 172 can include a logical node CU-CP 172A that hosts the control plane part of the PDCP protocol of the CU 172. The CU 172 can also include logical node(s) CU-UP 172B that hosts the user plane part of the PDCP protocol and / or Service Data Adaptation Protocol (SDAP) protocol of the CU 172. The CU-CP 172A can transmit control information (e.g., RRC messages, Fl application protocol messages), and the CU-UP 172B can transmit the data packets (e.g., SDAP PDUs or Internet Protocol packets).

[0062] The CU-CP 172A can be connected to multiple CU-UP 172B through the El interface. The CU-CP 172A selects the appropriate CU-UP 172B for the requested services for the UE 102. In some implementations, a single CU-UP 172B can connect to multiple CU-CP 172A through the El interface. The CU-CP 172A can connect to one or more DU 174s through an Fl-C interface. The CU-UP 172B can connect to one or more DU 174 through the Fl-U interface under the control of the same CU-CP 172A. In some implementations, one DU 174 can connect to multiple CU-UP 172B under the control of the same CU-CP 172A. In such implementations, the connectivity between a CU-UP 172B and a DU 174 is established by the CU-CP 172A using Bearer Context Management functions.

[0063] Fig. 2A illustrates, in a simplified manner, an example protocol stack 200 according to which the UE 102 can communicate with an eNB / ng-eNB or a gNB (e.g., one or more of the base stations 104, 106).

[0064] In the example stack 200, a physical layer (PHY) 202A of EUTRA provides transport channels to the EUTRA MAC sublayer 204A, which in turn provides logical channels to the EUTRA RLC sublayer 206A. The EUTRA RLC sublayer 206A in turn provides RLC channels to an EUTRA PDCP sublayer 208 and, in some cases, to an NR PDCP sublayer 210. Similarly, the NR PHY 202B provides transport channels to the NR MAC sublayer 204B, which in turn provides logical channels to the NR RLC sublayer 206B. The NR RLC sublayer 206B in turn provides data transfer services to the NR PDCP sublayer 210. The NR PDCP sublayer 210 in turn can provide data transfer services to Service Data Adaptation Protocol (SDAP) 212 or aradio resource control (RRC) sublayer (not shown in Fig. 2A). The UE 102, in some implementations, supports both the EUTRA and the NR stack as shown in Fig. 2A, to support handover between EUTRA and NR base stations and / or to support DC over EUTRA and NR interfaces. Further, as illustrated in Fig. 2A, the UE 102 can support layering of NR PDCP 210 over EUTRA RLC 206A, and SDAP sublayer 212 over the NR PDCP sublayer 210.

[0065] The EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 receive packets (e.g., from an Internet Protocol (IP) layer, layered directly or indirectly over the PDCP layer 208 or 210) that can be referred to as service data units (SDUs), and output packets (e.g., to the RLC layer 206 A or 206B) that can be referred to as protocol data units (PDUs). Except where the difference between SDUs and PDUs is relevant, this disclosure for simplicity refers to both SDUs and PDUs as “packets.”

[0066] On a control plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 can provide signaling radio bearers (SRBs) or RRC sublayer (not shown in Fig. 2A) to exchange RRC messages or non-access-stratum (NAS) messages, for example. On a user plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 can provide Data Radio Bearers (DRBs) to support data exchange. Data exchanged on the NR PDCP sublayer 210 can be SDAP PDUs, Internet Protocol (IP) packets or Ethernet packets.

[0067] Fig. 2B illustrates, in a simplified manner, an example protocol stack 250, which the UE 102 can communicate with a DU (e.g., DU 174) and a CU (e.g., CU 172). The radio protocol stack 200 is functionally split as shown by the radio protocol stack 250 in Fig. 2B. The CU at any of the base stations 104 or 106 can hold all the control and upper layer functionalities (e.g., RRC 214, SDAP 212, NR PDCP 210), while the lower layer operations (e.g., NR RLC 206B, NR MAC 204B, and NR PHY 202B) are delegated to the DU. To support connection to a 5GC, NR PDCP 210 provides SRBs to RRC 214, and NR PDCP 210 provides DRBs to SDAP 212 and SRBs to RRC 214.

[0068] Fig. 3 is a service-based representation 300 of an example CN architecture, which the CN 110 of Fig. 1 for example can implement. In the representation 300, the overall non-roaming reference architecture of the policy and charging control (PCC) framework for the 5GS includescomponents illustrated using solid lines, and the other components are illustrated using dashed lines. According to this representation, network functions enable other authorized network functions to access their services. The components that are outside the PCC framework include a Network Slicing Selection Function (NSSF) 302, a Network Repository Function (NRF) 306, a Unified Data Management (UDM) 308, an Edge Application Server Discovery Function (EASDF) 310, a Network Slice Specific Authentication and Authorization Function (NSSAAF) 312, an Authentication Server Function (AUSF) 314, a Service Communication Proxy (SCP) 316, and a Network Slice Admission Control Function (NSACF) 318. The non-PCC architecture further includes the Ues 102A and 102B, the PINEs 108A and 108B, and the IAN 105.

[0069] The PCC framework in the architecture 300 includes a Unified Data Repository (UDR) 352, a Network Exposure Function (NEF) 354, a network data analytics function (NWDAF) 356, an Application Function (AF) 358, a Policy Control Function (PCF) 360, a Charging Function (CHF) 362, an Access & Mobility Management Function (AMF) 364, a Session Management Function (SMF) 366, and a User Plane Function (UPF) 370.

[0070] The AMF 364 is generally configured to manage registration, connection, and mobility of a UE (such as the UE 102A or 102B) and provide transport for session management (SM) messages between the UE 102A or 102B and the SMF 366. In some implementations, the AMF 364 is configured to generate logical interface IDs, as will be described below in detail.

[0071] The SMF 366 is generally configured to manage sessions, allocate IP addresses for UEs, and provides downlink (DL) notifications. The UDM 308 is generally configured to handle user identification, access authorization based on subscription data, and subscription management. In some implementations, the UDM 308 is configured to generate or change logical interface IDs, as will be described below in detail. In some implementations, the UDM 308 supports the functionality of PIN group management handling.

[0072] The UDR 352 is generally configured to store subscription-related information, such as subscription data, policy data, structured data for exposure, and application data. In some implementations, the UDR 352 is configured to store PIN communication configuration information, as will be described below in detail. The UPF 370 is generally configured to handlepacket routing and forwarding. Tn some implementations, the UPF 370 includes a functionality of supporting PDR configuration with a packet filter set for the PIN. The NEF 354 is generally configured to expose a network’s capabilities and services to authorized third-party applications.

[0073] The AF 358 in some deployment operates in a trusted domain or outside the trusted domain, i.e., in a non-trusted domain. The trusted domain is generally internal to the CN 110 and includes such components as the UDM 308, the UDR 352, the PCF 360, the AMF 364, the SMF 366, and the UPF 370. Generally speaking, an AF operating outside the trusted domain (such as operated by an authorized third-party entity) can access the network functions of the CN 110 only via the NEF 354, whereas an AF operating within the trusted domain can access at least some of the network functions of the CN 110 directly, or may access these functions via the NEF 354 in some deployments. The UE 102 or the AF 358 may provide QoS flow parameters to the CN 110.

[0074] A Binding Support Function (BSF) 390 can support correlation of sessions across multiple policy servers, which allows operators to scale the network.

[0075] The AMF 364 can correspond to the AMF 164, the SMF 366 can correspond to the AMF 166, and the UPF 370 can correspond to the UPF 170, respectively, in the system of Fig. 1A.

[0076] Fig. 4 is a reference-point based representation 400 of an example 5GS architecture. In Fig. 4, the non-roaming reference architecture of the PCC framework for the 5GS is illustrated as blocks and connections with solid lines, and components and connections outside the PCC framework are illustrated using dashed lines. Also, the BSF 390 can have local respective interfaces to the AF 358, the NEF 354, and PCF 360.

[0077] Next, Fig. 5A illustrates a certain type of NTN deployment referred to as transparent payload architecture, which involves a satellite gateway 502 and a “transparent” satellite 504 for extending the range of the Uu interface. The satellite 504 implements a frequency conversion and a Radio Frequency (RF) amplifier in both the uplink and downlink directions. The satellite function is similar to that of an analogue RF repeater. As a result, the satellite 504 repeats the Uu radio interface from the feeder link (between the NTN gateway and the satellite) to the servicelink (between the satellite and the UE) in the downlink direction and vice versa in the uplink direction. The Satellite Radio Interface (SRI) on the feeder link is the Uu, and the NTN gateway 502 supports all necessary functions to forward the signal of the Uu interface. The NTN gateway 502 can be placed at the same site as the base station (e.g., eNB, gNB) 104 location, or be connected to the base station 104 at a distance via a wired link. It is also possible to connect more than one NTN gateway to a base station. Different transparent satellites may be connected to the same base station on the ground, via the same NTN gateway, or via different NTN gateways.

[0078] Fig. 5B illustrates the case where two different satellites (504 and 506) are connected to the same base station 104 via the same NTN gateway 502, and these two satellites (504 and 506) are covering the Earth surface using two different Physical Cell IDs (PCIs).

[0079] The NTN user plane protocol stack involving the UE 102, satellite 504, NTN gateway 502, the BS 104 and the S-GW 114 is illustrated in Fig. 6A. The diagram of the NTN user plane protocol stack is similar to that of the terrestrial network (TN), with the addition of two new nodes, the satellite 504 and the NTN gateway 502, being placed in the middle of the Uu interface. Similarly, the NTN control plane protocol stack illustrated in Fig. 6B is also similar to that of the terrestrial network.

[0080] Referring generally to Figs. 1-5B, an NTN can support at least three types of service links NTN, described in terms of satellite movement patterns: (i) Earth-fixed: provisioned by beam(s) continuously covering the same geographical areas all the time (e.g., the case of GEO / GSO satellites); (ii) Quasi-Earth-fixed: provisioned by beam(s) covering one geographic area for a limited period and a different geographic area during another period (e.g., the case of LEO / MEO satellites capable of using steerable beams); and (iii) Earth-moving: provisioned by beam(s) whose coverage area slides over the Earth surface (e.g., the case of LEO / MEO satellites using fixed or non-steerable beams).

[0081] With LEO / MEO satellites, a base station can provide either quasi-Earth-fixed cell coverage or Earth-moving cell coverage. With GEO satellites, the base station can provide Earth fixed cell coverage.

[0082] Although the transparent payload architecture illustrated in Figs. 3A and 3B is the current focus of the 3GPP development, the regenerative payload architecture that places some of the base station functions on the satellite is also a possible NTN deployment in the future. In such an architecture, the Uu only exists between the satellite and the UE. In general, the techniques of this disclosure can apply to the transparent payload architecture as well as the regenerative payload architecture.

[0083] Referring to Figs. 7A-C, a base station servicing an loT NTN cell in scenarios 700A-C broadcasts a new (specific-purpose, dedicated) broadcast information indicating support of an emergency texting service. The UE 102 in these scenarios can be an loT device 102.

[0084] In particular, in a scenario 700A, the UE 102 selects an loT NTN cell for accessing the network when the UE 102 determines that it requires an emergency texting service and receives 702, from the RAN 105, broadcasting information indicating support of emergency texting service.

[0085] The UE 102 performs 702A a Registration Request procedure. More specifically, during an RRC Connection Setup procedure, the UE 102 sends an RRCSetupRequest message in which the establishmentcause field is set to “emergency.” Alternatively, establishmentcause can have a new (dedicated, special-purpose) value such as “emergencyTexting,” to differentiate the use of radio resources from emergency bearer services. In the Registration Request message, the UE 102 can request the emergency texting service using NIDD or a new (dedicated, specialpurpose) registration type as emergency texting registration.

[0086] In the scenario 700A of Fig. 7A, the UE 102 sets 704A the registration type to “emergency registration for emergency service registration” and includes an emergency texting service indicator, in the Registration Request message.

[0087] Alternatively, in the scenario 700B of Fig. 7B, the UE 102 sets 704B the registration type to a dedicated, special-purpose value such as “emergency texting registration.”

[0088] As yet another alternative, in the scenario 700C of Fig. 7C, the UE 102 sets 704C the registration type to “emergency registration” similar to the scenario 700A, and includes an emergency texting service support indicator in Preferred Network Behavior IE.

[0089] For an emergency registration, the UE 102 includes a Subscription PermanentIdentifier (SUPI) or, when the UE 102 docs not have a SUP, an International Mobile Equipment Identity IMEI (IMEI) in the Registration Request message.

[0090] With continued reference to Figs. 7A-C, the AMF 366 can request 705 that the UDM 308 retrieve UE subscription service data for emergency services or emergency texting services based on the SUPI. For an unauthenticated UE which indicates IMEI, the AMF 366 can use the local policy for emergency services or emergency texting services.

[0091] The AMF 366 determines 706 to enable emergency texting services for the UE 102 (which can be an loT device) that accesses the network using the radio access technology (RAT) type set to NB-IoT Satellite RAT (e.g. NBIoT-LEO, NBIoT-MEO, NBIoT-GEO, NBIoT- OTHERSAT), based on the local policy or UE subscription data that include DNN or a combination of Data Network Name (DNN) and Single Network Slice Selection Assistance Information (S-NSSAI) with an indication of emergency texting.

[0092] After the registration procedure, the UE 102 can operate in the CM registered state in case of successful registration, or in a limited state in case of unsuccessful registration. If the registration is successful, the AMF 366 sends 708, to the UE 102, a Registration Accept message including an emergency texting service support indicator. If the AMF 366 supports the emergency texting service, the AMF 366 can include the emergency texting service support indicator in a 5GS network feature support IE. Generally speaking, the emergency texting service support indicator informs the UE 102 that the network supports emergency texting services, and thus the UE 102 is allowed to request a PDU Session for emergency texting services for NIDD. Based on the emergency texting service support indicator, the UE 102 enables the emergency texting service and performs a procedure 712.

[0093] On the other hand, when the registration is unsuccessful, the AMF 366 specifies the corresponding cause in the Registration Reject message. The cause can indicate, for example, that emergency texting services are not available, or that emergency texting services are not authorized, or that emergency texting services require a subscription, etc.

[0094] The UE 102 performs 712 a PDU Session Establishment request procedure. In one implementation, in the PDU Session Establishment Request message, the UE 102 indicates that the request type for the 5GSM message is an initial emergency request, and includes S-NSSAI and DNN for emergency texting. In another implementation, in the PDU Session Establishment Request message, the UE 102 indicates that the request type for the 5GSM message is a new (i.e., special-purpose) emergency texting service type, and includes S-NSSAI and DNN for emergency texting.

[0095] The UE 102 then sends 732 Non-IP (unstructured) data for emergency texting services to the AF 380 using the established PDU Session. The User Identity the UE 102 and the network can use in these procedures can be the SUPI for mobile-originated (MO) data or an External Identifier or an Mobile Station International Subscriber Directory Number (MSISDN) for mobile-terminated (MT) data when the UE 102 is authenticated, and the IMEI or an emergency texting service user identifier when the UE 102 is unauthenticated. This operation can include an enhancement of the following procedures: (i) the NEF Anchored Mobile Originated Data Transport (MO) for the NEF Anchored Mobile Originated Data Transport procedure, described in TS 23.502, and (ii) the NEF Anchored Mobile Terminated Data Transport (MT) for the procedure using which the AF sends unstructured data to a given user as identified via External Identifier or MSISDN, also described on TS 23.502

[0096] Now referring to scenarios 800A-C of Figs. 8 A-C, a base station servicing an loT NTN cell can broadcast an indication of emergency service support along with new (special-purpose) broadcast information indicating CIoT 5GS optimization support.

[0097] In particular, when the UE 102 requires an emergency texting service and receives 802 an indication of emergency service support and a new broadcasting information of CIoT 5GS optimization support from a camp-on loT NTN cell using a satellite RAT, the UE 102 selects the cell and initiates 820 the Registration Request procedure for the emergency service registration, with the request type indicating emergency registration.

[0098] The UE 102 performs 804A, 804B, or 804C the Registration Request procedure as follows. Similar to the scenarios 700A-C, the UE 102 sends an RRCSetupRequest message inwhich the establishmentCause field is set to “emergency” or, alternatively, a new (dedicated, special-purpose) value such as “cmcrgcncyTcxting,”

[0099] In the scenario 800A of Fig. 8A, the UE 102 sets 804A the registration type to “emergency registration for emergency service registration” and includes an emergency texting service indicator, and a CIoT 5GS Optimization Support indicator in the Preferred Network Behavior IE, in the Registration Request message to request emergency texting using NIDD.

[0100] Alternatively, in the scenario 800B of Fig. 8B, the UE 102 sets 804B the registration type to a dedicated, special-purpose value such as “emergency texting registration” and a CIoT 5GS Optimization Support indicator in the Preferred Network Behavior IE, in the Registration Request message to request emergency texting using NIDD.

[0101] As yet another alternative, in the scenario 800C of Fig. 8C, the UE 102 sets 804C the registration type to “emergency registration” similar to the scenario 800A, and includes an emergency texting service support indicator in Preferred Network Behavior IE to request emergency texting using NIDD.

[0102] For an emergency registration, the UE 102 includes a SUP1 or 1ME1 in the Registration Request message. Next, events 805 and 806 are similar to the events 705 and 706 discussed above with reference to Figs. 7A-C.

[0103] After the registration procedure, the UE 102 can operate the in CM registered state in case of successful registration or in a limited state in case of unsuccessful registration. If the registration is successful, and if the AMF 366 supports emergency services and CIoT 5GS optimization, the AMF 366 sends 808, to the UE 102, a Registration Accept message including an emergency texting service support indicator in a 5GS network feature support IE. Alternatively, if the registration is successful, and if the AMF 366 supports the emergency service and control-plane CIoT 5GS optimization, the AMF 366 sends 808 a Registration Accept message with an emergency service support indicator and an indication of control-plane CIoT 5GS optimization support in a 5GS network feature support IE. Both the emergency texting service support indicator and the control-plane CIoT 5GS optimization can implicitly indicate to the UE 102 that the network supports emergency texting services, i.e., that the UE is allowed torequest a PDU Session for emergency texting services for NIDD. When the registration is unsuccessful, the AMF 366 can specify the corresponding cause in the Registration Reject message similar to the scenarios 700A-C.

[0104] Now referring to example scenarios 900A-C of Figs. 9A-C, a base station servicing an loT NTN cell in these broadcasts an indication of emergency service support.

[0105] When the UE 102 requires an emergency texting service and receives 902, from a camp-on loT NTN cell and via a satellite RAT, an emergency service support indication. The UE 102 selects 902 selects the cell and initiates a registration request procedure for the emergency service registration, with the request type indicating emergency registration.

[0106] In particular, during an RRC connection setup procedure, the UE sends 904A an RRCSetupRequest message with the establishmentcause field set to “emergency” or a new, special-purpose value such as “emergencyTexting,” to differentiate the radio resource usage from emergency bearer services. As in the scenarios discussed above, the UE 102 performs a Registration Request procedure. In particular, the UE 102 sends 904A a Registration Request message, which indicates a request for an emergency texting service using NIDD.

[0107] In the scenario 900A of Fig. 9A, the UE 102 sets 904A the registration type to “emergency registration for emergency service registration” and includes an emergency texting service indicator, in the Registration Request message. Alternatively, in the scenario 900B of Fig. 9B, the UE 102 sets 904B the registration type to a dedicated, special-purpose value such as “emergency texting registration,” in the Registration Request message. As yet another alternative, in the scenario 900C of Fig. 9C, the UE 102 sets 904C the registration type to “emergency registration” and includes an emergency texting service support indicator in Preferred Network Behavior IE. Also similar to the scenarios above, the UE 102 includes a SUPI or IMEI (when the SUPI is unavailable) in the Registration Request message.

[0108] Events 905-932 are similar to the events 905-932 discussed above with reference to Fig. 7A.

[0109] Now referring to Fig. 10, a scenario 1000 is consistent with the approaches discussed above, where the UE 102, implemented as an loT device, initiates a PDU Session Establishment request procedure for emergency texting services using NIDD.

[0110] In some implementations, the AMF that supports emergency texting services (e.g., the AMF 364) stores a local configuration of the NEF Identity for NIDD of an emergency texting service associated with a certain combination of DNN and S-NSSAI.

[0111] When the UE 102 performs the PDU Session establishment procedure with PDU session type set to "unstructured," and the local configuration includes "NEF Identity for NIDD of emergency texting" (EMRtxt-NEF ID) for the corresponding UE requested DNN and S- NSSAI combination, the SMF 366 initiates an SMF-NEF Connection establishment procedure toward the NEF corresponding to the "EMRtxt-NEF ID" for that DNN I S-NSSAI Combination.

[0112] For the emergency texting services support of an unauthenticated UE, the network identifies the UE using the IMEI or a user identifier associated with the IMEI for emergency texting services (emergency texting service user identifier). The UE and the network can utilize the user identifier during related procedures that require a user identifier. For simplicity, in this discussion, the IMEI represents the user identifier for an unauthenticated UE.

[0113] Procedure 1002 can include the events 702, 704A-C, 705, and 706 discussed with reference to Figs. 7A-C, or the events 802, 804A-C, 805, and 806 discussed with reference to Figs. 8A-C, or the events 902, 904A-C, 905, and 906 discussed with reference to Figs. 9A-C.

[0114] During the registration procedure, the UDM 308 can trigger 1007 a certain new (special-purpose) procedure with the NEF 354 (which can be identified by EMRtxt-NEF ID) or with the AF 380 using a certain new (special-purpose) service operation, to initiate 1009 an NIDD configuration for emergency texting services with the local AF 380, associated with an authorized third party, which can dispatch the emergency event to an appropriate PSAP such as the PSAP 182. More specifically, the UDM 308 can trigger 1007 the procedure with the NEF 354 associated with an EMRtxt-NEF ID, to configure an emergency texting service, using for example an Nnef_NIDD_Get request and an Nnef_NIDD_Get response messages. According to the other option, the UDM 308 triggers 1007 the procedure directly with the AF 380, toconfigure an emergency texting service, using for example an Naf_NIDD_Get request and an Naf_NIDD_Gct response message.

[0115] During the configuration procedure, the network obtain and / or updates 1009 the NIDD configuration for emergency texting services from the AF 380, for the authenticated UE 102 (identified by a SUPI, a Generic Public Subscription Identifier (GPSI), etc.) and / or the unauthenticated UE 102 (to be identified by an IMEI for an emergency texting service user identifier).

[0116] When the UDM 308 initiates 1007 the procedure according to the first option, i.e., with the NEF 354, the AF 380 can configure the necessary information at the NEF 354 for NIDD of emergency texting service using a NIDD API. The related procedure can be based on TS 23.502 clause 4.25.3 (“NIDD Configuration”), with the appropriate enhancement or modification for supporting of an unauthenticated UE. As discussed above, the UE can be identified for example by an IMEI or a user identifier associated with the IMEI for emergency texting services (an emergency texting service user identifier).

[0117] When the UDM 308 initiates 1007 the procedure according to the second option, i.e., directly with the AF 354, the AF 354 stores the necessary user identifier information of the authenticated UE or unauthenticated UE. For emergency texting services, the SMF 366 can use a new (special-purpose) service operation of the AF 366 to forward MO NIDD for emergency texting or MT NIDD for emergency texting, for an authenticated an UE as well as for an unauthenticated UE.

[0118] The UE sends 1012, to the AMF 364, a PDU Session Establishment Request message indicating the SUPI or the IMEI, the request type for the 5GSM message as “initial emergency request,” the PDU Session ID, the S-NSSAI, and the DNN for emergency texting. The UE 102 can include a Reliable Data Service (RDS) support indication if the UE capability with an indication of RDS support is included in the Protocol Configuration Option (PCO) in the PDU Session Establishment Request message.

[0119] Based on the DNN or the combination of DNN and S-NSSAI values for emergency texting in the local policy or the UE subscription data, the AMF 364 determines 1014 to enableemergency texting services for the ToT device (i.e., the UE 102) that accesses the network using the RAT type indicating an NB-IoT Satellite RAT (c.g. NBIoT-LEO, NBIoT-MEO, NBIoT- GEO, NBIoT-OTHERSAT). The AMF 364 also selects 1014 an SMF configured for emergency texting services using NIDD, e.g., the SMF 366.

[0120] Based on the DNN for an emergency texting service and the S-NSSAI, the AMF 364 obtains 1016 the NEF Identity for NIDD of emergency texting service (EMRtxt-NEF ID) and the NIDD information, using the local configuration for emergency texting services, and sends 1016, to the SMF 366, an Nsmf_PDUSession_CreateSMContext Request message including the NEF identity for NIDD of an emergency texting service (EMRtxt-NEF ID) and the NIDD information (e.g., user identity of GPSI or IMEI, and an AF Identifier). When the UE 102 is an authenticated UE, the AMF 364 provides a GPSI to the SMF 366. When the UE 102 is an unauthenticated UE, the AMF 364 provides an IMEI to the SMF 366.

[0121] The SMF 366 can retrieve or update 1018 the UE subscription for the UE 102. The SMF 366 then responds 1019 to the AMF 364.

[0122] Next, during an SMF-NEF Connection establishment procedure and upon receiving the NEF Identity for NIDD of an emergency texting service (EMRtxt-NEF ID), the SMF 366 creates 1020 a PDU session with the NEF 354. To this end, the SMF 366 sends 1020, to the NEF 354, an Nnef_SMContext_Create Request message including a user identity with the value of SUPI or the IMEI, the PDU Session ID, the SMF ID, the NIDD information (GPSI or IMEI, AF-ID), the S-NSSAI, the DNN, and (optionally) the RDS support indication. The SMF 366 includes the RDS support indication if the UE capability with an indication of RDS support is included in the Protocol Configuration Option (PCO) in the PDU Session Establishment Request message.

[0123] The NEF 354 creates 1022 an NEF PDU session Context for emergency texting services and associates it with User Identity of SUPI or IMEI and PDU session ID.

[0124] The NEF 354 sends 1024, to the SMF 366, an Nnef_SMContext_Create Response message including a cause value, optionally an RDS support indication, an optionally NIDD parameters. This message confirms for the UE 102 the establishment of the PDU session to the NEF 354. When the NEF 354 supports, allows the use of, RDS, the NEF 354 includes an RDSsupport indication in the Nnef_SMContext_Create Response message to SMF 366. Then, the SMF 366 includes the RDS support indication in the PCO. The NEF 354 sends the NIDD parameters (e.g. maximum packet size) to the SMF 366 when such parameters are available.

[0125] The SMF 366 sends 1026, to the UE 102, a PDU Session Establishment Accept message including a PCO IE with NIDD parameters and the RDS support indication.

[0126] When the NEF 354 receives 1032, from the UE 102, unstructured data identifies the NEF PDU Session context and the AF Address, the NEF 354 sends 1032 the unstructured data to the AF 380, in an Nnef_NIDD_DeliveryNotify Request message using a user identity indicating the GPSI or the IMEI, the unstructured data, and the RDS configuration). The user identity applied can be the SUPI (for MO data) or the External Identifier or the MSISDN (for MT data) for an authenticated UE, and the IMEI or the emergency texting service user identifier for an unauthenticated UE. These procedures can be based on the NEF Anchored Mobile Originated Data Transport (MO) procedure of TS 23.502, applicable to the NEF Anchored Mobile Originated Data Transport procedure, or the NEF Anchored Mobile Terminated Data Transport (MT) procedure of TS 23.502, when the AF 380 sends unstructured data to a given user.

[0127] Finally, referring to Fig. 11, an loT device such as the UE 102 implement a method 1100 to perform emergency messaging in an loT NTN cell. At block 1102, the UE 102 selects an loT NTN cell (see, e.g., events 702, 802, 902, 1002) and, optionally, determines 1102 that the loT NTN cell supports emergency (see, e.g., events 702, 802, 902, 1002). At block 1104, the loT device registers with the network and indicates that the loT is requesting an emergency messaging service, e.g., a Sat-EMS service (see, e.g., events 704A-C, 804A-C, 904A-C).

[0128] At block 1108, the loT device optionally receives, from the network, an indication that network supports the emergency messaging service (see, e.g., events 708, 808, 908). Next, at block 1112, the loT device establishes a PDU session for the emergency messaging service, with the network (see, e.g., events 712, 812, 912, 1012). At block 1132, the loT device performs NIDD for the emergency messaging service (see, e.g., events 732, 832, 932, 1032).

[0129] The following list of examples reflects a variety of the embodiments explicitly contemplated by the present disclosure.

[0130] Example 1 . A method in a UE comprises transmitting, to a CN, via RAN, a registration request message indicating that the UE requires an emergency texting service (ETS); and establishing a protocol data unit (PDU) session for the ETS.

[0131] Example 2. The method of example 1, further comprising: receiving, from the RAN, a registration accept message indicating that the CN supports the ETS.

[0132] Example 3. The method of example 2, wherein the registration accept message includes an ETS support indicator.

[0133] Example 4. The method of example 2, wherein the registration accept message includes (i) an emergency service indictor and (ii) a cellular Internet-of-Things (CIoT) fifthgeneration system (5GS) optimization support indicator.

[0134] Example 5. The method of any of the preceding examples, further comprising, prior to the transmission of the registration request message receiving, from the RAN, a message including an indication of ETS support.

[0135] Example 6. The method of any of examples 1-4, further comprising, prior to the transmission of the registration request message: receiving, from the RAN, a message including (i) an indication of emergency services support and (ii) an indication of CIoT 5GS optimization support.

[0136] Example 7. The method of example 5 or 6, wherein the message is a broadcast message.

[0137] Example 8. The method of any of the preceding examples, wherein the registration request message includes (i) a registration type field indicating emergency service registration and (ii) an emergency texting service indicator.

[0138] Example 9. The method of any of examples 1-7, wherein the registration request message includes a registration type field indicating emergency texting registration.

[0139] Example 10. The method of any of examples 1-7, wherein the registration request message includes (i) a registration type field indicating emergency service registration and (ii) an emergency texting service support indicator.

[0140] Example 1 1 .The method of cl example aim 10, wherein the emergency texting service support indicator is included in a Preferred Network Behavior information clement (IE).

[0141] Example 12. The method of any of the preceding examples, wherein the UE is an internet of things (loT) device.

[0142] Example 13. A network node comprising processing hardware and configured to implement of any of the preceding examples.

[0143] Generally speaking, description for one of the above figures can apply to another of the above figures. Examples, implementations and methods described above can be combined, if there is no conflict. An event or block described above can be optional or omitted. For example, an event or block with dashed lines in the figures can be optional. In some implementations, “message” is used and can be replaced by “information element (IE)”, and vice versa. In some implementations, “IE” is used and can be replaced by “field”, and vice versa. In some implementations, “configuration” can be replaced by “configurations” or “configuration parameters”, and vice versa.

[0144] Although the discussion pertains primarily to loT devices, a user device in which the techniques of this disclosure more generally can be implemented (e.g., the UE 102) can be any suitable device capable of wireless communications such as a smartphone, a tablet computer, a laptop computer, a mobile gaming console, a point-of-sale (POS) terminal, a health monitoring device, a drone, a camera, a media- streaming dongle or another personal media device, a wearable device such as a smartwatch, a wireless hotspot, a femtocell, or a broadband router. Further, the user device in some cases may be embedded in an electronic system such as the head unit of a vehicle or an advanced driver assistance system (ADAS). Still further, the user device can operate as an intemet-of-things (loT) device or a mobile-internet device (MID). Depending on the type, the user device can include one or more general-purpose processors, a computer- readable memory, a user interface, one or more network interfaces, one or more sensors, etc.

[0145] Certain embodiments are described in this disclosure as including logic or a number of components or modules. Modules may can be software modules (e.g., code, or machine- readable instructions stored on non-transitory machine-readable medium) or hardware modules.A hardware module is a tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. A hardware module can comprise dedicated circuitry or logic that is permanently configured (e.g., as a special-purpose processor, such as a field programmable gate array (FPGA) or an application- specific integrated circuit (ASIC), a digital signal processor (DSP), etc.) to perform certain operations. A hardware module may also comprise programmable logic or circuitry (e.g., as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. The decision to implement a hardware module in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g.. configured by software) may be driven by cost and time considerations.

[0146] The term “or” as used herein is to be interpreted as an inclusive or meaning any one or any combination, unless expressly indicated otherwise, mutually exclusive, or indicated otherwise by context. Therefore, herein, the expression “A or B” means “A, B, or both A and B.”

[0147] When implemented in software, the techniques can be provided as part of the operating system, a library used by multiple applications, a particular software application, etc. The software can be executed by one or more general-purpose processors or one or more specialpurpose processors.

Claims

What is claimed is:

1. A method in a user equipment (UE), the method comprising: selecting a cell of a non-terrestrial network (NTN) that supports Intemet-of-Things (loT) devices; transmitting, to a core network (CN) via the cell, a registration request message indicating that the UE requires an emergency messaging service (EMS); and establishing, with the cell, a protocol data unit (PDU) session for the EMS.

2. The method of claim 1, further comprising: receiving, from the RAN, a registration accept message indicating that the CN supports the EMS.

3. The method of claim 2, wherein the registration accept message includes an EMS support indicator.

4. The method of claim 2, wherein the registration accept message includes (i) an emergency service indictor and (ii) a cellular Internet-of-Things (CIoT) fifth-generation system (5GS) optimization support indicator.

5. The method of any of the preceding claims, further comprising, prior to the transmission of the registration request message: receiving, from the RAN, a broadcast message including an indication of support of the EMS.

6. The method of any of claims 1-4, further comprising, prior to the transmission of the registration request message: receiving, from the RAN, a message including an indication of emergency services support.

7. The method of claim 6, wherein the message from the RAN further includes an indication of cellular Intcmct-of-Things (CIoT) Fifth Generation System (5GS) optimization support.

8. The method of any of the preceding claims, wherein the registration request message includes (i) a registration type field indicating emergency service registration and (ii) an emergency texting service indicator.

9. The method of any of claims 1-7, wherein the registration request message includes a registration type field indicating emergency texting registration.

10. The method of any of claims 1-7, wherein the registration request message includes (i) a registration type field indicating an emergency service registration and (ii) an emergency texting service support indicator.

11. The method of claim 10, wherein the emergency texting service support indicator is included in a Preferred Network Behavior information element (IE).

12. The method of any of the preceding claims, wherein the UE is an internet of things (loT) device.

13. The method of any of the preceding claims, further comprising: sending, using the PDU session, non-IP data for the emergency messaging service.

14. The method of any of the preceding claims, wherein the registration request message indicates Non-IP data delivery (NIDD).

15. An Intemet-of-Things (loT) device comprising processing hardware and configured to implement of any of the preceding claims.

Images