Enabling an emergency messaging service

Abstract

Techniques for enabling an emergency messaging service are described herein. A UE receives system information via a cell. The UE performs an attach procedure for a messaging service with a core network (CN) via the cell, and communicates one or more emergency messages with the CN.

Description

ENABLING AN EMERGENCY MESSAGING SERVICECROSS-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 / 620,539 entitled “Enabling an Emergency Messaging Service,” filed on January 12, 2024. The entire content of the provisional application is hereby expressly incorporated herein by referenceFIELD OF THE DISCLOSURE

[0002] This disclosure relates generally to wireless communication systems, and particularly to communicating emergency messages.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] Generally speaking, a base station operating a cellular radio access network (RAN) communicates with a user equipment (UE) using a certain radio access technology (RAT) and multiple layers of a protocol stack. For example, the physical layer (PHY) of a RAT provides transport channels to the Medium Access Control (MAC) sublayer, which in turn provides logical channels to the Radio Link Control (RLC) sublayer, and the RLC sublayer in turn provides data transfer services to the Packet Data Convergence Protocol (PDCP) sublayer. The Radio Resource Control (RRC) sublayer is disposed above the PDCP sublayer.

[0005] The RRC sublayer specifies the RRC IDLE state, in which a UE does not have an active radio connection with a base station and does not store a UE access stratum (AS) context; the RRC CONNECTED state, in which the UE has an active radio connection with the base station; and the RRC INACTIVE to allow a UE to more quickly transition back to the RRC_CONNECTED state due to Radio Access Network (RAN)-level base station coordination and RAN-paging procedures. Depending on different implementations or scenarios, the basestation can configure Small Data Transmission (SDT) for the UE operating in the RRC INACTIVE to transmit one or more small packets.

[0006] 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-IoT) or the enhanced Machine Type Communication (eMTC) scenarios. In an NTN, an RF transceiver is mounted on a satellite, an unmanned aircraft system (UAS), also called a drone, balloon, plane, or another suitable apparatus. For simplicity, the discussion below refers to all such apparatuses 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 UEs, and inter-satellite links (ISL) when satellites form constellations.

[0007] 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 (MEO) 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.

[0008] A GSO satellite is stationary relative to the Earth’s surface and is able to communicate continuously with the same one or several sat-gateways within a satellite targeted coverage area (e.g., a region or even a continent). A non-GSO satellite changes its location over time relative to the Earth's surface, and, therefore, at different times, is able to communicate only temporarily 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.

[0009] 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, asatellite 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.

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

[0011] Generally speaking, 3GPP specifications support Emergency Calls with voice and other media, but this does not include short message services (SMS). Thus, UEs supporting LTE and / or NR cannot perform an emergency attach for emergency messaging services using SMS.

[0012] Furthermore, 3GPP has specified that support for emergency bearer services is not available when the UE is using NB-IoT, i.e. the MME shall not indicate support for emergency bearer services using the Emergency Service Support indicator in the Attach and TAU procedures to a UE that accesses the network using a RAT Type equal to NB-IoT, and an NB- loT cell shall not indicate support for emergency services in any broadcast information in AS. In some implementations, the satellite NB-IoT is supported by a smartphone. Thus, when the UE is out of coverage of a terrestrial network, the UE can use the satellite NB-IoT for communications. Because the satellite NB-IoT generally follows the functionality of the terrestrial network NB- loT, satellite NB-IoT does not support emergency services either. Thus, the UE cannot perform emergency messaging services with the satellite NB-IoT. If the UE is only in coverage of the satellite NB-IoT and is out of coverage of any terrestrial network, the UE cannot perform an emergency attach for an emergency messaging service and transmit an emergency message via the satellite NB-IoT RAT.SUMMARY

[0013] One example embodiment of these techniques is a method in a UE for enabling an emergency messaging service. The method includes receiving, at the UE, system information via a cell, performing, by the UE, an attach procedure for a messaging service with a core network (CN) via the cell, and communicating, by the UE, one or more emergency messages with the CN.

[0014] Another embodiment of these techniques is a UE comprising processing hardware configured to implement the method above.

[0015] Another example embodiment of these techniques is a method in a core network (CN) for performing an attach procedure for a messaging service. The method includes performing, by the CN, an attach procedure for a messaging service with a UE via a base station, and communicating, by the CN, one or more emergency messages with the UE via the base station.

[0016] Another embodiment of these techniques is a core network comprising processing hardware configured to implement the method above.

[0017] Yet another example embodiment of these techniques is a method in a base station for supporting an emergency messaging service. The method includes broadcasting, by the base station, system information via a satellite. The method also includes receiving, by the base station via the satellite, a radio connection request message from a UE indicating an emergency, and transmitting, by the base station to a core network (CN), a message indicating the emergency.

[0018] Another embodiment of these techniques is a base station comprising processing hardware configured to implement the method above.BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate one or more embodiments and, together with the detailed description, explain these embodiments.

[0020] Fig. 1 A is a block diagram of an example wireless communication system in which a user device and a base station perform methods according to various embodiments.

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

[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. 3A is a block diagram of an example NTN node with transparent payload implementation.

[0025] Fig. 3B 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.

[0026] Figs. 4A-4C are messaging diagrams of example attach procedures for messaging services.

[0027] Figs. 4A-4C are messaging diagrams of example attach procedures for messaging services.

[0028] Figs. 5A-5E are messaging diagrams of example procedures for communicating text messages for emergency after performing the emergency attach and connection release procedures described in Figs. 4A-4C.

[0029] Figs. 6A-6I are flow diagrams of example methods for performing attach procedures for messaging services, which can be implemented in the UE of Fig. 1.

[0030] Fig. 7 is a flow diagram of an example method for supporting an emergency messaging service, which can be implemented in the RAN or base station of Fig. 1.

[0031] Figs. 8A-8B are flow diagrams of example methods for performing attach procedures for messaging services, which can be implemented in the core network of Fig. 1.

[0032] Fig. 9 is a flow diagram of an example method for supporting emergency messaging services or an IMS emergency call, which can be implemented in the RAN or base station of Fig. 1.

[0033] Fig. 10 is a flow diagram of an example method for indicating support of emergency message services and / or support of IMS emergency call, which can be implemented in the core network of Fig. 1.

[0034] Figs. 11-13 are flow diagrams of example methods for performing attach procedures for messaging services, which can be implemented in the UE of Fig. 1.

[0035] Fig. 14 is a flow diagram of an example method for supporting an emergency messaging service, which can be implemented in the RAN or base station of Fig. 1.DETAILED DESCRIPTION OF THE DRAWINGS

[0036] As discussed in more detail below, a user equipment (UE) and / or a network node of a radio access network (RAN) can use the techniques of this disclosure for managing early data communication and transitioning a UE between states of a protocol for controlling radio resources between the UE and the RAN.

[0037] Referring first to Fig. 1A, an example wireless communication system 100 includes a UE 102, 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.

[0038] 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 eNB, the cell 124 is an evolved universal terrestrial radio access (E-UTRA) cell or a NarrowBand Internet of Things (NB-IoT) 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 eNB, the cell 126 is an E-UTRA cell or a NB-IoT cell. The cells 124 and 126 can be in the same Radio Access Network Notification Areas (RNA) or different RNAs. The base station 104 operates the cell 124 via a satellite (e.g., satellite 304 in Fig. 3) and operates the cell 126 via one or more antennas on the ground. 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”), E-UTRA or NB-IoT air interface to communicate with the base station 104 or 106. Each of thebase 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.

[0039] NB-IoT provides access to network services using physical layer optimized for very low power consumption (e.g. full carrier bandwidth is 180 kHz, subcarrier spacing can be 3.75 kHz or 15 kHz). Unlike NR and E-UTRA, a number of functions, such as inter-RAT mobility, handover, measurement reports, public warning functions, Guaranteed Bit Rate (GBR), carrier aggregation, multi-radio dual connectivity, real-time services, interference avoidance for indevice coexistence, minimization of drive test (MDT), emergency call, Circuit Switched (CS) fallback, access barring, and RRC INACTIVE, are not supported for NB-IoT.

[0040] 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, security activation, 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) 162 and an Access and Mobility Management Function (AMF) 164, and / or Session Management Function (SMF) 166. Generally speaking, the UPF 162 is configured to transfer user-plane packets related to audio calls, video calls, Internet traffic, etc., the AMF 164 is configured to manage authentication, security activation, registration, paging, and other related functions, and the SMF 166 is configured to manage PDU sessions.

[0041] The CN 110 may connect to a short message service center (SMSC) 170 directly or via one or more other network nodes to provide short message services (SMS) via a control plane function or a user plane function. In some implementations, to support SMS via the control plane function, the MME 114 may connect to a SMS-Gateway Mobile Switching Center (SMS- GMSC) (not shown in Fig. 1) and the SMS-GMSC connects to the SMSC 170. In other implementations, the MME 114 may connect to the SMSC 170 directly, i.e., via an interface. In some implementations, to support SMS (i.e., IMS SMS) via the user plane function, the SGW 112 or PGW 116 connects to an IMS network (not shown in Fig. 1), the IMS network connectsto an Internet Protocol (IP) short message gateway (IP-SM-GW), and the IP-SM-GW connects to the SMSC 170. In some implementations, to support SMS via the control plane function, the AMF 164 may connect to a short message service function (SMSF) (not shown in Fig. 1) and the SMSF connects to the SMSC 170. In other implementations, to support SMS (i.e., IMS SMS) via the user plane function, the UPF 162 connects to an IMS network (not shown in Fig. 1), the IMS network connects to the SMSF, and the SMSF connects to the SMSC 170. The IMS network may include one or more Call Session Control Function (CSCF) nodes such as Interrogating CSCF, Proxy CSCF, and / or Serving CSCF.

[0042] The CN 110 may connect to a Home Subscriber Server (HSS) or a Unified Data Management (UDM) 172 directly or via one or more other network nodes. In some implementations, the MME 1 14 connects to the HSS 172 via an interface. In other implementations, the AMF 164 connects to the UDM 172 via an interface. In yet other implementations, the SMF 166 connects to the UDM 172 via an interface. The HSS / UDM 172 may connect to the SMSC 170 via an interface.

[0043] As illustrated in Fig. 1A, the base station 104 supports a cell 124, and the base station 106 supports a cell 126. Note that cell 124 has a shape corresponding to the footprint of the satellite beams, which unlike cell 126, can project on different areas at different times. 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 can 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.

[0044] As discussed in detail below, the UE 102 and / or the RAN 105 may utilize the techniques of this disclosure when the radio connection between the UE 102 and the RAN 105 is suspended, e.g., when the UE 102 operates in an inactive or idle state of the protocol for controlling radio resources between the UE 102 and the RAN 105. For clarity, the examples below refer to the RRC INACTIVE or RRC IDLE state of the RRC protocol.

[0045] 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 (CRM) storing instructions that the one or more general -purpose processors execute.Additionally or alternatively, the processing hardware 130 can include special-purposeprocessing units. According to an embodiment illustrated in Fig. 1 A, the processing hardware 130 includes a processor 132 to process data that the base station 104 will transmit in the downlink direction, or data received by the base station 104 in the uplink direction. The processing hardware 130 also includes a transceiver 134 configured to transmit data in the downlink direction and to receive data in the uplink direction. The processing hardware 130 further includes CRM 136 storing executable codes for the processor 132 to perform methods according to embodiments described in this section. The base station 106 can include generally similar components. In particular, components 140, 142, 144, and 146 of the base station 106 can be similar to the components 130, 132, 134, and 136 respectively.

[0046] 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 transceiver 156 configured to transmit data in the downlink direction and to receive data in the uplink direction.

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

[0048] 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 special-purpose 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.

[0049] 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 172 operates as an lAB-donor. In some embodiments, the RAN 105 supports Non-Terrestrial Network (NTN) functionality.

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

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

[0052] Fig. 2 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).

[0053] In the example stack 200, a physical (PHY) layer 202 provides transport channels to a MAC sublayer 204, which in turn provides logical channels to a RLC sublayer 206. The RLCsublayer 206 in turn provides RLC channels to a PDCP sublayer 208. The PDCP sublayer 208 in turn can provide data transfer services to a radio resource control (RRC) sublayer 210, an Internet Protocol (IP) layer and / or a Service Data Adaptation Protocol (SDAP) sublayer (not shown in Fig. 2). The PDCP sublayer 208 receives packets (e.g., from the RRC sublayer 210, the SDAP sublayer, or the IP layer, layered directly or indirectly over the PDCP layer 208) that can be referred to as service data units (SDUs), and output packets (e.g., to the RLC layer 206) 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”. In some implementations, the PHY layer 202, MAC sublayer 204, RLC sublayer 206, PDCP sublayer 208, RRC sublayer 210 are EUTRA layers or sublayers. In other implementations, the PHY layer 202, MAC sublayer 204, RLC sublayer 206, PDCP sublayer 208, RRC sublayer 210 are NR layers or sublayers.

[0054] The RRC sublayer 210 provide data transfer services to a Non- Access-Stratum (NAS) layer 212. The NAS layer 212 includes a mobility management (MM) sublayer and / or a session management (SM) sublayer. In some implementations, the MM sublayer is an EPS MM (EMM) sublayer. In other implementations, the MM sublayer is a 5G MM (5GMM) sublayer. In some implementations, the SM sublayer is an EPS SM (ESM) sublayer. In other implementations, the SM sublayer is a 5G SM (5GSM) sublayer.

[0055] On a control plane, the PDCP sublayer 208 can provide signaling radio bearers (SRBs) to the RRC sublayer 210 to exchange RRC messages or NAS messages (e g., MM messages and / or SM messages), for example. On a user plane, the PDCP sublayer 208 can provide Data Radio Bearers (DRBs) to support user plane data exchange. User plane data exchanged on the PDCP sublayer 208 can be SDAP PDUs, Internet Protocol (IP) packets or Ethernet packets.

[0056] Fig. 3A illustrates a certain type of NTN deployment referred to as transparent payload architecture, which involves a satellite gateway 302 and a “transparent” satellite 304 for extending the range of the Uu interface. In one implementation, the satellite 304 implements a frequency conversion and a Radio Frequency (RF) amplifier in both the uplink and downlink directions. With that being said, the satellite function is similar to that of an analogue RF repeater. As a result, the satellite 306 repeats the Uu radio interface from the feeder link (between the NTN gateway and the satellite) to the service link (between the satellite and theUE) 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 302 supports all necessary functions to forward the signal of the Uu interface. The NTN gateway 302 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. Fig. 3B illustrates the case where two different satellites (304 and 306) are connected to the same base station 104 via the same NTN gateway 302, and these two satellites (304 and 306) are covering the Earth surface using two different Physical Cell IDs (PCIs).

[0057] Next, several example scenarios that involve several components of Figs. 1-3 are discussed next with reference to Figs. 4A-5D. To simplify the following description, all the messages communicated between the UE 102 and the base station 104 and / or the CN 110 are via the satellite 304. The satellite 304 may provide one or more cells. The UE 102 and the base station 104 / satellite 304 can communicate with each other via the NB-IoT radio access technology (RAT), satellite NB-IoT RAT, E-UTRA RAT, satellite E-UTRA RAT, NR RAT, satellite NR RAT, 6G RAT, or satellite 6G RAT. The MME 114 can be replaced by the AMF 164, the SMF 166 or the CN 110. The HSS 172 can be replaced by the UDM 172. The description of Figs. 4A-5D can apply to the terrestrial network scenarios, e.g., the base station 104 in Figs. 4A-5D can be replaced by the base station 106. In the following description, the SGW 112 and the PGW 116 can be replaced by the UPF 162.

[0058] Referring first to Fig. 4A, an example scenario 400A in which the UE 102 performs an emergency attach procedure for an emergency messaging service. Initially, the base station 104 broadcasts 402 a master information block and 404 system information for NB-IoT. The UE 102 in an idle state (e.g., RRC IDLE) selects the satellite cell and receives 402 the MIB and 404 the system information. In some implementations, the master information block is a Master InformationBlock-NB, and the system information includes a SystemlnformationBlockTypel-NB, SystemInformationBlockType2-NB, and / or SystemInformationBlockType31-NB for the NB-IoT RAT. In other implementations, the master information block is a Master InformationB lock, and the system information includes aSystemlnformationBlockType 1 , SystemInformationBlockType2, and / or SystemInformationBlockType31 for the E-UTRA RAT. In yet other implementations, the master information block is &MIB, and the system information includes a SIB1, SIB2, and / or SIB 19 for the NR RAT.

[0059] After receiving the master information block 402 and the system information 404, the UE 102 initiates 406 an emergency attach procedure for an emergency messaging service. In some implementations, the UE 102, the base station 104 and / or the MME 114 do not support other services (e.g., voice services and / or video services), e.g., with a specific RAT (e.g., NB-loT RAT, satellite E-UTRA RAT or satellite NR RAT). In some implementations, the master information block includes an indicator indicating that an / the emergency messaging service is supported. In such cases, the UE 102 determines to initiate the emergency attach procedure in response to the indication. If the master information block does not indicate that the indication, the UE 102 does not initiate an emergency attach procedure for an emergency messaging service. In other implementations, the system information includes an indicator indicating that an / the emergency messaging service is supported. In such cases, the UE 102 determines to initiate the emergency attach procedure in response to the indication. If the system information does not indicate that the indication, the UE 102 does not initiate an emergency attach procedure. In some implementations, the UE 102 is preconfigured with a first PLMN ID supporting an emergency attach procedure for an / the emergency messaging service. The UE 102 determines to initiate the emergency attach procedure for the emergency messaging service because the system information (e.g., a system information block described above) includes the first PLMN ID (i.e., the satellite cell belongs to a first PLMN identified by the first PLMN ID). If the system information does not include the first PLMN ID, the UE 102 does not perform an emergency attach procedure for an emergency messaging service via the satellite cell.

[0060] In response to initiating the emergency attach procedure, the UE 102 initiates a RRC connection establishment procedure. In the RRC connection establishment procedure, the UE 102 transmits a RRC connection request message to the base station 104, receives a RRC connection setup message from the base station in response to the RRC connection request message, and transmits a RRC connection setup complete message to the base station 104 in response to the RRC connection setup message. The UE 102 transitions to a connected state(e.g., RRC CONNECTED state) in response to receiving the RRC connection setup message. In some implementations, the base station 104 configures a RRC connection (e.g., a SRB such as SRB1 or SRB Ibis) in the RRC connection setup message and the UE 102 transmits the RRC connection setup complete message via the SRB to the base station 104. In some implementations, the UE 102 includes a Global Navigation Satellite System (GNSS) validity duration in the RRC connection setup complete message. The GNSS validity duration indicates the remaining GNSS validity duration in the UE 102. In some implementations, the UE 102 sets an establishment cause to “emergency” or “emergency messaging” and includes the establishment cause in the RRC connection request message. Based on the establishment cause, the base station 104 can prioritize radio resources in a higher priority than other UEs not requesting to establish an RRC connection (e.g., the SRB) for an / the emergency messaging service.

[0061] In some implementations, the RRC connection request message, the RRC connection setup message and the RRC connection setup complete message for the NB-IoT RAT is an RRCConnectionRequest-NB message, an RRCConnectionSetup-NB message, and an RRCConnectionSetupComplete-NB message, respectively. In some implementations, the RRC connection request message, the RRC connection setup message and the RRC connection setup complete message for the E-UTRA RAT is an RRCConnectionRequest message, an RRCConnectionSetup message, and an RRCConnectionSetupComplete message, respectively. In yet implementations, the RRC connection request message, the RRC connection setup message and the RRC connection setup complete message for the NR RAT is an RRCSetupRequest message, an RRCSetup message, and an RRCSetupComplete message, respectively.

[0062] After establishing the RRC connection through the RRC connection establishment procedure 408, the UE 102 transmits 410 an Attach Request message to the MME 114 via the base station 104. The UE 102 includes one or more indications in Attach Request message to indicate that the UE requests emergency attach for an emergency messaging service. In some implementations, the indication(s) includes an attach type and / or a SMS only indication. The SMS only indication indicates that SMS is used for an / the emergency messaging service. For example, the indication(s) include an EPS attach type and / or an additional update type. In some implementations, the UE 102 sets the EPS attach type to a value indicating EPS emergencyattach and / or sets the additional update type to a value indicating SMS only. In other implementations, the UE 102 sets the EPS attach type to a value indicating“EPS emergency attach for an emergency messaging service. In other implementations, the indication(s) includes an attach type that indicates emergency SMS or emergency SMS only. In some implementations, the UE 102 includes a UE identity / identifier (ID) in the Attach Request message. In some implementations, the UE ID is a Globally Unique Temporary Identifier (GUTI), an International Mobile Subscriber Identity (IMSI) or an International Mobile Equipment Identity (IMEI). In some scenarios or implementations, the UE 102 performs the emergency attach procedure using a Universal Subscriber Identity Module (USIM) and the UE ID is the IMSI or the GUTI. In one implementation, the USIM can be a physical card. In another implementation, the USIM is an embedded USIM profile stored in the UE 102 (e.g., a chip in the UE 102). In other scenarios or implementations, the UE 102 performs the emergency attach procedure without using a USIM and the UE ID is the IMEI. In the case of the GUTI or the IMSI, the MME 114 may transmit 412 an Identity Request message to the UE 102 via the base station 104 to request the UE 102 to transmit an IMEI. In some implementations, the MME 114 transmits 412 the Identity Request message because the MME 114 cannot use the GUTI or the IMSI to verify whether the UE 102 is valid. In response to the Identity Request message, the UE 102 transmits an Identity Response message including the IMEI. In some implementations, the UE 102 includes the Attach Request message in the RRC connection setup complete message. In some implementations, the GUTI can be a 4G GUTI or a 5G GUTI.

[0063] In some implementations, the UE 102 includes the SMS only indication in th Attach Request message to indicate the emergency attach for SMS only. That is, the UE 102 indicates to the MME 114 that SMS is used for the emergency messaging service (only). In such cases, the UE 102 may not establish a packet data network (PDN) connection with the MME 114. In some implementations, the UE 102 includes an ESM Dummy Message in the Attach Request message instead of a PDN Connectivity Request message in order not to establish a PDN connection. In response to receiving the ESM Dummy Message from the UE 102, the MME 114 includes an ESM Dummy Message in the Attach Accept message. In response to receiving the ESM Dummy Message in the Attach Accept message, the UE 102 includes an ESM Dummy Message in the Attach Complete message. In some implementations, the MME 114 includes a SMS only indication (e.g., in an additional update result) in the Attach Accept message to indicate to the UE102 that SMS is used for the emergency messaging service (only). In some implementations, the MME 114 does so in response to receiving the SMS only indication in the Attach Request message. In other implementations, the MME 114 does so regardless of whether the Attach Request message includes the SMS only indication. In some implementations, the MME 114 includes the SMS only result in an Additional update result IE and includes the IE in the Attach Accept message. In response to transmitting the SMS only indication or receiving the SMS only result, the UE 102 only uses SMS for / as the emergency messaging service.

[0064] After receiving the IMEI, the MME 114 may verify 416 the 1MEI is valid (i.e., the UE 102 is granted by the MME 114 for the emergency attach for the emergency messaging service). In some implementations, the MME 114 stores a plurality of IMEIs that are allowed for an emergency attach for the emergency messaging service. Because the IMEI of the UE 102 is one of the plurality of IMEIs, the MME 114 verifies that the UE 102 is allowed for the emergency attach for the emergency messaging service.

[0065] In some alternative implementations, the MME 114 transmits 418 an Authentication Information Request message including the IMEI to the HSS 172. The HSS 172 may verify 420 the IMEI is valid and transmit 422 an Authentication Information Answer message to the MME 114 to grant the emergency attach for the UE 102 or indicate that the UE 102 is a valid UE. In some implementations, the HSS 172 stores a plurality of IMEIs that are allowed for an emergency attach for the emergency messaging service. Because the HSS 172 finds the IMEI of the UE 102 in the plurality of IMEIs, the HSS 172 verifies that the UE 102 is allowed for the emergency attach for the emergency messaging service. In some alternative implementations, a network node other than the HSS 172 can be used to verify the UE 102 is valid, and the discussion above related to the HSS 172 can also apply to the network node. The network node transmits a message indicating that the UE 102 is valid to the MME 114.

[0066] After verifying the UE ID is valid or receiving the 422 the Authentication Information Answer message, the MME 114 transits 424 an Attach Accept message to the UE 102 via the base station 104. In response, the UE 102 transmits an Attach Complete message to the MME 114 via the base station 104. After (e.g., in response to) receiving the Attach Accept message or transmitting the Attach Complete message, the UE 102 has 428 emergency attached for the emergency messaging service (only). In some implementations, the MME 114 may include atemporary UE ID (e.g., a GUTI) for the UE 102 in the Attach Accept message. After successfully completing the emergency attach procedure, the UE 102 communicates SMS messages with the MME 114 as described in Figs. 5A and 5B.

[0067] The messages 412, 414, 424 and 426 are NAS PDUs exchanged between the UE 102 and the base station 104 via RRC messages. The base station 104 generates a DL RRC message (e.g., DLInformationTransfer message or DLInformationTransfer-NB message) including the Identity Request message (i.e., a NAS PDU) and transmits 412 the DL RRC message to the UE 102. The UE 102 retrieves the Identity Request message from the DL RRC message. The UE 102 generates a UL RRC message (e.g., ULInformationTransfer message or ULInformationTransfer- NB message) including the Identity Response message (i.e., a NAS PDU) and transmits the UL RRC message to the base station 104. The base station 104 retrieves the Identity Response message from the UL RRC message and transmits the Identity Response message to the MME 114. The base station 104 generates a DL RRC message for NB-IoT (e.g., DLInformationTransfer message or DLInformationTransfer-NB message) including the Attach Accept message (i.e., a NAS PDU) and transmits 424 the DL RRC message to the UE 102. The UE 102 retrieves the Attach Accept message from the DL RRC message. The UE 102 generates a UL RRC message for NB-IoT (e.g., ULInformationTransfer message or ULInformationTransfer- NB message) including the Attach Complete message (i.e., a NAS PDU) and transmits the UL RRC message to the base station 104. The base station 104 retrieves the Attach Complete message from the UL RRC message and transmits the Identity Response message to the MME 114.

[0068] At a later time, the base station 104 transmits 434 a RRC connection release message to the UE 102 to release the RRC connection. The UE 102 transitions to the idle state from the connected state in response to the RRC connection release message. In some implementations, the base station 104 receives 432 a UE Context Release Command message from the MME 114 and transmits the RRC connection release message in response to receiving the UE Context Release Command message. The base station 104 may transmit a UE Context Release Complete message to the MME 114 in response to the UE Context Release Command message. In other implementations, the base station 104 determines to transmit the RRC connection release message because of detecting no data activity for the UE 102. The base station 104 may transmit430 a UE Context Release Request message to the MME 114 in response to detecting no data activity for the UE 102. The MME 114 may transmit the UE Context Release Command message in response to receiving the UE Context Release Request message. In some implementations, the RRC connection release message is an RRCConnectionRelease message for the E-UTRA RAT. In other implementations, the RRC connection release message is an RRCRelease message for the NR RAT. In yet other implementations, the RRC connection release message is an RRCConnectionRelease-NB message for the NB-IoT RAT.

[0069] In some implementations, the Attach Request message, Attach Accept message and Attach Complete message can be replaced by a Tracking Area Update Request message, a Tracking Area Update Accept message and a Tracking Area Complete message, respectively. The discussion above related to the Attach Request message, Attach Accept message and Attach Complete message can apply to the Tracking Area Update Request message, Tracking Area Update Accept message and Tracking Area Update Complete message, respectively.

[0070] The events 406, 408, 410, 412, 414, 416, 418, 420, 422, 424, 426, and 428 are collectively referred to in Fig. 4A as an emergency attach procedure 490. The procedure 490 and the events 430, 432, and 434 are collectively referred to in Fig. 4A as an emergency attach and connection release procedure 492. In some implementations, the events 402 and 404 and the messages communicated between the UE 102 and the base station 104 in the procedure 492 are via a particular satellite cell or a beam of the satellite 304.

[0071] Referring next to Fig. 4B, an example scenario 400B is described which is similar to Fig. 4A. In the scenario, the MME 114 verifies 117 that the UE 102 is invalid. In response to the MME 114 verifying the UE 112 is invalid, the MME 114 transmits 425 an Attach Reject message to the UE 102. For example, the MME 114 verifies that the UE 102 is invalid because the MME 114 does not find the IMEI of the UE 102 in the plurality of IMEIs. In the case that the HSS 172 verifies the UE 102, the HSS 172 verifies 421 that the UE 102 is invalid and transmits 423 an Authentication Information Answer message indicating that the UE 102 is invalid to the MME 114. For example, the HSS 172 verifies that the UE 102 is invalid because the HSS 172 does not find the IMEI of the UE 102 in the plurality of IMEIs. In response to receiving the Authentication Information Answer message, the MME 114 transmits the Attach Reject message to the UE 102.

[0072] In some implementations, the MME 114 includes a cause code in the Attach Reject message. For example, the cause code (e.g., #5) indicates the IMEI is not accepted. In another example, the cause code (e.g., #3) indicates the UE is illegal. In yet another example, the cause code (e.g., #6) indicates that the Mobile Equipment (ME) is illegal. In yet another example, the cause code (e.g., #9) indicates the UE ID cannot be derived by the network. In some implementations, the MME 114 determines the cause code based on a result code in the Authentication Information Answer message. In other implementations, the MME 114 determines the cause code based on a pre-configured or pre-determined configuration.

[0073] When receiving the Attach Reject message, the UE 102 determines 429 that the emergency attach procedure fails. In the case that the cell is a satellite cell, the UE 102 may stop accessing the satellite cell and / or any other satellite cell in response to the Attach Reject message. In some implementations, the UE 102 may turn off its transceiver to stop accessing the satellite cell and / or any other satellite cell. In other implementations, the UE 102 may configure its transceiver to a low power consumption state to stop accessing the satellite cell and / or any other satellite cell. In some implementations, the UE 102 determines whether to stop accessing the satellite cell and / or any other satellite cell or configure its transceiver to a low power consumption state, based on a cause code in the Attach Reject message. For example, if the cause code is a first value, the UE 102 determines to stop accessing the satellite cell and / or any other satellite cell or configure its transceiver to a low power consumption state. Otherwise, if the cause code is a second value, the UE 102 may re-attempt to access the satellite cell and / or any other satellite cell in a later time.

[0074] Referring next to Fig. 4C, an example scenario 400C is described which is similar to Fig. 4A except that the UE 102 performs a normal attach procedure with the MME 114. After receiving the master information block and the system information, the UE 102 initiates 405 a normal attach procedure. In such cases, the UE 102 is equipped with a USIM and performs the normal attach procedure using the USIM. In some implementations, the messaging service is an emergency messaging service. In other implementations, the messaging service is a normal messaging service. In some implementations, the UE 102 initiates 405 the normal attach procedure for a messaging service because the UE 102 and / or the CN 110 does not support other services (e.g., voice services and / or video services) on the NB-IoT RAT. After establishing theRRC connection as a result of the RRC connection establishment procedure 408, the UE 102 transmits 411 an Attach Request message to the MME 114 via the base station 104. The UE 102 includes one or more indications in the Attach Request message to indicate that the UE requests normal attach. In some implementations, the indication(s) includes an attach type and / or a SMS only indication. The SMS only indication indicates that the UE 102 attaches only for a messaging service. For example, the indication(s) include an EPS attach type and / or an additional update type. In some implementations, the UE 102 sets the EPS attach type to a value indicating EPS attach instead of the EPS emergency attach. The EPS attach indicates to the MME 114 that the UE 102 is requesting for a normal attach (i.e., EPS attach). In some implementations, the UE 102 sets the additional update type to a value indicating SMS only. In some implementations, the UE 102 includes a UE ID in the Attach Request message and the UE ID is a GUTI or an IMSI. In the case of the GUTI, the MME 114 requests the UE 102 to transmit an IMSI and / or an IMEI in the Identity Request message, and the UE 102 transmits an Identity Response message including the IMSI and / or the IMEI in response to the Identity Request message. In the case of the IMSI, the MME 114 requests the UE 102 to transmit an IMEI in the Identity Request message, and the UE 102 transmits an Identity Response message including the IMEI in response to the Identity Request message.

[0075] After receiving the UE ID(s) (i.e., the GUTI, the IMSI and / or the IMEI), the MME 114 may verify 416 the UE ID(s) is / are valid (i.e., the UE 102 is granted by the MME 114 for the normal attach for the messaging service). In some implementations, the MME 114 stores a plurality of IMEIs, IMSIs and / or GUTIs that are allowed for a normal attach for the messaging service. Because the MME 114 finds the UE ID(s) of the UE 102 in the plurality of IMEIs, IMSIs and / or GUTIs, the MME 114 verifies that the UE 102 is allowed for the normal attach for the messaging service.

[0076] In some implementations, the MME 114 transmits 418 an Authentication Information Request message including the UE ID(s) to the HSS 172. The HSS 172 may verifies 420 the UE ID(s) is / are valid and transmit 422 an Authentication Information Answer message to the MME 114 to grant the normal attach for the UE 102 or indicate that the UE 102 is a valid UE. In some implementations, the HSS 172 stores a plurality of IMEIs, IMSIs and / or GUTIs that are allowed for a normal attach for the messaging service. Because the HSS 172 finds the UE ID(s) of theUE 102 in the plurality of IMEIs, IMSIs and / or GUTIs, the HSS 172 verifies that the UE 102 is allowed for the normal attach for the messaging service. In some alternative implementations, a network node (e.g., authentication center) other than the HSS 172 can be used to verify the UE 102 is valid, and the discussion above related to the HSS 172 can apply to the network node. The network node transmits a message indicating that the UE 102 is valid to the MME 114.

[0077] After verifying the UE ID(s) is / are valid or receiving the 422 the Authentication Information Answer message, the MME 114 may performs an authentication and key agreement procedure (i.e., events 454 and 456) with the UE 102 to authenticate the UE 102. The MME 114 transmits 454 an Authentication Request message to the UE 102 via the base station 104. In the Authentication Request message, the MME 114 includes authentication parameters such as a random challenge RAND, an authentication token AUTN and / or a Key Set Identifier (KSI). In some implementations, the KSI is a KSIASME. The UE 102 or the USIM of the UE 102 checks whether the AUTN is valid. If the AUTN is valid, the UE 102 or the USIM of the UE 102 computes a response RES based on the RAND. The UE 102 transmits 456 an Authentication Response message including the RES to the MME 114 via the base station 104. The MME 114 verifies whether the RES is valid or not. In this scenario, the MME 114 verifies that the RES is valid. As a result of the authentication and key agreement procedure, the UE 102 derives at least one security key (e.g., KASME or KAM ).

[0078] In some other implementations, the MME 114 may skip the authentication and key agreement procedure because authentication status for the UE 102 has still been valid since the MME 114 recently authenticated the UE 102.

[0079] After verifying the UE ID(s) is / are valid, receiving the 422 the Authentication Information Answer message or completing the authentication and key agreement procedure, the MME 114 transmits 458 a Security Mode Command message to the UE 102 via the base station 104 to activate security protection for exchanging NAS messages. In response, the UE 102 activates security protection and transmits 460 a Security Mode Complete message to the MME 114 via the base station 104.

[0080] After activating the security protection, the MME 114 transmits 424 an Attach Accept message to the UE 102 via the base station 104. In response, the UE 102 transmits an Attach Complete message to the MME 114 via the base station 104. After (e.g., in response to) receivingthe Attach Accept message or transmitting the Attach Complete message, the UE 102 has 429 normally attached for the emergency messaging service (only). After successfully completing the normal attach procedure, the UE 102 communicates SMS messages for an emergency messaging service with the MME 114 as described in Figs. 5C and 5D.

[0081] In some implementations, the MME 114 includes the SMS only indication (e.g., in an additional update result) in the Attach Accept message to indicate to the UE 102 that SMS is used for the messaging service (only). In some implementations, the MME 114 does so in response to receiving the SMS only indication in the Attach Request message. In other implementations, the MME 114 does so regardless of whether the Attach Request message includes the SMS only indication. In some implementations, the MME 114 includes the SMS only result in an Additional update result IE and includes the IE in the Attach Accept message. In response to transmitting the SMS only indication or receiving the SMS only result, the UE 102 only uses SMS for / as the messaging service.

[0082] In some implementations, the MME 114 indicates whether the MME 114 supports emergency attach for an emergency messaging service in the Attach Accept message. If the Attach Accept message indicates support of an emergency attach for an emergency messaging service, the UE 102 may perform emergency message communication, as described in Fig. 5C. Otherwise if the Attach Accept message does not indicate support of an emergency attach for an emergency messaging service, the UE 102 does not perform emergency message communication. If the Attach Accept message indicates support of an emergency attach for an emergency messaging service, the UE 102 may perform a PDN connectivity procedure to establish a PDN connection for an / the emergency messaging service, as described in Fig. 5D. Otherwise if the Attach Accept message does not indicate support of an emergency attach for an emergency messaging service, the UE 102 does not perform a PDN connectivity procedure to establish a PDN connection for an / the emergency messaging service. In this case, the UE 102 may perform a PDN connectivity procedure to establish a PDN connection for a messaging service. The PDN connectivity procedure is similar to the procedure 598 in Fig. 5D, except that the UE 102 does not indicate “emergency” or “emergency messaging” in a PDN Connectivity Request message of the PDN connectivity procedure. For example, the UE 102 may set a request type to “initial request” instead of “emergency” and includes the request type in the PDNConnectivity Request message. In some implementations, the messaging service is an emergency messaging service. In other implementations, the messaging service is a normal messaging service.

[0083] The events 405, 408, 411, 412, 414, 416, 418, 420, 422, 454, 456, 458, 460, 424, and 429 are collectively referred to in Fig. 4C as a normal attach procedure 491. The procedure 491 and the events 430, 432, and 434 are collectively referred to in Fig. 4C as a normal attach and connection release procedure 493.

[0084] Now referring to Fig. 5 A, in an example scenario 500A, the UE 102 communicates one or more text messages for emergency with the MME 114 and / or the SMSC 170. After receiving 502 a MIB, receiving 504 system information, and performing 592 the emergency attach and connection release procedure as described with reference to Fig. 4A and in connection with events 402, 404, and 492, respectively, the UE 102 initiates a control plane service request procedure in order to communicate a text message for emergency (i.e., mobile originated emergency message scenarios). In response to the initiating, the UE 102 performs 508 a RRC connection establishment procedure to establish a SRB (e.g., SRB1 or SRBlbis), similar to the event 408. In some implementations, the UE 102 sets an establishment cause to “emergency” or “emergency messaging” and includes the establishment cause in the RRC connection request message of the RRC connection establishment procedure 508. After receiving a RRC connection setup message in the procedure 508, the UE 102 transmits 540 a Control Plane Service Request message to the MME 114 via the base station 104. In some implementations, the UE 102 includes the Control Plane Service Request message in a RRC connection setup complete message of the RRC connection establishment procedure 508, instead of sen. Attach Compete message. In response, the MME 114 may transmit 542 a Service Accept message to the UE 102 via the base station 104. After receiving the Service Accept message, the UE 102 transmits 544 a UL NAS Transport message including the text message to the MME 114 via the base station 104. In some implementations, the UE 102 includes the text message in a first SMS PDU and includes the first SMS PDU in the UL NAS Transport message. The MME 114 retrieves the first SMS PDU from the UL NAS Transport message and transmits 548 the first SMS PDU to the SMSC 170. In some implementations, the SMSC 170 retrieves the text message from the first SMS PDU and transmits the text message to an emergency response center. In one implementation,the SMSC 170 generates a SMS PDU including the text message and transmits the SMS PDU to the emergency response center (e.g., a mobile number). In another implementation, the SMSC 170 generates an IP packet including the text message and transmits the IP packet to the emergency response center.

[0085] In some scenarios or implementations, the SMSC 170 transmits 550 a second SMS PDU including a text message to the MME 114 after receiving the first SMS PDU. The MME 114 generates a DL NAS Transport message including the second SMS PDU and transmits 552 the DL NAS Transport message to the UE 102 via the base station 104. In some implementations, the SMSC 170 receives the text message in an IP packet or a SMS PDU from the emergency response center.

[0086] In some other scenarios (i.e., mobile terminated emergency message scenarios), after performing the emergency attach and connection release procedure 492, SMSC 170 receives a text message for emergency for the UE 102 and transmits 562 the text message to the MME 114. To transmit the text message to the UE 102, the MME 114 transmits 564 a paging message to the base station 104 to page the UE 102. For example, the paging message 564 is an SI application protocol (S1AP) paging message. In response to receiving the paging message 564, the base station 104 transmits 507 a paging message to page the UE 102. For example, the paging message 507 is a RRC paging message. The UE 102 initiates the control plane service request procedure in response to receiving the paging message 507. In some implementations, the base station 104 includes a paging cause in the paging message 507 to indicate paging for an / the emergency messaging service. In some implementations, the base station 104 receives the paging cause in the paging message 564. In other implementations, the base station 104 receives an emergency indication in the paging message 564 and includes the paging cause in the paging message 507 in response to the emergency indication. In response to receiving the paging cause, the UE 102 sets an establishment cause to indicate emergency or emergency messaging and includes the establishment cause in the RRC connection request message of the RRC connection establishment procedure 508. In other implementations, the base station 104 does not include a paging cause in the paging message 507. In response to receiving the paging message, the UE 102 sets an establishment cause to “mt-access” and includes the establishment cause in the RRC connection request message of the RRC connection establishment procedure 508. After (e.g., inresponse to) receiving the Control Plane Service Request message, the MME 114 transmits 542 a DL NAS Transport message including the text message to UE 102 via the base station 104. In such cases, the MME 114 may not transmit a Service Accept message to the UE 102 to respond to the Control Plane Service Request message.

[0087] In some implementations, the MME 114 includes the UE ID (e.g., the IMEI) in the paging message 562. In one implementation, the base station 104 includes the UE ID in the paging message 507. In another implementation, the base station 104 derives a paging UE ID from the UE ID and includes the paging UE ID in the paging message 507. In such a case, the UE 102 also derives the paging UE ID from the UE ID. In some implementations, the paging UE ID is a portion of the UE ID (e.g., the IMEI). For example, the UE ID is N units (e.g., bits or digits) and the paging UE ID is M units (e.g., M last significant units or M most significant units) of the N units, where M is smaller than N.

[0088] In other implementations, the MME 114 includes the temporary UE ID (i.e., received in the Attach Accept message in the procedure 490) in the paging message 564. In one implementation, the base station 104 includes the temporary UE ID in the paging message 507. In another implementation, the base station 104 derive a paging UE ID from the temporary UE ID and includes the paging UE ID in the paging message 507. In such a case, the UE 102 also derives the paging UE ID from the temporary UE ID. For example, the temporary UE ID is N units (e g., bits or digits) and the paging UE ID is M units (e g., M last significant units or M most significant units) of the N units, where M is smaller than N.

[0089] In yet other implementations, the MME 114 derives a paging UE ID for paging from the UE ID or the temporary UE ID as described above and includes the paging UE ID in the paging message 564. In such cases, the base station 104 includes the paging UE ID in the paging message 507.

[0090] The events 544, 548, 550 and 552 are collectively referred to in Fig. 5 A as an emergency message communication 594. The events 562, 564, 507, 508, 540, 542 and the emergency message communication 594 are collectively referred to in Fig. 5A as an emergency message communication 595.

[0091] The messages 540, 542, 544 and 552 are NAS PDUs exchanged between the UE 102 and the base station 104 via RRC messages, similar to the messages 412, 414, 424 and 426.

[0092] Referring next to Fig. 5B, an example scenario 500B is described which is similar to Figs. 4A and 5A, except that the UE 102, the base station 104 and the MME 114 perform 590 the emergency attach procedure 590, similar to performing the emergency attach procedure 490 discussed above, the instead of the emergency attach and connection release procedure 592.

[0093] Referring next to Fig. 5C, an example scenario 500C is described which is similar to Figs. 4C and 5A, except that the UE 102, the base station 104 and the MME 114 perform the normal attach procedure 593, similar to performing the emergency attach procedure 493 discussed above, instead of the emergency attach and connection release procedure 592.

[0094] Referring next to Fig. 5D, an example scenario 500D is described which is similar to Figs. 4C, 5 A and 5C, except that the UE 102 performs 598 a PDN connectivity procedure with the MME 114 to establish a PDN connection for an emergency messaging service. After performing the normal attach and connection release procedure 593, the UE 102 initiates 598 the PDN connectivity procedure in order to communicate a text message for emergency. In response to the initiating, the UE 102 performs 505 a RRC connection establishment procedure to establish a RRC connection (e.g., a SRB such as SRB1 or SRBlbis), similar to the events 408 and 508. After receiving a RRC connection setup message in the procedure 505, the UE 102 transmits 562 a PDN Connectivity Request message to the MME 114 via the base station 104. In some implementations, the UE 102 transmits a Service Request message to the MME 114 to establish a NAS signaling connection and then transmits the PDN Connectivity Request message. In some implementations, the UE 102 indicates emergency or emergency messaging in the PDN Connectivity Request message to indicate that the UE 102 requests to establish a PDN connection for an emergency messaging service. For example, the UE 102 sets a request type to “emergency” or “emergency messaging” and includes the request type in the PDN Connectivity Request message to indicate that the UE 102 requests to establish a PDN connection for an emergency messaging service. In some implementations, the UE 102 includes the PDN Connectivity Request message in a RRC connection setup complete message of the RRC connection establishment procedure 505, instead of an Attach Compete message or a Control Plane Service Request message. In response, the MME 114 may transmit 564 an Activate DefaultEPS Bearer Context Request message to the UE 102 via the base station 104. After (e.g., in response to) receiving the Activate Default EPS Bearer Context Request message, the UE 102 transmits 566 an Activate Default EPS Bearer Context Accept message to the MME 114 via the base station 104. After receiving the Activate Default EPS Bearer Context Request message or transmitting Are. Activate Default EPS Bearer Context Accept message, the UE 102 has established a PDN connection for the emergency messaging service (only) with the MME 114 or the CN 110. The UE 102 and / or the CN 110 do not use the PDN connection for other services (e.g., voice call and / or video call).

[0095] After completing the PDN connectivity procedure 598, the UE 102 has emergency attached for the emergency messaging service (only), similar to the event 428. In some implementations, after the UE 102 has emergency attached for the emergency messaging service, the UE 102 transmit a 545D a ESM Data Transport message including a text message for emergency to the MME 114 via the base station 104. In some implementations, the UE 102 includes the text message in an IP packet and includes the IP packet in the ESM Data Transport message 545D. In other implementations, the UE 102 includes the text message in a non-IP packet and includes the non-IP packet in the ESM Data Transport message 545D. The MME 114 retrieves the packet (e.g., the IP packet or non-IP packet) from the ESM Data Transport message. In some implementations, the MME 114 transmits the packet to the emergency response center directly or via one or more other network nodes (e.g., the SGW 112 and / or the PGW 116). For example, the MME 114 transmits 549D the packet to the SGW 112 and the SGW 112 in turn transmits the packet to the PGW 116. The PGW 116 transmits the packet to the emergency response center.

[0096] In some scenarios or implementations, the SGW 112 transmits 55 ID a packet (e.g., an IP packet or a non-IP packet) including a text message to the MME 114 after receiving the packet 549D. The MME 114 generates an ESM Data Transport message including the packet and transmits 553D the ESM Data Transport message to the UE 102 via the base station 104. In some implementations, the SGW 112 receives the packet from the emergency response center.

[0097] The events 545D, 549D, 55 ID, 553D, 530, 532 and 534 are collectively referred to in Fig. 5D as an emergency message communication and connection release procedure 596D.

[0098] After the UE 102 has emergency attached for the emergency messaging service or the procedure 596D, the UE 102 may initiate a control plane service request procedure as described for Fig. 5A. In the mobile terminated emergency message scenarios, the MME 114 may transmit 543 an ESM Data Transport message in response to the Control Plane Service Request message 540 instead of a DL NAS Transport message. After receiving the Service Accept message or the ESM Data Transport message, the UE 102, the base station 104, the MME 114 and / or the SGW 112 perform 597D an emergency message communication and connection release procedure, similar to the procedure 596D.

[0099] Referring next to Fig. 5E, an example scenario 500E is described which is similar to Figs. 4A, 5A and 5D, except that the UE 102 communicates text messages with the SMSC 170 via the base station 104, the SGW 112, the PGW 166 and / or the IMS network instead of the MME 114. The IMS network is shown in Fig. 5E.

[0100] During the PDN connectivity procedure 598, the base station 104 transmits a RRC reconfiguration message to the UE 102 to configure a DRB and in response, the UE 102 transmits a RRC reconfiguration complete message to the base station 104. The RRC reconfiguration message and the RRC reconfiguration complete message form a RRC reconfiguration procedure. In one implementation, the RRC reconfiguration message and the RRC reconfiguration complete message are an RRCComiectionReconfiguration message and an RRCConnectionReconfigurationComplete message for the E-UTRA RAT respectively. In another implementation, the RRC reconfiguration message and the RRC reconfiguration complete message is an RRCConnectionReconfiguration-NB message and an RRCConnectionReconfigurationComplete-NB message for the NB-IoT RAT respectively. In yet another implementation, the RRC reconfiguration message and the RRC reconfiguration complete message is an RRCReconfiguration message and an RRCReconfigurationComplete message for the NR RAT respectively.

[0101] In some implementations, the UE 102 transmits 545E a text message to the base station 104 via the DRB and the base station 104 transmits the text message to the SGW 112. The SGW 112 transmits 549E the text message to the SMSC 170 via the PGW 116 and / or the IMS network. In some implementations, the UE generates a SMS PDU including the text message, generates an IMS packet including the SMS PDU and transmits 545E the IMS packet to the basestation 104 via the DRB. The base station 104 transmits the IMS packet to the SGW 112. The SGW 112 transmits the IMS packet to the IMS network directly or via the PGW 116. The IMS network retrieves the SMS PDU from the IMS packet and transmits SMS PDU to the SMSC 170. the IMS packet is a session initiation protocol (SIP) packet.

[0102] In some implementations, the SMSC 170 transits 55 IE a text message for the UE 102 to the SGW 112 via the PGW 116 and / or the IMS network. The SGW 112 transmits 553E the text message to the base station 104. The base station transmits the text message to the UE 102 via the DRB. In some implementations, the SMSC 170 generate a SMS PDU including a text message and transmits the SMS PDU to the IMS network. The IMS network generates an IMS packet including the SMS PDU and transmits the IMS packet to the SGW 112 directly or via the PGW 1 16. The SGW 112 transmits the IMS packet to the base station 104 and the base station 104 transmits the IMS packet to the UE 102 via the DRB. In some implementations, the IMS packet is a SIP packet.

[0103] The events 545E, 549E, 55 IE, 553E, 530, 532 and 534 are collectively referred to in Fig. 5E as an emergency message communication and connection release procedure 596E.

[0104] After the UE 102 has emergency attached for an emergency messaging service, the UE 102 may initiate a service request procedure. In some implementations, the UE 102 initiates the service request procedure to transmit a text message. In other implementations, the UE 102 initiates the service request procedure in response to receiving the paging message 507. In response to initiating the service request procedure, the UE 102 performs 508 the RRC connection establishment procedure to establish a RRC connection (e.g., a SRB1). After establishing the RRC connection, the UE 102 transmits 541 a Service Request message to the MME 114 via the base station 104 and the RRC connection. After transmitting the Serving Request message, the UE 102 may perform a RRC reconfiguration procedure to establish a DRB with the base station 104 as described above. The UE 102 performs 597E an emergency message communication and connection release procedure to communicates text messages with the SMSC 170, similar to the procedure 596E.

[0105] Next, several example methods that can be implemented in a UE (e.g., the UE 102), a RAN node such as a base station (BS), a RAN (e.g., the RAN 105), a MME (e.g., the MME 114, or a CN (e.g., the CN 110) are discussed with reference to Figs. 6A-8. Each of these methodscan be implemented using processing hardware such as one or more processors to execute instmctions stored on a non-transitory computer-readable medium such as computer memory. At least some of the discussion of Figs. 4A-5D above can apply to Figs. 6A-8. Similar steps are similarly labeled (e.g., 404, 604, etc.) and individual descriptions are therefore omitted.

[0106] Referring first to Fig. 6A, a method 600A can be implemented in a UE (e.g., the UE 102) for performing an emergency attach procedure for an emergency messaging service and communicating emergency messages. The method 600A begins at block 604, the UE receives system information via a cell. At block 690, the UE performs an emergency attach procedure for an emergency messaging service with a CN via the cell. At block 640, the UE transmits a Control Plane Service Request message via the cell to the CN. At block 694, the UE communicates one or more emergency messages with the CN via the cell, after completing the emergency attach procedure.

[0107] Fig. 6B is a flow diagram of an example method 600B, similar to the method 600A, except that the method 600B includes blocks 691, 698 and 695 instead of blocks 690 and 694. At block 691, the UE performs a normal attach procedure for a messaging service with a CN via the cell. The flow proceeds to block 698 and / or block 640. At block 698, the UE performs an emergency PDN connectivity procedure with the CN via the cell to establish an emergency PDN connection for an emergency messaging service. At block 695, the UE communicates one or more emergency messages with the CN via the cell after completing the emergency PDN connectivity procedure.

[0108] Fig. 6C is a flow diagram of an example method 600C, similar to the method 600A, except that the method 600C includes blocks 662 and 674 instead of blocks 640 and 694. The flow proceeds to block 662 from block 604. At block 662, the UE determines whether the system information indicates that an emergency messaging service is supported. If the system information indicates that an emergency messaging service is supported (i.e., “Yes” branch of block 662), the flow proceeds to block 690. At block 690, the UE performs an emergency attach procedure for an emergency messaging service with a CN via the cell. Otherwise, if the system information indicates that an emergency messaging service is not supported (i.e., “No” branch of block 662), the flow proceeds to block 674. At block 674, the UE refrain from performing an emergency attach procedure for an emergency messaging service with the CN via the cell.

[0109] Fig. 6D is a flow diagram of an example method 600D, similar to the methods 600A and 600C, except that the method 600D includes block 663 instead of block 662. The flow proceeds to block 663 from block 604. At block 663, the UE determines whether the system information indicates a particular PLMN (e.g., a first PLMN). If the system information indicates the particular PLMN (i.e., “Yes” branch of block 663), the flow proceeds to block 690. Otherwise, if the system information indicates a second PLMN (i.e., “No” branch of block 663), the flow proceeds to block 674.

[0110] In some implementations, the UE is preconfigured with a first PLMN ID of the first PLMN that supports an emergency attach for an emergency messaging service. In some implementations, the UE is preconfigured with the first PLMN ID during manufacturing. In other implementations, the UE is preconfigured with the first PLMN ID via an Over-the-Air (OTA) update before block 604 or 663. If the system information includes the first PLMN ID, the UE performs the action described in block 690. Otherwise, if the system information includes a PLMN ID (e.g., a second PLMN ID) different from the first PLMN ID, the UE performs the action described in block 674. In other implementations, the UE is preconfigured with a second PLMN ID of the second PLMN that does not support an emergency attach for an emergency messaging service. In some implementations, the UE is preconfigured with the second PLMN ID during manufacturing. In other implementations, the UE is preconfigured with the second PLMN ID via an OTA update before block 604 or 663. If the system information includes the second PLMN ID, the UE performs the action described in block 674. Otherwise, if the system information includes a PLMN ID (e.g., the first PLMN ID) different from the second PLMN ID, the UE performs the action described in block 690.

[0111] Fig. 6E is a flow diagram of an example method 600E, similar to the methods 600A, 600C and 600D, except that the method 600E includes block 661 instead of blocks 662 and 663. The flow proceeds to block 661 from block 604. At block 661, the UE determines whether the UE is preconfigured to perform an emergency attach for an emergency messaging service via a / the satellite. If the UE is preconfigured to perform an emergency attach for an emergency messaging service via a / the satellite (i.e., “Yes” branch of block 661), the flow proceeds to block 690. Otherwise, if the UE is not preconfigured to perform an emergency attach for an emergencymessaging service via a / the satellite (i.e., “No” branch of block 661), the flow proceeds to block 674.

[0112] In some implementations, the UE is preconfigured to perform an emergency attach for an emergency messaging service via a / the satellite during manufacturing. In other implementations, the UE is preconfigured to perform an emergency attach for an emergency messaging service via a / the satellite via an OTA update before block 604 or 661.

[0113] Fig. 6F is a flow diagram of an example method 600F, similar to the methods 600A, 600B and 600C, except that the method 600F includes blocks 675 and 676. The flow begins with blocks 604 and 691 and proceeds to block 662 from block 691. If the system information indicates that an emergency messaging service is supported (i.e., “Yes” branch of block 662), the flow proceeds to block 698. Otherwise, if the system information indicates that an emergency messaging service is not supported (i.e., “No” branch of block 662), the flow proceeds to block 675. At block 675, the UE refrain from performing an emergency PDN connectivity procedure for an emergency messaging service with the CN via the cell. The flow may proceed to block 676 from block 675. At block 676, the UE performs a non-emergency PDN connectivity procedure with the CN via the cell to establish a PDN connection for a messaging service.

[0114] Fig. 6G is a flow diagram of an example method 600G, similar to the methods 600A, 600B, 600D and 600F. The flow begins with blocks 604 and 691 and proceeds to block 663 from block 691. If the system information indicates the particular PLMN (i.e., “Yes” branch of block 663), the flow proceeds to block 698. Otherwise, if the system information indicates a second PLMN (i.e., “No” branch of block 663), the flow proceeds to block 675. The flow may proceed to block 676 from block 675.

[0115] In some implementations, the UE is preconfigured with a first PLMN ID of the first PLMN that supports an emergency attach for an emergency messaging service. In some implementations, the UE is preconfigured with the first PLMN ID during manufacturing. In other implementations, the UE is preconfigured with the first PLMN ID via an Over-the-Air (OTA) update before block 604 or 663. If the system information includes the first PLMN ID, the UE performs the action described in block 698. Otherwise, if the system information includes a PLMN ID (e.g., a second PLMN ID) different from the first PLMN ID, the UE performs the action(s) described in block 675 and / or block 676. In other implementations, the UE ispreconfigured with a second PLMN ID of the second PLMN that does not support an emergency attach for an emergency messaging service. In some implementations, the UE is preconfigured with the second PLMN ID during manufacturing. In other implementations, the UE is preconfigured with the second PLMN ID via an OTA update before block 604 or 663. If the system information includes the second PLMN ID, the UE performs the action(s) described in block 675 and / or block 676. Otherwise, if the system information includes a PLMN ID (e g., the first PLMN ID) different from the second PLMN ID, the UE performs the action described in block 698.

[0116] Fig. 6H is a flow diagram of an example method 600H, similar to the methods 600A, 600B, 600E and 600F. The flow begins with blocks 604 and 691 and proceed to block 661 from block 691 . If the UE is preconfigured to perform an emergency attach for an emergency messaging service via a / the satellite (i.e., “Yes” branch of block 661), the flow proceeds to block 698. Otherwise, if the UE is not preconfigured to perform an emergency attach for an emergency messaging service via a / the satellite (i.e., “No” branch of block 661), the flow proceeds to block 675.

[0117] Fig. 61 is a flow diagram of an example method 6001, similar to the methods 600A, 600B and 600F. The flow begins with blocks 604 and 691 and proceed to block 671 from block 691. If the Attach Accept message of the normal attach procedure indicates that emergency messaging service(s) is / are supported (i.e., “Yes” branch of block 671), the flow proceeds to block 698. Otherwise, if the Attach Accept message of the normal attach procedure indicates that emergency messaging service(s) is / are not supported (i.e., “No” branch of block 671), the flow proceeds to block 675.

[0118] Referring now to Fig. 7, a method 700 can be implemented in a RAN (e.g., the RAN 105 or the base station 104 or 106) for supporting an emergency messaging service. The method 700 begins at block 704 where the RAN broadcasts system information via a cell. At block 708- 1, the RAN receives an RRCConnectionRequest-NB message including an establishment cause for emergency from a UE via the cell. At block 708-2, the RAN transmits an RRCConnectionSetup-NB message to the UE in response to the RRCConnectionRequest-NB message via the cell. At block 708-3, the RAN receives an RRCConnectionSetupComplete-NBmessage from the UE via the cell. At block 711, the RAN may transmit a BS-to-CN message including the emergency cause to a CN (e.g., a MME).

[0119] In some implementations, the system information indicates that an emergency messaging service is supported. In some implementations, the RAN includes the establishment cause in the BS-to-CN message to indicate that the UE connects to the RAN for an emergency messaging service. In some implementations, the BS-to-CN message is an Initial UE Message message. In some implementations, the RRCConnectionSetupComplete-NB message includes a UL NAS message and the RAN includes the UL NAS message in the BS-to-CN message. For example, the UE NAS message is an Attach Request message, a Tracking Area Update Request message, a Control Plane Service Request message, a Service Request message or a PDN Connectivity Request message.

[0120] Referring now to Fig. 8A, a method 800A can be implemented in a CN (e.g., the CN 110, the MME 114 or the AMF 164) for performing an emergency attach procedure for an emergency messaging service and communicating emergency messages.

[0121] The method 800A begins at block 890 where the CN performs an emergency attach procedure for an emergency messaging service with a UE via the cell. At block 840, the CN receives a Control Plane Service Request message via the cell from the UE. At block 894, the CN communicates one or more emergency messages with the UE via the cell after completing the emergency attach procedure with the UE.

[0122] Fig. 8B is a flow diagram of an example method 800B, similar to the method 800A, except that the method 800B includes blocks 891, 898 and 895 instead of blocks 890 and 894. At block 891, the CN performs a normal attach procedure for a messaging service with a UE via the cell. The flow proceeds to block 898 and / or block 840. At block 898, the CN performs an emergency PDN connectivity procedure with the UE via the cell to establish an emergency PDN connection for an emergency messaging service. At block 895, the CN communicates one or more emergency messages with the UE via the cell after completing the emergency PDN connectivity procedure.

[0123] Referring now to Fig. 9, a method 900 can be implemented in a RAN (e.g., the RAN 105 or the base station 104 or 106) for supporting emergency messaging service(s). The method900 begins at block 904-1 where the RAN broadcasts first system information including a first indication via at least first one cell, where the first indication indicates support of an emergency messaging service. At block 908, the RAN establishes a connection for an emergency messaging service with a first UE. At block 904-2, the RAN broadcasts second system information including a second indication via at least one second cell, where the second indication indicates support of an IMS emergency call. At block 909, the RAN establishes a connection for an IMS emergency call with a second UE.

[0124] In some implementations, the RAN performs a RRC connection establishment procedure and / or a RRC reconfiguration procedure with the first UE to establish the connection for the emergency messaging service. In some implementations, the RAN performs a RRC connection establishment procedure and / or a RRC reconfiguration procedure with the second UE to establish the connection for the IMS emergency call. In some implementations, the first system information and the second system information are the same system information (i.e., the same instance). In other implementations the first system information and the second system information are different system information.

[0125] Referring now to Fig. 10, a method 1000 can be implemented in a CN (e.g., the CN 110, the MME 114 or the AMF 164) for indicating support of emergency message services and / or support of IMS emergency call. The method 1000 begins at block 1011-1 where the CN receives a first Attach Request message from a first UE. At block 1024-1, the CN transmits a first Attach Accept message including a first indication to the first UE, where the first indication indicates support of an emergency messaging service. At block 1098-1, the CN performs a PDN connectivity procedure with the first UE to establish an emergency PDN connection for an emergency messaging service. At block 1011-2, the CN receives a second Attach Request message from a second UE. At block 1024-2, the CN transmits a second Attach Accept message including a second indication to the second UE, where the second indication indicates support of an emergency call service. At block 1098-2, the CN performs a PDN connectivity procedure with the second UE to establish an emergency PDN connection for an IMS emergency call.

[0126] In some implementations, the CN refrains from including the first indication in the second Attach Accept message. In other implementations, the CN includes the first indication in the second Attach Accept message. In some implementations, the CN refrains from including thesecond indication in the first Atach Accept message. In other implementations, the CN includes the second indication in the first Atach Accept message.

[0127] Referring first to Fig. 11, a method 1100 can be implemented in a UE (e.g., the UE 102) for performing an emergency attach procedure for an emergency messaging service and communicating emergency messages. The method 1100 begins at block 1111 where the UE transmits an Attach Request message. At block 1124, the UE receives an Attach Accept message including a first indication, where the first indication indicates support of an emergency messaging service. At block 1198, the UE performs a PDN connectivity procedure with the first UE to establish an emergency PDN connection for an emergency messaging service based on the first indication.

[0128] Referring first to Fig. 12, a method 1200 can be implemented in a UE (e.g., the UE 102) for performing an emergency attach procedure for an emergency messaging service and communicating emergency messages. The method begins at block 1282 where the UE receives a message (e.g., event 404 or 424). At block 1284, the UE initiates transmission of an emergency message. At block 1285, the UE determines whether the message indicates support of an emergency messaging service. If the message indicates support of an emergency messaging service (i.e., “Yes” branch of block 1285), the UE sets an establishment cause to indicate emergency or emergency messaging at block 1286. Otherwise, if the message indicates not support of an emergency messaging service (i.e., “No” branch of block 1285), the UE sets the establishment cause to indicate mo-data at block 1287. The flow proceeds to block 1208 from block 1286 as well as block 1287. At block 1208, the UE transmits a RRC connection request message including the establishment cause.

[0129] Referring first to Fig. 13, a method 1300 can be implemented in a UE (e.g., the UE 102) for performing an emergency attach procedure for an emergency messaging service and communicating emergency messages. The method 1300 begins at block 1307 where the UE receives a paging message. At block 1309, the UE determines whether paging message includes a paging cause indicating emergency (i.e., the paging message includes an emergency indication). If the paging message includes a paging cause indicating emergency, the flow proceeds to block 1386. At block 1386, the UE sets an establishment cause to indicate emergency. Otherwise, if the paging message does not include a paging cause indicatingemergency, the flow proceeds to block 1387. At block 1387, the UE sets the establishment cause to indicate mobile terminated data (e.g., mt-data). The flow proceeds to block 1308 from block 1386 as well as block 1387. At block 1308, the UE transmits a RRC connection request message including the establishment cause.

[0130] Referring now to Fig. 14, a method 1400 can be implemented in a RAN node (e.g., the base station 104 or 106 or a distributed unit (DU) of the base station 104 or 106) for supporting an emergency messaging service. The method begins at block 1464 where the RAN node receives a first paging message to page a UE. At block 1465, the RAN node includes a UE ID of the UE in a second paging message. At block 1409, the RAN node determines whether the first paging message indicates emergency. If the first paging message indicates emergency (i.e., “Yes” branch of block 1409), the flow proceeds to block 1486. At block 1486, the RAN node includes a paging cause indicating emergency in the second paging message (i.e., includes an emergency indication in the second paging message). Otherwise, if the first paging message does not indicate emergency (i.e., “No” branch of block 1409), the flow proceeds to block 1407. At block 1407, the RAN node transmits the second paging message to page the UE without the paging cause.

[0131] In some implementations, the second paging message is a RRC paging message. In other implementations, the second paging message is a Fl application protocol (F1AP) paging message. In some implementations, the first paging message is an S1AP message or a NGAP message. In other implementations, the first paging message is a Fl AP paging message. In some implementations, the RAN node is a DU and receives the first paging message from a central unit (CU). In other implementations, the RAN node is a CU or a base station and receives the first paging message from a CN (e.g., a AMF).

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

[0133] Example 1. A method in a UE for enabling an emergency messaging service, the method comprising: receiving, at the UE, system information via a cell; performing, by the UE, an attach procedure for a messaging service with a core network (CN) via the cell; and communicating, by the UE, one or more emergency messages with the CN.

[0134] Example 2. The method of example 1, wherein performing the attach procedure includes: performing, by the UE, an emergency attach procedure for an emergency messaging service with the CN; and communicating, by the UE, the one or more emergency messages with the CN in response to completing the emergency attach procedure.

[0135] Example 3. The method of example 2, further comprising: determining, by the UE, whether the system information indicates that the emergency messaging service is supported.

[0136] Example 4. The method of example 3, further comprising: performing, by the UE, the emergency attach procedure for the emergency messaging service with the CN in response to determining that the emergency messaging service is supported.

[0137] Example 5. The method of example 3, wherein the UE performs the emergency attach procedure in a first instance, and the further comprising: in a second instance: refraining, by the UE, from performing the emergency attach procedure for the emergency messaging service with the CN in response to determining that the emergency messaging service is not supported.

[0138] Example 6. The method of example 3, further comprising: setting, by the UE, an establishment cause in a connection request message to indicate an emergency or emergency messaging in response to determining that the emergency messaging service is supported; and transmitting, by the UE, the connection request message including the establishment cause.

[0139] Example 7. The method of example 3, further comprising: setting, by the UE, an establishment cause in a connection request message to indicate mobile originated data (mo-data) in response to determining that the emergency messaging service is not supported; and transmitting, by the UE, the connection request message including the establishment cause.

[0140] Example 8. The method of example 2, further comprising: receiving, at the UE, a paging message; and determining, by the UE, whether the paging message indicates an emergency.

[0141] Example 9. The method of example 8, further comprising: setting, by the UE, an establishment cause in a connection request message to indicate the emergency in response to determining that the paging message indicates the emergency; and transmitting, by the UE, the connection request message including the establishment cause.

[0142] Example 10. The method of example 8, further comprising: setting, by the UE, an establishment cause in a connection request message to indicate mobile terminated data (mt-data) in response to determining that the paging message does not indicate the emergency; and transmitting, by the UE, the connection request message including the establishment cause.

[0143] Example 11. The method of example 2, further comprising: determining, by the UE, whether the system information indicates a particular public land mobile network (PLMN).

[0144] Example 12. The method of example 11, further comprising: performing, by the UE, the emergency attach procedure for the emergency messaging service with the CN in response to determining that the system information indicates the particular PLMN.

[0145] Example 13. The method of example 11, wherein the UE performs the emergency attach procedure in a first instance, and the further comprising: in a second instance: refraining, by the UE, from performing the emergency attach procedure for the emergency messaging service with the CN in response to determining that the system information does not indicate the particular PLMN.

[0146] Example 14. The method of example 2, further comprising: determining, by the UE, whether the UE is preconfigured to perform the emergency attach procedure via a satellite.

[0147] Example 15. The method of example 14, further comprising: performing, by the UE, the emergency attach procedure for the emergency messaging service with the CN in response to determining that the UE is preconfigured to perform the emergency attach procedure via the satellite.

[0148] Example 16. The method of example 14, wherein the UE performs the emergency attach procedure in a first instance, and the further comprising: in a second instance: refraining, by the UE, from performing the emergency attach procedure for the emergency messaging service with the CN in response to determining that the UE is not preconfigured to perform the emergency attach procedure via the satellite.

[0149] Example 17. The method of example 1, wherein performing the attach procedure includes: performing, by the UE, a normal attach procedure for the messaging service with the CN.

[0150] Example 18. The method of example 17, further comprising: performing, by the UE, an emergency packet data network (PDN) connectivity procedure with the CN via the cell to establish an emergency PDN connection for an emergency messaging service; and communicating, by the UE, the one or more emergency messages with the CN in response to completing the emergency PDN connectivity procedure.

[0151] Example 19. The method of example 18, further comprising: in response to performing the normal attach procedure, determining, by the UE, whether the system information indicates that an emergency messaging service is supported.

[0152] Example 20. The method of example 19, further comprising: performing, by the UE, the emergency PDN connectivity procedure for the emergency messaging service with the CN in response to determining that the system information indicates that the emergency messaging service is supported.

[0153] Example 21. The method of example 19, wherein the UE performs the emergency PDN connectivity procedure in a first instance, and the further comprising: in a second instance: refraining, by the UE, from performing the emergency PDN connectivity procedure for the emergency messaging service with the CN in response to determining that the system information does not indicate that the emergency messaging service is supported; and performing, by the UE, a non-emergency PDN connectivity procedure with the CN via the cell to establish a PDN connection for the messaging service.

[0154] Example 22. The method of example 18, further comprising: in response to performing the normal attach procedure, determining, by the UE, whether the system information indicates a particular public land mobile network (PLMN).

[0155] Example 23. The method of example 22, further comprising: performing, by the UE, the emergency PDN connectivity procedure for the emergency messaging service with the CN in response to determining that the system information indicates the particular PLMN.

[0156] Example 24. The method of example 22, wherein the UE performs the emergency PDN connectivity procedure in a first instance, and the further comprising: in a second instance: refraining, by the UE, from performing the emergency PDN connectivity procedure for the emergency messaging service with the CN in response to determining that the systeminformation does not indicate the particular PLMN; and performing, by the UE, a nonemergency PDN connectivity procedure with the CN via the cell to establish a PDN connection for the messaging service.

[0157] Example 25. The method of example 18, further comprising: in response to performing the normal attach procedure, determining, by the UE, whether the UE is preconfigured to perform the emergency attach procedure via a satellite.

[0158] Example 26. The method of example 25, further comprising: performing, by the UE, the emergency PDN connectivity procedure for the emergency messaging service with the CN in response to determining that the UE is preconfigured to perform the emergency attach procedure via the satellite.

[0159] Example 27. The method of example 25, wherein the UE performs the emergency PDN connectivity procedure in a first instance, and the further comprising: in a second instance: refraining, by the UE, from performing the emergency PDN connectivity procedure for the emergency messaging service with the CN in response to determining that the UE is not preconfigured to perform the emergency PDN connectivity procedure via the satellite; and performing, by the UE, a non-emergency PDN connectivity procedure with the CN via the cell to establish a PDN connection for the messaging service.

[0160] Example 28. The method of example 18, further comprising: in response to performing the normal attach procedure, determining, by the UE, whether an attach accept message in the normal attach procedure indicates that an emergency messaging service is supported.

[0161] Example 29. The method of example 28, further comprising: performing, by the UE, the emergency PDN connectivity procedure for the emergency messaging service with the CN in response to determining that the attach accept message indicates that the emergency messaging service is supported.

[0162] Example 30. The method of example 28, wherein the UE performs the emergency PDN connectivity procedure in a first instance, and the further comprising: in a second instance: refraining, by the UE, from performing the emergency PDN connectivity procedure for the emergency messaging service with the CN in response to determining that the attach accept message does not indicate that the emergency messaging service is supported; and performing,by the UE, a non-emergency PDN connectivity procedure with the CN via the cell to establish a PDN connection for the messaging service.

[0163] Example 31. The method of example 29, wherein performing the normal attach procedure includes: transmitting, by the UE, an attach request message; and receiving, at the UE, the attach accept message that indicates that the emergency messaging service is supported.

[0164] Example 32. The method of any of the preceding examples, further comprising: transmitting, by the UE, a control plane service request message via the cell to the CN.

[0165] Example 33. A UE comprising processing hardware configured to implement a method of any of examples 1-32.

[0166] Example 34. A method in a core network (CN) for performing an attach procedure for a messaging service, the method comprising: performing, by the CN, an attach procedure for a messaging service with a UE via a base station; and communicating, by the CN, one or more emergency messages with the UE via the base station.

[0167] Example 35. The method of example 34, wherein performing the attach procedure includes: performing, by the CN, an emergency attach procedure for an emergency messaging service with the UE; and communicating, by the CN, the one or more emergency messages with the UE in response to completing the emergency attach procedure.

[0168] Example 36. The method of example 34, wherein performing the attach procedure includes: performing, by the CN, a normal attach procedure for the messaging service with the UE.

[0169] Example 37. The method of example 36, further comprising: performing, by the CN, an emergency packet data network (PDN) connectivity procedure with the UE via the base station to establish an emergency PDN connection for an emergency messaging service; and communicating, by the CN, the one or more emergency messages with the UE in response to completing the emergency PDN connectivity procedure.

[0170] Example 38. The method of example 37, wherein the UE is a first UE and further comprising: receiving, at the CN, a first attach request message from the first UE; transmitting, by the CN to the first UE, a first attach accept message including a first indication that indicates support of an emergency message service; performing, by the CN, the PDN connectivityprocedure with the first UE via the base station to establish the emergency PDN connection for the emergency messaging service; receiving, at the CN, a second attach request message from a second UE; transmitting, by the CN to the second UE, a second attach accept message including a second indication that indicates support of an emergency call service; and performing, by the CN, the PDN connectivity procedure with the second UE via the base station to establish the emergency PDN connection for an emergency call.

[0171] Example 39. The method of any one of example 34-38, further comprising: receiving, at the CN, a control plane service request message from the UE via the base station.

[0172] Example 40. A core network comprising processing hardware configured to implement a method of any of examples 34-39.

[0173] Example 41. A method in a base station for supporting an emergency messaging service, the method comprising: broadcasting, by the base station, system information via a satellite; receiving, by the base station via the satellite, a radio connection request message from a UE indicating an emergency; and transmitting, by the base station to a core network (CN), a message indicating the emergency.

[0174] Example 42. The method of example 41, wherein receiving the connection request message includes: receiving, by the base station via the satellite, the connection request message including an establishment cause for emergency; and transmitting, by the base station to a core network (CN), a BS-to-CN message including the emergency cause.

[0175] Example 43. The method of example 41, further comprising: transmitting, by the base station to the UE via the satellite, a radio connection setup message in response to receiving the radio connection request message from the UE; and receiving, by the base station from the UE via the satellite, a radio connection setup complete message.

[0176] Example 44. The method of example 41, wherein the UE is a first UE and further comprising: broadcasting, by the base station via the satellite, first system information including a first indication that indicates support of an emergency message service; establishing, by the base station, a connection for the emergency messaging service with the first UE; broadcasting, by the base station via the satellite, second system information including a second indication thatindicates support of an emergency call; and establishing, by the base station, a connection for the emergency call with a second UE.

[0177] Example 45. The method of example 41, further comprising: receiving, by the base station from a core network (CN), a first paging message to page the UE; and generating, by the base station to the UE, a second paging message include a UE identifier of the UE.

[0178] Example 46. The method of example 45, further comprising: in a first instance: in response to determining that the first paging message indicates the emergency: including a paging cause indicating the emergency in the second paging message; and transmitting, by the base station, the second paging message to the UE.

[0179] Example 47. The method of example 45, further comprising: in a second instance: in response to determining that the first paging message does not indicate the emergency: transmitting, by the base station, the second paging message to the UE without the paging cause.

[0180] Example 48. A base station comprising processing hardware configured to implement a method of any of examples 41-47.

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

[0182] 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. The “attach” can be replaced by “registration”. The “Attach” can be replaced by “Registration”. The “EPS attach type” can be replaced by “5GS registration type”. “EPS emergency attach” can be “emergency registration”. The “emergency messaging service” can be replaced by “emergency SMS” or “emergency messaging services”. The “emergency messaging” can be replaced by “emergency SMS” or “emergency messaging service(s)”. “via a cell” can be replaced by “via a satellite”, “via the cell” can be replaced by “via the satellite”.

[0183] In some implementations, the “PDN connectivity procedure” can be replaced by a “PDU session establishment procedure”. In such cases, the “PDN Connectivity Request” and “Activate Default EPS Bearer Context Request” can be replaced by “PDU Session Establishment Request” and “PDU Session Establishment Accept”, respectively and the “Activate Default EPS Bearer Context Accept” is omitted.

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

[0185] Certain embodiments are described in this disclosure as including logic or a number of components or modules. Modules may 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.

[0186] 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 may 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 UE for enabling an emergency messaging service, the method comprising: receiving, at the UE, system information via a cell; performing, by the UE, an attach procedure for a messaging service with a core network (CN) via the cell; and communicating, by the UE, one or more emergency messages with the CN.

2. The method of claim 1, wherein performing the attach procedure includes: performing, by the UE, an emergency attach procedure for an emergency messaging service with the CN; and communicating, by the UE, the one or more emergency messages with the CN in response to completing the emergency attach procedure.

3. The method of claim 2, further comprising: performing, by the UE, the emergency attach procedure for the emergency messaging service with the CN in response to determining that the emergency messaging service is supported.

4. The method of claim 2, further comprising: setting, by the UE, an establishment cause in a connection request message to indicate an emergency or emergency messaging in response to determining that the emergency messaging service is supported; and transmitting, by the UE, the connection request message including the establishment cause.

5. The method of claim 2, further comprising: setting, by the UE, an establishment cause in a connection request message to indicate mobile originated data (mo-data) in response to determining that the emergency messaging service is not supported; andtransmitting, by the UE, the connection request message including the establishment cause.

6. The method of claim 1, further comprising: receiving, at the UE, a paging message; setting, by the UE, an establishment cause in a connection request message to indicate the emergency in response to determining that the paging message indicates the emergency; and transmitting, by the UE, the connection request message including the establishment cause.

7. The method of claim 1, further comprising: receiving, at the UE, a paging message; setting, by the UE, an establishment cause in a connection request message to indicate mobile terminated data (mt-data) in response to determining that the paging message does not indicate the emergency; and transmitting, by the UE, the connection request message including the establishment cause.

8. The method of claim 2, wherein: the performing of the emergency attach procedure for the emergency messaging service with the CN is in response to determining that the system information indicates a particular PLMN.

9. The method of claim 2, wherein: the performing of the emergency attach procedure for the emergency messaging service with the CN is in response to determining that the UE is preconfigured to perform the emergency attach procedure via a satellite.

10. The method of claim 1, wherein the performing of the attach procedure includes: performing, by the UE, a normal attach procedure for the messaging service with the CN;performing, by the UE, an emergency packet data network (PDN) connectivity procedure with the CN via the cell to establish an emergency PDN connection for an emergency messaging service.

11. The method of claim 10, further comprising, in response to the performing of the normal attach procedure: determining, by the UE, whether the system information indicates that an emergency messaging service is supported.

12. The method of claim 11, wherein the performing of the emergency PDN connectivity procedure for the emergency messaging service with the CN is in response to determining that the system information indicates that the emergency messaging service is supported.

13. A method in a base station for supporting an emergency messaging service, the method comprising: broadcasting, by the base station, system information via a satellite; receiving, by the base station via the satellite, a radio connection request message from a UE indicating an emergency; and transmitting, by the base station to a core network (CN), a message indicating the emergency.

14. The method of claim 13, wherein the receiving of the connection request message includes: receiving, by the base station via the satellite, the connection request message including an establishment cause for emergency; and transmitting, by the base station to a core network (CN), a BS-to-CN message including the emergency cause.

15. A device comprising a transceiver and processing hardware; the device configured to implement a method of any of the preceding claims.

Images