CN117730582A - New air interface positioning reference signal enhancement - Google Patents

Abstract

The radio network reference signal (PRS) may be dynamically managed via a User Equipment (UE) request triggered by a measurement according to an initial PRS configuration, whereby the UE contacts an access and mobility management function (AMF) and/or a Location Management Function (LMF). Similarly, the LMF may initiate adjustment of PRS configuration and transmission via communication with a base station, UE, and/or AMF. For example, dynamic signaling of PRS configuration may be implemented via legacy protocols and/or new air interface positioning protocol a (NRPPa). The request from the UE for PRS configuration adjustment may include, for example, an indication of a desired service level or class of service and/or an indication of signal measurement, a location estimate, an indication of a capability of the UE.

Description

New air interface positioning reference signal enhancement

Cross Reference to Related Applications

The present application claims the benefit of U.S. provisional patent application 63/168,369 entitled "New air interface positioning reference Signal enhancement (New Radio Positioning Reference Signal enhancements)" filed on 3/31 of 2021 and co-owned U.S. provisional patent application 63/185,642 filed on 5/7 of 2021, the contents of which are hereby incorporated by reference.

Background

The present disclosure relates to the operation of devices on a wireless network, such as those described in: 3GPP TS 38.305 phase 2 functional specification (Rel-16) for User Equipment (UE) positioning in NG-RAN; 3GPP TS 37.355LTE positioning protocol (LPP), version 16;3GPP TS 38.331 Radio Resource Control (RRC) protocol Specification (release 16); 3GPP TS 38.413,NGAP (NG application protocol); 3GPP TS 38.445NR positioning protocol A (NRPPa), version 16;3GPP TS 38.211,NR, physical channel and modulation (Rel-16); 3GPP TS 38.300,NR and NG-RAN general description; stage 2 (version 16); 3GPP TR 38.857, study on NR location enhancement (release 17); 3GPP TS 38.212,NR; multiplexing and channel coding (version 16); 3GPP TS 38.321,NR; medium Access Control (MAC) protocol (version 16); 3GPP TS 36.331, evolved universal terrestrial radio Access (E-UTRA); radio Resource Control (RRC) (release 16); 3GPP TS 36.300, evolved universal terrestrial radio Access (E-UTRA) and evolved universal terrestrial radio Access network (E-UTRAN); a general description; stage 2 (version 16).

Disclosure of Invention

For example, the efficiency of radio network operation may be improved by using dynamic positioning reference signals. For example, a User Equipment (UE) may be provided with an initial configuration for Positioning Reference Signal (PRS) operations, where the initial configuration includes criteria for determining when assistance with respect to such positioning reference signals is requested from a network. When the criterion is met, the UE may send a location services (LCS) request to an access and mobility management function (AMF), and then receive an updated PRS configuration from the Location Management Function (LMF). The LMF may also provide initial and updated PRS configurations to the base station/gNB. Similarly, the UE may send a PRS resource request to the LMF based on the measurements and trigger criteria.

The request from the UE may include, for example, an indication of a desired service level or class of service and/or an indication of signal measurements, location estimates, or an indication of the capabilities of the UE.

PRS configurations may be exchanged using a new air interface positioning protocol A, NRPPa and/or via RRC or legacy protocols. The PRS configuration may include an indication of a period of time and/or a positioning system information block (posSIB) for which the updated PRS configuration is to be used.

This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to solving any or all disadvantages noted in any part of this disclosure.

Drawings

A more detailed understanding of the description may be had by way of example only, given below in connection with the accompanying drawings.

Fig. 1 is a block diagram of an exemplary CP/UP architecture.

Fig. 2 is a block diagram of an example of an NR positioning interface and node.

Fig. 3 is a call flow of an example of a general LCS procedure.

Fig. 4 is a call flow of an example of LPP messaging for a single location/measurement request.

Fig. 5 is a block diagram illustrating a multi-point positioning technique.

Fig. 6 is a call flow of an example of a UE request for reference signal reconfiguration.

Fig. 7 is a flow chart of an example of UE criteria for triggered PRS (re) configuration.

Fig. 8 is a call flow of an example LMF initiated PRS transmission configuration.

Figure 9 is a flow chart of an example of an LMF initiated location reconfiguration procedure.

Fig. 10A illustrates an exemplary communication system.

Fig. 10B-10D are system diagrams of an exemplary RAN and core network.

Fig. 10E illustrates another exemplary communication system.

Fig. 10F is a block diagram of an exemplary apparatus or device, such as a WTRU.

FIG. 10G is a block diagram of an exemplary computing system.

Detailed Description

Many of the abbreviations used herein are described in the annex's item 22.

NR PRS context, use case and deployment scenario

Version 16NR positioning protocol and signal

Positioning protocols and RAN-based positioning signals have been specified in 3GPP since release 9LTE for implementing emergency services and location-based services.

In Rel-16, the Control Plane (CP) positioning architecture supports the 3GPP NR positioning protocol. A Secure User Plane Location (SUPL) server (also known as a SUPL Location Platform (SLP)) that may utilize any IP bearer may also support the NR architecture. Interworking for CP and UP positioning solutions is defined in TS 38.305, where SUPL may also be used as a tunnel for CP positioning protocols (e.g., LPP). See 3GPP TS 38.305, stage 2 functional Specification for User Equipment (UE) positioning in NG-RAN (Rel-16). See fig. 1.

The associated positioning nodes and interfaces are shown in fig. 2, which also includes a conventional LTE interface. The 3GPP has defined various protocols to implement positioning techniques and methods, such as GNSS, sensors, positioning signals, etc. The main protocol LPP (LTE positioning protocol) is terminated between the UE and the LMF (location management function). LPP is a point-to-point LCS and NAS messaging protocol defined in 3GPP TS 37.355LTE positioning protocol (LPP), release 16. Since Rel-15, LPP was agreed for reuse in NR and will continue to be utilized.

RRC (radio resource control) is another protocol for providing the transmission of LPP messages and other positioning procedures over the NR-Uu interface, which terminates between the gNB and the UE. See 3gpp TS 38.331, radio Resource Control (RRC) protocol specification (release 16).

On the network side, NGAP (NG application protocol) terminates between AMF and NG-RAN node (i.e. gNB/TRP) and serves as transport of LPP and NRPPa messages over NG-C interface. See 3GPP TS 38.413,NGAP (NG application protocol).

Finally, NRPPa (NR positioning protocol a) carries information between NG-RAN nodes and LMF. See 3gpp TS 38.445nr positioning protocol a (NRPPa), release 16.

From the protocol perspective of Rel-16, fig. 3 shows a general LCS flow employed from TS 38.305.

In step 1a, some entity in 5GC (e.g., GMLC-gav mobile location center) requests some location service (e.g., location) for the target UE from the serving AMF. Alternatively, in step 1b, the serving AMF of the target UE determines that some location service is needed (e.g. locating the UE for an emergency call). Alternatively, in step 1c, the UE requests a certain location service (e.g. delivery of positioning or assistance data) from the serving AMF at NAS level.

In step 2, the AMF passes a location services request to the LMF.

In step 3a, the LMF initiates a positioning procedure with the serving and possibly neighboring NG-eNB or gNB in the NG-RAN, e.g. to obtain positioning measurements or assistance data.

In step 3b, the lmf initiates a positioning procedure with the UE, e.g. to obtain a position estimate or a positioning measurement or to communicate position assistance data to the UE, in addition to or instead of step 3 a.

In step 4, the LMF provides a location service response to the AMF and includes any required results, such as a success or failure indication, and if requested and obtained, a location estimate for the UE.

In step 5a, if step 1a is performed, the AMF returns a location services response to the 5GC entity in step 1a and includes any required results, such as a location estimate for the UE.

In step 5b, if step 1b occurs, the AMF uses the location service response received in step 4 to assist in triggering the service of this case in step 1b (e.g., a location estimate associated with the emergency call may be provided to the GMLC).

In step 5c, if step 1c is performed, the AMF returns a location services response to the UE and includes any required results, such as a location estimate for the UE.

Looking more closely at the positioning procedure related to the UE procedure in step 3b of fig. 3, the LPP message related to the UE assisted location request is shown in fig. 4. In the example of fig. 4, the LMF requests UE capabilities in step 1 and the UE provides the capabilities in step 2. In step 3, the UE receives assistance data, and in step 4, the UE receives location information from the LMF. The LMF-to-UE positioning assistance data may include information/configuration. Broadcast of positioning Assistance Data (AD) is supported via positioning system information blocks (possibs) and carried in SI messages. See 3gpp TS 38.331 and 3gpp TS 38.413.

In step 5 of fig. 4, the UE transmits an RRC position measurement indication, and in step 6, the gNB/TRP transmits an RRC measurement gap configuration. In step 7, the UE makes a measurement, which is relayed in step 8. In step 9, the LMF performs its calculations.

NR location use case

Positioning may be implemented in standalone, UE-based or UE-assisted modes.

In standalone positioning, the UE processes all aspects of positioning, scans for accessible positioning sources, makes measurements and processes positioning signals/sources. Finally, the UE calculates its own position in 2 or 3 dimensions. In independent positioning, uu interface impact includes UE capability exchange and UE location reporting.

In UE-based positioning (UE-B), the network provides acquisition assistance data, and the UE scans for accessible positioning sources, makes measurements, and processes positioning signals/sources (based on assistance information from the network). Finally, the UE calculates its own position in 2 or 3 dimensions and can report its position to the network.

In UE-assisted positioning (UE-a), the network provides acquisition assistance and UE scanning may access a positioning source, measure a positioning signal/source (based on assistance information from the NW). Finally, the UE returns the measurements to the network and the network calculates the device location (at the location server/LMF). See TS 38.305.

NR DL positioning reference signal

Recently, in Rel-16, 3GPP has defined enhanced positioning protocols, new positioning techniques, and new air interface (NR) based Positioning Reference Signals (PRS). NR PRS is approximately based on LTE pseudo-random sequences and specified in TS 38.211. The updated NR PRS further improves the "listening ability" of PRSs from neighboring cells. This results in improved positioning accuracy, but it depends on network deployment (e.g., density of gNB/TRP), RF conditions, and PRS configuration parameters such as bandwidth, periodicity, and muting patterns as further discussed.

DL-TDOA (DL time difference of arrival) is one such method that utilizes PRS transmissions broadcast from NG-RAN nodes. The UE performs a downlink reference signal time difference (DL-RSTD) measurement for each gNB/TRP PRS, and optionally performs a DL-PRS-RSRP. In the case of UE-a, these measurements are reported to the LMF (location management server/location server). For UE-B, the UE calculates and reports its location to the network.

Another DL technique using broadcasted PRSs is the AoD (departure angle) method. The UE measures PRS reference signal received power (DL RSRP) per beam/gNB. The measurement report is used to determine AoD based on the UE beam position for each gNB. For UE-a, the LMF then uses AOD to estimate UE location, or for UE-B, the UE calculates and reports its location to the network.

These multi-point positioning techniques depicted in fig. 5 are well known and established methods for positioning UEs. Geometrically, UE position is derived from each time/range difference (RSTD). Typically, reliable location requires a minimum of 3 gNB (geographically dispersed) measurements with respect to UE internal timing. This also requires timing/RSRP measurements from the serving (reference) cell and from neighboring cells.

TRP location and assistance data (configuration/source information) may be delivered over the Uu interface in NAS signaling by broadcast in positioning system information blocks (posSIB) and/or in LPP messages via rrc_connected.

DL PRS configuration technique

The IE NR-DL-PRS-Info defines a downlink PRS configuration that is sent from the network (e.g., LMF) to the UE, as defined in TS 37.355 (LPP). This assists the UE in receiving PRS transmissions from the serving cell and neighboring cells. See abstract syntax notation one (ASN.1) example of appendix item 1 and NR-DL-PRS-Info field description of appendix item 2.

PRS transmission configuration information and assistance data (e.g., NR-DL-PRS-Info) enable the UE to detect and measure positioning reference signals and calculate the UE position or send measurements to the network for calculation. Typically, this information is delivered to the UE in a P2P (point-to-point) manner in RRC connected mode via NAS (LPP) signaling.

Another alternative for the UE to receive PRS related IEs is via a positioning system information block (posSIB). The posSIB contains positioning assistance data associated with a variety of positioning techniques, including PRS related methods such as DL TDOA, DL-AoD, and multi-RTT.

The procedure for posSIB acquisition utilizes the same procedure as other SIBs (e.g., SIB2, SIB, etc.). For example, SIB1 contains scheduling information (PosSchedulingInfo-r 16) associated with the posSIB. These SIBs may be mapped to the BCCH and broadcast periodically on the DL-SCH, broadcast on demand on the DL-SCH (e.g., upon request from a UE in rrc_idle or rrc_inactive), or sent in a dedicated manner on the DL-SCH to a UE in rrc_connected.

The IEs broadcast in the posSIB are identical to those defined in LPP. Within 38.331, the RRC PosSystemInformation-r16-IE maps to a positioning SIB type (posSibType), where the detailed AD IE is defined in the LPP.

Some of the relevant IEs for PRS-related positioning methods are defined in TS 37.355 clause 6.4.3, 7.4.2 and then mapped in RRC to the following posSIBTypes: see table in appendix 3.

TR 38.857 conclusion

The studies on NR localization enhancement summarize many enhancements over the existing Rel-16 NR localization mechanism. That is, these general problems of the current PRS definitions are confirmed. See TR 38.857.

Efficiency is that: PRS uses revenue-generating BW, potentially adding interference.

NR PRS has unnecessary overhead and resource wastage during a certain time or without UE positioning in a certain coverage area of the network. If supported, the DL PRS is always broadcast from the gNB. In the case of beamformed DL-PRSs, DL-PRS transmissions in all beam scanning directions may result in unnecessary transmissions of DL-PRSs. Temporary changes in DL-PRS configuration/resources are suggested to meet higher positioning accuracy and/or lower latency positioning requirements in certain areas or at certain times.

Accuracy: DL-PRS configuration may be insufficient to meet the accuracy requirements of LCS clients; for example, there may be too little bandwidth, too little repetition, etc., as it is statically configured from the LMF. Network deployment and RF conditions are factors that affect the confidence/uncertainty of a location.

Delay time: the DL-PRS configuration may not be sufficient to meet the response time requirements of LCS clients, e.g. may have a periodicity that is too large, which is a static configuration parameter.

Finally, it is necessary to manage the tradeoff between efficiency, accuracy, and latency from both a UE and network perspective.

In view of these problems, in TR 38.857 Rel-17, from a top layer perspective, the following three approaches for on-demand PRS functionality can be used. The first is a UE-initiated request for on-demand DL-PRS transmission. The second is LMF-initiated on-demand control of DL-PRS transmissions. Third is a dynamic change of parameters, measurements and/or assistance information for LMF/UE initiated PRS on demand.

UL data transfer optimization

Positioning protocols typically require frequent transmission of small UL messages. A problem arises because NR supports only data transmission in the rrc_connected state. This means that positioning related UL data transmissions require frequent transitions between RRC states, which consumes energy and introduces signaling overhead.

Recently, 3GPP has begun to work on solving the problems of energy consumption and signaling overhead caused by small data. This improvement is called Small Data Transmission (SDT), where the main principle is to keep such UEs requiring frequent transmission of small UL data in rrc_inactive state and allow UL transmission of small data in rrc_inactive state. In this way, frequent RRC state transitions are avoided and energy consumption and overhead problems are alleviated. The details of SDTs are still discussed, but it is expected that they are based on a similar kind of concept to Early Data Transfer (EDT) features and cellular IoT optimisation in LTE.

Contemplated uses of NR SDT include procedures commonly associated with existing positioning protocols, such as the transfer of measurement and assistance data.

Exemplary challenges

Problem 1a: how a UE triggers, acquires and assists a network in modifying DL PRS resources for proper PRS resource allocation

As part of the Rel-17 study on NR localization enhancement, RAN2 agreed to: "UE-initiated request for on-demand DL-PRS transmission is recommended for specification work; the details will be decided during the WI stage. "

The existing UE positioning procedures and mechanisms as described in release 16 utilize static resources for PRS transmissions. This may result in an inefficient use of network resources because DL PRS transmissions are broadcast from the gNB in the absence of LCS/positioning procedures. In addition, PRS resources and configurations may require modification to meet higher demands for accuracy and latency requirements.

When the network changes the configuration of PRS transmissions, the impact on other nearby UEs (e.g., inter-cell interference) must also be identified and mitigated.

Problem 1b: how the network (gNB, LMF) evaluates and modifies DL PRS configuration and resources for one or more Appropriate PRS resource allocation for individual UEs

As part of the Rel-17 study on NR localization enhancement, RAN2 agreed to: "LMF-initiated on-demand control of DL-PRS transmissions is recommended for specification work; the details will be decided during the WI stage. "

Existing LMF positioning procedures and mechanisms utilize static configuration for PRS transmissions. This may result in an inefficient use of network resources because DL PRS transmissions are broadcast in the absence of LCS/positioning procedures. In addition, PRS resources and configurations may require modification to meet accuracy and latency requirements of one or more UEs or groups of UEs and possibly TRP/gNB. The LMF/network needs to have certain criteria, evaluations, and procedures to initiate modifications to PRS transmission configurations and resources.

Problem 2: how to minimize latency in positioning procedures associated with PRS related techniques

As part of the Rel-17 study on NR localization enhancement, RAN2 agreed to: "enhancements to signaling and procedures for reducing NR positioning latency" are recommended for regulatory work, including DL and DL+UL positioning methods. "

The existing Rel-16 NR positioning procedure incurs delays associated with the reception of DL PRS, the measurement and reporting and requesting of measurements, and the requesting and delivering of network assistance data. This latency can be further increased by introducing non-persistent PRS transmissions by the gNB/TRP and PRS (re) configuration procedure.

Problem 3: how to identify and mitigate PRS error sources to enhance integrity of positioning calculations and/or measurements

The existing Rel-16 NR positioning process does not adequately address the identification of error sources and the integrity (trustworthiness) of PRS reception. This may lead to an increase in uncertainty/confidence KPIs associated with PRS related measurements and positioning calculations. Error sources may include RF conditions such as NLoS (non-line of sight) and multipath, as well as inter-cell PRS interference. The identification and subsequent mitigation of these error sources may improve positioning accuracy, latency, and reliability.

Problem 4: how to identify cells supporting SDT

Existing 3GPP radio interface standardization methods assume that the network has complete knowledge of the UE capabilities. This is a prerequisite for RRC configuration of the UE and a main mechanism to ensure interoperability and mobility in rrc_connected state.

This situation is different for SDT procedures in rrc_inactive state, because the transmitting entity (UE) is not aware of the capabilities of the receiving entity (radio access network node). If the UE triggers UL data transmission in rrc_inactive state but the cell does not implement SDT feature, the procedure will fail because the network cannot receive data. This may occur after a cell selection and reselection procedure, which is the only mobility procedure in the rrc_inactive state.

It is worth emphasizing that it is not practical to assume that all networks will always support the SDT procedure in all cells for a number of reasons. Depending on how quickly the network deployment, operator preferences, and network equipment providers introduce new features.

Real-life network deployments typically have a mix of devices from different vendors, and all vendors do not push out software updates and new features at the same time. Generally, upgrades of nodes (tens of thousands of nodes) in a large network can take weeks even if the operator has only one vendor's equipment. It is also typical that some of the old network nodes cannot be upgraded due to hardware limitations to support up-to-date features or software updates. Thus, a real-life network deployment may have a border area where neighboring cells support different feature sets.

In addition, the SDT procedure in the rrc_inactive state cannot guarantee the same level of UL data security as in the rrc_connected state. These security aspects may influence the operator's decision whether to deploy the SDT and, if so, where and when to deploy the SDT.

Exemplary solutions

Exemplary solution to problem 1a

To improve positioning accuracy and efficiency of positioning reference signals, existing positioning procedures and architectures supporting UE requests to modify one or more serving and/or neighboring TRPs may be enhanced. Details of these enhancement processes are further described to achieve these potential benefits.

To further illustrate the process, one or more of the following steps are applied. As an initial step, some preconditions for UE triggering or criteria for evaluating PRS-based positioning (re) configuration should be preset to UEs with PRS and associated positioning calculation methods (RSTD, TDOA, multi-RTT, aoD, etc.). This may be done in advance, stored in some persistent or semi-persistent memory (volatile or non-volatile memory/data structures stored on the UE), or configured over the air over the network. Such a preset UE trigger for evaluating PRS resources/configuration may be based on events (periodic measurements, event-based triggers, etc.) and parameter sets (e.g., request Config Allowed) to enable or disable positioning reconfiguration requests and criteria evaluation. The event-based trigger may be a plurality of UE actions such as a location request, a cell selection (reselection), detection of a positioning signal, an emergency call or a combination of events and positioning measurements.

The validity of the evaluation trigger may be granular for a particular gNB, TRP, or beam, or have a wider granularity, e.g., PLMN, TA, RNA, etc. Further, the UE trigger may be preconfigured by the network source (e.g., gNB, TRP, LMF or location server). In addition, validity may also have a time (timer) aspect associated with evaluating the trigger.

Once the UE has identified a trigger that has met PRS evaluation criteria, the UE evaluates existing (initial/first) PRS resources and configurations based on one or more of: positioning KPIs (e.g., qoS, positioning accuracy, positioning delay, inter-cell interference), current PRS configurations (including Request Config Allowed for a particular UE, request Config Allowed for a particular gNB/network resource), and other UEs nearby or in proximity. It is noted that other embodiments of Request Config Allowed may include other aspects such as the frequency of Request Config Allowed (e.g., counter/given time, number of allowed UE requests) or allowed requests for only certain services (e.g., emergency services).

In addition, UE measurements (e.g., PRS, SSB, NLOS/LOS, multipath detection) of serving and neighboring gnbs may be part of the evaluation process.

If the UE recognizes that the criteria for PRS transmission/resource request have been met, the UE generates and transmits a PRS transmission request (in RRC connected, inactive, or idle mode), including one or more of the following parameters nine.

The first is the frequency limit of the requested (re) configuration or the configuration only in some cases (e.g. 911). The second is coarse positioning. Third is UE capability. Fourth is the PRS measurement set, PRS transmission configuration parameters, and/or PRS resource identifiers. Fifth is other positioning measurements such as cell edge and mobility measurements. Sixth is an emergency indicator, e.g., an indication of whether the PRS reconfigures to be emergency or emergency level/level. Seventh is a time delay or time window. For example, the UE requires an indication of a new PRS reconfiguration within K milliseconds or within a certain time range. Eighth is the relative priority associated with more than one PRS (re) configuration request. The network may receive a plurality of PRS configuration requests. This will enable the network/LMF to prioritize more important items. The ninth is a time scheduling indication that the UE needs a new PRS configuration based on the provided scheduling.

A UE PRS transmission request is received by a network and a response is generated from the network. In one embodiment, the request is received by a gNB or NG-RAN node. In other embodiments, the request is received by a location server, LMF, or other network entity. The request is then processed by the network, which then sends one or more responses to one or more UEs, such as the requesting UE and/or nearby neighboring UEs.

The processing of the request by the network may include updating one or more gNB PRS configuration sets (configuration groups) or resources, including off/on, high/low resources and bandwidth, silent mode, emergency configuration, etc.

The processing of the request by the network may include authorizing, partially authorizing (e.g., authorizing only one or more PRS configuration parameters or only a portion of the requested resources) or rejecting PRS (re) configuration by modifying one or more of the following seven messages and procedures: the LPP provides assistance data; new configuration set/group, validity period of new configuration; LPP requests location information; prioritizing the newly configured TRP for measurement; broadcasting SI updates: posSIB; updating other UEs in the serving/neighboring cells of the TRP/gNB (re) configuration; in case of rejecting the PRS transmission request, a notification about a backoff behavior is received, e.g., a new positioning method (GNSS, enhanced cell ID, etc.).

In the event that the LMF denies the UE's request for PRS transmission reconfiguration, the LMF may configure other positioning sources, methods, and signals to meet positioning KPI/requirements. For example, depending on the capabilities of the UE and the system, the response received by the UE may include a configuration for utilizing other positioning signals (e.g., SSB measurements, CSI-RS measurements or other PRS measurements, UL methods utilizing SRS (sounding reference signals)).

In alternative embodiments, the network (e.g., LMF) may configure one or more UEs with a set of PRS resources (e.g., BW) in which resources are completely or partially deactivated at any given time. In addition, the UE may be made aware of the serving or neighbor cell via SI or dedicated signaling with multiple available PRS resource sets that may be activated upon request. The UE may then also use access layer signaling to request from the gNB which PRS resource set to activate/deactivate.

Subsequently, the LMF may then configure the UE via one of the following six methods. The first is an RRC message that activates a PRS resource set or subset via dedicated signaling or through system information. The second is an LPP message that activates a set or subset of PRS resources. Third is to use the MAC-CE to activate the set or subset of PRS resources that the UE should use to make measurements/measurement reports. Fourth is to use DCI to activate a set or subset of PRS resources that the UE should use for measurement/measurement reporting. Fifth is an RRC with a combination of the above methods (MAC-CE and/or DCI) for activating and indicating a set or subset of PRS resources to be used. Sixth is to activate more than one set/subset by MAC-CE and then use DCI to dynamically indicate to the UE when to use PRS resource sets or subsets or which PRS resource sets or subsets to use for positioning calculations and when to use PRS resource sets or subsets or which PRS resource sets or subsets to use for measurements and reporting to the network.

Note that in an exemplary solution, the existing DCI format as specified in TS 38.212 (7.3 downlink control information) may be used to specify activation (deactivation) by updated fields and/or bitmaps. Alternatively, a new DCI format may be specified for the NR positioning procedure.

Similarly, PRS resource set or subset deactivation may be triggered by the LMF via RRC, LPP, MAC CE, and/or DCI to deactivate the PRS resource set or subset that the UE may use for a positioning procedure. An exemplary set of MAC-CE values for LCID of DL-SCH is as follows:

based on TS 38.321 section 6.2.1, exemplary values for PRS resource activation/deactivation are given. Note that the content of the MAC CE may include an identifier to allow the UE to determine which PRS resource sets of PRS resource sets to activate (or deactivate). See appendix 8, which is a table of values of LCID for DL-SCH.

To further illustrate these procedures, i.e. the message flow in fig. 6, the UE requests a reference signal reconfiguration.

Once PRS and positioning (re) configuration are updated from the network point of view, the UE receives (re) configuration via broadcast SI or P2P positioning protocol and processes it. Based on this new information and configuration, the UE may perform positioning measurements and calculate a UE location (UE-B) or report measurements for network calculation of UE location (UE-a). An exemplary process flow is shown in fig. 7.

In one example, the UE may be configured via an Information Element (IE) embedded as part of an existing LPP messaging construct. An exemplary IE as shown in the following common PRS LPP provisioning assistance data enables a UE evaluation to request PRS (re) configuration based on one or more criteria, triggers, thresholds, measurements, etc., or a combination thereof.

TS 37.355 section 6.4.3

NR-DL-PRS-AssistanceData

The IE NR-DL-PRS-Assistance data is used by the location server to provide DL-PRS assistance data. The location server should include at least one TRP (e.g., a serving TRP) for which the SFN is available to the target device. The nr-DL-PRS-referenceInfo defines an "auxiliary data reference" TRP in the nr-DL-PRS-Assistance DataList that includes a DL-PRS configuration. The nr-DL-PRS-SFN0-Offset and nr-DL-PRS-predictedRSTD in the nr-DL-PRS-assysice DataList are provided relative to the assistance data reference "TRP. The network signals the zero value to nr-DL-PRS-SFN0-Offset, nr-DL-PRS-predictedRSTD and nr-DL-PRS-predictedRSTD-uncetaint y of the "assistance data reference" TRP in nr-DL-PRS-assistata List.

For NR DL-TDOA positioning (see clause 6.5.10), NR-DL-PRS-referenceInfo also defines the "RSTD reference" of the request. See abstract syntax notation one (ASN.1) example of appendix item 9, and NR-DL-PRS-Assistance data field description of appendix item 10.

Alternatively, these IEs may be broadcast from the gNB to the UE within a positioning SIB. Furthermore, the availability of the UE to fulfill a request for UE-initiated PRS (re) configuration may be included in the LPP request location information and associated IEs (shown in bold), similar to the LMF message sent to the UE in the NR providing assistance data message as previously discussed. Note that in the following examples, the request location information is shown as part of the TDOA method, but similar IEs are envisioned for other methods that utilize PRSs, such as RTT and AoD.

NR-DL-TDOA-RequestLocationInformation

The IE NR-DL-TDOA-RequestLocationInformation is used by the location server to request NR DL-TDOA location measurements from the target device. See abstract syntax notation one (ASN.1) example of appendix 11, and NR-DL-TDOA-RequestLocationInformation field description of appendix 12. See TS 37.355 section 6.5.10.5.

As previously described, the UE may request PRS transmission (re) configuration based on meeting preconditions. If the UE is allowed to send a request (and information associated with the request) and has met the evaluation criteria to do so, this may be done via an existing LPP message with a newly configured IE. In one example, the LPP request assistance data may include an IE for the UE to request LMF (re) configuration PRS transmissions, as shown herein for TDOA techniques, but may be similarly updated for example AoD, RTT, etc.

NR-DL-TDOA-RequestAssistanceData

The IE NR-DL-TDOA-RequestAssistance data is used by the target device to request assistance data from the location server. See abstract syntax notation one (ASN.1) example of appendix item 13, and NR-DL-TDOA-RequestAssistance Data field description of appendix item 14. See TS 37.355 section 6.5.10.2.

In alternative embodiments, the UE may require some measure to determine or calculate the need for the network to modify the PRS transmissions of the serving or neighbor cells. As part of the LPP providing location information IE, the UE may also include a general or specific request for modification of PRS transmissions, as shown.

NR-DL-TDOA-ProvideLocationInformation

The IE NR-DL-TDOA-ProvidLocationInformation is used by the target device to provide NR DL-TDOA location measurements to the location server. It can also be used to provide NR DL-TDOA locating specific error causes. See abstract syntax notation one (ASN.1) example of appendix item 19, and NR-DL-TDOA-ProvidLocationInformation field description of appendix item 20. See TS 37.355 section 6.5.10.3.

In response to the foregoing providing location information and associated PRS transmission requests, the network may respond with LPP provided assistance data to inform the UE of a change in PRS transmission of one or more PRS resources and instruct the UE to obtain new measurements. Alternatively, rejection of the PRS request message with other fallback positioning methods or resources may be sent over the network. The network may switch dl-PRS-ConfigRqstAllowed to reject PRS (reconfiguration) requests.

Exemplary solution to problem 1b

To improve positioning accuracy and efficiency of positioning reference signals, existing positioning procedures and architectures supporting LMF initiated modification of one or more services and/or neighboring TRPs may be enhanced. Details of these enhancements are further described herein to achieve these potential benefits.

To further illustrate the process, one or more of the following steps are based on LPP and related protocols, as shown in fig. 8. It should be noted that LPP and NRPPa messages need not be performed sequentially as shown in fig. 8. This flow is illustrated in fig. 8, but, although similar to the UE-initiated case, the LMF/network must evaluate the resources and requirements associated with multiple UEs within the coverage of the serving cell and neighboring cells.

PRS transmission configurations for triggering LMF initiated methods that may also be used in connection with UE initiated methods, i.e., the following process flow evaluations and criteria, may be used. In the case that both UE-initiated and LMF-initiated PRS transmission configurations are enabled; any conflicts must be coordinated by the network when multiple UEs can request reconfiguration from the LMF. See fig. 9.

In this procedure, an LMF (location server/network) based solution may be used, whereby the LMF is operatively coupled with one or more TRPs and UEs. The LMF may initially transmit PRS configurations (including disabling PRS) to TRP and UE associated with validity and reconfigRequestAllowed parameters. Optionally, the LMF may transmit a request to the TRP, including one or more of: the required class/level of service, type of service, UE capability, measurement/location estimation, current PRS resource configuration. The process may also require some sort of acknowledgement from the TRP.

Next, the LMF evaluates the set of positioning resources, the current PRS configuration, and/or UE characteristics, including but not limited to measurements, a set of measurements, a gNB measurement (e.g., SRS transmitted by the UE), a (re) configuration request, a UE capability, a set of service types, and a set of minimum KPIs (e.g., qoS) from one or more UE/TRPs.

The LMF must then evaluate whether the criteria for triggering positioning and PRS (re) configuration have been met. If the triggering criteria have been met, the LMF requests that the TRP PRS transmission/resources be modified to a new configuration set within a predetermined or configurable duration. If the triggering criteria are not met, the LMF may wait for the next opportunity to re-evaluate the criteria for triggering (re) configuration. Note that the criteria may be partially met and trigger a partial reconfiguration or update to be initiated. The (re) configuration procedure may also require some kind of acknowledgement from the TRP.

Finally, the network/TRP transmits location and measurement configuration updates to the UE via broadcast posSIB, via P2P or other means as necessary.

Exemplary solution to problem 2

PosSIB acquisition and PRS reception

The use of LPP messaging for PRS (re) configuration and negotiation may add additional latency. Methods of reducing latency suggest that the UE requests modifications to PRS transmissions by utilizing procedures for requesting other SIs (on-demand SI). The posSIB may typically not be broadcast when explicitly requested by the UE to reduce unnecessary overhead in the cell by transmitting the posSIB only (broadcast is avoided when no UE is present). Corresponding to this case, if the PRS transmission is not currently broadcast, the relevant posSIB will not be broadcast either.

In this example, the existing procedure for UE request of the on-demand posSIB can be used as a trigger for the network (gNB, LMF) to activate or modify one or more TRP PRS transmissions and/or reconfigure existing transmissions.

For UEs in rrc_idle and rrc_inactive, requests for other SIs trigger a Random Access (RACH) procedure. This is determined by the UE after reading SI scheduling information from SIB 1. Thus, the UE may determine the broadcast status of the posSIB associated with the PRS (via si-BroadcastStatus). This field indicates whether one or more possibs within the SI message are being broadcast. If si-BroadcastStatus is set to "broadcast", the UE will "normally" acquire the relevant posSIB. This may also be an implicit indication that PRS transmission reconfiguration request is not possible.

However, if si-BroadcastStatus is set to "not broadcast", the UE will continue with RACH procedure to acquire those possibs. For this procedure, if the network configures the UE with resources for the posSIB request, this may also be an implicit trigger to activate or modify one or more TRP PRS transmissions. As part of this procedure, additional embodiments may include a UE to be configured by the network having dedicated or reserved RACH resources for PRS configuration. This may be specific to RACH frequency domain or time domain resources and may be used as an implicit indication of a PRS resource request set or subset (in case of a pre-configured activation). Furthermore, the UE may use the reserved RACH preamble set as another implicit mechanism to indicate a request for PRS configuration updates or specific PRS configuration updates. In the case of 2-step RACH, in message a, the UE may use dedicated or reserved PUSCH resources in time, frequency, or both as an implicit indication of PRS resource requests or requests for PRS configuration updates, etc. Furthermore, dedicated or reserved DMRS ports and/or sequences may also be used by the UE as an implicit indication of PRS resource requests or requests for PRS configuration updates. PUSCH resources in time and/or frequency, DMRS ports and/or sequences may be used jointly for implicit indications of PRS resource requests, requests for PRS configuration updates, and so forth.

Another embodiment may involve having an explicit indication of a request to carry an IE requesting a PRS configuration update. For both implicit and explicit cases, the request and associated information is communicated from the gNB to the LMF via NRPPa or other network protocol. However, for UEs in rrc_idle, there is no context in the gNB for a specific UE. This requires that the gNB resolve the UE request via one or more RNTIs (or Pos-RNTIs), and the LMF may associate RNTIs with the positioning procedure. For rrc_inactive, a context exists and the UE may be specifically identified during the network (e.g., NRPPa).

In either of these cases, the benefit of these procedures is that the UE is not required to transition to the rrc_connected state, thereby reducing the latency associated with these procedures.

Alternatively, for UEs in rrc_connected, the network may provide posSIB updates through dedicated signaling using rrcrecon configuration messages in case PRS transmission (reconfiguration) has occurred. See 3gpp TS 38.331. This may introduce additional delay.

As shown in the examples below, the network may provide posSIB updates with dedicated paging messages on the short message bit field.

As part of the paging notification, one or more UEs receive notification of PRS resource configuration updates, which further includes

i. Requesting the UE to calculate and/or report its location, or

Requesting UE reporting location related measurements

Using TS 38.331 section 6.5 as a baseline, examples of possible bit indications are highlighted below, depending on the configured positioning mode of the UE (i.e., UE-based, UE-assisted).

The short message may be transmitted on the PDCCH using the short message field of DCI format 1_0, with or without the P-RNTI of the associated Paging message (see TS 38.212, clause 7.3.1.2.1).

Appendix 17 is a short message table, with bit 1 being the most significant bit.

From an RRC perspective, acquisition and request of on-demand PosSIB can be enhanced as shown in bold as a criterion change in annex item 18.

Enhancement of PRS reception latency reduction

Additional enhancements to PRS reception reconfiguration may be used to further reduce latency. As part of the UE procedure with the reconfigRequestAllowed parameter set (including the measurements of the first PRS configuration), the UE may require additional and/or prioritized measurements depending on whether PRS reception reconfiguration occurs. For example, the UE may be configured to report measurements as part of a PRS reconfiguration request associated with a first PRS configuration, allowing subsequent UE-assisted measurement reports to be sent by the UE and later concatenated by the network for positioning determination.

In additional embodiments, UE reception, PRS reception for newly configured TRPs, and PRS measurement prioritization are performed as part of a second PRS transmission resource and configuration set. This will help reduce latency associated with the first PRS configuration and the second PRS configuration.

As part of the second PRS transmission resources and (re) configuration set, configurations associated with reporting additional PRS measurements based on reconfiguration under rrc_idle/INACTIVE via methods such as Small Data Transmission (SDT), MAC-CE, or CG-based transmission are included. This will also reduce the latency involved in typical measurement reporting methods done in RRC connected mode with LPP or user plane (SUPL).

Enhancements to a UE and/or a gNB configured with multiple PRS reception configurations may include one or more of: grouping the plurality of parameter sets into configuration sets/stages at the UE or the gNB; validity associated with each configuration group; a semi-persistent or persistent PRS transmission configuration that is stored and quickly accessed/activated; and PRS receive configuration sets and/or "Request Config Allowed" for only certain device types or characteristics (e.g., REDCAP, non-mobile UE).

The method may allow PRS reception (re) configuration procedures to occur as part of other positioning procedures and may not be associated with specific LCS requests to further reduce latency.

Exemplary solution to problem 3

Positioning accuracy, latency, and integrity are based on a number of factors, such as TRP/network well-geographically dispersed deployment (e.g., the density of gNB/TRP), RF conditions, and PRS configuration. To increase the positioning KPI, a method and system for a first device to identify and mitigate sources of error associated with discontinuous PRS transmissions as previously described may be used. The methods may include one or more of the following.

The first is the transmission of the UE to the network in PRS transmission measurement reports and/or UE PRS reconfiguration requests, including one or more of the following detected error sources and quantitative measurements. The second is multipath and LOS/NLOS identification for the serving cell and neighboring cells. Third is an insufficient number of TRP/gnbs for PRS related positioning calculations (e.g., RTT, TDOA, aoD). Fourth is that PRS inter-cell interference improves audibility and accuracy with increased PRS transmit power but may increase the likelihood of interfering with neighboring cells.

Fifth is that the UE receives PRS measurements and associated positioning calculation error source reporting configuration from the network, comprising: a threshold of acceptable and/or unacceptable interference levels; a threshold of delay spread as a result of multipath associated with the PRS signal; a threshold value for no LoS or number of TRPs identifying NLoS/LoS; an associated prohibit timer associated with the error source report and avoiding excessive reporting; a threshold of angular spread as a result of beamforming associated with the PRS signal; and thresholds for transmitter and receiver timing errors.

The network (gNB, LMF) upon receiving the PRS transmission measurement report and/or the UE PRS reconfiguration request identifies an associated error source and initiates one or more of the following. The first is to reallocate PRS transmission resources and update PRS configurations in view of potential interference. The second is to activate/update the muting pattern of the serving and/or neighboring cells. Third is the input for determining/calculating the confidence and uncertainty of the position/measurement. Fourth is triggering allowed UE-initiated PRS requests and evaluations. Fifth is to configure the UE to use other fallback positioning methods. Sixth, other positioning techniques/methods are required to verify measurements and position determination.

Cell identification that can trigger SDT procedures

Methods and systems for a network node to indicate support for SDT procedures in a cell by using system information broadcast to communicate an SDT indicator having the following components:

the SDT indicator has a presence bit, wherein the presence value of the SDT indicator is set to the value "present" in a cell in which the SDT enabled UE may trigger the SDT procedure. In a cell in which a UE supporting SDT is prohibited from triggering the SDT procedure, the presence value of the SDT indicator is set to the value "no".

In addition to the presence bit, the SDT indicator may have two possible values, where the value "allowed" indicates that SDT procedures are allowed in the cell, and "disallowed" indicates that SDT procedures are prohibited or temporarily prohibited

Methods and systems for UL transmission of SDT-enabled UE trigger data:

reading the SDT indicator from the system information block to obtain information whether SDT procedures are supported in the cell:

if the indicator consists of only presence bits:

interpreting the presence of an SDT indicator as allowing an SDT procedure in a cell

Interpreting the absence and omission of SDT indicators as disabling SDT procedures in a cell

If the indicator carries "allow" and "disallow" values

Interpreting the presence of an SDT indicator having a value of "allowed" as an allowed SDT procedure in a cell

Interpreting the presence of an SDT indicator having a value of "not allowed" as disabling or preventing SDT procedures in a cell

Interpreting an absence or omitted SDT indicator as a forbidden SDT procedure in a cell

Methods and systems for UE to perform reselection:

reading SDT indicators from system information blocks to obtain information whether SDT procedures are supported in a new cell

If the indicator consists of only presence bits, the presence of the SDT indicator is interpreted as allowing the SDT procedure after cell reselection. If the indicator carries an indication value, the presence of an SDT indicator having a value of "allowed" is interpreted as allowing the SDT procedure after cell reselection.

If the indicator consists of only presence bits, the absence of the SDT indicator and the omitted SDT indicator are interpreted as disabling the SDT procedure. If the indicator carries an indication value, the presence of an SDT indicator having a value of "not allowed" is interpreted as disabling or preventing the SDT procedure after cell reselection.

The SDT procedure initiated in the source cell is completed before performing a cell reselection to the new cell, or

Interrupting the SDT procedure initiated in the source cell and performing a cell reselection to the new cell, or

Request for RRC connection, transition to rrc_connected state and interrupt SDT procedure

Methods and systems for a UE to indicate positioning data as SDT:

setting a data type indicator bit to indicate that small data conveys control plane related positioning data and must be forwarded to the LMF, or

Containing separate messages for different types of small data, where one type of small data is 1) user plane data or user plane related positioning data and 2) the other type of small data is control plane related positioning data, allowing both small data types to be transmitted simultaneously.

Containing separate messages for different types of small data, where one type of small data is 1) user plane data, 2) user plane related positioning data, and 3) another type of small data is control plane related positioning data, allowing for simultaneous transmission of potentially all small data types.

Methods and systems for AMF to receive forwarded small data from a radio access network:

interpreting the value of the small data type indicator and forwarding control plane related positioning data to the LMF, or

In the case of separate messages for two different types of small data, forwarding the contained control plane related positioning small data to the LMF and the rest of the small data to the UPF

In the case of separate messages for three different types of small data, forwarding the contained control plane related positioning small data to the LMF and the rest of the small data to the UPF

For any of the above actions, the LMF may also transmit multiple UEs within or near the update/reconfiguration region via P2P or broadcast signaling.

This would require additional IEs for both the first UE to transmit error detection and associated KPIs, as well as IEs for the network entity to transmit notifications and/or mitigation for these error sources. From the UE perspective, this may be implemented in a measurement report (e.g., LPP provides location information) and/or as part of a PRS transmission reconfiguration request.

The exemplary IE structure is shown as part of the LPP provided location information message, but may also be included as part of other messages transmitted from the UE to the network (e.g., LPP, SUPL, or dedicated error messages). These specification updates may also be used for other positioning methods that utilize PRS transmissions or other positioning techniques.

Baseline from TS37.355 section 6.5.10.3

NR-DL-TDOA-ProvidLocationInformation (with error mitigation)Information request

The IE NR-DL-TDOA-ProvidLocationInformation is used by the target device to provide NR DL-TDOA location measurements to the location server. It can also be used to provide NR DL-TDOA location specific errors and error metrics. See abstract syntax notation one (asn.1) example in appendix item 15 and NR-DL-TDOA-providelocalinformation field description of appendix item 16.

The error source detected by the UE may also be included in the existing error IE construction of each LPP.

NR-DL-TDOA-TargetDeviceErrorCauses

The IE NR-DL-TDOA-TargetDeviceErrorCauses is used by the target device to provide NR DL-TDOA error causes to the location server. See abstract syntax notation one (asn.1) example of annex item 21.

In response to receiving these error metrics and notifications from the first UE, the network/LMF may transmit mitigation information to one or more UEs. This may include informing one or more UEs of a proximity error condition that may have a potential impact to assist the UE in location measurement and calculation. This information may be sent in the LPP provide assistance data message (P2P or broadcast posSIB) by removing the TRP/beam associated with the PRS source ID from the configuration.

Solution to problem 4

The NR SDT feature may be based on a similar concept as mobile-originated EDT in LTE [11,12]. Similar to LTE, two different types of UL data transfer may be supported on the Common Control Channel (CCCH):

UL small data is contained in NAS message octet strings in a separate UL RRC message. UL RRC messages are only used for SDT procedures. The small data contained is forwarded from the receiving radio access network node to the AMF in the core network

UL small data is transmitted on DTCH multiplexed with UL RRC resume request message and forwarded from receiving radio access network node to AMF in core network

If the small data contains positioning related data, there are three possible implementations of UL message conveying the small data:

the UL message carries an indicator that can be used to identify the type of small data in the NAS message from the following two possible types: 1) User plane data or user plane related positioning data, 2) control plane related positioning data

The contained NAS message carries an indicator that can be used to identify the type of small data in the NAS message from the following two possible types: 1) User plane data or user plane related positioning data, or 2) control plane related positioning data

UL messages have separate and independent octet strings for NAS messages to contain 1) user plane data or user plane related positioning data, and 2) control plane related positioning data, where both octet strings can be contained in the message at the same time

The UL message may be a separate RRC message specifically designed for small data transfer, but in case of small data multiplexed transfer on DTCH together with an RRC resume request message, the indicator may also be included in a Medium Access Control (MAC) header or in an RRC resume request message. It should be noted that in the case where the indicator is included in the MAC header, the indicator may be specified in the form of a logical channel specific to small data transfer, or a logical channel specific to small data transfer may be used as the SDT indicator.

The solution consists of the following steps in the different nodes:

the radio access network node supporting SDT includes an SDT indicator of the transmitted system information message to indicate that SDT procedures are allowed in its cell. The system information message communicated may be an NR main information block, an extension of an existing system information block type, or a new system information block type. The indicator need not be broadcast in all cells belonging to the same radio access network node, but only in such cells where SDT is allowed. The indicator may be implemented as a presence bit, where presence indicates that SDT procedures are allowed and absence indicates that SDT procedures are prohibited.

When the small data in the rrc_inactive state arrives at the transmitter buffer of the UE, the UE initiates the SDT procedure only when the SDT indicator is present in the system information of the current cell. Otherwise, the UE considers the SDT procedure to be disabled. This is to ensure interoperability with legacy network equipment in which the indicator is not implemented and thus cannot be set as present or absent.

While small data transfers are in progress, cell reselection criteria may be fulfilled. Before cell reselection, the UE reads the SDT indicator from the system information of the new cell. The UE may use the value of the indicator to make one or more of the following decisions:

for cell reselection, a cell supporting SDT is selected or prioritized over a cell not supporting SDT. If the UE reselects to a cell that allows the SDT procedure, the UE may resume the SDT procedure in the new cell. In this case, the UE may transmit an RRC resume request message accompanied by small data to the new cell and continue the SDT procedure.

If the UE reselects to a cell that does not allow the SDT procedure, for example if the UE does not find any cell supporting SDT as a reselection candidate cell, the UE may complete the initiated SDT procedure in the source cell before performing cell reselection.

The ongoing SDT procedure is interrupted, the request transitions to the rrc_connected state and the data transfer continues in the rrc_connected state. This may be the case if the UE does not find a candidate cell supporting SDT for cell reselection. The UE may include mobility measurements into the RRC resume request to assist its serving node in triggering the handover procedure. If the RRC connection request is denied or fails, the UE transitions to the rrc_idle state, performs cell reselection, and starts small data transmission from scratch in the new cell after the normal data transfer procedure.

Transition to RRC IDLE, perform cell reselection, and start transmission of small data from scratch in the new cell after the normal data transfer procedure.

If the SDT procedure is triggered and the SDT data conveys positioning data, there are four possible solutions:

the UE adds an indicator bit to the NAS message conveying information about the type of small data. The indicator is read by the AMF to determine where to forward the small data.

The UE adds an indicator bit to the RRC message or MAC header to convey information about the type of small data. The receiving radio access network node adds an indicator from the received RRC message to the NG interface frame that conveys small data to the AMF.

The UE populates separate NAS messages for 1) user plane data or user plane related positioning data and 2) control plane related positioning data.

The UE populates separate NAS messages for 1) user plane data, 2) user plane related positioning data, and 3) control plane related positioning data.

When small data is received in the AMF, if an indicator is used, the AMF will read the indicator from the small data itself or from the NG frame to determine if the data is location related. If the indicator value indicates the presence of control plane related positioning data, the small data is forwarded to the LMF.

If separate NAS messages are used for 1) user plane data or user plane related location data and 2) control plane related location data, the AMF will forward the control plane related location data to the LMF and the user plane data to the UPF.

If separate NAS messages are used for 1) user plane data, 2) user plane related location data, and 3) control plane related location data, the AMF will forward the control plane related location data to the LMF and the user plane data to the UPF.

Exemplary Environment

The 3 rd generation partnership project (3 GPP) developed technical standards for cellular telecommunication network technology including radio access, core transport network and service capabilities, including research on codec, security and quality of service. Recent Radio Access Technology (RAT) standards include WCDMA (commonly referred to as 3G), LTE (commonly referred to as 4G), LTE advanced standards, and new air interface (NR) (also referred to as "5G"). The 3GPP NR standards are expected to continue to evolve and include definitions of next generation radio access technologies (new RATs), which are expected to provide new flexible radio access below 7GHz and new ultra mobile broadband radio access above 7 GHz. The flexible radio access is intended to include new non-backward compatible radio access in the new spectrum below 7GHz and to include different modes of operation that can be multiplexed together in the same spectrum to address a broad set of 3GPP NR use cases with different requirements. Ultra mobile broadband is expected to include the centimeter and millimeter wave spectrum that would provide opportunities for ultra mobile broadband access such as indoor applications and hotspots. In particular, ultra mobile broadband is expected to share a common design framework with flexible radio access below 7GHz, with centimeter wave and millimeter wave specific design optimizations.

3GPP has identified a variety of use cases that NR expects to support, resulting in a wide variety of user experience requirements for data rate, delay, and mobility. The use cases include the following general categories: enhanced mobile broadband (eMBB), ultra-reliable low-latency communication (URLLC), large-scale machine type communication (mctc), network operations (e.g., network slicing, routing, migration and interworking, energy saving), and enhanced vehicle-to-vehicle (eV 2X) communication, which may include any of vehicle-to-vehicle communication (V2V), vehicle-to-infrastructure communication (V2I), vehicle-to-network communication (V2N), vehicle-to-pedestrian communication (V2P), and vehicle communication with other entities. Specific services and applications in these categories include, for example, monitoring and sensor networks, device remote control, two-way remote control, personal cloud computing, video streaming, cloud-based wireless offices, first-responder connections, car emergency calls, disaster alerts, real-time games, multi-person video calls, autonomous driving, augmented reality, haptic internet, virtual reality, home automation, robotics, and drones, among others. All of these and other uses are contemplated herein.

Fig. 10A illustrates an exemplary communication system 100 in which the systems, methods, and apparatus described and claimed herein may be used. The communication system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, and/or 102g, which are commonly or collectively referred to as WTRU 102 or WTRUs 102. The communication system 100 may include Radio Access Networks (RANs) 103/104/105/103b/104b/105b, core networks 106/107/109, public Switched Telephone Networks (PSTN) 108, the internet 110, other networks 112, and network services 113. 113. Web services 113 may include, for example, V2X servers, V2X functions, proSe servers, proSe functions, ioT services, video streaming, and/or edge computation, etc.

It should be appreciated that the concepts disclosed herein may be used with any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102 may be any type of apparatus or device configured to operate and/or communicate in a wireless environment. In the example of fig. 10A, each of the WTRUs 102 is depicted in fig. 10A-E as a handheld wireless communicator. It should be appreciated that in the context of various use cases contemplated for wireless communications, each WTRU may include or be included in any type of apparatus or device configured to transmit and/or receive wireless signals, including by way of example only: user Equipment (UE), mobile station, fixed or mobile subscriber unit, pager, cellular telephone, personal Digital Assistant (PDA), smart phone, laptop, tablet computer, netbook, notebook computer, personal computer, wireless sensor, consumer electronics device, wearable device (such as a smart watch or smart garment), medical device or electronic health device, robot, industrial equipment, drone, carrier such as a car, truck, train or airplane, or the like.

Communication system 100 may also include a base station 114a and a base station 114b. In the example of fig. 10A, each base station 114a and 114b is depicted as a single element. In practice, base stations 114a and 114b may include any number of interconnected base stations and/or network elements. The base station 114a may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, and 102c to facilitate access to one or more communication networks, such as the core networks 106/107/109, the internet 110, the network services 113, and/or the other networks 112. Similarly, the base station 114b may be any type of device configured to interface, wired and/or wireless, with at least one of a Remote Radio Head (RRH) 118a, 118b, a Transmission and Reception Point (TRP) 119a, 119b, and/or a roadside unit (RSU) 120a and 120b to facilitate access to one or more communication networks, such as the core network 106/107/109, the internet 110, the other network 112, and/or the network service 113. The RRHs 118a, 118b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102 (e.g., the WTRU 102 c) to facilitate access to one or more communication networks (such as the core networks 106/107/109, the internet 110, the network services 113, and/or the other networks 112).

The TRPs 119a, 119b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102d to facilitate access to one or more communication networks, such as the core networks 106/107/109, the internet 110, the network services 113, and/or the other networks 112. RSUs 120a and 120b may be any type of device configured to wirelessly interface with at least one of WTRUs 102e or 102f to facilitate access to one or more communication networks, such as core networks 106/107/109, internet 110, other networks 112, and/or network services 113. As an example, the base stations 114a, 114B may be Base Transceiver Stations (BTSs), node bs, evolved node bs, home evolved node bs, next generation node bs (gNode bs), satellites, site controllers, access Points (APs), wireless routers, and the like.

Base station 114a may be part of RANs 103/104/105 that may also include other base stations and/or network elements (not shown), such as Base Station Controllers (BSCs), radio Network Controllers (RNCs), relay nodes, and the like. Similarly, base stations 114b may be part of RANs 103b/104b/105b, which may also include other base stations and/or network elements (not shown), such as BSCs, RNCs, relay nodes, and the like. Base station 114a may be configured to transmit and/or receive wireless signals within a particular geographic area, which may be referred to as a cell (not shown). Similarly, the base station 114b may be configured to transmit and/or receive wired and/or wireless signals within a particular geographic area, which may be referred to as a cell (not shown). The cell may be further divided into cell sectors. For example, a cell associated with base station 114a may be divided into three sectors. Thus, for example, base station 114a may include three transceivers, e.g., one for each sector of a cell. Base station 114a may employ multiple-input multiple-output (MIMO) technology and thus may utilize multiple transceivers for each sector of a cell, for example.

The base station 114a may communicate with one or more of the WTRUs 102a, 102b, 102c, and 102g over an air interface 115/116/117, which may be any suitable wireless communication link (e.g., radio Frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). Any suitable Radio Access Technology (RAT) may be used to establish the air interfaces 115/116/117.

The base station 114b may communicate with one or more of the RRHs 118a and 118b, TRPs 119a and 119b, and/or RSUs 120a and 120b over a wired or air interface 115b/116b/117b, which may be any suitable wired communication link (e.g., cable, fiber optic, etc.) or wireless communication link (e.g., RF, microwave, IR, UV, visible light, centimeter wave, millimeter wave, etc.). Any suitable RAT may be used to establish the air interfaces 115b/116b/117b.

The RRHs 118a, 118b, trps 119a, 119b, and/or RSUs 120a, 120b may communicate with one or more of the WTRUs 102c, 102d, 102e, 102f over the air interfaces 115c/116c/117c, which may be any suitable wireless communication links (e.g., RF, microwave, IR, ultraviolet UV, visible, centimeter wave, millimeter wave, etc.). Any suitable RAT may be used to establish the air interfaces 115c/116c/117c.

The WTRUs 102 may communicate with each other over a direct air interface 115d/116d/117d, such as a side link communication, which may be any suitable wireless communication link (e.g., RF, microwave, IR, ultraviolet UV, visible, centimeter wave, millimeter wave, etc.). Any suitable RAT may be used to establish the air interfaces 115d/116d/117d.

Communication system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, or the like. For example, a base station 114a in RAN103/104/105 and a WTRU 102a, 102b, 102c or an RRH 118a, 118b in RAN103 b/104b/105b, TRP 119a, 119b and/or RSUs 120a and 120b and WTRUs 102c, 102d, 102e and 102f may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) terrestrial radio access (UTRA) that may use Wideband CDMA (WCDMA) to establish air interfaces 115/116/117 and/or 115c/116c/117c, respectively. WCDMA may include communication protocols such as High Speed Packet Access (HSPA) and/or evolved HSPA (hspa+). HSPA may include High Speed Downlink Packet Access (HSDPA) and/or High Speed Uplink Packet Access (HSUPA).

Base station 114a in RAN103/104/105 and the WTRUs 102a, 102b, 102c and 102g or RRHs 118a and 118b in RAN103 b/104b/105b, TRP 119a and 119b and/or RSUs 120a and 120b and WTRUs 102c, 102d may implement a radio technology such as evolved UMTS terrestrial radio Access (E-UTRA) that may use, for example, long Term Evolution (LTE) and/or LTE advanced (LTE-A) to establish air interfaces 115/116/117 or 115c/116c/117c, respectively. The air interfaces 115/116/117 or 115c/116c/117c may implement 3GPP NR techniques. LTE and LTE-a technologies may include LTE D2D and/or V2X technologies and interfaces (such as side link communications, etc.). Similarly, 3GPP NR techniques can include NR V2X techniques and interfaces (such as side link communications, etc.).

Base station 114a in RAN 103/104/105 and WTRUs 102a, 102b, 102c, and 102g or RRHs 118a and 118b, TRPs 119a and 119b, and/or RSUs 120a and 120b in RAN 103b/104b/105 and WTRUs 102c, 102d, 102e, and 102f may implement radio technologies such as: IEEE 802.16 (e.g., worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000 1X, CDMA EV-DO, tentative standard 2000 (IS-2000), tentative standard 95 (IS-95), tentative standard 856 (IS-856), global system for mobile communications (GSM), enhanced data rates for GSM evolution (EDGE), GSM EDGE (GERAN), and the like.

The base station 114c in fig. 10A may be, for example, a wireless router, home node B, home evolved node B, or access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area such as a business, home, carrier, train, antenna, satellite, factory, campus, etc. Base station 114c and WTRU 102 (e.g., WTRU 102 e) may implement a radio technology such as IEEE 802.11 to establish a Wireless Local Area Network (WLAN). Similarly, the base station 114c and the WTRU 102 (e.g., WTRU 102 d) may implement a radio technology such as IEEE 802.15 to establish a Wireless Personal Area Network (WPAN). The base station 114c and WRTU 102 (e.g., WTRU 102 e) may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, NR, etc.) to establish a pico cell or femto cell. As shown in fig. 10A, the base station 114c may have a direct connection with the internet 110. Thus, the base station 114c may not need to access the Internet 110 via the core network 106/107/109.

The RANs 103/104/105 and/or the RANs 103b/104b/105b may communicate with a core network 106/107/109, which may be any type of network configured to provide voice, data, messages, authorization and authentication, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102. For example, core networks 106/107/109 may provide call control, billing services, mobile location based services, prepaid calls, internet connections, packet data network connections, ethernet connections, video distribution, etc., and/or perform advanced security functions such as user authentication.

Although not shown in fig. 10A, it should be appreciated that RANs 103/104/105 and/or RANs 103b/104b/105b and/or core networks 106/107/109 may communicate directly or indirectly with other RANs that employ the same RAT as RANs 103/104/105 and/or RANs 103b/104b/105b or a different RAT. For example, in addition to being connected to the RAN 103/104/105 and/or the RAN 103b/104b/105b that may be utilizing an E-UTRA radio technology, the core network 106/107/109 may also communicate with another RAN (not shown) employing a GSM or NR radio technology.

The core networks 106/107/109 may also act as gateways for the WTRU 102 to access the PSTN 108, the internet 110, and/or other networks 112. PSTN 108 may include circuit-switched telephone networks that provide Plain Old Telephone Services (POTS). The internet 110 may include a global system for interconnecting computer networks and devices using common communication protocols, such as Transmission Control Protocol (TCP), user Datagram Protocol (UDP), and Internet Protocol (IP) in the TCP/IP internet protocol suite. Other networks 112 may include wired or wireless communication networks owned and/or operated by other service providers. For example, network 112 may include any type of packet data network (e.g., an IEEE 802.3 Ethernet network) or another core network connected to one or more RANs, which may employ the same RAT as RAN 103/104/105 or RAN 103b/104b/105b or a different RAT.

Some or all of the WTRUs 102a, 102b, 102c, 102d, 102e, and 102f in the communication system 100 may include multi-mode capabilities, e.g., the WTRUs 102a, 102b, 102c, 102d, 102e, and 102f may include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU 102g shown in fig. 10A may be configured to communicate with a base station 114a that may employ a cellular-based radio technology and with a base station 114c that may employ an IEEE 802 radio technology.

Although not shown in fig. 10A, it should be understood that the user equipment may be wired to the gateway. The gateway may be a Residential Gateway (RG). The RG may provide connectivity to the core network 106/107/109. It should be appreciated that many of the ideas contained herein are equally applicable to UEs that are WTRUs and UEs that connect to a network using a wired connection. For example, the ideas applied to wireless interfaces 115, 116, 117 and 115c/116c/117c are equally applicable to wired connections.

Fig. 10B is a system diagram of an exemplary RAN 103 and core network 106. As described above, RAN 103 may communicate with WTRUs 102a, 102b, and 102c over air interface 115 using UTRA radio technology. RAN 103 may also communicate with core network 106. As shown in fig. 10B, RAN 103 may include node bs 140a, 140B, and 140c, which may each include one or more transceivers for communicating with WTRUs 102a, 102B, and 102c over air interface 115. Node bs 140a, 140B, and 140c may each be associated with a particular cell (not shown) within RAN 103. RAN 103 may also include RNCs 142a, 142b. It should be appreciated that RAN 103 may include any number of node bs and Radio Network Controllers (RNCs).

As shown in fig. 10B, the node bs 140a, 140B may communicate with the RNC 142 a. In addition, node B140 c may communicate with RNC 142B. Node bs 140a, 140B, and 140c may communicate with respective RNCs 142a and 142B via Iub interfaces. The RNCs 142a and 142b may communicate with each other via an Iur interface. Each of the RNCs 142a and 142B may be configured to control the respective node B140 a, 140B, and 140c to which it is connected. Furthermore, each of the RNCs 142a and 142b may be configured to perform or support other functionality, such as outer loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, data encryption, and the like.

The core network 106 shown in fig. 10B may include a Media Gateway (MGW) 144, a Mobile Switching Center (MSC) 146, a Serving GPRS Support Node (SGSN) 148, and/or a Gateway GPRS Support Node (GGSN) 150. Although each of the foregoing elements are depicted as part of the core network 106, it should be understood that any of these elements may be owned and/or operated by an entity other than the core network operator.

The RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an IuCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, and 102c with access to a circuit-switched network, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, and 102c and conventional landline communication devices.

The RNC 142a in the RAN 103 may also be connected to the SGSN 148 in the core network 106 via an IuPS interface. SGSN 148 may be coupled to GGSN 150.SGSN 148 and GGSN 150 may provide WTRUs 102a, 102b, and 102c with access to packet-switched networks, such as internet 110, to facilitate communications between WTRUs 102a, 102b, and 102c and IP-enabled devices.

The core network 106 may also be connected to other networks 112, which may include other wired or wireless networks owned and/or operated by other service providers.

Fig. 10C is a system diagram of an exemplary RAN 104 and core network 107. As noted above, the RAN 104 may communicate with the WTRUs 102a, 102b, and 102c over the air interface 116 using an E-UTRA radio technology. RAN 104 may also communicate with core network 107.

RAN 104 may include enodebs 160a, 160B, and 160c, but it should be understood that RAN 104 may include any number of enodebs. The enode bs 160a, 160B, and 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102B, and 102c over the air interface 116. For example, the evolved node bs 160a, 160B, and 160c may implement MIMO technology. Thus, the enode B160 a may use multiple antennas to transmit wireless signals to and receive wireless signals from the WTRU 102a, for example.

Each of the evolved node bs 160a, 160B, and 160c may be associated with a particular cell (not shown) and may be configured to process radio resource management decisions, handover decisions, user scheduling in the uplink and/or downlink, and so on. As shown in fig. 10C, the enode bs 160a, 160B, and 160C may communicate with each other through an X2 interface.

The core network 107 shown in fig. 10C may include a mobility management gateway (MME) 162, a serving gateway 164, and a Packet Data Network (PDN) gateway 166. Although each of the foregoing elements are depicted as part of the core network 107, it should be appreciated that any of these elements may be owned and/or operated by an entity other than the core network operator.

MME 162 may be connected to each of evolved node bs 160a, 160B, and 160c in RAN 104 via an S1 interface and may function as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, and 102c, bearer activation/deactivation, selecting a particular serving gateway during initial attach of the WTRUs 102a, 102b, and 102c, and the like. MME 162 may also provide control plane functionality for switching between RAN 104 and other RANs (not shown) employing other radio technologies, such as GSM or WCDMA.

Service gateway 164 may be connected to each of evolved node bs 160a, 160B, and 160c in RAN 104 via an S1 interface. The serving gateway 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, and 102 c. The serving gateway 164 may also perform other functions such as anchoring user planes during inter-enode B handover, triggering paging, managing and storing the contexts of the WTRUs 102a, 102B and 102c when downlink data is available to the WTRUs 102a, 102B and 102c, etc.

The serving gateway 164 may also be connected to a PDN gateway 166 that may provide the WTRUs 102a, 102b, and 102c with access to a packet-switched network, such as the internet 110, to facilitate communication between the WTRUs 102a, 102b, 102c and IP-enabled devices.

The core network 107 may facilitate communication with other networks. For example, the core network 107 may provide the WTRUs 102a, 102b, and 102c with access to a circuit-switched network (such as the PSTN 108) to facilitate communications between the WTRUs 102a, 102b, and 102c and conventional landline communication devices. For example, the core network 107 may include or may communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the core network 107 and the PSTN 108. In addition, the core network 107 may provide the WTRUs 102a, 102b, and 102c with access to the network 112, which may include other wired or wireless networks owned and/or operated by other service providers.

Fig. 10D is a system diagram of an exemplary RAN 105 and core network 109. RAN 105 may communicate with WTRUs 102a and 102b over an air interface 117 using NR radio technology. RAN 105 may also communicate with core network 109. A non-3 GPP interworking function (N3 IWF) 199 may communicate with WTRU 102c over air interface 198 using non-3 GPP radio technology. The N3IWF 199 may also be in communication with the core network 109.

RAN 105 may include next generation node bs 180a and 180B. It should be appreciated that the RAN 105 may include any number of next generation node bs. The next generation node bs 180a and 180B may each include one or more transceivers for communicating with the WTRUs 102a and 102B over the air interface 117. When using integrated access and backhaul connections, the same air interface may be used between the WTRU and the next generation node B, which may be the core network 109 via one or more gnbs. The next generation node bs 180a and 180B may implement MIMO, MU-MIMO, and/or digital beamforming techniques. Thus, the next generation node B180a may, for example, use multiple antennas to transmit wireless signals to the WTRU 102a and to receive wireless signals from the WTRU 102 a. It should be appreciated that other types of base stations, such as enode bs, may be employed by RAN 105. It should also be appreciated that the RAN 105 may employ more than one type of base station. For example, the RAN may employ an evolved node B and a next generation node B.

The N3IWF 199 may include a non-3 GPP access point 180c. It should be appreciated that the N3IWF 199 may include any number of non-3 GPP access points. The non-3 GPP access point 180c can include one or more transceivers for communicating with the WTRU 102c over the air interface 198. The non-3 GPP access point 180c can communicate with the WTRU 102c over the air interface 198 using an 802.11 protocol.

Each of the next generation node bs 180a and 180B may be associated with a particular cell (not shown) and may be configured to process radio resource management decisions, handover decisions, user scheduling in the uplink and/or downlink, and so on. As shown in fig. 10D, the next generation node bs 180a and 180B may communicate with each other, for example, through an Xn interface.

The core network 109 shown in fig. 10D may be a 5G core network (5 GC). The core network 109 may provide a variety of communication services to clients interconnected by a radio access network. The core network 109 includes a plurality of entities that perform the functionality of the core network. As used herein, the term "core network entity" or "network function" refers to any entity that performs one or more functions of the core network. It should be appreciated that such core network entities may be logical entities implemented in the form of computer-executable instructions (software) stored in and executed on a processor of an apparatus or computer system configured for wireless and/or network communications, such as system 90 shown in fig. 10G.

In the example of fig. 10D, the 5G core network 109 may include an access and mobility management function (AMF) 172, a Session Management Function (SMF) 174, user Plane Functions (UPFs) 176a and 176b, a user data management function (UDM) 197, an authentication server function (AUSF) 190, a Network Exposure Function (NEF) 196, a Policy Control Function (PCF) 184, a non-3 GPP interworking function (N3 IWF) 199, and a User Data Repository (UDR) 178. Although each of the foregoing elements are depicted as part of the 5G core network 109, it should be understood that any of these elements may be owned and/or operated by an entity other than the core network operator. It should also be understood that the 5G core network may not include all of these elements, may include additional elements, and may include multiple instances of each of these elements. Fig. 10D shows the network functions directly connected to each other, however, it should be understood that they may communicate via a routing agent such as a diameter routing agent or a message bus.

In the example of fig. 10D, the connection between network functions is implemented via a set of interfaces or reference points. It should be appreciated that a network function may be modeled, described, or implemented as a set of services invoked or called by other network functions or services. Invocation of the network function service may be accomplished via a direct connection between network functions, message exchange over a message bus, invocation of a software function, and the like.

AMF 172 may be connected to RAN 105 via an N2 interface and may function as a control node. For example, AMF 172 may be responsible for registration management, connection management, reachability management, access authentication, access authorization. The AMF may be responsible for forwarding the user plane tunnel configuration information to the RAN 105 via the N2 interface. AMF 172 may receive user plane tunnel configuration information from the SMF via the N11 interface. The AMF 172 may generally route and forward NAS packets to/from the WTRUs 102a, 102b, and 102c via the N1 interface. The N1 interface is not shown in fig. 10D.

SMF 174 may be connected to AMF 172 via an N11 interface. Similarly, the SMF may be connected to PCF 184 via an N7 interface and to UPFs 176a and 176b via an N4 interface. The SMF 174 may be used as a control node. For example, the SMF 174 may be responsible for session management, IP address assignment for the WTRUs 102a, 102b, and 102c, management and configuration of traffic steering rules in the UPF 176a and the UPF 176b, and generation of downlink data notifications to the AMF 172.

The UPFs 176a and 176b may provide the WTRUs 102a, 102b, and 102c with access to a Packet Data Network (PDN), such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, and 102c and other devices. The UPFs 176a and 176b may also provide the WTRUs 102a, 102b, and 102c with access to other types of packet data networks. For example, the other network 112 may be an ethernet network or any type of network that exchanges data packets. UPF 176a and UPF 176b may receive traffic steering rules from SMF 174 via an N4 interface. The UPFs 176a and 176b may provide access to the packet data network by connecting to the packet data network via an N6 interface or by connecting to each other and to other UPFs via an N9 interface. In addition to providing access to the packet data network, the UPF 176 may be responsible for packet routing and forwarding, policy rule enforcement, quality of service processing for user plane traffic, downlink packet buffering.

AMF 172 may also be connected to N3IWF 199, for example, via an N2 interface. The N3IWF facilitates the connection between the WTRU 102c and the 5G core network 170, for example, via radio interface technologies that are not defined by 3 GPP. The AMF may interact with the N3IWF 199 in the same or similar manner as it interacts with the RAN 105.

PCF 184 may be connected to SMF 174 via an N7 interface, AMF 172 via an N15 interface, and Application Function (AF) 188 via an N5 interface. The N15 and N5 interfaces are not shown in fig. 10D. PCF 184 may provide policy rules to control plane nodes such as AMF 172 and SMF 174, allowing the control plane nodes to enforce these rules. PCF 184 may send policies for WTRUs 102a, 102b, and 102c to AMF 172 such that the AMF may deliver the policies to WTRUs 102a, 102b, and 102c via an N1 interface. Policies may then be enforced or applied at the WTRUs 102a, 102b, and 102 c.

UDR 178 may act as a repository of authentication credentials and subscription information. The UDR may be connected to a network function so that the network function may add to the data in the repository, read the data in the repository and modify the data in the repository. For example, UDR 178 may be connected to PCF 184 via an N36 interface. Similarly, UDR 178 may be connected to NEF 196 via an N37 interface, and UDR 178 may be connected to UDM 197 via an N35 interface.

The UDM 197 may serve as an interface between the UDR 178 and other network functions. The UDM 197 may grant network functions access to the UDR 178. For example, UDM 197 may be connected to AMF 172 via an N8 interface, and UDM 197 may be connected to SMF 174 via an N10 interface. Similarly, UDM 197 may be connected to AUSF 190 via an N13 interface. UDR 178 and UDM 197 may be tightly integrated.

AUSF 190 performs authentication related operations and is connected to UDM 178 via an N13 interface and AMF 172 via an N12 interface.

The NEF 196 exposes the capabilities and services in the 5G core network 109 to the Application Function (AF) 188. Exposure may occur on the N33 API interface. The NEF may be connected to the AF 188 via an N33 interface and may be connected to other network functions in order to expose the capabilities and services of the 5G core network 109.

The application functions 188 may interact with network functions in the 5G core network 109. Interaction between the application function 188 and the network function may occur via a direct interface or may occur via the NEF 196. The application functions 188 may be considered part of the 5G core network 109 or may be deployed outside of the 5G core network 109 and by an enterprise having a business relationship with the mobile network operator.

Network slicing is a mechanism by which a mobile network operator can support one or more "virtual" core networks behind the operator's air interface. This involves "slicing" the core network into one or more virtual networks to support different RANs or different service types running across a single RAN. Network slicing enables operators to create networks tailored to provide optimized solutions for different market scenarios requiring a wide variety of requirements, e.g., in terms of functionality, performance, and isolation.

3GPP has designed 5G core networks to support network slicing. Network slicing is a good tool that network operators can use to support a variety of 5G usage scenarios (e.g., large-scale IoT, critical communications, V2X, and enhanced mobile broadband) that require very diverse and sometimes extreme requirements. Without the use of network slicing techniques, the flexibility and scalability of the network architecture may not be sufficient to effectively support a wider range of use case requirements when each use case has its own set of specific requirements for performance, scalability, and availability. In addition, new network services should be introduced more efficiently.

Referring again to fig. 10D, in a network slice scenario, the WTRU 102a, 102b, or 102c may connect to the AMF 172 via an N1 interface. An AMF may be a logical portion of one or more slices. The AMF may coordinate the connection or communication of the WTRU 102a, 102b, or 102c with one or more of the UPFs 176a and 176b, the SMF 174, and other network functions. Each of the UPFs 176a and 176b, the SMF 174, and other network functions may be part of the same slice or different slices. When they are part of different slices, they may be isolated from each other in the sense that they may utilize different computing resources, security credentials, etc.

The core network 109 may facilitate communications with other networks. For example, the core network 109 may include or may communicate with an IP gateway, such as an IP Multimedia Subsystem (IMS) server, that serves as an interface between the 5G core network 109 and the PSTN 108. For example, the core network 109 may include or be in communication with a Short Message Service (SMS) service center that facilitates communication via a short message service. For example, the 5G core network 109 may facilitate the exchange of non-IP data packets between WTRUs 102a, 102b, and 102c and a server or application function 188. In addition, the core network 170 may provide the WTRUs 102a, 102b, and 102c with access to the network 112, which may include other wired or wireless networks owned and/or operated by other service providers.

The core network entities described herein and shown in fig. 10A, 10C, 10D, and 10E are identified by giving these entities names in some existing 3GPP specifications, but it should be understood that these entities and functions may be identified by other names in the future, and that some entities or functions may be combined in specifications that are disclosed by 3GPP in the future, including future 3GPP NR specifications. Thus, the particular network entities and functions described and illustrated in fig. 10A-E are provided by way of example only, and it should be understood that the subject matter disclosed and claimed herein may be embodied or implemented in any similar communication system, whether presently defined or defined in the future.

Fig. 10E illustrates an exemplary communication system 111 in which the systems, methods, and apparatus described herein may be used. The communication system 111 may include a wireless transmit/receive unit (WTRU) A, B, C, D, E, F, a base station gNB 121, a V2X server 124, and Road Side Units (RSUs) 123a and 123b. Indeed, the concepts presented herein may be applied to any number of WTRUs, base stations gNB, V2X networks, and/or other network elements. One or several or all of the WTRUs a, B, C, D, E and F may be outside the range of the access network coverage 131. WTRUs a, B, and C form a V2X group, where WTRU a is the group leader and WTRUs B and C are group members.

If WTRUs a, B, C, D, E, and F are within access network coverage 131, they may communicate with each other over Uu interface 129 via the gNB 121. In the example of fig. 10E, WTRUs B and F are shown within access network coverage 131. WTRUs a, B, C, D, E, and F may communicate directly with each other via a side-link interface (e.g., PC5 or NR PC 5), such as interfaces 125a, 125b, or 128, whether they are within access network coverage 131 or outside access network coverage 131. For example, in the example of fig. 10E, WRTU D outside of access network coverage 131 communicates with WTRU F inside of coverage 131.

WTRUs a, B, C, D, E, and F may communicate with RSUs 123a or 123b via a vehicle-to-network (V2N) 133 or a side-link interface 125 b. WTRUs a, B, C, D, E, and F may communicate with V2X server 124 via a vehicle-to-infrastructure (V2I) interface 127. WTRUs a, B, C, D, E, and F may communicate with another UE via a vehicle-to-pedestrian (V2P) interface 128.

Fig. 10F is a block diagram of an exemplary apparatus or device WTRU 102 (e.g., the WTRU 102 of fig. 10A-E) that may be configured for wireless communication and operation in accordance with the systems, methods, and apparatus described herein. As shown in fig. 10F, the exemplary WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keyboard 126, a display/touchpad/indicator 128, non-removable memory 130, removable memory 132, a power source 134, a Global Positioning System (GPS) chipset 136, and other peripherals 138. It should be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements. In addition, base stations 114a and 114B and/or nodes that base stations 114a and 114B may represent, such as, but not limited to, transceiver stations (BTSs), node bs, site controllers, access Points (APs), home node bs, evolved home node bs (enodebs), home evolved node bs (henbs), home evolved node B gateways, next generation node bs (gNode-bs), proxy nodes, and the like, may include some or all of the elements depicted in fig. 10F and described herein.

The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a Digital Signal Processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, application Specific Integrated Circuits (ASICs), field Programmable Gate Arrays (FPGAs) circuits, any other type of Integrated Circuit (IC), a state machine, or the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functions that enable the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to a transceiver 120, which may be coupled to a transmit/receive element 122. While fig. 10F depicts the processor 118 and the transceiver 120 as separate components, it should be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

The transmit/receive element 122 of a UE may be configured to transmit signals to or receive signals from a base station (e.g., base station 114a of fig. 10A) over air interfaces 115/116/117, or to transmit signals to or receive signals from another UE over air interfaces 115d/116d/117 d. For example, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. The transmit/receive element 122 may be an emitter/detector configured to emit and/or receive, for example, IR signals, UV signals, or visible light signals. The transmit/receive element 122 may be configured to transmit and receive both RF signals and optical signals. It should be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals or wired signals.

Further, although the transmit/receive element 122 is depicted as a single element in fig. 10F, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Accordingly, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interfaces 115/116/117.

The transceiver 120 may be configured to modulate signals to be transmitted by the transmit/receive element 122 and demodulate signals received by the transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs (e.g., NR and IEEE 802.11 or NR and E-UTRA) or with the same RAT via multiple beams to different RRH, TRP, RSU or nodes.

The processor 118 of the WTRU 102 may be coupled to and may receive user input data from a speaker/microphone 124, a keypad 126, and/or a display/touchpad/indicator 128 (e.g., a Liquid Crystal Display (LCD) display unit or an Organic Light Emitting Diode (OLED) display unit), the processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad/indicator 128.

The processor 118 may receive power from the power source 134 and may be configured to distribute and/or control power to other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries, solar cells, fuel cells, and the like.

The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or in lieu of information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114 b) over the air interface 115/116/117 and/or determine its location based on the timing of signals received from two or more nearby base stations. It should be appreciated that the WTRU 102 may obtain the location information by any suitable location determination method.

The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software modules and/or hardware modules that provide additional features, functionality, and/or wired or wireless connections. For example, the peripheral device 138 may include various sensors, such as an accelerometer, a biometric (e.g., fingerprint) sensor, an electronic compass, a computer program, a computer readable medium, and a computer program, Satellite transceiver, digital camera (for photo or video), universal Serial Bus (USB) port or other interconnect interface, vibration device, television transceiver, hands-free headset, portable electronic device, and electronic device,Modules, frequency Modulation (FM) radio units, digital music players, media players, video game player modules, internet browsers, and the like.

The WTRU 102 may be included in other apparatuses or devices such as sensors, consumer electronics, wearable devices (such as smart watches or smart clothing), medical or electronic health devices, robots, industrial equipment, drones, vehicles (such as automobiles, trucks, trains, or planes). The WTRU 102 may connect to other components, modules, or systems of such apparatuses or devices via one or more interconnect interfaces, such as an interconnect interface that may include one of the peripherals 138.

Fig. 10G is a block diagram of an exemplary computing system 90 in which one or more devices of the communication networks shown in fig. 10A, 10C, 10D, and 10E, such as some nodes or functional entities in RANs 103/104/105, core networks 106/107/109, PSTN 108, internet 110, other networks 112, or network services 113, may be embodied. The computing system 90 may comprise a computer or server and may be controlled primarily by computer readable instructions, which may be in the form of software, wherever or by whatever means such software is stored or accessed. Such computer readable instructions may be executed within processor 91 to cause computing system 90 to operate. Processor 91 may be a general-purpose processor, a special-purpose processor, a conventional processor, a Digital Signal Processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, application Specific Integrated Circuits (ASICs), field Programmable Gate Arrays (FPGAs) circuits, any other type of Integrated Circuit (IC), a state machine, or the like. Processor 91 may perform signal encoding, data processing, power control, input/output processing, and/or any other functionality that enables computing system 90 to operate in a communication network. Coprocessor 81 is an optional processor, different from main processor 91, that may perform additional functions or assist processor 91. Processor 91 and/or coprocessor 81 may receive, generate, and process data related to the methods and apparatus disclosed herein.

In operation, processor 91 fetches instructions, decodes and executes instructions, and transfers information to and from other resources via the main data transfer path (system bus 80) of the computing system. Such a system bus connects the components in computing system 90 and defines a medium for data exchange. The system bus 80 typically includes data lines for transmitting data, address lines for transmitting addresses, and control lines for transmitting interrupts and for operating the system bus. An example of such a system bus 80 is a PCI (peripheral component interconnect) bus.

The memory coupled to the system bus 80 includes Random Access Memory (RAM) 82 and Read Only Memory (ROM) 93. Such memories include circuitry that allows information to be stored and retrieved. ROM 93 typically contains stored data that cannot be easily modified. The data stored in RAM 82 may be read or changed by processor 91 or other hardware device. Access to RAM 82 and/or ROM 93 may be controlled by memory controller 92. The memory controller 92 may provide address translation functionality that translates virtual addresses into physical addresses as instructions are executed. The memory controller 92 may also provide memory protection functions that isolate processes within the system and isolate system processes from user processes. Thus, a program running in the first mode may only access memory mapped by its own process virtual address space; unless memory sharing between processes has been set, it cannot access memory within the virtual address space of another process.

In addition, the computing system 90 may contain a peripheral controller 83 responsible for delivering instructions from the processor 91 to peripheral devices, such as a printer 94, keyboard 84, mouse 95, and disk drive 85.

The display 86, controlled by the display controller 96, is used to display visual output generated by the computing system 90. Such visual outputs may include text, graphics, animated graphics, and video. The visual output can be provided in the form of a Graphical User Interface (GUI). The display 86 may be implemented with a CRT-based video display, an LCD-based flat panel display, a gas plasma-based flat panel display, or a touch pad. The display controller 96 includes the electronics necessary to generate the video signals that are sent to the display 86.

Further, the computing system 90 may contain communications circuitry such as, for example, a wireless or wired network adapter 97 that may be used to connect the computing system 90 to external communications networks or devices such as the RANs 103/104/105, core networks 106/107/109, PSTN 108, internet 110, WTRU 102, or other networks 112 of fig. 10A-10E to enable the computing system 90 to communicate with other nodes or functional entities of these networks. Communication circuitry alone or in combination with processor 91 may be used to perform the transmit and receive steps of certain apparatus, nodes or functional entities described herein.

It should be understood that any or all of the apparatus, systems, methods, and processes described herein may be embodied in the form of computer-executable instructions (e.g., program code) stored on a computer-readable storage medium, which when executed by a processor (such as processor 118 or 91) cause the processor to perform or implement the systems, methods, and processes described herein. In particular, any of the steps, operations, or functions described herein may be implemented in the form of such computer-executable instructions executed on a processor of a computing system or device configured for wireless and/or wired network communications. Computer-readable storage media include volatile and nonvolatile, removable and non-removable media implemented in any non-transitory (e.g., tangible or physical) method or technology for storage of information, but such computer-readable storage media do not include signals. Computer-readable storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital Versatile Disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other tangible or physical medium which can be used to store the desired information and which can be accessed by a computing system.

/>

/>

/>

/>

/>

/>

/>

/>

/>

/>

/>

/>

/>

/>

/>

/>

/>

/>

/>

/>

/>

/>

/>

/>

/>

/>

/>

/>

/>

/>

/>

/>

/>

/>

/>

/>

/>

/>

/>

/>

Claims (20)

1. A wireless transmit/receive unit, WTRU, comprising a processor, communication circuitry, memory, and computer-executable instructions stored in the memory that, when executed by the processor, cause the WTRU to:

receiving a first positioning reference signal, PRS, configuration, the first PRS configuration comprising an indication of one or more PRS reconfiguration criteria;

receiving a first PRS from a base station gNB according to the first PRS configuration;

making one or more measurements of the first PRS;

if the measurement meets the PRS reconfiguration criteria, sending a PRS reconfiguration request to a device performing a location management function, LMF, of the network;

receiving a second PRS configuration from the LMF device; and

and receiving a second PRS from the gNB according to the second PRS configuration.

2. The WTRU of claim 1, wherein the instructions further cause the WTRU to send a PRS reconfiguration request to the LMF on a condition that the measurement meets the PRS reconfiguration criteria.

3. The WTRU of claim 2, wherein the second PRS is used in a calculation of a location of the WTRU.

4. The WTRU of claim 3, wherein the PRS reconfiguration request includes an indication of a required positioning accuracy.

5. The WTRU of claim 3, wherein the PRS reconfiguration request includes an indication of a required quality of service for a service using the WTRU location.

6. The WTRU of claim 3, wherein the PRS reconfiguration request includes an indication of a required delay for the WTRU location calculation.

7. The WTRU of claim 2, wherein the PRS reconfiguration request includes an indication of a signal measurement and/or a location estimate.

8. The WTRU of claim 2, wherein the PRS reconfiguration request includes an indication of capabilities of the WTRU.

9. The WTRU of claim 1, wherein the first PRS configuration and the second PRS configuration are transmitted using a new air interface positioning protocol a NRPPa.

10. The WTRU of claim 1, wherein the second PRS configuration includes an indication of a time period for which the second PRS configuration is to be used.

11. A method performed by an apparatus that performs a location management function, LMF, of a network, the method comprising:

receiving a positioning reference signal, PRS, resource request from a wireless transmit/receive unit, WTRU, over the network; and

and in response to the PRS reconfiguration request, sending an updated PRS configuration to a base station gNB of the network.

12. The method of claim 10, further comprising transmitting a first PRS configuration to the gNB.

13. The method of claim 11, wherein the first PRS configuration includes an indication of one or more PRS reconfiguration criteria.

14. The method of claim 12, wherein the PRS reconfiguration request includes an indication of a required service level or class of service.

15. The method of claim 12, wherein the PRS reconfiguration request includes an indication of a signal measurement and/or a location estimate.

16. The method of claim 12, wherein the PRS reconfiguration request includes an indication of UE capabilities.

17. The method of claim 12, wherein the first PRS configuration and the updated PRS configuration are transmitted using a new air interface positioning protocol a NRPPa.

18. The method of claim 10, wherein the updated PRS configuration includes an indication of a period of time for which the updated PRS configuration is to be used.

19. The method of claim 10, wherein the updated PRS configuration comprises a positioning system information block posSIB.

20. The method of claim 10, wherein the updated PRS configuration is sent via radio resource control signaling.