Mechanisms of handling emergency SMS over nas
The introduction of capability negotiation mechanisms for emergency SMS over NAS in wireless communication systems ensures priority treatment and reliable delivery of emergency SMS messages, overcoming the limitations of uniform SMS treatment in current standards.
Patent Information
- Application Number
- PCT/CN2025/126912
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2024-10-11
- Filing Date
- 2025-10-11
- Publication Date
- 2026-04-16
AI Technical Summary
Current 5G and future 6G wireless communication systems lack mechanisms for prioritizing emergency SMS messages over Non-Access Stratum (NAS), leading to uniform treatment of all SMS messages without distinction, which hinders reliable delivery during critical situations, especially during network congestion.
Implementing capability negotiation mechanisms for UEs and networks to discover mutual support for emergency SMS over NAS through dynamic explicit signaling and pre-configuration methods, allowing differentiated handling of emergency SMS messages by assigning a separate access category and bypassing NAS back-off timers during congestion.
Ensures priority treatment for emergency SMS messages, enabling reliable delivery even during network congestion, thus addressing the public safety gap in existing systems.
Smart Images

Figure CN2025126912_16042026_PF_FP_ABST
Abstract
Description
MECHANISMS OF HANDLING EMERGENCY SMS OVER NASCROSS-REFERENCE TO RELATED APPLICATION (S)
[0001] This application claims priority to Indian Patent Application Serial No. 202421077299, entitled “METHOD TO HANDLE EMERGENCY SMS OVER NAS” and filed on October 11, 2024, which is expressly incorporated by reference herein in its entirety.BACKGROUNDField
[0002] The present disclosure relates generally to wireless communications, and more particularly, to techniques of handling emergency Short Message Service (SMS) messages over Non-Access Stratum (NAS) with priority treatment in wireless communication systems. Background
[0003] The statements in this section merely provide background information related to the present disclosure and may not constitute prior art.
[0004] Wireless communication systems are widely deployed to provide various telecommunication services such as telephony, video, data, messaging, and broadcasts. Typical wireless communication systems may employ multiple-access technologies capable of supporting communication with multiple users by sharing available system resources. Examples of such multiple-access technologies include code division multiple access (CDMA) systems, time division multiple access (TDMA) systems, frequency division multiple access (FDMA) systems, orthogonal frequency division multiple access (OFDMA) systems, single-carrier frequency division multiple access (SC-FDMA) systems, and time division synchronous code division multiple access (TD-SCDMA) systems.
[0005] These multiple access technologies have been adopted in various telecommunication standards to provide a common protocol that enables different wireless devices to communicate on a municipal, national, regional, and even global level. An example telecommunication standard is 5G New Radio (NR) . 5G NR is part of a continuous mobile broadband evolution promulgated by Third Generation Partnership Project (3GPP) to meet new requirements associated with latency, reliability, security, scalability (e.g., with Internet of Things (IoT) ) , and other requirements. Some aspects of 5G NR may be based on the 4G Long Term Evolution (LTE) standard. There exists a need for further improvements in 5G NR technology. These improvements may also be applicable to other multi-access technologies and the telecommunication standards that employ these technologies.SUMMARY
[0006] The following presents a simplified summary of one or more aspects in order to provide a basic understanding of such aspects. This summary is not an extensive overview of all contemplated aspects, and is intended to neither identify key or critical elements of all aspects nor delineate the scope of any or all aspects. Its sole purpose is to present some concepts of one or more aspects in a simplified form as a prelude to the more detailed description that is presented later.
[0007] In an aspect of the disclosure, a method, a computer-readable medium, and an apparatus are provided. The apparatus may be a user equipment (UE) . The UE determines to send a Short Message Service (SMS) message over a Non-Access Stratum (NAS) . The UE determines that the SMS message is an emergency SMS message. The UE assigns an emergency access category to the emergency SMS message. This emergency access category is different from a standard access category used for non-emergency SMS messages over NAS. The UE sets a Radio Resource Control (RRC) establishment cause corresponding to the assigned emergency access category. The UE initiates transmission of the emergency SMS message over NAS using the assigned emergency access category or the RRC establishment cause.
[0008] In another aspect of the disclosure, a method, a computer-readable medium, and an apparatus are provided. The apparatus may be a UE. The UE transmits, to a network, a capability indication message indicating support for emergency Short Message Service (SMS) over Non-Access Stratum (NAS) . The capability indication message comprises a mobility management message. The UE receives, from the network, a capability confirmation message indicating network support for emergency SMS over NAS. The UE enables emergency SMS over NAS procedures based on the received capability confirmation message.
[0009] In yet another aspect of the disclosure, a method, a computer-readable medium, and an apparatus are provided. The apparatus may be a UE. The UE receives a request to send an emergency SMS message over a NAS while at least one NAS back-off timer is running. The at least one NAS back-off timer prevents the initiation of NAS procedures for non-emergency services. The UE bypasses the at least one NAS back-off timer for the emergency SMS message over NAS. The UE establishes a NAS signaling connection despite the active state of the at least one NAS back-off timer. The UE then transmits a mobility management message containing the emergency SMS message over NAS
[0010] To the accomplishment of the foregoing and related ends, the one or more aspects comprise the features hereinafter fully described and particularly pointed out in the claims. The following description and the annexed drawings set forth in detail certain illustrative features of the one or more aspects. These features are indicative, however, of but a few of the various ways in which the principles of various aspects may be employed, and this description is intended to include all such aspects and their equivalents.BRIEF DESCRIPTION OF THE DRAWINGS
[0011] FIG. 1 is a diagram illustrating an example of a wireless communications system and an access network.
[0012] FIG. 2 is a diagram illustrating a base station in communication with a UE in an access network.
[0013] FIG. 3 illustrates an example logical architecture of a distributed access network.
[0014] FIG. 4 illustrates an example physical architecture of a distributed access network.
[0015] FIGs. 5 (A) - (D) are a diagram illustrating techniques of handling emergency SMS messages over NAS in wireless communication systems.
[0016] FIG. 6 is a flow chart of a method for handling an emergency short message service message over a non-access stratum.
[0017] FIG. 7 is a flow chart of a method for handling capability negotiation for emergency short message service over non-access stratum.
[0018] FIG. 8 is a flow chart of a method for handling an emergency short message service message over non-access stratum during network congestion.DETAILED DESCRIPTION
[0019] The detailed description set forth below in connection with the appended drawings is intended as a description of various configurations and is not intended to represent the only configurations in which the concepts described herein may be practiced. The detailed description includes specific details for the purpose of providing a thorough understanding of various concepts. However, it will be apparent to those skilled in the art that these concepts may be practiced without these specific details. In some instances, well known structures and components are shown in block diagram form in order to avoid obscuring such concepts.
[0020] Several aspects of telecommunications systems will now be presented with reference to various apparatus and methods. These apparatus and methods will be described in the following detailed description and illustrated in the accompanying drawings by various blocks, components, circuits, processes, algorithms, etc. (collectively referred to as “elements” ) . These elements may be implemented using electronic hardware, computer software, or any combination thereof. Whether such elements are implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system.
[0021] By way of example, an element, or any portion of an element, or any combination of elements may be implemented as a “processing system” that includes one or more processors. Examples of processors include microprocessors, microcontrollers, graphics processing units (GPUs) , central processing units (CPUs) , application processors, digital signal processors (DSPs) , reduced instruction set computing (RISC) processors, systems on a chip (SoC) , baseband processors, field programmable gate arrays (FPGAs) , programmable logic devices (PLDs) , state machines, gated logic, discrete hardware circuits, and other suitable hardware configured to perform the various functionality described throughout this disclosure. One or more processors in the processing system may execute software. Software shall be construed broadly to mean instructions, instruction sets, code, code segments, program code, programs, subprograms, software components, applications, software applications, software packages, routines, subroutines, objects, executables, threads of execution, procedures, functions, etc., whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise.
[0022] Accordingly, in one or more example aspects, the functions described may be implemented in hardware, software, or any combination thereof. If implemented in software, the functions may be stored on or encoded as one or more instructions or code on a computer-readable medium. Computer-readable media includes computer storage media. Storage media may be any available media that can be accessed by a computer. By way of example, and not limitation, such computer-readable media can comprise a random-access memory (RAM) , a read-only memory (ROM) , an electrically erasable programmable ROM (EEPROM) , optical disk storage, magnetic disk storage, other magnetic storage devices, combinations of the aforementioned types of computer-readable media, or any other medium that can be used to store computer executable code in the form of instructions or data structures that can be accessed by a computer.
[0023] FIG. 1 is a diagram illustrating an example of a wireless communications system and an access network 100. The wireless communications system (also referred to as a wireless wide area network (WWAN) ) includes base stations 102, UEs 104, an Evolved Packet Core (EPC) 160, and another core network 190 (e.g., a 5G Core (5GC) ) . The base stations 102 may include macrocells (high power cellular base station) and / or small cells (low power cellular base station) . The macrocells include base stations. The small cells include femtocells, picocells, and microcells.
[0024] The base stations 102 configured for 4G LTE (collectively referred to as Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (E-UTRAN) ) may interface with the EPC 160 through backhaul links 132 (e.g., SI interface) . The base stations 102 configured for 5G NR (collectively referred to as Next Generation RAN (NG-RAN) ) may interface with core network 190 through backhaul links 184. In addition to other functions, the base stations 102 may perform one or more of the following functions: transfer of user data, radio channel ciphering and deciphering, integrity protection, header compression, mobility control functions (e.g., handover, dual connectivity) , inter cell interference coordination, connection setup and release, load balancing, distribution for non-access stratum (NAS) messages, NAS node selection, synchronization, radio access network (RAN) sharing, multimedia broadcast multicast service (MBMS) , subscriber and equipment trace, RAN information management (RIM) , paging, positioning, and delivery of warning messages. The base stations 102 may communicate directly or indirectly (e.g., through the EPC 160 or core network 190) with each other over backhaul links 134 (e.g., X2 interface) . The backhaul links 134 may be wired or wireless.
[0025] The base stations 102 may wirelessly communicate with the UEs 104. Each of the base stations 102 may provide communication coverage for a respective geographic coverage area 110. There may be overlapping geographic coverage areas 110. For example, the small cell 102’ may have a coverage area 110’ that overlaps the coverage area 110 of one or more macro base stations 102. A network that includes both small cell and macrocells may be known as a heterogeneous network. A heterogeneous network may also include Home Evolved Node Bs (eNBs) (HeNBs) , which may provide service to a restricted group known as a closed subscriber group (CSG) . The communication links 120 between the base stations 102 and the UEs 104 may include uplink (UL) (also referred to as reverse link) transmissions from a UE 104 to a base station 102 and / or downlink (DL) (also referred to as forward link) transmissions from a base station 102 to a UE 104. The communication links 120 may use multiple-input and multiple-output (MIMO) antenna technology, including spatial multiplexing, beamforming, and / or transmit diversity. The communication links may be through one or more carriers. The base stations 102 / UEs 104 may use spectrum up to 7 MHz (e.g., 5, 10, 15, 20, 100, 400, etc. MHz) bandwidth per carrier allocated in a carrier aggregation of up to a total of Yx MHz (x component carriers) used for transmission in each direction. The carriers may or may not be adjacent to each other. Allocation of carriers may be asymmetric with respect to DL and UL (e.g., more or fewer carriers may be allocated for DL than for UL) . The component carriers may include a primary component carrier and one or more secondary component carriers. A primary component carrier may be referred to as a primary cell (PCell) and a secondary component carrier may be referred to as a secondary cell (SCell) .
[0026] Certain UEs 104 may communicate with each other using device-to-device (D2D) communication link 158. The D2D communication link 158 may use the DL / UL WWAN spectrum. The D2D communication link 158 may use one or more sidelink channels, such as a physical sidelink broadcast channel (PSBCH) , a physical sidelink discovery channel (PSDCH) , a physical sidelink shared channel (PSSCH) , and a physical sidelink control channel (PSCCH) . D2D communication may be through a variety of wireless D2D communications systems, such as for example, FlashLinQ, WiMedia, Bluetooth, ZigBee, Wi-Fi based on the IEEE 802.11 standard, LTE, or NR.
[0027] The wireless communications system may further include a Wi-Fi access point (AP) 150 in communication with Wi-Fi stations (STAs) 152 via communication links 154 in a 5 GHz unlicensed frequency spectrum. When communicating in an unlicensed frequency spectrum, the STAs 152 / AP 150 may perform a clear channel assessment (CCA) prior to communicating in order to determine whether the channel is available.
[0028] The small cell 102’ may operate in a licensed and / or an unlicensed frequency spectrum. When operating in an unlicensed frequency spectrum, the small cell 102’ may employ NR and use the same 5 GHz unlicensed frequency spectrum as used by the Wi-Fi AP 150. The small cell 102’ , employing NR in an unlicensed frequency spectrum, may boost coverage to and / or increase capacity of the access network.
[0029] A base station 102, whether a small cell 102’ or a large cell (e.g., macro base station) , may include an eNB, gNodeB (gNB) , or another type of base station. Some base stations, such as gNB 180 may operate in a traditional sub 6 GHz spectrum, in millimeter wave (mmW) frequencies, and / or near mmW frequencies in communication with the UE 104. When the gNB 180 operates in mmW or near mmW frequencies, the gNB 180 may be referred to as an mmW base station. Extremely high frequency (EHF) is part of the RF in the electromagnetic spectrum. EHF has a range of 30 GHz to 300 GHz and a wavelength between 1 millimeter and 10 millimeters. Radio waves in the band may be referred to as a millimeter wave. Near mmW may extend down to a frequency of 3 GHz with a wavelength of 100 millimeters. The super high frequency (SHF) band extends between 3 GHz and 30 GHz, also referred to as centimeter wave. Communications using the mmW / near mmW radio frequency band (e.g., 3 GHz -300 GHz) has extremely high path loss and a short range. The mmW base station 180 may utilize beamforming 182 with the UE 104 to compensate for the extremely high path loss and short range.
[0030] The base station 180 may transmit a beamformed signal to the UE 104 in one or more transmit directions 108a. The UE 104 may receive the beamformed signal from the base station 180 in one or more receive directions 108b. The UE 104 may also transmit a beamformed signal to the base station 180 in one or more transmit directions. The base station 180 may receive the beamformed signal from the UE 104 in one or more receive directions. The base station 180 / UE 104 may perform beam training to determine the best receive and transmit directions for each of the base station 180 / UE 104. The transmit and receive directions for the base station 180 may or may not be the same. The transmit and receive directions for the UE 104 may or may not be the same.
[0031] The EPC 160 may include a Mobility Management Entity (MME) 162, other MMEs 164, a Serving Gateway 166, a Multimedia Broadcast Multicast Service (MBMS) Gateway 168, a Broadcast Multicast Service Center (BM-SC) 170, and a Packet Data Network (PDN) Gateway 172. The MME 162 may be in communication with a Home Subscriber Server (HSS) 174. The MME 162 is the control node that processes the signaling between the UEs 104 and the EPC 160. Generally, the MME 162 provides bearer and connection management. All user Internet protocol (IP) packets are transferred through the Serving Gateway 166, which itself is connected to the PDN Gateway 172. The PDN Gateway 172 provides UE IP address allocation as well as other functions. The PDN Gateway 172 and the BM-SC 170 are connected to the IP Services 176. The IP Services 176 may include the Internet, an intranet, an IP Multimedia Subsystem (IMS) , a PS Streaming Service, and / or other IP services. The BM-SC 170 may provide functions for MBMS user service provisioning and delivery. The BM-SC 170 may serve as an entry point for content provider MBMS transmission, may be used to authorize and initiate MBMS Bearer Services within a public land mobile network (PLMN) , and may be used to schedule MBMS transmissions. The MBMS Gateway 168 may be used to distribute MBMS traffic to the base stations 102 belonging to a Multicast Broadcast Single Frequency Network (MBSFN) area broadcasting a particular service, and may be responsible for session management (start / stop) and for collecting eMBMS related charging information.
[0032] The core network 190 may include a Access and Mobility Management Function (AMF) 192, other AMFs 193, a location management function (LMF) 198, a Session Management Function (SMF) 194, and a User Plane Function (UPF) 195. The AMF 192 may be in communication with a Unified Data Management (UDM) 196. The AMF 192 is the control node that processes the signaling between the UEs 104 and the core network 190. Generally, the SMF 194 provides QoS flow and session management. All user Internet protocol (IP) packets are transferred through the UPF 195. The UPF 195 provides UE IP address allocation as well as other functions. The UPF 195 is connected to the IP Services 197. The IP Services 197 may include the Internet, an intranet, an IP Multimedia Subsystem (IMS) , a PS Streaming Service, and / or other IP services.
[0033] The base station may also be referred to as a gNB, Node B, evolved Node B (eNB) , an access point, a base transceiver station, a radio base station, a radio transceiver, a transceiver function, a basic service set (BSS) , an extended service set (ESS) , a transmit reception point (TRP) , or some other suitable terminology. The base station 102 provides an access point to the EPC 160 or core network 190 for a UE 104. Examples of UEs 104 include a cellular phone, a smart phone, a session initiation protocol (SIP) phone, a laptop, a personal digital assistant (PDA) , a satellite radio, a global positioning system, a multimedia device, a video device, a digital audio player (e.g., MP3 player) , a camera, a game console, a tablet, a smart device, a wearable device, a vehicle, an electric meter, a gas pump, a large or small kitchen appliance, a healthcare device, an implant, a sensor / actuator, a display, or any other similar functioning device. Some of the UEs 104 may be referred to as IoT devices (e.g., parking meter, gas pump, toaster, vehicles, heart monitor, etc. ) . The UE 104 may also be referred to as a station, a mobile station, a subscriber station, a mobile unit, a subscriber unit, a wireless unit, a remote unit, a mobile device, a wireless device, a wireless communications device, a remote device, a mobile subscriber station, an access terminal, a mobile terminal, a wireless terminal, a remote terminal, a handset, a user agent, a mobile client, a client, or some other suitable terminology.
[0034] Although the present disclosure may reference 5G New Radio (NR) , the present disclosure may be applicable to other similar areas, such as LTE, LTE-Advanced (LTE-A) , Code Division Multiple Access (CDMA) , Global System for Mobile communications (GSM) , or other wireless / radio access technologies.
[0035] FIG. 2 is a block diagram of a base station 210 in communication with a UE 250 in an access network. In the DL, IP packets from the EPC 160 may be provided to a controller / processor 275. The controller / processor 275 implements layer 3 and layer 2 functionality. Layer 3 includes a radio resource control (RRC) layer, and layer 2 includes a packet data convergence protocol (PDCP) layer, a radio link control (RLC) layer, and a medium access control (MAC) layer. The controller / processor 275 provides RRC layer functionality associated with broadcasting of system information (e.g., MIB, SIBs) , RRC connection control (e.g., RRC connection paging, RRC connection establishment, RRC connection modification, and RRC connection release) , inter radio access technology (RAT) mobility, and measurement configuration for UE measurement reporting; PDCP layer functionality associated with header compression / decompression, security (ciphering, deciphering, integrity protection, integrity verification) , and handover support functions; RLC layer functionality associated with the transfer of upper layer packet data units (PDUs) , error correction through ARQ, concatenation, segmentation, and reassembly of RLC service data units (SDUs) , re-segmentation of RLC data PDUs, and reordering of RLC data PDUs; and MAC layer functionality associated with mapping between logical channels and transport channels, multiplexing of MAC SDUs onto transport blocks (TBs) , demultiplexing of MAC SDUs from TBs, scheduling information reporting, error correction through HARQ, priority handling, and logical channel prioritization.
[0036] The transmit (TX) processor 216 and the receive (RX) processor 270 implement layer 1 functionality associated with various signal processing functions. Layer 1, which includes a physical (PHY) layer, may include error detection on the transport channels, forward error correction (FEC) coding / decoding of the transport channels, interleaving, rate matching, mapping onto physical channels, modulation / demodulation of physical channels, and MIMO antenna processing. The TX processor 216 handles mapping to signal constellations based on various modulation schemes (e.g., binary phase-shift keying (BPSK) , quadrature phase-shift keying (QPSK) , M-phase-shift keying (M-PSK) , M-quadrature amplitude modulation (M-QAM) ) . The coded and modulated symbols may then be split into parallel streams. Each stream may then be mapped to an OFDM subcarrier, multiplexed with a reference signal (e.g., pilot) in the time and / or frequency domain, and then combined together using an Inverse Fast Fourier Transform (IFFT) to produce a physical channel carrying a time domain OFDM symbol stream. The OFDM stream is spatially precoded to produce multiple spatial streams. Channel estimates from a channel estimator 274 may be used to determine the coding and modulation scheme, as well as for spatial processing. The channel estimate may be derived from a reference signal and / or channel condition feedback transmitted by the UE 250. Each spatial stream may then be provided to a different antenna 220 via a separate transmitter 218TX. Each transmitter 218TX may modulate an RF carrier with a respective spatial stream for transmission.
[0037] At the UE 250, each receiver 254RX receives a signal through its respective antenna 252. Each receiver 254RX recovers information modulated onto an RF carrier and provides the information to the receive (RX) processor 256. The TX processor 268 and the RX processor 256 implement layer 1 functionality associated with various signal processing functions. The RX processor 256 may perform spatial processing on the information to recover any spatial streams destined for the UE 250. If multiple spatial streams are destined for the UE 250, they may be combined by the RX processor 256 into a single OFDM symbol stream. The RX processor 256 then converts the OFDM symbol stream from the time-domain to the frequency domain using a Fast Fourier Transform (FFT) . The frequency domain signal comprises a separate OFDM symbol stream for each subcarrier of the OFDM signal. The symbols on each subcarrier, and the reference signal, are recovered and demodulated by determining the most likely signal constellation points transmitted by the base station 210. These soft decisions may be based on channel estimates computed by the channel estimator 258. The soft decisions are then decoded and deinterleaved to recover the data and control signals that were originally transmitted by the base station 210 on the physical channel. The data and control signals are then provided to the controller / processor 259, which implements layer 3 and layer 2 functionality.
[0038] The controller / processor 259 can be associated with a memory 260 that stores program codes and data. The memory 260 may be referred to as a computer-readable medium. In the UL, the controller / processor 259 provides demultiplexing between transport and logical channels, packet reassembly, deciphering, header decompression, and control signal processing to recover IP packets from the EPC 160. The controller / processor 259 is also responsible for error detection using an ACK and / or NACK protocol to support HARQ operations.
[0039] Similar to the functionality described in connection with the DL transmission by the base station 210, the controller / processor 259 provides RRC layer functionality associated with system information (e.g., MIB, SIBs) acquisition, RRC connections, and measurement reporting; PDCP layer functionality associated with header compression / decompression, and security (ciphering, deciphering, integrity protection, integrity verification) ; RLC layer functionality associated with the transfer of upper layer PDUs, error correction through ARQ, concatenation, segmentation, and reassembly of RLC SDUs, re-segmentation of RLC data PDUs, and reordering of RLC data PDUs; and MAC layer functionality associated with mapping between logical channels and transport channels, multiplexing of MAC SDUs onto TBs, demultiplexing of MAC SDUs from TBs, scheduling information reporting, error correction through HARQ, priority handling, and logical channel prioritization.
[0040] Channel estimates derived by a channel estimator 258 from a reference signal or feedback transmitted by the base station 210 may be used by the TX processor 268 to select the appropriate coding and modulation schemes, and to facilitate spatial processing. The spatial streams generated by the TX processor 268 may be provided to different antenna 252 via separate transmitters 254TX. Each transmitter 254TX may modulate an RF carrier with a respective spatial stream for transmission. The UL transmission is processed at the base station 210 in a manner similar to that described in connection with the receiver function at the UE 250. Each receiver 218RX receives a signal through its respective antenna 220. Each receiver 218RX recovers information modulated onto an RF carrier and provides the information to a RX processor 270.
[0041] The controller / processor 275 can be associated with a memory 276 that stores program codes and data. The memory 276 may be referred to as a computer-readable medium. In the UL, the controller / processor 275 provides demultiplexing between transport and logical channels, packet reassembly, deciphering, header decompression, control signal processing to recover IP packets from the UE 250. IP packets from the controller / processor 275 may be provided to the EPC 160. The controller / processor 275 is also responsible for error detection using an ACK and / or NACK protocol to support HARQ operations.
[0042] New radio (NR) may refer to radios configured to operate according to a new air interface (e.g., other than Orthogonal Frequency Divisional Multiple Access (OFDMA) -based air interfaces) or fixed transport layer (e.g., other than Internet Protocol (IP) ) . NR may utilize OFDM with a cyclic prefix (CP) on the uplink and downlink and may include support for half-duplex operation using time division duplexing (TDD) . NR may include Enhanced Mobile Broadband (eMBB) service targeting wide bandwidth (e.g. 80 MHz beyond) , millimeter wave (mmW) targeting high carrier frequency (e.g. 60 GHz) , massive MTC (mMTC) targeting non-backward compatible MTC techniques, and / or mission critical targeting ultra-reliable low latency communications (URLLC) service.
[0043] A single component carrier bandwidth of 100 MHz may be supported. In one example, NR resource blocks (RBs) may span 12 sub-carriers with a sub-carrier bandwidth of 60 kHz over a 0.25 ms duration or a bandwidth of 30 kHz over a 0.5 ms duration (similarly, 50MHz BW for 15kHz SCS over a 1 ms duration) . Each radio frame may consist of 10 subframes (10, 20, 40 or 80 NR slots) with a length of 10 ms. Each slot may indicate a link direction (i.e., DL or UL) for data transmission and the link direction for each slot may be dynamically switched. Each slot may include DL / UL data as well as DL / UL control data. UL and DL slots for NR may be as described in more detail below with respect to FIGs. 5 and 6.
[0044] The NR RAN may include a central unit (CU) and distributed units (DUs) . A NR BS (e.g., gNB, 5G Node B, Node B, transmission reception point (TRP) , access point (AP) ) may correspond to one or multiple BSs. NR cells can be configured as access cells (ACells) or data only cells (DCells) . For example, the RAN (e.g., a central unit or distributed unit) can configure the cells. DCells may be cells used for carrier aggregation or dual connectivity and may not be used for initial access, cell selection / reselection, or handover. In some cases DCells may not transmit synchronization signals (SS) in some cases DCells may transmit SS. NR BSs may transmit downlink signals to UEs indicating the cell type. Based on the cell type indication, the UE may communicate with the NR BS. For example, the UE may determine NR BSs to consider for cell selection, access, handover, and / or measurement based on the indicated cell type.
[0045] FIG. 3 illustrates an example logical architecture of a distributed RAN 300, according to aspects of the present disclosure. A 5G access node 306 may include an access node controller (ANC) 302. The ANC may be a central unit (CU) of the distributed RAN. The backhaul interface to the next generation core network (NG-CN) 304 may terminate at the ANC. The backhaul interface to neighboring next generation access nodes (NG-ANs) 310 may terminate at the ANC. The ANC may include one or more TRPs 308 (which may also be referred to as BSs, NR BSs, Node Bs, 5G NBs, APs, or some other term) . As described above, a TRP may be used interchangeably with “cell. ”
[0046] The TRPs 308 may be a distributed unit (DU) . The TRPs may be connected to one ANC (ANC 302) or more than one ANC (not illustrated) . For example, for RAN sharing, radio as a service (RaaS) , and service specific ANC deployments, the TRP may be connected to more than one ANC. A TRP may include one or more antenna ports. The TRPs may be configured to individually (e.g., dynamic selection) or jointly (e.g., joint transmission) serve traffic to a UE.
[0047] The local architecture of the distributed RAN 300 may be used to illustrate fronthaul definition. The architecture may be defined that support fronthauling solutions across different deployment types. For example, the architecture may be based on transmit network capabilities (e.g., bandwidth, latency, and / or jitter) . The architecture may share features and / or components with LTE. According to aspects, the next generation AN (NG-AN) 310 may support dual connectivity with NR. The NG-AN may share a common fronthaul for LTE and NR.
[0048] The architecture may enable cooperation between and among TRPs 308. For example, cooperation may be preset within a TRP and / or across TRPs via the ANC 302. According to aspects, no inter-TRP interface may be needed / present.
[0049] According to aspects, a dynamic configuration of split logical functions may be present within the architecture of the distributed RAN 300. The PDCP, RLC, MAC protocol may be adaptably placed at the ANC or TRP.
[0050] FIG. 4 illustrates an example physical architecture of a distributed RAN 400, according to aspects of the present disclosure. A centralized core network unit (C-CU) 402 may host core network functions. The C-CU may be centrally deployed. C-CU functionality may be offloaded (e.g., to advanced wireless services (AWS) ) , in an effort to handle peak capacity. A centralized RAN unit (C-RU) 404 may host one or more ANC functions. Optionally, the C-RU may host core network functions locally. The C-RU may have distributed deployment. The C-RU may be closer to the network edge. A distributed unit (DU) 406 may host one or more TRPs. The DU may be located at edges of the network with radio frequency (RF) functionality.
[0051] In modern wireless communication systems compliant with 5G standards, User Equipment (UE) must follow specific procedures to access network services through a mechanism known as Unified Access Control (UAC) . The UAC framework manages network access to prevent overload, particularly during periods of high congestion, and governs how a UE initiates communication with the network for various services. When a UE needs to access the 5G System (5GS) , and the UE is not operating as an integrated access and backhaul (IAB) node, not acting as a 5G proximity-based services (ProSe) layer-2 UE-to-network relay UE triggered by a remote UE, and not functioning as a network-controlled repeater mobile termination (NCR-MT) node, it first performs access control checks to determine if the access is allowed.
[0052] One service governed by these procedures is the transmission of mobile-originated (MO) Short Message Service (SMS) messages over the Non-Access Stratum (NAS) . The NAS is a functional layer in the protocol stack between the UE and the core network that handles signaling and traffic management independently of the radio access technology. According to current 3rd Generation Partnership Project (3GPP) standards, specific access control checks must be performed when a UE in 5GMM-CONNECTED mode over 3GPP access, or in 5GMM-CONNECTED mode with Radio Resource Control (RRC) inactive indication, receives a request from upper layers to send a mobile originated SMS over NAS, unless that request triggers a service request procedure to transition the UE from 5GMM-IDLE mode or 5GMM-IDLE mode with suspend indication to 5GMM-CONNECTED mode.
[0053] The determination of access categories for such requests follows predefined mapping tables established in the standards. For MO SMS over NAS, the access attempt is classified under standardized access category 7, which encompasses MO SMS over NAS, MO SMS over IP (SMSoIP) transfer, mobile terminated (MT) SMS over SMSoIP, and NAS signaling connection recovery during ongoing MO SMS or SMSoIP transfer or ongoing MT multimedia telephony (MMTel) video calls. This standardized access category 7 then maps to an underlying access category value of 6, which is labeled as "MO SMS and SMSoIP" for purposes of RRC establishment cause determination.
[0054] Once the underlying access category is determined, it is used to derive the Radio Resource Control (RRC) establishment cause that will be signaled to the radio access network. The RRC establishment cause informs the network of the reason for the UE’s request to establish or modify a connection. According to the mapping table for access identities and access categories when establishing N1 NAS signaling connections via new radio (NR) connected to the 5G core network (5GCN) , when access identity 0 is used with underlying access category 6 (MO SMS and SMSoIP) , the RRC establishment cause is set to "mo-SMS" .
[0055] When the lower layers indicate that an access attempt is allowed for a request to send mobile originated SMS over NAS, the 5G Mobility Management (5GMM) layer initiates the NAS transport procedure to send the SMS in an uplink (UL) NAS TRANSPORT message. Conversely, if the lower layers indicate that the access attempt is barred due to network congestion or other access control policies, the 5GMM layer must not initiate the NAS transport procedure. The UE must then wait until it receives an indication from lower layers that the barring for the associated access category has been alleviated before it can re-attempt to send the SMS message, if still needed.
[0056] The existing UAC framework provides special handling for certain types of services to avoid double barring and manage exceptions during ongoing services. These services include emergency service, MMTel voice, MMTel video, SMSoIP, SMS over NAS, 5G Core mobile originated location request (5GC-MO-LR) procedures, UE-requested policy provisioning procedures for vehicle-to-everything (V2XP) or proximity services policy (ProSeP) , and cellular internet of things (CIoT) user data transfer over the control plane. While an SMS over NAS is ongoing without concurrent SMSoIP, MMTel video call, or MMTel voice call, any service request or registration procedure initiated in 5GMM-IDLE mode or 5GMM-IDLE mode with suspend indication for NAS signaling connection recovery or following a fallback indication from lower layers is mapped to access category 6.
[0057] For emergency services, the standards define a separate high-priority handling mechanism. An access attempt for an emergency session is mapped to standardized access category 2, which corresponds to underlying access category 2 labeled as "emergency" . This emergency access category then maps to an RRC establishment cause of "emergency" , providing preferential treatment and allowing such services to bypass certain restrictions that would apply to normal services. The emergency category includes 5GMM specific procedures while the emergency service is ongoing and 5GMM connection management procedures required to establish a PDU session with request type set to "initial emergency request" or "existing emergency PDU session" . However, the current standards treat all SMS transmissions over NAS uniformly as non-emergency services, making no distinction between a regular SMS message and an SMS message sent to an emergency number.
[0058] FIGs. 5 (A) - (D) are a diagram 500 illustrating techniques of handling emergency SMS messages over NAS in current 5G and future 6G wireless communication systems. The diagram 500 depicts a UE 502 attempting to communicate with a network comprising a base station 504 (such as a gNB) and core network functions 506 (such as an AMF) . The figure highlights three fundamental problems that prevent emergency SMS messages from receiving appropriate priority treatment in the current 3GPP standards.
[0059] The first problem involves undefined capability negotiation 512. Current specifications provide no method for the UE 502 to indicate its support for emergency SMS over NAS functionality to the network, nor for the network to signal such capability back to the UE 502. Without this mutual capability discovery, the UE 502 cannot determine whether the network will recognize and properly handle an emergency SMS differently from a regular SMS message. This lack of capability negotiation forces the UE 502 to treat all SMS transmissions uniformly, regardless of their emergency nature.
[0060] The second problem concerns the undefined behavior for access category determination when handling emergency SMS messages. When upper layers of the UE 502 request transmission of an SMS to an emergency number, the UE 502 must determine an appropriate access category for the access attempt. The network provides local emergency numbers to the UE 502 after registration, allowing the UE 502 to identify when a destination number corresponds to an emergency service. However, the current standards do not define how the UE 502 should handle this emergency SMS scenario. The UE 502 lacks guidance on whether to use the standard access category 6 (designated for MO SMS and SMSoIP) or the emergency access category 2. This ambiguity extends to the RRC establishment cause determination 514, where the UE 502 cannot determine whether to signal "mo-SMS" or "emergency" as the reason for the connection request. Consequently, an SMS message destined for an emergency number like 911 receives the same treatment as any regular SMS, using access category 6 and RRC establishment cause "mo-SMS" rather than receiving emergency priority.
[0061] The third problem relates to congestion handling during network overload conditions. The diagram 500 shows a congestion condition 516 affecting the network path between the UE 502 and the base station 504. When the network experiences congestion, it activates back-off timers such as T3346 for mobility management congestion control or T3447 for session management congestion control. These timers, represented as active back-off timer states 518, prevent the UE 502 from initiating new NAS procedures for non-emergency services. The undefined congestion handling behavior 520 for emergency SMS means that when these back-off timers are running, the UE 502 treats an emergency SMS request the same as a regular SMS request. Under current rules, the UE 502 must respect these timers and refrain from sending any SMS messages, resulting in a blocked transmission path 522 for the emergency SMS.
[0062] This blocking effect is particularly problematic during large-scale emergencies when network congestion is most likely to occur. While the standards provide exceptions allowing emergency voice calls to bypass back-off timers through their assignment to access category 2, no such exception exists for emergency SMS messages. The UE 502 therefore cannot transmit critical emergency information via SMS precisely when network resources are constrained and voice communication might not be feasible. This gap in the standards affects users who rely on text-based emergency communication, including those who are deaf or hard of hearing, or individuals in situations where making a voice call would be dangerous or impossible.
[0063] The combination of these three problems creates a significant public safety gap in the 5G and future 6G systems. Without capability negotiation, proper access categorization, and congestion bypass mechanisms, emergency SMS messages sent over NAS cannot receive the priority treatment necessary for reliable delivery during critical situations. The current standards’ uniform treatment of all SMS messages, regardless of their emergency nature, fails to meet the requirements for robust emergency communication services that modern wireless networks must provide.
[0064] Further, referring to FIGs. 5 (A) - (D) , the present disclosure addresses the problem of undefined capability negotiation 512 for emergency SMS over NAS by introducing comprehensive mechanisms for the UE 502 and the network to discover and confirm mutual support for this feature. As described above, without these mechanisms, the UE 502 cannot determine whether the network will recognize and properly handle an emergency SMS differently from a regular SMS message, forcing uniform treatment of all SMS transmissions regardless of their emergency nature.
[0065] The present disclosure proposes two complementary approaches for capability negotiation: dynamic explicit signaling and pre-configuration methods. In the dynamic signaling approach, the UE 502 initiates the capability discovery by transmitting a capability indication message 524 to the core network functions 506 through the base station 504. This capability indication message 524 can be implemented using existing Mobility Management (MM) protocol messages that are already part of the standard communication flow between the UE 502 and the network. The specific MM protocol layer can be 6GMM for sixth-generation systems, 5GMM for fifth-generation systems, or EMM for evolved packet system, providing backward compatibility across different network generations.
[0066] The capability indication message 524 can take the form of a REGISTRATION REQUEST message when the UE 502 is performing initial registration or mobility registration update procedures. Alternatively, it can be a SERVICE REQUEST message when the UE 502 needs to establish a signaling connection for emergency SMS transmission, or an ATTACH REQUEST message in legacy systems. Within these existing message structures, the UE 502 includes a capability indicator 526 that signals its support for emergency SMS over NAS. The capability indicator 526 can be implemented as a new bit added to an existing Information Element (IE) within the message, minimizing the impact on current message formats. Alternatively, the capability indicator 526 can be a completely new IE added to the message structure, providing more flexibility for future enhancements and additional capability parameters.
[0067] Upon receiving the capability indication message 524, the core network functions 506 process the capability indicator 526 to determine the UE’s support for emergency SMS over NAS. If the network also supports this feature, it responds with a capability confirmation message 528 transmitted back to the UE 502. The capability confirmation message 528 follows a similar implementation pattern, utilizing existing network-to-UE messages such as REGISTRATION ACCEPT, SERVICE ACCEPT, CONFIGURATION UPDATE COMMAND, or ATTACH ACCEPT. The network’s confirmation is conveyed through a network capability indicator 530, which can be implemented as either a new bit within an existing IE or as a new IE within these response messages.
[0068] This bidirectional exchange establishes a capability negotiation handshake 532 between the UE 502 and the network, creating mutual awareness of emergency SMS over NAS support. The capability negotiation handshake 532 allows both entities to align their behavior and activate the special handling procedures for emergency SMS messages. Once completed, this negotiation remains valid for the duration of the registration or until explicitly updated through subsequent signaling exchanges.
[0069] As an alternative or complementary approach, the present disclosure provides pre-configuration methods that allow the UE 502 to determine its emergency SMS over NAS capability without requiring runtime negotiation. These methods are particularly useful in deployments where emergency SMS support is mandated by regulation or where dynamic signaling overhead needs to be minimized. The pre-configuration can be implemented through a USIM configuration 534 stored in the Universal Subscriber Identity Module of the UE 502. The USIM configuration 534 contains provisioning data that indicates whether the emergency SMS over NAS feature is enabled for the subscriber, allowing the UE 502 to activate the feature immediately upon power-on or USIM insertion.
[0070] Another pre-configuration method involves a Management Object (MO) configuration 536 delivered through device management protocols. The MO configuration 536, which can specifically be a NAS Management Object, allows network operators to remotely provision and update the emergency SMS over NAS capability on deployed devices. This approach provides flexibility for operators to enable the feature across their device fleet without requiring USIM updates or device replacement. The MO configuration 536 can be delivered using Open Mobile Alliance Device Management (OMA-DM) protocols or similar device management frameworks.
[0071] Additionally, the emergency SMS over NAS capability can be enabled through secure packet delivery 538, where configuration information is transmitted to the UE 502 via secure channels such as SMS messages. The secure packet delivery 538 method allows for dynamic updates to device capabilities without requiring full device management infrastructure. The configuration data delivered through these secure packets is authenticated and integrity-protected to prevent unauthorized modification of emergency service capabilities.
[0072] When the UE 502 determines that the emergency SMS over NAS feature is enabled through any of these pre-configuration methods-the USIM configuration 534, the MO configuration 536, or the secure packet delivery 538-it is authorized to use the emergency SMS over NAS procedures without first performing explicit capability negotiation with the network. This pre-configured state 540 allows the UE 502 to immediately treat SMS messages to emergency numbers with appropriate priority, reducing latency in emergency situations. The pre-configuration methods work in conjunction with the dynamic signaling approach, where pre-configured devices can still perform capability negotiation to confirm network support and maintain alignment with network capabilities.
[0073] Further referring to FIGs. 5 (A) - (D) , the present disclosure addresses the problem of undefined access category determination for emergency SMS messages over NAS. As described above, in current standards, when the UE 502 needs to send an SMS message over NAS, it uniformly applies access category 6 designated for MO SMS and SMSoIP, regardless of whether the destination is an emergency number. This creates an undefined access category mapping situation where emergency SMS messages receive no priority treatment. The present disclosure resolves this problem by introducing specific procedures for proper classification and prioritization of emergency SMS transmissions.
[0074] When upper layers of the UE 502 generate a request for emergency SMS over NAS, the UE 502 first performs an emergency detection process 556. This detection occurs when the UE 502 identifies that the destination number matches one of the local emergency numbers provided by the core network functions 506 after registration. Upon detecting that the SMS is destined for an emergency number, the UE 502 initiates an emergency SMS classification procedure 558 that changes how the access attempt is handled compared to regular SMS messages.
[0075] The emergency SMS classification procedure 558 involves multiple coordinated operations that transform the standard SMS handling into emergency service handling. First, the UE 502 determines an access attempt type 560 for the transmission. Instead of treating this as a regular mobile-originated service, the UE 502 classifies the access attempt type 560 as "emergency" . Alternatively, the standards may define a new access attempt type specifically for emergency SMS over NAS, providing granular control over this specific service type while maintaining backward compatibility with existing emergency services.
[0076] Based on this emergency classification, the UE 502 performs an access category assignment 562 that overrides the default category 6 normally used for SMS services. The primary approach involves assigning the emergency SMS to access category 2, which is the existing category designated for emergency services in current standards. This assignment allows the emergency SMS to inherit all the priority treatment and network resource allocation associated with emergency services. As an alternative implementation, the standards may introduce a new dedicated access category specifically for emergency SMS over NAS, such as "MO emergency SMS" , providing flexibility for networks to handle emergency text messages with specific policies while maintaining the high-priority nature of the service.
[0077] Following the access category assignment 562, the UE 502 determines an RRC establishment cause 564 that corresponds to the selected access category. When using access category 2, the RRC establishment cause 564 is set to "emergency" , clearly signaling to the base station 504 that this connection request is for emergency services. If a new dedicated access category for emergency SMS is introduced, a corresponding new RRC establishment cause may be defined, such as "emergency-SMS" , providing explicit identification of the service type to the radio access network. This RRC establishment cause 564 replaces the standard "mo-SMS" cause that would otherwise be used for regular SMS transmissions.
[0078] The present disclosure defines that emergency SMS over NAS service is handled and considered similar to other emergency services within the network. This similarity in handling means that the emergency SMS inherits various priority mechanisms and exceptions that apply to emergency services. An aspect of this handling involves a barring check procedure 566 performed by the UE 502. The UE 502 is allowed to initiate procedures for emergency SMS over NAS if the selected access category, whether category 2 or a newly introduced emergency SMS category, is determined not to be barred by the network. Furthermore, even if the category was previously barred, the UE 502 can proceed once it receives an indication that the barring has been alleviated. This behavior contrasts sharply with regular SMS handling, where the UE 502 must strictly respect access barring for category 6.
[0079] The present disclosure also establishes an emergency procedure lifecycle management 568 that defines clear boundaries for when the emergency context is active. The UE 502 considers an emergency service procedure as started when the 5GMM layer, or any applicable mobility management layer such as 6GMM or EMM, receives a request from upper layers to send emergency SMS over NAS. This marks the beginning of the emergency context, during which all the priority handling and special exceptions apply. The emergency procedure lifecycle management 568 maintains this emergency context throughout the entire transmission process.
[0080] The UE 502 considers the emergency service procedure as stopped based on specific termination criteria defined in the emergency procedure lifecycle management 568. The procedure ends when the emergency SMS over NAS procedure is completed successfully, indicating that the message has been transmitted and acknowledged by the network. Alternatively, the procedure stops when the network resources allocated for the emergency SMS transmission are released, when the signaling connection established specifically for the emergency SMS over NAS is released by either the UE 502 or the network, or when the UE 502 transitions to IDLE mode. These clear termination criteria prevent the UE 502 from maintaining emergency priority indefinitely and allow proper resource management within the network.
[0081] Through this comprehensive access category and classification framework, the present disclosure transforms emergency SMS from an undefined service into a properly prioritized emergency communication method. The combination of the emergency detection process 556, the emergency SMS classification procedure 558, the access attempt type 560 determination, the access category assignment 562, the RRC establishment cause 564 selection, the barring check procedure 566, and the emergency procedure lifecycle management 568 creates a solution that places emergency SMS messages on equal priority footing with emergency voice calls, addressing a critical gap in current wireless communication standards.
[0082] Further referring to FIGs. 5 (A) - (D) , the present disclosure addresses the critical problem of undefined congestion handling for emergency SMS messages over NAS. As described above, when the network experiences a congestion condition 516, it activates NAS back-off timers such as T3346 for mobility management congestion control or T3447 for session management congestion control. These timers, represented as active back-off timer states 518, prevent the UE 502 from initiating new NAS procedures under normal circumstances. In current standards, these restrictions apply uniformly to all SMS messages, creating a blocked transmission path 522 that prevents emergency SMS transmission precisely when emergency communication is most critical. The present disclosure introduces specific mechanisms that allow the UE 502 to bypass these congestion controls for emergency SMS over NAS.
[0083] When the UE 502 receives a request from upper layers for emergency SMS over NAS, or when the UE 502 is attempting to send such a message while the NAS back-off timers are running, the UE 502 initiates an emergency congestion override procedure 590. The emergency congestion override procedure 590 represents the primary solution for handling emergency SMS during network congestion and consists of two coordinated operations that work together to establish communication with the network despite the active congestion controls.
[0084] The first operation within the emergency congestion override procedure 590 allows the UE 502 to establish a NAS signaling connection 592 with the base station 504 and the core network functions 506. This establishment of the NAS signaling connection 592 creates an explicit exception to the standard back-off timer restrictions. While regular SMS messages must wait until the expiration of timers such as T3346 or T3447, the emergency SMS over NAS is permitted to immediately initiate connection establishment procedures. This behavior parallels the exception already granted to emergency voice calls in existing standards, extending similar priority treatment to emergency text communications.
[0085] The second operation involves the transmission of emergency mobility management messages to carry the emergency SMS. Once the NAS signaling connection 592 is established, the UE 502 is authorized to send an xMM message 594 to the network, where xMM represents the applicable mobility management protocol layer. The specific protocol depends on the network generation: EMM for Evolved Packet System, 5GMM for fifth-generation systems, or 6GMM for sixth-generation systems. The xMM message 594 can take several forms depending on the current state of the UE 502 and the specific network procedures required. When the emergency SMS payload needs to be transported directly, the UE 502 sends an UL NAS TRANSPORT message containing the SMS data. If the UE 502 needs to perform registration procedures to support the emergency transmission, it sends a REGISTRATION REQUEST message. For service activation in connected mode, the UE 502 uses a SERVICE REQUEST message. In legacy network scenarios or initial network attachment, the UE 502 may send an ATTACH REQUEST message.
[0086] The combination of establishing the NAS signaling connection 592 and transmitting the xMM message 594 constitutes the primary solution for emergency SMS congestion handling. This approach transforms the previously blocked transmission path 522 into an emergency transmission path 596 that bypasses the congestion restrictions. The emergency transmission path 596 provides a dedicated channel for emergency SMS delivery that operates independently of the general congestion control mechanisms affecting regular traffic.
[0087] In addition to the primary solution, the present disclosure defines a fallback mechanism 598 that provides resilience when the emergency congestion override procedure 590 cannot successfully complete the SMS transmission. The fallback mechanism 598 is triggered when the UE 502 encounters persistent failures in establishing the NAS signaling connection 592 or transmitting the xMM message 594, such as due to severe radio link conditions or complete network unavailability. When such failures occur, the NAS layer of the UE 502 generates a failure notification 600 to inform the upper layers that the emergency SMS over NAS procedure has failed.
[0088] Upon receiving the failure notification 600, the upper layers of the UE 502 activate alternative domain selection 602 to attempt emergency SMS delivery through other available communication paths. The alternative domain selection 602 evaluates and attempts transmission through multiple fallback options. The UE 502 may attempt to send the emergency SMS through a Circuit-Switched (CS) domain 604 using traditional circuit-switched SMS mechanisms if available. Alternatively, the UE 502 may utilize an IMS domain 606 to transmit the message as SMS over IP (SMSoIP) , using packet-switched voice infrastructure for text delivery. As another option, the UE 502 may employ an alternative IP-CAN 608 such as Wi-Fi connectivity to route the emergency SMS through non-cellular internet connections.
[0089] The fallback mechanism 598 operates sequentially or in parallel based on the availability of alternative domains and the urgency of the emergency communication. Each alternative domain provides an independent path for emergency SMS delivery, maximizing the probability of successful transmission even when the primary NAS-based path is unavailable. This multi-layered approach, combining the emergency congestion override procedure 590 as the primary solution with the fallback mechanism 598 as a secondary option, creates a robust framework for emergency SMS delivery that adapts to varying network conditions and maintains service availability during critical situations.
[0090] FIG. 6 is a flow chart 600 of a method for handling an emergency SMS message over an NAS. The method may be performed by a UE (e.g., the UE 104, 250, or 502) . In operation 602, the UE determines to send an SMS message over a NAS. In operation 604, the UE determines that the SMS message is an emergency SMS message. In certain implementations, to determine that the SMS message is an emergency SMS message, the UE compares a destination number of the SMS message with local emergency numbers provided by a network after registration.
[0091] In operation 606, the UE assigns an emergency access category to the emergency SMS message. The emergency access category is different from a standard access category used for non-emergency SMS messages over NAS. In certain implementations, the emergency access category is access category 2 designated for emergency services. In certain implementations, the emergency access category is a newly defined access category specifically for emergency SMS over NAS.
[0092] In operation 608, the UE sets an RRC establishment cause corresponding to the assigned emergency access category. In certain implementations, the RRC establishment cause is set to indicate an emergency scenario when the emergency access category is assigned. In certain implementations, the RRC establishment cause is set to one of: "emergency" or a defined RRC establishment cause for emergency SMS over NAS.
[0093] In operation 610, the UE initiates transmission of the emergency SMS message over NAS using the assigned emergency access category or the RRC establishment cause. In certain implementations, to initiate transmission of the emergency SMS message, the UE treats the emergency SMS message with similar priority handling as other emergency services, including priority resource allocation and network admission control exceptions.
[0094] In certain implementations, the UE performs an access barring check for the assigned emergency access category. The UE proceeds with the transmission when the emergency access category is determined to be not barred or when barring is alleviated.
[0095] In certain implementations, the UE manages an emergency procedure lifecycle. The emergency procedure is considered started when a mobility management layer receives a request to send the emergency SMS message. The emergency procedure is considered stopped when at least one of: an emergency SMS procedure is completed, resources allocated for the emergency SMS message are released, a signaling connection established for the emergency SMS message is released, or the UE enters an IDLE mode.
[0096] FIG. 7 is a flow chart 700 of a method for handling capability negotiation for emergency SMS over NAS. The method may be performed by a UE (e.g., the UE 104, UE 250, or UE 502) . In operation 702, the UE transmits, to a network, a capability indication message indicating support for emergency SMS over NAS. The capability indication message comprises a mobility management message. In operation 704, the UE receives, from the network, a capability confirmation message indicating network support for emergency SMS over NAS. In operation 706, the UE enables emergency SMS over NAS procedures based on the received capability confirmation message.
[0097] In certain implementations, the capability indication message comprises one of: a REGISTRATION REQUEST message, a SERVICE REQUEST message, or an ATTACH REQUEST message. The capability indication message includes a capability indicator implemented as at least one of: a dedicated bit in an existing Information Element (IE) or a dedicated IE.
[0098] In certain implementations, the capability confirmation message comprises one of: a REGISTRATION ACCEPT message, a SERVICE ACCEPT message, a CONFIGURATION UPDATE COMMAND message, or an ATTACH ACCEPT message.
[0099] In certain implementations, the UE determines emergency SMS over NAS support through a pre-configuration stored in the UE. The pre-configuration is provided via at least one of: a Universal Subscriber Identity Module (USIM) configuration, a Management Object (MO) configuration, or a secure packet delivery.
[0100] FIG. 8 is a flow chart 800 of a method for handling an emergency SMS message over NAS during network congestion. The method may be performed by a UE (e.g., the UE 104, 250, or 502) . In operation 802, the UE receives a request to send an emergency SMS message over NAS while at least one NAS back-off timer is running. The at least one NAS back-off timer prevents initiation of NAS procedures for non-emergency services. In operation 804, the UE bypasses the at least one NAS back-off timer for the emergency SMS message over NAS. In operation 806, the UE establishes a NAS signaling connection despite the at least one NAS back-off timer being active. In operation 808, the UE transmits a mobility management message containing the emergency SMS message over NAS.
[0101] In certain implementations, the at least one NAS back-off timer includes at least one of: a T3346 timer for mobility management congestion control or a T3447 timer for session management congestion control.
[0102] In certain implementations, the mobility management message is one of: an UL NAS TRANSPORT message, a REGISTRATION REQUEST message, a SERVICE REQUEST message, or an ATTACH REQUEST message.
[0103] In certain implementations, to transmit the mobility management message, the UE uses one of: an EMM protocol, a 5GMM protocol, or a 6GMM protocol.
[0104] In certain implementations, the UE detects a failure to transmit the emergency SMS message over NAS. Upon detecting the failure, the UE generates a failure notification to upper layers and attempts to transmit the emergency SMS message through an alternative domain. The alternative domain includes at least one of: a CS domain, an IMS domain for SMSoIP, or an alternative IP-CAN. In some of these implementations, the alternative IP-CAN is a Wi-Fi network.
[0105] The UE 502, as well as the UE configured to perform the methods illustrated in the flow charts 600, 700, and 800 of FIGs. 6-8, may be implemented with a hardware architecture similar to that of the UE 250 depicted in FIG. 2. The core functionality for handling emergency Short Message Service (SMS) messages over a Non-Access Stratum (NAS) as disclosed herein may be implemented by the controller / processor 259, operating in conjunction with instructions and data stored in the memory 260. The memory 260, which may be a computer-readable medium, stores the program codes that, when executed by the controller / processor 259, configure the UE to perform the novel procedures for capability negotiation, access category assignment, and congestion handling for emergency SMS over NAS.
[0106] Specifically, the controller / processor 259 is configured to execute the operations described in the solutions and flowcharts. For example, the controller / processor 259 determines that an SMS message is an emergency SMS message (operation 604) , assigns an emergency access category (e.g., access category 2) and a corresponding Radio Resource Control (RRC) establishment cause (e.g., “emergency” ) (operations 606, 608) , and initiates transmission. For capability negotiation (FIG. 7) , the controller / processor 259 generates capability indication messages (e.g., a REGISTRATION REQUEST) and processes received capability confirmation messages. For congestion handling (FIG. 8) , the controller / processor 259 is configured to bypass NAS back-off timers (e.g., T3346) by establishing a NAS signaling connection (operation 806) and transmitting a mobility management message (operation 808) . The physical transmission and reception of these messages are handled by the TX processor 268, transmitters 254TX, RX processor 256, receivers 254RX, and antennas 252, under the control of the controller / processor 259.
[0107] It is understood that the specific order or hierarchy of blocks in the processes / flowcharts disclosed is an illustration of exemplary approaches. Based upon design preferences, it is understood that the specific order or hierarchy of blocks in the processes / flowcharts may be rearranged. Further, some blocks may be combined or omitted. The accompanying method claims present elements of the various blocks in a sample order, and are not meant to be limited to the specific order or hierarchy presented.
[0108] The previous description is provided to enable any person skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects. Thus, the claims are not intended to be limited to the aspects shown herein, but is to be accorded the full scope consistent with the language claims, wherein reference to an element in the singular is not intended to mean “one and only one” unless specifically so stated, but rather “one or more. ” The word “exemplary” is used herein to mean “serving as an example, instance, or illustration. ” Any aspect described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects. Unless specifically stated otherwise, the term “some” refers to one or more. Combinations such as “at least one of A, B, or C, ” “one or more of A, B, or C, ” “at least one of A, B, and C, ” “one or more of A, B, and C, ” and “A, B, C, or any combination thereof” include any combination of A, B, and / or C, and may include multiples of A, multiples of B, or multiples of C. Specifically, combinations such as “at least one of A, B, or C, ” “one or more of A, B, or C, ” “at least one of A, B, and C, ” “one or more of A, B, and C, ” and “A, B, C, or any combination thereof” may be A only, B only, C only, A and B, A and C, B and C, or A and B and C, where any such combinations may contain one or more member or members of A, B, or C. All structural and functional equivalents to the elements of the various aspects described throughout this disclosure that are known or later come to be known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the claims. Moreover, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the claims. The words “module, ” “mechanism, ” “element, ” “device, ” and the like may not be a substitute for the word “means. ” As such, no claim element is to be construed as a means plus function unless the element is expressly recited using the phrase “means for. ”
Claims
1.A method of wireless communication of a user equipment (UE) , comprising:determining to send a Short Message Service (SMS) message over a Non-Access Stratum (NAS) ;determining that the SMS message is an emergency SMS message;assigning an emergency access category to the emergency SMS message, wherein the emergency access category is different from a standard access category used for non-emergency SMS messages over NAS;setting a Radio Resource Control (RRC) establishment cause corresponding to the assigned emergency access category; andinitiating transmission of the emergency SMS message over NAS using the assigned emergency access category or the RRC establishment cause.2.The method of claim 1, wherein determining that the SMS message is an emergency SMS message comprises:comparing a destination number of the SMS message with local emergency numbers provided by a network after registration.3.The method of claim 1, wherein the emergency access category is access category 2 designated for emergency services.4.The method of claim 1, wherein the emergency access category is a newly defined access category specifically for emergency SMS over NAS.5.The method of claim 1, wherein the RRC establishment cause is set to indicate an emergency scenario when the emergency access category is assigned.6.The method of claim 5, wherein the RRC establishment cause is set to one of: "emergency" or a defined RRC establishment cause for emergency SMS over NAS.7.The method of claim 1, further comprising:performing an access barring check for the assigned emergency access category; andproceeding with the transmission when the emergency access category is determined to be not barred or when barring is alleviated.8.The method of claim 1, further comprising:managing an emergency procedure lifecycle, wherein: the emergency procedure is considered started when a mobility management layer receives a request to send the emergency SMS message; and the emergency procedure is considered stopped when at least one of: an emergency SMS procedure is completed, resources allocated for the emergency SMS message are released, a signaling connection established for the emergency SMS message is released, or the UE enters an IDLE mode.9.The method of claim 1, wherein initiating transmission of the emergency SMS message comprises:treating the emergency SMS message with similar priority handling as other emergency services, including priority resource allocation and network admission control exceptions.10.A method of wireless communication of a user equipment (UE) , comprising:transmitting, by the UE to a network, a capability indication message indicating support for emergency Short Message Service (SMS) over Non-Access Stratum (NAS) , wherein the capability indication message comprises a mobility management message;receiving, from the network, a capability confirmation message indicating network support for emergency SMS over NAS; andenabling emergency SMS over NAS procedures based on the received capability confirmation message.11.The method of claim 10, wherein the capability indication message comprises one of: a REGISTRATION REQUEST message, a SERVICE REQUEST message, or an ATTACH REQUEST message.12.The method of claim 10, wherein the capability indication message includes a capability indicator implemented as at least one of: a dedicated bit in an existing Information Element (IE) or a dedicated IE.13.The method of claim 10, wherein the capability confirmation message comprises one of: a REGISTRATION ACCEPT message, a SERVICE ACCEPT message, a CONFIGURATION UPDATE COMMAND message, or an ATTACH ACCEPT message.14.The method of claim 10, further comprising:determining emergency SMS over NAS support through a pre-configuration stored in the UE, wherein the pre-configuration is provided via at least one of: a Universal Subscriber Identity Module (USIM) configuration, a Management Object (MO) configuration, or a secure packet delivery.15.A method of wireless communication of a user equipment (UE) , comprising:receiving a request to send an emergency Short Message Service (SMS) message over Non-Access Stratum (NAS) while at least one NAS back-off timer is running, wherein the at least one NAS back-off timer prevents initiation of NAS procedures for non-emergency services;bypassing the at least one NAS back-off timer for the emergency SMS message over NAS;establishing a NAS signaling connection despite the at least one NAS back-off timer being active; andtransmitting a mobility management message containing the emergency SMS message over NAS.16.The method of claim 15, wherein the at least one NAS back-off timer comprises at least one of: a T3346 timer for mobility management congestion control or a T3447 timer for session management congestion control.17.The method of claim 15, wherein the mobility management message comprises one of: an uplink (UL) NAS TRANSPORT message, a REGISTRATION REQUEST message, a SERVICE REQUEST message, or an ATTACH REQUEST message.18.The method of claim 15, wherein the mobility management message is transmitted using one of: an Evolved Packet System Mobility Management (EMM) protocol, a 5G Mobility Management (5GMM) protocol, or a 6G Mobility Management (6GMM) protocol.19.The method of claim 15, further comprising:detecting a failure to transmit the emergency SMS message over NAS;generating a failure notification to upper layers; andattempting to transmit the emergency SMS message through an alternative domain.20.The method of claim 19, wherein the alternative domain comprises at least one of: a Circuit-Switched (CS) domain, an IP Multimedia Subsystem (IMS) domain for SMS over IP (SMSoIP) , or an alternative IP-Connectivity Access Network (IP-CAN) .21.The method of claim 20, wherein the alternative IP-CAN comprises a Wi-Fi network.
Citation Information
Patent Citations
Short message service capability updating method, equipment and device
CN110392369A
Support of emergency short message service messages
EP4322563A1
System and method for packetized emergency messages
US20110189971A1
Secure short message service over non-access stratum
US20190037407A1