Supporting priority emergency messaging in a cellular communication network

Abstract

A equipment (UE) receives (902), in a cell or a radio access network (RAN), an indication that priority non-Internet-Protocol-Multimedia-Subsystem (non-IMS ) messaging is supported; performs (910), with a core network (CN) via the cell, a registration procedure, which includes providing (990) an indication that the UE has a priority non-IMS message to send; and transmits, to the CN, the priority non-IMS message

Description

SUPPORTING PRIORITY EMERGENCY MESSAGING IN A CELLULAR COMMUNICATION NETWORKCROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims priority to and the benefit of the filing date of provisional U.S. Patent Application No. 63 / 681,775, entitled “Method of Handling Satellite-Enabled Priority Messaging Services,” filed on August 9, 2024. The entire content of the provisional application is hereby expressly incorporated herein by reference.FIELD OF THE DISCLOSURE

[0002] This disclosure relates generally to wireless communication systems such as 3GPP communication systems and, more particularly, to priority messaging between a resource- constrained device and a core network.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 3rd Generation Partnership Project (3GPP) has developed specifications for supporting, at a voice-capable user equipment (UE), emergency calls and Short Message Service (SMS) messaging over Internet Protocol (IP) Multimedia Service (IMS). However, Internet-of- Things (loT) devices operating in cellular communication networks can lack certain capabilities of a non-IOT UE and not support IMS emergency sessions. In general, an loT device is a type of UE dedicated to support a set of specific use cases or services, and which is allowed to use certain features restricted to this UE type. An loT device may be optimized for the specific needs of services and applications such as smart home, smart city, smart utilities, e-Health, or small wearable applications. Some loT devices are not intended for human type communications at all.

[0005] An loT device that can access a 5G Public Land Mobile Network (PLMN) using a direct network connection mode using a 3GPP radio access technology (RAT) has a 3GPP subscription. An operator can identify a UE as an loT device based on certain characteristics of the UE, such as the equipment identifier or a range of equipment identifiers, or based on the subscription of the UE, or both.

[0006] According to TS 23.401, support for emergency bearer services is not available when the UE is using a Narrowband loT (NB-loT) cell. More particularly, the Mobility Management Entity (MME) does not indicate, to a UE that accesses the network using a radio access type (RAT) type set to NB-loT, support for emergency bearer services using the Emergency Service Support indicator in the Attach and Tracking Area Update (TAU) procedures. An NB-loT cell does not indicate support for emergency services in any broadcast information.

[0007] NB-loT cells can be non-terrestrial network (NTN) cells. In particular, the fifthgeneration (5G) 3GPP technology relies primarily on legacy terrestrial networks, but 3GPP has proposed to extend 5G communications to NTNs with 5G new radio (NR) technologies, or with the Long-Term-Evolution (LTE) technologies tailored for the NB-IT or the enhanced Machine Type Communication (eMTC) scenarios. In an NTN, an RF transceiver is mounted on a satellite, an unmanned aircraft system (UAS) such as a 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.

[0008] 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.

[0009] A GSO satellite can communicate with one or several satellite-gateways deployed over a satellite targeted coverage area (c.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.

[0010] 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.

[0011] 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 technologies requires satellite connectivity to provide coverage beyond terrestrial deployments. Satellite NB- loT or eMTC is defined in a complementary manner to terrestrial deployments.

[0012] An loT NTN generally has broad coverage, which is beneficial for emergency scenarios. Therefore, loT NTN has become the technology of choice for emergency texting. In an emergency service context, the fundamental requirements include identification and emergency callback, reliable transmission, and roaming support.

[0013] It is widely recognized the loT and satellite industries that, because most loT devices have limited support for IMS, the use of SMS over IMS is not a viable alternative for supportingemergency messaging services. Both ToT devices and satellites have limited resources, which makes resource efficiency a crucial factor in delivering emergency messaging services.

[0014] Some third parties provide over-the-top (OTT) emergency messaging services for UEs that use normal sessions over 3GPP system or for proprietary devices using non-3GPP compliant satellite access. However, it is important to provide prioritization treatment within a 3GPP system with satellite access, to deliver timely notification from the UEs using satellite access to an OTT application server (AS). For emergency events subject to regulation requirements and operator policies, an AS can subsequently dispatch the IP / non-IP data to a proper Public Safety Answering Point (PSAP). This prioritization handling of emergency messaging data in a 3GPP system can enhance the availability of emergency services by leveraging the broader coverage provided by satellite access.

[0015] Thus, in connection with enabling an loT device to use emergency messaging services, it remains unclear how a resource-constrained UE, such as an loT device that lacks voice and IMS capabilities, can use Satellite-Enabled Priority Messaging Services. Further, it is not clear how prioritization treatment of messaging can be implemented within a 3GPP system with satellite access, to deliver a timely notification from a UE using satellite access to an OTT AS of an authorized third party. Still further, it is unclear how an loT device can obtain prioritization treatment of priority messaging services over a 3GPP system with satellite access during emergency events.SUMMARY

[0016] An example embodiment of the techniques of this disclosure is a method in a user equipment (UE). The method comprises receiving, in a cell or a radio access network (RAN), an indication that priority non-Internet-Protocol-Multimedia-Subsystem (non-IMS ) messaging is supported; performing, with a core network (CN) via the cell, a registration procedure, including providing an indication that the UE has a priority non-IMS message to send; and transmitting, to the CN, the priority non-IMS message.

[0017] Another example embodiment of these techniques is a UE comprising a transceiver, at least one sensor configured to determine a position of the UE, and processing hardware. The UE is configured to implement the method above,

[0018] Another example embodiment of these techniques is a method in one or more network functions (NFs) of a CN of a cellular communication system. The method comprises receiving, from a UE, a registration request including an indication that the UE has a non-IMS message to transmit; determining whether the CN supports priority non-IMS messaging; and transmitting, to the UE, a response to the registration request, the response including an indication of whether the UE is allowed to transmit the non-IMS message to the CN.

[0019] Still another example embodiment of these techniques is a CN of a cellular communication network, comprising processing hardware and configured to implement the method above.BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Fig. 1A is a block diagram of an example wireless communication system in which a user device and a core network of this disclosure can support priority non-IMS messaging;

[0021] 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;

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

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

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

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

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

[0027] 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;

[0028] Fig. 6A illustrates an example user plane protocol stack for use with the architecture of Fig. 5A;

[0029] Fig. 6B illustrates an example control plane protocol stack for use with the architecture of Fig. 5B;

[0030] Fig. 7 is a messaging diagram of an example scenario in which a UE transmits a priority non-IMS message via a RAN and a CN;

[0031] Fig. 8 is a flow diagram of an example method in a UE for performing network selection and network registration for transmitting a priority non-IMS message;

[0032] Fig. 9 is a flow diagram of an example method in a UE for transmitting a priority non- IMS message; and

[0033] Fig. 10 is a flow diagram of an example method in a core network (CN) for processing a priority non-IMS message from a UE.DETAILED DESCRIPTION OF THE DRAWINGSOverview

[0034] A CN and a UE of this disclosure support a priority non-IMS messaging service, new relative to the set of services described by 3GPP specifications, which can be referred to as Priority Messaging Service (PMS). When the UE uses this service over an NTN, the PMS can be referred as to a Satellite-Enabled PMS. The UE can be a resource-constrained device with data-only capability, and the PMS can provide prioritization treatment to SMS or IP / Non-IP data which the UE can transmit in the event of emergency for example over a 3GPP system. In a typical scenario, the UE uses satellite access to register with the 3GPP system and transmits a priority non-IMS message, and the service can be referred to as Satellite-Enabled Emergency Messaging Service (Sat-EMS).

[0035] For simplicity, in the discussion below, priority non-IMS messaging can be referred to as PMS, and a priority non-IMS message can be referred to as priority messaging data.

[0036] The techniques discussed can apply to an Evolved Packet System (EPS), a fifthgeneration system (5GS), or a latcr-gcncration system. Generally speaking, in the examples discussed below, an loT NTN can support a narrowband (NB) loT (NB-IoT) satellite radio access network (RAT) that can include an NBIoT-LEO, NBIoT-MEO, NBIoT-GEO, NBIoT- OTHERSAT for both EPS and 5GS.

[0037] In some implementations, 5GS procedures such as the registration procedure, the protocol data units (PDU) session establishment procedure generally conform to the corresponding 3GPP specifications (e.g., TS 23.501, TS 23.502) but include the additional functionality and support the additional parameters discussed below. Similarly, the EPC procedures such as the attach procedure, the default / dedicated bearer activation procedure, etc. generally conform to the corresponding 3GPP specifications but include the additional functionality and parameters to support priority non-IMS messaging.

[0038] The examples of this disclosure pertain primarily to satellite access due to the energy- constrained characteristics of satellite RATs. However, these techniques in general can be used in a UE and in a cell of any type, including cells associated with terrestrial access. For example, these techniques can apply to a 3GPP system that provides terrestrial-access cell for a priority event that is not subject to regulation requirements for emergency calls for UEs that use voice and / or IMS-based SMS.

[0039] In an example scenario, a user takes a simple, resource-constrained UE capable only of non-IMS emergency messaging (e.g. SMS or IP / Non-IP data), on a hike through a remote area. This simple UE is configured with emergency messaging services settings and equipped with sensors (e.g., an accelerometer, GPS). The UE can communicate emergency messaging over a 3GPP system with terrestrial access or satellite access.

[0040] While hiking the user falls and sustains an injury. The impact triggers the UE to automatically initiate an emergency messaging procedure. The UE assesses terrestrial access availability but, at this location, the UE does find a cellular signal in a terrestrial cell. The simple UE then assesses the availability of a 3GPP system with satellite access and selects a network that provides a Sat-EMS service over 3GPP with satellite access. Using satellite access, the UEaccess registers with the selected network for Sat-EMS Service. The UE uses a unique identifier of the simple UE, such as International Mobile Subscriber Identity (IMSI), Subscription Permanent Identifier (SUPI), or International Mobile Station Equipment Identity (IMEI), to register with the network operator, including the mobile network operator and the satellite network operator, as well as the authorized third party.

[0041] The simple UE then sends the emergency messaging data, which can include the precise GPS coordinates, the emergency type indicator (e.g. as specified in TS 22.101), optional sensor data, and a pre-set SOS text message. The network, based on the identified emergency event indicated in the emergency messaging data, forwards the emergency messaging data to the application server of the authorized third party in an efficient and reliable manner. The application in turn 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 and the emergency type and routes the emergency messaging data to the proper LERC. The application server can also forward the emergency messaging data to the user’s emergency contacts. After the LERC receives the emergency messaging data, the LERC determines the user’s location on a map and initiates a dispatch of a rescue team. At the same time, the LERC replies with a confirmation emergency messaging data to the simple UE, using the satellite access, to notify the user that help is on the way.

[0042] In this and similar scenarios, a 3GPP system with satellite access supports a priority non-IMS messaging service, and in particular a Sat-EMS service, for efficient and reliable transmission of non-IMS IP / Non-IP data with priority treatment, for emergency events and other priority events. As discussed in more detail below, the system provides network selection information to UEs for selecting a network with satellite access for a Sat-EMS service, provides mechanisms to support identification of a UE using satellite access for a Sat-EMS service, provide mechanisms for an authorized third party to route emergency messaging data to and from a LERC serving the location where the UE is located and route responses back to the UE, including the case of roaming.Example system

[0043] Referring first to Fig. 1 A, an example wireless communication system 100 includes a UE 102, a radio access network (RAN) 105 that includes base stations such as a base station (BS) 104, and a core network (CN) 110 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. The CN 110 can access a priority message service (PMS) authorization and accounting (PMS-AAA) server 182 operating in a corresponding network.

[0044] The base station 104 covers a cell 124. The base station 104 can operate as a part of an NTN and can be associated with a satellite according to an implementation discussed with reference to Fig. 5 A or Fig. 5B for example. The cell 124 accordingly can be an NTN cell and, more particularly, an loT NTN cell that supports an NB-IoT Satellite RAT such as NBIoT-LEO, NBIoT-MEO, NBIoT-GEO, NBIoT-OTHERSA, for EPS or 5GS implementations of the CN 110.

[0045] 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 station 104, and the base station 104 can connect to the CN 110 via an interface (e.g., SI or NG interface). The base station 104 also can be interconnected with other base stations of the RAN 105 via an interface (e.g., X2 or Xn interface) for interconnecting RAN nodes. The RAN 105 in general can include base stations such as gNBs that provide Next Radio (NR) cells, ng- eNB or eNB to provide an evolved universal terrestrial radio access (E-UTRA) cells, etc.

[0046] Example techniques in a CN for supporting priority non-IMS messaging arc discussed below with reference to the 5GC 160, but in general these techniques can be implemented in any suitable CN including the EPC 111.

[0047] Among other components, the EPC 111 can include a Serving Gateway (SGW) to transfer user-plane packets related to audio calls, video calls, Internet traffic, etc., and, a Mobility Management Entity (MME) to manage authentication, registration, paging, and other related functions, a Packet Data Network Gateway (PGW) to provide connectivity from the UE to one ormore external packet data networks, e.g., an Internet network and / or an Internet Protocol (IP) Multimedia Subsystem (IMS) network, and a Service Capability Exposure Function (SCEF) and / or Services Capability Server (SCS) to exposes the services and capabilities of the EPC 111 to external applications (none shown to avoid clutter). When the CN 110 includes the EPC 111, the CN techniques discussed with reference to Figs. 7-10 below can be implemented in the one or more of the SGW, the MME, the SCEF, and the SCF.

[0048] The 5GC 160 includes an Access and Mobility Management Function (AMF) 164, a Session Management Function (SMF) 166, a Network Exposure Function (NEF) 165, and a Unified Data Management (UDM) 168, along with other components. When the CN 110 implements the 5GC 160, the CN techniques for supporting priority non-IMS messaging can be implemented in the one or more of the AMF, the SMF, the NEF, and the AF, as discussed below

[0049] 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 transceiver 136 configured to transmit data over a radio interface in the downlink direction toward UEs and receive data the UEs transmit over the radio interface in the uplink direction.

[0050] The UE 102 is equipped with processing hardware 140 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 140 in an example implementation includes a processor 142 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 140 can also include a transceiver 144 configured to transmit data in the uplink direction and receive data in the downlink direction relative to the RAN 105. The processing hardware further can includeone or more sensors 146 such as for example a Global Positioning Service (GPS) unit, an accelerometer, etc.

[0051] The UE 102 implements, as a set of software instructions stored on non-transient computer-readable medium and executable by the processor 142, for example, a PMS controller 152 configured to generate priority non-IMS messages, request registration and PDU sessions for transmitting the priority non-IMS messages to the PMS-AAA server 182, etc. The PMS controller 152 can operate on PMS settings 156 stored in the memory of the UE 102, which can include manufacturer settings, operator settings, and / or user settings.

[0052] Next, Fig. IB depicts an example distributed or disaggregated implementation of any the base stations 104. In this implementation, the base station 104 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.

[0053] 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.

[0054] 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 includelogical 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).

[0055] 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.

[0056] 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 230 or a gNB 232 (e.g., the base station 104).

[0057] 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 a radio 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.

[0058] 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.”

[0059] 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.

[0060] 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.

[0061] Fig. 3 is a service-based representation 300 of an example CN architecture, which the CN 110 of Fig. 1 for example can implement. 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 UDM 368, 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) 315, and a Network Slice Admission Control Function (NSACF) 316.

[0062] The CN architecture 300 further includes a Unified Data Repository (UDR) 352, an NEF 365, 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, an SMF 366, and a User Plane Function (UPF) 370.

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

[0064] 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.

[0065] 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 handle packet routing and forwarding. The NEF 354 is generally configured to expose a network’s capabilities and services to authorized third-party applications.

[0066] 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 NEF354 in some deployments. The UE 102 or the AF 358 may provide QoS flow parameters to the CN 110.

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

[0068] 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.

[0069] Next, Fig. 5A illustrates a certain type of NTN deployment referred to as transparent payload architecture 500A, 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 service link (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.

[0070] Fig. 5B illustrates the case 500B, 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) cover the Earth surface using two different Physical Cell IDs (PCIs).

[0071] 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 planeprotocol 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.

[0072] In terms of the satellite moving pattern, there are three types of service links that are supported in NTN: (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), or (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).

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

[0074] Although the transparent payload architecture illustrated in Figs. 5A / 5B is the current focus of the 3GPP development, the regenerative payload architecture that installs the eNB 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.Transmitting priority non-IMS data

[0075] The UE 102 can be an loT device capable of satellite access using an NB-IoT Satellite RAT (e.g. NBIoT-LEO, NBIoT-MEO, NBIoT-GEO, NBIoT-OTHERSAT). The UE 102 can store (e.g., as a part of the PMS settings 156), one or more priority event IDs for which the UE 102 can attempt to initiate PMS. Using the sensor(s) 146, such as an accelerometer and / or a GPS unit, the UE 102 can generate sensor data (e.g., GPS coordinates) for inclusion in a priority message.

[0076] The AMF 164, the UDM 168, the SMF 166, and the NEF 165 can be implemented as the AMF 364, the UDM 368, the SMF 366, and the NEF 365, respectively.

[0077] The UE 102 can communicate priority messaging data over a 3GPP system with satellite access based on Non-Access Stratum (NAS) signaling, e.g., using control-plane cellular loT (CIoT) 5GS / EPS optimization, or using a Non-IP data delivery (NIDD) mechanism for delivery of IP / Non-IP data via a Network Exposure Function (NEF) or User Plane Function (UPF), toward an Application Server (AS) of the authorized third party. The UE 102 is capable of non-IMS based emergency messaging, e.g. SMS or IP / Non-IP data, to longer sustain battery life.

[0078] The PMS settings 156 can include home operator and / or manufacturer settings. The PMS settings 156 can include one or more of (i) a PMS indication to indicate PMS capability of the UE 102, (ii) a (first) list of priority event IDs for non-emergency events, (iii) a (second) list of priority event IDs for emergency events or a list of emergency event IDs, or (iv) one or more authorized party IDs.

[0079] A priority event ID included in the list of priority event IDs for non-emergency events corresponds to a priority event for which an authorized third party, which has a service-level agreement with one or more network operators, supports the PMS. The UE 102 is allowed to initiate PMS for the priority event ID included in the first list. A priority event ID or an emergency event ID in the second list corresponds to an emergency event subject to emergency regulations and operator policies associated with the CN.

[0080] Referring to a scenario 700 illustrated in Fig. 7, the UE 102 can receive 701, from an upper layer of the protocol stack implemented in the UE 102, a request including a PMS indication and a priority event ID. The UE 102 can determine to initiate (or “trigger”) a PMS procedure in view of the PMS settings 156, which as discussed above can include PMS parameters from a home operator or manufacturer settings. The default values provided as a pail of the manufacturer settings can include only priority event IDs corresponding to emergency events subject to emergency regulations. A priority event ID indicates an allowed priority eventfor the PMS which an authorized third party provides, according to service-level agreement with the network operator.

[0081] The UE 102 receives 702, in a camped-on cell of the RAN 105, broadcast information indicating PMS support. The camp-on cell can be an loT NTN cell, and the UE 102 can access this cell using a satellite RAT. When the UE 102 determines 701 to use PMS and receives 702 an indication of PMS support, the UE 102 selects the cell and the corresponding network. In an alternative implementation, the cell (e.g., an loT NTN cell) broadcasts a list of priority event IDs. The UE 102 selects the cell and the corresponding network only if the RAN 105 supports the required priority event ID (e.g., the priority event ID the upper layer provided 701).

[0082] The UE 102 then performs a Registration Request procedure by sending 710 a Registration Request message. To this end, the UE 102 first performs 709 an RRC Connection Setup procedure, during which the UE 102 sends, to the RAN 105, an RRCSetupRequest message. According to one implementation or scenario, the UE 120 sets the establishmentcause in the RRCSetupRequest message to emergency, if the priority event ID that triggered 701 the PMS at the UE 102 corresponds to an emergency event subject to local regulations. According to another implementation or scenario, the UE 120 sets the establishmentcause to a dedicated value such as PriorityMessagingService, so as to differentiate the use of radio resources from emergency bearer services, e.g. from IMS-based emergency calls or IMS over SMS.

[0083] The UE 102 can include 710, in the Registration Request message, a SUPI or an IMEI. To request a priority messaging service using NIDD, the UE 102 can include, in the Registration Request message, a registration type set to a dedicated value such as Priority Messaging registration (which indicates to the network that the registration request is for PMS), a PMS user ID, and the priority event ID. The UE 102 can format the Registration Request message in this manner when the UE 120 set 709 the establishmentcause in the RRCSetupRequest message to emergency.

[0084] On the other hand, if the UE 102 set 709 the establishmentcause to a dedicated value such as PriorityMessagingService, the UE 102 can include, in the Registration Request message, the registration type set to emergency registration for emergency service registration (whichindicates to the CN that the registration request is for emergency). The UE 102 can also include the priority event ID, the PMS user ID, and a PMS indicator (which indicates to the network that the registration request is for the PMS with the priority event ID).

[0085] Alternatively, if the UE 102 set 709 the establishmentcause to a dedicated value such as Priority MessagingService, the UE 120 can set the registration type set to emergency registration for emergency service registration, as above, but include a PMS support indicator in a Preferred Network Behavior IE (which indicates to the network that the UE 102 supports PMS capability), along with the PMS user ID and the priority event ID.

[0086] When the UE 102 performs emergency registration, the UE 102 can include the SUPI when available, and the IMEI when no SUPI value is available.

[0087] The AMF 164 then triggers 720 an authentication procedure. In some implementations, the AMF 164 / the UDM 168 determine, based on the priority event ID, the preconfigured address of the PMS authentication, authorization and accounting (PMS-AAA) server 182. Alternatively, the UE 102 provides 710 the address of the PMS-AAA server 182 as a part of the registration request information. When the UE 102 provides 710 the IMEI, the AMF 164 can apply the local policy for PMS. When the UE 102 does not provide 710 the IMSI or the IMEI, the AMF 164 can request the IMEI from the UE 102 and then proceed with the local policy for PMS. The AMF 164 can use 720 the SUPI or the IMEI in the authentication request.

[0088] According to one implementation, the AMF 164 uses the PMS indicator to indicate, to the UDM 168, that the AMF 164 is requesting UE subscription service data for the PMS, based on the SUPI. The AMF 164 can also indicate, to the UDM 168, the SUPI / IMEI and the priority event ID for authentication. When the UE 102 provides a SUPI, the UDM 168 can perform an authentication procedure based on the SUPI. When the UE 102 provides an IMEI or a PMS user ID, the UDM 168 can trigger 730 an authentication procedure with the PMS-AAA server 182.

[0089] According to another implementation, based on the IMEI, PMS user ID, and the priority event ID, the AMF 164 sends an authentication request to the PMS-AAA server 182 for authentication and authorization for the PMS with priority event ID.

[0090] With continued reference to Fig. 7, the PMS-AAA server 182 can send 750 the authentication result to the AMF 164 directly or via the UDM 168.

[0091] The AMF 164 determines 760 to enable PMS for the UE 102, which accessed the network using satellite access. The AMF 164 can determine to enable PMS based on the authentication response message received 750 from an authorized third party, the local policy, and UE subscription data that includes a data network name (DNN) or a combination of DNN and Single Network Slice Selection Assistance (S-NSSA1 (S-NSSA1) with an indication for PMS support.

[0092] If the registration procedure is successful, and if the AMF 164 supports PMS, the AMF 164 sends 712, to the UE 102, a Registration Accept message with a PMS support indicator (which can be included in a 5GS network feature support IE for example). The PMS support indicator notifies the UE 102 that the network supports PMS are supported. More specifically, the PMS support indicates that the UE 102 is allowed to request a PDU session for PMS via NIDD. Based on the PMS support indicator, the UE 102 enables PMS for the requested priority event ID and initiates 780 PDU session establishment.

[0093] When the registration is not successful, the AMF 164 includes an appropriate cause value in the Registration Reject message. The cause value can indicate, for example, that PMS is not available, that the PMS event is not authenticated, that the UE 102 is not authenticated for PMS, that PMS for the specified priority event requires subscription, etc.

[0094] After the registration procedure, the UE 102 implemented as an loT device can be in the Connection Management (CM)-registered state after successful registration or in a limited connectivity state after unsuccessful registration.

[0095] Still referring to Fig. 7, the UE 102 performs 780 the PDU session establishment request procedure. In the PDU Session Establishment Request message, the UE 102 can set the request type for the 5GSM message to a dedicated PMS value. The UE 102 also includes, in the PDU Session Establishment Request message, the PMS or priority event ID, the S-NSSAI, and the DNN for PMS.

[0096] The UE 102 sends 790 the non-IP (unstructured) data for PMS, over NIDD and in the established PDU session, to the PMS-AAA 182 (via the appropriate AF). The UE 102 and the PMS-AAA server 182 can use, as user identity when the UE 102 is authenticated, 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 unauthenticated, the UE 102 and the PMS-AAA server 182 can use the IMEI or the PMS user identifier / IMEI. In this sense, the NIDD delivery 790 can extend the NEF Anchored Mobile Originated Data Transport (MO) based on TS 23.502 for the NEF Anchored Mobile Originated Data Transport procedure, and the NEF Anchored Mobile Terminated Data Transport (MT) based on TS 23.502, for the procedure using which an AF sends unstructured data to a user identified via an External Identifier or an MSISDN.

[0097] Next, Fig. 8 illustrates an example method 800, which a UE such as the UE 102 can implement to perform network selection and network registration for transmitting a priority nonIMS message using satellite access.

[0098] At block 801, the UE receives a request from an upper layer, similar to the event 701 discussed above. At block 805, determines to trigger PMS. Next, at block 806, the UE 102 performs a network selection procedure for PMS and selects a network that provides PMS service over a 3GPP system with satellite access.

[0099] At block 810, the UE uses satellite access to perform a registration procedure for the network the UE selected for PMS. As discussed above with reference to event 710, the UE can provide, to the network a unique device identifier such as an IMSI, a SUPI, or an IMEI. The UE can request registration with the network operator, including the mobile network operator and the satellite network operator, and optionally with the authorized third party.

[0100] At block 811, the UE determines when the UE received a registration accept message that confirms successful registration for PMS. If yes, the flow proceeds to block 890. Otherwise, the flow proceeds to block 813, where the UE checks the cause value in the registration reject message, depending on the cause value (e.g., PMS congestion), determines whether toimmediately attempt selecting another network at block 806 or apply a back-off / wait timer at block 815.

[0101] At block 890, the UE sends a priority non-IMS message, which can include one or more of the following: the GPS coordinates, a timestamp, a priority type indicator, sensor data, or a pre-set text message. The priority type indicator can be an operator-defined priority type, a third-party defined priority type, an emergency type indicator defined by the 3GPP, etc.

[0102] Finally, at block 892, the UE can receive a response to the priority non-IMS message the UE transmitted at block 890, in the form of a response priority non-IMS message. The response can arrive from the recipient of the priority non-IMS data (e.g., the PMS server 182) via the 3GPP network with satellite access, and can confirm the delivery of the priority non-IMS message. In some cases, the response includes additional information from the recipient.

[0103] Fig. 9 illustrates an example method 900 in a UE, such as the UE 102, for transmitting a priority non-IMS message. The UE can be an loT device, and the cell via which the UE registers with the network can be a satellite NB-IoT cell for example.

[0104] At block 902, the UE receives, in a cell of a RAN, an indication that priority non-IMS messaging is supported (see, e.g., event 702 and block 806). At block 910, the UE performs, with a core network, a registration procedure and provides, to the CN, an indication that the UE has a priority non-IMS message to send (see, e.g., event 710, block 810). Next, at block 990, the UE transmits the priority to the non-IMS message to the CN (see, e.g., event 790 and block 890).

[0105] Fig. 10 illustrates an example method 1000 a CN for processing a priority non-IMS message from a UE. The CN can be for example the CN 110, and the UE can be the UE 102 of Fig. 1. The CN can communicate with the UE via a NTN RAT, e.g., via an satellite NB-IoT cell.

[0106] At block 1010, the CN receives, from the UE, a registration request including indication that the UE has a priority non-IMS message to send (see, e.g., event 710, block 810). At block 1060, the CN determines whether the CN supports priority non-IMS messaging (see, e.g., event 760). At block 1012, the CN transmits, to the UE, an indication of whether the UE is allowed to transmit the non-IMS message to the CN (see, e.g., event 712 and blocks 811, 813 of Fig. 8).

[0107]

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

[0109] Example 1. A method in a user equipment (UE), the method comprising: receiving, in a cell or a radio access network (RAN), an indication that priority non-Internet-Protocol- Multimedia-Subsystem (non-IMS) messaging is supported; performing, with a core network (CN) via the cell, a registration procedure, including providing an indication that the UE has a priority non-IMS message to send; transmitting, to the CN, the priority non-IMS message.

[0110] Example 2. The method of example 1 , wherein the performing of the registration procedure includes: providing, to the CN, a priority event identifier (ID) to identify a priority event with which the priority non-IMS message is associated.

[0111] Example 3. The method of example 2, further comprising: receiving, from an upper layer of a protocol stack, a request for a priority service, the request including the priority event ID; wherein the performing of the registration procedure is in response to determining that the priority event ID qualifies for the priority non-IMS messaging.

[0112] Example 4. The method of example 3, further comprising: storing, in a memory of the UE, a set of priority event IDs for which the UE initiates registration for the priority non-IMS messaging.

[0113] Example 5. The method of example 3, wherein the set of priority event IDs includes: a first list of priority event IDs for non-emergency events for which the UE is configured for priority non-IMS messaging with a third party; and a second list of priority event IDs for emergency events for which the UE is configured for priority non-IMS messaging according to an operator policy of the CN.

[0114] Example 6. The method of any of examples 2-5, wherein the receiving of the indication that the priority non-IMS message is supported includes: receiving a list of priority event IDs for which the cell supports the priority non-IMS messaging; and determining that list of priority event IDs includes the priority event ID with which the priority non-IMS message is associated.

[0115] Example 7. The method of any of examples 2-6, wherein the priority event ID is provided to the CN in a registration request message.

[0116] Example 8. The method of example 7, further comprising: receiving, from the CN and in response to the registration request message, a registration accept message including the priority event ID to indicate that the UE is allowed to establish a Protocol Data Unit (PDU) session associated with the priority event ID, for transmitting the priority non-IMS message using Non-lP Data Delivery (N1DD).

[0117] Example 9. The method of any of examples 1-6, wherein the performing of the registration procedure includes: transmitting, to the CN, a registration request message including (i) an identifier of the UE for the priority non-IMS messaging and (ii) a priority event ID to identify a priority event with which the priority non-IMS message is associated.

[0118] Example 10. The method of example 9, further comprising: transmitting, to the RAN and prior to sending the registration request message, a setup request to request a setup of a radio a connection between the UE and the RAN, including: in response to determining that the priority event ID corresponds to an emergency event recognized by the CN, setting an establishment cause in the request to a value indicating emergency; the method further comprising: setting a registration type in the registration request message to a value dedicated to requesting priority messaging registration with a network configured to receive the priority non- IMS message.

[0119] Example 11. The method of example 9, further comprising: transmitting, to the RAN and prior to sending the registration request message, a setup request to request a setup of a radio connection between the UE and the RAN, including: setting an establishment cause in the request to a value indicating a priority messaging service to request a radio bearer other than an emergency radio bearer; the method further comprising: setting a registration type in the registration request message to a value indicating emergency registration for the priority messaging service with a network configured to receive the priority non-IMS message.

[0120] Example 12. The method of example 1 1 , further comprising: including, in the registration request message, an indicator of the priority non-IMS messaging to identify the network configured to receive the priority non-IMS message.

[0121] Example 13. The method of example 11, further comprising: including, in a Preferred Network Behavior Information Element (IE) included in the registration request message, an indicator of support of the priority non-IMS messaging, the Preferred Network Behavior IE referencing the network configured to receive the priority non-IMS message.

[0122] Example 14. The method of any of the preceding examples, wherein the performing of the registration procedure includes: requesting registration, via the CN, with a third party to which the UE is configured to address the priority non-IMS message.

[0123] Example 15. The method of any of examples 1-7 or 9-14, further comprising: subsequently to the registration procedure, establishing a PDU session including indicating, in a request to establish the PDU session, that the PDU session is for sending the priority non-IMS message.

[0124] Example 16. The method of any of the preceding examples, wherein the priority non- IMS message includes a priority type indicator indicating at least one of: (i) a priority type defined by an operator of the CN; (ii) a priority type defined by a third-party, or (iii) an emergency type defined by a communication standard according to which the UE communicates with the CN.

[0125] Example 17. The method of example 16, wherein the priority non-IMS data further includes one or more of: (i) positioning data for the UE, (ii) a timestamp, (iii) a priority type indicator, (iv) a pre-defined text message, or (v) sensor data collected at the UE.

[0126] Example 18. The method of any of the preceding examples, wherein: the cell is an Internet-of-Things (loT) non-terrestrial network (NTN) cell.

[0127] Example 19. The method of example 18, wherein the cell is a satellite cell.

[0128] Example 20. The method of any of the preceding examples, wherein: the indication that the priority non-IMS messaging is supported is received in a broadcast message.

[0129] Example 21 . The method of example 20, wherein the broadcast message includes a list of priority event IDs for which the UE is configured for the priority non-IMS messaging.

[0130] Example 22. The method of any of the preceding examples, wherein the UE lacks IMS capability and / or voice capability.

[0131] Example 23. The method of any of the preceding examples, wherein the UE is a resource-constrained loT device.

[0132] Example 24. A user equipment (UE) comprising: a transceiver; at least one sensor configured to determine a position of the UE; and processing hardware; the UE configured to implement a method of any of the preceding examples.

[0133] Example 25. A method in one or more network functions (NFs) of a core network (CN) of a cellular communication system, the method comprising: receiving, from a user equipment (UE), a registration request including an indication that the UE has a priority non- Internet-Protocol-Multimedia-Subsystem (non-IMS) message to transmit; determine whether the CN supports priority non-IMS messaging; and transmit, to the UE, a response to the registration request, the response including an indication of whether the UE is allowed to transmit the non- IMS message to the CN.

[0134] Example 26. The method of example 25, wherein: the registration request includes a priority event identifier (ID) to identify a priority event with which the priority non-IMS message is associated.

[0135] Example 27. The method of example 26, further comprising: determining, based on the priority event ID, an address of a third-party priority messaging server configured to receive the priority non-IMS message; and performing, with the third-party priority messaging server, an authentication procedure for the UE.

[0136] Example 28. The method of example 27, further comprising: when the registration request includes a Subscription Permanent Identifier (SUPI), retrieving UE subscription service data for the priority non-IMS messaging, based on the SUPI; and including, in an authentication request, the SUPI.

[0137] Example 29. The method of example 27, further comprising: when the registration request includes an International Mobile Equipment Identity (IMEI) and a priority messaging user ID: including, in an authentication request, the priority event ID.

[0138] Example 30. The method of example 27, further comprising: determining whether the UE is allowed to transmit the non-IMS message to the CN based on an authentication response received in the authentication procedure.

[0139] Example 31. The method of example 30, wherein the determining whether the UE is allowed to transmit the non-IMS message to the CN is further based on a local policy stored in the CN.

[0140] Example 32. The method of example 30 or 31, wherein the determining whether the UE is allowed to transmit the non-IMS message to the CN is further based on whether a data network name (DNN) and Single Network Slice Selection Assistance (S-NSSAI) information in a subscription data for the UE indicate support of the priority non-IMS messaging.

[0141] Example 33. The method of any of examples 25-32, wherein the registration request includes the priority event ID and an indication that the priority non-IMS messaging is allowed.

[0142] Example 34. The method of any of examples 25-32, wherein a response to the registration request includes a cause value indicating that the priority non-IMS messaging is not allowed.

[0143] Example 35. A core network (CN) of a cellular communication network, the CN comprising processing hardware and configured to implement a method of any of examples 25- 34.

[0144] The following description may be applied to the description above.

[0145] 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 someimplementations, “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.

[0146] A user device in which the techniques of this disclosure 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 internet-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.

[0147] 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.

[0148] 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.”

[0149] 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: receiving, in a cell or a radio access network (RAN), an indication that priority non- Internet-Protocol-Multimedia-Subsystem (non-IMS ) messaging is supported; performing, with a core network (CN) via the cell, a registration procedure, including providing an indication that the UE has a priority non-IMS message to send; and transmitting, to the CN, the priority non-IMS message.

2. The method of claim 1, wherein the performing of the registration procedure includes: providing, to the CN, a priority event identifier (ID) to identify a priority event with which the priority non-IMS message is associated.

3. The method of claim 2, further comprising: receiving, from an upper layer of a protocol stack, a request for a priority service, the request including the priority event ID; wherein the performing of the registration procedure is in response to determining that the priority event ID qualifies for the priority non-IMS messaging.

4. The method of claim 2 or 3, wherein the receiving of the indication that the priority non-IMS message is supported includes: receiving a list of priority event IDs for which the cell supports the priority non-IMS messaging; anddetermining that list of priority event IDs includes the priority event ID with which the priority non-IMS message is associated.

5. The method of claim 1, wherein the performing of the registration procedure includes: transmitting, to the CN, a registration request message including (i) an identifier of the UE for the priority non-IMS messaging and (ii) a priority event ID to identify a priority event with which the priority non-IMS message is associated.

6. The method of claim 5, further comprising: transmitting, to the RAN and prior to sending the registration request message, a setup request to request a setup of a radio a connection between the UE and the RAN, including: in response to determining that the priority event ID corresponds to an emergency event recognized by the CN, setting an establishment cause in the request to a value indicating emergency; the method further comprising: setting a registration type in the registration request message to a value dedicated to requesting priority messaging registration with a network configured to receive the priority non- IMS message.

7. The method of claim 5, further comprising: transmitting, to the RAN and prior to sending the registration request message, a setup request to request a setup of a radio a connection between the UE and the RAN, including: setting an establishment cause in the request to a value indicating a priority messaging service to request a radio bearer other than an emergency radio bearer; the method further comprising:setting a registration type in the registration request message to a value indicating emergency registration for the priority messaging service with a network configured to receive the priority non-IMS message.

8. The method of any of the preceding claims, wherein the performing of the registration procedure includes: requesting registration, via the CN, with a third party to which the UE is configured to address the priority non-IMS message.

9. The method of any of the preceding claims, wherein the priority non-IMS message includes a priority type indicator indicating at least one of:(i) a priority type defined by an operator of the CN;(ii) a priority type defined by a third-party, or(iii) an emergency type defined by a communication standard according to which the UE communicates with the CN.

10. A user equipment (UE) comprising: a transceiver; at least one sensor configured to determine a position of the UE; and processing hardware; the UE configured to implement a method of any of the preceding claims.

11. A method in one or more network functions (NFs) of a core network (CN) of a cellular communication system, the method comprising:receiving, from a user equipment (UE), a registration request including an indication that the UE has a priority non-Intcmct-Protocol-Multimcdia-Subsystcm (non-IMS) message to transmit; determining whether the CN supports priority non-IMS messaging; and transmitting, to the UE, a response to the registration request, the response including an indication of whether the UE is allowed to transmit the non-IMS message to the CN.

12. The method of claim 11, wherein: the registration request includes a priority event identifier (ID) to identify a priority event with which the priority non-IMS message is associated.

13. The method of claim 12, further comprising: determining, based on the priority event ID, an address of a third-party priority messaging server configured to receive the priority non-IMS message; and performing, with the third-party priority messaging server, an authentication procedure for the UE.

14. The method of claim 13, further comprising: determining whether the UE is allowed to transmit the non-IMS message to the CN based on an authentication response received in the authentication procedure.

15. A core network (CN) of a cellular communication network, the CN comprising processing hardware and configured to implement a method of any of claims 11-14.

Images