6g NTN -resilient notification

Abstract

In an aspect of the disclosure, a method, a computer-readable medium, and an apparatus are provided. The apparatus may be a UE. The UE transmits a mobility management message to a network. The mobility management message comprises an indication that the UE supports a resilient notification feature for receiving notifications about missed mobile-terminated (MT) communications in a non-terrestrial network (NTN). The UE receives a response message from the network. The response message comprises an indication that the network supports the resilient notification feature.

Description

6G NTN -RESILIENT NOTIFICATIONCROSS-REFERENCE TO RELATED APPLICATION (S)

[0001] The application claims priority to Indian Patent Application Serial No. 202421088168, entitled “NTN -RESILIENT NOTIFICATION” and filed on November 14, 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 providing resilient notifications for missed mobile-terminated communications in non-terrestrial network environments. 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 UE. The UE transmits a mobility management message to a network. The mobility management message comprises an indication that the UE supports a resilient notification feature for receiving notifications about missed mobile-terminated (MT) communications in a non-terrestrial network (NTN) . The UE receives a response message from the network. The response message comprises an indication that the network supports the resilient notification feature.

[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 determines that a resilient notification feature is enabled based on configuration data provisioned through at least one of a management object (MO) , data stored in a universal subscriber identity module (USIM) , or a secure packet. In response to this determination, the UE enables support for the resilient notification feature.

[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, from a network via a satellite link in a non-terrestrial network (NTN) , a message comprising resilient notification information corresponding to a mobile-ter1minated (MT) communication attempt missed by the UE. The UE extracts, from the resilient notification information, caller information and a timestamp associated with the missed MT communication attempt.

[0010] In a further aspect of the disclosure, a method, a computer-readable medium, and an apparatus are provided. The apparatus may be a UE. The UE receives resilient notification information from a network at a modem of the UE. The resilient notification information corresponds to a missed mobile-terminated (MT) communication. The UE transfers one or more parameters from the modem to an application layer of the UE via an internal interface. The UE derives the one or more parameters from the resilient notification information. The one or more parameters comprise caller information and a timestamp. The UE presents a notification to a user via a user interface of the UE. The UE bases the notification on the one or more transferred parameters.

[0011] 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

[0012] FIG. 1 is a diagram illustrating an example of a wireless communications system and an access network.

[0013] FIG. 2 is a diagram illustrating a base station in communication with a UE in an access network.

[0014] FIG. 3 illustrates an example logical architecture of a distributed access network.

[0015] FIG. 4 illustrates an example physical architecture of a distributed access network.

[0016] FIG. 5 is a diagram illustrating resilient notification capability negotiation and delivery mechanisms for mobile-terminated communications in a 6G non-terrestrial network architecture.

[0017] FIG. 6 is a flow chart of a method for capability negotiation for a resilient notification feature in a non-terrestrial network.

[0018] FIG. 7 is a flow chart of a method for enabling resilient notification feature support based on provisioned configuration data.

[0019] FIG. 8 is a flow chart of a method for receiving resilient notifications in a non-terrestrial network.

[0020] FIG. 9 is a flow chart of a method for handling resilient notifications at a user equipment.DETAILED DESCRIPTION

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0053] Non-Terrestrial Networks (NTN) are increasingly being considered for next-generation wireless communications systems, including 6G networks. In NTN architectures, satellites play a critical role in providing communication coverage, particularly in areas where terrestrial infrastructure is limited or unavailable. A UE 104 may communicate with the core network 190 (e.g., containing an AMF 192 or other core network entities) through a satellite link, either directly or via a ground-based base station 102 that acts as an intermediary. In some NTN deployment scenarios, the satellite itself may host network functions such as base station capabilities or core network entities like the MME 162 or AMF 192, rather than merely serving as a relay.

[0054] Communication between satellites and user devices such as smartphones faces significant technical challenges compared to terrestrial wireless communications. The satellite-to-smartphone communication link typically operates with very limited power margin due to the large distances involved and the power constraints of both the satellite and the user device. Additionally, optimal performance of satellite communication requires line-of-sight (LOS) conditions between the satellite and the UE 104. Environmental factors such as building obstruction, foliage, weather conditions, and the orientation of the user device can significantly degrade the channel quality of the satellite link.

[0055] For mobile-originated (MO) communications, where a user initiates a call or message transmission, the user is typically aware of the need to communicate and can take conscious actions to improve channel conditions. When initiating an MO communication, the user can observe signal strength indicators and consciously adjust their position or device orientation to achieve better LOS communication with the satellite. The user may move to an outdoor location, change their physical position, or reorient the device to establish optimal transmission conditions before initiating the communication. This user awareness during MO communications provides an opportunity to overcome the inherent challenges of satellite communication through deliberate user action.

[0056] In contrast, mobile-terminated (MT) communications present a different challenge in NTN environments. For MT communications, where the network attempts to deliver an incoming call, message, or notification to the UE 104, the user is completely unaware that a communication attempt is being made. The UE 104 may be located in an environment with poor satellite reception conditions-such as indoors, inside a vehicle, in a pocket or bag, or positioned with an orientation unfavorable for satellite communication-when the network attempts MT communication delivery. Under these circumstances, the UE 104 may fail to receive important incoming calls or messages due to the poor satellite link conditions. Most critically, the user remains completely unaware that such communication attempts occurred, as there is no mechanism to inform them of the missed MT communications after the initial delivery failure.

[0057] This asymmetry between MO and MT communications in satellite networks creates a significant reliability problem for communication services. Users may miss critical communications without any indication that delivery attempts were made. The inability to notify users about missed MT communications in poor satellite access conditions undermines the reliability of the entire communication service, particularly for time-sensitive or emergency communications.

[0058] To address this challenge, the concept of resilient notification has been identified as a requirement for NTN systems. Resilient notification refers to a highly reliable mechanism that delivers notifications about missed communications directly to user devices, such as smartphones, even when the initial MT communication failed due to poor satellite access conditions. The resilient notification mechanism would inform users that communication attempts were made, providing details such as caller information and timestamp, thereby allowing users to take appropriate action such as returning missed calls or retrieving missed messages.

[0059] However, despite the identification of resilient notification as a requirement for future NTN releases such as Release 18, there are currently no procedures defined in existing 3GPP specifications for how the UE 104 and network entities should implement and handle the resilient notification feature. Specifically, there is no standardized mechanism for capability negotiation between the UE 104 and network to determine support for resilient notification, no defined procedures for how the network should generate and deliver resilient notifications to the UE 104, and no specified interface for how the UE 104 should present resilient notification information to the user. The absence of these standardized procedures creates a gap that prevents the deployment of reliable MT communication services in NTN environments, leaving users vulnerable to missing important communications without their knowledge.

[0060] FIG. 5 is a diagram 500 illustrating resilient notification capability negotiation and delivery mechanisms for mobile-terminated communications in a 6G non-terrestrial network (6G NTN) architecture. In 6G NTN systems, communication between a satellite 512 and a UE 504 such as a smartphone typically has very limited power margin and requires line of sight for optimal performance. For mobile originated (MO) calls, users are aware of the channel quality and can achieve line of sight communication by consciously adjusting the position of their device for signal transmission and reception. However, for mobile terminated (MT) communication, users are unaware of the channel condition and might miss important calls or messages due to poor reception channel conditions when the satellite 512 attempts to deliver notifications. The resilient notification feature addresses this problem by providing a highly reliable mechanism that delivers notifications directly to user devices when experiencing poor conditions during satellite access.

[0061] Depending on deployment, the UE 504 may communicate directly with the satellite 512, the UE 504 may transmit to the ground base station 510 which forwards toward the satellite 512, and the satellite 512 may either act as a relay toward a terrestrial core network 514 or host entities such as an AMF or an MME which is part of the core network 514. The resilient notification feature enables the network to convey notification information to the UE 504 with high reliability when MT communication is attempted under poor satellite access conditions.

[0062] In this example, the UE 504 contains a UE modem 506 for handling lower-layer protocols and a UE application layer 508 for upper-layer functions. A capability negotiation mechanism enables the UE 504 and the core network 514 to determine whether both entities support the resilient notification feature. Two approaches are available for this capability negotiation, with the signaling-based approach having higher implementation priority based on standardization considerations.

[0063] In the first capability negotiation approach, which uses explicit signaling, the UE 504 transmits a mobility management message to the core network 514. This message may be a registration request 520, a service request 526, or an attach request 536. Within the selected message, the UE 504 includes resilient notification capability information 540 that indicates the UE’s support for the resilient notification feature. The resilient notification capability information 540 may comprise a new or existing bit within an existing IE of a mobility management protocol, where the mobility management protocol can be 6G mobility management (6GMM) , 5G mobility management (5GMM) , or evolved packet system mobility management (EMM) . Alternatively, the resilient notification capability information 540 may comprise a new IE within the existing mobility management message or may be conveyed in a new message specifically for capability indication.

[0064] When the core network 514 receives the mobility management message containing the resilient notification capability information 540, the core network 514 determines whether it supports the resilient notification feature. If the core network 514 supports this feature, it transmits a response message back to the UE 504. The response message corresponds to the received request type: a registration accept 522 responds to the registration request 520, a service accept 528 responds to the service request 526, or an attach accept 538 responds to the attach request 536. Additionally, the core network 514 may send a configuration update command 546 to convey capability information. The selected response message includes network resilient notification capability information 548, which may be implemented as an existing bit, a new bit, or a new IE within the response message. The network resilient notification capability information 548 informs the UE 504 that the core network 514 supports the resilient notification feature, thereby completing the bilateral capability negotiation process.

[0065] Upon receiving the response message with the network resilient notification capability information 548, the UE 504 determines that both the UE 504 and the core network 514 support the resilient notification feature. This mutual capability awareness enables subsequent utilization of the resilient notification feature for reliable notification delivery when MT communications encounter poor channel conditions.

[0066] In the second capability negotiation approach, the UE 504 can be configured to support the resilient notification feature through provisioning mechanisms that do not require explicit signaling exchange with the core network 514. The UE 504 may be configured to support the resilient notification feature through management object configuration data 544 stored in the UE’s memory or through information provisioned in a universal subscriber identity module (USIM) within the UE 504. When the resilient notification feature is enabled through the management object configuration data 544, the UE 504 reads the configuration from a non-access stratum (NAS) management object. Alternatively, the UE 504 may read the configuration from USIM data that has been pre-provisioned by a network operator.

[0067] The resilient notification feature support configuration can also be delivered to the UE 504 dynamically via a secure packet. For example, the core network 514 may send a short message service (SMS) message 532 containing the management object configuration data 544 to enable or update the resilient notification feature configuration. When the resilient notification feature is enabled through any of these provisioning mechanisms-management object configuration, USIM data 545, or secure packet delivery-the UE 504 activates support for the resilient notification feature without requiring the transmission of the resilient notification capability information 540 in mobility management messages. This provisioning-based approach provides flexibility for network operators to enable the resilient notification feature through configuration management rather than through capability negotiation signaling during each registration, service request, or attach procedure.

[0068] The capability negotiation mechanisms illustrated in FIG. 5 establish whether the resilient notification feature is supported before the core network 514 attempts to deliver resilient notifications to the UE 504. The signaling-based approach using mobility management messages with the resilient notification capability information 540 provides explicit bilateral negotiation that confirms both the UE 504 and the core network 514 are aware of each other’s capabilities. The provisioning-based approach using the management object configuration data 544, USIM data, or secure packet delivery reduces signaling overhead during mobility management procedures while still enabling feature activation. Both approaches enable the core network 514 to determine which UEs support the resilient notification feature and can therefore receive resilient notifications when MT communications encounter poor channel conditions in the satellite communication path between the satellite 512 and the UE 504.

[0069] After capability negotiation establishes that both the UE 504 and the core network 514 support the resilient notification feature, the core network 514 can deliver resilient notifications to the UE 504 when mobile-terminated communications fail due to poor satellite channel conditions. The resilient notification delivery mechanism addresses scenarios where the UE 504 misses important incoming calls or messages because of inadequate line-of-sight communication with the satellite 512 during the initial communication attempt.

[0070] The core network 514 employs multiple methods to deliver the resilient notification information 542 to the UE 504, with method selection depending on the current state of the UE 504 and network conditions. The resilient notification information 542 contains specific details about the missed mobile-terminated communication, including caller information that identifies the calling party through a mobile number or telephone number, and a timestamp indicating when the communication attempt occurred. This information enables users to understand what communication was missed and take appropriate responsive action such as returning missed calls.

[0071] The primary resilient notification delivery approach utilizes ongoing mobility management procedures for efficient notification delivery. When the UE 504 initiates a registration procedure by transmitting the registration request 520 or initiates a service procedure by transmitting the service request 526, the core network 514 determines whether resilient notifications need to be delivered based on recorded failed mobile-terminated communication attempts. Upon this determination, the core network 514, which may include an AMF or MME entity located within the satellite 512 itself or in terrestrial infrastructure, appends the resilient notification information 542 to the corresponding response message. Specifically, the core network 514 includes the resilient notification information 542 as a new or existing information element within the registration accept 522 when responding to the registration request 520, or within the service accept 528 when responding to the service request 526. This approach efficiently utilizes existing mobility management signaling exchanges without requiring additional dedicated messages, reducing signaling overhead while delivering notifications when the UE 504 has already established adequate satellite channel conditions to complete the mobility management transaction.

[0072] When the UE 504 is in idle mode and not engaged in mobility management procedures, the core network 514 can initiate notification delivery through paging mechanisms. The core network 514 transmits a paging message 524 or a dedicated notification message containing the resilient notification information 542 as a new or existing information element. The paging message 524 propagates from the core network 514 through the satellite 512 and, depending on the deployment architecture, may be forwarded through the ground base station 510 to reach the UE 504. The ground base station 510 serves as an intermediary that addresses the limited transmission power of the UE 504, which may be insufficient for direct communication with the satellite 512. When receiving the paging message 524 from the satellite 512, the ground base station 510 broadcasts it within its coverage area. The UE 504 monitors paging occasions and receives the paging message 524 containing the resilient notification information 542, becoming aware of previously missed mobile-terminated communications.

[0073] The core network 514 can alternatively utilize cell broadcast mechanisms for resilient notification delivery. The core network 514 instructs the ground base station 510 or the satellite 512 to broadcast the resilient notification information 542 using system information blocks or radio resource control signaling. The ground base station 510 transmits an SIB / RRC message 530 containing the resilient notification information 542 as a new or existing information element within a system information block from the camped cell or within a dedicated RRC message. The UE 504, camping on the cell provided by the ground base station 510, receives and decodes the SIB / RRC message 530 to extract the resilient notification information 542. This cell broadcast approach enables efficient delivery to multiple UEs simultaneously when several users within a coverage area have experienced missed communications during periods of degraded satellite channel conditions.

[0074] As another alternative, the core network 514 can transmit an SMS message 532 to deliver the resilient notification information 542. The SMS message 532 may be implemented as SMS over NAS or SMS over IP, depending on the capabilities of the UE 504 and the core network 514. The core network 514 formulates the SMS message 532 with the resilient notification information 542 encoded in the message payload and transmits it through the satellite 512 toward the UE 504. The SMS message 532 follows standard SMS delivery paths, propagating from the core network 514 through the satellite 512 and optionally through the ground base station 510. The UE 504 receives and processes the SMS message 532 according to standard SMS handling procedures, extracting the resilient notification information 542 from the message content.

[0075] The delivery of resilient notifications traverses the non-terrestrial network architecture with varying deployment configurations. In scenarios where the satellite 512 hosts core network functions including the AMF or MME, resilient notifications originate directly from network entities within the satellite 512. The satellite 512 transmits messages containing the resilient notification information 542 directly to the UE 504 when direct satellite access capability exists, or forwards messages to the ground base station 510 for subsequent transmission to the UE 504. In alternative deployments where the core network 514 comprises terrestrial infrastructure, resilient notifications originate from terrestrial network entities and propagate through backhaul connections to the satellite 512, which acts as a relay forwarding notifications toward the UE 504. The ground base station 510 receives uplink transmissions from the UE 504 and forwards them toward the satellite 512, while receiving downlink transmissions from the satellite 512 and forwarding them to the UE 504, thereby addressing the power limitations that prevent reliable direct UE-to-satellite communication over large distances.

[0076] After the UE modem 506 receives the resilient notification information 542 from the core network 514 through any of the delivery mechanisms, the notification details must be conveyed from the lower protocol layers to the user-facing components of the UE 504. The UE modem 506 implements the 3GPP protocol stack, including the access stratum and non-access stratum layers, which process incoming messages from the satellite 512 and core network 514. However, the resilient notification information 542 received at these lower layers remains inaccessible to users until transferred to the UE application layer 508, where terminal equipment and user interface components can present the notification to the user.

[0077] An interface mechanism between the UE modem 506 and the UE application layer 508 may be used to enable resilient notification information to propagate from lower layers to upper layers. This interface may comprise a new or existing message, indicator, or method for transferring data from the 3GPP modem to terminal equipment, application layer components, or user interface elements. The interface implementation may be UE-specific AT commands, internal UE signaling from access stratum or non-access stratum layers to application layers, or pre-defined standardized AT commands following established 3GPP conventions. An AT command interface designated as the AT command 534 provides a specific implementation of this notification mechanism. As an example, the AT command 534 implements a new command identified as the Resilient Notification command with syntax +CRENOTF. This command enables the UE modem 506 to report resilient notification details to the UE application layer 508, including caller information identifying the calling party and timestamp information indicating when the missed communication attempt occurred. In this example, the +CRENOTF command structure includes three distinct command formats with corresponding response behaviors, as shown in the following table. AT Command +CRENOTF syntax and responses

[0078] The set command format +CRENOTF= [<n>] controls the presentation of unsolicited result codes containing resilient notification information. When the UE application layer 508 issues this set command to the UE modem 506, the parameter <n> determines whether the UE modem 506 will automatically generate notifications upon receiving resilient notification information 542 from the core network 514. Setting <n> to the integer value 1 enables the presentation of unsolicited result codes with the format +CRENOTF: <n>, <Caller information>, <time stamp of call>, <feature support>, allowing the UE modem 506 to proactively notify the UE application layer 508 when resilient notification information arrives. Setting <n> to 0 disables this automatic presentation. If an error occurs during command processing, the UE modem 506 returns a +CME ERROR: <err>response, where valid error values are defined in clause 9.2 of the relevant AT command specification.

[0079] The read command format +CRENOTF? queries the current configuration state and retrieves any available resilient notification details. When the UE application layer 508 issues this read command, the UE modem 506 responds with +CRENOTF: <n>, <Caller information>, <time stamp of call>, <feature support>, providing the current setting of the enable / disable parameter along with the actual notification content when such information is available. This read command allows the UE application layer 508 to poll for resilient notifications rather than relying solely on unsolicited result codes. If an error occurs, the UE modem 506 returns a +CME ERROR: <err> response.

[0080] The test command format +CRENOTF=? queries the capabilities supported by the particular implementation of the UE modem 506. When the UE application layer 508 issues this test command, the UE modem 506 responds with +CRENOTF: (list of supported <n>s) , providing a compound value that enumerates the valid parameter values supported. This capability discovery mechanism enables the UE application layer 508 to determine which configuration options are available before attempting to configure notification behavior. If an error occurs during test command processing, the UE modem 506 returns a +CME ERROR: <err> response.

[0081] The parameters conveyed through the AT command 534 carry specific notification details extracted from the resilient notification information 542. The parameter <n> is an integer type where 0 disables presentation of unsolicited result codes and 1 enables presentation. The parameter <feature support> is an integer type indicating whether the core network 514 supports the resilient notification feature, with a value of 1 indicating support and 0 indicating no support. The UE modem 506 determines this value based on the capability negotiation procedures. The parameter <Caller information> contains identifying information for the calling party, such as a mobile number or telephone number of the mobile-originated party whose communication attempt was missed. The parameter <time stamp of call> is a string type value coded as one byte in an 8-bit format, corresponding to octet 3 of the GPRS Timer 3 information element as defined in 3GPP TS 24.008 Table 10.5.163a and 3GPP TS 24.501 clause 5.3.26. For example, the bit format "01000111" represents a value of 70 hours. The default value, if available, is manufacturer specific.

[0082] The operational flow between the UE modem 506 and the UE application layer 508 proceeds as follows. The UE application layer 508 initially configures notification behavior by issuing the set command +CRENOTF= [1] to enable unsolicited result code presentation. Subsequently, when the UE modem 506 receives the resilient notification information 542 from the core network 514 through any delivery mechanism-whether appended to a registration accept 522, included in a paging message 524, embedded in an SIB / RRC message 530, or delivered via an SMS message 532-the lower layer protocol stack within the UE modem 506 extracts the caller information and timestamp details. Because unsolicited result code presentation has been enabled, the UE modem 506 immediately generates and transmits an unsolicited result code through the AT command 534 interface to the UE application layer 508, conveying the complete resilient notification details including the calling party identification and the time of the missed communication attempt.

[0083] Upon receiving the notification through the AT command 534 interface, the UE application layer 508 processes the caller information and timestamp to present a user notification through the user interface of the UE 504. The user interface may display a notification message indicating that a call or message from the specified caller was missed at the indicated time due to poor satellite reception conditions. This notification mechanism addresses the fundamental problem that users remain unaware of communication attempts that occurred when the UE 504 experienced poor satellite channel conditions. By conveying the resilient notification information 542 from the UE modem 506 through the AT command 534 to the UE application layer 508, the complete notification path from the core network 514 to the end user is established, enabling users to become aware of missed communications and take appropriate action such as returning missed calls when improved satellite channel conditions become available.

[0084] FIG. 6 is a flow chart 600 of a method for capability negotiation for a resilient notification feature in a non-terrestrial network. The method may be performed by a UE, such as UE 504 in FIG. 5. In operation 602, the UE transmits, to a network, a mobility management message comprising an indication that the UE supports a resilient notification feature for receiving notifications about missed mobile-terminated communications in a non-terrestrial network. For example, the network may be core network 514 in FIG. 5.

[0085] In certain implementations, the mobility management message is one of a registration request message, a service request message, or an attach request message. For example, the mobility management message may be registration request 520, service request 526, or attach request 536 in FIG. 5.

[0086] In certain implementations, the indication that the UE supports the resilient notification feature is comprised in first resilient notification capability information in the mobility management message and / or the indication that the network supports the resilient notification feature is comprised in second resilient notification capability information in the response message. For example, the resilient notification capability information may be resilient notification capability IE 540 in FIG. 5.

[0087] In certain implementations, at least one of the first resilient notification capability information or the second resilient notification capability information comprises one of a bit in an existing IE of a mobility management protocol or a designated IE. The mobility management protocol can be 6G mobility management, 5G mobility management, or evolved packet system mobility management.

[0088] In operation 604, the UE receives, from the network, a response message comprising an indication that the network supports the resilient notification feature. For example, the response message may include network resilient notification capability information, such as network resilient notification capability IE 548 in FIG. 5.

[0089] In certain implementations, the response message is one of a registration accept message, a service accept message, an attach accept message, or a configuration update command. For example, the response message may be registration accept 522, service accept 528, attach accept 538, or configuration update command 546 in FIG. 5.

[0090] FIG. 7 is a flow chart 700 of a method for enabling resilient notification feature support based on provisioned configuration data. The method may be performed by a UE, such as UE 504. In operation 702, the UE determines, based on configuration data, that a resilient notification feature is enabled for the UE. The configuration data is provisioned via at least one of: a MO, data stored in a USIM, or a secure packet. For example, the configuration data may be the management object configuration data 544 stored in the UE’s memory or provisioned in the USIM within the UE 504.

[0091] In operation 704, the UE enables support for the resilient notification feature in response to the determination. When the resilient notification feature is enabled through any of these provisioning mechanisms, the UE 504 activates support for the resilient notification feature without requiring the transmission of a resilient notification capability information in mobility management messages.

[0092] In certain implementations, the MO is a NAS MO. To determine the configuration, the UE further reads the configuration from the NAS MO.

[0093] In certain implementations, the secure packet is an SMS message. For example, the SMS message may be SMS message 532 containing the management object configuration data 544 to enable or update the resilient notification feature configuration.

[0094] FIG. 8 is a flow chart 800 of a method for receiving resilient notifications in a non-terrestrial network. The method may be performed by a UE, such as UE 504 in FIG. 5. In operation 802, the UE receives, from a network via a satellite link in an NTN, a message comprising resilient notification information corresponding to an MT communication attempt missed by the UE. For example, the network may be the core network 514 communicating through the satellite 512 as illustrated in FIG. 5. The resilient notification information 542 provides notification about missed communications that occurred when the UE experienced poor satellite channel conditions.

[0095] In operation 804, the UE extracts, from the resilient notification information, caller information and a timestamp associated with the missed MT communication attempt. For example, the resilient notification information 542 contains these details to inform the user about the missed communication as illustrated in FIG. 5.

[0096] In certain implementations, the message is a mobility management response message received in response to a mobility management request message transmitted by the UE. The mobility management response message is one of a registration accept message or a service accept message. For example, the message may be the registration accept 522 received in response to the registration request 520, or the service accept 528 received in response to the service request 526, as illustrated in FIG. 5.

[0097] In certain implementations, the message is one of: a paging message; a SIB or an RRC message; or an SMS message. For example, the message may be the paging message 524, the SIB / RRC message 530, or the SMS message 532 as illustrated in FIG. 5.

[0098] In certain implementations, the caller information comprises a mobile number or a telephone number of a calling party.

[0099] FIG. 9 is a flow chart 900 of a method for handling resilient notifications at a UE. The method may be performed by a UE, such as UE 504. In operation 902, a modem of the UE (e.g., UE modem 506) receives resilient notification information from a network (e.g., core network 514) . The resilient notification information corresponds to a missed MT communication. The resilient notification information may be received through various delivery mechanisms, such as appended to a registration accept 522, included in a paging message 524, embedded in an SIB / RRC message 530, or delivered via an SMS message 532.

[0100] In operation 904, the modem transfers, to an application layer of the UE (e.g., UE application layer 508) via an internal interface, one or more parameters derived from the resilient notification information. The one or more parameters comprise caller information and a timestamp. The caller information identifies the calling party through a mobile number or telephone number, and the timestamp indicates when the communication attempt occurred.

[0101] In operation 906, the UE presents, via a user interface, a notification to a user based on the one or more transferred parameters. The user interface may display a notification message indicating that a call or message from the specified caller was missed at the indicated time due to poor satellite reception conditions.

[0102] In certain implementations, the internal interface is an AT command interface (e.g., AT command 534) . The AT command interface enables the modem to report resilient notification details to the application layer.

[0103] In certain implementations, to transfer the one or more parameters, the modem sends an unsolicited result code to the application layer. When the modem receives the resilient notification information from the network, the lower layer protocol stack within the modem extracts the caller information and timestamp details, and the modem immediately generates and transmits the unsolicited result code through the internal interface to the application layer.

[0104] In certain implementations, the method further comprises transmitting, from the application layer to the modem, a set command to enable the sending of the unsolicited result code. For example, the application layer may issue a set command +CRENOTF= [1] to enable presentation of unsolicited result codes, allowing the modem to proactively notify the application layer when resilient notification information arrives.

[0105] In certain implementations, the unsolicited result code comprises the caller information, the timestamp, and an indication of whether the network supports a resilient notification feature. The indication of feature support enables the application layer to determine whether the resilient notification capability has been successfully negotiated between the UE and the network.

[0106] In certain implementations, the AT command interface further supports a read command to query for the one or more parameters and a test command to query for supported parameter values. The read command allows the application layer to poll for resilient notifications rather than relying solely on unsolicited result codes, and the test command enables the application layer to determine which configuration options are available before attempting to configure notification behavior.

[0107] The UE 504 implementing the resilient notification feature described in FIGs. 5-9 may utilize hardware components similar to those of the UE 250 illustrated in FIG. 2. Specifically, the UE modem 506 functionality described in the resilient notification solutions may be implemented using the controller / processor 259, which handles the NAS and AS layer processing required for capability negotiation and resilient notification reception. The controller / processor 259, in conjunction with the memory 260 storing program codes and data, executes the mobility management procedures for transmitting the resilient notification capability information 540 in registration request 520, service request 526, or attach request 536 messages. Additionally, the RX processor 256 and receivers 254RX process incoming signals containing resilient notification information 542 delivered through various mechanisms such as registration accept 522, paging message 524, SIB / RRC message 530, or SMS message 532, while the TX processor 268 and transmitters 254TX handle the uplink transmission of capability indications and mobility management messages through the satellite link.

[0108] The UE application layer 508 functionality and the AT command interface 534 described in the resilient notification solutions may be implemented as software modules executed by the controller / processor 259 or by a separate application processor within the UE 504. The memory 260 stores the management object configuration data 544 used for provisioning-based capability enablement, as well as the extracted resilient notification parameters including caller information and timestamps. The internal interface between the UE modem 506 and UE application layer 508, particularly the AT command 534 implementation (+CRENOTF) , represents inter-process communication mechanisms within the controller / processor 259 or between the baseband processor implementing the modem functions and an application processor implementing the user interface functions. The hardware architecture enables the complete resilient notification processing flow from receiving satellite signals containing notification information through the antennas 252 and receivers 254RX, to processing in the controller / processor 259, and ultimately presenting notifications to users through the device’s user interface components.

[0109] The network entities implementing the resilient notification feature in FIGs. 5-9 comprise multiple components with distinct hardware architectures. The ground base station 510, which serves as an intermediary between the UE 504 and satellite 512, may utilize hardware components similar to those of the base station 210 described in FIG. 2. Specifically, the ground base station 510 employs the controller / processor 275 to manage the relay of resilient notification messages between the satellite and UE, the TX processor 216 and transmitters 218TX to broadcast paging messages 524 and SIB / RRC messages 530 containing resilient notification information 542 to UEs within its coverage area, and the RX processor 270 and receivers 218RX to receive capability indications and mobility management messages from UEs. The memory 276 stores configuration data and buffers resilient notification information received from the satellite 512 for subsequent transmission to UEs. The satellite 512, depending on deployment architecture, may host similar baseband processing components when functioning as a base station, or may implement specialized satellite communication hardware for bent-pipe relay operations when simply forwarding signals between ground stations and UEs.

[0110] The core network 514 entities responsible for resilient notification generation and management, such as the AMF 192 or MME 162, are typically implemented using server-grade computing hardware comprising high-performance processors, substantial memory resources, and network interface cards for high-throughput packet processing. These core network entities execute software functions for determining when to generate resilient notifications based on failed MT communication attempts, maintaining databases of missed call information including caller details and timestamps, and formatting resilient notification information 542 for inclusion in various message types. When the AMF or MME is hosted within the satellite 512 as described in certain NTN deployments, these functions are implemented using space-hardened computing platforms designed for satellite operation, featuring radiation-tolerant processors, error-correcting memory systems, and specialized interfaces for satellite communication links. The core network hardware, whether terrestrial or satellite-based, includes network interfaces supporting backhaul connections to other network elements, enabling the propagation of resilient notifications from the point of generation through the satellite network infrastructure to the target UE 504.

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

[0112] 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 performed by a user equipment (UE) , the method comprising:transmitting, to a network, a mobility management message comprising an indication that the UE supports a resilient notification feature for receiving notifications about missed mobile-terminated (MT) communications in a non-terrestrial network (NTN) ; andreceiving, from the network, a response message comprising an indication that the network supports the resilient notification feature.2.The method of claim 1, wherein:the mobility management message is one of a registration request message, a service request message, or an attach request message; andthe response message is one of a registration accept message, a service accept message, an attach accept message, or a configuration update command.3.The method of claim 1, wherein:the indication that the UE supports the resilient notification feature is comprised in first resilient notification capability information in the mobility management message; orthe indication that the network supports the resilient notification feature is comprised in second resilient notification capability information in the response message.4.The method of claim 3, wherein at least one of the first resilient notification capability information or the second resilient notification capability information comprises one of:a bit in an existing information element (IE) of a mobility management protocol; ora designated IE.5.A method performed by a user equipment (UE) , the method comprising:determining, based on configuration data, that a resilient notification feature is enabled for the UE, wherein the configuration data is provisioned via at least one of: a management object (MO) , data stored in a universal subscriber identity module (USIM) , or a secure packet; andenabling support for the resilient notification feature in response to the determination.6.The method of claim 5, wherein the MO is a non-access stratum (NAS) MO.7.The method of claim 5, wherein the secure packet is a short message service (SMS) message.8.A method performed by a user equipment (UE) , the method comprising:receiving, from a network via a satellite link in a non-terrestrial network (NTN) , a message comprising resilient notification information corresponding to a mobile-terminated (MT) communication attempt missed by the UE; andextracting, from the resilient notification information, caller information and a timestamp associated with the missed MT communication attempt.9.The method of claim 8, wherein the message is a mobility management response message received in response to a mobility management request message transmitted by the UE, the mobility management response message being one of a registration accept message or a service accept message.10.The method of claim 8, wherein the message is one of:a paging message;a system information block (SIB) or a radio resource control (RRC) message; ora short message service (SMS) message.11.The method of claim 8, wherein the caller information comprises a mobile number or a telephone number of a calling party.12.A method performed by a user equipment (UE) , the method comprising:receiving, at a modem of the UE, resilient notification information from a network, the resilient notification information corresponding to a missed mobile-terminated (MT) communication;transferring, from the modem to an application layer of the UE via an internal interface, one or more parameters derived from the resilient notification information, the one or more parameters comprising caller information and a timestamp; andpresenting, via a user interface of the UE, a notification to a user based on the one or more transferred parameters.13.The method of claim 12, wherein the internal interface is an AT command interface.14.The method of claim 13, wherein transferring the one or more parameters comprises the modem sending an unsolicited result code to the application layer.15.The method of claim 14, further comprising:transmitting, from the application layer to the modem, a set command to enable the sending of the unsolicited result code.16.The method of claim 14, wherein the unsolicited result code comprises the caller information, the timestamp, and an indication of whether the network supports a resilient notification feature.17.The method of claim 13, wherein the AT command interface further supports:a read command to query for the one or more parameters; anda test command to query for supported parameter values.

Images