Systems and methods for providing network coverage information to wireless devices and entities

Abstract

A user equipment (UE) accesses a public land mobile network (PLMN) and obtains an address and authorization data of a server. The UE transmits a request for coverage data to the server based on the address and includes the authorization data. Upon verifying the authorization data, the server transmits the coverage data to the UE, the coverage data enabling the UE to determine whether access to the PLMN is possible at one or more locations of the UE, at one or more future times, and using one or more radio access technologies (RATs), the one or more radio access technologies (RATs) include a non-terrestrial network (NTN) RAT and / or a terrestrial network (TN) RAT. The authorization data may include a temporary identifier of the UE, which may be encrypted and may enable verification of the authorization data. The request for coverage data may indicate the signal level required for the UE to access the NTN and TN RAT as well as the location and the future time.

Description

[0001] Related Applications

[0002] This application claims the benefit of U.S. Application No. 18 / 312,455, filed on May 4, 2023, entitled “SYSTEMS AND METHODS FOR PROVISION OF NETWORK COVERAGE INFORMATION TO WIRELESS DEVICES AND ENTITIES,” which claims the benefit of U.S. Provisional Application No. 63 / 338,884, filed on May 5, 2022, entitled “PROVISION OF NON-TERRESTRIAL NETWORK COVERAGE INFORMATION,” U.S. Provisional Application No. 63 / 370,925, filed on August 9, 2022, entitled “PROVISION OF NON-TERRESTRIAL NETWORK COVERAGE INFORMATION,” and U.S. Provisional Application No. 63 / 370,925, filed on February 9, 2023, entitled “PROVISION OF NON-TERRESTRIAL NETWORK COVERAGE INFORMATION.” The present application relates to U.S. Provisional Application No. 63 / 484,187, filed on April 6, 2023, entitled “PROVISION OF NON-TERRESTRIAL NETWORK COVERAGE INFORMATION” and the benefit of U.S. Provisional Application No. 63 / 494,764, filed on April 6, 2023, entitled “PROVISION OF NON-TERRESTRIAL NETWORK COVERAGE INFORMATION”, all of which are assigned to the assignee of the present application and are incorporated herein by reference in their entirety. Technical Field

[0003] The following relates to wireless communications, including support for coverage gaps for satellite access to wireless networks. Background Art

[0004] Wireless communication systems are widely deployed to provide various types of communication content, such as voice, video, packet data, messaging, broadcast, etc. These systems may be able to support communication with multiple users by sharing available system resources (e.g., time, frequency, and power). Examples of such multiple access systems include fourth generation (4G) systems (such as long term evolution (LTE) systems, advanced LTE (LTE-A) systems, or LTE-A Pro systems) and fifth generation (5G) systems (which may be referred to as new radio (NR) systems). These systems may employ techniques such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), or discrete Fourier transform spread orthogonal frequency division multiplexing (DFT-S-OFDM). A wireless multiple access communication system may include one or more base stations or one or more network access nodes, each base station or network access node simultaneously supporting communication for multiple communication devices, which may be further referred to as user equipment (UE).

[0005] Access to a wireless network may be provided using a communication satellite that may support 5G NR, 4G LTE, future 6G access, or other types of radio access technology (RAT) radio interfaces to the UE. In such cases, the communication satellite may not always be visible to the UE, resulting in coverage gaps (also referred to as "discontinuous satellite coverage") whenever no communication satellite is visible or whenever a visible communication satellite cannot or is not allowed to provide wireless coverage to the UE. The coverage gap may last anywhere from about a few minutes to a few hours, during which time the UE may unsuccessfully expend power trying to find a communication satellite, and the wireless network may expend network resources trying to page the UE. This may be detrimental to UE battery life and to network resource availability. In addition, the UE and the network may not know when the satellite will become visible and accessible to the UE again, which may delay the UE's access to the network if the UE or the UE's user is not ready or cannot access a satellite that becomes visible and accessible. Summary of the invention

[0006] A user equipment (UE) accesses a public land mobile network (PLMN) and obtains an address of a server and a temporary identifier of the UE known to the server. The address and temporary identifier can be obtained from a network entity in the PLMN. The temporary identifier can be part of the address and can be encrypted. The UE can access the server based on the address and provide the temporary identifier to the server. When verifying the temporary identifier, the server can provide the UE with requested data, such as coverage data, which enables the UE to determine whether access to the serving PLMN is possible at one or more locations of the UE, at one or more future times, using one or more radio access technologies (RATs) (including non-terrestrial network RATs and / or terrestrial network RATs), or for a combination of these items.

[0007] According to the present disclosure, an example method performed by a user equipment (UE) for obtaining coverage data to assist the UE in wireless access to a serving public land mobile network (PLMN) may include accessing the serving PLMN. The method may also include obtaining an address and authorization data of a server. The method may also include transmitting a request to the server based on the address, the request including the authorization data. The method may also include receiving coverage data from the server based on verification of the authorization data by the server, wherein the coverage data enables the UE to determine whether access to the serving PLMN via one or more satellites is possible in the following situations: at one or more locations in a geographic area, at one or more future times, using one or more radio access technologies (RATs), or a combination of these items.

[0008] According to the present disclosure, an example method performed by a server for providing coverage data to a user equipment (UE) to assist the UE in wireless access to a serving public land mobile network (PLMN) may include receiving a request for coverage data from the UE, the request transmitted by the UE to an address of the server, the request including authorization data for the UE, the authorization data provided to the UE by an entity in the serving PLMN. The method may also include verifying the authorization data. The method may also include transmitting the coverage data to the UE based on the verification of the authorization data.

[0009] According to the present disclosure, an example user equipment (UE) for obtaining coverage data to assist UE in wireless access to a serving public land mobile network (PLMN) may include one or more transceivers, one or more memories, one or more processors communicatively coupled to the one or more transceivers and the one or more memories, wherein the one or more processors are configured to access the serving PLMN. The one or more processors may be further configured to obtain an address and authorization data of a server. The one or more processors may be further configured to transmit a request to the server via one or more transceivers based on the address, the request including the authorization data. The one or more processors may be further configured to receive coverage data from the server via one or more transceivers based on the server's verification of the authorization data, wherein the coverage data enables the UE to determine whether access to the serving PLMN via one or more satellites is possible in the following situations: at one or more locations in a geographic area, at one or more future times, using one or more radio access technologies (RATs), or a combination of these items.

[0010] According to the present disclosure, an example server for providing coverage data to a user equipment (UE) to assist the UE in wireless access to a serving public land mobile network (PLMN) may include one or more transceivers, one or more memories, and one or more processors communicatively coupled to the one or more transceivers and the one or more memories, wherein the one or more processors are configured to receive a request for coverage data from the UE, the request being transmitted by the UE to an address of the server, the request including authorization data for the UE, the authorization data being provided to the UE by an entity in the serving PLMN. The one or more processors may be further configured to verify the authorization data. The one or more processors may be further configured to transmit the coverage data to the UE based on the verification of the authorization data. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1 An example diagram of a communication system utilizing a network architecture with a transparent space vehicle (SV) capable of supporting satellite access to a wireless network is illustrated.

[0012] Figure 2 An example diagram of a communication system utilizing a network architecture with regenerative SVs capable of supporting satellite access to a wireless network is illustrated.

[0013] Figure 3 An example diagram of a communication system utilizing a network architecture with regenerative SVs and a split satellite Node B (gNB) architecture that is capable of supporting satellite access to a wireless network.

[0014] Figure 4An example of SV generating a plurality of beams over an area including a plurality of countries is illustrated.

[0015] Figure 5 An example of a satellite cell generated by an SV over an area including a plurality of fixed cells is illustrated.

[0016] Figure 6 An example of assigning a satellite cell generated by a SV to a fixed tracking area (TA) is illustrated.

[0017] Fig. 7A Examples of UEs being in or out of coverage of a SV at different times and at different locations are illustrated.

[0018] Figure 7B The coverage map and coverage bitmap of the UE are illustrated.

[0019] Figure 7C Another example of a coverage map and a coverage bitmap of a UE is illustrated.

[0020] Fig.7D Illustrated are example signal power heat maps that may be used to indicate satellite coverage availability in accordance with some embodiments.

[0021] Fig. 7E and Figure 7F Different types of grid point arrays that may be used to indicate satellite coverage availability are illustrated in accordance with some embodiments.

[0022] FIG. 8A to FIG. 8C An example of a process supporting transfer of coverage data from a server to a UE based on an obtained server address according to aspects of the present disclosure is illustrated.

[0023] Fig. 9 An example of a process for charging / charging a UE for access to coverage data in accordance with aspects of the present disclosure is illustrated.

[0024] Fig.10 A block diagram illustrating support for a UE obtaining coverage data to assist the UE in accessing a serving public land mobile network (PLMN) in accordance with aspects of the present disclosure is illustrated.

[0025] Fig.11 A block diagram illustrating network entities supporting provision of coverage data to assist UEs in accessing a serving PLMN in accordance with aspects of the present disclosure is illustrated.

[0026] Fig.12 A block diagram of a server supporting provision of coverage data to assist a UE in accessing a serving PLMN in accordance with aspects of the present disclosure is illustrated.

[0027] Fig.13A flow chart illustrating a method that may be performed by a UE to obtain coverage data to assist the UE in wireless access to a serving PLMN according to aspects of the present disclosure is illustrated.

[0028] Fig.14 A flow chart illustrating a method that may be performed by a network entity for providing coverage data to a UE to assist the UE in wireless access to a serving PLMN according to aspects of the present disclosure is illustrated.

[0029] Fig.15 A flow chart illustrating a method that may be performed by a server to provide coverage data to a UE to assist the UE in wireless access to a serving PLMN according to aspects of the present disclosure is illustrated.

[0030] Fig.16 is a diagram of a UE's registration with a PLMN, which may assist in providing coverage data to the UE.

[0031] Similar reference symbols in the various figures indicate similar elements according to certain example implementations. In addition, multiple instances of an element may be indicated by adding a letter or hyphen and a second number after the first number of the element. For example, multiple instances of element 102 may be indicated as 102-1, 102-2, 102-3, etc. When only the first number is used to refer to such an element, it will be understood as any instance of the element (e.g., element 102 in the previous example will refer to elements 102-1, 102-2, 102-3). DETAILED DESCRIPTION

[0032] In some deployment scenarios, wireless communication may be performed between a user equipment (UE) and a satellite so that the UE can access a wireless network via a satellite. For example, a satellite may be deployed so that the UE is located within a coverage area of ​​the satellite to support such communications. However, during initial deployment and / or in some coverage areas, the UE may be located outside the satellite coverage area, which may interrupt such satellite-based communications. For example, due to the orbital motion of the satellite, the UE may traverse the coverage area and non-coverage area of ​​the satellite, which may affect various operations of the UE, such as cell search, mobile station calling service, mobile station called service, power saving mode, etc. Therefore, it is desirable to improve the UE's support for the coverage area and non-coverage area of ​​the satellite to improve the UE operation with satellite-based communications. Similarly, a wireless communication network may benefit from improved support for the coverage area and non-coverage area of ​​the satellite, which may enable more efficient use of network resources and better communication services for the UE. In order to support coverage areas and non-coverage areas, coverage information may be provided to the UE so that the UE can know when there will be coverage of one or more RATs for non-terrestrial networks (NTNs) and possible terrestrial networks (TNs) at a specific location. The type of coverage information needs to be defined as well as the method of transmitting the coverage information to the UE. The coverage information may indicate when satellite coverage will be available for UEs at different locations and at different times, and may be referred to as "coverage data", "satellite coverage data", "coverage information", "satellite coverage information", "satellite coverage availability information" (SCAI), "coverage map" or other names.

[0033] Satellites (also referred to as spacecraft (SV) or communication satellites) can be used in communication systems, for example, using gateways (also referred to as earth stations or ground stations) and one or more satellites to relay communication signals between these gateways and one or more UEs. For example, a UE can access a satellite (rather than a ground base station), and the satellite can be connected to an earth station (ES), which is also referred to as a ground station or a non-terrestrial network (NTN) gateway. The earth station will then be connected to an element in a 5G (or 4G or future 6G) network, such as a modified base station (without a ground antenna) or a network node in a 5G core network (5GCN) or a 4G or future 6G core network. This element will then provide access to other elements in the 5G (or 4G or future 6G) network, and ultimately provide access to entities outside the 5G (or 4G or future 6G) network (such as Internet web servers and other user devices).

[0034] The basic principle of 5G (or other cellular network) satellite access of UE may include providing ubiquitous outdoor coverage for both users and mobile network operators (MNOs). For example, in many countries including the United States, unavailable or poor cellular network coverage is a common problem. In addition, even if there is generally good cellular coverage, cellular access is not always possible. For example, cellular access may be hindered by congestion, physical obstacles, local cellular outages caused by weather (e.g., hurricanes or tornadoes), or local power outages. Satellite access to cellular networks can provide new independent access that is potentially available everywhere outdoors. Current satellite-capable phones for low-Earth orbit (LEO) SVs may have similar sizes to cellular smartphones, and thus mobile NR support using satellite-capable phones does not require a significant increase in phone size. In addition, satellite-capable smartphones may help drive mobile phone sales and may increase operator revenue. For example, potential users may include anyone with limited or no cellular access, anyone who wants a backup for lack of cellular access, and anyone involved in public safety or otherwise requiring (almost) 100% reliable mobile communications. Additionally, some users may desire improved or more reliable E911 service, e.g., for medical emergencies or traffic breakdowns in remote areas. Additional user scenarios may include providing wireless communication access to UEs located outdoors and associated with automation or Internet of Things (IoT) devices, such as UEs that enable communication with and possibly control of unmanned aerial vehicles (UAVs), unmanned vehicles, automated machinery used in agriculture, forestry, or mining, smart meters, and monitoring equipment (e.g., for monitoring weather, traffic, crowds, hazardous conditions).

[0035] Using 5G satellite access can provide other benefits. For example, 5G satellite access can reduce mobile network operator (MNO) infrastructure costs. For example, MNOs can use satellite access to reduce the number of ground base stations (such as NR NodeBs, also known as gNBs) that need to be deployed and backhaul deployment in sparsely populated areas. In addition, 5G satellite access can be used to overcome Internet congestion in certain countries, for example. Additionally, 5G satellite access can provide diversification for spacecraft operators (SVOs). For example, 5G NR satellite access can provide another revenue stream for SVOs that would otherwise only provide fixed Internet access.

[0036] As a term, when there is previous context information that the "cell" is a "satellite cell", a wireless cell supported by a satellite (or SV) is referred to herein as a "satellite cell", "radio cell", "NTN cell" or simply a "cell". A satellite cell will be distinguished from wireless cells supported by ground base stations and access points, which are referred to herein as ground cells or ground network (TN) cells.

[0037] Note that the terms spacecraft (SV), communication satellite, and satellite may be synonymous and are therefore used interchangeably herein. In some cases, an SV (or satellite) may be a navigation SV (or satellite), such as an SV for GPS, Galileo, GLONASS, or BeiDou. SVs that function as navigation SVs but may not function as communication SVs are labeled and explicitly referred to herein to avoid confusion with communication SVs that may not support navigation.

[0038] In general, the technology described herein provides for transmitting (e.g., signaling) coverage information for satellite-based coverage areas to a UE, which are also referred to herein as satellite coverage areas and NTN coverage areas. For example, a UE may access its serving public land mobile network (PLMN) (e.g., a core network) via a communication satellite (e.g., one or more satellites providing service coverage (also referred to as NTN coverage and satellite coverage) for the UE). The UE may receive an indication of satellite coverage data for the satellite coverage area. The UE may obtain data (such as coverage data or other types of data) by, for example, obtaining a server address (such as a uniform resource identifier (URI)) from a network entity. The UE may, for example, transmit a request for coverage data to a server identified by the address using a hypertext transfer protocol (HTTP) or a hypertext transfer secure protocol (HTTPS). The server identifies the address association with the coverage data and returns the requested coverage data to the UE. In order to provide security and enable charging for coverage data, a preconfigured temporary identifier may be assigned to the UE and provided to the UE by the network entity. The UE provides the temporary identifier to the server together with the request for coverage data, and the server may verify the temporary identifier before returning the requested coverage data to the UE.

[0039] Broadly, the satellite coverage data may indicate a discontinuous service coverage pattern of the UE (e.g., may indicate a satellite coverage area for the UE). The UE may identify or otherwise determine a first time (T1) of satellite unavailability (e.g., a time when the UE is initially unable to wirelessly communicate with the serving PLMN via a satellite) and a second time (T2) of satellite availability (e.g., a time period during which the UE is able to resume wireless communication with the serving PLMN via a satellite). In some examples, the UE may identify, calculate, or otherwise determine T1 / T2 based on the satellite coverage data, the location of the UE, etc. Thus, the UE may transition to or otherwise enter a no-coverage state after a first time (e.g., T1, a time when the UE is initially unable to wirelessly communicate with the serving PLMN via a satellite). The no-coverage state may include, but is not limited to: the UE prohibiting a mobile origination (MO) request, reducing a satellite cell search frequency (e.g., how often the UE performs a cell search for a satellite) from a first frequency (e.g., when in a coverage state) to a second frequency (e.g., when in a no-coverage state), and the like. The UE may transition from or otherwise leave the no coverage state at a second time (e.g., T2, a time when the UE is able to resume wirelessly communicating with the serving PLMN via satellite). Various aspects of these techniques may be performed at an access stratum (AS) of the UE and / or at a non-access stratum (NAS) of the UE.

[0040] Aspects of the disclosure are initially described in the context of communication systems, including wireless communication systems. Aspects of the disclosure are further illustrated and described with reference to apparatus diagrams, system diagrams, and flow diagrams related to support of coverage gaps for satellite access.

[0041] Figure 1 An example of a communication system 100 capable of supporting satellite access using 5G NR or some other wireless access type such as CDMA, 4G, or future 6G according to some examples is illustrated. Figure 1 A network architecture with a transparent SV is illustrated. A transparent SV may implement frequency conversion and radio frequency (RF) amplifiers in both uplink (UL) and downlink (DL) directions, and may correspond to an analog RF repeater. A transparent SV may, for example, receive UL signals from all served UEs, and may DL redirect the combined signal to an earth station without demodulating or decoding the signals. Similarly, a transparent SV may receive UL signals from an earth station and DL redirect the signal to a served UE without demodulating or decoding the signal. However, the SV may frequency convert the received signals, and may amplify and / or filter the received signals before transmitting them.

[0042] The communication system 100 includes multiple UEs 115, multiple SVs 102 (e.g., SVs 102-1, 102-2, 102-3, and 102-4), multiple non-terrestrial network (NTN) gateways 104-1 to 104-4 (collectively referred to herein as NTN gateways 104) (and sometimes referred to herein simply as gateways 104, earth stations 104, or ground stations 104), and multiple satellite NodeBs (gNBs) 106-1 to 106-3 (collectively referred to herein as gNBs 106) that are capable of communicating with the UEs 115 via the SVs 102 and are part of a next generation (NG) radio access network (RAN) (NG-RAN) 112.

[0043] Note that the term "gNB" (or "gNodeB") traditionally refers to an NR NodeB base station for terrestrial access utilizing the NR radio interface. The same term (gNB) can also be used to refer to a base station that supports satellite access utilizing the NR radio interface. The two variants of gNB (satellite and terrestrial) can support many of the same functions, protocols, and interfaces, but are also different in other aspects. In order to distinguish between gNBs supporting terrestrial access and gNBs supporting satellite access, different labels are used in this article. gNB can also support terrestrial and satellite NR access, but for simplicity, this is not discussed further here.

[0044] The communication system 100 is illustrated as further including components of multiple fifth generation (5G) networks, including 5G core networks (5GCNs) 110-1 to 110-3 (collectively referred to herein as 5GCNs 110). 5GCN 110 may be a public land mobile network (PLMN) that may be located in the same or different countries. Figure 1 The various components within 5GCN1 110-1 that may operate with NG-RAN 112 are illustrated. It should be understood that 5GCN2 110-2 and 5GCN3 110-3 may include the same, similar or different components and associated NG-RANs, and to avoid unnecessary confusion, these components are not described in detail. Figure 1100. The 5G network may also be referred to as an NR network; the NG-RAN 112 may be referred to as a 5G RAN or an NR RAN; and the 5GCN 110 may be referred to as an NG core network (NGC). The communication system 100 may further utilize information from a spacecraft (SV) 190 of a satellite positioning system (SPS) (including a global navigation satellite system (GNSS), such as a global positioning system (GPS), a global navigation satellite system (GLONASS), Galileo, or BeiDou, or some other local or regional SPS such as the Indian Regional Navigation Satellite System (IRNSS), the European Geostationary Navigation Overlay Service (EGNOS), or a Wide Area Augmentation System (WAAS)), all of which are sometimes referred to herein as GNSS. It should be noted that SV 190 acts as a navigation SV and is separate and distinct from SV 102, which acts as a communication SV. However, it is not excluded that some of SV 190 may also act as some of SV 102 and / or some of SV 102 may also act as some of SV 190. In some implementations, for example, SV 102 can be used for both communication and positioning.Additional components of communication system 100 are described below. Communication system 100 can include additional or alternative components.

[0045] exist Figure 1 The connections permitted in the communication system 100 illustrated in FIG. 1 having a network architecture with transparent SV allow a gNB 106 to access multiple earth stations 104 and / or multiple SVs 102. A gNB 106 (e.g., illustrated by gNB 106-2) may also be shared by multiple PLMNs (5GCN 110), which may all be in the same country or may be in different countries, and an NTN gateway 104 (e.g., illustrated by NTN gateway 104-1) may be shared by more than one gNB 106.

[0046] It should be noted that Figure 1 Only generalized illustrations of the various components are provided, any or all of which may be utilized as appropriate, and each component may be repeated or omitted as desired. Specifically, although only three UEs 115 are illustrated, it will be understood that many UEs (e.g., hundreds, thousands, millions, etc.) may utilize the communication system 100. Similarly, the wireless communication system 100 may include a larger (or smaller) number of SVs 190, SVs 102, earth stations 104, gNBs 106, NG-RAN 112, ng-eNBs 114, 5GCNs 110, external clients 140, and / or other components. The illustrated connections connecting the various components in the communication system 100 include data and signaling connections, which may include additional (intermediate) components, direct or indirect physical and / or wireless connections, and / or additional networks. In addition, the components may be rearranged, combined, separated, replaced, and / or omitted depending on the desired functionality.

[0047] Although Figure 1 A 5G based network is illustrated, but similar network implementations and configurations may be used for other communication technologies such as 3G, 4G LTE, etc.

[0048] UE 115 may include and / or be referred to as a device, a mobile device, a wireless device, a mobile terminal, a terminal, a mobile station (MS), a terminal (SET) with secure user plane location (SUPL) enabled, or some other name. In addition, UE 115 may correspond to a cellular phone, a smart phone, a laptop computer, a tablet, a PDA, a tracking device, a navigation device, an Internet of Things (IOT) device, or some other portable or mobile device. Typically, although not necessarily, UE 115 may support the use of one or more radio access technologies (RATs) such as GSM, CDMA, Wideband CDMA (WCDMA), LTE, High Rate Packet Data (HRPD), IEEE802.11 WiFi (also known as Wi-Fi), The UE 115 may also support wireless communications using a wireless local area network (WLAN), which may be connected to other networks (e.g., the Internet) using, for example, a digital subscriber line (DSL) or a packet cable. The UE 115 further supports wireless communications using a spacecraft such as the SV 102. Using one or more of these RATs may allow the UE 115 to communicate with an external client 140 (e.g., via a user plane function (UPF) 130, or possibly via a gateway mobile location center (GMLC) 126).

[0049] UE 115 may comprise a single entity or may comprise multiple entities, such as in a personal area network where a user may employ audio, video, and / or data I / O devices and / or body sensors and separate wired or wireless modems.

[0050] UE 115 may, for example, use signals and information from spacecraft 190 in an SPS (such as GPS, GLONASS, Galileo, or BeiDou) or some other local or regional SPS (such as IRNSS, EGNOS, or WAAS) to support position determination, all of which may be generally referred to as GNSS herein. Position measurements using SPS are based on measurements of propagation delay times of SPS signals broadcast from multiple orbiting satellites to SPS receivers in UE 115. Once the SPS receiver has measured the signal propagation delay for each satellite, the distance to each satellite may be determined, and the measured distances and the known positions of these satellites may then be used to determine accurate navigation information (including 3-dimensional positioning, velocity, and time of day of the SPS receiver). Positioning methods that may be supported using SV 190 may include Assisted GNSS (A-GNSS), Real-Time Kinematics (RTK), Precise Point Positioning (PPP), and Differential GNSS (DGNSS). Information and signals from SV 102 may also be used to support positioning. UE 115 may further support positioning using terrestrial positioning methods such as downlink (DL) time difference of arrival (DL-TDOA), enhanced cell ID (ECID), round-trip signal propagation time (RTT), multi-cell RTT, angle of arrival (AOA), angle of departure (AOD), time of arrival (TOA), receive time-transmit time difference (RxTx), and / or other positioning methods.

[0051] The estimate of the location of UE 115 may be referred to as a geodetic location, location, location estimate, location bearing, bearing, position, position estimate, or position fix, and may be geodetic, thereby providing location coordinates (e.g., latitude and longitude) of UE 115, which may or may not include an altitude / altitude component (e.g., height above sea level, height above or depth below ground level, floor level, or basement level). Alternatively, the location of UE 115 may be expressed as a civic location (e.g., a postal address or a designation of a point or smaller area in a building, such as a particular room or floor). The location of UE 115 may also be expressed as an area or volume (geodetically or civically defined) in which UE 115 is expected to be located with a certain probability or confidence level (e.g., 67%, 95%, etc.). The location of the UE 115 may also be a relative location, including, for example, a distance and direction or relative X, Y (and Z) coordinates defined relative to some origin at a known location, which may be defined geodetically, in municipal terms, or by reference to a point, area, or volume indicated on a map, floor plan, or building plan. In the descriptions contained herein, the use of the term "location" may include any of these variations unless otherwise indicated. When calculating the location of the UE, local x, y, and possibly z coordinates are typically solved, and then the local coordinates are converted to absolute coordinates (e.g., with respect to latitude, longitude, and altitude above or below mean sea level) if necessary.

[0052] UE 115 is configured to communicate with 5GCN 110 via SV 102, earth station 104, and gNB 106. As illustrated by NG-RAN 112, the NG-RAN associated with 5GCN 110 may include one or more gNBs 106. NG-RAN 112 may also include multiple terrestrial gNBs ( Figure 1 106-1 in NG-RAN 112). Paired terrestrial and / or satellite base stations (e.g., terrestrial gNBs and gNB 106-1 in NG-RAN 112) may be connected to each other using terrestrial links (e.g., directly or indirectly via other terrestrial gNBs or gNB 106) and communicate using an Xn interface. Access to the 5G network is provided to UE 115 via wireless communications between each UE 115 and the serving gNB 106, via SV 102 and NTN gateway 104. gNB 106 may provide wireless communication access to 5GCN 110 using 5G NR on behalf of each UE 115. 5G NR radio access may also be referred to as NR radio access or 5G radio access, and may be defined by the Third Generation Partnership Project (3GPP).

[0053] Figure 1 The base stations (BSs) in the illustrated NG-RAN 112 may also or alternatively include a next generation evolved Node B 114 (also referred to as ng-eNB 114). The ng-eNB 114 may be connected to one or more gNBs 106 and / or terrestrial gNBs in the NG-RAN 112 (e.g., directly or indirectly via other gNBs 106, terrestrial gNBs, and / or other ng-eNBs 114). The ng-eNB 114 may provide LTE wireless access and / or evolved LTE (eLTE) wireless access to the UE 115. The ng-eNB 114 may be connected to the NTN gateway 104 and support satellite wireless access for the UE 115 (e.g., IOT UE) using enhanced machine type communication (eMTC) (also referred to as LTE-M or narrowband IOT (NB-IOT)). eMTC and NB-IOT are variants of LTE in which lower bandwidth is provided to and supported by UE 115, and these variants enable support for UE 115 with low resource capabilities (e.g., lower processing and memory availability) and limited power availability (e.g., UE 115 with a battery that should provide power to UE 115 for 2 to 10 years before being replaced or recharged). NB-IOT and eMTC may be preferred over NR to support IOT UEs with very limited resources and power availability.

[0054] The term “satellite NodeB” is used herein to refer to a gNB (e.g., gNB 106) or ng-eNB (e.g., ng-eNB 114) that provides satellite wireless access, such as Figure 1 The satellite Node B may be regenerative, as described later with respect to Figure 2 and Figure 3Described, and / or in some embodiments may correspond to (e.g., using LTE, eMTC, or NB-IOT) an evolved Node B (eNB) that provides satellite wireless access to a core network that is an EPC. A satellite NodeB may be referred to by other nomenclature or terminology, such as an sNB or "satellite node" or "satellite access node." A satellite NodeB corresponding to a gNB 106 is distinct from a terrestrial gNB, but may be based on a terrestrial gNB with additional capabilities. For example, a gNB 106 may terminate at a radio interface and associated radio interface protocol to a UE 115, and may send DL signals to and receive UL signals from a UE 115 via a SV 102 and an earth station 104. The gNB 106 may also support signaling connections to the UE 115 as well as voice and data bearers, and may support handover of the UE 115 between different satellite cells of the same SV 102, between different SVs 102, and / or between different gNBs 106. In some systems, the gNB 106 may be referred to as a gNB or an enhanced gNB. The gNB 106 may be configured to manage mobile satellite beams (for LEOSV) and the associated mobility of the UE 115. The gNB 106 may assist in the handover (or transfer) of the SV 102 between different earth stations 104, between different gNBs 106, and between different countries. The gNB 106 may hide or shield certain aspects of the connected SV 102 from the 5GCN 110, for example, by docking with the 5GCN 110 in the same or similar manner as a terrestrial gNB, and may avoid the 5GCN 110 having to maintain configuration information for the SV 102 or perform mobility management related to the SV 102. The gNB 106 may further assist in sharing the SV 102 in multiple countries. The gNB 106 may communicate with one or more earth stations 104, for example, as illustrated by the gNB 106-2 communicating with earth stations 104-2 and 104-1. The gNB 106 may be separate from the earth station 104, for example, as illustrated by gNBs 106-1 and 106-2 and earth stations 104-1 and 104-2. The gNB 106 may include one or more earth stations 104 or may be combined with the one or more earth stations, for example using a split architecture. For example, gNB 106-3 is illustrated as having a split architecture, where a gNB central unit (gNB-CU) 107 and earth stations 104-3 and 104-4 act as distributed units (DUs). The gNB 106 may typically be fixed to the ground using transparent SV operation. In one specific implementation, a gNB 106 may be physically combined with an NTN gateway 104 or may be physically connected to the gateway to reduce overall complexity and cost.

[0055] The satellite NodeB corresponding to ng-eNB 114 is different from the terrestrial ng-eNB, but may be based on the terrestrial ng-eNB with additional capabilities. The differences between ng-eNB 114 and the terrestrial ng-eNB and the additional satellite-related functions, capabilities, and uses of ng-eNB 114 may be similar to those described above for gNB 106.

[0056] The earth station 104 may be shared by more than one gNB 106 and / or more than one ng-eNB 114 and may communicate with the UE 115 via the SV 102. The NTN gateway 104 may be dedicated to only one SVO and one associated constellation of the SV 102, and may therefore be owned and managed by the SVO. Although the earth station 104 may be included within a ng-eNB 114 or gNB 106, for example, as a gNB-DU within gNB 106-3, this may only occur when the same SVO or the same MNO owns both the ng-eNB 114 or gNB 106 and the included earth station 104. The earth station 104 may communicate with the SV 102 using control plane and user plane protocols that are proprietary to the SVO. The control plane and user plane protocols between the earth station 104 and the SV 102 can: (i) establish and release the communication link from the NTN gateway 104 to the SV 102, including authentication and encryption; (ii) update the SV software and firmware; (iii) perform SV operations and maintenance (O and M); (iv) control satellite beams (e.g., direction, power, on / off status) and the mapping between satellite beams and earth station UL and DL payloads; and (v) assist in the handover of an SV 102 or a satellite cell to another NTN gateway 104.

[0057] As pointed out, although Figure 1 Nodes configured to communicate in accordance with 5G NR and LTE communication protocols for NG-RAN 112 are depicted, but nodes configured to communicate in accordance with other communication protocols such as, for example, the LTE protocol for an Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (E-UTRAN) (e.g., supporting UE 115 satellite access using eMTC or NB-IOT) or the IEEE 802.11x protocol for WLAN may also be used. For example, in a 4G Evolved Packet System (EPS) providing LTE wireless access to UE 115, the RAN may include an E-UTRAN, which may include base stations with evolved Node Bs (eNBs) supporting LTE wireless access. The core network for the EPS may include an Evolved Packet Core (EPC). The EPS may then include the E-UTRAN plus the EPC, where the Figure 1In the embodiment of the present invention, E-UTRAN corresponds to NG-RAN 112 and EPC corresponds to 5GCN 110. In this case, the satellite NodeB may include an eNB in ​​E-UTRAN connected to NTN gateway 104 and EPC. The methods and techniques described herein for supporting satellite acquisition assistance may be applicable to such other networks.

[0058] The gNB 106, ng-eNB 114, and terrestrial gNBs may communicate with an access and mobility management function (AMF) 122 in the 5GCN 110, which may communicate with a location management function (LMF) 124 for positioning functionality. For example, the gNB 106 and ng-eNB 114 may provide an N2 interface to the AMF 122. The N2 interface between the gNB 106 or ng-eNB 114 and the 5GCN 110 may be the same as the N2 interface supported between the terrestrial gNB or terrestrial ng-eNB and the 5GCN 110 for terrestrial NR or terrestrial LTE access by the UE 115, and the Next Generation Application Protocol (NGAP) defined in 3GPP Technical Specification (TS) 38.413 may be used between the gNB 106 or ng-eNB 114 and the AMF 122. The AMF 122 may support mobility of the UE 115, including satellite cell changes and handovers, and may participate in supporting signaling connections to the UE 115 and possible data and voice bearers for the UE 115. The LMF 124 may support positioning of the UE 115 when the UE accesses the NG-RAN 112, and may support positioning procedures / methods such as A-GNSS, DL-TDOA, RTK, PPP, DGNSS, ECID, AOA, AOD, multi-cell RTT, and / or other positioning procedures including positioning procedures based on communication signals from one or more SVs 102. The LMF 124 may also process location service requests for the UE 115 received, for example, from the AMF 122 or from a Gateway Mobile Location Center (GMLC) 126. The LMF 124 may be connected to the AMF 122 and / or the GMLC 126. In some embodiments, a node / system implementing LMF 124 may additionally or alternatively implement other types of location support modules, such as an Enhanced Serving Mobile Location Center (E-SMLC). Note that in some embodiments, at least a portion of the positioning functionality (including the derivation of the position of UE 115) may be performed at UE 115 (e.g., using signal measurements obtained by UE 115 for signals transmitted by SV 102, SV 190, terrestrial gNBs, and assistance data provided to UE 115, for example, by LMF 124).

[0059] GMLC 126 may support location requests for UE 115 received from external client 140 and may forward the location requests to AMF 122 for forwarding by AMF 122 to LMF 124, or may forward the location requests directly to LMF 124. A location response from LMF 124 (e.g., containing a location estimate of UE 115) may similarly be returned to GMLC 126 directly or via AMF 122, and GMLC 126 may then return the location response (e.g., containing the location estimate) to external client 140. GMLC 126 is shown connected to Figure 2 Both the AMF 122 and LMF 124 in the 5GCN 110, but in some specific implementations, only one of these connections may be supported by the 5GCN 110.

[0060] A network opening function (NEF) 128 may be included in the 5GCN 110, for example connected to the GMLC 126 and the AMF 122. In some implementations, the NEF 128 may be connected to communicate directly with the external client 140. The NEF 128 may support secure opening of capabilities and events about the 5GCN 110 and the UE 115 to the external client 140, and may enable secure provisioning of information from the external client 140 to the 5GCN 110.

[0061] A user plane function (UPF) 130 may support voice and data bearers for UE 115 and may enable voice and data access for UE 115 to other networks, such as the Internet 175. UPF 130 may be connected to gNB 106 and ng-eNB 114. UPF 130 functions may include: external protocol data unit (PDU) session interconnection points to data networks, packet (e.g., IP) routing and forwarding, user plane portion of packet inspection and policy rule enforcement, quality of service (QoS) handling of the user plane, downlink packet buffering, and downlink data notification triggering. UPF 130 may be connected to a secure user plane location (SUPL) location platform (SLP) 132 to implement support for locating UE 115 using SUPL. SLP 132 may also be connected to or accessible from external client 140.

[0062] As shown, a session management function (SMF) 134 is connected to AMF 122 and UPF 130. SMF 134 may have the ability to control local and central UPFs within a PDU session. SMF 134 may manage the establishment, modification, and release of PDU sessions for UE 115, perform IP address allocation and management for UE 115, act as a Dynamic Host Configuration Protocol (DHCP) server for UE 115, and select and control UPF 130 on behalf of UE 115.

[0063] The external client 140 may connect to the 5GCN 110 via the GMLC 126 and / or the SLP 132, and / or the NEF 128. The external client 140 may optionally connect to the 5GCN 110 and / or to a location server via the Internet 175, which may be, for example, an SLP external to the 5GCN 110. The external client 140 may directly ( Figure 1 The external client 140 may be connected to the UPF 130 via the Internet 175 or the external client 140 may be a server, a web server, or a user device such as a personal computer, a UE, etc.

[0064] As noted, while the communication system 100 is described with respect to 5G technology, the communication system 100 may be implemented to support other communication technologies (such as GSM, WCDMA, LTE, etc.) for supporting and interacting with mobile devices (such as UE 115) (e.g., to implement voice, data, positioning, and other functionality). In some such embodiments, the 5GCN 110 may be configured to control different air interfaces. For example, in some embodiments, the non-3GPP interworking function (N3IWF, Figure 1 110 to the WLAN. For example, the WLAN may support IEEE 802.11 WiFi access for UE 115 and may include one or more WiFi APs. Here, the N3IWF may connect to the WLAN and other elements in the 5GCN 110, such as the AMF 122.

[0065] To use Figure 1The support of transparent SV 102 of the network architecture shown may affect the communication system as follows. 5GCN110 may treat satellite RAT as a new type of terrestrial RAT with longer latency, reduced bandwidth and higher error rate. Therefore, although there may be some impact on PDU session establishment and mobility management (MM) and connection management (CM) processes, the impact on AMF 122 (or LMF 124) may be small, for example, such as providing pre-configured data of fixed tracking area (TA) and cell to UE 115 during registration. There may be no impact on SV 102. SV 102 can be shared with other services (e.g., satellite TV, fixed Internet access) that utilize 5G NR mobile access of UE 115 added in a transparent manner. This enables the use of old SV 102 and avoids the need to deploy a new type of SV 102. In addition, gNB 106 and ng-eNB114 can be fixed and can be configured to support a country and one or more PLMNs in the country. gNB 106 and ng-eNB 114 may need to assist in the assignment and transfer of SV 102 and satellite cells between gNB 106 or ng-eNB 114 and earth station 104, and support handover of UE 115 between satellite cells, SV 102, other gNB 106, and / or other ng-eNB 114. Thus, gNB 106 may be different from a terrestrial gNB and ng-eNB 114 may be different from a terrestrial ng-eNB. Additionally, the coverage area of ​​gNB 106 or ng-eNB 114 may be much larger than the coverage area of ​​a terrestrial gNB or terrestrial ng-eNB.

[0066] In some implementations, the satellite beam coverage of SV 102 may be large, e.g., up to or greater than 1000 kilometers (km), and may provide access to more than one country. NTN gateway 104 may be shared by multiple gNBs 106 and / or by multiple ng-eNBs 114 (e.g., NTN gateway 104-1 may be shared by gNBs 106-1 and 106-2 and by ng-eNB 114), and gNB 106 and / or ng-eNB 114 may be shared by multiple core networks located in separate PLMNs in the same country or in different countries (e.g., gNB 106-2 may be shared by 5GCN1 110-1 and 5GCN2 110-1, which may be in different PLMNs in the same country or in different countries).

[0067] To simplify later references to satellite NodeBs supporting transparent SV wireless access, as an alternative, any references to gNB 106 later in this document may also be considered to refer to ng-eNB 114 or a satellite NodeB including an eNB accessing the EPC.

[0068] Figure 2 An example of a communication system 200 capable of supporting satellite access using 5G NR or some other wireless access type such as CDMA, 4G, or future 6G according to one embodiment is illustrated. The communication system 200 may implement aspects of the communication system 100.

[0069] Figure 2 The network architecture shown in is similar to Figure 1 The network architecture shown in FIG. 1 is similar or identical to the components specified in FIG. 1 . However, with Figure 1 In contrast, the transparent SV 102 shown Figure 2 A network architecture utilizing regenerated SVs 202-1, 202-2, 202-3, and 202-4 (collectively referred to as SVs 202) is illustrated. Unlike transparent SVs 102, regenerated SVs 202 include an onboard satellite NodeB (referred to as gNB 202), which may include the functional capabilities of gNB 106 and is sometimes referred to herein as SV / gNB 202. NG-RAN 112 is illustrated as including SV / gNB 202. When referencing SV / gNB 202 functionality related to communication with UE 115 and 5GCN 110, reference to gNB 202 is used herein, while reference to SV 202 is used when referencing SV / gNB 202 functionality related to communication with earth station 104 and UE 115 at the physical radio frequency level. However, there may be no precise boundary between SV 202 and gNB 202.

[0070] The onboard gNB 202 may perform some or all of the same functions as the gNB 106 as previously described. For example, the gNB 202 may terminate at a radio interface and associated radio interface protocol to the UE 115, and may send DL signals to the UE 115 and receive UL signals from the UE 115, which may include encoding and modulation of the transmitted signals and demodulation and decoding of the received signals. The gNB 202 may also support signaling connections to the UE 115 and voice and data bearers, and may support handover of the UE 115 between different satellite cells of the same gNB 202 and between different gNBs 202. The gNB 202 may assist in the handover (or transfer) of the SV 202 between different earth stations 104, between different 5GCNs 110, and between different countries. The gNB 202 may hide or obscure certain aspects of the SV 202 from the 5GCN 110, for example, by interfacing with the 5GCN 110 in the same or similar manner as a terrestrial gNB. The gNB 202 may further facilitate sharing of the SV 202 in multiple countries. The gNB 202 may communicate with one or more earth stations 104 and, via the earth stations 104, with one or more 5GCNs 110. In some implementations, the gNB 202 may use an inter-satellite link (ISL) ( Figure 2 (not shown) communicates directly with other gNB 202, and ISL can support the Xn interface between any pair of gNB 202.

[0071] In the case of LEO SV, SV / gNB 202 may need to manage mobile satellite cells with coverage of different countries at different times. Earth station 104 may be directly connected to 5GCN 110, as illustrated. For example, as shown, NTN gateway 104-1 may be connected to AMF 122 and UPF 130 of 5GCN1 110-1, while NTN gateway 104-2 may be similarly connected to 5GCN2 110-2, and earth stations 104-3 and 104-4 are connected to 5GCN3 110-3. For example, in the case where earth station 104 is limited, earth station 104 may be shared by multiple 5GCN 110. For example, in some implementations (illustrated with dashed lines), NTN gateway 104-2 may be connected to both 5GCN1 110-1 and 5GCN2 110-2, and NTN gateway 104-3 may be connected to both 5GCN2 110-2 and 5GCN3 110-3. 5GCN 110 may need to know the SV 202 coverage area to page UE 115 and manage handover. Thus, as can be seen, the network architecture with regenerated SVs may have more advantages than 5GCN1 110 with respect to both gNB 202 and 5GCN 110. Figure 1 The network architecture with transparent SV 102 shown in FIG.

[0072] To use Figure 2 The support of regenerated SVs of the illustrated network architecture may impact the communication system 200 as follows. The 5GCN 110 may be impacted without support for fixed TAs and cells, because core components of mobility management and regulatory services that are typically based on fixed cells and fixed TAs for terrestrial PLMNs may have to be replaced by a new system (e.g., based on UE 115 location). With support for fixed TAs and fixed cells, the 5GCN 110 (e.g., AMF 122) may need to map any fixed TA to one or more SVs 202 with current radio coverage of the TA when performing paging of a UE 115 located in any TA. This may require configuration of long-term orbit data of the SV 202 in the 5GCN 110 (e.g., obtained from the SVO of the SV 202), and may add significant new impacts to the 5GCN 110.

[0073] Legacy SVs may require significant software (SW) updates to support gNB 202 functionality, which may not be feasible. SV 202 will also need to fully support all UEs 115 accessing the SV 202, which may be problematic for legacy SVs due to limited processing and storage capabilities. Therefore, SV 202 will likely need to include new hardware (HW) and SW, rather than being based on a SW upgrade to an existing SV. New SV / gNB 202 may need to support regulatory and other requirements of multiple countries. A GEO SV 202 coverage area will typically include several or many countries, while a LEO or medium earth orbit (MEO) SV 202 will typically orbit above many countries. Thus, support for fixed tracking areas (TAs) and fixed cells may require that the SV / gNB 202 be configured with fixed TAs and fixed cells for the entire global coverage area. Alternatively, the AMF 122 (or LMF 124) in a single 5GCN 110 may support fixed TA and fixed cells for the associated PLMN to reduce SV / gNB 202 complexity at the expense of more 5GCN 110 complexity. Additionally, the SV / gNB 202 to SV / gNB 202 ISL will typically change dynamically as the relative SV / gNB 202 location changes, making the Xn related process more complex.

[0074] To support satellite access using LTE, NB-IOT, or eMTC, the regenerated SV 202 may include an onboard satellite NodeB that may include the functional capabilities of an ng-eNB 114 or an eNB instead of the functional capabilities of a gNB 106 supporting NR access. The functions of the SV 202 and the onboard satellite NodeB and the impact on the 5GCN 110 may then be the same or similar to those described above for an SV 202 having an onboard satellite NodeB corresponding to a gNB 202 supporting NR access, but with the difference that any reference to the gNB 106 will refer to the ng-eNB or eNB, and any reference to the 5GCN 110 or a 5GCN 110 entity (e.g., AMF 122 or UPF 130) will refer to the EPC of the gNB 202 corresponding to the eNB or a corresponding EPC entity (e.g., a mobility management entity (MME) or a serving gateway (SGW) plus a packet data gateway (PDG)), respectively. Therefore, references herein to gNB 202, SV / gNB 202, or SV 202 may be considered to allow the satellite NodeB components of SV 202 to support the functionality of ng-eNB 114 or eNB.

[0075] Figure 3 An example of a diagram of a communication system 300 capable of supporting satellite access using 5G NR or some other wireless access type such as CDMA, 4G, or future 6G according to one embodiment is illustrated. Communication system 300 may implement aspects of communication systems 100 and / or 200.

[0076] Figure 3 The network architecture shown in is similar to Figure 1 and Figure 2 The network architecture shown in FIG. 1 is similar or identical to the components specified in FIG. 1 . However, with Figure 1 In contrast to the transparent SV 102 shown and utilizing the split architecture of the satellite NodeB, Figure 3A network architecture utilizing regenerative SVs 302-1, 302-2, 302-3, and 302-4 (collectively, SVs 302) is illustrated. Satellite NodeBs referred to as gNBs 307 (e.g., gNBs 307-1, 307-2, and 307-3) include a central unit and may sometimes be referred to as a gNB-CU 307, and unlike transparent SVs 102, regenerative SVs 302 include an onboard gNB distributed unit (gNB-DU) 302 and are sometimes referred to herein as SVs / gNB-DUs 302. References to gNB-DUs 302 are used herein when referencing SV / gNB 302 functionality associated with communications with UEs 115 and gNB-CUs 307, and references to SVs 302 are used when referencing SV / gNB-DUs 302 functionality associated with communications with earth stations 104 and UEs 115 at a physical radio frequency level. However, there may not be an exact boundary between SV 302 and gNB-DU 302.

[0077] Each gNB-DU 302 communicates with a ground-based gNB-CU 307 via one or more earth stations 104. A gNB-CU 307, together with one or more gNB-DUs 302 in communication with the gNB-CU 307, performs functions and may use internal communication protocols similar to or the same as those of a gNB using a split architecture as described in 3GPP TS 38.401. Here, the gNB distributed unit (gNB-DU) 302 corresponds to and performs functions similar to or the same as those of a gNB-DU defined in TS 38.401, and the gNB central unit (gNB-CU) 307 corresponds to and performs functions similar to or the same as those of a gNB-CU defined in TS 38.401. For example, gNB-DU 302 and gNB-CU 307 may communicate with each other using the F1 Application Protocol (F1AP) defined in 3GPP TS 38.473, and may together perform some or all of the same functions as gNB 106 or gNB 202 as previously described. To simplify references to different types of gNBs in the following description, gNB-DU 302 may sometimes be referred to as gNB 302 (without the "DU" tag), and gNB-CU 307 may sometimes be referred to as gNB 307 (without the "CU" tag).

[0078] The gNB-DU 302 may terminate at the radio interface to the UE 115 and the associated lower level radio interface protocols, and may send DL signals to the UE 115 and receive UL signals from the UE 115, which may include encoding and modulation of the transmitted signals and demodulation and decoding of the received signals. The gNB-DU 302 may support and terminate at the radio link control (RLC), medium access control (MAC), and physical (PHY) protocol layers of the NR RF interface to the UE 115, as defined in 3GPP TS 38.201, 38.202, 38.211, 38.212, 38.213, 38.214, 38.215, 38.321, and 38.322. The operation of the gNB-DU 302 is controlled in part by the associated gNB-CU 307. One gNB-DU 302 may support one or more NR satellite cells for the UE 115. The gNB-CU 307 may support and terminate the Radio Resource Control (RRC) protocol, Packet Data Convergence Protocol (PDCP), and Service Data Protocol (SDAP) of the NR RF interface to the UE 115, as defined in 3GPP TS 38.331, 38.323, and 37.324, respectively. The gNB-CU 307 may also be split into separate control plane (gNB-CU-CP) and user plane (gNB-CU-UP) portions, wherein the gNB-CU-CP uses the NGAP protocol to communicate with one or more AMFs 122 in one or more 5GCNs 110, and wherein the gNB-CU-UP uses the General Packet Radio System (GPRS) Tunneling Protocol (GTP) User Plane Protocol (GTP-U) to communicate with one or more UPFs 130 in one or more 5GCNs 110, as defined in 3GPP TS 29.281. The gNB-DU 302 and the gNB-CU 307 may communicate over the F1 interface to: (a) support control plane signaling for the UE 115 using IP, Stream Control Transmission Protocol (SCTP), and F1 Application Protocol (F1AP) protocols; and (b) support user plane data transfer for the UE using IP, User Datagram Protocol (UDP), PDCP, SDAP, GTP-U, and NR User Plane Protocol (NRUPP) protocols.

[0079] The gNB-CU 307 may use terrestrial links to communicate with one or more other gNB-CUs 307 and / or with one or more other terrestrial gNBs to support an Xn interface between any paired gNB-CUs 307 and / or between any gNB-CU 307 and any terrestrial gNB.

[0080] The gNB-DU 302 together with the gNB-CU 307 may: (i) support signaling connections and voice and data bearers to the UE 115; (ii) support handover of the UE 115 between different satellite cells of the same gNB-DU 302 and between different gNB-DUs 302; and (iii) assist in the handover (or transfer) of the SV 302 between different earth stations 104, different 5GCNs 110, and between different countries. The gNB-CU 307 may hide or mask certain aspects of the SV 302 from the 5GCN 110, for example, by interfacing with the 5GCN 110 in the same or similar manner as terrestrial gNBs. The gNB-CU 307 may further assist in sharing the SV 302 in multiple countries.

[0081] In the communication system 300, the gNB-DU 302 that communicates with and is accessible from any gNB-CU 307 will change over time along with the LEOSV 302. In the case of a split gNB architecture, the 5GCN 110 may be connected to a fixed gNB-CU 307 that does not change over time and may reduce the difficulty of paging the UE 115. For example, the 5GCN 110 may not need to know which SV / gNB-DU 302 is needed to page the UE 115. The network architecture with regenerated SV 302 with a split gNB architecture may therefore reduce the 5GCN 110 impact at the expense of additional impact on the gNB-CU 307.

[0082] For use Figure 3 Support for the regenerative SV 302 of the split gNB architecture shown in FIG. 3 may affect the communication system 300 as follows. The impact on the 5GCN 110 may be limited as discussed above for the transparent SV 102. For example, the 5GCN 110 may treat the satellite RATs in the communication system 300 as a new type of terrestrial RAT with longer latency, reduced bandwidth, and higher error rates. The impact on the SV / gNB-DU 302 may be less than that discussed above with reference to FIG. Figure 2 Impacts on SV / gNB 202 (with non-split architecture) discussed. SV / gNB-DU 302 may need to manage changing associations with different (fixed) gNB-CU 307. In addition, SV / gNB-DU 302 may need to manage satellite beams and satellite cells. For a network architecture with transparent SV 102, gNB-CU 307 impacts may be similar to gNB 106 impacts, as discussed above, except for the impact on supporting satellite cells and satellite beams (which may affect gNB-DU 302 but not gNB-CU 307).

[0083] To support satellite access using LTE, NB-IOT or eMTC, a regenerative SV 302 with a split architecture for satellite NodeBs may also be used. However, unlike the split architecture for terrestrial gNBs supporting 5G NR, no split architecture is defined for terrestrial ng-eNBs or terrestrial eNBs. However, in principle, a split architecture is possible using CUs and DUs that perform similar functions as gNB-Cu and gNB-DU for terrestrial ng-eNBs or terrestrial eNBs. In this case, Figure 3 The gNB-CU 307 shown may be composed of a CU for ng-eNB 114 (in Figure 3 ng-eNB-CU 308) or a CU for an eNB ( Figure 3 114 or eNB), and the gNB-DU 302 in the SV 302 may be replaced by a DU for the ng-eNB 114 or eNB. In this case, references to the gNB-DU 302 herein may refer to the DU for the ng-eNB 114 or eNB, references to the gNB 307 or gNB-CU 307 herein may refer to the ng-eNB-CU 308 or the CU for the eNB, and references to the SV 302 may refer to the SV having the onboard functionality of the DU for the ng-eNB 114 or eNB.

[0084] There are several SVOs currently in operation and several additional SVOs being prepared to begin operation that may be able to support satellite access using 5G NR or some other wireless access type (such as CDMA). The various SVOs may employ different numbers of LEO SVs and earth gateways, and may use different technologies. For example, currently operating SVOs include SVOs that use transparent ("bent pipe") LEO SVs that utilize CDMA and regenerative LEO SVs with ISL capabilities. New SVOs have recently been announced with plans for large constellations of LEO SVs to support fixed Internet access. These various SVOs are well known in the industry.

[0085] When supporting satellite access to a wireless network, SV 102 / 202 / 302 may send satellite beams (also referred to as "radio beams" or just "beams") over multiple countries. For example, the beams sent by SV 102 / 202 / 302 may overlap two or more countries. However, sharing beams over two or more countries may cause complexity. For example, in a situation where a beam is shared by two or more countries, an earth station 104 and gNB 106 / 202 / 302 / 307 in one country may need to support access by UE 115 from other countries. Sharing beams over multiple countries may cause security issues for the privacy of both data and voice. In addition, sharing SV beams over multiple countries may cause regulatory conflicts. For example, regulatory services including wireless emergency alerts (WEA), lawful interception (LI), and emergency services (EM) calls in a first country may require support from gNB 106 / 202 / 307 and earth station 104 in a second country that share the same SV beam.

[0086] One solution to the complexity caused by beam sharing between multiple countries may be to assign one beam to one country. Exceptions to assigning one beam to one country may exist for small nearby countries. Assigning a beam to a single country additionally implies assigning each satellite cell to one country.

[0087] Figure 4 An example of a communication system 400 is illustrated, which illustrates, by way of example, that SVs 102, 202, 302 generate multiple beams, identified as beams B1, B2, B3, B4, B5, and B6, over an area 405 that includes portions of multiple countries (e.g., country A, country B, country C). The communication system 400 may implement aspects of the wireless communication systems 100, 200, and / or 300. In the case where each beam is assigned to only one country, beams B1, B3, B5 are assigned to country A, beams B4 and B6 are assigned to country B, and beam B2 is assigned to country C.

[0088] In one implementation, individual beams may be assigned to a single country by steering or steer- ing the beam. Although non-geostationary orbit (NGEO) SVs have mobile coverage areas, the relative beam directions may be moved via steerable antenna arrays (sometimes referred to as "steerable beams") to remain or mostly remain within a country. For example, beam coverage may move slowly within a country and then jump to a new country, for example, after the SV 102, 202, 302 has been transferred to a new NTN gateway 104 or a new gNB 106 or 307.

[0089] In another specific implementation, satellite cells and satellite beams may be allowed to support access by different UEs 115 in two or more countries at the same time. For example, beam B1 may support access from UEs 115 in countries A and C, and beams B4 and B5 may support access from UEs 115 in countries A and B. In such cases, support for regulatory services may be important where the gNB 106 / 202 / 307 and / or AMF 122 can determine the country in which the UE 115 is located.

[0090] Figure 5 An example of a communication system 500 including a satellite cell generated by a SV 102, 202, 302 over an area 505 including multiple earth-fixed cells 502 is illustrated. The communication system 500 can implement aspects of the communication systems 100, 200, 300, and / or 400. The satellite cell can include a single beam or multiple beams, for example, all beams in a satellite cell can use the same frequency or the satellite cell can include one beam for each frequency in a set of different frequencies. For example, beams B1, B2, and B3 can support three separate satellite cells (one beam for each satellite cell) or can collectively support a single satellite cell (e.g., satellite cell 504 shown in dashed lines). Preferably, the satellite cells cover adjacent areas.

[0091] The satellite beams and satellite cells generated by the SVs 102, 202, 302 may not be aligned with cells used by terrestrial wireless networks (e.g., 5GCN 110 terrestrial cells or LTE terrestrial cells). For example, in an urban area, the satellite beams or satellite cells generated by the SVs 102, 202, 302 may overlap with many 5GCN fixed terrestrial cells. When supporting satellite access to a wireless network, information about the satellite beams and satellite cells generated by the SVs 102, 202, 302 may be hidden from the 5GCN 110 (e.g., not configured in the 5GCN or not provided to the 5GCN).

[0092] like Figure 5As illustrated, area 505 may include multiple earth fixed cells 502, and fixed tracking areas (TAs) such as TA 506. Fixed cells are not "real cells" such as for terrestrial NR and LTE access, and may be referred to as "virtual cells" or "geographic cells". Fixed cells such as fixed cell 502 have a fixed geographical coverage area that may be defined by a PLMN operator. For example, the coverage area of ​​a fixed cell or fixed TA may include the interior of a circle, an ellipse, or a polygon. The coverage area is fixed relative to the surface of the earth and does not change over time, which is different from the coverage area of ​​a satellite cell that generally changes over time for LEO or MEO SVs. Fixed cells 502 may be considered by 5GCN 110 to be the same as real cells supporting terrestrial NR access. A group of fixed cells 502 may define a fixed TA 506, which may be considered by 5GCN to be the same as a TA defined for terrestrial NR access. Fixed cells and fixed TAs for 5G satellite wireless access may be used by 5GCN 110 to support mobility management and regulatory services for UE 115 with minimal new impact.

[0093] In the case of a regenerated SV 202 utilizing a non-split architecture as in the communication system 200, each satellite cell may be maintained using the same SV 202 and may have mobile coverage areas supporting different 5GCNs 110 at different times.

[0094] In the case of a transparent SV 102 and a regenerative SV 302 with a split architecture as in the communication system 300, each satellite cell may be assigned to and controlled by a gNB 106 or 307 representing one or more PLMNs in a country. For GEO SVs 102 / 302, the assignment to the gNB 106 / 307 may be permanent or temporary. For example, the assignment may change daily to allow peak traffic to occur at different times in different parts of the SV 102 / 302 radio footprint and / or may change over longer periods of time to accommodate changing regional traffic needs. For non-geostationary (NGEO) SVs 102 / 302, the assignment may last for a short time, for example, only 5 to 15 minutes. The non-permanent satellite cell may then be transferred to a new gNB 106 / 307 as needed (e.g., when access to the NGEO SV 102 / 302 is transferred to the new gNB 106 / 307). For example, each gNB 106 / 307 may have a fixed geographic coverage area, e.g., including multiple fixed cells 502 and a fixed TA. When (or after) moving into the fixed coverage area of ​​a second gNB 106 / 307, the satellite cell of the first NGEO SV 102 / 302 may be transferred from the first gNB 106 / 307 to the second gNB 106 / 307. Prior to the transfer, a UE 115 accessing a satellite cell in a connected state may be moved to a new satellite cell of the first gNB 106 / 307 or may be handed over to the second gNB 106 / 307 as part of the transfer satellite cell. The SV 102 / 302 may be accessed from only one gNB 106 / 307 or from multiple gNBs 106 / 307 that may be in different countries. In one implementation, an SV 102 / 302 may be assigned to multiple gNBs 106 / 307 by partitioning the satellite cells generated by the SV 102 / 302 between different gNBs 106 / 307. The satellite cells may then be transferred to new gNBs 106 / 307 (and new countries) as the SV 102 / 302 moves or as traffic needs change. This implementation would be a form of soft handover, where the transfer of an SV 102 / 302 from one gNB 106 / 307 to another occurs in increments of satellite cells, rather than all at once.

[0095] Figure 6 An example of assignment of satellite cells (eg, cell 1 and cell 2 in communication system 600 ) generated by one or more SVs 102 , 202 , 302 over area 605 is illustrated. Figure 6 Aspects of wireless communication systems 100 , 200 , 300 , 400 , and / or 500 may be implemented.

[0096] In the communication system 600, and as illustrated, the area 605 includes multiple fixed TAs, such as TA1 to TA15, where TA4, TA5, TA8, and TA9 are assigned to gNB1 (which may be gNB 106, gNB 202, or gNB 307), and TA12, TA13, TA14, and TA15 are assigned to gNB2 (which may be another gNB 106, 202, or 307). In one specific implementation, a satellite cell may be considered to support a fixed TA if: the satellite cell is completely within the TA (e.g., cell 2 is within TA 12); the TA is completely within the satellite cell (e.g., TA4 is within cell 1); or the overlap of the coverage area of ​​the satellite cell and the TA exceeds a predetermined threshold fraction of the total coverage area of ​​the satellite cell or the total area of ​​the TA (e.g., cell 1 overlaps with TA1, TA3, TA5, TA8, or TA9). SV 102, 202, 302 may broadcast the identities (IDs) of supported PLMNs (e.g., where the PLMN ID includes a mobile country code (MCC) and a mobile network code (MNC)), and for each supported PLMN, broadcast the IDs of supported TAs (e.g., where the ID of the TA includes a tracking area code (TAC)), for example, in a system information block type 1 (SIB1) or SIB type 2 (SIB2). For NGEO SVs, the supported PLMNs and TAs may change as the satellite cell coverage area changes. gNB 106 / 202 / 307 may determine PLMN and TA support (and therefore the PLMN ID and TAC broadcasted in the SIB for each satellite cell) based on the known ephemeris data of each SV 102 / 202 / 302 and the known directivity and angular range of the component satellite beams of each satellite cell (e.g., cell 1 and cell 2). gNB 106 / 202 / 307 may then update the SIB broadcast.

[0097] Therefore, if Figure 6 As shown, SV 102 / 202 / 302 may broadcast a SIB including TACs of TA4 and possibly TA1, TA3, TA5, TA8, and / or TA9 for cell 1. Similarly, SV 102 / 202 / 302 or another SV 102 / 202 / 302 may broadcast a SIB including TACs of only TA12 for cell 2. Cell 1 may be assigned to gNB1 (which has coverage of TA4, TA5, TA8, and TA9), and cell 2 may be assigned to gNB2 (which has coverage of TA12, TA13, TA14, and TA15). In the event that the cell coverage area moves from one gNB area to another gNB area, cell 1 and cell 2 may be transferred from gNB1 to gNB2 or from gNB2 to gNB1.

[0098] The coverage area of ​​a fixed TA may be defined in a simple, precise, flexible manner, and requires minimal signaling to communicate to the UE 115 or gNB 106 / 202 / 307 or entity in the 5GCN 110. The fixed TA area may be small enough to allow efficient paging by including an area supported by only a few (e.g., less than 10) satellite cells, and may also be large enough to avoid excessive UE registrations (e.g., may extend for at least several kilometers in any direction). The shape of the fixed TA area may be arbitrary, e.g., the shape may be defined by a PLMN operator, or may have one or more restrictions. For example, one restriction on the shape of the fixed TA area may be that a fixed TA along a country border is precisely aligned with the border to avoid serving a UE 115 in another country. Additionally, the fixed TA may be restricted to align with an area of ​​interest, such as a public safety answering point (PSAP) service area, an area of ​​a large campus, etc. Additionally, the fixed TA may be restricted so that a portion of the fixed TA is aligned with a physical obstacle, such as the shore of a river or lake.

[0099] The coverage area of ​​a fixed cell may also be defined in a simple, precise, and flexible manner, and requires minimal signaling to communicate to the UE 115 or gNB 106 / 202 / 307. The fixed cell coverage area may allow for a simple and precise association with a fixed TA, e.g., a fixed cell may unambiguously belong to a fixed TA.

[0100] For an entity in a communication system (e.g., a UE 115 and / or AMF 122 in the communication system 100, 200, or 300), it may be beneficial to know when satellite coverage will be available and when it will not be available at a particular location (e.g., the current location of the UE 115). Conventional satellite coverage information technologies utilize satellite orbit and ephemeris data to indicate to an entity (e.g., the UE 115) when each of a plurality of satellites will be visible at a particular location (e.g., the current location of the entity). Using these techniques, the entity will need to calculate the position of the satellite (using orbit or ephemeris data) and determine at what time the satellite will be visible and will not be visible at a particular location, which may be processor intensive, require implementation of complex programming logic, and be prone to errors. For example, even when a satellite is visible at a location, the location may not be within the coverage of a satellite cell supported by the satellite (e.g., in the case where the satellite does not have an antenna pointed at the location and capable of sending and receiving signals to and from the location). Additionally, the satellite may not always have a backhaul connection to an NTN gateway (e.g., NNT gateway 104) during the time that the satellite is visible at the location (e.g., if the PLMN is not configured to provide coverage using the satellite when the satellite is visible at the location).

[0101] One way to provide satellite coverage data to the UE is by broadcasting ephemeris data at the access stratum (AS) level for the NTN RAT. For example, for EPS, a base station such as an eNB may broadcast ephemeris of up to (for example) four satellites in a system information block (SIB) such as SIB32 of coverage information for the RAT supporting a particular AS (e.g., LTE LEO). The base station may also broadcast orbital parameters (and possible positions) for each satellite. The amount of data broadcast by each satellite may be about 18 octets (e.g., such as EPS in 3GPP Release 17 using SIB32). The total data for four satellites is therefore about 72 octets. The LEO satellite coverage at any location may be in the range of 5 minutes to 15 minutes. Therefore, the broadcast data of the four satellites will provide coverage data for about the next 60 minutes at a minimum when there are almost no coverage gaps, or about 2 hours of coverage data in the case of 50% coverage, and about 10 hours of coverage data in the case of 10% coverage. The satellite may not return to cover the same location again for 12 hours or more, for example, due to the rotation of the earth. Therefore, SIB32 may only be used to indicate coverage for about 1 hour to 10 hours at any location. The amount of coverage data required for 24 hours coverage may therefore be as much as 500 to 1000 octets. Furthermore, the coverage data may not be completely reliable because radio cell information is not included, for example, radio cell coverage and areas where NTN is visible but not supported may not be addressed. Furthermore, the coverage data will not address the TN RAT. Additionally, there may also be security risks in the case of fake gNB / eNBs broadcasting SIB32 indicating lack of coverage when there is coverage.

[0102] Another way in which satellite coverage data can be provided to the UE is at the NAS level. For long-term coverage information at multiple locations, a large amount of data may be required, which may not be suitable for NAS transfer, which can usually be used to control services and mobility to the UE rather than to provide large amounts of data to the UE.

[0103] Therefore, new techniques may be needed to provide more accurate and reliable satellite coverage information to entities such as UE 115, AMF 122 and MME (in the case of 4G LTE networks). Satellite coverage information (or data) may also be referred to as Satellite Coverage Availability Information (SCAI).

[0104] One way to provide coverage information (e.g., SCAI) to the UE 115 is a coverage map, which may be more advantageous than providing satellite orbit (ephemeris) data. When coverage data is provided as ephemeris / orbit data, the UE must perform its own coverage prediction. For example, in the case where the UE is at position L at time T, the UE needs to determine whether there will be coverage at that position and time. To determine this, the UE will use the ephemeris (and any radio cells) data and calculate whether there is satellite visibility (for L and T) and whether there may be radio cell coverage for L and T (in a known situation). The answer can be a binary yes / no (e.g., there may be a threshold probability between yes and no). With a coverage map, the UE 115 may only need to look up the answer, which may be a very simple operation. Because the coverage map provider may have much more information than is available to the UE, the coverage map lookup of the yes / no answer may be much more reliable than providing the ephemeris data to the UE in only a few orbital parameters (e.g., the provider may know exactly how many satellites and radio cells will be supported for L and T).

[0105] Fig. 7A An example of assignment of satellite cells (eg, cell 1 and cell 2 in communication system 700) generated by one or more SVs 102, 202, 302 over an area divided into grid squares / points is illustrated. Fig. 7A Aspects of communication systems 100 , 200 , 300 , 400 , 500 , and / or 600 may be implemented.

[0106] Aspects of the techniques described herein may include a server (e.g., an operations and maintenance (O and M) server) that may be associated with (e.g., owned and operated by) a serving PLMN for a UE or a spacecraft operator (SVO). The server may determine, preconfigure, and signal satellite coverage data showing times of satellite cell (NTN) coverage and lack of coverage (e.g., times without NTN coverage) at different locations and / or at different times. The satellite coverage data may be provided by the server to the UE 115, AMF 122, MME, gNB 106 / 202 / 307, and / or other entities to show when wireless coverage via one or more satellite cells is available and when it is not available at one or more locations. The satellite coverage data may be determined (e.g., by the server) in part using SV orbit or ephemeris data, SV support of the satellite cells, and knowledge of the availability of backhaul connections to the NTN gateway. However, the satellite coverage data itself may exclude all such original source information and may more directly indicate coverage versus lack of coverage, which may reduce processing complexity and processing load at the receiving entity (e.g., UE 115 or AMF 122) and avoid errors.

[0107] In one embodiment, satellite coverage data may be provided in the form of a "coverage map" that may reference, indicate, or include a plurality of individual locations (designated herein as L1, L2, L3, ..., Ln) and / or a series of continuous times (designated herein as T1, T2, T3, ..., Tm). Thus, coverage data may be provided for one or more locations and at one or more times. Each location Li (1≤i≤n) may correspond to a single point on the surface of the Earth or to an area on the surface of the Earth (e.g., where each area is between 1 km and 20 km long from one side to the other, or where each point is spaced 1 km to 20 km from the nearest other point). The series of continuous times may occur at intervals, such as fixed intervals, where each fixed interval is 10 seconds to 2 minutes. In one specific implementation, these areas may each correspond to, for example, Figure 5 and Figure 6 The illustrated and described fixed cell or fixed tracking area. The location Li can also Fig. 7A The grid pattern arrangement illustrated in FIG. 1 , where the position Li may correspond to Fig. 7A The point 702 at which the vertical and horizontal lines intersect in Fig. 7A The vertical and horizontal lines in the rectangular area 704 define the area. Fig. 7A The grid pattern shown is rectangular, but other grid patterns are possible (e.g. based on triangles or hexagons). Fig. 7A Rectangular regions are shown, but the positions Li corresponding to the regions may have any shape, including, for example, circular, elliptical, and polygonal. In addition, the positions Li corresponding to the regions may be non-overlapping (e.g., Fig. 7A 115) or may be overlapping. For each location Li (1≤i≤n) and time Tj (1≤j≤m), the coverage map may indicate whether satellite coverage is available at that location and time. In the case where Li corresponds to an area and UE 115 is within the area, or in the case where Li corresponds to a point and is the closest point to UE 115, it may be assumed that UE 115 is at location Li.

[0108] Satellite coverage available may correspond to the location Li being completely or partially within the coverage area of ​​at least one satellite cell that can provide access to a particular PLMN (e.g., the current serving PLMN of UE 115, the home PLMN of UE 115, or any PLMN that UE 115 is allowed to access). Similarly, satellite coverage unavailable may correspond to the location Li not being completely or partially within the coverage area of ​​at least one satellite cell that can provide access to a particular PLMN (e.g., the current serving PLMN of UE 115, the home PLMN of UE 115, or any PLMN that UE 115 is allowed to access). For locations corresponding to points (e.g., Fig. 7A702 in FIG. 7 ), the point is usually within the coverage area of ​​the satellite cell or not within the coverage area, partially or completely within the coverage area. Fig. 7A For a location Li (area 704 in FIG. 1 ), the location Li may be partially within the coverage area of ​​the satellite cell but not completely within the coverage area, and therefore there may be a difference between a coverage map based on partial inclusion and a coverage map based on full inclusion. The UE 115 or other entity (e.g., AMF 122 or MME) may then decide (e.g., based on serving PLMN or home PLMN configuration data) whether to base the satellite coverage determination for the location Li on partial inclusion or full inclusion.

[0109] The coverage map may indicate whether satellite coverage is available at a location Li and a time Tj using a binary one value or a Boolean TRUE value (e.g., corresponding to coverage available) or a binary zero value or a Boolean FALSE value (e.g., corresponding to coverage not available). The coverage map may then be represented by an array or string of binary values ​​of one and zero (or Boolean TRUE and FALSE values), and thus represented as a bitmap, which may include a bit string or bit array, and in which there is a known correspondence between each bit in the bitmap and a specific location Li and time Tj. Additional information may be provided as part of the coverage map or separately therefrom to indicate the locations L1, L2, L3, ..., Ln and the consecutive times T1, T2, T3, ..., Tm represented in the coverage map, and (where not implicit) to indicate the method used to encode the bit values. Thus, a coverage map (e.g., a bitmap) may include a plurality of bits, each of which corresponds to satellite coverage data for a specific location and a specific time.

[0110] For example, Fig. 7A As shown, at time T11, UE 115 may be located within or at a grid point location where UE 115 is within the coverage area of ​​cell 2. Therefore, the bitmap may be encoded to indicate a "1" bit at a bit position corresponding to the current location of UE 115 at time T11. Therefore, UE 115 may transition to or otherwise enter the coverage state of cell 2 via SV 102 / 202 / 302 at time T11.

[0111] However, the movement of SV 102 / 202 / 303 may cause the coverage area of ​​cell 2 to move, so that at time T22, UE 115 is no longer in the coverage area of ​​cell 2. UE 115 accessing the coverage map may determine that its current location is out of coverage at time T22 by finding a "0" bit in the bitmap corresponding to the bit position of the current location of UE 115 at time T22. Therefore, at time T22, UE 115 may transition or otherwise enter a no coverage state. Various power saving and resource saving techniques may be employed by UE 115 when operating in a no coverage state.

[0112] At time T33, the movement of the other SV 102 / 202 / 302 may result in the current location of the UE 115 being within the coverage area of ​​cell 1. Again, the bit in the bitmap corresponding to the current location of the UE 115 at time T33 may be encoded as a "1" bit to again indicate that the UE 115 has satellite coverage at time T33. Thus, the UE 115 may transition to or otherwise enter a coverage state and resume communications via the other SV 102 / 202 / 302.

[0113] The total number of bits in the bitmap may depend on the number of locations n and the number of times m for which coverage data is provided. For example, for a PLMN with a 2000 km×2000 km coverage area, 24 hours of coverage data, a 1 minute interval between consecutive times, and a 20 km square grid point spacing, the coverage map may be encoded as a bitmap containing (100×100×24×60) bits, which equals 1.8 megabytes (million octets) of uncompressed data. However, it is likely that, because coverage conditions are generally the same at nearby times and nearby locations, the bits in the bitmap corresponding to nearby locations and nearby times will generally have the same value (“1” or “0”). This may allow the bitmap to be compressed using one-dimensional, two-dimensional, or three-dimensional compression techniques (e.g., compression algorithms). For example, using one-dimensional techniques, runs of consecutive zero or one-bit values ​​in a bitmap can each be encoded as a different, typically shorter, bit sequence that can be distinguished from any other bit sequence encoding (e.g., using a one-dimensional coding scheme defined in the ITU T.4 "Standardization of Group 3 fax terminals for document transmission" standard). This can significantly reduce the overall size of the bitmap. For example, using two-dimensional techniques, a bitmap applicable to one time (e.g., T1) can be compressed using a one-dimensional technique, and then a bitmap for the next time (e.g., T2) can be encoded by assigning a "0" bit value to any position Lj that covers it that has not changed since the previous time T1 and assigning a "1" bit value to any position Lk that covers it that has changed since the previous time T1. The bitmap can then be compressed using the same (or similar) one-dimensional technique as the bitmap at time T1. Additionally or alternatively, a bitmap may be provided to an entity (e.g., UE 115) for only a single location (e.g., the current location of UE 115) or for a small number of locations, which may significantly reduce the size of the bitmap. For example, the small number of locations may include: (i) locations near UE 115; (ii) locations recently visited by UE 115; (iii) locations that UE 115 habitually visits, such as work, home, or locations of friends or relatives; (iv) locations indicated by UE 115 as being of interest; (v) locations that UE 115 is expected to visit in the near future; or (vi) some combination of these locations. For the previous example, in the case of providing a bitmap for only one location, the uncompressed bitmap size would be reduced to 180 bytes, and in the case of providing a bitmap for an area of ​​100 km×100 km, the uncompressed bitmap size would be 4.5 kilobytes.

[0114] A separate time-location based coverage map may be provided for each RAT, or the coverage maps for each RAT may be combined, for example using a logical OR or by including separate bit values. Additionally, a coverage map for the TN RAT may be provided. In some implementations, the coverage map may provide two (or more) bits for each location and time to indicate the probability of coverage (e.g., zero, low, medium, high). For a location, 24 hours of coverage with 2 minute intervals, the uncompressed data size of the coverage data for one RAT may be approximately 90 octets.

[0115] Figure 7B An example of an overlay represented by a bitmap for a communication system 750 generated by one or more SVs 102, 202, 302 over an area covered with a square array of grid points is illustrated, where compression may be used. Figure 7B Aspects of communication systems 100, 200, 300, 400, 500, 600, and / or 700 may be implemented. The grid point array in communication system 750 includes 25 grid points (labeled L1, L2, L3, ..., L25) separated from each other by a distance D (e.g., where D equals 10 km to 50 km) and arranged around a central grid point 752 (corresponding to location L13), which may correspond to the current or most recent location of UE 115. The grid point array may be used to provide UE 115 with a coverage map for the current or most recent location of UE 115 (corresponding to grid point 752) and for a small number of locations at grid points near the current or most recent location. Figure 7B Satellite coverage 760 of a grid point array at time T1 and satellite coverage 770 of the same grid point array at a subsequent time T2 (e.g., where T2 may occur one or several minutes after time T1) are shown. The grid point locations with satellite coverage are Figure 7B Grid point locations with no satellite coverage are represented by small solid black disks in Figure 7B, represented by a small disk with a white interior. In the case of using a bit string to represent coverage at the grid point position at time T1 (where a "1" bit value is used to indicate coverage and a "0" bit value is used to indicate no coverage), the bit string for the positions L1, L2, L3, etc. in order would be "0000000011111000001100000". This bit string contains 25 bits (for 25 positions), in which there are 8 consecutive "0" values, 5 consecutive "1" values, 5 consecutive "0" values, 2 consecutive "1" values, and 5 consecutive "0" values. These values ​​can be compressed, for example, to "10011", "0011", "1100", "11", and "1100", respectively, using a one-dimensional decoding scheme defined in the ITU T.4 standard (and using white to represent "0" values ​​and black to represent "1" values). This allows the bit string to be compressed to "1001100111100111100", which now has 19 bits. A bit string representing coverage 770 at time T2 can be created using a "0" bit value for any position whose coverage did not change at time T2 and a "1" bit value for any position whose coverage changed at time T2. Figure 7B In the example of , at time T2, the coverage changes only at positions L17 and L18. Therefore, the bit string showing the coverage 770 at time T2 would be "0000000000000000110000000". This bit string has 16 consecutive "0" values, 2 consecutive "1" values, and 7 consecutive "0" values. These values ​​can be compressed to "101010", "11", and "1111", respectively, for example using the ITU T.4 one-dimensional decoding scheme. This allows the bit string to be compressed to "101010111111", which now has only 12 bits. Compression can be particularly efficient when a large area including many grid point locations is completely in coverage or completely out of coverage, and / or when the coverage does not change from one time to the next, because there can be a large number of consecutive bits with the same bit value, which can allow much higher compression than in the above two examples (e.g., using the ITU T.4 standard scheme or other schemes).

[0116] In another embodiment, satellite coverage data may be provided in the form of a "time series" that may include a sequence of times or time periods indicating when satellite coverage begins and ends at a particular location. For example, a sequence of consecutive times t1, t2, t3, ..., tr indicating when satellite coverage may begin or end at a certain location may be provided, wherein alternating times in the sequence alternately indicate the beginning or end of satellite coverage. For example, it may be indicated that satellite coverage begins at t1, ends at t2, begins again at t3, ends again at t4, and so on. There may be an implicit convention or an explicit indication that the first time in the sequence indicates the beginning (or end) of satellite coverage. In a variation of this embodiment, the consecutive times t1, t2, t3, ... may include time periods rather than moments. Then, there may also be an implicit start time T (e.g., which may be the current time at which the entity receives the consecutive times) or an explicitly provided start time T. The entity may then determine that satellite coverage will begin (or end) at time T+t1, end (or start) at time T+t1+t2, start again (or end again) at time T+t1+t2+t3, and so on.

[0117] In some embodiments, the coverage map may be combined with a time series. For example, a coverage map (e.g., a bitmap) indicating locations with and without satellite coverage at time T1 may be provided to UE 115. A second time T2 or duration D2 indicating the time or duration for the coverage map may also be provided to UE 115. For example, providing time T2 may indicate that the satellite coverage indicated by the coverage map remains the same from time T1 to time T2 (for all locations in the coverage map). Similarly, providing duration D2 may indicate that the satellite coverage indicated by the coverage map remains the same for duration D2 (i.e., from time T1 to time T1+D2). In some embodiments, when all locations in the coverage map have satellite coverage or do not have satellite coverage, a coverage map and additional time or duration (e.g., T2 or D2 in the previous example) may be provided.

[0118] Figure 7CAn example of a coverage map 780 showing locations 782 as grid points in a rectangular array is illustrated. As discussed above, the coverage map 780 may enable the UE 115 to determine that it must remain without service or must attempt to register on a different RAT / PLMN that is available to receive normal service during discontinuous coverage in the current NTN RAT. By using the coverage map 780, the UE 115 may avoid attempting PLMN access when there is no network coverage. In addition, the coverage map 780 may inform the UE 115 when there is network coverage so that the UE 115 may attempt PLMN access as needed, such as to deliver signaling, deliver data, or receive paging, etc., where network coverage is provided by any RAT supported by the UE. The content of the coverage data in the coverage map 780 may be general enough to support both satellite (NTN) RAT and TN RAT, either alone or in combination.

[0119] The content of the coverage data included in the coverage map 780 may show the expected coverage of one or more satellite RATs and / or one or more terrestrial RATs at one or more locations and at a specific time in the future. A set of coverage maps may then be provided to the UE 115 for each time in a time series that occurs at fixed periodic intervals (e.g., at one-minute intervals). The locations 782 supported by the coverage map 780 may correspond to grid points in a rectangular array, such as Figure 7C shown, but other arrays are possible, such as a hexagonal array.

[0120] exist Figure 7C , each grid point (dot) 782 represents a location. These locations (i.e., grid points) may be spaced apart by fixed distances (e.g., 20 km to 400 km) horizontally and vertically. The absolute position of each grid point may then be learned by specifying an absolute (global) position for only one grid point in the array (e.g., the center grid point or one grid point at a corner). The expected (satellite and / or land) coverage at the location of each grid point may be indicated by a binary one value (e.g., when coverage exists) or a binary zero value (e.g., when coverage does not exist), which will allow the entire coverage map to be represented and encoded as a binary array, as previously described. This binary array may be applicable to only one time, and then may need to be repeated to indicate coverage at other times. For example, at Figure 7C In the case of the grid point array shown, 36 bits would be needed to indicate coverage at all 36 grid points. In the case where this coverage applies to time T1 and coverage of additional times T2, T3, ... Tm is needed, a total of 36*m bits would need to be provided along with some encoding rules as to how these bits are associated with different grid point locations and different times T1 to Tm.

[0121] Instead of providing a simple binary "yes / no" coverage indication, the expected coverage can be indicated by assigning two or more bits per location to indicate the coverage probability. For example, where 00 = zero coverage probability, 01 = low probability, 10 = medium probability, 11 = high coverage probability. The coverage map 780 can also indicate coverage for only one RAT, or can indicate the expected coverage for multiple RATs. For example, in the case where binary coverage values are assigned to multiple RATs R1, R2, ... Rn, a binary one can mean that there is coverage from at least one of RATs R1 - Rn, while a binary zero value can indicate that no RAT provides coverage.

[0122] Because it is likely that the coverage will generally be the same for nearby times and for nearby locations, there is a possibility of compressing the binary encoding of the coverage map to reduce the bit size.

[0123] In the case of one location (e.g., which may be suitable for a UE 115 that will not move more than about 200 km from some initial location), the size of the binary coverage map of 24 - hour coverage data at 2 - minute intervals can be 90 octets without compression and ignoring additional data such as a global location indication for one location.

[0124] Figure 7C The example in assumes that the coverage map 780 is spatial (for only one time), and as previously described, repeats the coverage map for subsequent times, i.e.:

[0125] Coverage map = <Coverage of locations L1 to Ln at T1><Coverage of locations L1 to Ln at T2>

[0126] <Coverage of locations L1 to Ln at T3>... <Coverage of locations L1 to Ln at Tm>

[0127] However, this can be reversed by providing a time coverage map for one location (grid point) of a time series and then repeating that time coverage map for each of the other locations (grid points), i.e.:

[0128] Coverage map = <Coverage of location L1 at T1, T2,... Tm><Coverage of location L2 at T1,

[0129] T2,... Tm><Coverage of location L3 at T1, T2,... Tm>…<Coverage of location Ln at T1, T2,... Tm>

[0130] According to some embodiments, a smaller grid - point spacing (e.g., 100 km instead of 400 km) and a smaller interval between consecutive times (e.g., 15 seconds instead of 1 minute) can be used to increase the accuracy (precision) of the coverage and no - coverage indications, but this is accompanied by an increase in the size of the coverage map.

[0131] According to some embodiments, in order to compress the data size of the coverage map, any sequence of repeated binary ones or repeated binary zeros in the coverage map can be indicated by including the number of repeated binary ones or binary zeros rather than by including all repeated values. For example, a time coverage map for one position X (grid point) of the time series can be represented as:

[0132] Coverage at position X = <start time><1 / 0 duration 1><1 / 0 duration 2><1 / 0 duration 3>...<1 / 0 duration N>

[0133] In this example, a leading 1 or 0 binary value may indicate whether there is coverage, and the value of the associated duration indicates how long the coverage or lack of coverage will last. The duration may be related to an actual period of time given a start time. In the case where the duration is encoded as a 7-bit value (e.g., in minutes), the coverage at position X will become an octet sequence rather than a binary sequence. In the case of no coverage and / or the duration of coverage tends to be quite large (e.g., greater than 20 minutes), such as when coverage is very sparse or highly available, this may result in a much smaller coverage map than using binary encoding. The duration may be further encoded using 2 alternative units (e.g., minutes versus seconds, as indicated by the use of an additional bit) to achieve higher accuracy and precision with only a small increase in the size of the coverage map data.

[0134] SCAI may also be provided to the MME or AMF (e.g., AMF 122) and the UE. For the AMF (or MME), SCAI may be applied to a region and implicitly to a potentially large service area of ​​the AMF (or MME) (e.g., an entire country or region of a country). SCAI may also need to be applied to the region for a certain period of time (e.g., 6 hours, 24 hours, 48 ​​hours, etc.) to enable an indication of when coverage is available or unavailable for different locations within the region.

[0135] A single UE (e.g., UE 115) typically does not require SCAI for the entire AMF (or MME) area. However, since the UE may move around and may move unpredictably within the AMF (or MME) service area, and may cross different AMF (or MME) service areas, a regional approach to supporting the UE's SCAI may also be appropriate. For example, in extreme cases where the UE is not expected to move a large distance (e.g., less than 25km), the UE SCAI may be minimized to a single location or a smaller area around a single location (e.g., a circle with a radius of 25km). In other cases where the UE may move longer distances, the possible future location of the UE (e.g., based on a maximum travel distance estimate) may be used to define a larger area for which SCAI is provided. When the UE may cross an AMF (or MME) area, either possibility will make the UE SCAI a subset of the SCAI for one AMF (or MME) or for several AMFs (or MMEs).

[0136] Additionally or alternatively, the UE SCAI may be based on a known or expected trajectory of the UE, where future UE locations may be defined together with the times at which the UE will be at these locations. When the time is unknown, the UE trajectory may define areas where SCAI may be provided as a subset of the SCAI for the AMF (or MME). When the time is known, the UE SCAI may be provided for a specific location at a specific time, which may reduce the amount of SCAI. However, by including coverage information of a subset of both the location and time of the SCAI for the AMF (or MME), the UE SCAI may remain a subset of the SCAI for the AMF (or MME).

[0137] With respect to the content of SCAI, according to some embodiments and as previously described, satellite coverage availability may be represented by a Boolean "true" or "false" value (e.g., as for 7A to 7C The UE may also provide a 3GPP TS 38.304 (for example, 3GPP TS 36.304 for LTE) indication which may be provided for a set of locations (e.g., within an AMF or MME area or within an area applicable to the UE) and for a time series. At a particular location and time, the indication may simply mean that the UE will be able (true) or unable (false) to access at least one satellite of a particular satellite RAT at that location and time. This would mean being covered by at least one satellite radio cell with sufficient signal power and quality at the particular location and time to be considered a "suitable cell" by the UE (e.g., as required in 3GPP TS 38.304 for NR or 3GPP TS 36.304 for LTE). Radio cells that are unable to provide coverage to a particular location due to regulatory requirements (e.g., in the case where a radio cell unintentionally provides coverage to a non-allowed country) or PLMN restrictions (e.g., in the case where a radio cell does not support a particular serving PLMN or equivalent PLMN at a particular location) would have to be disregarded (e.g., ignored).

[0138] However, not all UEs may be equal in their minimum signal received power and quality requirements for selecting a "suitable cell". Differences may exist between different types of UEs, such as very small aperture terminals (VSATs) with small (and movable) dish antennas, handheld UEs (e.g., smartphones) with integrated antennas, and UEs in vehicles or within buildings with access to external (e.g., non-dish) antennas. These differences may affect cell selection for satellites with low elevation angles (e.g., 15 degrees or less), where low signal levels may allow some UEs to access but not others.

[0139] Since access to a suitable cell may depend on the UE's receiver sensitivity including the UE antenna gain or loss, the SCAI true and false indications may assume a standard minimum receiver sensitivity for the UE, e.g. as defined in 3GPP TS 38.101-5 for NR and 3GPP TS 36.102 for LTE. Any deviation from this (e.g., for VSAT UEs) may be indicated by the UE's receiver and antenna gain or loss relative to the standard minimum sensitivity.

[0140] Alternatively or additionally, the SCAI may distinguish between (e.g., based on) one or more of the following UE parameters:

[0141] - UE type (e.g. VSAT, handheld UE with integrated antenna, other UE with external antenna)

[0142] -Antenna Rx gain (or loss)

[0143] - Overall UE receiver and antenna gain (or loss)

[0144] -The minimum received power (and quality) level supported by the UE

[0145] The SCAI provided to the AMF or MME (e.g. provided by the O and M servers) may then include SCAI for each of the different allowed values ​​of the above parameters, while the SCAI provided to a single UE (e.g. provided by a server or by an AMF or MME) will include SCAI only for specific parameter values ​​applicable to that UE.

[0146] Additionally or alternatively, providing the SCAI (e.g., from a server to a UE, AMF, or MME) may include providing an indication of the maximum signal power (and quality) of all satellite radio cells available at any location and time to provide coverage to that location at that time. The signal power (and quality) may be in terms of intensity (i.e., dBm per unit area of ​​power) or in terms of power received by an ideal isotropic antenna (dBm). This indication of maximum signal power (and quality) may be provided over the entire area at any particular time in the form of a heat map, where locations with the same maximum signal power (and quality) level will have a common value (or values), which may be visually represented by a unique shading and / or color on a map of the area. Multiple instances of such a heat map may be provided to the UE, AMF, or MME for a series of separate times. For the UE, a small map with power level indications only for a particular location (and time) may be sufficient.

[0147] Fig.7D An example visual representation of a heat map is shown. In this example, a heat map of region 782 is illustrated for SVs 102, 202, 302. In the heat map, region 782 is divided into regions having high 784, medium 786, and low 788 maximum signal powers, respectively. Other heat maps may vary in the number of levels of value, allowing for a coarser or finer plotting of signal power, depending on the desired functionality.

[0148] For UEs, according to some embodiments, SCAI may be provided for known or expected UE trajectories. In limited degradation situations, when the UE is not expected to move beyond a certain maximum distance (e.g., 25 km), the trajectory may become a single location. The initial location may be provided using full coordinates (e.g., latitude, longitude), and subsequent locations (when present) may be indicated as locations relative to the initial location. SCAI indications may then be provided for each location, and may be provided one or more times when the UE is expected to have been or may be present at that location.

[0149] According to some embodiments, in order to indicate different locations over an area (e.g. for an AMF or MME or for a UE whose future mobility is unknown), a grid point method may be used in which the location is indicated for a set of grid points in a rectangular or hexagonal array with equal spacing (e.g. as for Figure 7B and Figure 7C described above).

[0150] Fig. 7E An example rectangular grid point array 790 is illustrated, and Figure 7FAn example hexagonal grid point array 795 is illustrated. A Boolean coverage availability indication or digital signal power indication may be provided to each grid point and may be calculated (e.g., by a server) to apply to only that location (option A) or to an area around the grid point ("grid point area") (option B). As an example, the digital signal power indication for a grid point may be set to the signal power at the grid point location (for option A) or to the minimum signal power of all locations in the grid point area (for option B). The Boolean coverage availability indication may similarly be set to true if and only if there is coverage at the grid point location (for option A) or at all locations in the grid point area (for option B).

[0151] According to some embodiments, a SCAI indication for a set of grid points may be provided for a time series with a fixed periodic interval. There may be a convention that the SCAI indication remains valid for some minimum portion of the time interval. For example, for the time series T0-T, T0, T0+T, T0+2T (where T is a periodic interval), the SCAI indication provided for T0 may be calculated to be applied to some portion (up to 100%) of time T0 or the time interval T0-0.5T to T0+0.5T at a minimum. The decoding of SCAI may be based on location and then on time, wherein SCAI indications are provided for all grid point locations at a specific time, and then the data is repeated for each consecutive time. Alternatively, the decoding may be based on time and then on location, wherein the opposite convention is used. The entire SCAI may be encoded as a bit string using a single bit to represent a Boolean coverage availability indication and a binary value to represent a digital signal power indication. In some cases, the SCAI indication may remain the same for different locations for a long time. This is generally applicable when satellite access availability is low (e.g., less than 15% of the time) or high (e.g., greater than 85% of the time). For these cases, providing a SCAI indication for a time series with a fixed periodic interval will typically repeat much of the same data at each periodic time. In this case, a more efficient way to provide a SCAI indication may be to provide the SCAI indication along with the period for which the indication applies. For a particular location and N durations, this would result in a sequence of the following type:

[0152] <Initial Time> <n><SCAI Indication 1><Period 1><SCAI Indication 2><Period 2>…<SCAI Indication N><Period N>

[0153] The initial time may indicate the start time. Each period may indicate how long a particular SCAI indication is to be applied, where the start time of the period is equal to the initial time plus all previous periods. According to some embodiments, this may be encoded as a bit string and repeated for each grid point or each location.

[0154] Regarding the encoding of SCAI, different types of SCAI content as described above may be combined and then encoded in different ways. Three examples that may be used according to some embodiments are provided below. It is assumed that these examples are for providing SCAI to a UE, where the UE first indicates a plurality of parameters (referred to as input parameters) and parameter values to an SCAI source such as a server, and then the server transmits the SCAI applicable to the parameters and parameter values received from the UE. However, these examples may also be applied to providing SCAI to an MME or an AMF instead of to a UE, where the MME or AMF provides the same parameters and parameter values (instead of the UE) and receives back the SCAI applicable to these parameters and parameter values.

[0155] A first example of SCAI encoding involves using grid points with a boolean coverage availability indication. In this example, the UE may first indicate the following "input parameters" to an SCAI source (e.g., an external server):

[0156] · A list of registered PLMNs and / or supported PLMNs (in cases where it is not known or implied);

[0157] · One or more satellite RATs (where satellite availability is then based on the radio cell availability of any RAT);

[0158] · A list of supported frequency bands (in cases where it is not implied by a particular RAT);

[0159] · The location (e.g., latitude and longitude) of a reference grid point (e.g., the most southerly and then the most westerly grid point);

[0160] · Grid point spacing;

[0161] · Start time, periodic time interval, number of periodic times;

[0162] · Array type (e.g., rectangular or hexagonal);

[0163] · The number of grid points (e.g., the total number or individual numbers in the north-south and east-west directions);

[0164] · The parameter of the minimum received signal power includes one or more of the following items:

[0165] o UE type (e.g., VSAT, handheld UE with integrated antenna, other UE with external antenna);

[0166] o UE category (e.g. category M1 or category NB1 / NB2 for UEs with E-UTRA access);

[0167] oUE antenna Rx gain (or loss);

[0168] ○ Relative to the minimum required UE receiver and antenna gain or loss (e.g., in 3GPP TS 38.101-5 or 3GPP TS 36.102);

[0169] o the minimum received power (and quality) level supported by the UE; or

[0170] ○Some combination of these items.

[0171] As described above, the AMF or MME may provide the same set of input parameters when requesting SCAI (e.g., from a server or using O and M), but these parameters may be provided separately for each satellite RAT, each frequency band, and for different received signal power parameters.

[0172] Note that the grid point spacing may define the north-south and east-west straight-line distances between adjacent pairs of grid points. Due to the curvature of the Earth, this distance may be measured on a great circle that may be a line of longitude for the distance in the north-south direction, and may be measured on a great circle at right angles to the distance in the east-west direction (the great circle approximates a line of latitude at lower latitudes, but deviates from the line of latitude at higher latitudes).

[0173] Input parameter values ​​may be restricted to reduce complexity. For example, the reference position may be quantized to exact degrees or exact half degrees of latitude and longitude; the grid point spacing may be restricted to, for example, 20km, 50km, 100km, or 200km; the start time may be the current time rounded to the next minute boundary; the time interval may be restricted to, for example, 30 seconds, 1 minute, 2 minutes, or 5 minutes; the number of times may be 100 times a certain power of 2; only rectangular arrays may be supported; the number of grid points may be restricted to squares with 1, 2×2, 3×3, 4×4, etc. grid points; and the minimum received signal power parameter may indicate only one of only a few values ​​for UE type, UE category, or receiver and antenna gain or loss.

[0174] Based on the above input parameters, the SCAI (e.g., from an external server) may be delivered to the requesting UE or requesting AMF or MME as a sequence of bit strings, where each bit string is for a separate time and includes one bit for each grid point in the grid point array, where a value of one indicates coverage and a value of zero indicates no coverage for the UE to which the above input parameters apply. There may be a fixed order of grid point inclusion (e.g., from west to east, then from south to north, starting at the reference grid point). This may result in a combined bit string containing only the SCAI Boolean indication, without the need for delimiters, length indications, or parameter type indications. In one example (referred to as "Example 1"), for a 2000 km x 2000 km square area containing 1600 grid points spaced 50 km apart and with a periodic time interval of 1 minute, the combined bit string size for 24 hours of data may have the following size:

[0175] SCAI size = (1600 × 24 × 60) bits

[0176] = 2.3 megabits or 288 kilobytes

[0177] This may be reasonable for the AMF or MME, although in some embodiments it may not be the case for the UE. In another example, for only one mesh point and a periodic time interval of 1 minute in 24 hours, the SCAI data size may be reduced to 180 octets, which may be small enough for one UE even using transport by SMS.

[0178] A second example of SCAI encoding involves using mesh points with a Boolean coverage availability indication and a duration indication. Based on input parameters, which may be the same as the input parameters of the first example of SCAI encoding described above, SCAI may be delivered as a sequence of durations for each mesh point, where each duration includes a Boolean indication of coverage availability or unavailability. When there are N durations (Duration 1, Duration 2, Duration 3, etc. to Duration N), for each mesh point, the output may look as follows:

[0179] Output = <n><binary 0 or 1><duration 1><binary 0 or 1><duration 2><binary 0 or 1><duration 3>…<binary 0 or 1><duration N>

[0180] The above initial value ( <n>) provides the number of durations, and each duration (e.g., <Duration n>) may be encoded as a fixed length bit string (e.g., 8 bits). The above output for only one grid point may then be concatenated for all grid points according to some defined ordering of the grid points to produce the complete SCAI as a combined bit string. For Example 1 above, and assuming that the average duration is 15 minutes and that 2 octets are used to encode the number of durations N, and 1 octet is used to encode each duration, the total SCAI size may be:

[0181] SCAI size = 1600x(16+(24x 60 / 15)x 9) bits

[0182] = 1.41 megabits or 176 kilobytes.

[0183] For only one grid point in this example, the SCAI data size can be reduced to 110 octets.

[0184] A third example of SCAI encoding involves using grid points or tracks with signal power and duration indications. For grid points, the input parameters may be described as above for the first example of SCAI encoding. For tracks (where it is assumed that the time and duration of the UE at each location may be unknown), the UE may indicate the following input parameters to the SCAI source (e.g., an external server):

[0185] A list of supported PLMNs (where this is not known or implied);

[0186] One or more satellite RATs (satellite availability is then based on radio cell availability of any RAT);

[0187] A list of supported frequency bands (in case not implied by a specific RAT);

[0188] Reference location (e.g., latitude and longitude where the trajectory starts);

[0189] an additional position of the trajectory (e.g. relative to a reference position or relative to a previous additional position);

[0190] Start time and total duration;

[0191] • Parameters for minimum received signal power as in the first example of SCAI encoding.

[0192] The above input parameters may be restricted to reduce complexity, as in the first SCAI example described above.

[0193] Based on the above input requirements, SCAI shall be delivered (eg to UE, AMF or MME) as a sequence of durations for each grid point or each location on the trajectory, where each duration comprises a numerical signal power (and quality) level for a supported frequency band.

[0194] For each grid point or each location and in case of N durations, the SCAI output may be as follows:

[0195] Output = <n><Signal power / quality level><Duration 1><Signal power / quality level><Duration 2>....<Signal power / quality level><Duration N>

[0196] This output may be encoded as a bit string and concatenated over all grid points or all positions based on a defined ordering of the grid points or positions to produce the final SCAI.

[0197] For the grid point example in the second example of SCAI encoding, and assuming that the signal power / quality level can be encoded in 2 octets and the average duration is 10 minutes, the total SCAI size may be:

[0198] SCAI size = 1600x(16+(24x 60 / 10)x 24) bits

[0199] = 5.56 Mbits or 694 Kbits.

[0200] For only one grid point in this example, the SCAI data size will be reduced to 434 octets.For a 2000 km long track containing positions at 50 km intervals (hence containing 41 positions), the SCAI size may be 17.8 kilobytes.

[0201] The coverage map (or set of coverage maps) may be provided to the UE by a server via the user plane or short message service (SMS), or may be provided to the UE by the MME or AMF using NAS. Two alternative solutions may be used for this purpose:

[0202] The first solution (referred to as "Solution A") is based on an HTTPS or SMS query from the UE to the server. The UE may include authorization data with the query that is meaningful to the server and was previously provided to the UE by the serving PLMM (also referred to as the Registered PLMN (RPLMN)).

[0203] • The second solution (referred to as "Solution B") is based on a simple NAS request / response (eg, as part of a NAS Attach, Tracking Area Update (TAU), or Registration).

[0204] For example, the communication may be based on an HTTPS query from UE 115 to the server via the user plane (e.g., as described later in Fig. 8A and Figure 8B The UE 115 may be provided with a coverage map (or set of maps) from a server. This may be supported by a visited PLMN (VPLMN), a home PLMN (HPLMN), or by a satellite operator. The UE 115 may also provide the server with a temporary identifier (ID) that is preconfigured in the server and verifies the permission (e.g., subscription) of the UE 115 to receive coverage data. The temporary ID may be assigned to the UE by the VPLMN or HPLMN after verifying the UE subscription or other permission to receive coverage data. The temporary ID may be or look like a large random number (e.g., 128 bits) to ensure security.

[0205] In another specific implementation, satellite coverage data, for example in the form of coverage maps and / or time series, may be provided to AMF 112 and / or gNB 106 / 202 / 307 (e.g., by O and M servers). AMF 112 or gNB 106 / 202 / 307 may then filter, reformat, or otherwise modify the satellite coverage data for easier and faster access (e.g., by UE 115), which may reduce the total satellite coverage data size (e.g., in the case where AMF 112 or gNB 106 / 202 / 307 removes data for certain locations and / or times in the satellite coverage data that are not needed by UE 115). AMF 112 or gNB 106 / 202 / 307 may then provide the filtered, reformatted, or otherwise modified satellite coverage data to UE 115, for example, only for the current UE 115 location, for all locations near UE 115, or for the entire serving PLMN coverage area (e.g., as described above). For example, the AMF 122 may provide satellite coverage data to the UE 115 using a non-access stratum (NAS) message (e.g., when the UE 115 performs a NAS registration with the AMF 122). The gNB 106 / 202 / 307 may also broadcast satellite coverage data (e.g., in one or more SIB messages) in each satellite cell to all UEs 115 that have access to the satellite cell. The broadcast satellite coverage data may be limited to providing coverage information only for locations within the current coverage area of ​​the satellite cell, or in an extreme variant, satellite coverage data may be provided only for a single location that includes the current coverage area of ​​the satellite cell or for a center location of the coverage area. The coverage information provided using this extreme variant may be approximate, because not all locations within the current coverage area of ​​the satellite cell will necessarily receive the same satellite coverage at a future time. However, a convention may then be used according to which, in the event that at least a portion of the entire current coverage area of ​​the satellite cell (e.g., the center location) receives satellite coverage at any future time, coverage is indicated as being available for the entire current coverage area of ​​the satellite cell at that future time. A UE 115 utilizing satellite coverage data for this extreme variation may then realize that, even when its current location is within a location area where satellite coverage is indicated as available at a future time, coverage may not always be available at the current location at the future time.

[0206] As described above, satellite coverage data may be provided to UE 115, which may include one or more coverage maps (e.g., each coverage map including a bitmap) and / or a time series indicating satellite coverage availability for one or more locations and / or for one or more times. For example, AMF 122 may transmit to UE 115 satellite coverage data (e.g., in the form of a bitmap or a time series) only for the current UE 115 location, which current location may be based on the current serving fixed cell of UE 115 or the current TA in which UE 115 is located (e.g., as indicated to AMF 122 by the serving gNB 106 / 202 / 307 of UE 115). Alternatively, UE 115 may transmit a request (e.g., a NAS request message) to the serving AMF 122, which indicates one or more locations and time periods for which UE 115 requests satellite coverage data. AMF 122 may then transmit to UE 115 the satellite coverage data for the indicated locations and time periods (e.g., in a NAS response message). For example, AMF 122 may determine satellite coverage data based on more complete and comprehensive satellite coverage data (e.g., for the entire PLMN coverage area) received by AMF 122 from O and M servers or from gNB 106 / 202 / 307. UE 115 may use the satellite coverage data, its current location, and the current time to determine when UE 115 will be in coverage of a satellite cell and out of coverage of a satellite cell.

[0207] As discussed above, in the case of limited satellite deployment (e.g., initially), there may be times when no satellite coverage (e.g., no satellite cells) is available for UE use at any given geographic location—this may be referred to as a "coverage gap." For some UEs (e.g., cellular IOT (CIoT)), the UE may transition to a dormant state during a coverage gap and may not attempt to find a cell or initiate a mobile originating (MO) service such as initiating a voice call or data session or transmitting data or text messages. When the UE is within a coverage gap, the network may similarly not attempt to initiate any mobile terminated (MT) services for the UE, such as not attempting to initiate a voice call or data session from an external entity to the UE, and not attempting to transmit data or text messages from an external entity (e.g., an external client 140) to the UE. For non-IOT UEs, the user of the UE may want to minimize out-of-coverage periods by finding and using other available terrestrial network (TN) cells or NTN cells for other NTN RATs or other PLMNs. In this case, transitioning to a fully dormant state may not be appropriate. Furthermore, in the case where the UE is moving, the coverage gap at the old location may become irrelevant at the new location where the satellite (or satellite cell) is available again. For MT services and for a moving UE, the network may be able to reach the UE at the new location (where the satellite is available), so again, transitioning to a full dormant state (with respect to the UE) on the network side may also not be appropriate.

[0208] In certain embodiments, an operations and maintenance (O and M) manager or server (e.g., belonging to a PLMN) may be preconfigured and transferred to other entities (e.g., gNB 106 / 202 / 307 and / or AMF 122) satellite coverage data showing times of NTN coverage and lack of coverage (e.g., times without NTN coverage) at different locations in the PLMN coverage area. The satellite coverage data may be, for example, for 7A to 7F as described.

[0209] In one embodiment, the gNB 106 / 202 / 307 that receives satellite coverage data from the O and M servers or calculates satellite coverage data from other data received from the O and M servers (e.g., satellite orbit or ephemeris data and data about satellite cells) may broadcast the satellite coverage data in each cell for a location in the cell, such as for a location in the cell. 7A to 7F As discussed. The UE 115 access stratum (AS) may then determine a period of satellite unavailability at the UE 115 location based on the received broadcast satellite coverage data. During satellite unavailability (e.g., during a no-coverage state), the AS layer may report a no-cell-available state to the NAS layer in the UE 115. The NAS layer may then change the NAS state of the UE 115 to indicate that wireless coverage is unavailable (e.g., may enter a NAS 5GMM-REGISTERED.NO-CELL-AVAILABLE state), which may also be supported for terrestrial wireless access when the UE 115 loses wireless coverage. The AS layer may reduce or stop cell searches (e.g., reduce satellite cell search frequency or stop cell searches) during no-coverage periods / states. The AS layer may optionally be configured to periodically search for NTN or TN cells before the next satellite cell available time to allow for possible UE 115 movement to a new location.

[0210] In some other embodiments, the UE 115 NAS layer may obtain and / or otherwise determine the time / timer T1 at which satellite coverage at the UE 115 location will cease (e.g., during a no coverage state) and the time / timer T2 at which satellite coverage will resume (e.g., during a covered state). For example, the network (e.g., serving AMF 122) may provide satellite coverage data to the UE 115 during UE registration and / or in other NAS responses if requested by the UE 115, and the UE 115 may then calculate T1 and T2. In another example, the network (e.g., serving AMF 122) may determine the values ​​of T1 and T2 and then provide these values ​​to the UE 115 during UE 115 registration and / or in other NAS responses. In yet another example, the serving gNB 106 / 202 / 307 may broadcast satellite coverage data or the values ​​of T1 and T2 in a SIB in a satellite cell. The broadcasted satellite coverage data or the values ​​of T1 and T2 may then be received by the UE 115 AS layer and provided by the UE 115 AS layer to the UE 115 NAS layer, for example, when a satellite cell is acquired or shortly thereafter (e.g., during a coverage state). The UE 115 NAS layer may provide the values ​​of T1 and T2 to applications and / or to a user of the UE 115 to indicate future loss and later restoration of satellite coverage. At time T1 (e.g., when a timer for T1 expires and when a no-coverage state begins), the NAS layer may enter a no-coverage state (e.g., 5GMM-REGISTERED.NO-COVERAGE state), may deactivate the AS layer, and may start a timer that will expire at time T2. At time T2 (e.g., when a timer for T2 expires, which may occur when a coverage state is restored), the NAS layer may reactivate the AS layer. In some embodiments, the network-side NAS layer (e.g., the NAS layer in the serving AMF 122) may also enter a no-coverage state with respect to the UE 115 at time T1, and may prohibit mobile station called (MT) activities of the UE 115 until time T2.

[0211] Combination of the above 7A to 7F The different types of satellite coverage data described and their use may enable UE 115 to determine at what times (e.g., times T1 and T2) UE 115 will and will not be in coverage of a satellite cell that enables access to a serving PLMN. However, the satellite coverage data may not indicate whether and at what times and locations UE 115 may be in coverage of a satellite cell that does not support the serving PLMN but supports a PLMN different from the serving PLMN (e.g., the home PLMN of UE 115). Additionally, the satellite coverage data may not indicate whether and at what locations (and possibly at what times) UE 115 may be in coverage of a TN cell (e.g., a TN cell supporting 5G NR access to a terrestrial gNB or a TN cell supporting LTE access to a terrestrial ng-eNB or terrestrial gNB) of the serving PLMN (or another PLMN, such as the home PLMN of UE 115). Therefore, when UE 115 determines that satellite coverage is not available for the serving PLMN (e.g., when UE 115 enters a no-coverage state for the serving PLMN), UE 115 may not know whether to continue searching for satellite cells of another PLMN (e.g., home PLMN) and / or whether to search for TN cells. This lack of knowledge by UE 115 may result in unnecessary power consumption if UE 115 continues searching for satellite cells of another PLMN and / or TN cell and no satellite cells are found. This lack of knowledge by UE 115 may also result in UE 115 instead entering a dormant state during the no-coverage state of the serving PLMN (wherein UE 115 deactivates all satellite and TN cell searches), and UE 115 unnecessarily lacking PLMN access if satellite cells of another PLMN or TN cell become available to UE 115 during the no-coverage state or later.

[0212] For UEs 115 that are subscribed or configured to access or are only able to access the satellite cell of the serving PLMN (e.g., where the serving PLMN is the home PLMN of the UE 115 and the UE 115 does not support TN access), this may not be a problem, and the UE 115 may then enter a fully dormant state during the period of no satellite coverage for the serving PLMN. However, for UEs 115 that support roaming to other PLMNs using satellite access and / or support TN access, it may be advantageous if the UE 115 can know whether satellite access and / or terrestrial wireless access for other PLMNs is available when it is in a no coverage state for the serving PLMN.

[0213] Extensions to the above-described techniques for providing satellite coverage data to UE 115 may be used to provide this additional information regarding satellite coverage availability and TN coverage availability for other PLMNs to UE 115. In one such extension, additional coverage data (e.g., such as for TN coverage availability) may be provided to UE 115 by a serving PLMN (e.g., by AMF 112, MME, or gNB 106 / 202 / 307) or by another entity (e.g., a server accessed by UE 115 via the Internet, such as by a home PLMN, SVO, or a server supported by a vendor or OEM of UE 115) for one or more other PLMNs and in the same or similar manner as satellite coverage data is provided for the serving PLMN. 7A to 7F described by the overlay, bitmap or time series). 7A to 7F Additional coverage data is supported as described, but instead of indicating satellite availability and unavailability at different locations and / or at different times for a serving PLMN, the additional coverage data may instead indicate satellite availability and unavailability at different locations and / or at different times for one or more other PLMNs. In another extension, additional coverage data may be provided for terrestrial wireless access and may indicate TN cell availability and TN cell unavailability at different locations and / or at different times for a serving PLMN and / or one or more other PLMNs. Since terrestrial cells are generally not mobile (although they may sometimes be connected and disconnected), the coverage map of the TN cell may include a bit string or bit array, wherein each bit in the bit string or bit array corresponds to a specific position in a position array (e.g., a rectangular grid point array of positions) and indicates whether the TN cell is available at that position and at any time rather than just at a specific time. Similar to the coverage map of satellite access, such a coverage map of the TN cell may also be compressed when nearby locations tend to have the same coverage or no coverage attributes and therefore have the same bit values.

[0214] In one extension that provides additional coverage data for terrestrial access, a binary value (e.g., 1 or 0) may be provided in the coverage map for each location to indicate coverage (e.g., binary value of "1") versus no coverage (e.g., binary value of "0"). In another type of extension for providing additional coverage data for terrestrial access, a ternary or quaternary value may be provided in the coverage map instead of a binary value. For example, in the case of a ternary value, a value of "0" may indicate that TN coverage is not available, a value of "1" may indicate that TN coverage is available, and a value of "2" may indicate that TN coverage is available but not guaranteed. A third value of "2" may be used to indicate a location where TN coverage is sometimes available (e.g., depending on the exact location of UE 115) but not always available, which may be used in locations where TN coverage of the serving PLMN may be blocked by buildings, natural obstacles (e.g., mountains, trees) but is generally available if UE 115 has line of sight to a terrestrial base station or access point. For the four-element value, "0", "1" and "2" may have the meanings just described, and may include a fourth value "3" to indicate locations where TN coverage may sometimes be available as for value "2" but with a lower (or higher) probability than value "2".

[0215] In another type of extension, the additional coverage data may be provided as a single coverage map combining coverage indications for the serving PLMN and other PLMNs and / or combining coverage indications for both satellite access and terrestrial access. The single coverage map may provide a string or array of binary, ternary, quaternary (or value-added) parameters, wherein each parameter in the string or array indicates whether there is satellite and / or TN cell coverage for the serving PLMN and possibly additional PLMNs at a specific location and / or a specific time. For example, in the simplest example, a coverage map such as for 7A to 7F The bitmap described herein may be used to provide a string or array of binary values. A bit set to "0" may then indicate that no coverage from a satellite cell or a TN cell is available for a particular location and time, while a bit set to "1" may indicate that coverage from at least one of a satellite cell or a TN cell is available for that time and location. In another example using quaternary values, a quaternary value provided for a particular location and time may indicate no satellite and no TN coverage for a value of "0", satellite but no TN coverage for a value of "1", TN but no satellite coverage for a value of "2", and both satellite and TN coverage for a value of "3". A string or array of quaternary values ​​may also be encoded as a bit string or array by using 2 bits to encode each quaternary value. Such a bit string or array may then also be compressed when values ​​for nearby locations and / or times tend to be the same.

[0216] The above-described extension for providing UE 115 with additional (satellite and / or terrestrial) coverage data for TN cells and / or other PLMNs may allow UE 115 to modify support for coverage gaps and satellite coverage such that UE 115 may access a satellite cell of another PLMN or TN cell during a (satellite) coverage gap for the serving PLMN and not expend power searching for other satellite cells or TN cells when no other satellite cells or TN cells are available.

[0217] In another specific implementation, the satellite coverage data may be provided to the UE 115 from a server. For example, the coverage information may be considered a network resource and accessed by the UE 115 using an address (such as a URI) of a server obtained by the UE 115 from a network entity (e.g., AMF 122, MME, or gNB 106 / 202 / 307). The UE 115 may then access the server based on the address to obtain the coverage information. For example, the UE 115 may transmit an HTTP or HTTPS (or other data) request to a server identified by the address. The request transmitted by the UE 115 to the server may indicate one or more input parameters that may be used to identify the requested information (e.g., as described above for the three SCAI examples). For example, the UE 115 may indicate the location of the requested coverage information or the area of ​​the requested coverage information, such as the radius of a circle centered at the location or the length and width of a rectangle associated with the location. The UE 115 may indicate the relevant time of the requested coverage information, such as a start time and a stop time. The UE 115 may indicate the relevant RAT and / or PLMN for the requested coverage information. UE 115 may indicate supported methods or encodings for receiving coverage information from the server. The server may identify the address association with the coverage data and return the requested coverage information to UE 115.

[0218] The server may belong to the serving PLMN or home PLMN (HPLMN) (e.g., when the UE is roaming) or to a separate third party, such as a spacecraft operator (SVO). The benefits of using an SVO server rather than a PLMN server to provide coverage data may be that: (a) coverage map data does not need to be delivered to one PLMN (or multiple PLMNs), and (b) the SVO server will receive each request directly and can therefore charge for data more reliably. For example, in a scenario where one SVO supports 100 PLMNs, instead of transmitting some or all of its coverage map data to each of the 100 separate PLMNs, the SVO may assign a URI ID to each PLMN and maintain a single server to provide coverage data on behalf of all 100 PLMNs. Thus, the total implementation cost of one server for the SVO may be reduced by up to 100 times compared to 100 separate servers for each of the 100 PLMNs.

[0219] The address (e.g., URI) of the server may be provided to the UE 115 by a network entity, such as in the HPLMN or VPLMN. The address may have limited use, such as the address may be used only once by the UE to request coverage data, or may be used multiple times within a limited period, and / or may be used for a maximum number of requests, or may be used indefinitely. The address may be provided to the UE 115 by the network entity using NAS (e.g., via a registration request and accept message), where the UE 115 may indicate in the NAS request one or more of the input parameters that may be used to identify the requested SCAI, as discussed above, to allow the network entity to select a server and address that may support these input parameters. The address may alternatively be provided to the UE 115 using an RRC unicast request / response or in a SIB (e.g., which may be encrypted to allow charging for configuration data), or the address may be provided by the HPLMN operator via pre-configuration on a Universal Subscriber Identity Module (USIM) of the UE 115.

[0220] It may be desirable to deliver coverage information in a secure manner that can protect UE privacy and that can allow for billing of coverage data. Coverage information may be delivered in a secure manner because a network entity in the serving or home PLMN provides an address and HTTPS may be used by the UE 115 to request and obtain coverage data. For billing of coverage data, an address (e.g., a URI) may need to identify the UE 115, but for possible privacy reasons, it may not be desirable to provide the real UE identity (e.g., a subscription permanent identifier (SUPI)) to the server. To achieve this, a temporary identifier may be assigned to the UE 115. For example, an address (e.g., a URI) may be assigned to a UE or a group of UEs having a random component (e.g., 128 or 256 random bits) in the least significant portion. In a variation, the random component may not be part of the address, but may be provided as a separate input parameter. The address (or random component) may be preconfigured in the server and the network entity (e.g., AMF or gNB) that provides the address. The server may record the use of the address or random component (e.g., the server records the address when receiving a request for coverage data from the UE). The network entity that provides the address also records the identity of the UE to which the address (or random component) was provided. The record may be evaluated offline, for example, by a network entity, a server, or a third-party charging entity to determine the provision of the address (or random component) to the UE and the use of the UE. The random component may be used as a temporary identifier for the UE.

[0221] To avoid the need to preconfigure millions of addresses or random components at the server and network entity, the server and network entity may agree on a simple set of identifiers (e.g., a regularly spaced sequence of numbers such as (decimal) 1,000,000,000, 1,000,001,000, 1,000,002,000, 1,000,003,000, 1,000,004,000, 1,000,005,000, etc.), and encryption may be used to generate and verify temporary identifiers. The network entity may, for example, select a hitherto unused identifier from the set of identifiers for the UE (e.g., 1,000,004,000 in the above example), and may encrypt the identifier using a secret encryption key to generate a random component, which is then transmitted by the UE to the server. The server uses the same encryption key to decrypt the random component to obtain an initial identifier (e.g., 1,000,004,000 in this example), which can then be verified as legitimate if the initial identifier belongs to a set of identifiers. For example, an unauthorized UE that attempts to request SCAI from a server by providing a random component that was not legally obtained and decrypted by the server to produce a value that does not belong to the set of identifiers (e.g., the value 1,000,003,107 in the previous example) can be identified by the server as unauthorized to receive SCAI. The server and network entities can record the assignment and use of identifiers for billing purposes. Using encrypted temporary identifiers for UEs can achieve security, privacy, and the ability to charge for access to coverage data. For example, when the number of bits is about 128 or more, an attacker cannot guess a valid random component with any probability of success. In the event that the UE is lost or the user discloses the address and temporary identifier, other parties may benefit, but this is no different from the user giving away any other valuable item and does not need to affect billing.

[0222] The security of a server address (e.g., URI) can be enabled by a very large number of possible random components. In the case where the random component contains 128 bits, this number can be about 10 38 . Assume that 1 trillion (10 12 ) are reserved for coverage data provision, the probability that an attacker correctly guesses one of these reserved components (and thereby enables free access to the coverage data) will be 1 / 10 26 , which is a very low probability. Using encryption to determine the random component avoids having to assign and store the random component separately through some other process (e.g., using a random number generator). Instead, a secret key is used to generate the random component as needed, and an ID selected from a preconfigured sequence of integers (e.g., all integers between 1 and 1 trillion or all integers between 1 and 1 trillion multiplied by 1 trillion) is encrypted. In the event that the key is discovered in some way, the operator can change it. In the event that the coverage data itself is not considered sensitive (e.g., the coverage data will not include user or UE information), there may be no significant loss except for the operator losing a small amount of revenue before changing the key.

[0223] The data may be obtained by the UE 115 using queries to a server, such as 7A to 7F 1. The coverage data illustrated in the coverage diagram shown. The process by which UE 115 obtains the data may have two parts. First, UE 115 obtains authorization data. Then, UE 115 transmits a request including the authorization data to the server (e.g., via HTTPS or SMS). The authorization data may be part of the address (URI) or may be a separate input parameter (e.g., in the body of an SMS message). In the case where billing will not be used (e.g., coverage data is available to all UEs without billing), the first part of the process may be omitted and the UE may construct a standard address (URI) associated with any serving PLMN (e.g., VPLMN or HPLMN).

[0224] Fig. 8A and Figure 8B 1 and 2 illustrate a process for UE 115 to obtain coverage data from server 187 based on authorization data obtained by UE 115 according to various aspects of the present disclosure, wherein the first part consists of Fig. 8A The process 800 in FIG. 8 is exemplified and the second part consists of Figure 8B This corresponds to solution A described above. Fig. 8A A first process 800 is shown for a 5G system (5GS). The process for EPS may similarly use a NAS Attach or a NAS Tracking Area Update (TAU) instead of a NAS Registration. Fig. 8A The process shown is based on NAS, but some other protocol layers, such as RRC, may also be used. Various aspects of process 800 may be implemented by or at communication systems 100, 200, 300, 400, 500, 600 and / or 700. Various aspects of process 800 may be implemented by or at UE 115 and / or network entity 185, which may be examples of corresponding devices described herein. For example, network entity 185 may include one or more entities within a core network, such as AMF 122, LMF 124, SMF 134, or MME, or may be a base station such as gNB 106 / 202 / 307, which may be separate from SV 102 / 202 / 302 or may be included as part of SV 202 as described above. FIG. 8A to FIG. 8C The operations within the processes in FIG. 1 are shown as numbers and are referred to herein as stages (which may or may not be individually labeled in the figures). This convention is also used in the other figures described below.

[0225] The coverage data communicated from the server 187 to the UE 115 may be coverage data that enables the UE 115 to determine whether a serving PLMN is accessible at one or more locations of the UE, at one or more future times, using one or more radio access technologies (RATs), or for some combination of these items. For example, the serving PLMN may have discontinuous satellite coverage, and the coverage data may include coverage data for one or more satellite RATs. The coverage data may additionally or alternatively apply to the TN RAT. In some implementations, the coverage data communicated from the server 187 to the UE 115 may be data in addition to the coverage data. For example, for 7A to 7F And for the first, second and third SCAI examples, the coverage data may be as described above.

[0226] Fig. 8A The illustrated process 800 may start with UE 115 being in satellite coverage of a serving PLMN. For example, UE 115 may be located within the coverage area of ​​at least one satellite cell supported by SV 102 / 202 / 302, as previously described. Note that references to serving PLMN herein may correspond to a dedicated wireless network (non-public wireless network) and / or a network providing Internet access and / or other satellite services in some cases. In addition, the UE may send and receive signals from the serving PLMN and / or otherwise access the serving PLMN via a communication satellite (e.g., SV 102 / 202 / 302 and NTN gateway 104). Therefore, UE 115 may establish a connection with the serving PLMN (e.g., with network entity 185), or may already have a connection with the serving PLMN to perform wireless communications via SV 102 / 202 / 302. For example, UE 115 may perform an initial registration process with a serving PLMN (e.g., with network entity 185) via SV 102 / 202 / 302, NTN gateway 104, and gNB 106 / 202 / 307.

[0227] At 805, the UE 115 may transmit a request for coverage data to the network entity 185. In one implementation, the UE 115 transmits a registration request (e.g., for initial registration, periodic registration, or registration update) to the network entity 185 (e.g., the serving AMF 122) and includes a request for coverage data from the server 187 ( Figure 8B 187) and whether HTTPS or SMS is preferred. In some implementations, the UE 115 may transmit the request using an RRC unicast request. The request may indicate, for example, one or more input parameters that may assist the network entity 185 in selecting the address of the server 187 to provide the coverage data (e.g., as described above for the first, second, and third SCAI examples). Input parameters may be included to indicate the type of coverage data required (e.g., one or more RATs) and the applicable location, time, and satellite RAT. For example, the request may indicate one or more coverage parameters, such as the location of the requested coverage information, the area of ​​the requested coverage information (such as the radius of a circle centered at the location, or the length and width of a rectangle associated with the location), the relevant time of the requested coverage information (such as the start time and the stop time), the relevant RAT and / or PLMN of the requested coverage information, and the supported methods or encodings for receiving the coverage information from the server.

[0228] At 810, the network entity 185 (e.g., the serving AMF 122) may authenticate the UE 115 and may verify that the UE is subscribed to receive coverage data (of the requested type and / or requested location) and whether the requested location is supported (e.g., in a country supported by the AMF 122).

[0229] At 820, the network entity 185 (e.g., the serving AMF 122) determines (i) a server of the type applicable to the coverage data and location, and (ii) authorization data. The authorization data may be a text string address (URI) of the server or the content of an SMS message to be transmitted to the server. The authorization data may include a temporary identifier (ID) of the UE 115 and, optionally, details of the request received at step 1 (e.g., may indicate applicable location, time, and satellite RAT). In the case where the authorization data includes a temporary ID, the temporary ID may be assumed to have been pre-configured in the server 187 and pre-agreed between the serving PLMN (e.g., the network entity 185) and the server 187 when the server 187 is managed by another party (e.g., SVO). Thus, the temporary ID may be, for example, a reserved value pre-defined in the network entity 185 and the server 187. The temporary ID may be a large random number or pseudo-random number (e.g., 128 bits) having a set of (pseudo) random numbers pre-configured in the server 187 and in the serving PLMN (e.g., the network entity 185). Such randomization may make it nearly impossible for an unsubscribed UE to guess a valid temporary ID. In some implementations, the temporary ID may be encrypted (e.g., as described above). A pseudo-random temporary ID may be generated by encrypting a regular ID series (e.g., integers 1, 2, 3, 4, 5, etc.) using a secret encryption key known only to the serving PLMN and the server. For example, the network entity 185 and the server 187 may be preconfigured with a common set of identifiers and encryption keys. The network entity 185 may select one of these identifiers (e.g., a previously unused identifier) ​​from the set of identifiers for the UE 115, and may encrypt the identifier using the encryption key to generate a temporary identifier for the UE 115. The server 187 may later use the encryption key to decrypt the temporary identifier of the UE 115 to obtain an identifier selected by the network entity 185 (in process 850). The temporary identifier may be part of the address of the server 187. For example, the temporary ID may be appended to the address (URI) as an extension of the URI.

[0230] At 825, the network entity 185 (e.g., the serving AMF 122) may return the authorization data in the Registration Accept and, in the case of SMS, the SMS address of the server. In some implementations, the network entity 185 may provide the authorization data to the UE 115 using an RRC unicast response or in a SIB (e.g., which may be encrypted). The network entity 185 (e.g., the serving AMF 122) may also indicate usage restrictions on the authorization data, such as a maximum number of requests to the server or a maximum duration of use.

[0231] In some implementations, instead of receiving authorization data from the network entity 185, the UE 115 may obtain the authorization data without assistance from the network entity 185, thereby eliminating the need for stages 805, 810, 820, and 825 that may be used when a standard URI is used and charging is not applicable. For example, the UE 115 may obtain the authorization data from a USIM on the UE 115, which may be configured by the home PLMN of the UE 115 or by assembling a standardized address or a standardized temporary identifier. For example, the UE 115 may assemble the standardized address as "nameofdata.mnc <mnc>.mcc <mcc>.3gppnetwork.org", where <mnc>and <mcc>is replaced by the Mobile Country Code (MCC) and Mobile Network Code (MNC) numbers used for the serving PLMN, and "nameofdata" represents some fixed alphanumeric name standardized for the coverage type such as "satellitecoveragedata". Standardized temporary identifiers can be compiled in a similar manner.

[0232] Figure 8B A second process 850 is shown, which may be the same for both 5GS and EPS. Figure 8B The process 850 shown in FIG. 8 can be performed as follows: Fig. 8A 850. Aspects of process 850 may be implemented by or at communication systems 100, 200, 300, 400, 500, 600, and / or 700. Aspects of process 850 may be implemented by or at UE 115 and / or server 187, which may be examples of corresponding devices described herein. For example, server 187 may, for example, belong to a serving PLMN (e.g., a VPLMN or a HPLMN) of UE 115, to a satellite operator (e.g., an SVO) that provides access to the serving PLMN, or to a separate third party.

[0233] At 855, the UE 115 uses the authorization data received in the first process 800 to access the server 187. For example, as illustrated at 855, the UE 115 transmits an HTTP or HTTPS request (e.g., HTTPS GET) to the server 187 with a URI equal to the authorization data obtained in the first process 800, or transmits an SMS message with the authorization data in the SMS message body using the SMS destination address received in the first process. The request (HTTPS request) or SMS message may not need to include any additional data because the authorization data may already include all data required by the server 187 (e.g., all input parameters). This may avoid any need for the UE 115 to have to support a proprietary server protocol related to the request or to standardize such a protocol. However, in another embodiment, the UE 115 may include input parameters in the HTTP or HTTPS request or in the SMS message transmitted at 855, such as those described above for the first, second, and third SCAI examples, and define the type of coverage data requested (e.g., such as applicable satellite RAT, location, and time). In this embodiment, the authorization data provided by network entity 185 in process 800 may not need to include any input parameters.

[0234] At 860, server 187 verifies that the authorization data is valid (e.g., contains a valid temporary ID and satisfies any restrictions on the number of requests or request period) and logs the details of the request. Fig. 8A As discussed in 820 of the illustrated process 800, the authorization data may include a temporary ID of the UE 115 known to both the network entity 185 and the server 187. The temporary ID may be, for example, a reserved value predefined in the network entity 185 and the server 187. In some implementations, the temporary ID may be encrypted. For example, the network entity 185 and the server 187 may be preconfigured with a common temporary ID and encryption key. The server 187 may decrypt the temporary ID received from the UE 115 using the encryption key to obtain an initial temporary ID selected by the network entity 185, and may verify that the initial temporary ID belongs to the preconfigured common temporary ID. The temporary ID of the UE 115 may allow the UE 115 to access the server 187 and obtain coverage data therefrom under limited circumstances. For example, the UE 115 may access the server 187 and obtain coverage data a limited number of times, or obtain coverage data within a limited amount of time, or both. The server 187 may verify that the temporary ID does not exceed any such limit.

[0235] At 865, the server 187 returns the requested coverage data to the UE 115 according to the request at 855. The returned coverage data may use an encoding known to both the UE and the server. For example, the coverage data may be provided in an HTTP or HTTPS 200 OK message or an SMS message from the server 187. The coverage data may enable the UE 115 to determine whether the serving PLMN can be accessed at one or more locations of the UE, at one or more future times, using one or more radio access technologies (RATs), or for a certain combination of these items, as described above. For example, the serving PLMN may have discontinuous satellite coverage, and the coverage data may include coverage data for one or more satellite RATs and may optionally apply to the TN RAT. In some specific implementations, the coverage data delivered from the server 187 to the UE 115 at 865 may be or may include data other than the coverage data.

[0236] To support charging and billing of UEs, the billing center may collect records of authorization data (e.g., the temporary ID assigned from the network entity 185 (e.g., AMF 122) and the corresponding UE identity and the temporary ID used to request coverage data from the server 187). This may allow the precise coverage data provided to each UE to be determined and billed.

[0237] Figure 8C The NAS process for obtaining coverage data for 5GS is shown. The EPS process can similarly use attachment or TAU. This process corresponds to the aforementioned solution B.

[0238] At 875, the UE 115 may transmit a NAS registration request (e.g., for an initial registration, a periodic registration, or a registration update) to a network entity 185 such as the serving AMF 122 and may include a request to provide coverage data. Additional input parameters may be included to indicate applicable location, time, and satellite RAT, such as those previously described for the first, second, and third SCAI examples.

[0239] At 880 , the network entity 185 may verify the UE subscription to receive the coverage data and whether the requested input parameters (eg, location and time) may be supported (eg, in a country supported by the network entity 185 ).

[0240] At 885, the network entity 185 returns the requested coverage data in a NAS Registration Accept. The network entity 185 may obtain the coverage data from pre-configured data in the network entity 185, which may not require any interpretation or significant processing by the network entity 185 in the case where the coverage data is configured in the network entity 185 only for a limited set of locations and a small set of selected durations. Alternatively, the network entity 185 may transmit the request from the UE 115 to the server (e.g., using Figure 8B Process 850 in which the network entity 185 acts as the UE 115 in process 850) and includes the returned coverage data at 885.

[0241] Figure 8C The process shown can be similar to Fig. 8A The process shown is the same as that shown, except that coverage data is returned instead of authorization data. This may allow the serving PLMN to support either process or both processes based on a common request / response from / to UE 115. For example, UE 115 may indicate in the NAS registration request which process(es) the UE 115 supports, and network entity 185 may then attempt to match the UE support. Conflicts may only occur if UE 115 and network entity 185 each support only one process that is different from each other. This may avoid conflicts in the case where one of the processes is defined as a common mandatory default.

[0242] Compared to providing satellite orbit data using SIBs (e.g., as in SIB32 in 3GPP TS 36.331), the coverage map defined herein may have several advantages. For example, with a coverage map, the UE may not need to perform any complex calculations to determine the expected coverage, and may simply look up its current position and time in the coverage data map to see if there is coverage. The coverage data may also be prepared in advance (e.g., by a satellite operator or server) using complete and accurate knowledge of satellite orbit data and radio cell planning, and may therefore be more reliable than coverage data extrapolated from orbit data parameters by the UE. Coverage data for any period of time (e.g., 24 hours or 1 week or longer) may also be provided. In addition, the coverage data may be more complete. For example, SIB32 as defined in 3GPP TS 36.331 may include ephemeris data for only 4 satellites. It may then be the case that a UE close to a radio cell border may receive coverage from satellites not included in SIB32, or that satellites included in SIB32 that should be visible to the UE do not provide coverage to the UE due to restrictions on PLMN or country support or because the radio cell is not configured for the entire visible area of ​​the satellite.

[0243] also, Fig. 8A and Figure 8B The processes 800 and 850 for obtaining coverage data using HTTPS or SMS queries to a server may have many benefits. For example, these processes allow the use of a server from a satellite operator that can avoid interfering with the PLMN in determining coverage data and providing coverage data to the UE. The process may also support charging and billing for coverage data and secure delivery of coverage data. The process may also support UEs with and without an IP protocol stack, for example, by using SMS in process 850 when the UE does not support HTTP and IP.

[0244] Figure 8C The process 870 for obtaining coverage data using NAS may have many benefits. For example, this may reduce the signaling impact on the UE as an extension of the existing NAS registration process for 5GS access and the existing NAS attach and TAU process for EPS access. The process 870 may also support charging for coverage data and secure delivery of coverage data.

[0245] Note that although FIG. 8A to FIG. 8C Techniques are described to enable a UE (e.g., UE 115) to request and obtain coverage data from a network entity or from a server, but similar or the same techniques may also be used to enable a UE to request and obtain other types of data from a network entity (e.g., network entity 185, AMF 122, SMF 134, or MME) or from a server (e.g., server 187). The UE may then request and obtain coverage data from a network entity (e.g., AMF 122, SMF 134, or MME) or from a server (e.g., server 187). Fig. 8A 805 Figure 8B 855 and Figure 8C The request sent at 875 of FIG. 8A to FIG. 8C The input parameters described above are different input parameters. For example, different input parameters may indicate aspects or characteristics of other types of data being requested. Fig. 8A 825 in the UE and is provided to the UE at Figure 8B The authorization data included by the UE at 855 in may be different from the authorization data described above, but may still include the temporary identifier of the UE. Figure 8B 865 and Figure 8C The data provided to the UE at 885 may not be the coverage data as described above, but may include other types of data.

[0246] Fig. 9 A process 900 for charging a UE 115 for accessing and obtaining coverage data is illustrated. As shown, after a server 187 receives a packet from a UE 115 that includes an identifier of the UE (e.g., as in Figure 8B After requesting coverage data for a temporary identifier (e.g., at 855 in the example), server 187 records the identifier and provides it to charging entity 910 along with possible details of the coverage data provided to UE 115 (e.g., at Figure 8B 865 in ). The charging entity 910 may belong to the serving PLMN or may belong to a third party. The identifier is determined and provided to the UE 115 (e.g., as in Fig. 8A The network entity 185 (at 820 and 825 in FIG. 1 ) provides the same identifier and permanent identifier (e.g., SUPI) of the UE 115 (e.g., their association) to the charging entity 910. The charging entity 910 may then identify the UE 115 that accessed the server 187 and obtained coverage data for it (using the association of the identifier and the permanent identifier) ​​and charge the UE 115 accordingly.

[0247] Fig.10 is an example UE 1000 (such as Figure 1 , Figure 2 , Figure 3 , Fig. 7A , Fig. 8A , Figure 8B , Figure 8C and Fig.16 UE 1000 may be configured to perform Fig. 8A , Figure 8B and Figure 8C The signal flow shown and Fig.13 The process flow 1300 of UE 1000 and any of the techniques disclosed herein. UE 1000 may include, for example, a wireless antenna ( Fig.10 1002) and SV 102 / 202 / 302 for wireless communication, such as a satellite transceiver 1003, for example, Figure 1 , Figure 2 and Figure 3 UE 1000 may also include a wireless antenna ( Fig.10 1000) and wirelessly communicates with a ground base station (e.g., a base station such as a gNB or ng-eNB) in the NG-RAN 112. The UE 1000 may also include additional transceivers such as a wireless local area network (WLAN) transceiver 1006 and a wireless antenna ( Fig.10 ) receives and measures the signal from SPS SV 190 ( Figure 1 , Figure 2 and Figure 3 1000). In some implementations, the UE 1000 may receive data from a satellite, for example, via a satellite transceiver 1003, and may respond to a ground base station, for example, via a wireless transceiver 1002 or via a WLAN transceiver 1006. Thus, the UE 1000 may include one or more transmitters, one or more receivers, or both, and these may be integrated, discrete, or a combination of both. The UE 1000 may also include one or more sensors 1010, such as a camera, an accelerometer, a gyroscope, an electronic compass, a magnetometer, a barometer, and the like. The UE 1000 may also include a user interface 1012 through which a user may interface with the UE 1000, which may include, for example, a display, a keypad, or other input device (such as a virtual keypad on a display). The UE 1000 also includes one or more processors 1004, a memory 1016, and a non-transitory computer-readable medium 1018, which may be coupled together using a bus 1014. One or more processors 1004 and other components of the UE 1000 may similarly be coupled together using the bus 1014, a separate bus, or may be directly connected together, or coupled using a combination of the foregoing.

[0248] The one or more processors 1004 may be implemented using a combination of hardware, firmware, and software. For example, the one or more processors 1004 may be configured to perform the functions discussed herein by implementing one or more instructions or program codes 1020 on a non-transitory computer-readable medium such as the medium 1018 and / or the memory 1016. In some embodiments, the one or more processors 1004 may represent one or more circuits capable of being configured to perform at least a portion of a data signal computing procedure or process related to the operation of the UE 1000.

[0249] The medium 1018 and / or the memory 1016 may store instructions or program code 1020 including executable code or software instructions that, when executed by the one or more processors 1004, cause the one or more processors 1004 to function as processors programmed to perform the techniques disclosed herein (e.g., such as Fig. 8A , Figure 8B and Figure 8C The signal flow shown and Fig.13 The process flow 1300 and the algorithm disclosed herein) are operated by a dedicated computer. As illustrated by UE 1000, the medium 1018 and / or the memory 1016 may include one or more components or modules, which may be implemented by one or more processors 1004 to perform the method system described herein. Although each component or module is illustrated as software in the medium 1018 that can be executed by one or more processors 1004, it should be understood that each component or module may be stored in the memory 1016 or may be dedicated hardware in one or more processors 1004 or outside the processor.

[0250] Several software modules and data tables may reside in the medium 1018 and / or memory 1016 and be utilized by the one or more processors 1004 to manage both the communications and functionality described herein. It should be understood that the organization of the contents of the medium 1018 and / or memory 1016 as shown by the UE 1000 is exemplary only, and thus the functionality of the various modules and / or data structures may be combined, separated and / or configured in different ways depending on the specific implementation of the UE 1000. Although the various components or modules are illustrated as software in the medium 1018 and / or memory 1016 that can be executed by the one or more processors 1004, it should be understood that the various components or modules may be firmware or dedicated hardware in the one or more processors 1004 or external to the processor.

[0251] As shown, program code 1020 stored on medium 1018 and / or memory 1016 may include a PLMN access module 1022, which, when implemented by one or more processors 1004, configures one or more processors 1004 to receive and send wireless signals via wireless transceiver 1002 or satellite transceiver 1003 to access a PLMN, such as Figures 1 to 3 5GCN 110 is shown. The one or more processors 1004 may be configured, for example, to access the PLMN and request, receive and use coverage data.

[0252] As shown, program code 1020 stored on medium 1018 and / or memory 1016 may include a data access module 1024 that, when implemented by one or more processors 1004, configures one or more processors 1004 to request and receive coverage data from a network entity or server, as described herein and particularly with respect to Fig. 8A , Figure 8B and Figure 8C described.

[0253] The methodologies described herein may be implemented by various means depending on the application. For example, these methodologies may be implemented in hardware, firmware, software, or any combination thereof. For hardware implementation, one or more processors 1004 may be implemented in one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), processors, controllers, microcontrollers, microprocessors, electronic devices, other electronic units designed to perform the functions described herein, or combinations thereof.

[0254] For specific implementations of UE 1000 involving firmware and / or software, these methodologies may be implemented with modules (e.g., procedures, functions, etc.) that perform the individual functions described herein. Any machine-readable medium that tangibly embodies instructions may be used to implement the methodologies described herein. For example, software codes may be stored in medium 1018 or memory 1016 and executed by one or more processors 1004, thereby causing one or more processors 1004 to operate as a special-purpose computer programmed to perform the techniques disclosed herein. The memory may be implemented within one or more processors 1004 or external to one or more processors 1004. As used herein, the term "memory" refers to any type of long-term, short-term, volatile, non-volatile, or other memory, and is not limited to any particular type of memory or any particular amount of memory, or the type of medium on which the memory is stored.

[0255] In the case of implementation in firmware and / or software, the functions performed by UE 1000 may be stored as one or more instructions or codes on a non-transitory computer-readable storage medium (such as medium 1018 or memory 1016). Examples of storage media include computer-readable media encoded with data structures and computer-readable media encoded with computer programs. Computer-readable media include physical computer storage media. Storage media can be any available media that can be accessed by a computer. By way of example and not limitation, such computer-readable media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage devices, magnetic disk storage devices, semiconductor storage devices or other storage devices, or any other medium that can be used to store desired program codes in the form of instructions or data structures and can be accessed by a computer; as used herein, disks and optical disks include compact disks (CDs), laser disks, optical disks, digital versatile disks (DVDs), floppy disks, and Blu-ray disks, where disks typically reproduce data magnetically, while optical disks reproduce data optically using lasers. Combinations of the above should also be included within the scope of computer-readable media.

[0256] In addition to being stored on a computer-readable storage medium, instructions and / or data for UE 1000 may also be provided as a signal on a transmission medium included in a communication device. For example, a communication device including part or all of UE 1000 may include a transceiver having a signal indicating instructions and data. These instructions and data are stored on a non-transitory computer-readable medium 1018 or a memory 1016, and are configured to cause one or more processors 1004 to operate as a special-purpose computer programmed to perform the techniques disclosed herein. That is, the communication device includes a transmission medium having a signal indicating information for performing the disclosed functions. At a first time, the transmission medium included in the communication device may include a first portion of information for performing the disclosed functions, and at a second time, the transmission medium included in the communication device may include a second portion of information for performing the disclosed functions.

[0257] Fig.11 is an example that can correspond to Fig. 8A , Figure 8C and Fig. 9 1 is a diagram of an example of a hardware implementation of a network entity 1100 of the network entity 185 shown. The network entity 1100 may be, for example, one or more entities within the core network, such as AMF 122, SMF 134, LMF 124, or MME, or may be a base station such as gNB 106 / 202 / 307, which may be separate from SV 102 / 202 / 302 or may be included as part of SV 202 as described above. The network entity 1100 may perform Fig. 8A , Figure 8C and Fig.16 The signal flow shown and Fig.14 The process flow 1400 and the algorithms disclosed herein. The network entity 1100 may include, for example, hardware components, such as an external interface 1102, which may include one or more wired and / or wireless interfaces that can be connected to and communicate with the UE 115 directly or through one or more intermediate networks and / or one or more network entities, and connected to and communicate with one or more entities in the core network in the PLMN (such as the AMF 122 in the 5GCN 110, the NTN gateway 104 and other gNBs), and connected to other elements in the wireless network, such as Figure 1 , Figure 2 and Figure 3 As shown. The external interface 1102 may include one or more antennas to support the wireless interface and / or wireless backhaul to elements in the wireless network. The network entity 1100 also includes one or more processors 1104, a memory 1116, and a non-transitory computer-readable medium 1118, which may be coupled together using a bus 1107. The network entity 1100 may include a gNB-DU 1112 and / or a gNB-CU 1114 (e.g., in the network entity 1100 corresponding to Figure 2 When the network entity 1100 itself corresponds to a gNB-DU (e.g., gNB-DU 302) or a gNB-CU (e.g., gNB-CU 307) or corresponds to a core network entity (such as AMF 122, LMF 124, or MME), gNB-DU 1112 and gNB-CU 1114 may not exist.

[0258] The one or more processors 1104 may be implemented using a combination of hardware, firmware, and software. For example, the one or more processors 1104 may be configured to perform the functions discussed herein by implementing one or more instructions or program codes 1120 on a non-transitory computer-readable medium such as the medium 1118 and / or the memory 1116. In some embodiments, the one or more processors 1104 may represent one or more circuits that can be configured to perform at least a portion of a data signal computing procedure or process related to the operation of the network entity 1100.

[0259] The medium 1118 and / or the memory 1116 may store instructions or program code 1120 including executable code or software instructions that, when executed by the one or more processors 1104, cause the one or more processors 1104 to function as processors programmed to perform the techniques disclosed herein (e.g., such as Fig. 8A , Figure 8B and Fig.12 The signal flow shown and Fig.14 The process flow 1400 and the algorithms disclosed herein are operated by a dedicated computer (process flow 1400 and the algorithms disclosed herein). As shown in the network entity 1100, the medium 1118 and / or the memory 1116 may include one or more components or modules that can be implemented by one or more processors 1104 to perform the method system described herein. Although each component or module is illustrated as software in the medium 1118 that can be executed by one or more processors 1104, it should be understood that each component or module can be stored in the memory 1116 or can be dedicated hardware in one or more processors 1104 or outside the processor.

[0260] Several software modules and data tables may reside in the media 1118 and / or memory 1116 and be utilized by the one or more processors 1104 to manage both the communications and functionality described herein. It should be understood that the organization of the contents of the media 1118 and / or memory 1116 as shown for the network entity 1100 is exemplary only, and thus the functionality of the various modules and / or data structures may be combined, separated, and / or configured in different ways depending on the specific implementation of the network entity 1100. Although the various components or modules are illustrated as software in the media 1118 and / or memory 1116 that can be executed by the one or more processors 1104, it should be understood that the various components or modules may be firmware or dedicated hardware in the one or more processors 1104 or external to the processors.

[0261] As shown, program code 1120 stored on medium 1118 and / or memory 1116 may include a data access module 1122 that, when implemented by one or more processors 1104, configures one or more processors 1104 to support providing coverage data from a server or from a network entity 1100 to a UE, as described herein and particularly with respect to Fig. 8A , Figure 8B , Figure 8C and Fig. 9 described.

[0262] The methodologies described herein may be implemented by various means depending on the application. For example, these methodologies may be implemented in hardware, firmware, software, or any combination thereof. For hardware implementation, one or more processors 1104 may be implemented in one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), processors, controllers, microcontrollers, microprocessors, electronic devices, other electronic units designed to perform the functions described herein, or combinations thereof.

[0263] For specific implementations of the network entity 1100 involving firmware and / or software, these methodologies may be implemented with modules (e.g., procedures, functions, etc.) that perform the individual functions described herein. Any machine-readable medium that tangibly embodies instructions may be used to implement the methodologies described herein. For example, software codes may be stored in the medium 1118 or the memory 1116 and executed by one or more processors 1104, thereby causing one or more processors 1104 to operate as a special-purpose computer programmed to perform the techniques disclosed herein. The memory may be implemented within one or more processors 1104 or external to one or more processors 1104. As used herein, the term "memory" refers to any type of long-term, short-term, volatile, non-volatile, or other memory, and is not limited to any particular type of memory or any particular amount of memory, or the type of medium on which the memory is stored.

[0264] In the case of implementation in firmware and / or software, the functions performed by the network entity 1100 may be stored as one or more instructions or codes on a non-transitory computer-readable storage medium (such as medium 1118 or memory 1116). Examples of storage media include computer-readable media encoded with data structures and computer-readable media encoded with computer programs. Computer-readable media include physical computer storage media. Storage media can be any available media that can be accessed by a computer. By way of example and not limitation, such computer-readable media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage devices, magnetic disk storage devices, semiconductor storage devices or other storage devices, or any other medium that can be used to store desired program code in the form of instructions or data structures and can be accessed by a computer; as used herein, disks and optical disks include compact disks (CDs), laser disks, optical disks, digital versatile disks (DVDs), floppy disks, and Blu-ray disks, where disks typically reproduce data magnetically, while optical disks reproduce data optically using lasers. Combinations of the above should also be included within the scope of computer-readable media.

[0265] In addition to being stored on a computer-readable storage medium, instructions and / or data for the network entity 1100 may also be provided as a signal on a transmission medium included in a communication device. For example, a communication device including part or all of the network entity 1100 may include a transceiver having a signal indicating instructions and data. These instructions and data are stored on a non-transitory computer-readable medium (e.g., medium 1118 or memory 1116) and are configured to cause one or more processors 1104 to operate as a special-purpose computer programmed to perform the techniques disclosed herein. That is, the communication device includes a transmission medium having a signal indicating information for performing the disclosed functions. At a first time, the transmission medium included in the communication device may include a first portion of information for performing the disclosed functions, and at a second time, the transmission medium included in the communication device may include a second portion of information for performing the disclosed functions.

[0266] Fig.12 1 is a diagram illustrating an example of a hardware implementation of a server 1200 belonging to a serving PLMN, a home PLMN of a UE, a satellite operator providing access to the serving PLMN or to a separate third party. The server 1200 may be, for example, Figure 8B and Fig. 9 Server 187 shown. Server 1200 may execute Figure 8B and Fig. 9 The signal flow and Fig.15 The process flow 1500 and the techniques disclosed herein. The server 1200 includes, for example, hardware components, such as an external interface 1202 configured to communicate with network components in the PLMN and UE 115, for example, using HTTP, HTTPs, or SMS. The server 1200 includes one or more processors 1204, a memory 1216, and a non-transitory computer-readable medium 1218, which can be coupled together using a bus 1207.

[0267] The one or more processors 1204 may be implemented using a combination of hardware, firmware, and software. For example, the one or more processors 1204 may be configured to perform the functions discussed herein by implementing one or more instructions or program codes 1220 on a non-transitory computer-readable medium such as the medium 1218 and / or the memory 1216. In some embodiments, the one or more processors 1204 may represent one or more circuits that may be configured to perform at least a portion of a data signal computing procedure or process associated with the operation of the network node 1200.

[0268] The medium 1218 and / or the memory 1216 may store instructions or program code 1220 including executable code or software instructions that, when executed by the one or more processors 1204, cause the one or more processors 1204 to function as processors programmed to perform the techniques disclosed herein (e.g., such as Figure 8B and Fig. 9 The signal flow and Fig.15 1500 and the techniques disclosed herein). As shown in the server 1200, the medium 1218 and / or the memory 1216 may include one or more components or modules that can be implemented by one or more processors 1204 to perform the method systems described herein. Although the components or modules are illustrated as software in the medium 1218 that can be executed by one or more processors 1204, it should be understood that the components or modules can be stored in the memory 1216 or can be dedicated hardware in one or more processors 1204 or outside the processor. The medium 1218 and / or the memory 1216 (or another medium including an external storage medium accessed by the server 1200) can store data that can be provided to the UE upon request, such as coverage data that can enable the UE to determine whether it is possible to access the serving PLMN at one or more locations of the UE, at one or more or more future times, using one or more radio access technologies (RATs), or for some combination of these items. The coverage data can be for NTN RAT and / or TN RAT.

[0269] Several software modules and data tables may reside in the media 1218 and / or memory 1216 and be utilized by the one or more processors 1204 to manage both the communications and functionality described herein. It should be appreciated that the organization of the contents of the media 1218 and / or memory 1216 as shown in the network node 1200 is merely exemplary, and as such, the functionality of the various modules and / or data structures may be combined, separated, and / or configured in different ways depending on the implementation of the network node 1200. Although the various components or modules are illustrated as software in the media 1218 and / or memory 1216 that is executable by the one or more processors 1204, it should be understood that the various components or modules may be firmware or dedicated hardware in the one or more processors 1204 or external to the processors.

[0270] As shown, program code 1220 stored on medium 1218 and / or memory 1216 may include a data access module 1222 that, when implemented by one or more processors 1204, configures one or more processors 1204 to support providing coverage data to a UE, as described herein and particularly with respect to Figure 8B and Fig. 9 described.

[0271] The methodologies described herein may be implemented by various means depending on the application. For example, these methodologies may be implemented in hardware, firmware, software, or any combination thereof. For hardware implementation, one or more processors 1204 may be implemented in one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), processors, controllers, microcontrollers, microprocessors, electronic devices, other electronic units designed to perform the functions described herein, or combinations thereof.

[0272] For specific implementations of server 1200 involving firmware and / or software, these methodologies may be implemented with modules (e.g., procedures, functions, etc.) that perform the individual functions described herein. Any machine-readable medium that tangibly embodies instructions may be used to implement the methodologies described herein. For example, software code may be stored in medium 1218 or memory 1216 and executed by one or more processors 1204, thereby causing one or more processors 1204 to operate as a special-purpose computer programmed to perform the techniques disclosed herein. Memory 1216 may be implemented within one or more processors 1204 or external to one or more processors 1204. As used herein, the term "memory" refers to any type of long-term, short-term, volatile, non-volatile, or other memory, and is not limited to any particular type of memory or any particular amount of memory, or the type of medium on which the memory is stored.

[0273] In the case of implementation in firmware and / or software, the functions performed by the server 1200 may be stored as one or more instructions or codes on a non-transitory computer-readable storage medium (such as medium 1218 or memory 1216). Examples of storage media include computer-readable media encoded with data structures and computer-readable media encoded with computer programs. Computer-readable media include physical computer storage media. Storage media can be any available media that can be accessed by a computer. By way of example and not limitation, such computer-readable media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage devices, magnetic disk storage devices, semiconductor storage devices or other storage devices, or any other medium that can be used to store desired program codes in the form of instructions or data structures and can be accessed by a computer; as used herein, disks and optical disks include compact disks (CDs), laser disks, optical disks, digital versatile disks (DVDs), floppy disks, and Blu-ray disks, where disks typically reproduce data magnetically, while optical disks reproduce data optically using lasers. The above combinations should also be included within the scope of computer-readable media.

[0274] In addition to being stored on a computer-readable storage medium, instructions and / or data for server 1200 may also be provided as a signal on a transmission medium included in a communication device. For example, a communication device including part or all of server 1200 may include a transceiver having a signal indicating instructions and data. These instructions and data are stored on a non-transitory computer-readable medium (e.g., medium 1218 or memory 1216) and are configured to cause one or more processors 1204 to operate as a special-purpose computer programmed to perform the technology disclosed herein. That is, the communication device includes a transmission medium having a signal indicating information for performing the disclosed functions. At a first time, the transmission medium included in the communication device may include a first portion of information for performing the disclosed functions, and at a second time, the transmission medium included in the communication device may include a second portion of information for performing the disclosed functions.

[0275] Fig.13 A flow chart illustrating a method 1300 performed by a user equipment (UE) (e.g., UE 115 or UE 1000) for obtaining coverage data to assist the UE in wireless access to a serving public land mobile network (PLMN) (e.g., 5GCN 110) according to various aspects of the present disclosure is shown. The operations of the method 1300 may be implemented by a UE or components thereof as described herein. For example, the operations of the method 1300 may be implemented by a UE or components thereof as described herein. Figures 1 to 10 and Fig.16 The described UE 115 is executed or performed at the UE. In some examples, the UE may execute an instruction set to control the functional elements of the UE to perform the described functions. Additionally or alternatively, the UE may use dedicated hardware to perform various aspects of the described functions.

[0276] At block 1302, the UE accesses a serving PLMN, e.g. Fig. 8A The means for accessing the serving PLMN may be, for example, Fig.10 A wireless transceiver 1002 or a satellite transceiver 1003 in the UE 1000 and one or more processors 1004 having dedicated hardware or implementing executable code or software instructions (such as a PLMN access module 1022) in memory 1016 and / or media 1018.

[0277] At block 1304, the UE obtains the address and authorization data of the server, e.g., as for Fig. 8A Procedure 800 or 825 for Figure 8C The component for obtaining the server address and authorization data may be, for example, Fig.10 A wireless transceiver 1002 or a satellite transceiver 1003 in the UE 1000 and one or more processors 1004 having dedicated hardware or implementing executable code or software instructions (such as a data access module 1024) in a memory 1016 and / or a medium 1018.

[0278] At block 1306, the UE transmits a request to the server based on the address, wherein the request includes authorization data, such as for Figure 8B 855 or 850 of the course Figure 8C The component for transmitting a request to a server based on the address (wherein the request includes authorization data) may be, for example, Fig.10 A wireless transceiver 1002 or a satellite transceiver 1003 in the UE 1000 and one or more processors 1004 having dedicated hardware or implementing executable code or software instructions (such as a data access module 1024) in a memory 1016 and / or a medium 1018.

[0279] At block 1308, the UE receives coverage data from the server based on the server's verification of the authorization data (e.g., the server's verification of the UE's temporary ID included in the authorization data), e.g., as for Figure 8B 850 or 865 for Figure 8C The component for receiving the coverage data from the server based on the server's verification of the authorization data may be, for example, Fig.10 The wireless transceiver 1002 or satellite transceiver 1003 in the UE 1000 in the embodiment and one or more processors 1004 with dedicated hardware or implementing executable code or software instructions (such as data access module 1024) in memory 1016 and / or medium 1018. The coverage data may enable the UE to determine whether access to the serving PLMN via one or more satellites is possible in the following situations: at one or more locations in the geographic area (e.g., one or more locations of the UE); at one or more future times; using one or more radio access technologies (RATs); or for some combination of these items, for example, as for 7A to 7F For example, the serving PLMN may have discontinuous satellite coverage, and the coverage data includes coverage data for one or more satellite RATs, such as for 7A to 7F described.

[0280] In one implementation, the coverage data includes a spatial coverage map indicating whether access to the serving PLMN is possible at one or more locations in the geographic area, wherein the one or more locations may include multiple locations on a grid, and wherein the coverage data may include multiple spatial coverage maps for each of one or more future times, e.g., as described herein with respect to 7A to 7F described.

[0281] A spatial coverage map may include a heat map indicating signal power levels, signal quality levels, or both at one or more locations, such as for Fig.7D To indicate whether access to a serving PLMN is possible at one or more locations, the spatial coverage map may include a plurality of grid points, wherein each grid point of the plurality of grid points is associated with a Boolean coverage availability indication or a digital signal power indication.

[0282] In one specific implementation, the coverage data includes a time coverage map indicating whether access to the serving PLMN is possible at one or more future times, and wherein the coverage data may include a plurality of time coverage maps for each of one or more locations of the UE, e.g., as described herein with respect to Figure 7C , Fig. 7E and Figure 7F described.

[0283] In one embodiment, the coverage data is specific to one or more parameters related to the UE (e.g., input parameters), where the one or more parameters may include: UE type; antenna receive (Rx) gain or loss; overall antenna signal gain or loss; one or more minimum signal reception levels of power, quality, or both supported by the UE; or some combination of these items, for example, as discussed above for the first, second, and third examples of SCAI encoding.

[0284] In one embodiment, the coverage data includes a time coverage map indicating (i) one or more durations during which access to the serving PLMN is possible, (ii) one or more durations during which access to the serving PLMN is not possible, or any combination thereof, and wherein the coverage data may include multiple time coverage maps for each of one or more locations of the UE, for example, as described herein with respect to Figure 7C , Fig. 7E and Figure 7F described.

[0285] In one specific implementation, the authorization data includes a temporary identifier of the UE, wherein the temporary identifier may enable verification of the authorization data by the server. The temporary identifier may include encryption of the identifier, wherein the identifier is configured in the serving PLMN and the server, and wherein the encryption is based on an encryption key configured in the serving PLMN and the server, for example, as for Fig. 8A and Figure 8B described.

[0286] In one implementation, the UE obtains the address and authorization data from a Universal Subscriber Identity Module (USIM) on the UE, or by transmitting a Non-Access Stratum (NAS) request to an entity in the serving PLMN, or by assembling a standardized address and standardized authorization data, e.g., as for Fig. 8A As described in 825 of process 800 in . In one example, the NAS request indicates at least one of the following items: the location of the coverage data, the area of ​​the coverage data, the relevant time or time period of the coverage data, the relevant RAT of the coverage data, the relevant PLMN of the coverage data, the supported method or coding for receiving the coverage data from the server, or any combination thereof. In a specific implementation, the authorization data indicates at least one of the following items: the location of the coverage data, the area of ​​the coverage data, the relevant time or time period of the coverage data, the relevant RAT of the coverage data, the relevant PLMN of the coverage data, the supported method or coding for receiving the coverage data from the server, or any combination thereof, and the authorization data may not be interpreted by the UE.

[0287] In one embodiment, the authorization data includes: (i) a temporary identifier of the UE, wherein the temporary identifier is known to the server, (ii) an address of the server, or both. In one embodiment, the authorization data includes the temporary identifier of the UE and the address of the server, wherein the temporary identifier of the UE is part of the address of the server, such as for example Fig. 8A As described in 820 of process 800.

[0288] In one implementation, the temporary identifier is a reserved value preconfigured in the server, for example, Fig. 8A As described in 820 of process 800.

[0289] In one implementation, the temporary identifier is encrypted, wherein the server decrypts the temporary identifier provided by the UE, for example, as for Fig. 8A As described in 820 of process 800.

[0290] In one implementation, the authorization data is a uniform resource identifier (URI), a text string, or both, such as for Fig. 8A For example, the authorization data includes a temporary identifier of the UE and an address of the server, and the temporary identifier may be part of the URI or part of the text string or both, for example, as for Fig. 8A As described in 820 of process 800.

[0291] In one specific implementation, a server is accessed based on a URI using a hypertext transfer protocol (HTTP) or a hypertext transfer secure protocol (HTTPS), wherein transmitting a request to the server includes transmitting an HTTP message or an HTTPS message to the server, wherein the HTTP message or the HTTPS message is addressed to the URI, for example, Figure 8B As described in 855 of process 850.

[0292] In one specific implementation, the server belongs to the serving PLMN, the home PLMN of the UE, a satellite operator providing access to the serving PLMN, or a separate third party, for example, as described with respect to process 800 and process 850.

[0293] In one implementation, the authorization data allows the UE to access and obtain coverage data from the server for a limited number of times or a limited amount of time, or both, e.g., for Figure 8B As described in process 850 in 860.

[0294] As mentioned above, you can use Fig.13 A method similar or identical to the illustrated method 1300 enables a UE to request and receive other types of data other than coverage data from a server.

[0295] Fig.14 A flow chart illustrating a method 1400 performed by a network entity (e.g., an entity in a serving PLMN, network entity 185, AMF 122, SMF 134, MME, or network entity 1100) for providing coverage data to a UE to assist the UE (e.g., UE 115) in wireless access to a serving public land mobile network (PLMN) (e.g., 5GCN 110) according to aspects of the present disclosure is shown. The operations of method 1400 may be implemented by a network entity or component as described herein. For example, the operations of method 1400 may be implemented by a network entity or component as described herein. Figures 1 to 9 as well as Fig.11 and Fig.16 The network entity 185 described herein is executed or executed at the network entity. In some examples, the network entity may execute an instruction set to control the functional elements of the network entity to perform the described functions. Additionally or alternatively, the network entity may use dedicated hardware to perform various aspects of the described functions.

[0296] At block 1402, a network entity receives a request for authorization data from a UE to enable a server (e.g., server 187) to provide coverage data to the UE, e.g., as for Fig. 8A The means for receiving a request for a server address from a UE to provide data to the UE may be, for example, an external interface 1102 and one or more processors 1104 having dedicated hardware or implementing executable code or software instructions in a memory 1116 and / or a medium 1118, such as Fig.11 The data access module 1122 in the network entity 1100.

[0297] At block 1404, the network entity determines authorization data, wherein at least a portion of the authorization data is known to the server, e.g., as described for Fig. 8A The means for assigning a temporary identifier to a UE (where the temporary identifier is known to the server) may be, for example, an external interface 1102 and one or more processors 1104 having dedicated hardware or implementing executable code or software instructions in a memory 1116 and / or a medium 1118, such as Fig.11 The data access module 1122 in the network entity 1100.

[0298] At block 1406, the network entity transmits authorization data to the UE, such as for Fig. 8A The means for providing the address of the server and the temporary identifier of the UE to the UE may be, for example, an external interface 1102 and one or more processors 1104 having dedicated hardware or implementing executable code or software instructions in a memory 1116 and / or a medium 1118, such as Fig.11 The data access module 1122 in the network entity 1100.

[0299] In one implementation, the coverage data enables the UE to determine whether access to the serving PLMN is possible at one or more locations of the UE, at one or more future times, using one or more radio access technologies (RATs), or for some combination of these, e.g., for 7A to 7F For example, the serving PLMN may have discontinuous satellite coverage, and the coverage data may include coverage data for one or more satellite RATs, such as for 7A to 7F In one specific implementation, the coverage data includes a spatial coverage map indicating whether access to the serving PLMN is possible at one or more locations of the UE, wherein the one or more locations include a plurality of locations on a grid, and wherein the coverage data includes a plurality of spatial coverage maps for each of one or more future times, for example, as described herein with respect to Figure 7C , Fig. 7E and Figure 7F In one specific implementation, the coverage data includes a time coverage map indicating whether access to the serving PLMN is possible at one or more future times, the coverage data including a plurality of time coverage maps for each of one or more locations of the UE, for example, as described herein with respect to Figure 7C , Fig. 7E and Figure 7F In one implementation, the coverage data includes a time coverage map indicating (i) one or more durations during which access to the serving PLMN is possible, (ii) one or more durations during which access to the serving PLMN is not possible, or any combination thereof, wherein the coverage data includes a plurality of time coverage maps for each of the one or more locations of the UE, for example, as described herein with respect to Figure 7C , Fig. 7E and Figure 7F described.

[0300] In one implementation, the network entity authenticates the UE and verifies the UE's subscription to receive coverage data from the server before transmitting authorization data to the UE, e.g., as for Fig. 8A The means for authenticating the UE and verifying the UE subscription to receive data from the server before providing authorization data to the UE may be, for example, an external interface 1102 and one or more processors 1104 having dedicated hardware or implementing executable code or software instructions in a memory 1116 and / or a medium 1118, such as Fig.11 The data access module 1122 in the network entity 1100.

[0301] In one implementation, the authorization data includes: (i) a temporary identifier of the UE, wherein the temporary identifier is known to the server, (ii) an address of the server, or both. In one implementation in which the authorization data includes the temporary identifier of the UE and the address of the server, the temporary identifier of the UE is part of the address of the server, for example, as for Fig. 8A As described in 820 of process 800.

[0302] In one implementation, the temporary identifier is a reserved value preconfigured in the entity in the serving PLMN and in the server, for example, Fig. 8A As described in 820 of process 800.

[0303] In one specific implementation, the network entity encrypts the temporary identifier transmitted to the UE, wherein the server decrypts the temporary identifier provided by the UE, and wherein the encryption and decryption are based on encryption keys configured in the network entity and the server, for example, as for Fig. 8A As described in 820 of process 800.

[0304] In one specific implementation, the authorization data or the address of the server is a uniform resource identifier (URI) or a text string or both. In one specific implementation, the authorization data includes a temporary identifier of the UE and the address of the server, and the temporary identifier can be part of the URI or part of the text string or both, such as for Fig. 8A As described in 820 of process 800.

[0305] In one specific implementation, the network entity records the association of the authorization data with the UE, wherein the UE is charged for access to the server based on the usage of the authorization data reported by the server and the association of the authorization data with the UE, for example, Fig. 8A and Fig. 9 The means for recording the association of the authorization data with the UE may be, for example, an external interface 1102 and one or more processors 1104 having dedicated hardware or implementing executable code or software instructions in a memory 1116 and / or a medium 1118, such as Fig.11 The data access module 1122 in the network entity 1100.

[0306] In one specific implementation, the server belongs to the serving PLMN, the home PLMN of the UE, a satellite operator providing access to the serving PLMN, or a separate third party, for example, as described with respect to process 800 and process 850.

[0307] In one implementation, the authorization data allows the UE to access and obtain data from the server a limited number of times or a limited amount of time, or both, e.g., for Figure 8B As described in process 850 in 860.

[0308] In one implementation, a request for authorization data is received from the UE, and the authorization data is transmitted to the UE in a non-access stratum (NAS) message, a radio resource control (RRC) unicast message, or a system information block (SIB), e.g., as for Fig. 8A 805 and 825 of process 800 in . In a specific implementation, the NAS message includes a NAS request from the UE, the NAS request indicating at least one of the following items: a location of the coverage data, an area of ​​the coverage data, a relevant time or time period of the coverage data, a relevant RAT of the coverage data, a relevant PLMN of the coverage data, a supported method or coding for receiving the coverage data from the server, or any combination thereof. In a specific implementation, the authorization data indicates at least one of the following items: a location of the coverage data, an area of ​​the coverage data, a relevant time or time period of the coverage data, a relevant RAT of the coverage data, a relevant PLMN of the coverage data, a supported method or coding for receiving the coverage data from the server, or any combination thereof, wherein the authorization data may not be interpreted by the UE.

[0309] As mentioned above, you can use Fig.14 A method similar or identical to the illustrated method 1400 enables a UE to request and receive authorization data from a network entity to enable the UE to obtain other types of data other than coverage data from a server.

[0310] Fig.15 A flow chart illustrating a method 1500 performed by a server (e.g., server 187, server 1200) for providing coverage data to a user equipment (UE) to assist the UE (e.g., UE 115) in wireless access to a serving public land mobile network (PLMN) (e.g., 5GCN 110) according to aspects of the present disclosure is shown. The operations of the method 1500 may be implemented by the server 187 or components thereof as described herein. For example, the operations of the method 1500 may be implemented by the server 187 or components thereof as described herein. Figures 1 to 9 and Fig.12 The described server 187 is executed or executed at the server. In some examples, the server can execute the instruction set to control the functional elements of the server to perform the described functions. Additionally or alternatively, the server can use dedicated hardware to perform various aspects of the described functions.

[0311] At block 1502, a server receives a request for coverage data from a UE, wherein the request is transmitted by the UE to an address of the server, and wherein the request includes authorization data for the UE, and wherein the authorization data is provided to the UE by an entity in a serving PLMN, e.g., as directed to Figure 8B The means for receiving a request for coverage data from the UE using a server address provided to the UE by an entity in the serving PLMN and the authorization data of the UE may be, for example, an external interface 1202 and one or more processors 1204 having dedicated hardware or implementing executable code or software instructions in a memory 1216 and / or a medium 1218, such as Fig.12 The data access module 1222 in the server 1200.

[0312] At block 1504, the server verifies the authorization data, e.g., Figure 8B The means for verifying the authorization data may be, for example, an external interface 1202 and one or more processors 1204 having dedicated hardware or implementing executable code or software instructions in a memory 1216 and / or a medium 1218, such as Fig.12 The data access module 1222 in the server 1200.

[0313] At block 1506, the server transmits coverage data to the UE based on the verification of the authorization data, e.g., as for Figure 8B The means for transmitting coverage data to the UE based on the verification of the authorization data may be, for example, an external interface 1202 and one or more processors 1204 having dedicated hardware or implementing executable code or software instructions in a memory 1216 and / or a medium 1218, such as Fig.12 The data access module 1222 in the server 1200.

[0314] In one implementation, the coverage data enables the UE to determine whether access to the serving PLMN is possible at one or more locations of the UE, at one or more future times, using one or more radio access technologies (RATs), or for some combination of these, e.g., for 7A to 7F For example, the serving PLMN may have discontinuous satellite coverage, and the coverage data may include coverage data for one or more satellite RATs, such as for 7A to 7F described.

[0315] In one specific implementation, the coverage data includes a spatial coverage map indicating whether access to the serving PLMN is possible at one or more locations of the UE, the one or more locations including a plurality of locations on a grid, and the coverage data includes a plurality of spatial coverage maps for each of one or more future times, for example, as described herein with respect to Figure 7C , Fig. 7E and Figure 7F In one specific implementation, the coverage data includes a time coverage map indicating whether access to the serving PLMN is possible at one or more future times, the coverage data including a plurality of time coverage maps for each of one or more locations of the UE, for example, as described herein with respect to 7A to 7F In one implementation, the coverage data includes a time coverage map indicating (i) one or more durations during which access to the serving PLMN is possible, (ii) one or more durations during which access to the serving PLMN is not possible, or any combination thereof, wherein the coverage data includes a plurality of time coverage maps for each of the one or more locations of the UE, for example, as described herein with respect to 7A to 7F described.

[0316] In one embodiment, the authorization data includes: (i) a temporary identifier of the UE, wherein the temporary identifier is known to the server, (ii) an address of the server, or both. In one embodiment, the authorization data includes the temporary identifier of the UE and the address of the server, and the temporary identifier of the UE may be a part of the address of the server, for example, as for Fig. 8A As described in 820 of process 800.

[0317] In one implementation, the temporary identifier is a reserved value that is (e.g., pre-) configured in an entity in the serving PLMN and in the server, e.g., as for Fig. 8A As described in 820 of process 800.

[0318] In one implementation, the temporary identifier is encrypted, wherein the server decrypts the temporary identifier, and wherein the encryption and decryption may be based on an encryption key configured in an entity in the serving PLMN and in the server, for example, as for Figure 8B In this specific implementation, the server may obtain a set of identifiers used to generate temporary identifiers by entities in the serving PLMN, for example, as for Figure 8B The means for generating a set of temporary identifiers based on encryption keys by an entity in the serving PLMN may be, for example, an external interface 1202 and one or more processors 1204 having dedicated hardware or implementing executable code or software instructions in a memory 1216 and / or a medium 1218, such as Fig.12 The server can verify the authorization data by decrypting the temporary identifier with the encryption key to generate an identifier, and can verify that the identifier is in the identifier set, for example, as for Figure 8B The means for decrypting the temporary identifier with the encryption key to generate the identifier may be, for example, an external interface 1202 and one or more processors 1204 having dedicated hardware or implementing executable code or software instructions in memory 1216 and / or media 1218, such as Fig.12 The data access module 1222 in the server 1200 in the embodiment. The means for verifying that the identifier is in the identifier set may be, for example, an external interface 1202 and one or more processors 1204 having dedicated hardware or implementing executable code or software instructions in a memory 1216 and / or a medium 1218, such as Fig.12 The data access module 1222 in the server 1200.

[0319] In one specific implementation, the server reports the use of the temporary identifier based on the association of the temporary identifier with the UE recorded by an entity in the serving PLMN to charge the UE for access to the server, for example, Fig. 9 The means for reporting the use of the temporary identifier based on the association of the temporary identifier with the UE recorded by the entity in the serving PLMN to charge the UE for access to the server may be, for example, an external interface 1202 and one or more processors 1204 having dedicated hardware or implementing executable code or software instructions in a memory 1216 and / or a medium 1218, such as Fig.12 The data access module 1222 in the server 1200.

[0320] In one embodiment, the authorization data is a uniform resource identifier (URI) or a text string or both, such as for example Fig. 8A For example, the authorization data may include a temporary identifier of the UE and an address of the server, and the temporary identifier may be part of a URI (e.g., an extension of the URI) or part of a text string or both, such as for example, Fig. 8A As described in 820 of process 800.

[0321] In one implementation, a request for coverage data is received from a UE using Hypertext Transfer Protocol (HTTP), Hypertext Transfer Protocol Secure (HTTPS), or Short Message Service (SMS), for example, as for Figure 8B As described in 855 of process 850.

[0322] In one specific implementation, the server belongs to the serving PLMN, the home PLMN of the UE, a satellite operator providing access to the serving PLMN, or a separate third party, for example, as described with respect to process 800 and process 850.

[0323] In one implementation, the authorization data allows the UE to access and obtain coverage data from the server for a limited number of times or a limited amount of time, or both, e.g., for Figure 8B As described in process 850 in 860.

[0324] In one specific implementation, the server reports the use of the authorization data based on the association of the authorization data recorded by the entity in the serving PLMN with the UE to charge the UE for access to the server, for example, Fig. 8A and Fig. 9 As described in 820 of process 800.

[0325] As mentioned above, you can use Fig.15 A method similar or identical to the illustrated method 1500 enables a UE to request and receive other types of data other than coverage data from a server.

[0326] Fig.16 A process is illustrated that enables a UE (e.g., UE 115) to register with a serving PLMN that can provide 5G NR satellite access to the UE, wherein a serving AMF (e.g., AMF 120) for the UE in the serving PLMN can provide authorization data to the UE. Fig.16 Shown with the previous Fig. 8A Similar procedures as described above, but allowing the serving AMF for the UE (such as Fig. 8A The authorization data is provided by the UDM in the UE's HPLMN. Fig.16 After the process shown, the UE can use the authorization data obtained thereby to obtain coverage data from a server (hereinafter referred to as an external server), such as for Figure 8B described.

[0327] exist Fig.16 In the present invention, the authorization data may come from (e.g., may be determined by) a unified data management (UDM) in the serving AMF or the HPLMN of the UE. The authorization data provides information to the UE to enable the UE to access an external server (e.g., a server belonging to a satellite network operator) and obtain satellite coverage data (e.g., satellite coverage map data) from the server. For example, the satellite coverage data may indicate when satellite coverage is available and unavailable at one or more locations and at one or more times, as described elsewhere herein. The UE may provide input parameters such as a minimum signal level or a minimum signal power to the external server, and when no satellite is visible at any location and time or when the signal level or signal power of all visible satellites from the location and time is lower than the minimum signal level or minimum signal power provided by the UE, the external server then determines that satellite coverage is not available at that location and time. However, when the signal level or signal power of at least one visible satellite from any location and time is equal to or greater than the minimum signal level or minimum signal power provided by the UE, the external server may determine that satellite coverage is available at that location and time. The minimum signal level or minimum signal power level provided by the UE may be equal to the minimum signal level or signal power required for the UE to access the satellite to communicate with the serving PLMN. When the serving AMF (e.g., AMF122) provides authorization data to the UE, the external server may be associated with the serving PLMN. When the UDM will provide authorization data to the AMF for forwarding to the UE, the external server may be associated with the HPLMN of the UE. The authorization data may include the address of the server (e.g., IP address, URI, fully qualified domain name (FQDN), SMS address), may indicate the protocol or transport protocol (e.g., HTTP, HTTPS, SMS) to be used by the UE to access the external server and obtain satellite coverage data from the server, may include a temporary identifier (or identity) of the UE that can be verified or authenticated by the external server (e.g., as described elsewhere herein), and may indicate the type of satellite coverage data that can be obtained from the external server and the period or duration during which the UE is allowed to access the external server to obtain satellite coverage data.

[0328] The UE may initiate a registration procedure using any of a number of registration types, including when the UE requires authorization to obtain coverage availability information for NR satellite access. Fig.16 The various stages of the process of obtaining authorization to receive coverage data are shown in italics.

[0329] Phase 1: UE sends a NAS registration request to AMF (e.g. Fig. 8A 805 of ). The details include UE to (R)AN: AN message (AN parameters, registration request (registration type, SUCI or 5G-GUTI or PEI, [last visited TAI (where available)], security parameters, [requested NSSAI], [mapping of requested NSSAI], [default configured NSSAI indication], [UE radio capability update], [UE MM core network capabilities], [PDU session status], [list of PDU sessions to be activated], [follow-up request], [MICO mode preference], [requested active time], [requested DRX parameters for E-UTRA and NR], [requested DRX parameters for NB-IoT], [extended idle mode DRX parameters], [LADN [Indicator of DNN or requesting LADN information], [NAS message container], [Indication of support for use of enhanced coverage], [Preferred network behavior], [UE paging probability information], [Paging subgroup support indication], [UE policy container (PSI list, UE support ANDSP indication and operating system identifier)] and [UE radio capability ID], [Release request indication], [Paging restriction information], PEI, [PLMN with disaster conditions], [Requested periodic update time], [Unavailable period duration], [Request authorization for obtaining satellite coverage availability information])). The UE policy container and its use are defined in 3GPP TS23.503.

[0330] In the case of NG-RAN, the AN parameters may include, for example, 5G-S-TMSI or GUAMI, the selected PLMN ID (or PLMNID and NID, see clause 5.30 of 3GPP TS23.501), and NSSAI information, and the AN parameters also include the establishment cause. The establishment cause provides the reason for requesting to establish an RRC connection. Whether and how the UE includes the NSSAI information as part of the AN parameters depends on the value of the Access Stratum Connection Establishment NSSAI Inclusion Mode parameter, as specified in clause 5.15.9 of 3GPP TS23.501.

[0331] In the case where the UE is an IAB node accessing 5GS, the AN parameters may also include an IAB indication.

[0332] The registration type indicates whether the UE wants to perform an initial registration (i.e., the UE is in RM-DEREGISTERED state), a mobility registration update (i.e., the UE is in RM-REGISTERED state and initiates a registration procedure due to mobility or because the UE needs to update its capabilities or protocol parameters or requests a change in the set of network slices it is allowed to use), a periodic registration update (i.e., the UE is in RM-REGISTERED state and initiates a registration procedure due to expiration of the periodic registration update timer, see clause 4.2.2.2.1 of 3GPPTS23.502), an emergency registration (i.e., the UE is in restricted service state), a disaster roaming initial registration, or a disaster roaming mobility registration update.

[0333] When the UE is using E-UTRA, the UE may indicate its support for CIoT 5GS Optimizations which may be related to AMF selection in the RRC connection establishment signaling associated with the Registration Request.

[0334] When the UE is performing an initial registration or a disaster roaming registration, the UE may indicate its UE identity in the Registration Request message as follows, listed in descending order of preference in the case of registration with a PLMN:

[0335] i) In case the UE has a valid EPS GUTI, the 5G-

[0336] GUTI;

[0337] ii) the native 5G-GUTI assigned by the equivalent SNPN to the SNPN to which the UE is attempting to register and the NID of the SNPN that assigned the 5G-GUTI (where available);

[0338] iii) the native 5G-GUTI assigned by the PLMN to which the UE is attempting to register (where available);

[0339] iv) The native 5G-GUTI assigned by the equivalent PLMN to the PLMN that the UE is attempting to register to

[0340] (where applicable);

[0341] iv) The native 5G-GUTI assigned by any other PLMN (where available). According to some embodiments, this may also be a 5G-GUTI assigned via another access type. v) Otherwise, the UE may include its SUCI in the Registration Request as defined in 3GPP TS 33.501.

[0342] In the case where the UE is registering with the SNPN, when the UE is performing an initial registration, the UE may indicate its UE identity in the Registration Request message as follows, listed in descending order of preference:

[0343] i) the native 5G-GUTI assigned by the same SNPN that the UE is attempting to register to (where available);

[0344] ii) The native 5G-GUTI assigned by any other SNPN and the NID of the SNPN that assigned the 5G-GUTI (where available).

[0345] iii) Otherwise, the UE may include its SUCI in the Registration Request as defined in 3GPP TS 33.501.

[0346] When the UE performing initial registration has both a valid EPS GUTI and a native 5G-GUTI, the UE may also indicate the native 5G-GUTI as an additional GUTI. In the event that more than one native 5G-GUTI is available, the UE may select a 5G-GUTI in descending order of preference from items (ii)-(iv) in the above list.

[0347] In the case where the UE is transmitting a Registration Request message as an initial NAS message and the UE has a valid 5G NAS security context and the UE needs to transmit non-plaintext IEs (see clause 4.4.6 in 3GPP TS 24.501), a NAS message container may be included. In the case where the UE does not need to transmit non-plaintext IEs, the UE may transmit a Registration Request message without including a NAS message container.

[0348] In the event that the UE does not have a valid 5G NAS security context, the UE may transmit a Registration Request message without including a NAS message container. The UE may include the entire Registration Request message (i.e., including plaintext IEs and non-plaintext IEs) in a NAS message container transmitted as part of the Security Mode Complete message in Phase 9b.

[0349] When the UE is performing an initial registration with a native 5G-GUTI (i.e., the UE is in RM-DEREGISTERED state), the UE may indicate relevant GUAMI information in the AN parameters. When the UE is performing an initial registration with its SUCI, the UE may not indicate any GUAMI information in the AN parameters.

[0350] When the UE is performing an initial registration or mobility registration and if CIoT 5GS optimization is supported, the UE may indicate its preferred network behavior (see clause 5.31.2 of 3GPP TS23.501). In the case of supporting S1 mode, the UE's EPC preferred network behavior is included in the S1UE network capabilities in the registration request message, see clause 8.2.6.1 of 3GPP TS24.501.

[0351] For emergency registration, SUCI may be included if the UE does not have a valid 5G-GUTI available; PEI may be included when the UE does not have SUPI and does not have a valid 5G-GUTI. In other cases, 5G-GUTI is included and indicates the last serving AMF.

[0352] The UE may provide the UE's usage settings based on its configuration as defined in clause 5.16.3.7 of 3GPP TS23.501. The UE provides the requested NSSAI (as described in clause 5.15.5.2.1 of 3GPP TS23.501) and, in the case where the UE supports subscription-based restrictions on simultaneously registered network slices, also considers the NSSRG information constraints as described in clause 5.15.12 of 3GPP TS23.501, and in the case of initial registration or mobility registration update, the UE includes a mapping of the requested NSSAI (where available), which is a mapping of each S-NSSAI of the requested NSSAI to the HPLMN S-NSSAI to ensure that the network can verify whether the S-NSSAI in the requested NSSAI is allowed based on the subscribed S-NSSAI. In case of inter-PLMN mobility, in the event that the serving PLMN S-NSSAI corresponding to the established PDU session is not present in the UE, the associated HPLMN S-NSSAI associated with the established PDU session may be provided in the mapping of the requested NSSAI as described in clause 5.15.5.2.1 of 3GPP TS 23.501.

[0353] In the case where the UE is using the default configured NSSAI, the UE includes a default configured NSSAI indication as defined in 3GPP TS 23.501.

[0354] In the case where the UE supports the assignment of WUS assistance information or AMF PEIPS assistance information from the AMF, the UE may include UE paging probability information (see 3GPP TS 23.501).

[0355] The UE may include a paging subgroup support indication as defined in 3GPP TS 23.501.

[0356] In case of a mobility registration update, the UE includes in the list of PDU sessions to be activated the PDU sessions for which there is pending uplink data. When the UE includes the list of PDU sessions to be activated, the UE may indicate only the PDU sessions associated with the access to which the registration request relates. As defined in 3GPP TS 24.501, the UE may include in the list of PDU sessions to be activated the always-open PDU sessions accepted by the network, even if there is no pending uplink data for those PDU sessions.

[0357] Note 3: When the UE is outside the availability area of ​​the LADN, the PDU session corresponding to the LADN is not included in the list of PDU sessions to be activated.

[0358] UE MM Core Network Capabilities are provided by the UE and processed by the AMF as defined in clause 5.4.4a of 3GPP TS23.501. The UE includes in the UE MM Core Network Capabilities an indication of whether it supports the request type flag "Handover" for PDN connectivity requests during the attach procedure as defined in clause 5.17.2.3.1 of 3GPP TS23.501. In the case where the UE supports "Strict Periodic Registration Timer Indication", the UE indicates its capability for "Strict Periodic Registration Timer Indication" in the UE MM Core Network Capabilities. In the case where the UE supports CAG, the UE indicates its capability for "Support CAG" in the UE MM Core Network Capabilities. In the case where a UE operating two or more USIMs supports and intends to use one or more multi-USIM features, the UE indicates in the UE MM Core Network Capabilities one or more multi-USIM specific features described in clause 5.38 of 3GPP TS23.501. In the case where the UE supports equivalent SNPN, the UE indicates its "equivalent SNPN" capability in the UE MM core network capabilities. In the case where the UE supports unavailable periods, the UE indicates its "unavailable period support" capability in the UE MM core network capabilities.

[0359] The UE may provide a LADN DNN or an indication to request LADN information as described in clause 5.6.5 of 3GPP TS 23.501.

[0360] Where available, the last visited TAI may be included to help the AMF generate a registration area for the UE.

[0361] NOTE 4: With NR satellite access, determine the last visited TAI as specified in clause 5.4.11.6 of 3GPP TS 23.501.

[0362] Security parameters are used for authentication and integrity protection, see 3GPP TS 33.501. The requested NSSAI indicates the network slice selection assistance information (as defined in clause 5.15 of 3GPP TS23.501). The PDU session status indicates the previously established PDU session in the UE. When the UE is connected to two AMFs belonging to different PLMNs via 3GPP access and non-3GPP access, the PDU session status indicates the established PDU session of the current PLMN in the UE.

[0363] A follow-up request is included when the UE has pending uplink signaling and the UE does not include a list of pending PDU sessions to be activated or the registration type indicates that the UE wants to perform an emergency registration. In initial registration and mobility registration update, the UE provides UE requested DRX parameters as defined in clause 5.4.5 of 3GPP TS 23.501. The UE may provide extended idle mode DRX parameters as defined in clause 5.31.7.2 of 3GPP TS 23.501 to request extended idle mode DRX.

[0364] The UE provides a radio capability update indication as described in 3GPP TS 23.501.

[0365] In case the UE wants to use MICO mode with active time, the UE includes a MICO mode preference and optionally a requested active time value and a requested periodic update time value.

[0366] The UE may indicate its service gap control capability in the UE MM Core Network Capabilities, see clause 5.31.16 of 3GPP TS 23.501.

[0367] For a UE with a service gap timer running in the UE, the UE may not set the follow-up request indication or uplink data status in the registration request message (see clause 5.31.16 of 3GPP TS 23.501), except for network access for regulatory prioritization services such as emergency services or exception reporting.

[0368] In case the UE supports RACS and has been assigned a UE radio capability ID, the UE may indicate the UE radio capability ID as defined in clause 5.4.4.1a of 3GPP TS 23.501 as a non-plain text IE.

[0369] The PEI may be retrieved from the UE in the initial registration as described in clause 4.2.2.2.1 of 3GPP TS 23.502.

[0370] In case the UE supports subscription-based restriction on simultaneous registration of network slices feature, it includes NSSRG handling support indication in the UE 5G MM core network capabilities as per clause 5.15.12 of 3GPP TS 23.501. The AMF stores whether the UE supports this feature in the UE context.

[0371] When a multi-USIM UE wants to enter CM-IDLE state immediately, for example after having performed mobility or periodic registration, it includes a release request indication and optionally provides paging restriction information.

[0372] When the UE is performing disaster roaming registration, the UE may indicate the disaster condition to the PLMN for situations as defined in 3GPP TS 24.501.

[0373] In the case where the UE and the network have indicated support for unavailable periods and an event is triggered in the UE that will make the UE unavailable for a certain period, the UE indicates the unavailable period by including the unavailable period duration as described in clause 5.4.1.4 of 3GPP TS 23.501.

[0374] In the case of registration for NR satellite access, and in the case where the UE supports receiving satellite coverage availability information (SCAI) and requires authorization or further authorization to obtain satellite coverage availability information from an external server, the UE includes an authorization request for obtaining satellite coverage availability information in the registration request transmitted in Phase 1.

[0375] Stage 2: In the event that the 5G-S-TMSI or GUAMI is not included, or the 5G-S-TMSI or GUAMI does not indicate a valid AMF, the (R)AN selects an AMF based on the (R)AT and the requested NSSAI (if available).

[0376] (R)AN selects AMF as described in clause 6.3.5 of 3GPP TS23.501. In the case where the UE is in CM-CONNECTED state, the (R)AN may forward the Registration Request message to the AMF based on the UE's N2 connection.

[0377] In case the (R)AN cannot select a suitable AMF, it forwards the Registration Request to the AMF that has been configured in the (R)AN to perform AMF selection.

[0378] Phase 3: (R)AN to new AMF: N2 message (N2 parameters, Registration Request (as described in Phase 1) and [LTE-M Indication].

[0379] When NG-RAN is used, the N2 parameters include the selected PLMN ID (or PLMN ID and NID, see clause 5.30 of 3GPP TS 23.501), location information and cell identity related to the cell in which the UE is camped, and a UE context request indicating that a UE context including security information needs to be established at the NG-RAN.

[0380] When using NG-RAN, the N2 parameters may also include the establishment cause and the IAB-Indication in case an indication is received in the AN parameters at stage 1.

[0381] The mapping for the requested NSSAI is provided only if available.

[0382] In the case where the registration type indicated by the UE is periodic registration update, stages 4 to 19 may be omitted.

[0383] When the establishment cause is associated with a priority service (e.g., MPS, MCS), the AMF includes a message priority header to indicate the priority information. Other NFs relay the priority information by including a message priority header in a service-based interface, as specified in 3GPP TS29.500.

[0384] Determine the RAT type that the UE is using (see clause 4.2.2.2.1 of 3GPP TS23.502), and based on this, the AMF determines whether the UE is performing inter-RAT mobility to or from NB-IoT. In the event that the AMF receives an LTE M indication, it considers the RAT type to be LTE-M and stores the LTE-M indication in the UE context.

[0385] In case the UE includes a preferred network behavior, this defines the network behavior that the UE supports and expects to be available in the network as defined in clause 5.31.2 of 3GPP TS 23.501.

[0386] In the event that the UE has included a preferred network behavior and the content that the UE indicates it supports in the preferred network behavior is incompatible with the network support, the AMF may reject the Registration Request with an appropriate cause value (e.g. a cause value to avoid retrying on this PLMN).

[0387] In the case where there is a service gap timer running in the UE context in the AMF for the UE and a follow-up request indication or uplink data status is included in the registration request message, the AMF may ignore the follow-up request indication and uplink data status and not perform any action related to the status.

[0388] In case the UE has included the UE radio capability ID in Phase 1 and the AMF supports RACS, the AMF stores the radio capability ID in the UE context.

[0389] For NR satellite access, the AMF may verify the UE location and determine whether the PLMN is allowed to operate at the UE location, as described in clause 5.4.11.4 of 3GPP TS23.501. In the event that the UE receives a Registration Reject message with a cause value indicating that the PLMN is not allowed to operate at the current UE location, the UE may attempt to select a PLMN, as specified in 3GPP TS23.122.

[0390] For disaster roaming registration, the AMF determines whether disaster roaming services can be provided based on the ULI (including cell ID) received from the NG-RAN, the PLMN with disaster conditions derived from the UE's 5G-GUTI, derived from the UE's SUCI or indicated by the UE, and local configuration. In the case that the current location is not subject to disaster roaming services, or disaster roaming services are not provided to the PLMN with disaster conditions derived from the UE's 5G-GUTI, derived from the UE's SUCI or indicated by the UE, the AMF shall reject the registration request indicating an appropriate cause value.

[0391] Phase 4: [Conditional] New AMF to old AMF: Namf_Communication_UEContextTransfer (complete registration request) or new AMF to UDSF: Nudsf_Unstructured Data Management_Query().

[0392] The new AMF uses the UE's 5G-GUTI to determine the old AMF. In the event that the new AMF receives the NID in the Registration Request, it determines that the 5G-GUTI is assigned by the SNPN and uses the SNPN's 5G-GUTI and NID to determine the old AMF.

[0393] (With UDSF deployment): In the case where the UE's 5G-GUTI is included in the Registration Request and the serving AMF has changed since the last registration procedure, the new AMF retrieves the stored UE's SUPI and UE context directly from the UDSF using the Nudsf_UnstructuredDataManagement_Query service operation if the new and old AMF are in the same AMF set and UDSF is deployed, or they may share the stored UE context via implementation specific means if UDSF is not deployed. This also includes event subscription information for each NF consumer for a given UE. In this case, the new AMF performs and verifies integrity protection using the integrity protected full Registration Request NAS message.

[0394] (No UDSF deployment): In the case where the UE's 5G-GUTI is included in the Registration Request and the serving AMF has changed since the last registration procedure, the new AMF may invoke the Namf_Communication_UEContextTransfer service operation on the old AMF, including a complete Registration Request NAS message that may be integrity protected and the access type, to request the UE's SUPI and UE context. See clause 5.2.2.2.2 of 3GPP TS23.502 for details of this service operation. In this case, in the case where the context transfer service operation call corresponds to the requested UE, the old AMF verifies the integrity protection using the 5G-GUTI and the integrity protected complete Registration Request NAS message, or using the SUPI and an indication from the new AMF that the UE is verified. The old AMF also passes the event subscription information of each NF consumer to the new AMF. In the case where the old AMF has not yet reported a non-zero MO exception data counter to the (H-)SMF, the context response also includes the MO exception data counter.

[0395] In case the old AMF has a PDU Session for another access type (different from the access type indicated at stage) and in case the old AMF determines that it is not possible to relocate the N2 interface to the new AMF, the old AMF returns the UE's SUPI and indicates that the Registration Request has been verified for integrity protection, but does not include the rest of the UE context.

[0396] For inter-PLMN mobility, the UE context information includes the HPLMNS-NSSAI corresponding to the allowed NSSAI for each access type, but does not include the allowed NSSAI of the old PLMN.

[0397] NOTE 5: In the case where the new AMF has performed a successful UE authentication after a previous integrity check failure in the old AMF, the new AMF sets an indication that the UE is verified according to operation 9a.

[0398] Note 6: After the UE successfully registers with the new AMF, the NF consumer does not need to subscribe to events with the new AMF again.

[0399] In case the new AMF has received the UE context from the old AMF during the handover procedure, stages 4, 5 and 10 may be skipped.

[0400] For emergency registration, in the case where the UE identifies itself with a 5G-GUTI that is unknown to the AMF, nodes 4 and 5 are skipped and the AMF immediately requests a SUPI from the UE. In the case where the UE identifies itself with a PEI, the SUPI request may be skipped. Allowing emergency registration without user identity depends on local regulations.

[0401] Phase 5: [Conditional] Old AMF to new AMF: Response to Namf_Communication_UEContextTransfer (SUPI, UE context in AMF (as per Table 5.2.2.2.2-1)) or UDSF to new AMF: Nudsf_UnstructuredData Management_Query(). The old AMF may start implementation specific (protection) timers for the UE context.

[0402] In case the UDSF is queried at phase 4, the UDSF responds to the new AMF for Nudsf_Unstructured Data Management_Query call with the relevant context including the established PDU session, the old AMF includes the SMF information DNN, S-NSSAI and PDU session ID, the active NGAP UE-TNLA binding to the N3IWF / TNGF / W-AGF, and the old AMF includes information about the NGAP UE-TNLA binding. In case the old AMF is queried at phase 4, the old AMF responds to the new AMF for Namf_Communication_UEContextTransfer call by including the UE's SUPI and UE context.

[0403] In case the old AMF holds information about the established PDU session and it is not an initial registration, the old AMF includes SMF information, DNN, S-NSSAI and PDU session ID.

[0404] In the case where the old AMF maintains the UE context established via N3IWF, W-AGF or TNGF, the old AMF includes the CM state via N3IWF, W-AGF or TNGF. In the case where the UE is in CM-CONNECTED state via N3IWF, W-AGF or TNGF, the old AMF includes information about NGAP UE-TNLA binding.

[0405] In the case where the old AMF fails the integrity check of the Registration Request NAS message, the old AMF may indicate that the integrity check failed. In the case where the new AMF is configured to allow emergency services for unauthenticated UEs, the new AMF behaves as follows:

[0406] - In the case where the UE has only an emergency PDU session, the AMF skips the authentication and security procedures, or accepts that authentication may have failed and continues with the mobility registration update procedure; or

[0407] - In case the UE has both emergency and non-emergency PDU sessions and authentication fails, the AMF continues with the mobility registration update procedure and deactivates all non-emergency PDU sessions as specified in clause 4.3.4.2 of 3GPP TS 23.502.

[0408] Note 7: The new AMF can determine whether the PDU Session is used for emergency services by checking whether the DNN matches the emergency DNN.

[0409] In the case where the old AMF maintains information about AM policy associations and information about UE policy associations (i.e., a policy control request trigger for updating UE policy as defined in 3GPP TS 23.503), the old AMF includes information about AM policy associations, UE policy associations and PCF IDs. In the case of roaming, this includes V-PCF ID and H-PCF ID.

[0410] In the case where the old AMF is a consumer of UE-related NWDAF services, the old AMF includes information about active analysis subscriptions in the Namf_Communication_UEContextTransfer response, i.e., subscription correlation ID, NWDAF identifier (i.e., instance ID or set ID), analysis ID and associated analysis specific data. The use of analysis information by the new AMF is specified in 3GPP TS 23.288.

[0411] During inter-PLMN mobility, the handling of UE Radio Capability ID in the new AMF is as defined in 3GPP TS 23.501.

[0412] NOTE 8: When the new AMF uses UDSF for context retrieval, the interaction between the old AMF, new AMF and UDSF due to simultaneous UE signalling on the old AMF is an implementation specific issue.

[0413] Phase 6: [Conditional] New AMF to UE: Identity Request ().

[0414] In the case where the SUCI is not provided by the UE or retrieved from the old AMF, the Identity Request procedure is initiated by the AMF to transmit an Identity Request message to the UE requesting the SUCI.

[0415] Phase 7: [Conditional] UE to new AMF: Identity Response ().

[0416] The UE responds with an Identity Response message including the SUCI. The UE derives the SUCI by using the provided public key of the HPLMN as specified in 3GPP TS 33.501.

[0417] Phase 8: AMF may decide to initiate UE authentication by invoking AUSF. In this case, AMF selects AUSF based on SUPI or SUCI as described in clause 6.3.4 of 3GPP TS23.501.

[0418] In case the AMF is configured to support Emergency Registration for an unauthenticated SUPI and the UE indicates Registration Type Emergency Registration, the AMF skips authentication or the AMF accepts that authentication may have failed and continues with the registration procedure.

[0419] Phase 9a: In case authentication is required, the AMF requests authentication from the AUSF; in case tracking requirements about the UE are available at the AMF, the AMF provides the tracking requirements in its request to the AUSF. For disaster roaming registration, the AMF may provide an indication of disaster roaming services in its request to the AUSF. Based on the request from the AMF, the AUSF may perform authentication of the UE. Authentication is performed as described in 3GPP TS 33.501. The AUSF selects the UDM and obtains authentication data from the UDM as described in clause 6.3.8 of 3GPP TS23.501.

[0420] Upon receiving an indication from the AMF, the AUSF may provide an indication to the UDM regarding disaster roaming services. For disaster roaming registration, the AUSF performs authentication of the UE based on local policy and / or local configuration, as specified in clause 5.40.4 of 3GPP TS 23.501 and in 3GPP TS 33.501.

[0421] Once the UE has been authenticated, the AUSF provides the relevant security related information to the AMF. In the case where the AMF provides the SUCI to the AUSF, the AUSF may return the SUPI to the AMF only after successful authentication.

[0422] After successful authentication in the new AMF (which was triggered by the integrity check failure in the old AMF in stage 5), the new AMF invokes stage 4 above again and indicates that the UE is verified (i.e. via the cause parameter as specified in clause 5.2.2.2.2 of 3GPP TS 23.502).

[0423] Phase 9b: In case NAS security context does not exist, NAS security initiation may be performed as described in 3GPP TS 33.501. In case the UE does not have NAS security context at Phase 1, the UE includes a complete Registration Request message as defined in 3GPP TS 24.501.

[0424] The AMF decides whether the Registration Request needs to be re-routed as described in clause 4.2.2.2.3 of 3GPP TS 23.502, where the Initial AMF refers to this AMF.

[0425] Phase 9c: In the event that the 5G-AN has requested a UE context, the AMF initiates an NGAP procedure to provide a security context to the 5G-AN, as specified in 3GPP TS 38.413. In addition, in the event that the AMF decides to support EPS fallback (e.g., based on UE capabilities, subscription data and local policies that support the request type flag "handover" for PDN connectivity requests during the attach procedure as defined in clause 5.17.2.3.1 of 3GPP TS 38.413), the AMF may transmit an indication "Voice EPS fallback can be redirected" towards the 5G-AN, as specified in 3GPP TS23.501. Otherwise, the AMF indicates "Voice EPS fallback cannot be redirected". In addition, in the event that a tracing requirement regarding the UE is available at the AMF, the AMF provides the tracing requirement for the 5G-AN in the NGAP procedure.

[0426] Phase 9d: 5G-AN stores the security context and acknowledges it to AMF. 5G-AN uses the security context to protect messages exchanged with the UE as described in 3GPP TS 33.501.

[0427] Phase 10: [Conditional] New AMF to old AMF: Namf_Communication_RegistrationStatusUpdate (e.g. PDU Session ID released due to no support for slicing).

[0428] In case the AMF has changed, the new AMF notifies the old AMF that the UE's registration in the new AMF is complete by calling the Namf_Communication_RegistrationStatusUpdate service operation.

[0429] In case the authentication / security procedure fails, the registration may be rejected and the new AMF invokes a Namf_Communication_RegistrationStatusUpdate service operation with a reject indication towards the old AMF. The old AMF continues as if the UE Context Transfer service operation had never been received.

[0430] The new AMF determines that PDU Sessions cannot be supported in the new registration area in the following cases:

[0431] - In the case where one or more S-NSSAIs used in the old registration area cannot be served in the target registration area.

[0432] - When continuity of PDU sessions cannot be supported between networks (e.g. SNPN-SNPN mobility, inter-PLMN mobility where no HR agreement exists).

[0433] In the event that any of the conditions are met, the new AMF calls the Namf_Communication_RegistrationStatusUpdate service operation including the rejected PDU Session ID towards the old AMF. The new AMF then modifies the PDU Session status accordingly. The old AMF notifies the corresponding SMF to release the UE's SM context locally by calling the Nsmf_PDUSession_ReleaseSMContext service operation.

[0434] In the event that the new AMF receives information about AM policy association and UE policy association in the UE context delivery in stage 5 and decides based on local policy not to use the PCF identified by the PCF ID used for AM policy association and UE policy association, it will notify the old AMF that the AM policy association and UE policy association in the UE context are no longer used and then perform PCF selection in stage 15.

[0435] In case the new AMF receives information about the UE related analysis subscriptions in the UE context transfer in phase 5, the new AMF may take over the analysis subscriptions from the old AMF. Otherwise, in case the new AMF decides to create a new analysis subscription instead, it informs the old AMF of the no longer needed analysis subscriptions (identified by their subscription correlation IDs) and the old AMF may now unsubscribe the UE from those NWDAF analysis subscriptions according to 3GPP TS 23.288.

[0436] Phase 11: [Conditional] New AMF to UE: Identity Request / Response (PEI).

[0437] In the case where the PEI is not provided by the UE or is not retrieved from the old AMF, the Identity Request procedure is initiated by the AMF to transmit an Identity Request message to the UE to retrieve the PEI. The PEI may be delivered encrypted unless the UE performs an emergency registration and cannot be authenticated.

[0438] For emergency registration, the UE may have included the PEI in the Registration Request. If so, PEI retrieval is skipped.

[0439] In case the UE supports RACS as indicated in the UE MM Core Network Capabilities, the AMF may use the UE's PEI to obtain the IMEI / TAC for RACS operation purposes.

[0440] Phase 12: Optionally, the new AMF initiates the ME identity check by invoking the N5g-eir_EquipmentIdentityCheck_Get service operation (see clause 5.2.4.2.2 of 3GPP TS 23.502).

[0441] Perform a PEI check as described in clause 4.7 of 3GPP TS 23.502.

[0442] For emergency registration, in the event that PEI is blocked, operator policy determines whether the emergency registration process continues or stops.

[0443] Stage 13: In case stage 14 is to be performed, the new AMF selects the UDM based on the SUPI, and the UDM may then select the UDR instance. See clause 6.3.9 of 3GPP TS 23.501.

[0444] The AMF selects UDM as described in clause 6.3.8 of 3GPP TS 23.501.

[0445] Phase 14a-c: In case the AMF has changed since the last registration procedure, in case the UE Registration Type indicates Initial Registration or Emergency Registration, or in case the UE provides a SUPI that does not refer to a valid context in the AMF, or in case the UE registers to the same AMF that it has registered to a non-3GPP access (i.e. the UE is registered on a non-3GPP access and this Registration procedure is initiated to add a 3GPP access), the new AMF registers with the UDM using Nudm_UECM_Registration for the access to be registered (and subscribes to be notified when the UDM deregisters the AMF). According to 3GPP TS 23.122, the SoR information that the UDM can act on based on the "Registration Type" in the Nudm_UECM_Registration request. In this case, the AMF indicates this to the UDM in case the AMF does not have event exposure subscription information for this UE. Then, in case the UDM has an existing applicable event exposure subscription for an event detected in the AMF for this UE or for any group to which the UE belongs (possibly retrieved from the UDR), the UDM calls the Namf_EventExposure_Subscribe service to recreate the event exposure subscription.

[0446] The AMF provides the "Homogeneous support for IMS voice over PS sessions" indication to the UDM (see clause 5.16.3.3 of 3GPP TS23.501). The "Homogeneous support for IMS voice over PS sessions" indication may not be included unless the AMF has completed its evaluation of support for "IMS voice over PS sessions" as specified in clause 5.16.3.2 of 3GPP TS23.501.

[0447] During initial registration, in case the AMF and UE support SRVCC from NG-RAN to UTRAN, the AMF provides the UE SRVCC capability to the UDM.

[0448] In case the AMF determines that only the UE SRVCC capability has changed, the AMF transmits the UE SRVCC capability to the UDM.

[0449] Note 9: At this stage, the AMF may not have all the information needed to determine the setup of the indication of support for IMS voice over PS session for this UE (see clause 5.16.3.2 of 3GPP TS 23.501). Therefore, the AMF may transmit "Homogeneous support for IMS voice over PS session" later in the process.

[0450] After the AMF has successfully completed the Nudm_UECM_Registration operation, and in the case where the AMF does not have subscription data for the UE, the AMF uses Nudm_SDM_Get to retrieve access and mobility subscription data, SMF selection subscription data, UE context in SMF data, and LCS mobile station calling. In the case where the AMF already has subscription data for the UE, but the SoR update indicator in the UE context requires the AMF to retrieve SoR information according to the NAS registration type ("initial registration" or "emergency registration") (see Annex C of 3GPP TS23.122), the AMF uses Nudm_SDM_Get to retrieve roaming steering information. This requires the UDM to retrieve this information from the UDR via Nudr_DM_Query. After receiving a successful response, the AMF uses Nudm_SDM_Subscribe to subscribe to be notified when the requested data is modified, and the UDM can subscribe to the UDR via Nudr_DM_Subscribe. In the case where the GPSI is available in the UE subscription data, the GPSI is provided to the AMF in the access and mobility subscription data from the UDM. The UDM may provide an indication to the UE to update the subscription data for the network slice. In the case where the UE subscribes to MPS in the serving PLMN, the "MPS priority" will be included in the access and mobility subscription data provided to the AMF. In the case where the UE subscribes to MCX in the serving PLMN, the "MCX priority" will be included in the access and mobility subscription data provided to the AMF. The UDM also provides an indication of allowing IAB operation to the AMF as part of the access and mobility subscription data. The AMF may trigger the establishment of the UE context in the NG-RAN or the modification of the UE context in the NG-RAN (in the case of initial establishment in phase 9c), including an indication that the IAB node is authorized. In the case where the registration request transmitted in phase 1 is for NR satellite access and includes an authorization request for obtaining satellite coverage availability information, in phase 14b, the AMF retrieves subscription data for satellite coverage availability information from the UE's UDM in the UE's HPLMN using the Nudm_SDM_Get service operation.

[0451] For disaster roaming registration, AMF may provide an indication of disaster roaming services to UDM. UDM provides subscription data for disaster roaming services to AMF based on local policy and / or local configuration, as specified in clause 5.40.4 of 3GPP TS23.501.

[0452] In case the UE includes the MINT support indication in the 5GMM capabilities as specified in clause 5.40.2 of 3GPP TS 23.501, or in case the MINT support indication in the 5GMM capabilities changes, the AMF provides the MINT support indication to the UDM via Nudm_UECM_Registration.

[0453] In the case where the AMF receives a priority indication as part of the access and mobility subscription data (e.g. MPS, MCX), but the UE does not provide an establishment cause associated with a priority service, the AMF may include a message priority header to indicate the priority information for all subsequent messages. Other NFs relay the priority information by including a message priority header in the service-based interface, as specified in 3GPP TS 29.500.

[0454] The new AMF provides the UDM with the access type it serves for the UE, and the access type is set to "3GPP access". The UDM stores the associated access type with the serving AMF and does not remove the AMF identity associated with other access types (in some cases). The UDM can store the information provided during AMF registration in the UDR via Nudr_DM_Update.

[0455] In the case where the UE is registered for access in the old AMF and the old AMF and the new AMF are in the same PLMN, after the old AMF relocation is successfully completed, the new AMF transmits a separate / independent Nudm_UECM_Registration to update the UDM with the access type set to the access used in the old AMF.

[0456] The new AMF creates a UE context for the UE after obtaining the access and mobility subscription data from the UDM. The access and mobility subscription data includes whether the UE is allowed to include NSSAI in clear text in the 3GPP access RRC connection establishment. The access and mobility subscription data may include enhanced coverage restriction information. In the case where it is received from the UDM and the UE includes support for restricting the use of enhanced coverage in stage 1, the AMF determines whether enhanced coverage is restricted for the UE as specified in clause 5.31.12 of 3GPP TS23.501 and stores the updated enhanced coverage restriction information in the UE context.

[0457] Access and mobility subscription data may include NB-IoT UE priority.

[0458] The subscription data may include a service gap time parameter. In the case of receiving from the UDM, the AMF stores the service gap time in the UE context in the AMF for the UE.

[0459] For emergency registrations where the UE is not successfully authenticated, the AMF may not register with the UDM.

[0460] The AMF implements mobility restrictions as specified in clause 5.3.4.1.1 of 3GPP TS23.501. For emergency registration, the AMF may not check mobility restrictions, access restrictions, area restrictions or subscription restrictions. For emergency registration, the AMF may ignore any unsuccessful registration response from the UDM and continue the registration process.

[0461] NOTE 10: Instead of the Nudm_SDM_Get service operation, the AMF may use the Nudm_SDM_Subscribe service operation with an immediate reporting indication which triggers the UDM to return the subscribed data immediately if the corresponding feature is supported by both the AMF and the UDM.

[0462] Phase 14d: When the UDM stores the associated access type (e.g. 3GPP) with the serving AMF as indicated in phase 14a, this phase will cause the UDM to initiate a Nudm_UECM_DeregistrationNotification (see clause 5.2.3.2.2 of 3GPP TS23.502) to the old AMF (if present) corresponding to the same (e.g. 3GPP) access. In the event that the timer started in phase 5 is not running, the old AMF may remove the UE context of the same access type. Otherwise, when the timer expires, the AMF may remove the UE context of the same access type. In the event that the serving NF removal reason indicated by the UDM is initial registration, as described in clause 4.2.2.3.2 of 3GPP TS23.502, the old AMF invokes the Nsmf_PDUSession_ReleaseSMContext (SM Context ID) service operation towards all associated SMFs of the UE to notify the UE to deregister from the old AMF for the same access type. The SMF may release the PDU Session upon obtaining this notification.

[0463] In the case where the old AMF has established AM policy association and UE policy association with the PCF and the old AMF has not passed the PCF ID to the new AMF (for example, the new AMF is in a different PLMN), the old AMF performs the AMF-initiated policy association termination procedure as defined in clause 4.16.3.2 of 3GPP TS23.502 and the AMF-initiated UE policy association termination procedure as defined in clause 4.16.13.1 of 3GPP TS23.502. In addition, in the case where the old AMF passed the PCF ID in the UE context, but the new AMF notified in stage 10 that the AM policy association information and UE policy association information in the UE context will not be used, the old AMF performs the AMF-initiated policy association termination procedure as defined in clause 4.16.3.2 of 3GPP TS23.502 and the AMF-initiated UE policy association termination procedure as defined in clause 4.16.13.1 of 3GPP TS23.502.

[0464] In the case where the old AMF has an N2 connection for the UE (for example, because the UE was in RRC Inactive state but has now moved to E-UTRAN or moved to an area not served by the old AMF), the old AMF may perform AN release with a cause value indicating that the UE has locally released the RRC connection to the NG-RAN (see clause 4.2.6 of 3GPP TS 23.502).

[0465] In the case where the UE context in the old AMF contains an allowed NSSAI including one or more S-NSSAIs subject to NSAC, the old AMF, upon receiving Nudm_UECM_DeregistrationNotification from UDM, transmits an update request message for each S-NSSAI subject to NSAC to the corresponding NSACF, where the update flag parameter is set to reduce (see clause 4.2.11.2 of 3GPP TS 23.502).

[0466] At the end of the registration process, the AMF may initiate synchronization of the event exposure subscription with the UDM, provided that the AMF has not indicated in phase 14a that the event exposure subscription is unavailable.

[0467] NOTE 11: The AMF may initiate synchronization with the UDM even if events are available in the UE context at any given time (e.g. as received from the old AMF) and based on local policy. This may be done during subscription change related events.

[0468] Stage 14e: [Conditional] In case the old AMF does not have UE context for another access type (i.e. non-3GPP access), the old AMF uses Nudm_SDM_unsubscribe to unsubscribe the subscription data to the UDM.

[0469] Phase 15: In case AMF decides to initiate PCF communication, AMF operates as follows.

[0470] In the case where the new AMF decides to use the (V-)PCF identified by the (V-)PCF ID included in the UE context from the old AMF in stage 5, the AMF contacts the (V-)PCF identified by the (V-)PCF ID to obtain the policy. In the case where the AMF decides to perform PCF discovery and selection, the AMF selects the (V)-PCF and may select the H-PCF (for roaming scenarios) as described in clause 6.3.7.1 of 3GPP TS 23.502 and in accordance with the V-NRF to H-NRF interaction described in clause 4.3.2.2.3.3 of 3GPP TS 23.501.

[0471] Phase 16: [Optional] New AMF performs AM policy association establishment / modification. For emergency registration, this phase is skipped.

[0472] In the case that the new AMF selects a new (V-)PCF at stage 15, the new AMF performs an AM policy association establishment with the selected (V-)PCF as defined in clause 4.16.1.2 of 3GPP TS 23.502.

[0473] In case of using a (V-)PCF identified by the (V-)PCF ID included in the UE context from the old AMF, the new AMF performs an AM policy association modification with the (V-)PCF as defined in clause 4.16.2.1.2 of 3GPP TS 23.502.

[0474] In the case where the AMF notifies the PCF of mobility restrictions (e.g., UE location) for adjustment, or in the case where the PCF updates its own mobility restrictions due to some conditions (e.g., applications in use, time and date), the PCF may provide the updated mobility restrictions to the AMF. In the case where the subscription information includes tracking requirements, the AMF provides the tracking requirements to the PCF.

[0475] In case AMF supports DNN replacement, AMF provides the allowed NSSAI and the mapping of allowed NSSAI (where available) to PCF.

[0476] In the case where PCF supports DNN replacement, PCF provides a trigger for DNN replacement to AMF.

[0477] Phase 17: [Conditional] AMF to SMF: Nsmf_PDUSession_UpdateSMContext().

[0478] For emergency registered UEs (see 3GPP TS 23.501), this phase applies when the Registration Type is Mobility Registration Update.

[0479] The AMF calls Nsmf_PDUSession_UpdateSMContext (see clause 5.2.8.2.6 of 3GPP TS 23.502) in the following scenarios:

[0480] - In case the list of PDU sessions to be activated is included in the Registration Request of phase 1, the AMF transmits a Nsmf_PDUSession_UpdateSMContext request to the SMF associated with the PDU sessions in order to activate the user plane connection for these PDU sessions. The phases from phase 5 onwards as described in clause 4.2.3.2 of 3GPP TS 23.502 are performed to complete the user plane connection activation without transmitting RRC Inactive Assistance Information and without transmitting MM NAS Service Accept from the AMF to the (R)AN as described in phase 12 of clause 4.2.3.2 of 3GPP TS 23.502. The AS layer in the UE indicates to the NAS layer when the user plane connection for the PDU session is activated.

[0481] - In case the AMF has determined in Phase 3 that the UE is performing inter-RAT mobility to or from NB-IoT, the AMF transmits a Nsmf_PDUSession_UpdateSMContext request to the SMF associated with the UE PDU session, so that the SMF can update the UE PDU session according to the

[0482] "PDU Session Continuity at Inter-RAT Mobility" subscription data to update them. Perform the stages from stage 5 onwards as described in clause 4.2.3.2, rather than in 3GPP TS

[0483] The MM NAS Service Acceptance is transmitted from the AMF to the (R)AN as described in stage 12 of clause 4.2.3.2 of 23.502.

[0484] When the serving AMF has changed, the new serving AMF informs the SMF for each PDU Session that it has taken over the responsibility for the signalling path towards the UE: the new serving AMF calls the Nsmf_PDUSession_UpdateSMContext service operation using the SMF information received from the old AMF in stage 5. It also indicates whether the PDU Session is to be reactivated.

[0485] Note 12: In the case where the UE moves into a different PLMN, the AMF in the serving PLMN may insert or change the V-SMF in the serving PLMN for the home routed PDU session. In addition, in the case where the UE moves from a VPLMN to a HPLMN, the V-SMF is removed. In these cases, the same procedures described in clause 4.23.3 of 3GPP TS 23.502 are applied to the V-SMF change as for the I-SMF change (i.e., by replacing the I-SMF with the V-SMF). During inter-PLMN changes, session continuity may be supported depending on the operator policy in the case where the same SMF is used.

[0486] The stages from stage 5 onwards described in clause 4.2.3.2 of 3GPP TS23.502 are performed. In the case of an intermediate UPF insertion, removal or change for a PDU session not included in the "PDU session to be reactivated", the process is performed without N11 and N2 interaction to update the N3 user plane between the (R)AN and the 5GC.

[0487] The AMF invokes the Nsmf_PDUSession_ReleaseSMContext service operation towards the SMF in the following scenarios:

[0488] - In case any PDU Session status indicates that it is released at the UE, the AMF invokes the Nsmf_PDUSession_ReleaseSMContext service operation towards the SMF in order to release any network resources associated with the PDU Session.

[0489] In the case of a change of serving AMF, the new AMF may wait until all SMFs associated with the UE are completed by phase 18. Otherwise, phases 19 to 22 may continue in parallel with this phase.

[0490] Stage 18: [Conditional] In case the new AMF and the old AMF are in the same PLMN, the new AMF transmits a UE Context Modification Request to the N3IWF / TNGF / W-AGF as specified in 3GPP TS 29.413.

[0491] In case the AMF has changed and the old AMF has indicated by the N3IWF, W-AGF or TNGF that the UE is in CM-CONNECTED state, and in case the new AMF and the old AMF are in the same PLMN, the new AMF creates a NGAP UE association towards the N3IWF / TNGF / W-AGF to which the UE is connected. This automatically releases the existing NGAP UE association between the old AMF and the N3IWF / TNGF / W-AGF.

[0492] Phase 19: N3IWF / TNGF / W-AGF transmits UE Context Modification Response to the new AMF.

[0493] Phase 19a: [Conditional] After the new AMF receives a response message from the N3IWF, W-AGF or TNGF in phase 19, the new AMF registers with the UDM using Nudm_UECM_Registration as in phase 14a, but the access type is set to "Non-3GPP Access". The UDM stores the associated access type with the serving AMF and does not remove the AMF identity associated with other access types (if any). The UDM may store the information provided during AMF registration in the UDR via Nudr_DM_Update.

[0494] Phase 19b: [Conditional] When the UDM stores the associated access type (e.g. non-3GPP) with the serving AMF as indicated in phase 19a, this phase shall cause the UDM to initiate a Nudm_UECM_DeregistrationNotification (see clause 5.2.3.2.2 of 3GPP TS 23.502) to the old AMF corresponding to the same (e.g. non-3GPP) access. The old AMF removes the UE context for the non-3GPP access.

[0495] Phase 19c: The old AMF uses Nudm_SDM_unsubscribe to unsubscribe the subscription data from the UDM.

[0496] Phase 20a( Fig.16 Not shown in the figure): empty.

[0497] Phase 21: AMF returns NAS Registration Accept to UE (e.g. Fig. 8A 825 in ). The details are: New AMF to UE: Registration Accept (5G-GUTI, Registration Area, [Mobility Restrictions], [PDU Session State], [Allowed NSSAI], [Mapping of Allowed NSSAI], [Configured NSSAI for Serving PLMN], [Mapping of Configured NSSAI], [NSSRG Information], [NSAG Information], [Rejected S-NSSAI], [Pending NSSAI], [Mapping of Pending NSSAI], [Periodic Registration Update Timer], [Active Time], [Strict Periodic Registration Timer Indication], [LADN Information], [Accepted MICO Mode], [Indication of Support for IMS Voice over PS Session] ], [Emergency Services Support Indicator], [Accepted DRX parameters for E-UTRA and NR], [Accepted DRX parameters for NB-IoT], [Extended Idle Mode DRX parameters], [Paging Time Window], [Interworking Network Support without N26], [Access Stratum Connection Establishment NSSAI Including Mode], [Network Slice Subscription Change Indication], [Operator Defined Access Class Definition], [List of Equivalent PLMNs], [Enhanced Coverage Limited Information], [Supported Network Behaviors], [Service Gap Time], [PLMN Assigned UE Radio Capability ID], [PLMN Assigned UE Radio Capability ID Removal], [WUS Assistance Information], [AMF [PEIPS assistance information], [truncated 5G-S-TMSI configuration], [support connection release], [support paging cause indication for voice service], [support paging restriction], [support rejection of paging request], [paging restriction information acceptance / rejection], ["list of PLMNs to be used in disaster conditions"], [disaster roaming waiting range information], [disaster return waiting range information], [prohibited TAI], [list of equivalent SNPN], [registered NID], [support unavailable period], [authorization for obtaining satellite coverage availability information]). The authorization for obtaining satellite coverage availability information included in the NAS Registration Accept may correspond to the authorization for obtaining satellite coverage availability information for the NAS Registration Accept. Fig. 8A The authorization data described in 820 and 825.

[0498] In case the requested NSSAI does not include an S-NSSAI mapped to the S-NSSAI of the HPLMN subject to network slice specific authentication and authorization, and the AMF determines that the S-NSSAI cannot be provided among the allowed NSSAIs of the UE in the tracking area of ​​the current UE, and in case a default S-NSSAI that has not been involved in the current UE registration process cannot be further considered, the AMF may reject the UE registration and may include a list of rejected S-NSSAIs in the rejection message, each of them with an appropriate rejection cause value.

[0499] The allowed NSSAI for the UE's access type is included in the N2 message carrying the Registration Accept message. The allowed NSSAI contains only the S-NSSAIs that do not require network slice specific authentication and authorization based on the subscription information, and those S-NSSAIs for which network slice specific authentication and authorization have previously succeeded based on the UE context in the AMF, regardless of the access type. The mapping of pending NSSAIs is a mapping of each S-NSSAI in the pending NSSAI for the serving PLMN to the HPLMN S-NSSAI.

[0500] In case the UE has indicated its support for network slice specific authentication and authorization procedures in the UE MM Core Network Capabilities in the Registration Request, the AMF includes in the pending NSSAI the S-NSSAI mapped to the S-NSSAI of the HPLMN (which has an indication in the subscription information that it is subject to network slice specific authentication and authorization) as described in clause 4.6.2.4 of 3GPP TS 24.501. In this case, the AMF may then trigger the network slice specific authentication and authorization procedures specified in clause 4.2.9.2 of 3GPP TS 23.502 at stage 25, except that, based on network policy, for those S-NSSAIs, network slice specific authentication and authorization has already been initiated on another access type for the same S-NSSAI. The UE may not attempt to re-register with the S-NSSAI included in the pending NSSAI list until the network slice specific authentication and authorization procedures have been completed, regardless of the access type.

[0501] In case the UE does not indicate its support for network slice specific authentication and authorization procedures in the UE 5GMM Core Network Capabilities in the Registration Request, and the requested NSSAI includes S-NSSAIs that map to HPLMN S-NSSAIs that are subject to network slice specific authentication and authorization, the AMF may include those S-NSSAIs in the requested NSSAIs among the rejected S-NSSAIs.

[0502] In the case where S-NSSAI cannot be provided in the allowed NSSAI because:

[0503] - All S-NSSAIs in the requested NSSAI will be subject to network slice specific authentication and authorization;

[0504] or

[0505] - The requested NSSAI is not provided, or no S-NSSAI in the requested NSSAI matches any subscribed S-NSSAI, and all S-NSSAIs marked as default in the subscribed S-NSSAI will be subject to network slice specific authentication and authorization.

[0506] The AMF may provide an empty Allowed NSSAI. When receiving an empty Allowed NSSAI and a pending NSSAI, the UE registers in the PLMN but may wait for completion of the network slice specific authentication and authorization procedures without attempting to use any services provided by the PLMN on any access, except for example emergency services (see 3GPP TS24.501), until the UE receives the Allowed NSSAI.

[0507] The AMF stores the NB-IoT priority retrieved in stage 14 and associates it with the 5G-S-TMSI assigned to the UE.

[0508] In the event that the Registration Request message received over the 3GPP access does not include any paging restriction information, the AMF may delete any stored paging restriction information for the UE and stop restricting paging accordingly.

[0509] In the case where the registration request message received via 3GPP access includes paging restriction information, the AMF may accept or reject the paging restriction information requested by the UE based on the operator policy. In the case where the AMF rejects the paging restriction information, the AMF removes any stored paging restriction information from the UE context and discards the paging restriction information requested by the UE. In the case where the AMF accepts the paging restriction information from the UE, the AMF stores the paging restriction information from the UE in the UE context and notifies the UE of the acceptance / rejection of the requested paging restriction information in the registration accept message.

[0510] In the event that the registration request message received via the 3GPP access includes a release request indication, then:

[0511] - The AMF updates the UE context with any received paging restriction information and then implements it in the network triggered service request procedure as described in clause 4.2.3.3 of 3GPP TS 23.502;

[0512] -After the registration process is completed, the AMF does not establish user plane resources and trigger 3GPP TS

[0513] The AN release process described in clause 4.2.6 of 23.502.

[0514] The AMF transmits a Registration Accept message to the UE indicating that the registration request has been accepted. In the case where the AMF allocates a new 5G-GUTI, the 5G-GUTI is included. When a Registration Request message of type "Initial Registration", "Mobility Registration Update", "Disaster Roaming Initial Registration" or "Disaster Roaming Mobility Registration Update" is received from the UE, the AMF may include the new 5G-GUTI in the Registration Accept message. When a Registration Request message of type "Periodic Registration Update" is received from the UE, the AMF shall include the new 5G-GUTI in the Registration Accept message. In the case where the UE is already in the RM-REGISTERED state via another access in the same PLMN, the UE may use the 5G-GUTI received in the Registration Accept for two registrations. In the case where the 5G-GUTI is not included in the Registration Accept, the UE shall also use the 5G-GUTI assigned for the existing registration for the new registration. In the case where the AMF allocates a new registration area, it may transmit the registration area to the UE via the Registration Accept message. For disaster roaming registration, the AMF allocates a registration area limited to areas with disaster conditions as specified in clause 5.40 of 3GPP TS23.501. In the event that the registration area is not included in the registration accept message, the UE may regard the old registration area as valid. In the event that mobility restrictions are applied to the UE and the registration type is not an emergency registration, mobility restrictions are included. The AMF indicates the established PDU session to the UE in the PDU session state. The UE locally removes any internal resources related to the PDU session that is not marked as established in the received PDU session state. In the event that the AMF calls the Nsmf_PDUSession_UpdateSMContext procedure for UP activation of the PDU session in stage 18 and receives a rejection from the SMF, the AMF indicates to the UE the PDU session ID and the reason why the user plane resources are not activated. When the UE is connected to two AMFs belonging to different PLMNs via 3GPP access and non-3GPP access, the UE locally removes any internal resources related to the PDU session that is not marked as established in the received PDU session state in the current PLMN. In case the PDU session status information is in the registration request, the AMF may indicate the PDU session status to the UE.

[0515] In the case where the RAT type is NB-IoT and the network is configured to use the Control Plane Relocation Indication procedure, the AMF may include in the Registration Accept message a truncated 5G-S-TMSI configuration used by the UE optimized using the control plane CIoT 5GS to create a truncated 5G-S-TMSI, see clause 5.31.4.3 of 3GPP TS23.501.

[0516] The allowed NSSAI provided in the Registration Accept is valid in the Registration Area and it applies to all PLMNs that have the tracking area of ​​the PLMN included in the Registration Area. The mapping of the allowed NSSAI is a mapping of each S-NSSAI in the allowed NSSAI to the HPLMN S-NSSAI. The mapping of the configured NSSAI is a mapping of each S-NSSAI in the configured NSSAI for the serving PLMN to the HPLMN S-NSSAI.

[0517] In case the UE has indicated in the UE 5GMM Core Network Capabilities its support for the subscription-based restriction of simultaneously registered network slices feature, the AMF includes (where available) the NSSRG information defined in clause 5.15.12 of 3GPP TS 23.501.

[0518] In the case where the UE has not indicated its support for subscription-based restriction of simultaneous registration of network slices feature and the subscription information for the UE includes NSSRG information and the AMF is providing the configured NSSAI to the UE, the configured NSSAI may include S-NSSAI in accordance with clause 5.15.12 of 3GPP TS 23.501.

[0519] In case the UE has indicated its support for the NSAG feature in the 5G MM Core Network Capabilities, the AMF includes (where available) the NSAG information defined in clause 5.15.14 of 3GPP TS 23.501.

[0520] The AMF may include in the Registration Accept message the LADN information of the list of LADNs available within the registration area determined by the AMF for the UE as described in clause 5.6.5 of 3GPP TS23.501. The AMF may include the operator-defined access class definition to let the UE determine the applicable operator-specific access class definition as described in 3GPP TS24.501.

[0521] In the case where the UE includes MICO mode in the Registration Request, the AMF responds in the Registration Accept message whether the MICO mode should be used. When the UE allows MICO mode, the AMF may include an active time value and / or a strict periodic registration timer indication in the Registration Accept message. The AMF determines the periodic registration update timer value, the active time value and the strict periodic registration timer indication based on local configuration, expected UE behavior (where available), UE indicated preferences, UE capabilities, UE subscription information and network policies or any combination thereof to achieve UE power saving, as described in clause 5.31.7 of 3GPP TS 23.501. In the case where the UE indicates its capability of strict periodic registration timer indication in the Registration Request message, the AMF determines to apply the strict periodic registration timer indication to the UE as described in stage 1. In the case where the AMF provides the UE with a periodic registration update timer value with a strict periodic registration timer indication, the UE and the AMF start the periodic registration update timer after this stage, as described in clause 5.31.7.5 of 3GPP TS23.501.

[0522] In case of registration on 3GPP access, the AMF sets the indication of support for IMS Voice over PS session as described in clause 5.16.3.2 of 3GPP TS 23.501. In order to set the indication o...

Claims

1. A method performed by a user equipment (UE) for obtaining coverage data to assist the UE in wireless access to a serving public land mobile network (PLMN), the method comprising: Accessing the serving PLMN; Get the server's address and authorization data; transmitting a request to the server based on the address, the request including the authorization data; as well as receiving the coverage data from the server based on verification by the server of the authorization data, wherein the coverage data enables the UE to determine whether access to the serving PLMN via one or more satellites is possible under the following circumstances: At one or more locations in a geographic area, At one or more future times, using one or more radio access technologies (RATs), or For some combination of these items.

2. The method of claim 1, wherein the coverage data comprises a spatial coverage map indicating whether the access to the serving PLMN is possible at the one or more locations in a geographic area, the one or more locations comprising a plurality of locations on a grid. 3 . The method of claim 2 , wherein the spatial coverage map comprises a heat map indicating signal power levels, signal quality levels, or both at the one or more locations.

4. The method according to claim 2, wherein: To indicate whether the access to the serving PLMN is possible at the one or more locations, the spatial coverage map comprises a plurality of grid points, wherein each grid point of the plurality of grid points is associated with a Boolean coverage availability indication or a digital signal power indication.

5. The method of claim 1, wherein the coverage data comprises a time coverage map indicating whether the access to the serving PLMN is possible at the one or more future times.

6. The method of claim 1 , wherein the coverage data is specific to one or more parameters related to the UE, the one or more parameters comprising: UE type; Antenna receive (Rx) gain or loss; overall antenna signal gain or loss; one or more minimum signal reception levels of power, quality, or both supported by the UE; or Some combination of these items.

7. The method of claim 1, wherein the coverage data comprises a temporal coverage map indicating: (i) one or more durations for which said access to said serving PLMN is likely to occur; (ii) one or more durations during which said access to said serving PLMN is not possible, or Any combination of them.

8. The method of claim 1, wherein the authorization data comprises a temporary identifier of the UE.

9. The method of claim 8, wherein the temporary identifier enables verification of the authorization data by the server.

10. The method of claim 9, wherein the temporary identifier comprises an encryption of an identifier, wherein the identifier is configured in the serving PLMN and the server, wherein the encryption is based on an encryption key configured in the serving PLMN and the server.

11. The method of claim 1 , wherein the UE obtains the address and the authorization data from a Universal Subscriber Identity Module (USIM) on the UE, or by transmitting a Non-Access Stratum (NAS) request to an entity in the serving PLMN, or by assembling a standardized address and standardized authorization data.

12. The method of claim 11, wherein the NAS request indicates at least one of: a location of the coverage data, an area of ​​the coverage data, a relevant time or time period of the coverage data, a relevant RAT of the coverage data, a relevant PLMN of the coverage data, a supported method or encoding for receiving the coverage data from the server, or any combination thereof.

13. The method of claim 12, wherein the authorization data indicates at least one of: the location of the coverage data, the area of ​​the coverage data, the relevant time or time period of the coverage data, the relevant RAT of the coverage data, the relevant PLMN of the coverage data, the supported method or encoding for receiving the coverage data from the server, or any combination thereof, wherein the authorization data is not interpreted by the UE.

14. A method performed by a server for providing coverage data to a user equipment (UE) to assist the UE in wireless access to a serving public land mobile network (PLMN), the method comprising: receiving a request for coverage data from the UE, the request being transmitted by the UE to the address of the server, the request comprising authorization data for the UE, the authorization data being provided to the UE by an entity in the serving PLMN; verifying the authorization data; as well as The coverage data is transmitted to the UE based on the verification of the authorization data.

15. The method of claim 14, wherein the coverage data enables the UE to determine whether access to the serving PLMN is possible at one or more locations of the UE, at one or more future times, using one or more radio access technologies (RATs), or for some combination of these items.

16. The method of claim 15, wherein the serving PLMN has discontinuous satellite coverage, wherein the coverage data comprises coverage data for one or more satellite RATs.

17. A method according to claim 15, wherein the coverage data includes a spatial coverage map indicating whether the access to the serving PLMN is possible at the one or more locations of the UE, the one or more locations including multiple locations on a grid, and the coverage data includes multiple of the spatial coverage maps for each of the one or more future times.

18. A method according to claim 15, wherein the coverage data includes a time coverage map indicating whether the access to the serving PLMN is possible at the one or more future times, and the coverage data includes a plurality of the time coverage maps for each of the one or more locations of the UE.

19. A method according to claim 15, wherein the coverage data includes a time coverage map indicating the following items: (i) one or more time durations during which the access to the serving PLMN is possible, (ii) one or more time durations during which the access to the serving PLMN is not possible, or any combination thereof, wherein the coverage data includes a plurality of the time coverage maps for each of the one or more locations of the UE.

20. The method of claim 14, wherein the authorization data comprises: a temporary identifier of the UE, wherein the temporary identifier is known to the server, said address of said server, or Both of these.

21. The method of claim 20, wherein: The authorization data comprises the temporary identifier of the UE and the address of the server, and the temporary identifier of the UE is a part of the address of the server; The temporary identifier is a reserved value configured in the entity in the serving PLMN and in the server; or The temporary identifier is encrypted, wherein the server decrypts the temporary identifier, wherein the encryption and decryption are based on an encryption key configured in the entity in the serving PLMN and in the server.

22. The method of claim 21, wherein the temporary identifier is encrypted, and wherein the method further comprises obtaining a set of identifiers used to generate temporary identifiers by the entity in the serving PLMN, wherein verifying the authorization data comprises: decrypting the temporary identifier using the encryption key to produce an identifier; as well as Verify that the identifier is in the set of identifiers.

23. A user equipment (UE) for obtaining coverage data to assist the UE in wireless access to a serving public land mobile network (PLMN), the UE comprising: one or more transceivers; one or more memories; as well as one or more processors communicatively coupled to the one or more transceivers and the one or more memories, wherein the one or more processors are configured to: Accessing the serving PLMN; Get the server's address and authorization data; transmitting, via the one or more transceivers, a request to the server based on the address, the request including the authorization data; as well as receiving, via the one or more transceivers, the coverage data from the server based on verification by the server of the authorization data, wherein the coverage data enables the UE to determine whether access to the serving PLMN via one or more satellites is possible under the following circumstances: At one or more locations in a geographic area, At one or more future times, using one or more radio access technologies (RATs), or Some combination of these items.

24. The UE according to claim 23, wherein: To receive the coverage data, the one or more processors are configured to receive a spatial coverage map indicating whether the access to the serving PLMN is possible at the one or more locations in a geographic area, the one or more locations comprising a plurality of locations on a grid.

25. The UE according to claim 23, wherein: To receive the coverage data, the one or more processors are configured to receive a time coverage map indicating whether the access to the serving PLMN is possible at the one or more future times.

26. The UE according to claim 23, wherein: To receive the coverage data, the one or more processors are configured to receive a temporal coverage map indicating: (i) one or more durations for which said access to said serving PLMN is likely to occur; (ii) one or more durations during which said access to said serving PLMN is not possible, or Any combination of them.

27. A server for providing coverage data to a user equipment (UE) to assist the UE in wireless access to a serving public land mobile network (PLMN), the server comprising: one or more transceivers; one or more memories; as well as one or more processors communicatively coupled to the one or more transceivers and the one or more memories, wherein the one or more processors are configured to: receiving a request for coverage data from the UE, the request being transmitted by the UE to the address of the server, the request comprising authorization data for the UE, the authorization data being provided to the UE by an entity in the serving PLMN; verifying the authorization data; as well as The coverage data is transmitted to the UE based on the verification of the authorization data.

28. A server according to claim 27, wherein the one or more processors are configured to configure the coverage data so that the coverage data enables the UE to determine whether access to the serving PLMN is possible at one or more locations of the UE, at one or more future times, using one or more radio access technologies (RATs), or for some combination of these items.

29. A server according to claim 28, wherein the one or more processors are configured to include in the coverage data a spatial coverage map indicating whether the access to the serving PLMN is possible at the one or more locations of the UE, the one or more locations comprising a plurality of locations on a grid, and the coverage data comprising a plurality of the spatial coverage maps for each of the one or more future times.

30. A server according to claim 28, wherein the one or more processors are configured to include in the coverage data a time coverage map indicating whether the access to the serving PLMN is possible at the one or more future times, and the coverage data includes a plurality of the time coverage maps for each of the one or more locations of the UE.

Images