Coarse location information reporting for an internet of things user equipment (UE)

Abstract

This disclosure provides systems, methods, and apparatuses for managing coarse location reporting for a UE (102). In some aspects, a core network (110) can control whether to enable coarse location reporting based on a variety of considerations, such as UE type (e.g., an Internet of things (IoT) UE), UE capability, subscription information, user consent, geographic location, regulatory requirements, or radio access technology (RAT) type (e.g., narrowband IoT satellite), among other examples.

Description

COARSE LOCATION INFORMATION REPORTING FOR AN INTERNET OFTHINGS USER EQUIPMENT (UE)CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This Patent Application claims benefit of priority to U.S. Provisional Patent Application No. 63 / 620,762, filed January 12. 2024, and U.S. Provisional Patent Application No. 63 / 618,281, filed January 5, 2024, both entitled "LOCATION INFORMATION REPORTING FOR NARROWBAND INTERNET OF THINGS” and assigned to the assignee hereof, the disclosures of which are incorporated by reference in this Patent Application.TECHNICAL FIELD

[0002] This disclosure relates generally to wireless communication and some aspects relate to managing coarse location reporting for an internet-of-things (loT) user equipment (UE), such as a narrowband loT UE (NB-IoT UE).BACKGROUND

[0003] This background description is provided for the purpose of generally presenting the context of the disclosure. Work of the presently named inventors, to the extent it is described in this background section, as well as aspects of the description that may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present disclosure.

[0004] A wireless communication system includes one or more network entities (such as a base station) enabling communication for a mobile communication device (referred to as a user equipment (UE)). Each base station operates one or more cells to provide wireless signal coverage for the UE. Existing wireless communication systems rely primarily on legacy terrestrial networks. However, the 3rd Generation Partnership Project (3GPP) organization has proposed to extend 5th generation (5G) communications to non-terrestrial networks (NTNs) with 5G new radio (NR) technologies, or with the Long-Term-Evolution (LTE) technologies tailored for the Narrowband intemet-of-things (NB-IoT) or the enhanced Machine Type Communication (eMTC) scenarios. A non-terrestrial network (NTN) refers to a network, or segment of networks, using radio frequency (RF) resources on board an NTN node, such as a satellite, uncrewed aircraft system (UAS), or high altitude platform (HAP). An NTN node can include a spaceborne vehicle (such as a satellite) or an airborne vehicle (such as UAS or airplane). For simplicity', the discussion below refers to all such apparatus as satellites. In addition to satellites, an NTN can include the sat-gateways that connectsatellites to a public data network, feeder links between sat-gateways and satellites, service links between satellites and UEs, and inter-satellite links (ISL) when satellites form constellations.

[0005] According to the 3GPP specifications, a core network can obtain location information for some types of UEs and radio access technologies (RATs). Current and proposed mechanisms for UE location reporting are not well adapted for certain UEs that might potentially access an NTN at a variety of different geographic areas having different regulatory and privacy requirements.BRIEF SUMMARY

[0006] The systems, methods, and apparatuses of this disclosure each have several innovative aspects, no single one of which is solely responsible for the desirable attributes disclosed herein.

[0007] One innovative aspect of the subject matter described in this disclosure can be implemented as a method by a first network entity of a core network of a wireless communication system. The method includes the first network entity receiving a registration request for a user equipment (UE) requesting access to the core network via a narrowband internet-of-things non -terrestrial network (NB-IoT NTN) radio access network (RAN). The method includes the first network entity obtaining UE-specific parameters that indicate whether coarse location reporting is allowed for the UE, provisioning the coarse location reporting associated with the UE based on the UE-specific parameters. The method includes the first network entity receiving location information for the UE based on the coarse location reporting.

[0008] Another innovative aspect of the subject matter described in this disclosure can be implemented as a method by a UE. The method includes the UE transmitting a registration request to a core network via a NB-IoT NTN RAN. The method includes the UE receiving an allowed location reporting indication from the NB-IoT NTN RAN or the core network, where allowed location reporting indication provisions coarse location reporting. The method includes the UE transmitting location information for the UE based on the coarse location reporting.

[0009] Another innovative aspect of the subject matter described in this disclosure can be implemented as a method by a network element of an NB-IoT NTN RAN. The method includes the NB-IoT NTN RAN receiving an allowed location reporting indication from the core network, where allowed location reporting indication causes the NB-IoT NTN RAN toprovision coarse location reporting for a UE. The method includes the NB-IoT NTN RAN transmitting location information for the UE based on the coarse location reporting.

[0010] Another innovative aspect of the subject matter described in this disclosure can be implemented as a method of an Access and Mobility Management Function (AMF) or a Mobility Management Entity (MME) of a wireless communication system. The method includes the AMF / MME receiving, from a UE, a request message requesting access to a core network via a RAN node of the wireless communication system. The method includes the AMF / MME obtaining an allowed location reporting indication that enables coarse location reporting for the UE based on at least one of the UE being an loT UE, UE capability, user consent, or a radio access technology (RAT) of the RAN node. The method includes the AMF / MME causing the RAN node to provision the coarse location reporting associated with the UE based on the allowed location reporting indication.

[0011] Another innovative aspect of the subject matter described in this disclosure can be implemented as a method a RAN node of a wireless communication system. The method includes the RAN node receiving, from a UE, a request message requesting access to a core network via the RAN node. The method includes the RAN node transmitting the request message to the core network. The method includes the RAN node receiving a location reporting control message that triggers coarse location reporting for the UE based on at least one of the UE being an loT UE, UE capability , user consent, or a radio access technology' (RAT) of the RAN node. The method includes the RAN node providing coarse location information of the UE to the core network.

[0012] Another innovative aspect of the subject matter described in this disclosure can be implemented as an apparatus that includes a communication unit and a processing system configured to control the communication unit to implement any one of the above-referenced methods.

[0013] Details of one or more implementations of the subject matter described in this disclosure are set forth in the accompanying drawings and the description below. Other features, aspects, and advantages will become apparent from the description, the drawings, and the claims.BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Like reference numbers and designations in the various drawings indicate like elements. Note that the relative dimensions of the figures may not be drawn to scale. To easily identify the discussion of any particular element or act, the most significant digit ordigits in a reference number refer to the figure number in which that element is first introduced.

[0015] FIG. 1 is an example wireless communication system in which a core network (CN) manages coarse location reporting by an internet of things user equipment (loT UE) accessing a non-terrestrial network (NTN).

[0016] FIG. 2A illustrates a block diagram of an example wireless communication system implementing an NTN base station (BS) connecting to a satellite via an NTN gateway using a transparent payload implementation.

[0017] FIG. 2B illustrates a block diagram of an example wireless communication system implementing an NTN BS with feeder links to multiple satellites.

[0018] FIG. 2C illustrates a block diagram of an example wireless communication system implementing an NTN BS onboard on a satellite using a regenerative payload implementation.

[0019] FIG. 3A illustrates an example control plane protocol stack in which the example wireless communication system of FIG. 1 is a 5th generation system (5GS).

[0020] FIG. 3B illustrates an example control plane protocol stack in which the example wireless communication system of FIG. 1 is a 4th generation system evolved packet system (EPS).

[0021] FIG. 4 is a message flow diagram illustrating example operations for provisioning coarse location reporting based on UE-specific parameters and other considerations.

[0022] FIG. 5 is a flow chart diagram with example operations for a network entity, such as a Unified Data Management (UDM) or a Home Subscriber Server (HSS).

[0023] FIG. 6 illustrates example criteria for a core network considering whether to enable coarse location reporting for an loT UE.

[0024] FIG. 7 is a message flow diagram showing example options for enabling coarse location reporting.

[0025] FIG. 8 is a message flow diagram showing example operations for a core network to update an loT UE configuration for coarse location reporting.

[0026] FIG. 9 is a message flow diagram showing example operations using a Radio Resource Control (RRC) protocol to coordinate coarse location reporting in which the loT UE provides UE capability information via the RRC protocol.

[0027] FIG. 10A is a message flow diagram in which the loT UE provides UE capabilityinformation via a Non-Access Stratum (NAS) message and the coarse location reporting is accomplished using RRC messaging.

[0028] FIG. 10B is a message flow diagram showing an option of FIG. 10A in which the radio access network informs the loT UE regarding the coarse location reporting via an RRC message.

[0029] FIG. 11 is a message flow diagram illustrating example operations for provisioning coarse location reporting using NAS layer messaging while the UE location reporting is done at the RRC layer.

[0030] FIG. 12A is a message flow diagram illustrating example operations in which coarse location reporting provisioning and reporting are both performed using NAS layer.

[0031] FIG. 12B is a message flow diagram illustrating example operations for updating an loT UE configuration to enable coarse location reporting at the NAS layer after a network registration.

[0032] FIG. 13A is a message flow diagram illustrating example operations for provisioning coarse location reporting using the NAS layer based on UE capability information obtained at the RRC layer.

[0033] FIG. 13B is a message flow diagram combining aspects of the loT UE provisioning as described with reference to FIG. 12B with the UE capability information being updated at the RRC layer as described with reference to FIG. 13 A.

[0034] FIG. 14 is a block diagram of an example wireless communication system showing hardware features and communication interfaces.

[0035] FIG. 15A is a first part of a message flow diagram illustrating an example attach procedure in an example wireless communication system.

[0036] FIG. 15B is a second part of the message flow diagram of Fig. 15 A.

[0037] FIG. 16 is a message flow diagram illustrating an example Location Reporting procedure in an example wireless communication system.DETAILED DESCRIPTION

[0038] The following description is directed to certain implementations for the purpose of describing innovative aspects of this disclosure. However, a person having ordinary skill in the art will readily recognize that the teachings herein can be applied in a multitude of different ways. Some of the examples in this disclosure are based on wireless communicationaccording to the 3rd Generation Partnership Project (3GPP) wireless standards, such as the 4th generation (4G) Long Term Evolution (LTE) and 5th generation (5G) New Radio (NR) standards. However, the described implementations can be implemented in any device, system, or network that is capable of transmitting and receiving radio frequency signals according to any of the wireless communication standards, including any of the Institute of Electrical and Electronics Engineers (IEEE) 802.11 or 802.16 wireless standards, or other known signals that are used to communicate within a wireless, cellular, or internet of things (loT) network, such as a system utilizing 4G, 5G, WiFi, or future radio technology.

[0039] A core network of a wireless communication system can use location information to determine whether a particular user equipment (UE) should access a particular radio access technology (RAT) of a radio access network (RAN) and a data network. In some implementations, a RAN node can provide coarse location information for certain types of UE. One type of UE is referred to as a narrowband loT user equipment (NB-IoT UE). The RAT types of NBIOT, NB IOT LEO, NB IOT MEO, NB IOT GEO, and NB IOT OTHERSAT (as specified by 3GPP technical specification (TS) 29.571, version 18.4.0, section 5.4.3.2) are tailored for low-power, low-throughput applications such as loT device applications. Due to limited bandwidth and privacy concerns, the 3GPP specifications currently do not require, or even enable, an NB-IoT UE to report location information. NB- loT UEs are expected to increasingly use NB-IoT with satellite access (also referred to as NB-IoT non-terrestrial network (NTN), which contemplate low earth orbit (LEO), medium earth orbit (MEO), geostationary earth orbit (GEO), and other satellite access types as enumerated by the RAT types of NB IOT LEO. NB IOT MEO, NB IOT GEO, and NB IOT OTHERSAT). It would be advantageous for the core network to obtain at least coarse location information about the NB-IoT UE to determine, for example, whether or not the NB-IoT UE is allowed to access the NB-IoT NTN from the NB-IoT UE's current location. Although examples refer to NB-IoT UEs, the examples can also refer to other types of UEs (including other types of loT UEs or non-IoT UEs).

[0040] This disclosure provides systems, methods and apparatuses for managing coarse location reporting for a UE (such as a NB-IoT UE). In some aspects, a core network can control whether to enable the coarse location reporting based on a variety of considerations (referred to as UE-specific parameters), such as UE capability, subscription information, user consent, geographic location, regulatory7requirements, or radio access technology (RAT) type, among other examples. A control plane network element of the core network such as an Access and Mobility7Management Function (AMF) (in a 5G system) or MobilityManagement Entity (MME) (in a 4G system) can obtain UE-specific parameters. In some aspects, the AMF / MME obtains some or all of the UE-specific parameters from another core network element, such as a Unified Data Management (UDM) entity (in a 5G system) or a Home Subscriber Server (HSS) (in a 4G system). In some aspects, the AMF / MME can obtain some or all of the UE-specific parameters from the UE or from a network node of the radio access network (RAN). Based on the UE-specific parameters, the AMF / MME can determine whether to enable coarse location reporting for the UE. The AMF / MME can send an indication (referred to as an "allowed location reporting indication") to either the RAN, the UE, or both, to enable (or disable) the coarse location reporting. In some aspects, the allowed location reporting indication can indicate whether a UE is allowed for coarse location reporting which can be based on user consent, restriction from operator and regulator.

[0041] In some aspects, the core network coordinates with the RAN to enable coarse location reporting such that the location reporting is implemented using Radio Resource Control (RRC) messaging between the UE and the RAN. A potential technical advantage of using the RRC layer to implement location reporting is that coarse location reporting policies can be implemented within a geographic area or for particular NB-IoT NTNs based on regulatory requirements. Alternatively, or additionally, the coarse location reporting can be implemented using non-access stratum (NAS) layer messaging. This disclosure includes several options for implementing (or restricting / limiting) coarse location reporting based on core network considerations when using either RRC or NAS layer messaging.

[0042] For brevity, the examples in this disclosure refer to 5G system elements such as the AMF and the UDM. However, it should be apparent that the same techniques can be implemented in a 4G system using similar network elements, such as the MME and the HSS, respectively. Similarly, the techniques can be implemented in a 6th generation (6G) or beyond using any network elements (or combinations of network elements) that perform the same or similar functions as the AMF and the UDM. Unless otherwise noted, references to a “UE” in this disclosure can be relevant to any type of UE, and in some instances can be specific to a UE that implements a particular RAT (e g., an NB-IoT UE).

[0043] Based on 3GPP technical specification (TS) 36.331 and TS 38.331 , some types of UEs (specifically enhanced Machine Type Communication (eMTC) and NR UEs) can provide UE Coarse Location using RRC messaging. An RRC message can include a “coarseLocationlnfo” field. This field indicates the coarse location information reported by the UE. This field is coded as the Ellipsoid-Point information element (IE) defined in 3GPP TS 37.355. The first / leftmost bit of the first octet contains the most significant bit. The leastsignificant bits of degreesLatitude and degreesLongitude are set to 0 to meet the accuracy requirement which corresponds to a granularity of approximately 2 kilometers (km). It is up to UE implementation as to how many least significant bits (LSBs) are set to 0 to meet the accuracy requirement. Upon network request, after access stratum (AS) security is established in connected mode, some UEs (such as Bandwidth reduced Low Complexity (BL) UEs and UEs in enhanced coverage) can report their coarse UE location information (such as most significant bits of the global navigation satellite system (GNSS) coordinates, ensuring an accuracy in the order of 2 km) to an LTE / NR base station. However, it is not feasible for an NB-IoT UE to report coarse location information over AS to an NTN due to limited uplink bandwidth, simplified radio design, and security / privacy requirements of network operators and regulators.

[0044] Currently, 3GPP implementations assume that if an NB-IoT UE does not report any location information over AS to the RAN node, the RAN node provides its "‘best estimate” of the NB-IoT UE’s location based on tracking area information (TAI) and E-UTRAN Cell Global Identifier (TAI+ECGI) to the AMF / MME when the NB-IoT UE is entering or in the RRC CONNECTED state. However, the RAN's “best estimate” may be insufficient for the core network to determine whether the UE is permitted to use a particular RAN and a particular network in a particular location. A lack of sufficiently accurate user location information (ULI) reported to the AMF / MME from the NB-IoT UEs located in an NB-IoT NTN coverage area across multiple regulatory7areas could result in significant unnecessary7signaling overheads. For example, the AMF / MME might proceed with NAS procedures but eventually fail location verification or later reject the mobility or session management requests from the NB-IoT UE. In addition, there is increasing interest from network operators, satellite service providers, and UE vendors to enable an NB-IoT UE to report coarse location information when it accesses NB-IoT NTN.

[0045] Aspects of this disclosure address various considerations of network operators and regulators. Network operators and regulators might desire to enable NB-IoT use cases while balancing privacy or security concerns. Similarly, a network might prevent coarse location reporting for some NB-IoT UEs (based on regulatory, operator, or geographic considerations, etc.) while enabling coarse location reporting for other NB-IoT UEs. Aspects of this disclosure address how a wireless communication system might enable coarse location reporting by an NB-IoT UE only when it accesses an NB-IoT NTN while disabling (or not enabling) the coarse location reporting when the NB-IoT UE accesses a different type of RAN. Furthermore, aspects of this disclosure address how and whether an NB-loT UE reportsits location information based on its capability and network policies. According to various aspects of this disclosure, provisioning an NB-IoT UE for coarse location reporting can be done using NAS layer or RRC layer. Similarly, the actual coarse location reporting can be done using the NAS layer or the RRC layer. In some implementations, the actual location reporting is done using a different protocol layer than what was used for the provisioning.

[0046] The aspects of this disclosure are not limited to a particular RAT or UE type. For example, references to NB-IoT NTN or NB-IoT RAN can refer to any type of NTN access as an alternative to narrowband technologies. Similarly, references to NB-IoT UE can refer to any type of UE that implements loT technologies and / or that accesses a wireless communication system via an NTN RAN. Furthermore, some aspects of the coarse location reporting techniques of this disclosure may apply to coarse location reporting that is not specific to any particular RAT or UE type.

[0047] Particular implementations of the subject matter described in this disclosure can be implemented to realize one or more of the following potential advantages. A core network can accurately determine access for an NB-IoT UE based on a UE location in a coarse location report while still addressing security / privacy concerns for particular jurisdictions or particular users. Some aspects provide coarse location information while reducing signaling overhead that might otherwise consume precious uplink resources for an NB-IoT NTN. Furthermore, some aspects enable UE capability reporting and network provisioning of coarse location reporting based on UE capability such that the coarse location reporting features are backward compatible with some existing NB-IoT UEs.

[0048] FIG. 1 is an example wireless communication system 100 in which a core network (CN) 110 manages coarse location reporting for an loT UE (referred to as UE 102) accessing an NTN. In FIG. 1, the UE 102 is camping on an NTN cell 196 of a satellite 106. For comparison, FIG. 1 also shows a terrestrial network (TN) cell 194 operated by a TN BS 104. FIG. 1 also shows a second satellite 106' of a second RAN 105' and a second loT UE (UE 102'), which will be described further below to highlight some aspects of this disclosure.

[0049] An NTN extends or augments the service capability of a wireless communication system. An NTN refers to a network, or segment of networks, using radio frequency (RF) resources on board an NTN node (such as satellite or an airborne platform). In some implementations, an NTN node implements 5G NR technologies or Long-Term-Evolution (LTE) technologies tailored for the NB-IoT or the eMTC scenarios. Example NTN nodes include spaceborne vehicles (such as a satellite) or airborne vehicle (such as an unmanned aircraft system (UAS) or High-Altitude Platform Systems (HAPS)). Airborne platforms caninclude balloons, dirigibles, winged platforms such as airplane or drones, among other examples. Spaceborne platforms can include a Geostationary Earth Orbit (GEO) satellite (sometimes also referred to as a geosynchronous orbit (GSO) satellite), a Low Earth Orbit (LEO) satellite, a Medium Earth Orbit (MEO) satellite, or a Highly Elliptical Orbit (HEO) satellite, among other examples. In some implementations, NTN nodes can form constellations. An NTN node can belong to one of several types based on altitude, orbit, and beam footprint size. For brevity in this disclosure, all types of NTN nodes are referred to as a satellite 106.

[0050] An NTN gateway 107 (sometimes also referred to as a "sat-gateway") connects the satellite 106 to a BS 108A or other data network resources. In some deployments, some operations of the BS 108A can be collocated with the satellite 106 (shown as BS 108B). In this disclosure, the term BS 108 can refer to either or both of the BS 108 A on the ground (when present) or the BS 108B (when onboard the satellite 106). The NTN gateway 107 provides a ground station that communicatively couples the satellite 106 to the BS 108 A (when present) or the CN 110 (when BS 108A is not present). The BS 104 and the BS 108 are part of one or more radio access networks (RANs). In the example of FIG. 1, the satellite 106, the NTN gateway 107, and the BS 108 form part of a first RAN (referred to as RAN 105). In the example of FIG. 1, the radio access technology for the RAN 105 is associated with NB-IoT, and thus the RAN 105 can be referred to as an NB-IoT NTN RAN. NB-IoT and 5G NR are distinct wireless communication technologies targeting different use cases within the broader scope of the loT and 5G networks. NB-IoT is a Low Power Wide Area Network (LPWAN) technology designed for loT applications (such as smart meters, asset tracking, environmental monitoring, and industrial automation). NB-IoT is built for narrow bandwidth and low data rates, making it suitable for applications that require long battery' life and do not require high-speed data transfer. Increasingly, NB-IoT is being developed for use with NTNs.

[0051] The BS 104 might be associated with a different RAT (other than NB-IoT) and might be referred to as a different RAN. For example, the BS 104 can be a next generation base station (gNB) and can operate the TN cell 194 as a new radio (NR) cell. Alternatively, the BS 104 can be a legacy type of base station (such as ng-eNB or eNB) and operates the TN cell 194 as an evolved universal terrestrial radio access (E-UTRA) cell. Similarly, the satellite 106' might operate an NTN cell (not shown) as a NR cell or other radio access technology. Various TN cells and NTN cells can be in the same Radio Access Network Notification Areas (RNA) or different RNAs. Each RAN (such as RAN 105) can include anynumber of network elements, such as base stations, transmission and reception points (TRPs), satellites, or the like.

[0052] A satellite 106 can support a transparent or a regenerative (with on board processing) payload, and typically generates several beams for a given service area bounded by the field of view. The footprints of the beams typically have an elliptic shape and depend on the onboard antenna configuration and the elevation angle. For a transparent payload implementation, a satellite can apply RF filtering and frequency conversion and amplification, and not change the waveform signal. For a regenerative payload implementation, a satellite 106 can apply RF filtering, frequency conversion and amplification, demodulation and decoding, routing, and coding / modulation. This approach is effectively equivalent to implementing most of the functions of a BS 108, e.g., a gNB.

[0053] Any number of RANs (such as RAN 105) can be communicatively coupled to a CN 110. The CN 110 can be implemented as an evolved packet core (EPC), a fifth generation (5G) core (5GC), or a sixth generation (6G) core. Among other components, the EPC can include a Serving Gateway (SGW), a Mobility Management Entity (MME), a Packet Data Network Gateway (PGW). and a Home Subscriber Server (HSS). The SGW in general is configured to transfer user-plane packets related to audio calls, video calls, Internet traffic, etc., and the MME is configured to manage authentication, registration, paging, and other related functions. The PGW provides connectivity from the UE to one or more external packet data networks, e g., an Internet network and / or an Internet Protocol (IP) Multimedia Subsystem (IMS) network. The HSS is a central database that stores and manages subscriber- related information, providing authentication, authorization, and mobility management functions in mobile networks.

[0054] The 5GC can include a User Plane Function (UPF), an Access and Mobility Management Function (AMF), a Session Management Function (SMF), and a Unified Data Management (UDM) entity7. Generally speaking, the UPF is configured to transfer user-plane packets related to audio calls, video calls, Internet traffic, etc., the AMF is configured to manage access, registration, mobility, paging, and other related functions, and the SMF is configured to manage protocol data unit (PDU) sessions. The UDM is a network element responsible for managing user subscription data, providing authentication and authorization services, and ensuring secure access to the network in 5G mobile networks. The UDM serves as a database for storing subscriber profile information, such as subscriber identities, securityparameters, and service-related information.

[0055] The UE 102 establishes a radio connection to the satellite 106, referred to as RRC CONNECTED state. Once RRC CONNECTED, the UE 102 might send a network registration via the RAN 105 (i.e., the satellite 106 and the BS 108 (such as BS 108A or BS 108B)) to the CN 110. An access stratum (AS) refers to the radio connection and RAN operations between the UE 102 and the satellite 106 and / or the BS 108. A Non-Access Stratum (NAS) refers to a communication between the UE 102 and the CN 110 (albeit via the RAN). The UE 102 sends the network registration ("registration request") via an uplink (UL) NAS message to a network entity of the CN 110.

[0056] The CN 110 might determine whether to accept or reject the network registration based on user subscription information. Depending on where the UE 102 is located or what RAN is being accessed, the CN 110 might determine to accept or reject the network registration. The CN 110 may use location reporting from the UE or the RAN to determine the UE's location. Due to the low bandwidth and security / privacy concerns for NB-IoT, the 3GPP does not currently define a mechanism for location reporting for some RATs (such as NB-IoT RAT). Traditional techniques for location reporting are inadequate because they fail to take into consideration criteria that are specific to UEs (such as the UE being of a particular type (NB-IoT UE) or other UE-specific parameters). Furthermore, an NB-IoT NTN might cover a potentially large or changing coverage area that spans different political or geographic boundaries in which regulatory requirements might differ depending on where the UE 102 is located.

[0057] This disclosure introduces several mechanisms in which the CN 110 can provision (e.g., configure, enable, manage) coarse location reporting by a UE (such as an NB-IoT UE) based on UE-specific parameters. The CN 110 might provision (block 150) the coarse location reporting to cause the UE 102 or the RAN 105 to provide location information regarding the UE 102. In this disclosure, an enablement indication (referred to as “allowed location reporting indication”) informs the RAN 105 and / or the UE 102 that coarse location reporting is enabled. The allowed location reporting indication might be based on a variety of factors, such as the RAN 105 or 105' the location of the NTN (such as the satellite 106 or 106'), regulatory requirements, subscription information, or user consent, among other examples.

[0058] As a result of the CN 110 provisioning the coarse location reporting, the UE 102 might provide location information (block 160) to the CN 110 or the RAN 105. However, the CN 110 might come to a different conclusion about whether to provision the coarse location reporting for the second UE 102'. In the example in FIG. 1, the second UE 102' orthe second RAN 105' might be associated with a policy in which location reporting is not enabled (block 190). In other words, the CN 110 might communicate the allowed location reporting indication to the UE 102 (or RAN 105) and might not communicate the allowed location reporting indication to the second UE 102' (or the second RAN 105'). It should be understood that the term ‘‘allowed location reporting indication” is an example, and the indication can be referred to by other terms, such as “location reporting enablement indication,” “location indication,” “X indication” (where X can be any name), or other similar terms. In some implementations, the allowed location reporting indication can be present to indicate the coarse location reporting is enabled and can be omitted when coarse location reporting is not enabled. Alternatively, the allowed location reporting indication can be a first value to indicate that coarse location reporting is enabled or a second value to indicate that coarse location reporting is not enabled.

[0059] FIG. 2A is a block diagram of an example wireless communication system 200A implementing a BS 108 A (on the ground) connecting to a satellite 106 via an NTN gateway using a transparent payload implementation. The example wireless communication system 200A uses one type of NTN deployment referred to as transparent payload architecture, which involves an NTN gateway 107 and a “transparent” satellite 106 for extending the range of a Uu interface. The Uu interface refers to the link between the UE 102 and a base station. In some implementations, the satellite 106 implements a frequency conversion and an RF amplifier in both the uplink and downlink directions. With that being said, the satellite 106 function is similar to that of an analogue RF repeater. As a result, the satellite 106 repeats the Uu radio interface from a feeder link (between the NTN gateway 107 and the satellite 106) to the service link (between the satellite 106 and the UE 102) in the downlink direction and vice versa in the uplink direction. The Satellite Radio Interface (SRI) on the feeder link is the Uu interface, and the NTN gateway 107 supports all necessary functions to forward the signal of the Uu interface. The NTN gateway 107 can be placed at the same site as the BS 108A location, or can be connected to the BS 108A at a distance via a wired link. It is also possible to connect more than one NTN gateway 107 to a BS 108A. Different transparent satellites may be connected to the same base station on the ground, via the same NTN gateway, or via different NTN gateways.

[0060] FIG. 2B is a block diagram of an example wireless communication system 200B implementing a BS 108 A with feeder links to multiple satellites. Two different satellites 106 and 206 are connected to the same BS 108A via the same NTN gateway 107. The twosatellites 106 and 206 can each provide different NTN cells on the Earth surface and the different NTN cells can use different Physical Cell IDs (PCIs).

[0061] Although the transparent payload architecture illustrated in FIG. 2A and FIG. 2B is the current focus of the 3 GPP development, the regenerative pay load architecture that installs the BS functions on the satellite 106 is also a possible NTN deployment in the future. In such an architecture, the Uu interface exists between the satellite 106 and the UE 102, and some or all of the functions of the BS 108 are on-board the satellite 106 (such as show n in FIG. 2C.

[0062] FIG. 2C illustrates a block diagram of an example wireless communication system 200C implementing an NTN BS 108B onboard on a satellite 106 using a regenerative payload implementation. The BS 108B can perform some or all of the functions of a base station, including those described with reference to BS 108 or BS 108 A in this disclosure. The Uu interface is shown between the UE 102 and the BS 108B. The feeder link from the BS 108B to the NTN gateway 107 can be referred to as a Satellite Radio Interface (SRI). The SRI is a transport link between the NTN gateway 107 and the satellite 106. The Ng interface from the BS 108B includes a portion over the SRI (shown as Ng over SRI) and a portion on the ground. In some implementations, a first portion of the base station functionality (such as BS 108 A) can be implemented on the satellite 106 while a second portion of the base station functionality7(shown as BS 108B) can be implemented at a ground entity. For example, in a disaggregated network, BS 108 can be divided into two components: the Distributed Unit (DU) and Centralized Unit (CU). In an example, the BS 108B can operate as a DU that handles baseband processing, including RF signal processing and modulation / demodulation. The BS 108A can be an example CU that manages higher-layer tasks like resource management, scheduling, and netw ork optimization.

[0063] The techniques of this disclosure can apply to the transparent payload architecture as well as the regenerative payload architecture. References to RAN 105 can refer to the BS 108 (which could be implemented as either or both of the BS 108A or BS 108B illustrated in FIG. 1. FIG. 2A, FIG. 2B, or FIG. 2C).

[0064] FIG. 3A illustrates an example control plane protocol stack in which the example wireless communication system of FIG. l is a 5thgeneration system (5GS). FIG. 3A shows the control plane protocol stack protocol layers 300A for the UE 102, the BS 108, and network entities of the CN 110 (the AMF 312 and the SMF 314 if the CN 110 is a 5GC). The RAN 105 includes the BS 108 as w ell as the addition of the satellite 106 and the NTN gateway 107 being placed in the Uu interface. BS 108 can be either, or both, a network entity on theground (such as BS 108 A) or a network entity partially or completely onboard the satellite 106 (such as BS 108B).

[0065] The protocol layers between the UE 102 and the BS 108 include a physical (PHY) sub-layer that provides transport channels. A media access control (MAC) sub-layer provides logical channels for a radio link control (RLC) sub-layer. The RLC sublayer in turn provides data transfer services to the Packet Data Convergence Protocol (PDCP) sublayer. The PDCP sublayer in turn can provide data transfer services to a radio resource control (RRC) sublayer. For a 5GC, the protocol layers between the BS 108 and the core network include a layer 1 (LI) sub-layer, layer 2 (L2) sub-layer, an Internet protocol (IP) sub-layer, Stream Control Transmission Protocol (SCTP) sub-layer, and Next Generation Application Protocol (NGAP) sub-layer. The AMF 312 and the SMF 314 can implement any variety of protocol layers to manage communication between themselves and the UDM 316.

[0066] Aspects of this disclosure are related to the NAS communications between the UE 102 and the core network (such as a 5GC). Generally speaking, a NAS protocol manages the UE’s mobility, session, and control plane signaling between the UE 102 and the CN 110, transparent to any access network node (e.g., BS 108). In some aspects, the core network implements various discrete control plane functions (shown as the AMF 312 and the SMF 314). Together the AMF 312 and the SMF 314 can implement portions of the NAS layer. The AMF 312 can provide mobility management (MM) aspects of the NAS layer while the SMF 314 can provide session management (SM) aspects of the NAS layer. The UE 102 communicates to a SMF 314 via NAS messages that are first sent to the AMF 312. The AMF 312 is responsible for managing the UE’s mobility and connection to the CN 110. Also, any upper layer control signal can be delivered over NAS layer between the AMF 312 and the UE 102, which is also called NAS-MM layer. The SMF 314 is responsible for managing PDU sessions, and a UE 102 can be associated with one or more SMF 314 at the same time. The NAS protocol between the UE 102 and the SMF 314 is also called NAS-SM layer. The UE 102 and the AMF 312 communicate with each other via a logical interface referred to as the N1 control interface. The N1 control interface is a logical interface that traverses the Uu interface and the Sl / NG interface (sometimes referred to as the NG-C or N2 interface in a 5GC).

[0067] FIG. 3B illustrates an example control plane protocol stack in which the example wireless communication system of FIG. 1 is a 4th generation system evolved packet system (EPS). The control plane protocol stack protocol layers 300B of the EPS is similar to the control plane protocol stack protocol layers 300A described with reference to FIG. 3B. Somenomenclature differences between FIG. 3B and FIG. 3A include: the BS 108 might be an E- UTRA base station (eNB), the Uu interface is labeled as an LTE-Uu interface, and the Sl / NG interface is referred to as an SI -MME interface. In the EPS, the MME 322 serves as a single endpoint for the NAS protocol in the core network. The MME 322 is responsible for both MM and SM aspects, although SM related protocols assumes to be upper to MM related protocols. The MME 322 can communicate with the HSS 317 to obtain user subscription information or other parameters related to UE registration.

[0068] Aspects of this disclosure are related to the NAS protocol and can be applied to either the 5GS (FIG. 3A) or EPS (FIG. 3B). For avoidance of doubt, in this disclosure when referring to UL NAS messages, the UL NAS message is communicated from the UE 102 to any of the NAS endpoints in the core network (such as the SMF 314, the AMF 312, or the MME 322). DL NAS messages are communicated to the UE 102 from the AMF 312, the SMF 314, or the MME 322.

[0069] FIG. 4 is a message flow diagram illustrating example operations for provisioning coarse location reporting based on UE-specific parameters and other considerations. The message diagram 400 shows messaging and operations performed by the UE 102. the RAN 105 (such as a base station of the RAN), and the CN 110. In FIG. 4, some operations of the CN 110 are broken down between the AMF 312 and the UDM 316. However, it should be understood that the operations shown for the CN 110 can be performed by any network entity, including the AMF. SMF, or UDM in a 5GC or the MME, SGW / PGW. or HSS in a 4GC. The illustration and description of FIG. 4 refers to the AMF 312 and the UDM 316 as an example implementation. Furthermore, in FIG. 4, the RAN 105 is an NTN RAN, as demonstrated by the satellite 106 icon. In some implementations, the UE 102 and the RAN 105 are configured to communicate using an NB-IoT NTN RAT type.

[0070] After establishing a radio connection to the RAN 105, the UE 102 communicates a registration request 420 to the CN 110 (e.g., the AMF 312). The CN 110 obtains UE-specific parameters 430. For example, the AMF 312 might receive the UE-specific parameters 430 from the UDM 316 in response to a registration request or a query message. The UE-specific parameters 430 might include any information relevant to the example considerations 650 for determining whether to enable coarse location reporting described with reference to FIG. 6.

[0071] In some implementations, the CN 110 also obtains UE capability information 440 about the UE 102. The CN 110 can obtain the UE capability information 440 in a UL NAS message, e.g., registration request message or N2 message over an N2 interface between theAMF 312 and the RAN 105. Alternatively, or additionally, the CN 110 might obtain UE capability information (not shown) from another network entity.

[0072] At block 450, the CN 110 determines whether to enable coarse location reporting for the UE 102. The determination whether to enable coarse location reporting can be based on any of the example considerations 650 described with reference to FIG. 6, among other examples. In some implementations, the AMF 312 makes the determination based on information obtained from the UDM 316 and / or the RAN 105. The operations of block 450 can be performed by the AMF 312, the UDM 316, a different network entity, or a combination of network entities. For example, the UDM 316 (or another network entity) can make the determination and provide an allowed location reporting indication to the AMF 312 as a result of a determination to enable coarse location reporting for the UE 102. In some aspects, when the UDM 316 determines to enable coarse location reporting, the 316 provides an allowed location reporting indication to the UE 102 via the AMF 312 as part of a registration procedure or using a UE parameter update via a UDM Control Plane procedure. In some implementations, the allowed location reporting indication can be a different value for a home public land mobile network (HPLMN) and a roaming network. In some implementations, the allowed location reporting indication is defined only for use when an loT UE is accessing an NB-IoT RAT over satellite access.

[0073] Based on the determination to enable coarse location reporting for the UE 102, the CN 110 provisions the coarse location reporting. This disclosure includes several techniques 460 to provision the coarse location reporting. For example, the CN 110 can include an allowed location reporting indication in an N2 message and an RRC message via registered RAN node (shown at arrow (CN->RAN) 462). Alternatively, the CN 110 can include the allowed location reporting indication in a NAS registration accept message (shown at arrow NAS (Reg. accept) 466). In yet another example, the CN 110 can provide the allowed location reporting indication in a UE Configuration Update procedure (shown at arrow (NAS UE config, update) 468). The NAS registration procedure and parameter update via UDM control plane are further described in 3GPP TS .23.502

[0074] After the CN 1 10 provisions the UE 102 for coarse location reporting by any of the techniques 460 described in this disclosure, the CN 110 can receive location information about the UE by at least one of the techniques 480 described in this disclosure. The techniques 480 for receiving the UE location information include receiving the location information from a RAN node that obtains the coarse location reporting from the UE 102 (shown at arrow (RAN->CN) 482). For example, the RAN 105 can uery the UE 102 toobtain the location information. Alternatively, or additionally, the UE 102 configured with allowed location reporting indication can send an RRC message with the location information to the RAN node if requested by the RAN node or in related RRC messages. In another example technique 480, the CN 110 can receive the location information from the UE 102 via a NAS message (shown at arrow (NAS) 486). For example, the UE 102 can include location information in a UL NAS message to the CN in related NAS procedures, including UE initiated Registration request procedure with registration type set as initial registration, mobility registration update, or periodic registration update, or Security Mode Complete message / UL NAS Transport message if requested / configured by the CN, or UE initiated PDU Session Establishment / Modification request procedure.

[0075] Some aspects of this disclosure enable coarse location reporting via RRC messaging. A potential technical advantage of using RRC messaging is that the wireless communication system can leverage known techniques for location reporting via RRC messaging (such as for eMTC or NR UEs). Meanwhile, the core network can provision coarse location reporting for a subset of NB-IoT UEs based on subscription, consent, or other considerations. Some aspects of this disclosure enable coarse location reporting via NAS messaging. A potential technical advantage of using NAS messaging is that the coarse location reporting can be integrated with a NAS layer registration process or session management process. Some aspects of this disclosure describe a combination of RRC layer and NAS layer operations to achieve further potential technical advantages.

[0076] In this disclosure, the location information regarding a UE can be reported using coarse location reporting, such as the “coarseLocationlnfo” field described in 3GPP TS 36.331 and 38.331. The UE 102 can include the coarseLocationlnfo field in a NAS or RRC message for coarse location reporting. The UE 102 can send its location information as coarse location information and coded as the Ellipsoid-Point IE defined in 3GPP TS 37.355 to the CN after (1) NAS security is established if reporting location via NAS message or (2) after AS security is established in connected mode if reporting location to the RAN node via RRC message. The IE Ellipsoid-Point can be used to describe a geographic location as defined in 3GPP TS 23.032. (see Table 1).Table 1

[0077] For coarse location information, the first / leftmost bit of the first octet contains the most significant bit of the GNSS coordinates and a number of the least significant bits (LSBs) of degreesLatitude and degreesLongitude are set to 0 based on UE implementation with local configuration of accuracy requirement (e.g., corresponds to a granularity of approximately 2 km).

[0078] FIG. 5 is a flow chart diagram with example operations 450 for determining whether to enable coarse location reporting for a UE. The operations can be performed by any network entity of the CN, such as the UDM or the AMF (in a 5GC) or the HSS or MME (in an EPC).

[0079] At block 532, the CN obtains UE subscription data that might or might not indicate whether the UE and the registering network enable coarse location reporting. At block 550, the CN (for example, the UDM 316 or AMF 312 illustrated in FIG. 3A) may store or obtain UE subscription data that might or might not include the allowed location reporting indication for the UE.

[0080] At block 550, the CN determines whether to send the allowed location reporting indication (to either the RAN or the UE), which might or might not include transmission via another CN. If so, the flow chart continues to block 560, where the CN sends the allowed location reporting indication to the RAN and / or UE as part of a registration procedure or UE parameter update procedure. If. at block 550, the CN determines not to send the allowed location reporting indication, the flow chart proceeds to block 597. At block 597. the CN might refrain from sending the allowed location reporting indication to the RAN or the UE. Alternatively, or additionally, the CN might send a different indication or a particular value of the allowed location reporting indication to explicitly indicate to the RAN or the UE that the UE is not provisioned for coarse location reporting. At block 598, the CN might use a RAN-estimated location for the UE to determine whether to accept or reject a network registration request. Alternatively, the CN might default to either accepting or rejecting the network registration request based on no location reporting for the UE.

[0081] Having described the example operations 450 generally, below is a detailed example showing one possible implementation of the operations 450:• Block 532: a first network entity (e.g., UDM / HSS) of the CN stores UE subscription that might or might not include subscription information that leads to a decision to sendan allowed location reporting indication to the UE. Alternatively, a first network entity (e.g., UDM / HSS) sends UE subscription information that might or might not include an allowed location reporting indication to a second network entity (e.g., AMF / MME) of the CN without making decision whether to send an allowed location reporting indication to the UE.• Block 550: based on the UE subscription, network ID, e.g.. Public land mobile network (PLMN) ID or non-public network (NPN) ID, and requirements of the local network operator and regulator, the first network entity7determines whether to send the allowed location reporting indication to a second network entity (e.g., AMF or MME) for conveyance to the UE. The decision can be based on UE subscription and requirements of security and privacy of the Home network operator, local network operator (based on the registered network ID, e.g., PLMN ID or NPN ID, indicated from the second network entity ) and the regulator.• Block 560: if yes (at block 550), the first network entity sends the allowed location reporting indication to the UE using one of various potential procedures such as a registration procedure or UE parameter update via UDM Control plane procedure.• Block 597: If no (at block 550), the first network entity does not send an allowed location reporting indication to the second network entity or the UE.

[0082] FIG. 6 illustrates example criteria for a core network considering whether to enable coarse location reporting for an loT UE. The example considerations 650 for determining whether to enable coarse location reporting include considerations based on one or more of the following: UE capability information 652A; subscription information 652B; operator / network policy 652C; user consent 652D; configuration for home network 652E; coarse location reporting enabled for list of network IDs (such as PLMN, mobile network code (MNC) and mobile country code (MCC). or NPN ID) 652F; RAT type 652G; geographic location 652H; regulatory requirements 6521; or other parameters 652(x). Although some considerations are listed separately, they can be combined in various ways.

[0083] The UE capability7information 652A can indicate whether the loT UE supports location reporting. For example, the UE might be a sensor or other device not intended to obtain location and might not be equipped with any means for determining location. In such instances, the CN does not configure location reporting for the loT UE.

[0084] The subscription information 652B can include one of the following information:• loT NTN service subscription information;• User consent for coarse location reporting; and / or• Allowed location reporting indication with applicable network information including: o Allowed location reporting indication for a Home PLMN (HPLMN) or an NPN; o Allowed location reporting indications are set for a list of network IDs (PLMN ID based on MNC and MCC, or NPN ID), e.g., Network ID#A, Network ID#D, Network ID#D (652F); and / or o Allowed location reporting indications are set for a list of combination of network ID and RAT ty pe, e.g., Network ID#A and RAT type as NR(LEO) RAT, Network ID#A and RAT type as NR, Network ID#C and RAT type as LTE NB- loT, (652G) etc.

[0085] The operator / network policy 652C might indicate whether a particular RAN or operator is configured to use coarse location reporting for the loT UEs. In some instances, an operator in one region might disable coarse location reporting for loT UEs. while an operator in another region might enable coarse location reporting for loT UEs.

[0086] The user consent 652D might be an opt-in or opt-out feature in which a network operator might give the user an opportunity to consent to coarse location reporting or refuse coarse location reporting.

[0087] The configuration for home network 652E might indicate whether a Home PLMN for an NB-loT UE has enabled coarse location reporting, which might be useful for a core network to determine whether to enable coarse location reporting for the NB-loT UE when it is roaming on a Visited PLMN.

[0088] The geographic location 652H might indicate a current location of the NB-loT NTN or the location of the NTN in relation to political or regulatory7boundaries.

[0089] The regulatory requirements 6521 might indicate whether location reporting is allowed or forbidden for a particular region or type of device.

[0090] The example considerations 650 shown in FIG. 6 are provided as non-limiting examples and other parameters 652(x) or considerations are possible. For example, a CN might consider a priority, access class, access category, subscription type, or other information about the NB-loT UE to determine whether to enable coarse location reporting.

[0091] In some aspects, a CN (such as AMF or MME) can determine whether to enable coarse location reporting for loT NTN based on at least one of the following coarse location reporting enabling conditions:• loT UE subscription which contains allowed location reporting indication or allowed location reporting indication as a parameter received from a network entity of the CN during registration request procedure.• loT UE information indicating its RAT type, e g., EUTRAN-NB-IoT or E-UTRA-NB- loT RAT, with extended indication of Satellite RAT if using loT NTN in EPS. or NR- based satellite RAT types (NR-LEO-NB-IoT, NR-MEO-NB-IoT, NR-GEO-NB-IoT) in 5GS;• The loT UE capability support for location reporting; and / or• The network support for coarse location reporting.

[0092] Having described several example considerations, provisioning, and coarse location reporting options at a high-level, this disclosure now includes several examples to illustrate some of options of various aspects of the disclosure. The examples in FIG. 7 through FIG. 13B show the UE 102 (such as an NB-IoT UE) communicating with a CN 110 via a RAN 105 with an NB-IoT NTN RAT type. For brevity, the following description will focus on the differences in each figure compared to the general technique described with reference to FIG. 4 and its preceding figures. Where possible, to reduce redundancy, the figures include like reference numbers to represent an event or message already described in a previous figure and the description of that event or message is omitted or summarized in the description of the latter figure. In FIG. 7 through FIG. 13B, in some implementations, the UE 102 is an NB-IoT UE and the RAN 105 is an NB-IoT NTN. Furthermore, as with FIG. 4. the examples of FIG. 7 through FIG. 13B show the CN 110 having an AMF 312 and a UDM 316. However, as with FIG. 4, the functionalities described for FIG. 7 through FIG. 13B might be performed by other types of network entities, including an MME and an HSS, respectively.

[0093] Table 2 provides a high level overview of the examples illustrated in each of the FIG. 7 through FIG. 13B.Table 2

[0094] In some examples, an NB-IoT UE (such as UE 102) performs location reporting via RRC messages (such as in FIG. 7 through FIG. 11). The NB-IoT UE might or might not be configured with allowed location reporting indication based on provisioning by the core network. The NB-IoT UE can send an RRC message with the location information to the RAN node if requested by the RAN node or in related RRC messages. In some examples, the NB-IoT UE performs location reporting via NAS messages (such as in FIG. 7, FIG. 8. and FIG 12 through FIG. 13B). The NB-IoT UE can include location information in a UL NAS message to the CN in related NAS procedures, including UE initiated Registration request procedure with registration type set as initial registration, mobility registration update, or periodic registration update, or Security Mode Complete message / UL NAS Transport message if requested / configured by the CN, or UE initiated PDU Session Establishment / Modification request procedure.

[0095] FIG. 7 is a message flow diagram 700 showing example operations for enabling coarse location reporting. After receiving a registration request 420 from the UE 102, the AMF 312 proceeds with a Network Unified Data Management (Nudm) registration procedure. At arrow 732, the AMF 312 communicates a Nudm UE configuration management (UECM) registration (Nudm_UECM_Registration) message to the UDM 316. The UDM 316 responds to the Nudm_UECM_Registration by sending a Nudm_UECM_Registration response to the AMF 312 in response to the Nudm_UECM_Registration message. In some implementations, theNudm_UECM_Registration response can include the allowed location reporting indication, such as when the UDM 316 determines to enable coarse location reporting for the UE 102.

[0096] FIG. 7 shows some other options for the UDM 316 to provide the allowed location reporting indication to the AMF 312. For example, at arrow 734, the AMF 312 can send a Nudm_SDM Get request to the UDM 316 and receive aNudm_SDM response from the UDM 316. The Nudm_SDM response can include the allowed location reporting indication. Alternatively, or additionally, the AMF 312 can send a Nudm_SDM Subscribe message to the UDM 316 and get a Nudm_SDM Notify message in response (shown at arrow 736). The Nudm_SDM Notify message can include the allowed location reporting indication.

[0097] After obtaining the allowed location reporting indication from the UDM 316, the AMF 312 can determine to enable the coarse location reporting at block 450. FIG. 7 shows two options by which the AMF 312 can provision the RAN and / or the UE for coarse location reporting and obtain the UE location information. In a first option 760A, the AMF 312 sends a UE context create (or update) message 762 to the RAN 105. The UE context create / update message 762 includes an allowed location reporting indication to prompt the RAN 105 to provision the coarse location reporting. The RAN 105 transmits an RRC message 763 to the UE 102 to include the NAS registration accept message and the allowed location reporting indication). After provisioning the coarse location reporting, the RAN 105 may obtain the UE location reporting via RRC message 781 and provide the location information (not shown) to the AMF 312.

[0098] In another option 760B, the AMF 312 can send a NAS registration Accept message 766 to the UE 102. where the NAS registration Accept message 766 includes the allowed location reporting indication. The NAS registration Accept message 766 (and included allowed location reporting indication) cause the UE 102 to configure coarse location reporting. The UE 102 includes UE location reporting via NAS message 786 either during normal NAS operations or in response to the NAS registration Accept message 766.

[0099] FIG. 8 is a message flow diagram 800 showing example operations for a CN 110 to update a UE configuration for coarse location reporting. At block 830, the UDM 316 decides to perform UE Parameter Update for coarse location reporting. At arrow 838A, the UDM sends a Nudm message including the allowed location reporting indication to the AMF 312. In response, the AMF 312 may send a Nudm response message (arrow 838B) to update its information (e.g., network support for coarse location reporting). At arrow 868 A, the AMF 312 sends a DL NAS Transport message including the allowed location reporting indication to the UE 102. The UE 102 stores the allowed location reporting indication in NAS UE context or RRC UE context. In some implementations, the UE NAS provides the allowed location reporting indication to the lower layer. If an acknowledgement is requested, the UE102 sends a UL NAS Transport message (arrow 868B) to acknowledge the receipt of the DL NAS transport message 868 A. At block 880A, the UE 102 enables (or disables) location reporting (via NAS). Alternatively, or additionally, at block 880B, the UE 102 enables (or disables) the location reporting (via RRC).

[0100] FIG. 9 is a message flow diagram 900 showing example options using an RRC protocol to coordinate coarse location reporting in which the UE provides UE capability information via the RRC protocol. FIG. 9 begins with similar operations 420, 450, 732, and 762 as described with reference to FIG. 4 and FIG. 7, respectively. In FIG. 9. the UE context create / update message 762 might prompt the RAN 105 to provision location information for the UE. The RAN 105 communicates an RRC message 963 including the NAS Registration Accept message. In some implementations (not shown in FIG. 9), the RRC message 963 includes an allowed location reporting indication. Alternatively, in some implementations (as shown in FIG. 9), the RRC message 963 does not indicate the allowed location reporting indication. In either way, the RAN 105 provisions coarse location reporting and obtains the UE location information based on the allowed location reporting indication in the UE context create / update message 762.

[0101] To obtain the location information of the UE 102, the RAN 105 can check the UE context to determine whether the UE capability supports location reporting. If the UE capability7information regarding location reporting is not available in the UE context, the RAN 105 can send an RRC request message (referred to as an RRC capability enquiry 964A) indicating the type of UE capability7, e.g., location reporting capability to obtain UE capability information. The RAN 105 receives an RRC response message (referred to as a UE capability information message 964B) indicating whether the UE does support (or does not support) location reporting. The RAN 105 stores the UE capability information regarding location reporting in the UE context. Otherwise, if the UE context indicates whether the UE capability supports location reporting, the RAN 105 can proceed with obtaining location information from the UE 102. In some implementations, if the RAN 105 determines that the UE 102 is incapable of providing location data (e.g., the UE capability information or UE context indicates that the UE 102 does not support location reporting), the RAN 105 sends an N2 message (not shown) to CN for reporting the location information with a proper cause value that indicates the unsupported UE capability' for location reporting.

[0102] Assuming the UE 102 is capable of providing the coarse location information, the RAN 105 sends an RRC request message (shown as RRC UE location reporting request 981 A) to obtain location information from the UE 102. The RAN 105 receives an RRC response2f>message (shown as RRC UE location reporting response 98 IB) including UE location information from the UE 102. At block 984, the RAN 105 stores the received UE location information in the UE context. In some implementations, the RAN 105 stores a timestamp with the stored UE location information.

[0103] At event 988C, the RAN 105 sends an N2 message to the CN 110 to report the last stored UE location information. The N2 message 988C might be sent in response to an N2 request message (988A) for location information from the CN. Alternatively, or additionally, the N2 message 988C might be a one-time report, a periodic report, or an event triggered report (e.g., cell / TA / MCC / MNC change). In another alternative, the N2 message 988C might be sent when sending a NAS container to the CN 110 based on a NAS message included in an RRC message 988B from the UE 102. In some implementations, the N2 message is based on a location report procedure defined in 3GPP specifications. In some implementations, the N2 message is a new format or procedure specific to loT UEs or NB-IoT UEs.

[0104] A potential technical advantage of the example shown in FIG. 9 is that RRC overhead might be reduced, such as when the RAN 105 stores the UE location information with the UE context and can respond to the N2 location request message based on the stored UE location information. The UE 102 can avoid sending location information (and related communication overhead) unless there has been a change in location or a threshold time since the last location report.

[0105] FIG. 10A is a message flow diagram 1000A in which the UE 102 provides UE capability information via a NAS message and the coarse location reporting is accomplished using RRC messaging. In FIG. 10A. the UE 102 can include UE capability information with the registration request 1020. For example, the registration request 1020 differs from the registration request 420 of FIG. 4 in that the registration request 1020 indicates the UE capability for location reporting. The CN 110 (such as the 316 or the AMF 312) may take the UE capability into consideration along with any other UE-specific parameters to determine whether to enable coarse location reporting as described with reference to FIG. 6. The rest of FIG. 10A is the same as described with reference to FIG. 7 and FIG. 9. A potential technical advantage of the example of FIG. 10A is that the UE capability information can be included at the original registration request, which might reduce or eliminate some additional steps for the RAN 105 or CN 110 to obtain UE capability' information.

[0106] FIG. 10B is a message flow diagram 1000B showing an option of FIG. 10A in which the radio access network informs the UE regarding the coarse location reporting via an RRC message. FIG. 10B is similar to the messages and operations of FIG. 10A, except that FIG.10B shows that the RAN 105 communicates an allowed location reporting indication with the NAS registration accept message in the RRC message 1063 (compared to the RRC message 963 which might or might not include the allowed location reporting indication).

[0107] FIG. 11 is a message flow diagram 1100 in which coarse location reporting is provisioned using NAS layer messaging while the loT UE location reporting is done at the RRC layer. In FIG. 11, the UE 102 provides UE capability information in a UL NAS message (such in the registration request 1020) which the CN 110 uses to determine to enable coarse location reporting as described with reference to FIG. 6. The CN 110 (such as the AMF 312) transmits a DL NAS message 1166 to the UE 102 to provision the coarse location reporting. In the example shown in FIG. 11, the DL NAS message 1166 is a registration accept message that also indicates network capability support and the allowed location reporting indication.

[0108] Based on the DL NAS message 1166 provisioning the coarse location reporting, the UE 102 configures location reporting. In some implementations (as shown in FIG. 11), the UE NAS sublayer provides an indication of location reporting to the UE RRC sublayer (block 1167). Thus, the CN 110 can use a NAS layer message to provision location reporting, while the actual location reporting is managed at the RRC layer as described with reference to FIG. 9.

[0109] FIG. 12A is a message flow diagram 1200A in which coarse location reporting provisioning and reporting are both done using NAS layer. As with FIG. 11, FIG. 12A shows the DL NAS message 1166 indicating registration accept also indicates the allowed location reporting indication. The DL NAS message 1166 also optionally indicates network capability support. FIG. 12A is similar to FIG. 11 except that in FIG. 11 the location reporting was done at the RRC layer while FIG. 12A shows the location reporting is done at the NAS layer. The UE 102 provides the location information via NAS messaging (such as UL NAS message 1286). After receiving the DL NAS message 11 6 including the allowed location reporting indication, the UE 102 includes location reporting with at least one (possibly all) UL NAS message sent to the AMF 312 after receiving the allowed location reporting indication. As described with reference to FIG. 4 through FIG. 6, FIG. 12A includes a mechanism for selectively enabling (or not) the coarse location reporting based on UE-specific parameters (block 450). Thus, even when using NAS layer for location reporting, the example in FIG. 12A only enables coarse location reporting for particular UEs based on considerations that might be specific to the UEs.

[0110] FIG. 12B is a message flow diagram 1200B in which a UE configuration is updated to enable coarse location reporting at the NAS layer after a network registration. In FIG.12B, the CN 110 receives a registration request 420 or 1020 (e.g., with or without UE capability information) and proceeds with a registration accept message 1266. The registration accept message 1266 can indicate the network capability support for coarse location reporting. For example, if the AMF 312 determines to enable coarse location reporting for the UE 102, the AMF 312 sends a Registration Accept message including network support of coarse location reporting to the UE 102.

[0111] At block 1250, the CN 110 (such as the AMF 312) determines to update the UE configuration for coarse location reporting. For example, the AMF 312 may receive an allowed location reporting indication for the UE from the UDM 316. Or some change (such as a change in the user consent, subscription information, or geographic location of the NTN) might prompt the CN 110 to update the UE configuration. Based on the determination (block 1250), the CN 110 sends a UE configuration update command 1268A to the UE 102. In the example shown in FIG. 12B, the UE configuration update command 1268A includes an allowed location reporting indication or some other field to inform the UE 102 to enable coarse location reporting. Note that while FIG. 12B shows the location reporting via NAS layer, other implementations might use RRC layer for location reporting (such as FIG. 9 through FIG. 11).

[0112] After receiving and processing the UE configuration update command 1268A, the UE 102 sends a UE Configuration update Complete message 1268B if acknowledgement is requested. The UE stores the allowed location reporting indication in the UE context. In some implementations, the AMF 312 communicated a Nudm_SDM Info 1269 message to the UDM 316 to indicate that the coarse location reporting was enabled. After the CN 110 provisions the coarse location reporting (such as using the UE configuration update command 1268A), the UE 102 includes location information in one or more subsequent UL NAS messages 1286.

[0113] FIG. 13A is a message flow diagram 1300A in which coarse location reporting is provisioned using the NAS layer based on UE capability information obtained at the RRC layer. FIG. 13 A begins with a network registration request 1020 (or alternatively the registration request 420). The CN 110 may determine whether the registration should include an allowed location reporting indication based on UE capability7. FIG. 13A includes another implementation option for obtaining UE capability information. The CN 110 can communicate an N2 message 1332 (e.g., between the AMF 312 and the RAN 105) including a UE capability enquiry to obtain UE capability information regarding the UE's location reporting capability7. When receiving the N2 message 1332, the RAN 105 can provide theUE capability information in an N2 response message 1336. In some implementations, the RAN 105 already has information regarding the UE's capability for location reporting. Alternatively, the RAN 105 can query the UE 102 using RRC messaging to obtain the UE capability information from the UE 102 (e.g., messages 964A and 964B). In FIG. 13 A, the RAN 105 sends an RRC UE capability request message (referred to as a UE capability enquiry) 964A to the UE 102. The UE 102 responds with an RRC response message (referred to as UE capability information) 964B indicating whether the UE supports location reporting. The RAN 105 communicates the N2 response message 1336 including the UE capability information to the CN 110.

[0114] At block 1350A, the CN 110 (e.g., the AMF 312) determines whether to enable location reporting for the UE 102. The operations of block 1350A are similar to those described for block 450, including the example operations and considerations described with reference to FIG. 5 and FIG. 6. If the CN 110 determines to enable location reporting for the UE 102, the CN 110 (e.g., AMF 312) sends a Registration Accept message 1366A including the allowed location reporting indication to the UE 102. Thereafter, the UE 102 can provide coarse location reporting via NAS layer (as shown in FIG. 13 A) or via RRC layer (using any of the examples described with reference to FIG. 9 through FIG. 12B).

[0115] FIG. 13B is a message flow diagram 1300B combining aspects of the UE configuration as described with reference to FIG. 12B with the UE capability information being updated at the RRC layer as described with reference to FIG. 13 A. In FIG. 13B, the CN 110 (e.g., AMF 312) communicates a registration accept message 1366B (which might or might not include an allowed location reporting indication). Based on N2 messaging (1332 and 1336) and RRC layer messaging (964A and 964B), the CN 110 obtains the UE capability information regarding location reporting. At block 1250 (as described with reference to FIG. 12B, the CN 110 decides to update the UE configuration. The UE configuration update procedure (including operations and messages 1268 A, 1268B, 1269, and 1286) are the same as described with reference to FIG. 12B.

[0116] The examples provided in FIG. 4 through FIG. 13B are intended to show various options in accordance with aspects of this disclosure. The figures provide different examples for obtaining UE capability information (such as NAS layer, RRC layer, and N2 messaging) regarding whether the UE supports location reporting. Other mechanisms might be possible. For example, the CN 110 might determine the UE capability based on the UE type, capability information from another network entity, or from a central server, among other examples. The figures provide different examples for provisioning the coarse location reporting such asNAS layer, RRC layer, UE Configuration update, among other examples. Similarly, the figures provide different examples for obtaining UE location information such as via RRC layer, NAS layer, or using stored UE location information at the RAN 105, among other examples. In addition to the examples illustrated in FIG. 4 through FIG. 13B, the various options in those figures can be combined in a variety of different ways to achieve other examples.

[0117] FIG. 14 is a block diagram of an example wireless communication system 1400 showing hardware features and communication interfaces. The depicted hardware configurations may omit certain components well-understood to be frequently implemented in such electronic devices, such as displays, peripherals, power supplies, and the like. The wireless communication system 1400 includes the same elements as described with reference to FIG. 1, including the UE 102, the BS 104, the BS 108, the satellite 106, and the CN 110. The UE 102 can support at least a 5G NR (or simply, “NR”) or E-UTRA air interface to communicate with the BS 104. The BS 104 connects to the CN 110 via an interface (e.g., SI or NG interface). The BS 104 can connect to other base stations (including the BS 108) via an interface (e.g., X2 or Xn interface) for interconnecting NG RAN nodes.

[0118] The BS 108 (such as either or both of the BS 108A or BS 108B) is equipped with processing hardware 1418 that can include a receiver 1408B configured to receive data in the uplink direction. The processing hardware 1418 can also include a transmitter 1408A configured to transmit data in the downlink direction. The processing hardware further can one or more general-purpose processor(s) 1408C (e.g., CPUs) and a non-transitory computer- readable memory 1408D storing instructions that the one or more general-purpose processors execute. Additionally, or alternatively, the processing hardware 1418 can include specialpurpose processing units. The processor 1408C may include, for example, one or more central processing units, graphics processing units (GPUs), or other application-specific integrated circuits (ASIC), and the like. CRM 1408D may include any suitable memory or storage device such as random-access memory' (RAM), static RAM (SRAM), dynamic RAM (DRAM), nonvolatile RAM (NVRAM), read-only memory' (ROM), or Flash memory' usable to store device data of the BS 104.

[0119] The satellite 106 can include processing hardware 1416, such as atransmitter 1406A, a receiver 1406B, a processor 1406C, and CRM 1406D (similar to components 1418, 1408A, 1408B. 1408C and 1408D of the BS 104). The BS 104 can include generally similar components (not shown) as the processing hardware 1418.

[0120] The UE 102 is equipped with processing hardware 1412 that can include one or more general-purpose processors such as CPUs and non-transitory computer-readable memory 1402D storing machine-readable instructions executable on the one or more general-purpose processors, and / or special-purpose processing units. The processing hardware 1412 can also include a transmitter 1402A configured to transmit data in the downlink direction. The processing hardware further can include a receiver 1402B configured to receive data in the uplink direction. The processing hardware 1412, in an example implementation, includes a processor 1402C to process data that the UE 102 will transmit in the uplink direction or process data received by UE 102 in the downlink direction. The processor(s) 1402C may include, for example, one or more central processing units, graphics processing units (GPUs), or other application-specific integrated circuits (ASIC), and the like. To illustrate, the processor(s) 1402C may include an application processor (AP) utilized by the UE 102 to execute an operating system and various user-level software applications, as well as one or more processors utilized by modems or a baseband processor. The computer readable media / memory (CRM) 1402D may include any suitable memory or storage device such as randomaccess memory (RAM), static RAM (SRAM), dynamic RAM (DRAM), non-volatile RAM (NVRAM), read-only memory (ROM), Flash memory7, solid-state drive (SSD) or other massstorage devices, and the like useable to store one or more sets of executable software instructions and associated data that manipulate the one or more processor(s) 1402C and other components of the processing hardware 1412 to perform the various functions described herein and attributed to the UE 102. The sets of executable software instructions include, for example, an operating system (OS) and various drivers (not shown), and various software applications (not shown), which are executable by processor(s) 1402C to enable user-plane communication, control -plane signaling, and user interaction with the UE 102.

[0121] It is desirable to enable NB-IoT UE support for coarse location reporting over satellite access. Lacking sufficiently accurate user location information (ULI) reported to the MME from a massive quantity of NB-IoT UEs located within an loT NTN coverage area across multiple regulatory areas would result in significant unnecessary7signaling overheads. For example, the MME could proceed with MM / SM procedures but eventually fail location verification or reject the MM / SM requests from the NB-IoT UE. Furthermore, network operators, satellite service providers, and device vendors seem increasingly interested in enabling NB-IoT UEs to report coarse location information when the NB-IoT UEs access loT NTN.

[0122] RRC reporting of UE Coarse Location is possible based on 3GPP TS 36.331 / 38.331 using UEInformationRequest / UEInformationResponse messages for eMTC, NR UE using UECapabilityEnquiryl UEC apability Information messages after successful security activation. Some aspects of this disclosure enable RRC based coarse location reporting adapted for NB-IoT UE.

[0123] NB-IoT UEs differ from NR UEs in that the NB-IoT UEs focus on low-power, low- throughput applications where exact location may not be a requirement. Furthermore, it is less desirable for an NB-IoT UE to provide location information over the access stratum to an eNB due to limited bandwidth, and simplified radio design. Other limitations regarding NB-IoT UE reporting coarse location include security and privacy concerns from operators and regulators. According to some aspects of this disclosure, coarse location reporting is enabled on a per-UE basis for NB-IoT UEs. The network can determine whether this feature can be enabled for an NB-IoT UE based on the following criteria: for a specific RAT. e.g. NB-IoT UE over satellite access, NB-IoT UE capability support for location reporting, network support for location reporting, security and privacy requirements from network operator and regulator, and / or whether the NB-IoT UE subscription includes user consent or indication for permitting coarse location reporting.

[0124] Some aspects of this disclosure enable network initiated RRC based coarse location reporting. UE subscription information can include an allowed coarse location reporting indication (sometimes referred to as allowed location reporting indication) that refers to user consent and / or requirement of operator and regulator. The MME’s functionality can store the allowed coarse location reporting indication as received from an HSS within the MME's stored UE context. The MME can determine whether a NB-IoT UE allows for coarse location reporting, and request location reporting from an eNodeB if the target NB-IoT UE is eligible for coarse location reporting. Procedures for network initiated RRC based coarse location reporting can include: an Attach procedure in which the MME checks whether a NB-ToT UE allows coarse location reporting, and / or a location reporting procedure that supports a new request type for coarse location information.

[0125] In some aspects, 3GPP TS 23.401 is modified to support network initiated RRC based coarse location reporting. For example, 3GPP TS 23.401, section 5.7.1, can add a “Allowed location reporting indication” field to HSS data, where the “Allowed location reporting indication” indicates whether a NB-IoT UE allows for coarse location reporting which can refer to user consent, restriction from operator, and / or restriction from a regulator. In some implementations, the “Allowed location reporting indication” includes differentvalues for HPLMN and roaming case. In some implementations, the “Allowed location reporting indication” includes different values specific to one or more RATs (such as NB- loT RAT over satellite access).

[0126] FIG. 15A and FIG. 15B shows an example Attach procedure based on 3GPP TS 23.401, section 5.3.2, the contents of which are incorporated by reference in this Patent Application. For brevity, proposed modifications are described while legacy aspects are omitted. In some implementations, the HSS acknowledges an Update Location message (1532) by sending an Update Location Ack (1538) message to the MME, where the Update Location Ack includes subscription data having an “Allowed Coarse Location reporting Indication” (which alternatively may be referred to as an “allowed location reporting indication” or “coarse location reporting indication”). In some implementations, the “Allowed Coarse Location reporting Indication” applies to the UEs on a specific RAT (e.g. NB-IoT). If received from the HSS, the MME stores the Allowed Coarse Location reporting Indication in the MME MM context. The MME initiates Location Reporting Procedure to the RAN as defined in 3GPP TS 23.401 section 5.9.1 or Location Change Reporting Procedure as defined in 3GPP TS 23.401 section 5.9.2. In some implementations, the MME only initiates the Location Reporting Procedure or Location Change Reporting Procedure if the Allowed Coarse Location Reporting Indication is active and the NB-IoT UE is over Satellite access.

[0127] FIG. 16 shows an example Location Reporting procedure based on 3GPP TS 23.401, section 5.9.1, the contents of which are incorporated by reference in this Patent Application. For brevity, proposed modifications are described while legacy aspects are omitted. In some implementations, the location reporting procedure is adapted so that the MME can request the eNodeB to report where a UE is currently located. The MME sends a Location Reporting Control message (1688A) to the eNodeB. The Location Reporting Control message can identity the UE(s) for which reports are requested, the requested location information and may contain information such as reporting type. Absent the techniques of this disclosure, a location reporting procedure triggers a location information report that includes TAI+EGCI, and PSCell ID, if requested by the MME. According to aspects of this disclosure, the requested location information includes coarse location information. In some implementations, the reporting type indicates whether the message is intended to trigger: a single stand-alone report about the current Cell ID serving the UE; or start the eNodeB to report whenever the UE changes cell; or coarse location information. Thus, the reporting type can instruct the eNodeB to trigger reporting of coarse location information about the UE.

[0128] In response to the Location Reporting Control message, the eNodeB sends a Location Report message (1688B) informing the MME about the location of the UE(s). The Location Report message includes the requested location information. In some implementations, if the MME requests UE location of coarse location information, the MME may apply it only for a particular RAT (e g., NB-IoT UE over satellite access) and the MME's UE context stores the active Allowed location reporting indication. Alternatively, if the MME requests UE location of TAI+EGCI (e.g., different from coarse location information), in the case of satellite access for Cellular loT, the eNodeB provides all broadcast TAIs to the MME as part of the ULI. The eNodeB also reports the TAI where the UE is geographically located if this TAI can be determined. The cell and TAI reporting by eNodeB refer to a fixed cell and fixed TA in which a UE is geographically located.

[0129] FIG. 1 through FIG. 16 and the operations described herein are examples meant to aid in understanding example implementations and should not be used to limit the potential implementations or limit the scope of the claims. Some implementations may perform additional operations, fewer operations, operations in parallel or in a different order, and some operations differently.

[0130] The foregoing disclosure provides illustration and description but is not intended to be exhaustive or to limit the aspects to the precise form disclosed. Modifications and variations may be made in light of the above disclosure or may be acquired from practice of the aspects. While the aspects of the disclosure have been described in terms of various examples, any combination of aspects from any of the examples is also within the scope of the disclosure. The examples in this disclosure are provided for pedagogical purposes. Alternatively, or in addition to the other examples described herein, examples include any combination of the following implementation options (enumerated as clauses for clarity).

[0131] Clause 1. A method by a core network of a wireless communication system, the method including: receiving a registration request for a user equipment (UE) requesting access to the core network via a narrowband internet-of-things non-terrestrial network (NB- ToT NTN) radio access network (RAN); obtaining UE-specific parameters that indicate whether coarse location reporting is allowed for the UE; provisioning the coarse location reporting associated with the UE based on the UE-specific parameters: and receiving location information for the UE based on the coarse location reporting.

[0132] Clause 2. The method of clause 1, where a first network entity of the core network performs the obtaining the UE-specific parameters and the obtaining further includesreceiving at least one of the UE-specific parameters from a second network entity’ of the core network or the NB-IoT NTN RAN.

[0133] Clause 3. The method of clause 1 or 2, where the obtaining the UE-specific parameters includes receiving at least one of the UE-specific parameters from the UE via a Non-Access Stratum (NAS) registration request message or a Radio Resource Control (RRC) message to the NB-IoT NTN RAN.

[0134] Clause 4. The method of clause 2. where the first network entity is an Access and Mobility Management Function (AMF), and where the obtaining the UE-specific parameters includes receiving, at the AMF, a Unified Data Management (UDM) message including the UE-specific parameters from a UDM entity.

[0135] Clause 5. The method of clause 4, where the obtaining the UE-specific parameters includes sending, from the AMF, a request message to the UDM to request the UE-specific parameters; and where the receiving the UDM message from the UDM including the UE- specific parameters is in response to the request message.

[0136] Clause 6. The method of clause 4 or 5, where the UDM message is: a Network UDM subscriber data management (SDM) notification, or a Network UDM user equipment configuration management (UECM) registration message.

[0137] Clause 7. The method of clause 2 or 3, where the first network entity’ is a Mobility Management Entity (MME), and where the obtaining the UE-specific parameters includes receiving, at the MME, a subscription information message including the UE-specific parameters from a Home Subscriber Server (HSS) entity of the core network.

[0138] Clause 8. The method of clause 7, where the obtaining the UE-specific parameters includes sending, from the MME, a request message to the HSS to request the UE-specific parameters; and where the receiving the subscription information message from the HSS including the UE-specific parameters is in response to the request message.

[0139] Clause 9. The method of any one of clauses 1 to 8, where the UE-specific parameters include an allowed location reporting indication.

[0140] Clause 10. The method of any one of clauses 1 to 9, where the provisioning the coarse location reporting includes transmitting, from the first network entity’, an allowed location reporting indication to the UE via a downlink (DL) Non-Access Stratum (NAS) message.

[0141] Clause 11. The method of clause 10, where the DL NAS message is: a NAS registration accept message, a downlink NAS transport (DL_NAS_TRANSPORT) message, or a UE configuration update command message.

[0142] Clause 12. The method of any one of clauses 1 to 11, further including: obtaining UE capability information indicating whether the UE supports location reporting, where the UE-specific parameters include the UE capability information.

[0143] Clause 13. The method of clause 12, where the obtaining the UE capabilityinformation includes at least one of: receiving the UE capability information with the registration request; querying the UE for the UE capability- information; or query ing the NB- loT NTN RAN for the UE capability information.

[0144] Clause 14. The method of any one of clauses 1 to 13, where the provisioning of the coarse location reporting includes communicating an allowed location reporting indication to the NB-IoT NTN RAN.

[0145] Clause 15. The method of clause 14, further including: communicating the allowed location reporting indication to UE via the NB-IoT NTN RAN based on a Radio Resource Control (RRC) protocol.

[0146] Clause 16. The method of any one of clauses 1 to 15, where the provisioning the coarse location reporting includes: communicating the allowed location reporting indication from the first network entity- to the UE via a DL NAS message.

[0147] Clause 17. The method of any one of clauses 1 to 16, where the receiving location information for the UE includes: receiving the location information from the UE via a UL NAS message; or receiving the location information from the NB-IoT NTN RAN via a network message (via N2 interface).

[0148] Clause 18. The method of any one of clauses 1 to 17, where the UE-specific parameters include any one or more of the following criteria: UE capability- information indicating whether the UE supports location reporting; subscription information indicating whether the UE is allowed to enable coarse location reporting or not; operator / network policy indicating whether an operator or a particular network is configured for the coarse location reporting; user consent information indicating whether a user consents to the coarse location reporting; a configuration of a home public land mobile network (HPLMN) associated with the UE; a visited public land mobile network (VPLMN) associated with the NB-IoT NTN RAN; a list of networks enabled for the coarse location reporting; an indication whether the coarse location reporting is allowed for the UE based on one or more radio access technology (RAT) types that include a first RAT type of the NB-IoT NTN RAN; a geographic locationrestriction or permission based on a location of the NB-IoT NTN RAN; or one or more regulatory requirements based on geographic boundary, network, or UE type.

[0149] Clause 19. A method by a user equipment (UE) of a wireless communication system, the method including: transmitting a registration request to a core network with a narrowband internet-of-things non-terrestrial network (NB-IoT NTN) radio access network (RAN); receiving an allowed location reporting indication from the NB-IoT NTN RAN or the core network, where the allowed location reporting indication provisions coarse location reporting; and transmitting location information for the UE based on the coarse location reporting.

[0150] Clause 20. The method of clause 19, further including: providing one or more UE- specific parameters to assist the NB-IoT NTN RAN or the core network to determine whether the coarse location reporting is allowed for the UE.

[0151] Clause 21. The method of clause 19 or 20, further including: providing UE capability' information indicating whether the UE supports the coarse location reporting.

[0152] Clause 22. The method of any one of clauses 19 to 21, further including: receiving network capability support indicating whether the core network supports the coarse location reporting.

[0153] Clause 23. The method of any one of clauses 19 to 22, further including: enabling or disabling the coarse location reporting based on the allowed location reporting indication.

[0154] Clause 24. The method of any one of clauses 19 to 23, further including: enabling the coarse location reporting when a Non-Access Stratum (NAS) message or a Radio Resource Control (RRC) message includes the allowed location reporting indication; and refraining from enabling the coarse location reporting when the NAS message or the RRC message excludes the allowed location reporting indication.

[0155] Clause 25. The method of any one of clauses 19 to 23, further including: enabling the coarse location reporting when a Non-Access Stratum (NAS) message or a Radio Resource Control (RRC) message includes a field for the allowed location reporting indication; and the field is set to a first value and refraining from enabling the coarse location reporting when the field is set to a second value.

[0156] Clause 26. The method of any one of clauses 19 to 25. further including: receiving a Radio Resource Control (RRC) message containing a UE capability enquiry; and responding to the UE capability enquiry with UE capability information indicating whether the UE supports the coarse location reporting.

[0157] Clause 27. An apparatus, including: a communication unit; and a processing system configured to control the communication unit to implement any one of the methods of any one of clauses 1 to 26.

[0158] Clause 28. The apparatus of clause 27, where the apparatus is a narrowband internet- of-things (NB-IoT) user equipment (UE).

[0159] Aspects of the subject matter described in this disclosure can be implemented as a computer-readable medium having stored therein instructions which, when executed by a processor, causes the processor to perform any one of the above-mentioned functionalities. Aspects of the subject matter described in this disclosure can be implemented as a system having means for implementing any one of the above-mentioned functionalities. Aspects of the subject matter described in this disclosure can be implemented as an apparatus having one or more processors configured to perform one or more operations from any one of the above- mentioned functionalities.

[0160] The following additional considerations may apply to the foregoing and the following discussions.

[0161] Unless defined otherwise, technical and scientific terms used herein have the same meaning as is commonly understood by one of ordinary skill in the art to which this specification belongs. The terms “first”. “second’; and the like, as used herein do not denote any order, quantity, or importance, but rather are used to distinguish one element from another. The use of terms “including,” “comprising” or “having” and variations thereof herein are meant to encompass the items listed thereafter and equivalents thereof as well as additional items. The terms “connected” and “coupled” are not restricted to physical or mechanical connections or couplings and can include electrical connections or couplings, whether direct or indirect. Furthermore, terms “circuit” and “circuitry” and “control unit” may include either a single component or a plurality of components, which are either active and / or passive and are connected or otherwise coupled together to provide the described function. In addition, the term operationally coupled as used herein includes wired coupling, wireless coupling, electrical coupling, magnetic coupling, radio communication, softwarebased communication, or combinations thereof.

[0162] Some or all of the foregoing or the following implementations can be jointly combined or formed to be a new or another one implementation. The foregoing or the following techniques can be used to solve at least (but not limited to) the issue(s) or scenario(s) mentioned in this disclosure. Any two or more than two of the foregoing or the following paragraphs, (sub)-bullets, points, actions, or claims described in eachmethod / technique / implementation may be combined logically, reasonably, and properly to form a specific method. Any sentence, paragraph, (sub)-bullet, point, action, or claim described in each of the foregoing or the following technique(s) / implementation(s) / concept(s) may be implemented independently and separately to form a specific method. Dependency, such as "based on," "more specifically,'’ “where” or etc., in technique(s) / implementation(s) / concept(s) mentioned in this disclosure is just one possible implementation which would not restrict the specific method.

[0163] Generally speaking, description for one of the above figures can apply to another of the above figures. Examples, implementations and methods described above can be combined, if there is no conflict. An event or block described above can be optional or omitted. For example, an event or block with dashed lines in the figures can be optional. In some implementations, “message” is used and can be replaced by “information element (IE),” and vice versa. In some implementations, “IE” is used and can be replaced by “field,” and vice versa. In some implementations, “configuration” can be replaced by “configurations” or “configuration parameters,” and vice versa. In some implementations, “some” means “one or more.” In some implementations, “at least one” means “one or more.”

[0164] As used herein, the terms “user device”, “user equipment” (for example, UE 102), “wireless communication device”, “mobile communication device”, “communication device"’, or “mobile device” refer to any one or all of cellular telephones, smartphones, portable computing devices, personal or mobile multi-media players, laptop computers, tablet computers, smartbooks, Intemet-of-Things (loT) devices, palm-top computers, wireless electronic mail receivers, multimedia Internet enabled cellular telephones, wireless gaming controllers, display sub-systems, driver assistance systems, vehicle controllers, vehicle system controllers, vehicle communication system, infotainment systems, vehicle telematics systems or subsystems, vehicle display systems or subsystems, vehicle data controllers, point- of-sale (POS) terminals, health monitoring devices, drones, cameras, media-streaming dongles or another personal media devices, wearable devices such as smartwatches, wireless hotspots, femtocells, broadband routers or other types of routers, and similar electronic devices which include a programmable processor and memory and circuitry configured to perform operations as described herein. Further, the user device in some cases may be embedded in an electronic system such as the head unit of a vehicle or an advanced driver assistance system (ADAS). Still further, the user device can operate as an intemet-of-things (loT) device or a mobile-internet device (MID). Depending on the type, the user device caninclude one or more general-purpose processors, a computer-readable memory, a user interface, one or more network interfaces, one or more sensors, etc.

[0165] Certain techniques are described in this disclosure as including logic or a number of components or modules. Modules can be software modules (e g., code, or machine-readable instructions stored on non-transitory machine-readable medium) or hardware modules. A hardware module is a tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. A hardware module can comprise dedicated circuitry or logic that is permanently configured (e.g, as a special-purpose processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC), a digital signal processor (DSP), etc.) to perform certain operations. A hardware module may also comprise programmable logic or circuitry (e.g, as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. The decision to implement a hardware module in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g, configured by software) may be driven by cost and time considerations.

[0166] When implemented in software, the techniques can be provided as part of the operating system, a library used by multiple applications, a particular software application, etc. The software can be executed by one or more general-purpose processors or one or more special-purpose processors.

[0167] As used herein, the terms ‘'component” and “module” are intended to be broadly construed as hardware, firmware, or a combination of hardware and software. As used herein, a processor is implemented in hardware, firmware, or a combination of hardware and software. As used herein, the phrase “based on” is intended to be broadly construed to mean “based at least in part on.”

[0168] As used herein, a phrase referring to a list of items separated by “or” refers to any combination of those items, including single members. For example, “a, b. or c” is intended to cover the possibilities of: a only, b only, c only, a combination of a and b, a combination of a and c, a combination of b and c, and a combination of a and b and c.

[0169] In this disclosure, an expression of ‘‘X / Y" may include meaning of any of the following: “X or Y” or “X and Y” or '‘X and / or Y." An expression of “(A) B” or “B (A)” may include concept of “only B.” An expression of “(A) B” or “B (A)” may include the concept of “A+B” or “B+A.”

[0170] In this disclosure, the term "can" indicates a capability, or alternatively indicates a possible implementation option. The term "may" indicates a permission or a possible implementation option.

[0171] Some aspects are described herein in connection with thresholds. As used herein, satisfying a threshold may refer to a value being greater than the threshold, greater than or equal to the threshold, less than the threshold, less than or equal to the threshold, equal to the threshold, not equal to the threshold, or the like.

[0172] The various illustrative components, logic, logical blocks, modules, circuits, operations and algorithm processes described in connection with the implementations disclosed herein may be implemented as electronic hardware, firmware, software, or combinations of hardware, firmware or software, including the structures disclosed in this specification and the structural equivalents thereof. The interchangeability of hardware, firmware and software has been described generally, in terms of functionality, and illustrated in the various illustrative components, blocks, modules, circuits and processes described above. Whether such functionality is implemented in hardware, firmware or software depends upon the particular application and design constraints imposed on the overall system.

[0173] As described above, some aspects of the subject matter described in this specification can be implemented as software. For example, various functions of components disclosed herein, or various blocks or steps of a method, operation, process or algorithm disclosed herein can be implemented as one or more modules of one or more computer programs. Such computer programs can include non-transitory processor-executable or computer-executable instructions encoded on one or more tangible processor-readable or computer-readable storage media for execution by, or to control the operation of, a data processing apparatus including the components of the devices described herein. By way of example, and not limitation, such storage media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that may be used to store program code in the form of instructions or data structures. Combinations of the above should also be included within the scope of storage media.

[0174] Various modifications to the implementations described in this disclosure may be readily apparent to persons having ordinary skill in the art, and the generic principles defined herein may be applied to other implementations without departing from the scope of this disclosure. Thus, the claims are not intended to be limited to the implementations shownherein but are to be accorded the widest scope consistent with this disclosure, the principles and the novel features disclosed herein.

[0175] Additionally, various features that are described in this specification in the context of separate implementations also can be implemented in combination in a single implementation. Conversely, various features that are described in the context of a single implementation also can be implemented in multiple implementations separately or in any suitable subcombination. As such, although features may be described above as acting in particular combinations, and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

[0176] The drawings may schematically depict one or more example processes in the form of a flowchart or flow diagram. However, other operations that are not depicted can be incorporated in the example processes that are schematically illustrated. For example, one or more additional operations can be performed before, after, simultaneously, or between any of the illustrated operations. In some circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the implementations described above should not be understood as requiring such separation in all implementations, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products. Additionally, other implementations are within the scope of the following claims. In some cases, the actions recited in the claims can be performed in a different order and still achieve desirable results.

Claims

CLAIMSWhat is claimed is:

1. A method of an Access and Mobility Management Function (AMF) or a Mobility Management Entity (MME) of a wireless communication system, the method comprising: receiving, from a user equipment (UE), a request message requesting access to a core network via a radio access network (RAN) node of the wireless communication system; obtaining an allowed location reporting indication that enables coarse location reporting for the UE based on at least one of the UE being an internet of things (loT) UE, UE capability, user consent, or a radio access technology (RAT) of the RAN node; and causing the RAN node to provision the coarse location reporting associated with the UE based on the allowed location reporting indication.

2. The method of claim 1, wherein the causing the RAN node to provision the coarse location reporting includes: communicating, to the RAN node, a Location Reporting control message that indicates a reporting type associated with the coarse location reporting; and receiving coarse location information of the UE via the RAN node.

3. The method of claim 2, wherein the receiving the coarse location information includes: receiving the coarse location information from the UE via a UL NAS message transported by the RAN node; or receiving the coarse location information from the RAN node via an N2 interface between the RAN node and the AMF or MME.

4. The method of any one of claims 1 to 3, wherein the allowed location reporting indication enables the coarse location reporting based on RAT specific parameters for a satellite RAT associated with the RAN.

5. The method of any one of claims 1 to 4, further comprising: obtaining UE capability information indicating whether the UE supports the coarse location reporting, wherein the obtaining the UE capability information includes at least one of: receiving the UE capability information in the request message from the UE; querying the UE for the UE capability information; or querying the RAN node for the UE capability information.

6. The method of any one of claims 1 to 5, further comprising: determining whether to trigger the coarse location reporting at the RAN node or the UE based on UE-specific parameters that include any one or more of the following criteria:UE capability7information indicating whether the UE supports the coarse location reporting; subscription information indicating whether the UE is allowed to enable the coarse location reporting or not; operator / network policy indicating whether an operator or a particular network allows the coarse location reporting; user consent information indicating whether a user consents to the coarse location reporting; a configuration of a home public land mobile network (HPLMN) associated with the UE; a visited public land mobile network (VPLMN) associated with a particular RAT; a list of networks enabled for the coarse location reporting; an indication whether the coarse location reporting is allowed for the UE based on one or more RAT types that include a first RAT ty pe of the RAN node; a geographic location restriction or permission based on a location of the RAN node; or one or more regulatory requirements based on geographic boundary7, network, or UE type.

7. The method of any one of claims 1 to 6, wherein the obtaining the allowed location reporting indication includes: receiving subscription information from a Home Subscriber Server (HSS) entity or a Unified Data Management (UDM) entity of the core network, the subscription information including the allowed location reporting indication; and storing the allowed location reporting indication in the AMF's or MME's UE context for the UE.

8. The method of claim 7, wherein the subscription information includes one or more of: internet of things (loT) non-terrestrial network (NTN) service subscription information; user consent for the coarse location reporting; orone or more allowed location reporting indications in association with applicable network information, wherein the applicable network information includes one or more of an identification (ID) of a Home public land mobile network (HPLMN) or a non-public network (NPN); a list of network IDs; and / or a list of combinations of network ID and RAT.

9. The method of any one of claims 1 to 8, wherein the allowed location reporting indication enables the coarse location reporting based on the RAT of the RAN node being a narrowband loT (NB-IoT) non-terrestrial network (NTN) RAT and the UE being an NB-IoT UE.

10. A method by a radio access network (RAN) node of a wireless communication system, the method comprising: receiving, from a user equipment (UE), a request message requesting access to a core network via the RAN node; transmitting the request message to the core network; receiving a location reporting control message that triggers coarse location reporting for the UE based on at least one of: the UE being an internet of things (loT) UE, UE capability7, user consent, or a radio access technology7(RAT) of the RAN node; and providing coarse location information of the UE to the core network.

11. The method of claim 10, further comprising: enabling or disabling the coarse location reporting based on an allowed location reporting indication from the UE or the core network.

12. The method of claim 10, further comprising: enabling the coarse location reporting when a Non-Access Stratum (NAS) message or a Radio Resource Control (RRC) message includes an allowed location reporting indication; or refraining from enabling the coarse location reporting when the NAS message or the RRC message excludes the allowed location reporting indication.

13. The method of claim 10, further comprising: receiving an allowed location reporting indication from the core network;transmiting a Radio Resource Control (RRC) message to the UE to request coarse location information of the UE based on the allowed location reporting indication; receiving the UE location information; storing the UE location information in a UE context for the UE; and wherein the providing the coarse location information includes transmitting a location report message to the core network, the location report message including the coarse location information based on the UE location information and the allowed location reporting indication.

14. The method of any one of claims 10 to 13, wherein the providing the coarse location information includes: transporting the coarse location information via a UL NAS message from the UE to the core network; or transmitting the coarse location information from the RAN node to the core network via an N2 interface between the RAN node and the core network.

15. The method of any one of claims 10 to 14, wherein the providing the coarse location information includes: enabling the coarse location reporting based on RAT specific parameters for a nonterrestrial network (NTN) RAT when the RAT of the RAN node is the NTN RAT and the UE is the loT UE.

16. An apparatus, comprising: a communication unit; and a processing system configured to control the communication unit to implement any one of the methods of any one of claims 1 to 15.

Images