Methods and apparatus for handling a user equipment context after successful NAS procedure with the UE in a wireless communication system

Abstract

The disclosure relates to a fifth generation (5G) or sixth generation (6G) communication system for supporting higher data rates. Embodiments herein provide a method and a system for handling UE context in a wireless communication. The method includes receiving by the HSS apparatus, an Update Location Request message from a first MME. The Update Location Request message comprises the first timestamp indicating an interaction of the first MME with the UE. Further the HSS apparatus compares the first timestamp received from the first MME with the second timestamp stored at the HSS apparatus from a previous interaction with the UE. Furthermore, the HSS apparatus accepts the Update Location Request message received from the first MME, when the first timestamp is newer than or equal to the second timestamp and rejects the Update Location Request message received from the first MME, when the first timestamp is older than the second timestamp.

Description

METHODS AND APPARATUS FOR HANDLING A USER EQUIPMENT CONTEXT AFTER SUCCESSFUL NAS PROCEDURE WITH THE UE IN A WIRELESS COMMUNICATION SYSTEM

[0001] The present application is based on and claims priority from an Indian Provisional Application Number 202441049460 filed on 27th June 2024, the disclosure of which is hereby incorporated by reference herein. The proposed embodiments relate to wireless communication and more particularly relates to a method and a system for handling User Equipment (UE) context using request time.

[0002] 5G mobile communication technologies define broad frequency bands such that high transmission rates and new services are possible, and can be implemented not only in “Sub 6GHz” bands such as 3.5GHz, but also in “Above 6GHz” bands referred to as mmWave including 28GHz and 39GHz. In addition, it has been considered to implement 6G mobile communication technologies (referred to as Beyond 5G systems) in terahertz bands (for example, 95GHz to 3THz bands) in order to accomplish transmission rates fifty times faster than 5G mobile communication technologies and ultra-low latencies one-tenth of 5G mobile communication technologies.

[0003] At the beginning of the development of 5G mobile communication technologies, in order to support services and to satisfy performance requirements in connection with enhanced Mobile BroadBand (eMBB), Ultra Reliable Low Latency Communications (URLLC), and massive Machine-Type Communications (mMTC), there has been ongoing standardization regarding beamforming and massive MIMO for mitigating radio-wave path loss and increasing radio-wave transmission distances in mmWave, supporting numerologies (for example, operating multiple subcarrier spacings) for efficiently utilizing mmWave resources and dynamic operation of slot formats, initial access technologies for supporting multi-beam transmission and broadbands, definition and operation of BWP (BandWidth Part), new channel coding methods such as a LDPC (Low Density Parity Check) code for large amount of data transmission and a polar code for highly reliable transmission of control information, L2 pre-processing, and network slicing for providing a dedicated network specialized to a specific service.

[0004] Currently, there are ongoing discussions regarding improvement and performance enhancement of initial 5G mobile communication technologies in view of services to be supported by 5G mobile communication technologies, and there has been physical layer standardization regarding technologies such as V2X (Vehicle-to-everything) for aiding driving determination by autonomous vehicles based on information regarding positions and states of vehicles transmitted by the vehicles and for enhancing user convenience, NR-U (New Radio Unlicensed) aimed at system operations conforming to various regulation-related requirements in unlicensed bands, NR UE Power Saving, Non-Terrestrial Network (NTN) which is UE-satellite direct communication for providing coverage in an area in which communication with terrestrial networks is unavailable, and positioning.

[0005] Moreover, there has been ongoing standardization in air interface architecture / protocol regarding technologies such as Industrial Internet of Things (IIoT) for supporting new services through interworking and convergence with other industries, IAB (Integrated Access and Backhaul) for providing a node for network service area expansion by supporting a wireless backhaul link and an access link in an integrated manner, mobility enhancement including conditional handover and DAPS (Dual Active Protocol Stack) handover, and two-step random access for simplifying random access procedures (2-step RACH for NR). There also has been ongoing standardization in system architecture / service regarding a 5G baseline architecture (for example, service based architecture or service based interface) for combining Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies, and Mobile Edge Computing (MEC) for receiving services based on UE positions.

[0006] As 5G mobile communication systems are commercialized, connected devices that have been exponentially increasing will be connected to communication networks, and it is accordingly expected that enhanced functions and performances of 5G mobile communication systems and integrated operations of connected devices will be necessary. To this end, new research is scheduled in connection with eXtended Reality (XR) for efficiently supporting AR (Augmented Reality), VR (Virtual Reality), MR (Mixed Reality) and the like, 5G performance improvement and complexity reduction by utilizing Artificial Intelligence (AI) and Machine Learning (ML), AI service support, metaverse service support, and drone communication.

[0007] Furthermore, such development of 5G mobile communication systems will serve as a basis for developing not only new waveforms for providing coverage in terahertz bands of 6G mobile communication technologies, multi-antenna transmission technologies such as Full Dimensional MIMO (FD-MIMO), array antennas and large-scale antennas, metamaterial-based lenses and antennas for improving coverage of terahertz band signals, high-dimensional space multiplexing technology using OAM (Orbital Angular Momentum), and RIS (Reconfigurable Intelligent Surface), but also full-duplex technology for increasing frequency efficiency of 6G mobile communication technologies and improving system networks, AI-based communication technology for implementing system optimization by utilizing satellites and AI (Artificial Intelligence) from the design stage and internalizing end-to-end AI support functions, and next-generation distributed computing technology for implementing services at levels of complexity exceeding the limit of UE operation capability by utilizing ultra-high-performance communication and computing resources.

[0008] The present disclosure relates to wireless communication systems and, more specifically, the present disclosure relates to handling a user equipment context after successful NAS procedure with the UE in a wireless communication system.

[0009] The principal object of the embodiments herein is to provide a system and method for handling UE context using request time.

[0010] Another object of the embodiments herein is to provide a method to transmit a timestamp to the HSS apparatus to indicate the latest network with which the UE is successfully registered.

[0011] Yet another object of the embodiments herein is to provide the HSS apparatus that accepts the update location procedure request from the latest MME-ground and cancels the update location procedure request from the earlier MME-ground.

[0012] In an aspect, the objects are achieved by providing a method for handling the UE context by HSS apparatus. The method includes receiving by the HSS apparatus an Update Location Request message from a first MME. The Update Location Request message comprises the first timestamp indicating an interaction of the first MME with the UE. Further, the HSS apparatus compares the first timestamp received from the first MME with the second timestamp stored at the HSS apparatus. Furthermore, the HSS apparatus accepts the Update Location Request message received from the first MME when the first timestamp is newer than or equal to the second timestamp and rejects the Update Location Request message received from the first MME when the first timestamp is older than the second timestamp.

[0013] In another aspect, the objects are achieved by providing a method for including the timestamp by the first MME. The method includes determining by the first MME the first timestamp when the first MME interacts with the UE following a successful attach or Tracking Area Update (TAU) procedure. Further, the first MME generates the Update Location Request message by adding the first timestamp and transmits the Update Location Request message comprising the first timestamp to the HSS apparatus.

[0014] In yet another aspect, the objects are achieved by providing a first MME for handling User Equipment in the wireless communication. The first MME includes a memory, a processor, and a location management controller operatively coupled with the memory and the processor. The location management controller determines the first timestamp when the first MME interacts with the UE following a successful attach or Tracking Area Update (TAU) procedure. Further, the location management controller generates an Update Location Request message by adding the first timestamp and transmits the Update Location Request message comprising the first timestamp to the HSS apparatus.

[0015] In yet another aspect, the objects are achieved by providing the HSS apparatus for handling the UE context in the wireless communication. The HSS apparatus includes a memory, a processor, an I / O interface, and a location management controller. The location management controller receives the Update Location Procedure Request message from the first MME. The Update Location Procedure Request message comprises a first timestamp indicating an interaction of the first MME with the UE. The location management controller compares the first timestamp received from the first MME with a second timestamp stored at the HSS apparatus. Further, the HSS apparatus accepts the Update Location Procedure Request message received from the first MME when the first timestamp is newer than or equal to the second timestamp. If the first timestamp is older than the second timestamp, the HSS apparatus rejects the Update Location Procedure Request message received from the first MME.

[0016] In yet another aspect, the objects are achieved by providing a method performed by a home subscriber server (HSS) in a communication system, the method comprising: receiving, from a mobility management entity (MME), a first update location request; identifying whether the first update location request includes a timestamp associated with a time when an on-board MME has received a message for a non-access stratum (NAS) procedure from a user equipment (UE); in case that the first update location request includes the timestamp, identifying whether the timestamp included in the first update location request is older than a stored timestamp included in a second update location request; and in case that the timestamp included in the first update location request is older than the stored timestamp included in the second update location request, determining to reject the first update location request.

[0017] In yet another aspect, the objects are achieved by providing a method performed by a mobility management entity (MME) in a communication system, the method comprising: transmitting, to a home subscriber server (HSS), a first update location request; and in case that the first update location request includes a timestamp, receiving, from the HSS, a message indicating whether the first update location request is rejected or accepted, based on a comparison of whether the timestamp included in the first update location request is older than a stored timestamp included in a second update location request, wherein the timestamp associated with a time when an on-board MME has received a message for a non-access stratum (NAS) procedure from a user equipment (UE).

[0018] In yet another aspect, the objects are achieved by providing a home subscriber server (HSS) in a communication system, the HSS comprising: at least one transceiver; at least one processor communicatively coupled to the at least one transceiver; and at least one memory, communicatively coupled to the at least one processor, storing instructions executable by the at least one processor individually or in any combination to cause the HSS to: receive, from a mobility management entity (MME), a first update location request; identify whether the first update location request includes a timestamp associated with a time when an on-board MME has received a message for a non-access stratum (NAS) procedure from a user equipment (UE); in case that the first update location request includes the timestamp, identify whether the timestamp included in the first update location request is older than a stored timestamp included in a second update location request; and in case that the timestamp included in the first update location request is older than the stored timestamp included in the second update location request, determine to reject the first update location request.

[0019] In yet another aspect, the objects are achieved by providing a mobility management entity (MME) in a communication system, the MME comprising: at least one transceiver; at least one processor communicatively coupled to the at least one transceiver; and at least one memory, communicatively coupled to the at least one processor, storing instructions executable by the at least one processor individually or in any combination to cause the MME to: transmit, to a home subscriber server (HSS), a first update location request; and in case that the first update location request includes a timestamp, receive, from the HSS, a message indicating whether the first update location request is rejected or accepted, based on a comparison of whether the timestamp included in the first update location request is older than a stored timestamp included in a second update location request, wherein the timestamp associated with a time when an on-board MME has received a message for a non-access stratum (NAS) procedure from a user equipment (UE).

[0020] These and other aspects of the embodiments will be better understood with the following description and accompanying drawings. The descriptions, indicating preferred embodiments and specific details, are for illustration and not limitation. Many changes and modifications can be made within the scope of the embodiments without departing from their spirit, and all such modifications are included.

[0021] According to an embodiment of the disclosure, a wireless communication can be performed efficiently. Especially, a handling a user equipment context after successful NAS procedure with the UE can be performed efficiently.

[0022] These and other features, aspects, and advantages of the present embodiments are illustrated in the accompanying drawings, throughout which like reference letters indicate corresponding parts in the various figures. The embodiments herein will be better understood from the following description with reference to the drawings, in which:

[0023] Fig. 1 is a schematic diagram that illustrates the normal / default satellite operation mode of a 5G system with satellite access according to the prior art.

[0024] Fig. 2 is a schematic diagram that illustrates the S&F satellite operation mode of the 5G system with satellite access according to the prior art.

[0025] Fig. 3 is a high-level overview of the UE satellite UE communication according to the prior art.

[0026] Fig. 4 is a high-level overview of satellite network, terrestrial network, and UE communication architecture according to the prior art.

[0027] Fig. 5 is a sequence diagram that illustrates existing UE context handling where the latest MME ground is rejected by the HSS.

[0028] Fig. 6 is a block diagram that illustrates the hardware features associated with the HSS apparatus according to the embodiments as disclosed herein.

[0029] Fig. 7 is a block diagram that illustrates the hardware features associated with the first MME according to the embodiments as disclosed herein.

[0030] Fig. 8 is a sequence diagram that illustrates handling UE context using request time according to the embodiments as disclosed herein.

[0031] Fig. 9 is a flow diagram that illustrates the method of handling the UE context according to the embodiments as disclosed herein.

[0032] Store and Forward (S&F) mode is a widely recognized concept in the fields of delay-tolerant networking and disruption-tolerant networking. This mode is particularly useful in scenarios where continuous end-to-end connectivity is not feasible. In the context of 3GPP, a service analogous to S&F is the Short Message Service (SMS), which does not require direct connectivity between endpoints, such as a User Equipment (UE) and an application server. Instead, connectivity is only required between the endpoints and the Short Message Service Center (SMSC), which acts as an intermediary node responsible for storing and forwarding messages.

[0033] S&F mode is advantageous for delay-tolerant and non-real-time Internet of Things (IoT) satellite services, particularly those utilizing Non-Geostationary Satellite Orbit (NGSO) satellites. In satellite communication, the UE context encompasses both dynamic and static data associated with the UE, facilitating connectivity, authentication, and session management within the satellite network. This context includes information such as user identity, network session details, location data, security credentials, and Quality of Service (QoS) parameters.

[0034] In S&F mode for split MME case, there are two parts of the Mobility Management Entity (MME) included: MME-onboard, which is located on the satellite, and MME-ground, situated on the ground. MME-onboard stores any UE requests and forwards them to MME-ground when the feeder link between them is established. However, establishing a connection in S&F mode between the UE and the ground network is time-consuming, requiring the establishment of both the service link and the feeder link.

[0035] A significant issue arises when the UE transitions from being in contact with a first MME-ground to a second MME-ground. When the second MME-ground sends an update location procedure request to the Home Subscriber Server (HSS) apparatus, the HSS apparatus may mistakenly assume that the UE is still in contact with the first MME-ground and reject the update location request from the second MME-ground. This results in service unavailability for the UE, which is currently registered with the second MME-ground. Consequently, there is a need to address these disadvantages, issues, and shortcomings, or at least provide a useful alternative to mitigate the problem. The problem is illustrated in Fig.1 and Fig 2.

[0036] Thus, it is desired to address the above-mentioned disadvantages, issues or other shortcomings or at least provide a useful alternative.

[0037] The embodiments herein and the various features and advantageous details thereof are explained more fully with reference to the non-limiting embodiments that are illustrated in the accompanying drawings and details in the following description. Descriptions of well-known components and processing techniques are omitted so as to not unnecessarily obscure the embodiments herein. Also, the various embodiments described herein are not necessarily mutually exclusive, as some embodiments can be combined with one or more other embodiments to form new embodiments. The term “or” as used herein, refers to a non-exclusive or, unless otherwise indicated. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein can be practiced and to further enable those skilled in the art to practice the embodiments herein. Accordingly, the examples are not be construed as limiting the scope of the embodiments herein.

[0038] As is traditional in the field, embodiments are described and illustrated in terms of blocks that carry out a described function or functions.　These blocks, which referred to herein as managers, units, modules, hardware components or the like, are physically implemented by analog and / or digital circuits such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuits and the like, and optionally be driven by firmware and software. The circuits, for example, be embodied in one or more semiconductor chips, or on substrate supports such as printed circuit boards and the like.　The circuits constituting a block be implemented by dedicated hardware, or by a processor (e.g., one or more programmed microprocessors and associated circuitry), or by a combination of dedicated hardware to perform some functions of the block and a processor to perform other functions of the block. Each block of the embodiments be physically separated into two or more interacting and discrete blocks without departing from the scope of the proposed method.　Likewise, the blocks of the embodiments be physically combined into more complex blocks without departing from the scope of the proposed method.

[0039] The accompanying drawings are used to help easily understand various technical features and it is understood that the embodiments presented herein are not limited by the accompanying drawings. As such, the proposed method is construed to extend to any alterations, equivalents and substitutes in addition to those which are particularly set out in the accompanying drawings. Although the terms first, second, etc. used herein to describe various elements, these elements are not be limited by these terms. These terms are generally used to distinguish one element from another.

[0040] The terms transmit, receive, and communicate, as well as derivatives thereof, encompass both direct and indirect communication. The terms include and comprise, as well as derivatives thereof, mean inclusion without limitation. The term or is inclusive, meaning and / or. The phrase associated with, as well as derivatives thereof, means to include, be included within, interconnect with, contain, be contained within, connect to or with, couple to or with, be communicable with, cooperate with, interleave, juxtapose, be proximate to, be bound to or with, have, have a property of, have a relationship to or with, or the like. The term controller means any device, system, or part thereof that controls at least one operation. Such a controller may be implemented in hardware or a combination of hardware and software and / or firmware. The functionality associated with any particular controller may be centralized or distributed, whether locally or remotely. As used herein, such terms as 1st and 2nd or first and second may be used to simply distinguish a corresponding component from another and do not limit the components in other aspects (e.g., importance or order). It is to be understood that if an element (e.g., a first element) is referred to with or without the term operatively or communicatively as coupled with, coupled to, connected with, or connected to another element (e.g., a second element), it means that the element may be coupled with the other element directly (e.g., wiredly), wirelessly, or via a third element.

[0041] For a 5G system with satellite access, the following requirements apply: the 5G system shall support service continuity between NR terrestrial access network and NR satellite access networks owned by the same operator or owned by two different operators having an agreement. The NTN and TN could either operate in two different frequency bands (e.g., FR1 vs FR2) or in the same frequency band (e.g., FR1 or FR2).

[0042] The terms satellite 3GPP access, satellite access, satellite access network, NR satellite access network, satellite NG-RAN access technology, and NR Satellite access have been interchangeably used and have the same meaning. The methods, issues, or solutions disclosed in this embodiment are explained using NR satellite access or Satellite NG-RAN Access Technology as an example and are not restricted or limited to NR Satellite access only. However, the solutions proposed in this embodiment are also applicable for Satellite E-UTRAN access Technology NB (Narrow Band)-S1 mode or WB (Wide Band)-S1 mode via satellite E-UTRAN access and / or NB-IOT (Narrowband Internet of Things) or WB-IOT (Wideband Internet of Things) Satellite Access / Architecture. The solutions which are defined for NR (5GC) are also applicable to legacy RATs like E-UTRA / LTE; the corresponding CN entities need to be replaced by LTE entities, e.g., AMF with MME, g-nodeB with e-nodeB, UDM with HSS, etc. But principles of the solution remain the same. In a similar way, the solutions or proposals which are defined for LTE (EPC) are also applicable to other RAT(s) (e.g., 5G or 5GC and other RATs).

[0043] An example list of NAS messages can be, but not limited to, REGISTRATION REQUEST message, DEREGISTRATION REQUEST message, SERVICE REQUEST message, CONTROL PLANE SERVICE REQUEST, IDENTITY REQUEST, AUTHENTICATION REQUEST, AUTHENTICATION RESULT, AUTHENTICATION REJECT, REGISTRATION REJECT, DEREGISTRATION ACCEPT, SERVICE REJECT, SERVICE ACCEPT, and so on. The Network used in this embodiment is explained using any 5G Core Network Function, e.g., AMF. However, the network could be any 5G / EUTRAN Core Network Entities like AMF / SMF / MME / UPF, or the Network could be any 5G / EUTRAN RAN Entity like eNodeB (eNB) or gNodeB (gNB) or NG-RAN, etc. The messages used or indicated in this embodiment are shown as an example. The messages could be any signaling messages between UE and the Network Functions / Entities or between different Network functions / entities. The terms area / location / geographical area used in this embodiment may refer to any of cell / cell ID, TAC / TAI, PLMN, MCC / MNC, Latitude / longitude, CAG cell, or any geographical location / coordinate.

[0044] The methods, issues, or solutions disclosed in this embodiment are explained using NR access or NG-RAN Access Technology as an example and are not restricted or limited to NR access only. However, the solutions proposed in this embodiment are also applicable for E-UTRAN access Technology NB (Narrow Band)-S1 mode or WB (Wide Band)-S1 mode via E-UTRAN access and / or NB-IOT (Narrowband Internet of Things) or WB-IOT (Wideband Internet of Things) Access / Architecture. The solutions which are defined for NR (5GC) are also applicable to legacy RATs like E-UTRA / LTE; the corresponding CN entities need to be replaced by LTE entities, e.g., AMF with MME, g-nodeB with e-nodeB, UDM with HSS, etc. But principles of the solution remain the same. The Network used in this embodiment is explained using any 5G Core Network Function, e.g., AMF. However, the network could be any 5G / EUTRAN Core Network Entities like AMF / SMF / MME / UPF, or the Network could be any 5G / EUTRAN RAN Entity like eNodeB (eNB) or gNodeB (gNB) or NG-RAN, etc. The messages used or indicated in this embodiment are shown as an example. The messages could be any signaling messages between UE and the Network Functions / Entities or between different Network functions / entities.

[0045] The terms camp and register are used interchangeably and have the same meaning. The term area as used in this embodiment may refer to any of cell / cell ID, TAC / TAI, PLMN, MCC / MNC, Latitude / longitude, any CAG / CAG identifier, or any geographical location / coordinate. The UE location or UE area as used in this embodiment may refer to any of cell / cell ID, TAC / TAI, PLMN, MCC / MNC, Latitude / longitude, any CAG / CAG identifier, or any geographical location / coordinate. For the list of possible NAS messages, please refer to 3GPP TS 24501 or 3GPP TS 24301; for the list of AS messages, please refer to 3GPP TS 38331 or 3GPP TS 36331. The cause names in this embodiment are for illustration purposes and can have any name. The Non-Access Stratum (NAS) messages and Access Stratum (AS) messages described in this embodiment are only for illustration purposes; they can be any NAS or AS messages as per the defined protocol between UE and AMF / MME or UE and gNB (NG-RAN / any RAN node) / eNB.

[0046] In an embodiment, the term Satellite is used interchangeably with 5G or 4G system with satellite access and is used to represent any Satellite(s) or constellation of Satellites(s) or any aerial body / satellite in any of the Satellite orbits (e.g., LEO / MEO / GEO / HEO, etc.) or any 5G system with Satellite Access or 4G System with Satellite Access or any RAN Entity or Core Network Entity or any Network Function(s) associated with the Satellite Access / RAT / PLMN / Network. The terms MME / AMF On-board and MME / AMF-lighter are used interchangeably in this embodiment and have the same meaning. The terms SAT and Satellite are used interchangeably in this embodiment and have the same meaning. The Network used in this embodiment is explained using any EPS Core Network Function, e.g., MME. However, the network could be any 5G / EUTRAN Core Network Entities like AMF / SMF / MME / UPF, or the Network could be any 5G / EUTRAN RAN Entity like eNodeB (eNB) or gNodeB (gNB) or NG-RAN, etc.

[0047] In an embodiment, an example list of NAS messages includes but is not limited to REGISTRATION REQUEST message, DEREGISTRATION REQUEST message, SERVICE REQUEST message, CONTROL PLANE SERVICE REQUEST, IDENTITY REQUEST, AUTHENTICATION REQUEST, AUTHENTICATION RESULT, AUTHENTICATION REJECT, REGISTRATION REJECT, DEREGISTRATION ACCEPT, SERVICE REJECT, SERVICE ACCEPT, UE CONFIGURATION UPDATE command, UE PARAMETERS UPDATE command.

[0048] The term 5GMM sublayer states in this embodiment are at least one of 5GMM-NULL, 5GMM-DEREGISTERED, 5GMM-DEREGISTERED-NORMAL-SERVICE, 5GMM-DEREGISTERED-LIMITED-SERVICE, 5GMM-DEREGISTERED-ATTEMPTING-REGISTRATION, 5GMM-DEREGISTERED-PLMN-SEARCH, 5GMM-DEREGISTERED-NO-SUPI, 5GMM-DEREGISTERED-NO-CELL-AVAILABLE, 5GMM-DEREGISTERED-eCALL-INACTIVE, 5GMM-DEREGISTERED-INITIAL-REGISTRATION-NEEDED, 5GMM-REGISTERED-INITIATED, 5GMM-REGISTERED, 5GMM-REGISTERED-NORMAL-SERVICE, 5GMM-REGISTERED-NON-ALLOWED-SERVICE, 5GMM-REGISTERED-ATTEMPTING-REGISTRATION-UPDATE, 5GMM-REGISTERED-LIMITED-SERVICE, 5GMM-REGISTERED-PLMN-SEARCH, 5GMM-REGISTERED-NO-CELL-AVAILABLE, 5GMM-REGISTERED-UPDATE-NEEDED, 5GMM-DEREGISTERED-INITIATED, 5GMM-SERVICE-REQUEST-INITIATED.

[0049] In an embodiment, the term EMM sublayer states are at least one of EMM-NULL, EMM-DEREGISTERED, EMM-DEREGISTERED-NORMAL-SERVICE, EMM-DEREGISTERED-LIMITED-SERVICE, EMM-DEREGISTERED-ATTEMPTING-TO-ATTACH, EMM-DEREGISTERED-PLMN-SEARCH, EMM-DEREGISTERED-NO-IMSI, EMM-DEREGISTERED-ATTACH-NEEDED, EMM-DEREGISTERED-NO-CELL-AVAILABLE, EMM-DEREGISTERED-eCALL-INACTIVE, EMM-REGISTERED-INITIATED, EMM-REGISTERED, EMM-REGISTERED-NORMAL-SERVICE, EMM-REGISTERED-ATTEMPTING-TO-UPDATE, EMM-REGISTERED-LIMITED-SERVICE, EMM-REGISTERED-PLMN-SEARCH, EMM-REGISTERED-UPDATE-NEEDED, EMM-REGISTERED-NO-CELL-AVAILABLE, EMM-REGISTERED-ATTEMPTING-TO-UPDATE-MM, EMM-REGISTERED-IMSI-DETACH-INITIATED, EMM-DEREGISTERED-INITIATED, EMM-TRACKING-AREA-UPDATING-INITIATED, EMM-SERVICE-REQUEST-INITIATED.

[0050] The term RAT as defined in this embodiment can be one of NG-RAN, 5G, 4G, 3G, 2G, EPS, 5GS, NR, NR in unlicensed bands, NR (LEO) satellite access, NR (MEO) satellite access, NR (GEO) satellite access, NR (OTHER-SAT) satellite access, NR RedCap, E-UTRA in unlicensed bands, NB-IoT, WB-IoT, LTE-M.

[0051] 5GS registration types are initial registration, mobility registration updating, periodic registration updating, emergency registration, SNPN onboarding registration, disaster roaming initial registration, or disaster roaming mobility registration updating.

[0052] In an embodiment, not setting the registration type to disaster roaming initial registration or disaster roaming mobility registration updating means 5GS registration type is set to a value other than "disaster roaming initial registration" or "disaster roaming mobility registration updating," at least one of the above 5GS registration types excluding disaster roaming initial registration and disaster roaming mobility registration updating.

[0053] Visited PLMN (VPLMN): This is a PLMN different from the HPLMN (if the EHPLMN list is not present or is empty) or different from an EHPLMN (if the EHPLMN list is present).

[0054] Allowable PLMN: In the case of an MS operating in MS operation mode A or B, this is a PLMN which is not in the list of "forbidden PLMNs" in the MS. In the case of an MS operating in MS operation mode C or an MS not supporting A / Gb mode and not supporting Iu mode, this is a PLMN which is not in the list of "forbidden PLMNs" and not in the list of "forbidden PLMNs for GPRS service" in the MS.

[0055] Available PLMN: PLMN(s) in the given area which is / are broadcasting capability to provide wireless communication services to the UE.

[0056] Camped on a cell: The MS (ME if there is no SIM) has completed the cell selection / reselection process and has chosen a cell from which it plans to receive all available services. Note that the services may be limited, and that the PLMN or the SNPN may not be aware of the existence of the MS (ME) within the chosen cell.

[0057] EHPLMN: Any of the PLMN entries contained in the Equivalent HPLMN list.

[0058] Equivalent HPLMN list: To allow provision for multiple HPLMN codes, PLMN codes that are present within this list shall replace the HPLMN code derived from the IMSI for PLMN selection purposes. This list is stored on the USIM and is known as the EHPLMN list. The EHPLMN list may also contain the HPLMN code derived from the IMSI. If the HPLMN code derived from the IMSI is not present in the EHPLMN list then it shall be treated as a Visited PLMN for PLMN selection purposes.

[0059] Home PLMN: This is a PLMN where the MCC and MNC of the PLMN identity match the MCC and MNC of the IMSI.

[0060] Registered PLMN (RPLMN): This is the PLMN on which certain LR (location registration which is also called as registration procedure) outcomes have occurred. In a shared network the RPLMN is the PLMN defined by the PLMN identity of the CN operator that has accepted the LR.

[0061] Registration: This is the process of camping on a cell of the PLMN or the SNPN and doing any necessary LRs.

[0062] UPLMN: PLMN / access technology combination in the "User Controlled PLMN Selector with Access Technology" data file in the SIM (in priority order).

[0063] OPLMN: PLMN / access technology combination in the "Operator Controlled PLMN Selector with Access Technology" data file in the SIM (in priority order) or stored in the ME (in priority order).

[0064] Feeder Link: Feeder link can be defined as　a wireless link between the NTN Gateway and the satellite.

[0065] Service Link: Service link is the radio link between a user equipment (UE) and a Satellite.

[0066] serving satellite: a satellite providing the satellite access to an UE. In the case of NGSO (Non-Geostationary Satellite Orbit), the serving satellite is always changing due to the nature of the constellation.

[0067] Store & Forward Satellite operation: in the context of this study, it is an operation mode of a 5G system with satellite-access where the 5G system can provide some level of service (in storing and forwarding the data) when satellite connectivity is intermittently / temporarily unavailable, e.g. to provide communication service for UEs under satellite coverage without a simultaneous active feeder link connection to the ground segment.

[0068] S&F data retention period: it is the data storage validity period for the 5G system with satellite access supporting store and forward operation (e.g. after which undelivered data stored is being discarded).

[0069] UE-Satellite-UE Communication: for the 5G system with satellite access, it refers to the communication between UEs under the coverage of one or more serving satellites, using satellite access without going through the ground segment

[0070] The methods, systems, issues, or solutions disclosed in this embodiment are explained using NR access or NG-RAN Access Technology as an example and are not restricted or limited to NR access only. Solutions proposed in this embodiment are also applicable for E-UTRAN access Technology, NB (Narrow Band)-S1 mode, or WB (Wide Band)-S1 mode via E-UTRAN access and / or NB-IOT (Narrowband Internet of Things) or WB-IOT (Wideband Internet of Things) Access / Architecture. Solutions defined for NR (5GC) are also applicable to legacy RATs like E-UTRA / LTE, with the corresponding CN entities needing to be replaced by LTE entities, for example, AMF with MME, g-nodeB with e-nodeB, UDM with HSS, etc. However, the principles of the solution remain the same.

[0071] Any 5G Core Network Function, such as AMF, is used to explain the network in this embodiment. The network apparatus could be any of the 5G / EUTRAN Core Network Entities like AMF / SMF / MME / UPF or any 5G / EUTRAN RAN Entity like eNodeB (eNB) or gNodeB (gNB) or NG-RAN, etc. Messages used or indicated in this embodiment are shown as examples and could be any signaling messages between the UE and the network apparatus or between different network apparatus.

[0072] The term "area" as used in this embodiment may refer to any of cell / cell ID, TAC / TAI, PLMN, MCC / MNC, Latitude / longitude, any CAG / CAG identifier, or any geographical location / coordinate. Cause names in this embodiment are for illustration purposes and can have any name. NAS messages and AS messages described in this embodiment are only for illustration purposes and can be any NAS or AS messages as per the defined protocol between UE and AMF / MME or UE and gNB (NG-RAN / any RAN node) / eNB.

[0073] The term "Satellite" is used interchangeably with 5G or 4G systems with satellite access and represents any Satellite(s) or constellation of Satellites(s) or any aerial body / satellite in any of the Satellite orbits (for example, LEO / MEO / GEO / HEO, etc.) or any 5G system with Satellite Access or 4G System with Satellite Access or any RAN Entity or Core Network Entity or any Network Function(s) associated with the Satellite Access / RAT / PLMN / Network.

[0074] In an embodiment, the term "satellite" represents at least one of the NF or gNB onboard from a 3GPP perspective. The onboard satellite MME part or satellite access as used or defined in this embodiment is applicable for both 5G systems with satellite access and / or 4G systems with satellite access or any RAT with satellite access.

[0075] MME onboard and MME on the ground are used as examples in an embodiment, but this same concept can be applied to any of the network functions (NFs). The list of NFs includes SMF / PCF / UDM / AUSF / MME / P-GW / S-GW / HSS / NEF / SCEF. A Control Plane NF is composed of one or multiple NF Services. Within an NF, an NF service may have multiple instances. These multiple NF Service instances can be grouped into an NF Service Set if they are interchangeable with each other because they share the same context data. The ground NF (e.g., MME / AMF) can also be treated as a UDSF function with whom UE context data is synchronized by all the NFs onboard the satellite.

[0076] In existing methods, the HSS, upon successful execution of a new attach procedure of a UE, cancels the location of the UE with the old MME (with which the UE was last attached). The old MME deletes the session with the SGW and PGW. When a UE is performing S / F attach, the UE's attach request and other updates reach the ground MME and HSS with a significant delay. Due to this delay, the UE may perform attach with another MME while the HSS is updated on the UE's S / F attach status in the location update request. In such cases, the HSS may not be able to determine the MME with which the UE attached first. The MME may end up deleting the context of the UE with the new MME as the request from the old MME may be received at a later time due to the delay explained before.

[0077] Embodiments disclosed herein provide a system and method for handling UE context using request time. In general, any interaction MME does with HSS, optionally for S / F, a UE should include request time in the message / indication sent to HSS so that HSS knows about the time at which this request was generated / completed. In another embodiment, the HSS optionally provides a new reject cause to the MME to indicate that the update location request is not the latest one and the UE has attached to another MME. Based on this reject cause, the MME will delete the UE context, e.g., MM context, bearer context, etc. The MME on the ground sends the reject cause to the MME onboard. The MME onboard optionally gives a reject cause to the UE. In general, the HSS, after determining that the requesting MME is not the latest one based on the update location request or any other request, will signal / provide indication / send a message to the MME indicating that the MME is not the latest. Based on this, the MME will delete the UE context.

[0078] The term "satellite" used in this embodiment means the satellite and the NF onboard the satellite. The term "satellite" may refer to any of the LEO, MEO, GEO, HEO Satellites. The terms MME-ground, MME-onboard, and MME are used interchangeably and have the same meaning considering the interface between MME-onboard and MME-ground is based on the implementation. The terms S / F, S&F, S and F, and Store and Forward are used interchangeably and have the same meaning.

[0079] In an embodiment, the terms MME-onboard and onboard satellite MME part are used interchangeably. In another embodiment, MME / AMF onboard is used as an example. It can be any other 5GC network function (NF) or EPC CN Node or any new function. It may be with full functionality or limited functionality to fulfill the requirement of S / F operation.

[0080] Referring now to the drawings and more particularly to Figs. 1 through 9, where similar reference characters denote corresponding features consistently throughout the figure, these are shown preferred embodiments.

[0081] Fig. 1 is a schematic diagram illustrating the normal / default satellite operation mode of a 5G system with satellite access according to the prior art. This figure depicts the signaling and data traffic exchange between the UE (100) and the network apparatus (105) under normal / default service conditions. Under normal service, the signaling and data traffic exchange between the UE (100) and the ground station (102) require the service link and the feeder links to be active simultaneously. Consequently, when the UE (100) interacts over the service link with the satellite network (101), there is a continuous end-to-end connectivity path between the UE (100), the satellite network (101), and the ground station (102).

[0082] Fig. 2 is a schematic diagram illustrating the S&F satellite operation mode of the 5G system with satellite access according to the prior art. The end-to-end signaling and data traffic exchange between the UE (100) and the ground station (102) through the S&F mode is depicted. The S&F mode, as illustrated in Fig. 2, handles the end-to-end exchange of signaling and data traffic as a combination of two steps that are not concurrent in time. In step S201, signaling and data traffic exchange between the UE (100) and the Onboard Satellite MME part (101) occurs without the Onboard Satellite MME part (101) being simultaneously connected to the ground station (102), meaning the satellite can operate the service link without an active feeder link connection. Subsequently, connectivity between the Onboard Satellite MME part (101) and the ground station (102) is established, allowing communication between the satellite network (101) and the ground station (102). Thus, the Onboard Satellite MME part (101) transitions from being connected to the UE (100) in step S201 to being connected to the ground station (102) in step S202.

[0083] The store and forward (S&F) satellite operation in a 5G system with satellite access aims to provide some level of communication service for UEs under satellite coverage with intermittent or temporary satellite connectivity. This is particularly useful when the satellite is not connected via a feeder link or via ISL to the ground network, facilitating delay-tolerant communication services.

[0084] An example of S&F satellite operation is illustrated in Fig. 2, contrasting with the current assumption for the normal / default satellite operation of a 5G system with satellite access as shown in Fig. 1. Under normal / default satellite operation mode, signaling and data traffic exchange between a UE with satellite access and the remote ground network requires the service and feeder links to be active simultaneously. When the UE interacts over the service link with the satellite, there is a continuous end-to-end connectivity path between the UE, the satellite, and the ground network. In contrast, under S&F satellite operation mode, the end-to-end exchange of signaling and data traffic is managed as a combination of two steps that are not concurrent in time. In Step S201, signaling and data exchange between the UE and the satellite occur without the satellite being simultaneously connected to the ground network, allowing the satellite to operate the service link without an active feeder link connection. In Step S202, connectivity between the satellite and the ground network is established, enabling communication between the satellite and the ground network. Thus, the satellite transitions from being connected to the UE in step S201 to being connected to the ground network in step S202.

[0085] Fig. 3 is a high-level overview of UE-Satellite-UE communication according to the prior art. The UE-Satellite-UE (UE-SAT-UE) communication refers to communication between UEs under the coverage of the same or different serving satellites using satellite access, where the user traffic is transferred between the UEs without transiting through the ground segment. The UE 1 (100a) is accessing via a satellite (constellation) that has gNB, UPF, and IMS-AGW onboard. The other UE, UE 2 (100b), is also accessing via the same satellite (constellation) that has gNB, UPF, and IMS-AGW onboard, and both the UEs' serving satellite (constellation) can communicate. But the satellite (101) is not connected with the remote Data Network (DN) due to the unavailability of the feeder link.

[0086] Fig. 4 is an example of a high-level overview of satellite network, terrestrial network, and UE communication architecture according to the prior art. The figure illustrates the sequence of the UE attach procedure followed by location update at the HSS at different timelines. At step 1, the UE (100) sends an attach request to onboard MME (101) at 10 AM. The onboard MME waits for the feeder link availability and sends the location update request to the first MME-ground at 12 AM, as illustrated at step 2. Further, the first MME-ground interacts with HSS, and the attach is completed at 4 PM. But the update location request is shared with the HSS by the onboard MME (101) at 6 PM. Meanwhile, the UE initiates the attach procedure with the MME 2 at 5 PM, which reaches the HSS at 5 PM. The update location request for the MME 2 (103) is also shared at 5 PM. The HSS tracks that the MME 2 is the MME where the UE is registered to. But as the update location request of the first MME-ground reaches the HSS at 6 PM, the HSS (104) now accepts this request from MME 2 (103), which is latest received at the HSS, and accepts the update location request from the first MME-ground (102). Consequently the HSS will start considering that first MME is the MME which is serving the UE(but actually the UE is served by the MME-2) and it will wrongly send the cancel / delete context request to the MME-2(which is actually serving the UE) and the UE context at MME-2 will be deleted thus UE will be in no service from network perspective. i.e. Although UE attach in S / F mode was completed at 4 PM, the location update request reaches HSS only at 6 PM. Meanwhile, UE performs another attach at 5 PM with the terrestrial network(TN) network; the location update request for this reaches HSS at 5 PM. The HSS finds the location update request received at 6 PM to be the latest one, but actually, the latest attach for UE was done at 5 PM. This results in service unavailability for the UE. The update location to HSS from MME ground reaches very late because its serving in S&F mode whereas the one from MME-2 reaches almost same time of attach with UE because it is served using terrestrial network or NTN not in S&F mode.

[0087] FIG. 5 is a sequence diagram that illustrates handling UE context using request time according to the prior art. At step S501, the S&F mode supporting UE (100) sends an attach request to the S&F supporting onboard satellite MME (101) operating in S&F mode at time t1. The onboard satellite MME (101) stores the attach request from the UE (100) and waits for feeder link availability to fetch UE context and authentication vectors from the ground HSS. The onboard satellite MME (101) provides a temporary GUTI to the UE (100) or provides an acknowledgment to the UE (100) to let the UE (100) know that the attach procedure is under process.

[0088] In some cases, the UE (100) sends an attach request and receives an attach reject from the network with a back-off timer. The UE (100) attempts to attach again after the expiry of the back-off timer. The satellite(s) fetch the UE context from the ground station after sending the reject, and the attach is completed when the UE (100) again attempts to attach after the expiry of the back-off timer.

[0089] At step S502, at time t2, the onboard satellite MME (101), upon establishment of a feeder link with MME 1 (102), sends the stored attach request to the MME 1 (102). At steps S503 and S504, the MME 1 (102) fetches the UE context and authentication vectors and optionally subscription information for the UE (100) from the HSS (104). The HSS (104) provides the MME 1 (102) with all the necessary information to process the attach or any other NAS / AS message received from the UE (100).

[0090] At step S505, the MME 1 (102) sends the UE context and authentication vectors and optionally subscription information to the onboard satellite MME (101), the same or a different satellite. The satellite, upon reaching the UE location at time t3, pages the UE (100) with the temporary GUTI provided earlier. In another case, the satellite waits for the UE (100) to initiate attach again (upon expiry of the back-off timer). The UE (100) completes the attach procedure (or any other NAS / AS procedure) with the satellite, and the satellite is able to process the attach with the fetched context and authentication vectors.

[0091] Further, from steps S507 to S510, the UE (100), after some time, i.e., at t4, comes into coverage of the TN network (or another satellite which is providing normal services, i.e., not S&F) of the same PLMN and performs the attach procedure with it using a new MME (MME2) (103). At step S510, the new MME (MME 2) (103) performs an HSS location update, and the HSS (104) maintains the UE (100) as registered with the new MME (103). The HSS (104) acknowledges the Update Location message by sending an Update Location Ack (IMSI Subscription data) message to the new MME (103).

[0092] At step S511, at time t5, the onboard satellite MME (101) sends the update location request to MME 1 (102) (i.e., MME on the ground) which was for attach completed at t3. At step S512, the MME 1 (102) sends / forwards the update location request to the HSS (104). At step S513, the HSS (104), upon receiving the location update request, sends a cancel location to MME 2 (103). The new MME (103) deletes the UE context, and the UE (100) is internally detached from the MME 2 (103). The MME 2 (103) acknowledges with Cancel Location Ack (IMSI) and removes the MM and bearer contexts. The MME 2 (103) sends a delete session request to the PDN GW and deletes the bearer context. The HSS (104) acknowledges the Update Location message by sending an Update Location Ack (IMSI Subscription data) message to the MME 2 (103).

[0093] The HSS (104) considers the UE to be attached to the onboard satellite MME (101) and deletes the UE context with the new MME (103). However, the UE (100) has registered with the MME 2 (103) later and considers itself attached to the second MME (103).

[0094] Fig. 6 is a block diagram that illustrates the hardware features associated with the HSS apparatus according to the embodiments as disclosed herein.

[0095] In an embodiment, the examples of the UE (200) can include, but are not limited to, Consumer Electronics (such as Mobile Phones and Smartphones), Tablets, Wearable Devices, Computing Devices (such as Laptops, Notebooks, Desktops, Workstations, etc.), IoT Devices, Automotive Systems (such as connected cars, Autonomous Vehicles, Vehicle-to-Everything (V2X) communication devices, etc.), Enterprise Devices such as robotics, Specialized Equipment (such as Medical Devices, Public Safety Devices, etc.), Media Devices (such as Gaming Consoles, Streaming Devices, etc.). Further, the first UE (105) and the second UE (106) can belong to the same user or different users.

[0096] Examples of the wireless communication network system include, but are not limited to, Cellular Networks (such as 2G, 3G, 4G, 5G, Beyond 5G (B5G) / 6G or advanced cellular networks), Local Area Networks (LANs) (such as Wi-Fi, Li-Fi, etc.), Personal Area Networks (PANs) (such as Bluetooth, Zigbee, Z-Wave, etc.), Wide Area Networks (WANs) (such as Satellite Communication Networks, Long Range Wide Area Network, Narrowband IoT, Low-bandwidth communication for IoT, etc.), Metropolitan Area Networks (MANs), Machine-to-Machine (M2M), Ad Hoc and Mesh Networks, Emerging and Advanced Networks.

[0097] The HSS apparatus (600) comprises the subscription-related information to support the network entities actually handling calls / sessions. The Home Network may contain one or several HSSs; it depends on the number of mobile subscribers, on the capacity of the equipment, and on the organization of the network. As an example, the HSS apparatus (600) provides support to the call control servers in order to complete the routing / roaming procedures by solving authentication, authorization, naming / addressing resolution, location dependencies, etc. The HSS apparatus (600) can encompass a diverse range of devices including, but not limited to, Mobility Management Entity (MME), Serving Gateway (SGW), Packet Data Network Gateway (PDN Gateway), Unified Data Management (UDM), Access and Mobility Management (AMF), Authentication Server Function (AUSF), among others. In an embodiment, the HSS apparatus (600) includes a memory (601), a processor (602), an I / O interface (604), and a location management controller (603).

[0098] The memory (601) stores instructions to be executed by the processor (602). The memory (601) can include non-volatile storage elements. Examples of such non-volatile storage elements may include magnetic hard disks, optical disks, floppy disks, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories. In addition, the memory (601) may in some examples be considered a non-transitory storage medium. The term non-transitory may indicate that the storage medium is not embodied in a carrier wave or a propagated signal. However, the term non-transitory should not be interpreted that the memory (601) is non-movable. In some examples, the memory (601) stores larger amounts of information. In certain examples, a non-transitory storage medium may store data that can over time change (e.g., in Random Access Memory (RAM) or cache). The memory (601) stores the subscriber information, MME Identity, MME capabilities, International Mobile Subscriber Identity (IMSI), Update Location Timestamp, UE capabilities, handover information, and others.

[0099] The processor (602) may include one or a plurality of processors. The one or the plurality of processors may be a general-purpose processor such as a central processing unit (CPU), an application processor (AP), or the like, a graphics-only processing unit such as a graphics processing unit (GPU), a visual processing unit (VPU), and / or an AI-dedicated processor such as a neural processing unit (NPU). The processor (602) may include multiple cores and is configured to execute the instructions stored in the memory (601). The processor (602) fetches the subscriber information, MME Identity, MME capabilities, timestamp, and others. Further, the processor (602) retrieves instructions and executes them.

[0100] The I / O interface (604) transmits the information between the memory (601) and external peripheral devices. The peripheral devices are the input-output devices associated with the network apparatus (201). The I / O interface (604) receives several pieces of information from a plurality of UEs, network devices, servers, and the like. The I / O interface (604) ensures that the operating speed of the processor is synchronized with respect to the input and output devices. The I / O interface (604) establishes a connection between different peripheral devices like the location management controller (603), memory (601), and others to handle the UE context for any scenario-specific action like update location procedure, Tracking Area Update (TAU) procedure, or any other functions of the UE attachment.

[0101] In an embodiment, the location management controller (603) of the HSS apparatus (600) communicates with the processor (602), the I / O interface (604), and the memory (601) for handling UE context in the wireless network system. The location management controller (603) receives the Update Location Procedure Request message from the first MME (400). The update location procedure request message comprises a first timestamp indicating an interaction of the first MME (400) with the UE (200). The location management controller (603) compares the first timestamp received from the first MME (400) with a second timestamp stored at the HSS apparatus (600). The comparison is performed using a timestamp comparison algorithm implemented in the processor (602) to ensure synchronization of UE context. Further, the HSS apparatus (600) accepts the Update Location Procedure Request message received from the first MME (400) when the first timestamp is newer than or equal to the second timestamp. If the first timestamp is older than the second timestamp, the HSS apparatus (600) rejects the Update Location Procedure Request message received from the first MME (400). The rejection process includes generating a reject cause code that is communicated back to the first MME (400) to inform it of the reason for rejection.

[0102] In an embodiment, the first timestamp is a time when the onboard satellite MME part received a Non-Access Stratum (NAS) procedure request from the UE (200), and where the second timestamp is a timestamp associated with the latest Update Location Request accepted by the HSS apparatus (600). The NAS procedure request may include various types of signaling messages such as attach requests, authentication requests, or location update requests. The onboard satellite MME part is equipped with a high-precision clock for timestamping of NAS procedure requests. The second timestamp stored at the HSS apparatus (600) is updated based on the most recent successful interaction with the UE (200), ensuring that the network maintains an up-to-date record of UE activity.

[0103] In an embodiment, the HSS apparatus (600) updates the second timestamp stored at the HSS apparatus (600) to the first timestamp when the Update Location Request message is accepted. This update process includes writing the new timestamp value to a specific memory location within the HSS apparatus (600) designated for storing UE interaction timestamps. Further, the HSS apparatus (600) stores the first timestamp associated with the latest Update Location Request message and UE context information when the request is accepted. The UE context information may include details such as the UE's IMSI, current serving cell ID, and subscription data. This information is stored in a structured format within the memory (601) to facilitate retrieval and processing during subsequent network operations.

[0104] In an embodiment, the location management controller (603) sends the cancel Update Location Request to the second MME (500) when the first timestamp is newer than or equal to the second timestamp. The cancel Update Location Request message is transmitted using a secure communication protocol. The location management controller (603) optionally transmits the reject cause code to the first MME upon rejecting the Update Location Request of the first MME and transmitting a cancel update location procedure request message. The reject cause code is generated based on predefined criteria and is included in the message payload to provide detailed information about the rejection reason.

[0105] In an embodiment, the location management controller (603) assigns the present time of reception of the Update Location Request message from the first MME (400) as the first timestamp, when the timestamp corresponding to the first MME (400) is not included in the Update Location Request message. The time of reception is determined using the system clock of the HSS apparatus (600) and is recorded in the memory (601) for future reference. This assignment process allow the HSS apparatus (600) to track the timing of interactions with the first MME (400) even in the absence of an explicit timestamp. The assigned time of reception is used in subsequent timestamp comparisons to maintain synchronization of UE context within the network.

[0106] Fig. 7 is a block diagram that illustrates the hardware features associated with the first MME (400) according to the embodiments as disclosed herein. The term first MME (400) is used for illustration only and can include any network entity that shares the Update Location Request message to the HSS apparatus (600). The first MME (400) used in the embodiment can be explained using any 5G Core Network Function, for example, MME, AMF. However, the network could be any 5G / EUTRAN Core Network Entities like AMF / SMF / MME / UPF, or the Network could be any 5G / EUTRAN RAN Entity like eNodeB (eNB) or gNodeB (gNB) or NG-RAN, etc. The messages used or indicated in this embodiment are shown as an example. The messages could be any signaling messages between UE and the Network Functions / Entities or between different Network functions / entities. The terms area / location / geographical area used in this embodiment may refer to any of cell / cell ID, TAC / TAI, PLMN, MCC / MNC, Latitude / longitude, CAG cell, or any geographical location / coordinate. The term ACK (or acknowledgment) in this embodiment should be treated as one of the NAS / AS messages. For example, when the UE sends an Attach / TAU request message, MME-onboard the satellite may send the UE with attach accept or TAU accept with the minimal context MME / AMF is holding. Later, MME / AMF-onboard will deliver the NAS message to the ground MME / AMF. The ground MME / AMF will start executing the procedure, and once the procedure is executed, the MME / AMF will provide the attach accept / tau accept / registration accept message, which will have all the contents required by the UE to create the UE context.

[0107] The First MME comprises a memory (401), a processor (402), a location management controller (403), and an I / O interface (404).

[0108] The memory (401) stores instructions to be executed by the processor (402). The memory (401) can include non-volatile storage elements. Examples of such non-volatile storage elements may include magnetic hard disks, optical disks, floppy disks, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories. In addition, the memory (401) may, in some examples, be considered a non-transitory storage medium. The term non-transitory may indicate that the storage medium is not embodied in a carrier wave or a propagated signal. However, the term non-transitory should not be interpreted that the memory (401) is non-movable. In some examples, the memory (401) stores larger amounts of information. In certain examples, a non-transitory storage medium may store data that can over time change (e.g., in Random Access Memory (RAM) or cache). The memory (401) stores the subscriber information, UE network capability, MME Identity, MM State, Globally Unique Temporary Identity (GUTI), UE Radio Capability for Paging Information, MME capabilities, International Mobile Subscriber Identity (IMSI), Update Location Timestamp, UE capabilities, handover information, and others.

[0109] The processor (402) may include one or a plurality of processors. The one or the plurality of processors may be a general-purpose processor such as a central processing unit (CPU), an application processor (AP), or the like, a graphics-only processing unit such as a graphics processing unit (GPU), a visual processing unit (VPU), and / or an AI-dedicated processor such as a neural processing unit (NPU). The processor (402) may include multiple cores and is configured to execute the instructions stored in the memory (401). The processor (402) fetches the subscriber information, MME Identity, MME capabilities, timestamp, and others. Further, the processor (402) retrieves instructions and executes them.

[0110] The I / O interface (404) transmits the information between the memory (401) and external peripheral devices. The peripheral devices are the input-output devices associated with the network apparatus (201). The I / O interface (404) receives several pieces of information from a plurality of UEs, network devices, servers, and the like. The I / O interface (404) ensures that the operating speed of the processor is synchronized with respect to the input and output devices. The I / O interface (404) establishes a connection between different peripheral devices like location management controller (403), memory (401), and others to handle the UE context for any scenario-specific action like update location procedure, Tracking Area Update (TAU) procedure, or any other functions of the UE attachment.

[0111] The location management controller (403) determines the first timestamp when the first MME (400) interacts with the UE (400) following a successful attach or Tracking Area Update (TAU) procedure. The timestamp is recorded in a high-precision format for tracking of the UE's movements. This interaction may include the exchange of authentication and security information, as well as the allocation of network resources to the UE. Further, the location management controller (403) generates an Update Location Request message by adding the first timestamp and transmits the Update Location Request message comprising the first timestamp to the HSS apparatus (600). The Update Location Request message is formatted according to the standardized protocol for communication between network elements, ensuring compatibility and interoperability. The HSS apparatus (600) uses the timestamp to update its records, which may include the UE's current location, status, and any relevant subscription information.

[0112] While Figs 6 and 7 illustrate the hardware components of the HSS apparatus (600) and the first MME (400) respectively, alternative embodiments may include different or additional components. The labels or names of these elements are illustrative and do not limit the invention's scope. Components may also be combined to perform similar functions.

[0113] The Fig 8 illustrates an example scenario of the sequence associated with the system for handling the UE context using a timestamp. At step S801, the S / F supporting UE (200) sends an attach request (or any other NAS message) to the S / F supporting satellite operating in S / F mode at time t1. The MME onboard the satellite stores the attach request from the UE and waits for feeder link availability to fetch UE context and authentication vectors from the ground (HSS). The onboard satellite MME part (300) provides a temporary GUTI to the UE (200) or provides an acknowledgment to the UE (200) to let the UE (200) know that the attach procedure is under process. The UE (200) optionally includes the request time in the attach request sent by the UE (200).

[0114] In an embodiment, the UE (200) sends an attach request and receives an attach reject from the network with a back-off timer. The UE (200) attempts to attach again after the expiry of the back-off timer. The satellite(s) fetch the UE context from the ground station after sending the reject, and the attach is completed when the UE (200) again attempts to attach after the expiry of the back-off timer.

[0115] At step S802, at time t2, the onboard satellite MME part (300), upon establishment of a feeder link with the second MME (500), sends the stored attach request to the second MME (500). The onboard satellite MME part (300) includes the request time (time at which the attach request was sent by UE) in the message sent to the second MME (500).

[0116] At steps S803 and S804, the second MME (500) fetches the UE context and Authentication Vectors and optionally subscription information for the UE from the HSS apparatus. The HSS apparatus (600) provides the second MME (500) with all the necessary information to process the attach or any other NAS / AS message received from the UE (200).

[0117] At step S805, the second MME (500) sends the UE context and authentication vectors and optionally subscription information to the MME onboard the same or different satellite. The UE authentication vectors include temporary authentication and key agreement data that enables the first MME to engage in AKA with a particular user.

[0118] Upon reaching the UE location at time t3, the onboard satellite MME part (300) pages the UE with the temporary GUTI provided earlier. In an embodiment, the satellite waits for the UE (200) to initiate attach again (upon expiry of the back-off timer). The UE (200) completes the attach procedure (or any other NAS / AS procedure) with the satellite, and the satellite is able to process the attach with fetched context and authentication vectors.

[0119] At steps S807 to S809, the UE (200), after some time at t4, comes into coverage of the TN network or another satellite providing normal services or S / F services of the same PLMN or different PLMN and performs the attach procedure with it (first MME). In general, the UE selects a cell and connects to a different MME, i.e., the first MME.

[0120] At step S810, the new MME (first MME) (400) performs an HSS location update, and the HSS apparatus (600) maintains the UE (200) as registered with the first MME (400). The HSS apparatus (600) acknowledges the Update Location Request message by sending an Update Location Ack (IMSI Subscription data) message to the first MME (400). In general, any interaction the MME has with the HSS apparatus (600), optionally for S / F UE, should include the request time in the message / indication sent to the HSS apparatus (600) so that the HSS apparatus (600) knows about the time at which this request was generated / completed.

[0121] At step S812, at time t5, when the feeder link is established, the onboard satellite MME part (300) sends the Update Location Request to the second MME (500) and includes the request time with the message, which was for attach completed at t3.

[0122] At step S813, the second MME (500) sends / forwards the update location request to the HSS and includes the request time as t3. In another embodiment, the request time included in the update location request by the MME on the ground is t1.

[0123] At steps S814 and S815, the HSS apparatus (600), upon receiving the Location Update Request or any other signal from the second MME (500), identifies that the request is not the latest one and the UE is currently registered with the first MME (400). The second MME sending the location update request is not the latest MME based on the indication provided by the MME (e.g., Request time or it can be called any other indication). Thus, the HSS apparatus indicates to the second MME (500) that it has to delete the UE context (e.g., MM context, bearer context, etc.) by sending the cancel location to the MME (e.g., MME-ground). The MME on the ground deletes the UE context, and the UE is internally detached from the second MME (500). The second MME (500) acknowledges with Cancel Location Ack (IMSI) and removes the MM and bearer contexts. The second MME (500) sends a delete session request to the PDN GW and deletes the bearer context. Optionally, the HSS acknowledges the Update Location message by sending an Update Location Ack, for example, with an indication to delete the UE context (e.g., MM context, bearer context, etc.) to the second MME (500). In an embodiment, the HSS apparatus may optionally provide a new reject cause to the second MME (500) to indicate that the update location request is not the latest one and the UE (200) has attached to some other MME. Based on this reject cause, the second MME will delete the UE context (e.g., MM context, bearer context, etc.).

[0124] The MME on the ground syncs with the MME onboard once the feeder link is established and updates the MME onboard. The MME onboard deletes the UE context and internally detaches the UE. In an embodiment, the MME on the ground sends the reject cause to the MME onboard. The MME onboard optionally gives a reject cause to the UE.

[0125] In general, the HSS apparatus (600), after determining that the requesting MME is not the latest one based on the update location request or any other request, will signal / provide indication / send a message to the MME indicating that the MME is not the latest. Based on this, the MME will delete the UE context.

[0126] In general, the MME should include a request time in the update location request message sent to the HSS apparatus (600), optionally for attach / TAU / service request signaling performed by the UE in S / F mode or any time when the MME determines to trigger the authentication procedure, so that the HSS apparatus (600), the onboard satellite MME part (300), or the first MME can determine the timestamp for the UE.

[0127] The timestamp can be any of the following:

[0128] Time at which attach message is received, detach request, Service Request, TAU at MME-onboard. The MME-onboard stores this as request time and provides it to MME-onground whenever it feeder link is established. (T1 in the diagram). In general this is the time MME receives the NAS message.

[0129] Time at which the attach procedure or any other NAS was successful (T3 in the diagram). The MME-onboard stores this as request time and provides it to MME-onground whenever it feeder link is established.

[0130] Time at which UE context and Authentication Vectors were fetched by the MME-onground from HSS apparatus (600). The MME-onground stores the request time and provides it to HSS apparatus (600) once attach or any other NAS procedure is completed. In another embodiment, the HSS apparatus (600) stores the request time, and later uses it to determine UE's location status and which MME UE is attached to.

[0131] Time at which UE initiated procedure was successful with onboard satellite MME part (300).

[0132] Time at which UE gets served at a location etc.

[0133] Time at which UE has initiated / sent a NAS message e.g. Attach message.

[0134] The timestamp (or any other indication / message / signal or NAS / AS message) sent by the first MME to HSS apparatus (600) indicating the time at which this message / indication / procedure was initiated / completed itself can act like an indication to HSS apparatus (600) to give back S&F related subscription data to MME. The HSS apparatus (600) upon receiving request time (or any other message) determines that the request is for S / F UE attach and provides S / F subscription information to the MME-onground / MME-onboard. The MME does not need to include any other indication if request time is present to indicate that the attach / NAS or AS procedure initiated by the UE is a S / F procedure and therefore HSS apparatus (600) will provide S / F subscription parameters to the MME.

[0135] The HSS apparatus (600) upon receiving the update location request:

[0136] Should send cancel location request to the old MME if the request time received in current update location request is later than the request time present in the last location update request. Store the request time present in current location update request along with UE context.

[0137] Should send cancel location request to the new MME if the request time received in current update location request is earlier than the request time present in the last location update request. Store the request time present in old location update request along with UE context.

[0138] If no request time is sent by the MME, then consider current time as the request time(i.e. this as latest request) or consider the request is coming from TN network thus it's the latest request, thus the MME sending the request is the correct and latest MME. If no request time was present in the last location update request, consider the time at which last location request was received as the request time for that Message / indication.

[0139] The procedure defined in this embodiment takes attach request / attach flow as an example. It could be any signaling requiring interaction with HSS apparatus (600). Example: Tracking area update request, detach request, Service Request, etc.

[0140] The terms Update Location Request and location update request are used interchangeably and have the same meaning.

[0141] The term 'request time' and the timestamp are used interchangeably and are used here as an example. This may be any other name such as 'receive time,' 'receipt time,' 'signaling time,' 'attach time,' etc. In general, it is the time at which any message is sent from UE or received at MME-onboard / MME on-ground, which can help identify which message / signal / procedure was started or completed first or the latest interaction with the network.

[0142] Fig 9 is a flow diagram that illustrates the method of handling UE context in the wireless communication. The method includes the reception of the timestamp in the last Update Location Request message or the time when the last Update Location Request message if the timestamp is absent from the Update Location Request message by the HSS apparatus (600). This timestamp is used by the HSS apparatus (600) to ensure that newer location for the UE (200) is not cancelled. If the first MME (400) makes an Update Location Request before the completion of the authentication procedure, it shall include an indication that this Location Update is provisional, i.e., the HSS apparatus (600) shall not consider the UE (200) as registered until it receives the final Update Location Request. The timestamp is the time when the on-board satellite MME part (300) has received the NAS procedure from the UE (200). The HSS apparatus (600) compares the timestamp received in the Update Location Request with any stored timestamp of a previous Update Location Request and determines whether to accept or reject the request. If the received Update Location Request does not include the timestamp, the HSS apparatus (600) assumes the present time as the timestamp of the received Update Location Request. The HSS apparatus (600) shall reject the Update Location Request if the timestamp associated with this request is older than the stored timestamp. If the HSS apparatus (600) accepts the Update Location Request, the HSS apparatus (600) stores the timestamp associated with the latest Update Location Request. The HSS apparatus (600) also updates the UE context information, including the current location and status of the UE (200), ensuring that the network maintains up-to-date records for communication and resource allocation.

[0143] At step S901, the HSS apparatus (600) receives the Update Location Request message from the first MME (400). The Update Location Request message comprises the first timestamp indicating an interaction of the first MME (400) with the UE (200) when the UE has successfully completed the Attach procedure or TAU procedure. Further, at step S902, the HSS apparatus (600) compares the first timestamp received from the first MME (400) with the second timestamp stored at the HSS apparatus (600). The comparison process includes checking the chronological order of the timestamps to record the latest interaction. This step is used for maintaining the integrity of the UE's location data and preventing outdated information from being used in network operations.

[0144] At step S903, the HSS apparatus (600) accepts the Update Location Request message received from the first MME (400) when the first timestamp is newer than or equal to the second timestamp. Further, at step S904, the HSS apparatus (600) rejects the Update Location Request message received from the first MME when the first timestamp is older than the second timestamp. The acceptance or rejection of the Update Location Request is communicated back to the first MME (400), ensuring that the network components are synchronized with the latest UE context. This mechanism helps in preventing potential conflicts or errors in the UE's location data or loosing the UE context unintentionally, thereby enhancing the reliability of the network's location management system.

[0145] In an embodiment, the first MME (400) transmits the first timestamp to the HSS apparatus (600), when the first MME has accepted at least one of a UE Attach request message or Tracking Area Update (TAU) request message from the UE (200).

[0146] In an embodiment, the first timestamp is a time when the onboard satellite MME part received the NAS procedure request from the UE (200) and where the second timestamp is a timestamp associated with the latest Update Location Request accepted by the HSS apparatus (600). The NAS procedure request includes information about the UE's current state and location, which is essential for location tracking. The onboard satellite MME part plays a vital role in relaying this information to the HSS apparatus (600), ensuring that the HSS apparatus (600) has the most recent data for decision-making processes.

[0147] In an embodiment, the HSS apparatus (600) updates the second timestamp stored at the HSS apparatus (600) to the first timestamp when the Update Location Request message is accepted. Further, the HSS apparatus (600) stores the first timestamp associated with the latest Update Location Request message and UE context information when the request is accepted. This update process allows the HSS apparatus (600) to maintain record of the UE's interactions with the network. The stored UE context information includes details such as the UE's current location, status, and any relevant network parameters, which are used for network management and resource allocation.

[0148] In an embodiment, the location management controller (603) sends the cancel Update Location Request to the second MME (500) when the first timestamp is newer than or equal to the second timestamp. The location management controller (603) optionally transmits the reject cause code to the first MME upon rejecting the Update Location Request of the first MME and transmitting a cancel update location procedure request message. This reject cause code provides detailed information about the reason for rejection, helping the first MME (400) to understand and rectify any issues in the Update Location Request. The cancel update location procedure allows the network components to be synchronized and that UE context is removed from the system.

[0149] In an embodiment, the location management controller (603) assigns the present time of reception of the Update Location Request message from the first MME (400) as the first timestamp, when the timestamp corresponding to the first MME (400) is not included in the Update Location Request message. This assignment process allows the HSS apparatus (600) to have a valid timestamp for processing the Update Location Request, even in the absence of an explicit timestamp from the first MME (400). The assigned timestamp is used for subsequent comparisons and decisions, maintaining the integrity and accuracy of the UE's location data within the network.

[0150] In an embodiment, the terms MME onboard and the onboard satellite MME part are used synonymously. In this embodiment, the MME is split into two functions, MME onboard and MME ground.

[0151] a. MME-onboard: the MME part which is onboard the satellite. MME-onboard is in charge of (1) handling the S1 interface with the onboard eNB and (2) handling the NAS protocol signalling from / to UEs via the onboard eNB.

[0152] b. MME ground: the MME part which is on the ground network. MME-ground is in charge of handling the rest of interfaces towards other CN functions (e.g. S6a towards HSS, SGd towards SMS-GMSC / IWMSC / SMS Router, T6a towards SCEF, T6ai towards IWF-SCEF, S11 towards SGW). The MME ground is associated with at least one MME-onboard. An MME-onboard is associated with a Satellite ID identifier. The MME-ground together with the associated MME-onboard(s) behave jointly as a single MME entity

[0153] The foregoing description of the specific embodiments will so fully reveal the general nature of the embodiments herein that others can, by applying current knowledge, readily modify and or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. Therefore, while the embodiments herein have been described in terms of preferred embodiments, those skilled in the art will recognize that the embodiments herein can be practiced with modification within the scope of the embodiments as described herein.

Claims

1.A method performed by a home subscriber server (HSS) in a communication system, the method comprising:receiving, from a mobility management entity (MME), a first update location request;identifying whether the first update location request includes a timestamp associated with a time when an on-board MME has received a message for a non-access stratum (NAS) procedure from a user equipment (UE);in case that the first update location request includes the timestamp, identifying whether the timestamp included in the first update location request is older than a stored timestamp included in a second update location request; andin case that the timestamp included in the first update location request is older than the stored timestamp included in the second update location request, determining to reject the first update location request.2.The method of claim 1, further comprising:in case that the first update location request does not include the timestamp, determining a present time as the timestamp included in the first update location request.3.The method of claim 1, further comprising:in case that the timestamp included in the first update location request is not older than the stored timestamp included in the second update location request, determining to accept the first update location request.4.The method of claim 1, further comprising:as a response to the first update location request, transmitting, to the MME, a message including information indicating whether the first update location request is rejected or accepted,wherein in case that the timestamp included in the first update location request is older than the stored timestamp included in the second update location request, the information indicates that the first update location request is rejected, andwherein in case that the timestamp included in the first update location request is not older than the stored timestamp included in the second update location request, the information indicates that the first update location request is accepted.5.A method performed by a mobility management entity (MME) in a communication system, the method comprising:transmitting, to a home subscriber server (HSS), a first update location request; andin case that the first update location request includes a timestamp, receiving, from the HSS, a message indicating whether the first update location request is rejected or accepted, based on a comparison of whether the timestamp included in the first update location request is older than a stored timestamp included in a second update location request,wherein the timestamp is associated with a time when an on-board MME has received a message for a non-access stratum (NAS) procedure from a user equipment (UE).6.The method of claim 5,wherein in case that the first update location request does not include the timestamp, a present time is determined as the timestamp included in the first update location request.7.The method of claim 5,wherein in case that the timestamp included in the first update location request is older than the stored timestamp included in the second update location request, the message indicates that the first update location request is rejected.8.The method of claim 5,wherein in case that the timestamp included in the first update location request is not older than the stored timestamp included in the second update location request, the message indicates that the first update location request is accepted.9.A home subscriber server (HSS) in a communication system, the HSS comprising:at least one transceiver;at least one processor communicatively coupled to the at least one transceiver; andat least one memory, communicatively coupled to the at least one processor, storing instructions executable by the at least one processor individually or in any combination to cause the HSS to:receive, from a mobility management entity (MME), a first update location request;identify whether the first update location request includes a timestamp associated with a time when an on-board MME has received a message for a non-access stratum (NAS) procedure from a user equipment (UE);in case that the first update location request includes the timestamp, identify whether the timestamp included in the first update location request is older than a stored timestamp included in a second update location request; andin case that the timestamp included in the first update location request is older than the stored timestamp included in the second update location request, determine to reject the first update location request.10.The HSS of claim 9, wherein the instructions further cause the HSS to:in case that the first update location request does not include the timestamp, determine a present time as the timestamp included in the first update location request.11.The HSS of claim 9, wherein the instructions further cause the HSS to:in case that the timestamp included in the first update location request is not older than the stored timestamp included in the second update location request, determine to accept the first update location request.12.The HSS of claim 9, wherein the instructions further cause the HSS to:as a response to the first update location request, transmit, to the MME, a message including information indicating whether the first update location request is rejected or accepted,wherein in case that the timestamp included in the first update location request is older than the stored timestamp included in the second update location request, the information indicates that the first update location request is rejected, andwherein in case that the timestamp included in the first update location request is not older than the stored timestamp included in the second update location request, the information indicates that the first update location request is accepted.13.A mobility management entity (MME) in a communication system, the MME comprising:at least one transceiver;at least one processor communicatively coupled to the at least one transceiver; andat least one memory, communicatively coupled to the at least one processor, storing instructions executable by the at least one processor individually or in any combination to cause the MME to:transmit, to a home subscriber server (HSS), a first update location request; andin case that the first update location request includes a timestamp, receive, from the HSS, a message indicating whether the first update location request is rejected or accepted, based on a comparison of whether the timestamp included in the first update location request is older than a stored timestamp included in a second update location request,wherein the timestamp is associated with a time when an on-board MME has received a message for a non-access stratum (NAS) procedure from a user equipment (UE).14.The MME of claim 13,wherein in case that the first update location request does not include the timestamp, a present time is determined as the timestamp included in the first update location request.15.The MME of claim 13,wherein in case that the timestamp included in the first update location request is older than the stored timestamp included in the second update location request, the message indicates that the first update location request is rejected, andwherein in case that the timestamp included in the first update location request is not older than the stored timestamp included in the second update location request, the message indicates that the first update location request is accepted.

Images