Patent Application
20240422725
Positioning protocols and RAN-based positioning signals have been specified in 3GPP since Release 9 LTE for enabling emergency services and location-based services. In Rel-17, 3GPP NR positioning protocols are supported by the Control Plane (CP) positioning architecture over the Uu interface (NG-RAN node to UE). The NR positioning architecture may also be supported by a Secure User Plane Location (SUPL) server, also known as a SUPL Location platform (SLP) or location server, that may leverage any IP bearer. Interworking for CP and UP positioning solutions are defined in TS 38.305, where SUPL can also be used as a tunnel for CP positioning protocols (e.g., LPP). This is shown in the
This background information is provided to reveal information believed by the applicant to be of possible relevance. No admission is necessarily intended, nor should be construed, that any of the preceding information constitutes prior art.
Disclosed herein are method, systems, or apparatus associated with SL positioning of a target UE (e.g., UE to be located), and related issues of discovery, selection, or configuration of the target UE, positioning assist UE (PA-UE), controlling entity, or other functions or devices.
For example, methods, systems, and apparatuses, among other things, as described herein may be configured to receive, from a sidelink (SL) positioning controlling entity or another device, sidelink positioning configuration; based on the received configuration, being triggered (e.g., detecting criteria) to perform a positioning task, and perform the positioning task. The performing of the positioning task may include at least one of the tasks disclosed herein. A task may be associated with sending indication of a use of relative positioning between the UE and a positioning assist (PA) UE or the UE and a controlling entity (CE), positioning mode (UE-based, UE-assisted), SL positioning algorithm, positioning security parameters, or the following tasks. In addition, or alternative to, the tasks may include: discovery of CE, discovery of PA-UE, selection of CE; selection of PA-UE; reception of the position of a PA-UE, a CE or a reference UE; measurement of SL PRS, Uu PRS; calculation of the UE absolute position; calculation of the UE relative position; or report of SL PRS measurements or Uu PRS measurement to a PA UE or a CE. Other tasks may include positioning capability negotiation between the UE and the PA-UE, between the UE and the CE or between the UE and a reference UE. The capability may include one or more of supported positioning type (e.g., absolute position, relative position), positioning algorithms, SL PRS types, or positioning mode (e.g., UE-based, UE-assisted)
Disclosed herein are methods, systems, and devices that may execute new radio (NR) positioning procedures over Sidelink (SL). Particularly, disclosed herein are methods and system to perform SL discovery and selection of a positioning assist (PA) user equipment (UE) transmitting positioning reference signals; methods related to network assisting and configuring a target UE (e.g., remote UE) and PA UEs with positioning reference signal (PRS) resources; methods and system for an NR UE to utilize both Uu and SL PRS; and methods to enable Uu and SL positioning and ranging for UEs equipped with distributed antenna systems.
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 constrained to limitations that solve any or all disadvantages noted in any part of this disclosure.
A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings wherein:
3GPP has defined various protocols to enable several positioning technologies and methods (GNSS, sensors, positioning signals, etc.). The primary protocol, LPP (LTE Positioning protocol), is terminated between the UE and LMF (Location Management Function). LPP is a Point-to-Point LCS and NAS messaging protocol that is defined in TS 37.355 [2]. LPP has been agreed to be re-used for NR since Rel-15 and will continue to be leveraged for the foreseeable future.
RRC (Radio Resource Control) is another protocol used to provide transport for LPP messages and other positioning procedures over the NR-Uu interface, which is terminated between the gNB and the UE [TS 38.331].
On the network side, NGAP (NG Application Protocol) is terminated between the AMF and the NG-RAN Node(s) (i.e., gNB/TRP) and is used as a transport for LPP and NRPPa messages over the NG-C interface [TS 38.413].
Finally, NRPPa (NR Positioning Protocol A) carries information between the NG-RAN Node(s) and the LMF [TS 38.445].
From a protocol perspective for Rel-17,
Further details for this process flow are as follows:
Looking at the positioning procedures related to UE procedures in step 3b of
Positioning can be done as standalone, UE-Based, or UE-Assisted modes. In Standalone positioning, the UE handles the aspects of the positioning, scans for accessible sources of positioning, measures, and processes positioning signals/sources. Finally, the UE computes its own position in 2 or 3 dimensions. In Standalone positioning, the Uu interface impacts include UE capability exchange and reporting of the UE position.
In UE-Based Positioning (UE-B), the network provides acquisition assistance data, and the UE scans for accessible sources of positioning, measures, and processes positioning signals/sources (based on assistance information from the network). Finally, the UE computes its own position in 2 or 3 dimensions and may report its position to the network.
In UE-Assisted Positioning (UE-A), the network provides acquisition assistance, and the UE scans for accessible sources of positioning, measures positioning signals/sources (based on assistance information from NW). Finally, the UE returns measurements to the network, and the network computes the device position (at the location server/LMF) [TS 38.305].
NR positioning modes, mechanisms, and protocols may be extended from leveraging only Uu-based (interface between the 5G UE and NG-RAN) signals to also include Sidelink (SL) mechanisms either to supplement Uu-based approaches or on a standalone SL-only basis. SL communications are direct communications between two or more 5G UEs without the participation of the NG-RAN in the communication. For direct UE-to-UE SL communications establishment, the existing high level L2 procedures are outlined in
The source Layer-2 ID and destination Layer-2 ID used to send the Direct Communication Request message are determined as specified in TS 23.287 may use 5.6.1.1 and 5.6.1.4. The destination Layer-2 ID may be broadcast or unicast Layer-2 ID. When unicast Layer-2 ID is used, the Target User Info shall be included in the Direct Communication Request message.
UE-1 may send the Direct Communication Request message via PC5 broadcast or unicast using the source Layer-2 ID and the destination Layer-2 ID.
The source Layer-2 ID used for the security establishment procedure is determined as specified in TS 23.287 clause use 5.6.1.1 and 5.6.1.4. The destination Layer-2 ID is set to the source Layer-2 ID of the received Direct Communication Request message. Upon receiving the security establishment procedure messages, UE-1 obtains the peer UE's Layer-2 ID for future communication, for signalling and data traffic for this unicast link.
The V2X layer of the UE that established PC5 unicast link passes the PC5 Link Identifier assigned for the unicast link and the PC5 unicast link related information down to the AS layer. The PC5 unicast link related information may include Layer-2 ID information (e.g., source Layer-2 ID and destination Layer-2 ID) and the corresponding PC5 QoS parameters. This enables the AS layer to maintain the PC5 Link Identifier together with the PC5 unicast link related information.
For SL Direct Communications for a remote UE (not in coverage of the NG-RAN) via relay UE, including RRC Connected mode (SRB2) establishment,
It is envisioned that SL positioning reference signals (SL-PRS) may also be communicated between two or more UEs for LCS determination with and without the network directly involved. To illustrate these scenarios, can look at a potential SL positioning connectivity architecture as shown in
There are several possible network coverage scenarios for the radio link possibilities as shown in
For these coverage scenarios, the radio link may include the Uu interface (uplink and downlink, applicable for in-coverage/partial), PC5 interface (sidelink, applicable for in/out/partial coverage), and their combinations. To expand on this terminology, for “Uu-based” solutions, the target UE may use only measurements on Uu interface. For “PC5-based” solutions, the target UE may use only measurements on PC5 interface. Finally, hybrid solutions are also envisioned, whereby UE may use measurements on both Uu and PC5 interfaces [TR 38.845].
Furthermore, specifically for positioning procedures, Uu based solutions may leverage assistance information over the PC5 interface, and PC5 based solutions may leverage assistance information over the Uu interface. If the PC5 (Sidelink) interface is added to
3GPP has defined enhanced positioning protocols, new positioning techniques, and New Radio (NR)-based Positioning Reference Signals (PRS) in Rel-16. The NR PRS is based on the LTE pseudo-random sequences and is specified in TS 38.211. The updated NR PRS further improves hear-ability of the PRS from neighbor cells. This yields an improved positioning accuracy, but it is dependent on network deployment (e.g., density of gNBs/TRPs), RF conditions, and PRS configuration parameters, such as bandwidth, periodicity, or muting patterns as discussed further. Although the existing PRS definition is a robust signal and enables excellent timing (aka ranging) measurements, other PRS signals also may exist that can be leveraged for positioning, such as, SSBs, CSI-RS, PT-RS, DMRS, SRS, or the like for both Uu and SL interfaces, or combination thereof. In fact, some of these types of PRSs may be sufficient for SL-based positioning given generally shorter distances for positioning/ranging.
PRSs enable various positioning techniques. DL-TDOA (DL Time Difference of Arrival) is one such method that leverages a PRS transmission broadcast from an NG-RAN node. UE performs downlink reference signal time difference (DL-RSTD) measurements for each gNB/TRP PRS(s), and optionally DL-PRS-RSRP. These measurements are reported to the LMF (Location Management Function/Location Server) in the case of UE-A. For UE-B, the UE calculates and reports its position to the network.
Another DL technique that leverages broadcast PRS is the AoD (Angle-of-Departure) method. The UE measures the PRS reference signal receive power (DL RSRP) per beam/gNB. Measurement reports are used to determine the AoD based on UE beam location for each gNB. For UE-A, the LMF then may use the AoDs to estimate the UE position or for UE-B, the UE calculates and reports its position to the network.
These multi-lateration techniques are well known and established methods for locating UEs. Geometrically, UE location is derived from each time/range difference (RSTD). Typically, a minimum of 3 gNB (geo-dispersed) measurements are required for reliable position relative to UE internal timing. This also requires a serving (reference) cell as well as timing/RSRP measurements from neighbor cells. It is envisioned that these techniques can be extended to include SL techniques. SL PRS may be advantageous as it would typically be shorter (closer) ranges to the target UE.
Location of TRPs and assistance data (configuration/resource information) can be delivered over the Uu interface either broadcast in positioning System Information Blocks (posSIBs) or in NAS signaling via LPP messages in RRC_CONNECTED.
To expand on these concepts from a SL positioning perspective, SL UEs (anchor UE, relay UE, Road Side Units (RSUs) or the like) can provide positioning reference signals with or without wide area network coverage. Additionally, SL UEs typically benefit from shorter distances between devices, resulting in more accurate location. The requirement for the need for multiple geometrically spaced Positioning Assistance (PA) nodes, as is the case for gNB PRSs, may also be eliminated or reduced while maintaining accurate position by RSTD and RTT techniques (see
For reference and baseline procedures, the IE NR-DL-PRS-Info defines downlink PRS configuration, which is sent from the network (e.g., LMF) to the UE as defined in TS 37.355 (LPP). This assists the UE in reception of PRS transmissions from serving and neighbor cells [TS 37.355]. See Table 1 and Table 2.
The PRS transmission configuration information and assistance data (e.g., NR-DL-PRS-Info) enable a UE to detect and measure positioning reference signals and either calculate 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 a UE to receive PRS-related IEs is via positioning System Information Blocks (posSIBs). The posSIBs contain positioning assistance data associated with a number of positioning technologies including, PRS-related methods such as DL TDOA, DL-AOD and multi-RTT.
The procedures for posSIB acquisition leverage the same procedures as other SIBs (e.g., SIB2, SIB, etc.), For example, SIB1 contains scheduling information (PosSchedulingInfo-r16) associated with the posSIBs. These SIBs are mapped to the BCCH and is either broadcast periodically on DL-SCH or broadcast on-demand on DL-SCH (upon request from UEs in RRC_IDLE or RRC_INACTIVE) or sent in a dedicated manner on DL-SCH to UEs in RRC_CONNECTED.
The IEs that are broadcast in the posSIBs are the same as those defined in LPP. Within 38.331, RRC, PosSystemInformation-r16-IEs maps to positioning SIB type (posSibType) where detailed AD IEs are defined in LPP.
Some of the Relevant IEs for PRS related positioning methods are defined in 37.355 clause 6.4.3, 7.4.2 and then mapped to the following posSIBTypes in RRC as in Table 3.
The Study on scenarios and requirements of in-coverage, partial coverage, and out-of-coverage NR positioning use cases (Release 17) concluded a number of use cases and requirement enhancements over the existing Rel-16/17 NR positioning methods. Positioning can refer to both absolute and relative positioning (ranging). Absolute position refers to an estimate of the UE position in 2D/3D geographic coordinates (e.g., latitude, longitude, elevation) within a coordinate system (e.g., WGS-84). Relative position also known as ranging refers to an estimate of the UE position relative to network elements, positioning assistance/reference nodes, or relative to other UEs. Namely, the following two general use cases were identified, but other commercial or Industrial IoT use cases can be envisioned [TR 38.845]: V2X or public safety.
V2X (Vehicle-to-everything). This use case involves traffic safety, traffic efficiency and information services. These sets of use cases carry the following requirements: Indoor (e.g., tunnel) and outdoor scenarios as well as in-coverage, out-of-coverage and partial network coverage scenarios. Some of the requirements and performance metrics are defined in a range depending on the positioning service level: 2-3 m (absolute) or 0.2 m (relative) vertical accuracy; Absolute (Lat/Long/Height Above Ellipsoid (HAE) coordinates of UE) and Relative (distance/angle between 2 UEs/nodes); 95-99.9% positioning service availability; 10 ms-1 s positioning service latency; or including GNSS-based positioning is not available or not accurate enough.
Public Safety. This use case involves “First responders” tracking and guidance. These sets of use cases carry the following requirements: Indoor and outdoor scenarios as well as in-coverage, out-of-coverage and partial network coverage scenarios. Some of the requirements and performance metrics are defined in a range depending on the positioning service level: 1 m horizontal accuracy; 2 m (absolute) or 0.3 m (relative) vertical accuracy. Absolute (Lat/Long/Height Above Ellipsoid (HAE) coordinates of UE) and Relative (distance/angle between 2 UEs/nodes); 95-98% positioning service availability; 1-5 s positioning service latency; or including scenarios where GNSS-based positioning is not available or not accurate enough.
As a point of clarity, the term user equipment (UE) defined herein, is broadly defined as a device with a communications module that may be used in positioning operations. For V2X use cases, a UE that may be involved in positioning can be installed in a vehicle, a roadside unit (RSU), or a device of a vulnerable road user (VRU). For these use cases, the UEs are collectively referred to as a Positioning Assist (PA) UE. Additionally, a UE in a vehicle or an RSU can be equipped with a distributed antenna system (DAS)-multiple antennas installed at different locations to improve positioning sensitivity and geometrical/angular calculation enhancements. DAS is particularly helpful in environments where only one TRP/RSU/VRU is available to a target UE. In these cases, measurements can be made by leveraging each antenna and measurement differences, and the target UE is able to determine, more accurately, the position (relative or absolute position).
The term target UE is the device for which the position/location is to be determined. The term relay UE/function in the context of SL positioning refers to a UE to Network relay or UE-to-UE relay that essentially extends network coverage by relaying positioning reference signals, connectivity, or associated configurations between the network and target UEs for partial network coverage scenarios. Terms anchor, or master (controlling) entity (e.g., function or UE) may refer to positioning assist (PA) devices to aid a target UE in position determination. Similarly for various SL positioning scenarios, anchor UEs (RSUs, etc.) will serve as positioning nodes to aid a target UE for positioning and ranging procedures.
A first issue addressed herein is related to discovery, selection, and configuration of target UEs for SL positioning and ranging without Uu involvement.
To support both absolute and relative positioning that leverages SL positioning reference signals, the following issues may be addressed for a target UE, master (controlling) entity (e.g., function or device), PA UE, or Relay UE without Uu involvement. In these scenarios, the master (controlling) entity may be a non-network node. Determining SL positioning procedures when direct communications over SL is not established may also be particularly beneficial for latency and signaling overhead reduction.
An overall procedure and architecture to support a target UE to discover, select, or receive assistance for SL UE(s) to aid in the positioning determination function is needed. The procedures may include support for the following considerations.
A first consideration is for (pre) configuration of a target UE, master (controlling) entity, PA UE, or relay UE/function to support in the SL positioning discovery or selection. For example, SL-PRS parameter configuration(s) from existing DL-PRS configurations, resource allocation, and SL-PRS muting functions as well as other reference signals that may be leveraged. In another example, SL-SRS parameter configuration(s) optimizations from existing UL SRS configurations or resource allocation methods. In another example, subsequent update of initial configurations or associated triggers. Subsequent update of initial configurations and associated triggers.
A second consideration may be how to perform identification or authentication of target UE, master (controlling) entity, PA UE, or Relay UE/function. A third consideration may define procedures for capabilities exchange for SL positioning entities/UEs. A fourth consideration may define triggers to instigate positioning procedures for target UE, master (controlling) entity, PA UE, or Relay UE/function.
A fifth consideration may define target UE selection criteria or priorities for master (controlling) entity, PA UE, or Relay UE/functions that are dependent on use case, environment, or key performance indicators (KPIs). Existing SL UE selection criteria leverages, e.g., RSRP measurements, which may not always be necessary for positioning. Priorities or selection criteria may consider, e.g., relative or absolute proximity, absolute velocity, LOS/NLOS determination, known/unknown absolute locations, or capabilities, among other things.
A sixth consideration may be how to support the SL positioning procedures scenarios within the existing positioning protocols or framework without Uu involvement. A seventh consideration may be how to enable, define, or implement security, access restrictions, or authorization for positioning information and SL-PRS, especially in public safety use cases. Examples include temporary access and configurations to SL-PRS or request and update SL-PRS transmission(s) “on-demand.” An eighth consideration may define how and what entity is the positioning calculation/determination function, measurements, or measurement configuration are carried out, e.g., target UE, master (controlling) entity, PA UE. Or account for target UE internal Tx/Rx delays in measurements, among other things.
This first issue may be addressed by the following first approach associated with discovery, selection, assistance of SL Positioning UEs, or SL ranging/positioning configuration without Uu involvement. In the first approach, methods or systems for a target UE may perform positioning measurements or receive associated configuration for SL positioning reference signals that are transmitted from one or more positioning assist (PA) UEs, without Uu involvement in the positioning procedures, comprising one or more of the following steps. The target UE may receive pre-configuration from the network, master (controlling) entity, or pre-provisioned with: SL positioning service, SL discovery authorization, SL discovery identifiers, measurement configuration, or SL-PRS reception resource and configuration set. The target UE or one or more positioning assist (PA) UEs (which may include a master (controlling) entity) may be configured to carry out positioning procedures autonomously from the network. The target UE, upon trigger of an LCS request, may perform tasks, which may include sending or receiving one or more of the following (which may be associated with direct discovery of one or more PA UEs): an announcement positioning discovery message, a solicitation positioning discovery message, a response positioning discovery message, PA UE sensing involving the PA UE transmitting broadcast posSIBs, or other system information.
With continued reference to the first approach, the target UE may select one or more of the authorized PA UEs that meet the configured criteria or capabilities to initiate positioning procedures. SL direct communication link may be established between the target UE and the relay UE/function. SL direct communication link may be used to exchange LCS messages or configure LCS messages. For SL direct communication, security may be established between the target UE and PA UE(s). Security may be established for SL positioning without SL direction communication. LCS procedures may be initiated between the target UE and PA UEs to determine the absolute or relative position of the target UE. LCS procedures may include requesting capabilities, providing capabilities, requesting assistance data, providing assistance data, requesting location information, or providing location information. The target UE may provide additional SL-PRS requests to modify the initial SL-PRS transmissions, existing SL-PRS transmissions, or positioning configurations from the PA UE(s).
The second issue is associated with supporting absolute and relative positioning that leverages SL positioning reference signals, in which the issue may be addressed for a target UE, master (controlling) entity, PA UE, or relay UE/function with Uu involvement. In these scenarios, the master (controlling) entity may be a network node (e.g., LMF), or designated by the network node.
There is a need for a procedure or architecture to support a target UE to discover, select, or receive assistance for SL UE(s) to aid in the positioning determination function. The procedures may include support for the following considerations. A first consideration may be with regard to (pre) configuration of a target UE, Master (controlling) entity, PA UE, and Relay UE/function to support in the SL positioning discovery and selection. For example, SL-PRS parameter configuration(s) from existing DL-PRS configurations, resource allocation and SL-PRS muting functions as well as other reference signals that may be leveraged. In an example, SL-SRS parameter configuration(s) optimizations from existing UL SRS configurations or resource allocation methods. In another example, subsequent update of initial configurations and associated triggers. A second consideration may be how to perform identification and authentication of target UE, master (controlling) entity, PA UE, or relay UE/function. A third consideration may be for defining procedures for capabilities exchange for SL positioning entities/UEs. A fourth consideration may define triggers to instigate positioning procedures for target UE, master (controlling) entity, PA UE, or relay UE/function.
With reference to a second issue, a fifth consideration may by with regard to defining target UE selection criteria and priorities for master (controlling) entity, PA UE, or relay UE/functions that may be dependent on use case, environment, or KPIs. Existing SL UE selection criteria may leverage RSRP measurements, which may not be necessary for positioning. Priorities or selection criteria may consider relative or absolute proximity, absolute velocity, LOS determination, NLOS determination, unknown absolute locations, known absolute locations, or capabilities, or the like. A sixth consideration may be for how to support the SL positioning procedures scenarios within the existing positioning protocols and framework without Uu involvement. A seventh consideration may be for how to enable, defining security, implementing security, access restrictions or authorization for positioning information and SL-PRS, especially in public safety use cases. Examples may include temporary access or configurations to SL-PRS, request SL-PRS transmission(s) on-demand, or update SL-PRS transmission(s) on-demand. An eighth consideration may be for defining how or what entity is the positioning calculation/determination function, measurements and measurement configuration are carried out by target UE, master (controlling) entity, or PA UE. Account for target UE internal Tx/Rx delays in measurements.
This second issue may be addressed by the following second approach associated with discovery, selection, and assistance of SL positioning UEs and SL ranging/positioning configuration with Uu involvement.
In the second approach, method or system for a target UE may be operatively coupled to a location server (e.g., LMF) via one or more of PA UE, to perform SL positioning function and for SL direct connectivity, to perform positioning configuration for SL-PRS transmissions comprising one or more of the following steps. The target UE may receive pre-configuration from the network, master (controlling) entity, or pre-provisioned with: SL positioning service, SL discovery authorization and identifiers, measurement configuration, or SL-PRS reception resource and configuration set. The target UE upon trigger of an LCS request, may perform direct discovery of one or more PA UEs 202, which may include one or more of the following: an announcement positioning discovery message, a solicitation positioning discovery message, a response positioning discovery message, PA UE sensing involving the PA UE transmitting broadcast posSIBs, or other system information.
With continued reference to the second approach, target UE may select one or more of the authorized PA UEs that meet the configured criteria or capabilities to initiate positioning procedures. For SL direct communication link including security may be established between the target UE and PA UE(s). SL direct communication link may be established and used to tunnel LCS messages to the network upon PC5-RRC connected mode. SL LCS procedures may be initiated between the target UE and PA UEs to determine the absolute or relative position of the target UE. LCS procedures may include requesting capabilities, providing capabilities, requesting assistance data, providing assistance data, requesting location information, or providing location information. The target UE may provide additional SL-PRS requests to modify the initial SL-PRS transmissions, existing SL-PRS transmissions, or positioning configurations from the PA UE(s).
A third issue addressed herein is related to enhanced Uu and SL procedures, to support ranging and positioning for UEs equipped with a distributed antenna system (DAS).
The third issue is associated with supporting absolute or relative positioning that leverages SL-PRS (or combination of SL-PRS and DL-PRS) or SL-SRS. UEs equipped with a DAS may require enhancements to the existing positioning protocols or procedures. The following is addressed. Measurement configuration and measurement reporting procedures may need to be address scenarios with DAS including target UE as well as PA UE, e.g., additional positioning nodes (VRU, RSU, etc.). The identification of a single antenna versus distributed antenna system (e.g., type) or associated capability exchange is addressed.
In the third approach, methods, or systems to configure or enable DAS measurements at a target UE or PA entity may comprise location protocol messages that support the following steps for a procedure. A procedure may include initial positioning configuration of a target UE via Uu or SL interfaces. A procedure may include capabilities exchange between the target UE and network or SL PA UEs that may include DAS support or type(s) of DAS. A procedure may include target UE request antenna configuration assistance data of PA UEs to the network or PA UE. A procedure may include target UE reception of antenna configuration assistance data of PA UEs from the network or PA UE. A procedure may include target UE Measurement reports that may encompass separate measurements for two or more antennae sent to the network or master (controlling) entity.
The detailed approaches described herein may be used on their own or in combination with each other to perform SL positioning functions from SL positioning reference signals or associated SL configuration. In an example, the approaches may help achieve relative (ranging) or absolute positioning via SL signals or configuration, among other things.
To improve accuracy and efficiency for absolute and relative positioning, it is proposed to enhance the existing NR positioning procedures and architecture to support positioning of a target UE via SL positioning reference signals (SL-PRS) and associated configurations.
To illustrate the procedures necessary to achieve positioning over SL, the following high-level steps are illustrated in the general process flow as shown in
The details of these enhanced procedures and architectures are further described herein. The entities involved in the SL positioning procedures include the legacy LCS entities as previously described, e.g., LCS client, LMF, or location server. However, the target UE 201 may discover and communicate with one or more SL Positioning Assist (PA) UE(s) 202 without the involvement of the network (including NG-RAN 207, AMF, LMF 206) for the positioning operations. It is envisioned that a PA UE 202 (or other entity) may include a plurality of logical functions, which may reside on a single device or a plurality of devices. These logical functions may include a positioning assist (PA) function to perform SL positioning and ranging procedures and transmit SL-PRS, a master (e.g., controlling) entity that serves as the controlling entity for SL positioning or ranging procedures to locate a target UE 201, and a SL Relay UE/Function (UE-to-UE relay) that provides the direct communication (e.g., PC5-RRC link) operations.
To further illustrate the procedures associated with the SL positioning operations without network involvement over Uu interface, the following sections detail steps that may apply.
At step 221, NR SL positioning discovery authorization, service authorization, or (pre) configuration may be performed by the target UE 201 and one or more PA UEs 202. The target UE 201 or PA UE(s) 202 may obtain initial positioning configuration information via e.g., broadcast system information, (pre) provisioning, or dedicated signaling whilst the UE(s) are in network coverage. This may allow for SL UE configuration or resource allocation to occur autonomously from the NG-RAN/network over the Uu interface. For some scenarios, the SL positioning (pre) configuration may be accompanied by a validity time or validity timer. Additionally, the SL positioning (pre) configuration may be associated with a validity area, which may be a geographic area or area associated with network coverage.
With continued reference to step 221, the configuration information may include provisioning or registration of positioning service, positioning service type (e.g., emergency, (a) periodic, relative, absolute position, etc.), positioning QOS (e.g., KPI) requirements, PA UE selection criteria or priority (separate PA UE/master entity e.g., (PRS) threshold for SL Positioning signal and threshold for SL Direct Communication for Relay UE/function), UE group identifiers (e.g., Layer-2 Group ID), initial SL-PRS parameters/resources (e.g., PRS type, PRS muting patterns, initial B/W, periodicities, or associated measurement configuration), discovery mechanism configurations, or the like. As part of the initial service authorization or (pre) configuration, some PA UEs 202 may be configured or designated as a master PA UE (master entity) in which the PA UE 202 has authorization to instigate (e.g., send or trigger) LCS requests, perform target UE positioning calculation, or other positioning operations for one or more target UEs 201 and a plurality of PA UEs 202. The SL Relay UE/function may also obtain SL direct communication service authorization and (pre) configuration via provisioning, dedicated signaling, or broadcast from the network while in-coverage.
The SL positioning discovery authorization or provisioning may be initiated by target UE 201 or PA UE(s) 202. This may include UE capabilities or type exchange or other information that may be required to facilitate positioning procedures for target UEs 201 or PA UE(s) 202. Note, this step may occur prior to or after positioning triggers (e.g., LCS requests).
With reference to step 222, for out-of-coverage scenarios and scenarios without Uu involvement, the target UE 201 may instigate SL positioning or PA UE discovery procedures. In some scenarios, target UE 201 or PA UE 202 may be equipped with an LCS client that may be configured for higher layer (e.g., application layer) triggers to instigate the LCS request of step 222. The LCS client or application may trigger the SL-PRS LCS request to determine position, periodic position, or due to other positioning methods that are not available (e.g., GNSS not available or degradation).
In other scenarios, a master (controlling) entity 203 (e.g., PA UE 202) may instigate the LCS request to the target UE 201, via, for example, LCS client/higher layers/application, if it is configured or designated as such in step 221. In these cases, the master entity or PA UE 202 may also broadcast or multicast its own position information via, for example, SL MIB/SIB (posSIB).
With continued reference to step 222, for these scenarios, there may be an indication of the positioning service type requested. For example, there may be a request for relative position or absolute position. Position requests may also target a particular QoS or KPIs associated with the LCS request. These may include one or more factors, such as Lat/Long/altitude for three dimensions, speed relative to another UE, or trajectory relative to another UE. For example, the LCS request may include a requirement (e.g., criteria) for a threshold speed relative to another UE.
At step 223, there may be multiple types of positioning or SL direct communications discovery message models, such as disclosed with step 223a, step 223b, or step 223c.
At step 223a, there may be a Model A type direct discovery that may use a single PA UE discovery protocol message, e.g., an announcement. The target UE 201 or PA UEs 202 may use pre-configured or provisioned configuration information from step 221 or another step. For example, the SL-PRS positioning techniques, scenarios supported, absolute or relative position support, selection criteria, or selection security, among other things. Information used for discovery may include positioning mode (e.g., UE-based or UE-assisted) or positioning type (e.g., absolute or relative/ranging) supported or requested.
At step 223b, there may be a Model B type direct discovery that may use two PA UE discovery protocol messages (e.g., solicitation and response). The PA UE 202 may send a solicitation message to the target UE 201, which in turn responds to PA UE 202. The target UE 201 or PA UEs 202 may use pre-configured information or provisioned configuration information from step 221 or other steps. For example, the SL-PRS positioning technique(s) or SL-PRS signal(s) supported, scenarios supported, absolute or relative position support, selection criteria and security to aid in target UE discovery. Information used for discovery may include positioning mode (e.g., UE-based or UE-assisted) or positioning type (e.g., absolute or relative/ranging) supported or requested.
At step 223c, there may be SL-PRS Discovery/sensing, in which discovery and PA UE “sensing” may involve the PA UE 202 transmitting broadcast posSIBs or System Information that may be leveraged by the target UE 201. Moreover, the PA UE 202 may transmit SL-SSB that may be inclusive of identification, discovery data that may also be used as part of the SL-PRS. The target UE 201 or PA UE 202 may leverage (pre) configuration to assist in discovery (e.g., sensing). In some cases, the target UE 201 may only need to receive SL-SSB from the PA UE 202 and perform measurements based on synchronization signals. In other scenarios, the SL-SSB from the PA UE 202 may enable acquisition of PSBCH to receive SL positioning configuration information or SL DMRS, which may also be leveraged by the target UE 201 for positioning measurements.
In one exemplary method, the existing Sidelink MIB (based on TS 38.331 section 6.2.2) may be modified to include assistance information for the target UE 201 to extract SL-PRS configuration or SL-PRS measurements (as previously described SL-PRS may involve signals, such as SSBs, CSI-RS, PT-RS, DMRS, or the like).
(MasterInformationBlockSidelink) may include the system information transmitted by a UE via SL-BCH, including configuration information for SL positioning and ranging. See Table 4 and Table 5. Configuration information may include RLC-SAP: TM; Logical channel: SBCCH; or Direction: UE to UE.
At step 224, target UE 201 may select one or more of the authorized PA UE 202 that meet the configured criteria to initiate positioning procedures, including measurements performed on SL-PRS(s). For this step 224, it may not be necessary to have established SL direct communication and the logical Relay Function 205 may or may not be present at the PA UE 202 (e.g., a separate PA UE may offer the SL PA UE or master entity and another PA UE may offer the Relay UE/function to aid in configuration). For simplicity, these functions are shown in
At step 225, SL positioning request or SL direct communication request may be sent from the target UE 201 to the PA UE(s) 202. The target UE 201 identifying information (e.g., layer-2 group ID) may include one of the following: SL positioning request or SL direct communication request. SL positioning request may include a request for SL-PRS transmission, request for SL-PRS configuration to assist in reception of PRS signals, request for capabilities, or the like. SL direct communications request may include request for unicast, broadcast/multicast. A request may include a SL positioning request and SL direct communications request. No request may be necessary if PA UE SL-PRS is detected with pre-configuration or sufficient QoS (e.g., KPIs) criteria are met as determined by the target UE 201.
At step 226, security establishment between target UE 201 and PA UE(s) relay function 205. The discovery procedures may enable the positioning authorization and SL direct communication security establishment between the target UE 201 and the PA UE(s) 202.
At step 227, SL positioning response or SL direct communication response may be executed. The SL response message(s) may be sent from one or more the PA UE(s) 202. The response message may include specific aspects of the request and approve, deny, or partially approve. In some methods, the SL positioning or SL direct communications responses may have a relationship or dependencies on one another. For example, depending on configuration and UE capabilities or requirements, the response message may categorically approve or deny the request.
Note that step 228-step 236 may be required if the SL request also includes a SL direct communication request. A direct communication request may be required if the target UE 201 requests SL-PRS reconfiguration or requires additional information (e.g., capabilities, resources, or configuration) from PA UE 202.
At step 228, if SL direct communication establishment is requested, the target UE 201 may send the first RRC message (e.g., RRCSetupRequestsidelink) for its connection establishment with the relay function 205, using a default Layer-2 configuration on SL (e.g., PC5).
At step 229, there may be a message (e.g., RRCSetupSidelink) delivery to the target UE 201, which may use the default configuration on SL (PC5). The target UE 201 may initiate its own connection establishment upon reception of the message on the default L2 configuration on PC5.
At step 230, PC5 RLC channel for SRB1 may be prepared. The relay function 205 and target UE 201 may perform channel setup procedure over Sidelink. The target UEs 201 may receive configuration from PA UE (if necessary), and the relay function 205 or target UE 201 may establish an RLC channel for SRB1 over PC5.
At step 231, target UE SRB1 message (e.g., an RRCSetupComplete message) may be sent to the PA UE Relay function 205 using SRB1 relaying channel over PC5. Then the target UE 201 may be connected to PA UE 202 over PC5-RRC.
At step 232, target UE 201 and PA UE relay function 205 may establish security mode (e.g., sending or receiving SecurityModeCommand.message), if not (pre) configured.
At step 233, target UE 201 may send security mode complete message (e.g., SecurityModeComplete message) to the PA UE relay function 205.
At step 234, PA UE relay function 205 may setup up additional RLC channels between the target UE 201 and PA UE 202. According to the (pre) configuration from step 221, the PA UE 202 or target UE 201 may set up additional RLC channels between the target UE 201 and PA UE 202 to modify the PC5-RRC connection, e.g., to modify/release SL RBs, to (re-)configure NR sidelink measurement and reporting, to (re-)configure SL-PRS, or sidelink CSI reference signal (CSI-RS) resources. The RRCReconfigurationSidelink may be sent to the target UE 201 from the PA UE, which may setup the relaying SRB2/DRBs that is similar to procedures outlined in TR38.836.
At step 235, target UE 201 may send a message (e.g., RR (ReconfigurationSidelinkComplete) from the target UE 201 to the PA UE relay function 205 as a response.
At step 236, prepare PC5 RLC channel for SRB2 via PA UE 202. The target UE 201 or PA UE relay function 205 may perform channel setup procedure over SL. The PA UEs 202 or target UEs 201 may use (pre) configuration, and the PA UE 202 or target UE 201 establish an RLC channel for SRB2 over PC5. This step prepares the RLC channel for SRB2 to enable SL (bi-directional, e.g., pseudo-DL/UL) information transfer.
At step 237, selection of additional PA UE(s) 202 or reception of PRS with associated configuration in PC5-RRC Connected mode may occur.
Step 238-step 246 may be in addition to one or more steps of step 221-step 237. At step 238-step 246 there may be LCS specific messages and procedures (e.g., LPP) which may be dependent upon the positioning mode and some possible pre-configuration. In this scenario, the PA UE 202 (master entity 203) may provide the SL positioning operations.
Step 238 may be associated with LPP request capabilities. The PA UE 202 may send a NAS message (e.g., RRC DL Information Transfer) to the target UE 201. RRC DL Information Transfer (LPP PDU). The PA relay function UE may send a NAS message to the target UE 201 originating from the master entity 203 (also referred herein as master function 203). The NAS message may be encapsulated in an RRC message that is sent over the SL via the PA UE 202 (Relay function 205), and the PA UE 202 (Relay Function) may forward the message to the target UE 201.
Step 239 may be associated with LPP providing capabilities. The target UE 201 may send a NAS message (RRC UL Information Transfer) to the PA UE 202. The target UE 201 may send the NAS message to the master entity 203 via the PA UE 202 (Relay Function 205). The NAS message is encapsulated in an RRC message that is sent over the SL from the target UE 201 via the PA UE 202 (Relay function 205), and the PA UE 202 (Relay Function 205) may forward the message to the master entity 203.
At step 240, target UE 201 may send a LPP Request Assistance Data associated NAS message (RRC UL Information Transfer) to the PA UE 202. RRC UL Information Transfer may be a LPP PDU. The target UE 201 may send this NAS message to the master entity 203 via the PA UE 202 (Relay Function 205). The NAS message may be encapsulated in an RRC message that is sent over the SL from the target UE 201 via the PA UE 202 (Relay function), and the PA UE 202 (Relay Function) may forward the message to the master entity 203.
At step 241, the PA UE 202 may send a LPP Provide Assistance Data associated NAS message (RRC DL Information Transfer) to the target UE 201. RRC DL Information Transfer may be LPP PDU. The PA relay function UE 205 may send this NAS message to the target UE 201 originating from the master entity 203. The NAS message may be encapsulated in an RRC message that is sent over the SL via the PA UE 202 (Relay function), and the PA UE 202 (Relay Function 205) may forward the message to the target UE 201.
At step 242, the PA UE 202 may send LPP Request Location Information associated NAS message (RRC DL Information Transfer) to the target UE 201. There may be a timer (or time) associated with the validity for the location request. RRC DL Information Transfer may be LPP PDU. The PA relay function UE 205 may send this NAS message to the target UE 201 originating from the master entity 203. The NAS message may be encapsulated in an RRC message that may be sent over the SL via the PA UE 202 (Relay function 205), and the PA UE 202 (Relay Function 205) may forward the message to the target UE 201.
Step 243 may be associated with UE measurements and optionally measurement (re) configuration of PA UE(s) 202. At step 243, the target UE 201 may also send an offset for timing measurements that include an adjustment for internal transmit or receive delays and not only absolute values.
Step 244 may be associated with UE positioning calculation. At step 244, the target UE 201 may perform positioning determination for UE-based mode of operation per configuration. Note that absolute and relative position determination is possible.
Step 245 may be associated with LPP provided location information. At step 245, the target UE 201 may send this NAS message (RRC UL Information Transfer) to the PA UE 202. RRC UL Information Transfer. LPP PDU. The target UE 201 may send this NAS message to the master entity 203 via the PA UE 202 (Relay Function 205). The NAS message may be encapsulated in an RRC message that is sent over the SL from the target UE 201 via the PA UE 202 (Relay function 205), and the PA UE 202 (Relay Function 205) forwards the message to the master entity.
Step 246 may be associated with PA UE positioning calculation. At step 246, the PA UE 202 may calculate the target UE 201 position for UE-assisted SL Positioning operations whereby the master entity is performing the positioning calculation function. Note that absolute and relative position determination is possible.
Furthermore, on discovery messages, announcements, solicitation and response, or PA UE 202 selection one or more of the following (pre) configuration IEs (e.g., parameters) may be provided. The (pre) configuration IEs may be specific to UE or group of UEs based on e.g., zone ID, beam ID, application ID, or destination layer-2 group ID. The (pre) configuration IEs may be associated with a NG-RAN serving cell/beam/area or network, e.g., TAC, RNA, PLMN, or S-NSSAI. The (pre) configuration IEs may be associated with (de) activation of a preconfigured SL-PRS resource set or subset. The (pre) configuration IEs may be counter limit (e.g., number of target UE 201 requests allowed). The (pre) configuration IEs may be validity or time limit for positioning service authorization, or associated prohibit timer. The (pre) configuration IEs may be service type, e.g., public safety, commercial, V2X, IoT, etc. The (pre) configuration IEs may be emergency services. The (pre) configuration IEs may be QoS attributes, which may include positioning accuracy, positioning latency, inter-cell interference, measurements, or associated thresholds or levels.
Other examples may address “on-demand” aspects of SL-PRS, related to Rel-17 DL-PRS “on-demand” enhancements. SL-PRS may not always be present or sufficient (e.g., PRS type, bandwidth, or periodicity) to meet QoS (e.g., KPI) requirements. Therefore, the target UE 201 may request SL-PRS transmissions from PA UEs 202. For an out of coverage scenario, the procedures depicted in
In further exemplary methods, the target UE 201 may leverage SL-SRS (Sounding Reference Signals) in the SL received at the PA UE 202 as well. As shown in
For configuration of target UE 201 and PA UE 202, to support both absolute and relative positioning that leverages SL-PRS (or combination of SL-PRS and DL-PRS) it is proposed that both SL and Uu positioning may be used together. Discovery, selection, and assistance of SL UEs may be accomplished with Uu involvement. The target UE 201 may be aided by the network (gNB, LMF) including tunneling of LCS messages to the Network for SL configuration and appropriate SL-PRS resource allocation.
It is envisioned that the PA UE 202 described may include a plurality of logical functions. Herein on the SL PA Function 204 (also a master entity) and the Relay (UE-N/W relay) Function 205. Note that in this case, the master entity 203 may take some role or a shared role of an LMF, but in the primarily, the controlling entity may be the N/W (e.g., LMF) and may be dependent upon the network coverage scenario (e.g., in, partial, or out) and other factors. It may also be envisioned that the logical PA UE 202 entities may be a single physical entity or separate entities, or deployed as combinations thereof. To further illustrate the procedures associated with the SL positioning operations with network involvement over Uu interface, the following detailed steps may apply as shown in in
Step 270 is associated with NR SL positioning service authorization or SL Direct Communication service authorization and (pre) configuration being performed by the target UE 201 (remote) or one or more PA UE 202 (master entity, relay UE functions). The target UE 201 or PA UEs 202 may obtain positioning initial configuration information via broadcast system information, (pre) provisioning, or dedicated signaling. For some scenarios, the SL positioning (pre) configuration may be accompanied by a validity time or validity timer. Additionally, the SL positioning (pre) configuration may be associated with a validity area, either geographic area or area associated with network coverage.
The configuration information may include provisioning of positioning service, positioning service type, positioning QoS requirements, PA UE selection criteria and priority (e.g., separate signal (PRS) threshold for SL Positioning signal and threshold for SL Direct Communication), UE group identifiers (e.g., Layer-2 Group ID), initial SL-PRS parameters or resources (e.g., PRS type, PRS muting patterns, initial B/W, periodicities, and associated measurement configuration), discovery mechanism configurations, or the like. As part of the initial service authorization and (pre) configuration, some PA UEs 202 may be configured or designated as a master entity 203 in which the PA UE 202 has authorization to instigate LCS request or perform target UE 201 positioning calculation or other positioning operations for one or more target UEs 201 and a plurality of PA UEs 202. SL Relay UE function may also obtain SL direct communication service authorization and (pre) configuration via provisioning, dedicated signaling, or broadcast from the network.
With reference to step 271, for the target UE 201 (remote) or one or more PA UEs 202, the SL positioning discovery authorization and provisioning may be initiated by the network or the UE(s). This may include UE capabilities (e.g., type) exchange (e.g., only certain device types/class such as non-RedCap UEs are authorized) or other information necessary to facilitate positioning procedures for the target UEs 201 or PA UEs 202. Note, this step 271 or other steps may occur prior to or after Positioning triggers or LCS requests.
At step 272, there may be a LCS request sent or received. With reference to step 272, for in-coverage scenarios. For a first in-coverage scenario, an entity in the 5GC (e.g., LMF, Location Server) may request some location service (e.g., positioning) for a target UE 201. In a second in-coverage scenario, the serving AMF for a target UE 201 may determine the need for a location service, e.g., to locate the UE for an emergency call. In a third in-coverage scenario, the target UE 201 may request some location service (e.g., positioning or delivery of assistance data/configuration) to the serving AMF at the NAS level. In a fourth in-coverage scenario, the PA UE 202 (master entity 203) may instigate the LCS Request to the target UE 201, if it is configured and designated as such in step 270. In these cases, the master entity 203 may also broadcast or multicast its own position information via e.g., SL MIB/SIB (posSIB).
For out-of-coverage (see previous discussion) and partial coverage scenarios, the target UE 201 instigates SL positioning and PA UE discovery procedures. Alternatively, a PA UE 202 (master entity 203) may instigate the LCS Request to the target UE 201, if it is configured and designated as such in step 270. In these cases, the master entity 203 may also broadcast or multicast its own position information via, for example, SL MIB/SIB (posSIB).
In some scenarios, the target UE 201 or PA UE 202 may be equipped with an LCS client, configured for higher layer/application layer triggers to instigate (e.g., trigger) the LCS request. The LCS client or application may trigger the SL-PRS LCS request to determine position, periodic position, or due to other positioning methods that are not available (e.g., GNSS not available or degradation).
Step 273 may be associated with discovery messages. At step 273a, there may be Model A type direct discovery that may use PA UE discovery protocol messages, e.g., announcements. In the SL positioning context, the target UE 201 or PA UE 202 (master entity or PA UE 202) may use pre-configured or provisioned configuration information for example, the SL-PRS positioning techniques, scenarios supported, selection criteria, or security. Other information used for discovery may include positioning mode (e.g., UE-based or UE-assisted) or positioning type (absolute or relative/ranging) supported or requested. Additionally, the PA UE 202 (relay function 205) may receive a separate discovery message for the SL Direct Communications discovery.
At step 273b, there may be Model B type direct discovery that may use two PA UE discovery protocol messages (e.g., solicitation and response). In the SL positioning context, the target UE 201 or PA UEs 202 use pre-configured or provisioned configuration information, for example, the SL-PRS positioning technique(s) and SL-PRS signal(s) supported, scenarios supported, selection criteria and security to aid in PA UE discovery. Other information used for discovery may include positioning mode (e.g., UE-based or UE-assisted) or positioning type (e.g., absolute or relative/ranging) supported or requested. In the SL positioning context, the PA UE 202 (e.g., relay function 205) may receive a separate discovery message for the SL Direct Communications discovery.
At step 273c, there may be SL-PRS Discovery/sensing. Discovery or PA UE “sensing” may involve the PA UE 202 transmitting broadcast posSIBs and System Information that may be leveraged by the target UE 201. Moreover, the PA UE 202 may transmit SL-SSB that may be inclusive of identification, discovery data that may also be used as part of the SL-PRS. The target UE 201 or PA UE 202 may leverage (pre) configuration to assist in discovery/sensing. In some cases, the target UE 201 may only need to receive SL-SSB from the PA UE 202 and perform measurements based on synchronization signals. Alternatively, the SL-SSB from the PA UE 202 may also enable acquisition of PBSCH to receive SL positioning configuration information or SL DMRS, which may also be leveraged by the target UE 201 for positioning measurements.
At step 274, the target UE 201 may select one or more of the authorized PA UE 202 that met the configured criteria to initiate positioning procedures, which may include measurements performed on SL-PRS(s) or measurements used for SL Direct Communication. The SL Relay Function 205 as disclosed in the previous procedures may or may not be present at the PA UEs 202. However, it may be envisioned that the selection of PA UEs 202 or reception of SL-PRS may involve the N/W, LMF, or Location server for in-coverage scenarios for SL positioning procedures and SL Direct Communication. Potentially, for partial coverage scenarios, the PA UE 202 may re-transmit broadcast posSIB or system information.
The target UE 201 selection of an authorized PA UE 202 may have separate selection criterion for SL positioning versus SL direct communication. The selection of a PA UE 202 on the basis of signal strength (RSRP) may not always be necessary for SL positioning.
At step 275, SL positioning or SL direct communication request may be sent from the target UE 201 to the PA UE(s) 202 with target UE 201 identifying information (e.g., layer-2 group ID). SL positioning request may include a request for SL-PRS transmission, request for SL-PRS configuration to assist in reception of PRS signals, request for capabilities, or the like. SL direct communications request may include request for unicast, broadcast, or multicast. A request may include a SL Positioning request and Direct Communications request. No request may be necessary if PA UE SL-PRS is detected with pre-configuration and sufficient QoS criteria is met, which may be determined by the target UE 201.
At step 276, security establishment between target UE 201 and PA UE(s) Relay Function 205. The discovery procedures may enable the positioning authorization and SL direct communication security establishment between the target UE 201 and the PA UE(s) 202. The NG-RAN and the LMF/Location Server may also be involved with authorization and security establishment.
Step 277 may be associated with SL Positioning response or SL Direct Communication response. The SL response message(s) may be sent from the PA UE(s) 202. The response message may include specific aspects of the request and approve, deny, or partially approve. In some methods, the SL Positioning and SL Direct Communications responses may have a relationship or dependencies on one another. For example, depending on configuration and UE capabilities/requirements, the response message may categorically approve or deny the request.
Steps 278-286 may be required if the SL request also includes a SL Direct Communication request. A direct communication request may be required if the target UE 201 requests SL-PRS reconfiguration or requires additional information (e.g., capabilities, resources, config) from the PA UE 202.
At step 278, if SL Direct Communication establishment is requested, the target UE 201 may send the first RRC message (e.g., RR (SetupRequest) for its connection establishment with NG-RAN via the PA relay function, using a default Layer-2 configuration on SL (PC5) [TS 38.836].
At step 279, the RRCSetup delivery to the target UE 201 may use the default configuration on SL (PC5). If the target UE 201 had not started in RRC_CONNECTED, it may do its own connection establishment upon reception of a message on the default L2 configuration on PC5.
At step 280, there may be a preparation of PC5 or Uu RLC channel for SRB1. The NG-RAN 207 (e.g., gNB or other base station) and PA UE relay function 205 may perform relaying channel setup procedure over Uu. The PA UE 202 or target UEs 201 may receive configuration from NG-RAN 207, and the PA (relay function 205) or target UE 201 may establish an RLC channel for relaying of SRB1 towards the Remote UE (e.g., target UE 201) over PC5. This step 280 may prepare the relaying channel for SRB1.
At step 281, a target UE SRB1 message (e.g., an RRCSetupComplete message) may be sent to the NG-RAN 207 via the PA (Relay function 205) using SRB1 relaying channel over PC5. Then the target UE 201 may be RRC connected over Uu.
At step 282, target UE 201 and NG-RAN 207 may establish security and the security messages (e.g., SecurityModeCommand) may be forwarded through the PA UE relay function 205.
At step 283, target UE 201 may send security mode complete message (e.g., SecurityModeComplete.) to the NG-RAN 207 via the PA UE relay function 205.
At step 284, the NG-RAN 207 may set up additional RLC channels between the NG-RAN 207 and PA UE relay function 205 for traffic relaying. According to the configuration from NG-RAN 207, the PA UE 202 or target UE 201 may set up additional RLC channels between the target UE 201 and PA UE relay function 205 for traffic relaying. The NG-RAN 207 may send an RRC Reconfiguration to the target UE 201 via the PA UE relay function 205, to set up the relaying SRB2/DRBs similar to procedures outlined in TR38.836.
At step 285, target UE 201 may send a message indicating completion (e.g., an RRCReconfigurationComplete) to the NG-RAN 207 via the PA UE relay function 205 as a response.
At step 286, there may be preparation of PC5 or Uu RLC channel for SRB2 via PA UE relay function 205. The NG-RAN 207 and PA UE relay function 205 may perform relaying channel setup procedure over Uu. The PA UEs 202 or target UEs 201 receive configuration from NG-RAN 207, and the PA relay function 205 or target UE 201 establish an RLC channel for relaying of SRB2 towards the target UE 201 over PC5. This step prepares the relaying channel for SRB2 to enable DL or UL information transfer.
At step 287, Selection of additional PA UE(s) 202 and reception of PRS with associated configuration in PC5-RRC Connected mode. Optionally, the selection of PA UE(s) 202 and reception of PRS may involve the Network, (NG-RAN), AMF, or LMF for partial and in-network cases.
The following procedures as depicted in
Note Steps 288-296 are LCS specific messages and procedures (e.g., LPP) and dependent upon the positioning mode and some possible pre-configuration. In this scenario, the master entity 203 is providing the SL positioning operations.
Step 288 is associated with LPP request capabilities. The PA UE 202 (master entity 203) via PA UE relay function 205 may send this NAS message (e.g., RRC DL Information Transfer) to the target UE 201. The LMF 206 may send this NAS message via the NG-RAN 207 via the master entity 203 or relay PA UE 202. The NAS message may be encapsulated in an RRC message that is sent over the SL via the PA UE relay function 205, and may forward the message to the target UE 201. NGAP DL NAS Transport: LPP PDU from the NG-RAN 207 to the LMF 206.
Step 289 is associated with LPP provide capabilities. The target UE 201 may send this NAS message (RRC UL Information Transfer) via PA UE relay function 205 to the PA UE 202 (master entity 205).
RRC UL Information Transfer-LPP PDU. The target UE 201 may send this NAS message to the LMF 206 via the PA UE 202 (Relay Function 205). The NAS message may be encapsulated in an RRC message that is sent over the SL from the target UE 201 via the PA UE 202 (UE-N/W Relay function 205), and the PA UE 202 (Relay Function 205) may forward the message to the LMF 206. NGAP UL NAS Transport-LPP PDU.
Step 290 is associated with LPP requesting assistance data. The target UE 201 may send this NAS message (RRC UL Information Transfer) via PA UE relay function 205 to the master entity 203, requesting assistance data for PA UE(s) 202. RRC UL Information Transfer-LPP PDU: the target UE 201 may send this NAS message to the LMF 206 via the PA UE 202 (Relay Function 205). The NAS message may be encapsulated in an RRC message that is sent over the SL from the target UE 201 via the PA UE 202 (UE-N/W Relay function 205), and the PA UE 202 (Relay Function 205) may forward the message to the LMF 206. NGAP UL NAS Transport-LPP PDU.
Step 291 may be associated with LPP providing assistance data. The PA UE 202 (master entity 203) via PA relay function may send this NAS message (RRC DL Information Transfer) to the target UE 201. RRC DL Information Transfer-LPP PDU: The LMF 206 may send this NAS message to the target UE 201 via the PA UE 202 (Relay Function 205). The NAS message is encapsulated in an RRC message that may send over the SL via the PA UE 202 (Relay function 205), and the PA UE 202 (Relay Function 205) may forward the message to the target UE 201. NGAP DL NAS Transport-LPP PDU.
Step 292 is associated with LPP requesting location information. The PA UE 202 (master entity 203) via PA UE relay function 205 may send this NAS message (RRC DL Information Transfer) to the target UE 201.
RRC DL Information Transfer-LPP PDU: The LMF 206 may send this NAS message to the target UE 201 via the PA UE 202 (Relay Function 205). The NAS message is encapsulated in an RRC message that is sent over the SL via the PA UE 202 (Relay function 205), and the PA UE 202 (Relay Function 205) forwards the message to the target UE 201. NGAP DL NAS Transport-LPP PDU.
Step 293 is associated with UE measurements and optionally measurement configuration of PA UE(s) 202 or NG-RAN 207. The target UE 201 may send an offset for timing measurements that include an adjustment for internal transmit and receive delays and not only absolute values.
Step 294 is associated with UE positioning calculation. The target UE 201 may perform positioning determination for UE-based mode of operation.
Step 295 is associated with LPP providing location information. The target UE 201 may send this NAS message (RRC UL Information Transfer) to the PA UE master entity 203 via PA UE relay function 205.
RRC UL Information Transfer-LPP PDU: The target UE 201 may send this NAS message to the LMF 206 via the PA UE 202 (Relay Function 205). The NAS message is encapsulated in an RRC message that is sent over the SL from the target UE 201 via the PA UE 202 (UE-N/W Relay function 205), and the PA UE 202 (Relay Function 205) forwards the message to the LMF 206. NGAP UL NAS Transport-LPP PDU.
Step 296 is associated with LMF 206 (e.g., location server) positioning calculation. Optionally, for UE-assisted SL Positioning operations whereby the network is performing the positioning calculation function of the target UE 201. In further embodiments, it may be envisioned that the master entity 203 may perform the positioning calculation function of the target UE 201.
In some examples, existing LCS protocols may be required to address SL only and SL+Uu positioning scenarios. Using TS 37.355 as a baseline, information elements for the LPP positioning operations previously defined may be updated as follows to account for SL and for PA UE(s) 202 that may serve some functions of a LMF 206 for configuration of target UEs 201. The following LPP message examples may be leveraged in some capacity for all potential coverage scenarios for target UE 201, e.g., in coverage, out of coverage, or partial coverage scenarios.
The RequestCapabilities message body (see Table 6) in a LPP message may be used by the location server or positioning assist UE to request the target device capability information for LPP and the supported individual positioning methods.
The ProvideCapabilities message body (see Table 7) in a LPP message may indicate the LPP capabilities of the target device to the location server or positioning assist UE.
The IE NR-SL-ProvideCapabilities-r18 defines the SL measurement capability (see Table 8 and Table 9). The target UE 201 may include this IE only if the UE supports SL Positioning for SL-TDOA, SL-RTT, or SL-AoD, etc. Otherwise, the UE does not include this IE.
The RequestAssistanceData message body in a LPP message may be used by the target device to request assistance data from the location server or positioning assist UE. See Table 10.
The Provide Assistance Data message body in a LPP message may be used by the location server or positioning assist UE to provide assistance data to the target device in response to a request from the target device or in an unsolicited manner. See Table 11 and Table 12.
Further assistance data specific for SL-PRS, TS 37.355 section 6.4.3 for DL-PRS is used as a baseline to enhance SL-PRS discovery, selection and hear-ability for the target UE 201. This would be configured for a PA UE 202 or a set of PA UEs 202, and analogous to a TRP(s) transmitting DL-PRS. NR-SL-PRS-AssistanceData is the response message to NR-SL-PRS-RequestAssistanceData. The NR-SL-PRS-RequestAssistanceData may include specific IEs specific to, e.g., absolute positioning, relative positioning, UE-based, assisted, scenario, etc.
The IE NR-SL-PRS-AssistanceData may be sent by the master (controlling) entity 203 (e.g., location server 206 or PA UE 202) to provide SL-PRS assistance data, which may include the geographical coordinates of the PA UE 202, SL-PRS resource information, etc. See Table 13 and Table 14.
Alternatively, these IEs may be broadcast from the PA UEs 202 or NG-RAN 207 within posSIBs. Furthermore, the target UE 201 requests of assistance data for SL-PRS (re) configuration, may be included in the procedure flows as previously discussed without Uu involvement. Note that in the examples, some of the ProvideAssistanceInformation is shown as part of the TDOA method, but similar IEs may be envisioned for other positioning methods that may leverage SL-PRS(s), such as RTT or AoA/AOD techniques.
The RequestLocationInformation message body in a LPP message may be used by the location server or positioning assist UE to request positioning measurements or a position estimate from the target device. See Table 15 and Table 16.
The ProvidelocationInformation message body in a LPP message may be used by the target device to provide positioning measurements or position estimates to the location server or positioning assist UE. See Table 17.
Further examples also may require the UE to assist the network in the position determination function. In these In- and partial-coverage scenarios (or out-of-coverage and a PA UE 202 is performing final positioning determination), SL measurements will need to be sent to the network over the Uu (for in-coverage) or over the SL (for partial coverage). The following examples show possible measurements reports.
The IE NR-SL-TDOA-SignalMeasurementInformation may be used by the target device to provide NR SL-TDOA measurements to the location server or to a master entity 203. See Table 18 and Table 19.
In addition to, or in lieu of, the target UE 201 may utilize additional measurements, such as, GNSS, LiDAR or Radar, or other signals of opportunity to determine its location. These measurements may also be sent in LPP-ProvideLocationInformation messages.
An alternative to SL-LPP-based approaches for instigating positioning signals as previously discussed may be via MAC CE/SDU. Based on TS 38.321 section 6.2.4, an example value for SL-SRS and SL-PRS resource activation or deactivation is given. Note that the contents of the MAC CE may contain an identifier to allow the UE to determine which of the SL-PRS resource sets to activate (or de-activate) for partial and in-coverage scenarios. From TS 38.321: LCID: The Logical Channel ID field identifies the logical channel instance of the corresponding MAC SDU or the type of the corresponding MAC CE within the scope of one Source Layer-2 ID and Destination Layer-2 ID pair or padding as described in Tables 6.2.4-1 for SL-SCH. There is one LCID field per MAC subheader except for SL-SCH subheader. The size of the LCID field is 6 bits. These indices may also be extended to additional SL positioning procedures that are supported by SL-LPP.
This activation or deactivation of SL SRS/PRS resources may also be triggered via RRC signaling.
In another scenario, the master entity 203 (e.g., network such as an LMF/Location Server 206 or PA UE 202), requests specific measurements with respect to SL positioning and ranging in addition to or in lieu of Uu positioning measurements or position determination. The following SL position request, using TS 37.355 section 6.5.10.5 as a baseline for DL-PRS techniques, are proposed for SL positioning and ranging.
The IE NR-SL-TDOA-RequestLocationInformation may be used by the master (controlling) entity 203 (e.g., location server 206 or PA UE 202) to request NR SL-TDOA location measurements from a target device. See Table 20 and Table 21.
In some examples, the UE (e.g., target UE 201) may request SL-PRS transmission (re) configuration based on criteria described herein. If allowed and the evaluation criteria has been met for the UE to send a request (and associated information with the request), this may be done via an existing LPP message with newly configured IEs. In one example, the LPP Request Assistance Data may include an IE for the UE to request an LMF or directly request to a PA UE 202 to (re) configure SL-PRS transmissions as shown here for TDOA techniques, but may be similarly updated for AoD, RTT, or the like using TS 37.355 section 6.5.10.2 as a baseline.
The IE NR-SL-TDOA-RequestAssistanceData may be used by the target device to request assistance data from a location server. See Table 22 and Table 23.
In other examples, the UE may require some measurements to determine or calculate the need for a request for modification by the network of the PRS transmissions for serving or neighboring cells. As part of the LPP Provide Location Information proposed IEs, the UE may also include general or specific requests for modifications of PRS transmissions as shown, in which TS 37.355 section 6.5.10.3 may be a baseline.
The IE NR-SL-TDOA-ProvideLocationInformation may be used by the target device to provide NR SL-TDOA location measurements to the location server (LMF) 206 or a PA UE 202. It may also be used to provide NR SL-TDOA positioning specific error reasons. See Table 24 and Table 25.
In response to the aforementioned Provide Location Information and associated SL-PRS transmission request, the PA UE 202 may respond with an LPP Provide Assistance Data to inform the UE of the change in PRS transmissions of one or more PRS resources and direct the UE to obtain new measurements. Alternately, denial of PRS request message with other fallback positioning methods or resources may be sent by the network. The network may toggle the sl-PRS-ConfigRqstAllowed for denial of SL-PRS (re) configuration request.
As mentioned, SL UEs, for example, a UE in a vehicle or an RSU may be equipped with a distributed antenna system (DAS). For example, multiple antennas or antenna array/panels at different locations may help to improve positioning sensitivity and geometrical/angular calculation enhancements. Some of the typical Uu-based positioning techniques, such as TDOA, may require multiple positioning “reference nodes” (e.g., gNBs, TRPs) that are necessary for accurate multi-lateration. This requirement may be mitigated or eliminated with DAS support on the PA UE 202 or target UE 201. Timing or angular deltas may enable accurate positioning with only one positioning “reference” node or PA UE 202.
Examples herein describe a method and system to configure and enable DAS measurements at a target UE 201 comprising location protocol messages that may support the procedures as shown in
In one example, the PA UEs 202 or network (e.g., NG-RAN 207 or LMF 206) dependent upon the interface(s) used for positioning procedures, may require initial configuration and capabilities exchange to determine whether or not DAS is supported. Additionally, measurement configurations, calibrations, and measurement reports may need to account for DAS. In further examples, the measurements from a plurality of antennas may be concatenated at the target UE 201, e.g., for a single reference point location of the target UE 201. If measurements are combined at the target UE 201, these also may need to be identified as such in the measurement reports as further described herein.
Firstly, for capabilities exchange, the target UE 201 may provide the network location entities (e.g., LMF 206, etc.) or PA UEs 202 with DAS support and configuration. In addition to the capabilities described previously, the location protocols may support some or more of the following or alternatively, the target UE 201 may provide or be identified as a class/type of UE that is equipped with DAS. Note that these capabilities may be signaled over the SL or the Uu interface, as it may also be beneficial to have DAS capabilities over both interfaces.
At step 302, there may be capabilities exchange between the target UE 201 and network or SL PA UEs 202 that include DAS support and type(s) of DAS.
At step 303, target UE 201 may request antenna configuration assistance data of PA UEs 202 to the network or PA UE 202.
At step 304, target UE 201 may receive antenna configuration assistance data of PA UEs from the network or PA UE.
At step 305, target UE measurement reports that encompass separate measurements for two or more antennae may be sent to the network or master entity 203.
The IE NR-SL-ProvideCapabilities-r18 may define the SL measurement capability. The target UE 201 or PA UE 202 may include this IE only if the UE supports SL Positioning for SL-TDOA, SL-RTT, for SL-AoD, etc. Otherwise, the UE may not include this IE. See Table 26 and Table 27.
In a further example, the positioning protocols may support methods to identify positioning measurements or report positioning measurements relative to DAS implementations. For these implementations, various antenna layouts or patterns (e.g., linear array, circular array, or 2D rectangular array) may be supported and measurement reports may be transmitted from the target UE 201 to PA UE 202 or the network (e.g., LMF 206). Alternatively, the PA UE 202 or the network may perform the SRS measurements. Depending on whether the DAS is equipped by the PA UE 202 or target UE 201, the antenna layouts or patterns may be indicated from the target UE 201 to PA UE 202 or the network or vice versa. As such, an example of the measurement reports may be exemplified as follows. See Table 28 and Table 29.
It is understood that the entities performing the steps illustrated herein, such as
Table 30 provides abbreviations and definitions, while Table 31 provides other terms and definitions.
The 3rd Generation Partnership Project (3GPP) develops technical standards for cellular telecommunications network technologies, including radio access, the core transport network, and service capabilities-including work on codecs, security, and quality of service. Recent radio access technology (RAT) standards include WCDMA (commonly referred as 3G), LTE (commonly referred as 4G), LTE-Advanced standards, and New Radio (NR), which is also referred to as “5G”. 3GPP NR standards development is expected to continue and include the definition of next generation radio access technology (new RAT), which is expected to include the provision of new flexible radio access below 7 GHz, and the provision of new ultra-mobile broadband radio access above 7 GHz. The flexible radio access is expected to include a new, non-backwards compatible radio access in new spectrum below 6 GHz, and it is expected to include different operating modes that may be multiplexed together in the same spectrum to address a broad set of 3GPP NR use cases with diverging requirements. The ultra-mobile broadband is expected to include cmWave and mm Wave spectrum that will provide the opportunity for ultra-mobile broadband access for, e.g., indoor applications and hotspots. In particular, the ultra-mobile broadband is expected to share a common design framework with the flexible radio access below 7 GHZ, with cmWave and mmWave specific design optimizations.
3GPP has identified a variety of use cases that NR is expected to support, resulting in a wide variety of user experience requirements for data rate, latency, and mobility. The use cases include the following general categories: enhanced mobile broadband (eMBB) ultra-reliable low-latency Communication (URLLC), Non-Terrestrial Networks (NTN), massive machine type communications (mMTC), network operation (e.g., network slicing, routing, migration and interworking, energy savings), and enhanced vehicle-to-everything (eV2X) communications, 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 communications with other entities. Specific service and applications in these categories include, e.g., monitoring and sensor networks, device remote controlling, bi-directional remote controlling, personal cloud computing, video streaming, wireless cloud-based office, first responder connectivity, automotive ecall, disaster alerts, real-time gaming, multi-person video calls, autonomous driving, augmented reality, tactile internet, virtual reality, home automation, robotics, and aerial drones to name a few. All of these use cases and others are contemplated herein.
It will be appreciated that the concepts disclosed herein may be used with any number of WTRUs, base stations, networks, or network elements. Each of the WTRUs 102a, 102b, 102c, 102d, 102e, 102f, or 102g may be any type of apparatus or device configured to operate or communicate in a wireless environment. Although each WTRU 102a, 102b, 102c, 102d, 102e, 102f, or 102g may be depicted in
The communications system 100 may also include a base station 114a and a base station 114b. In the example of
TRPs 119a, 119b may be any type of device configured to wirelessly interface with at least one of the WTRU 102d, to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 110, Network Services 113, or other networks 112. RSUs 120a and 120b may be any type of device configured to wirelessly interface with at least one of the WTRU 102e or 102f, to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 110, other networks 112, or Network Services 113. By way of example, the base stations 114a, 114b may be a Base Transceiver Station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a Next Generation Node-B (gNode B), a satellite, a site controller, an access point (AP), a wireless router, or the like.
The base station 114a may be part of the RAN 103/104/105, which may also include other base stations or network elements (not shown), such as a Base Station Controller (BSC), a Radio Network Controller (RNC), relay nodes, etc. Similarly, the base station 114b may be part of the RAN 103b/104b/105b, which may also include other base stations or network elements (not shown), such as a BSC, a RNC, relay nodes, etc. The base station 114a may be configured to transmit or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown). Similarly, the base station 114b may be configured to transmit or receive wired or wireless signals within a particular geographic region, which may be referred to as a cell (not shown) for methods, systems, and devices of NR SL Positioning, as disclosed herein. Similarly, the base station 114b may be configured to transmit or receive wired or wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in an example, the base station 114a may include three transceivers, e.g., one for each sector of the cell. In an example, the base station 114a may employ multiple-input multiple output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.
The base stations 114a may communicate with one or more of the WTRUs 102a, 102b, 102c, or 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, cmWave, mmWave, etc.). The air interface 115/116/117 may be established using any suitable radio access technology (RAT).
The base stations 114b may communicate with one or more of the RRHs 118a, 118b, TRPs 119a, 119b, or RSUs 120a, 120b, over a wired or air interface 115b/116b/117b, which may be any suitable wired (e.g., cable, optical fiber, etc.) or wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). The air interface 115b/116b/117b may be established using any suitable radio access technology (RAT).
The RRHs 118a, 118b, TRPs 119a, 119b or RSUs 120a, 120b, may communicate with one or more of the WTRUs 102c, 102d, 102e, 102f over an air interface 115c/116c/117c, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). The air interface 115c/116c/117c may be established using any suitable radio access technology (RAT).
The WTRUs 102a, 102b, 102c, 102d, 102e, or 102f may communicate with one another over an air interface 115d/116d/117d, such as Sidelink communication, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). The air interface 115d/116d/117d may be established using any suitable radio access technology (RAT).
The communications 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, the base station 114a in the RAN 103/104/105 and the WTRUs 102a, 102b, 102c, or RRHs 118a, 118b, TRPs 119a, 119b and RSUs 120a, 120b, in the RAN 103b/104b/105b and the WTRUs 102c, 102d, 102e, 102f, may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115/116/117 or 115c/116c/117c respectively using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink Packet Access (HSDPA) or High-Speed Uplink Packet Access (HSUPA).
In an example, the base station 114a and the WTRUs 102a, 102b, 102c, or RRHs 118a, 118b, TRPs 119a, 119b, or RSUs 120a, 120b in the RAN 103b/104b/105b and the WTRUs 102c, 102d, may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 115/116/117 or 115c/116c/117c respectively using Long Term Evolution (LTE) or LTE-Advanced (LTE-A). In the future, the air interface 115/116/117 or 115c/116c/117c may implement 3GPP NR technology. The LTE and LTE-A technology may include LTE D2D and V2X technologies and interfaces (such as Sidelink communications, etc.). Similarly, the 3GPP NR technology may include NR V2X technologies and interface (such as Sidelink communications, etc.).
The base station 114a in the RAN 103/104/105 and the WTRUs 102a, 102b, 102c, and 102g or RRHs 118a, 118b, TRPs 119a, 119b or RSUs 120a, 120b in the RAN 103b/104b/105b and the WTRUs 102c, 102d, 102e, 102f may implement radio technologies such as IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1×, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), or the like.
The base station 114c in
The RAN 103/104/105 or RAN 103b/104b/105b may be in communication with the core network 106/107/109, which may be any type of network configured to provide voice, data, messaging, authorization and authentication, applications, or voice over internet protocol (VOIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. For example, the core network 106/107/109 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, packet data network connectivity, Ethernet connectivity, video distribution, etc., or perform high-level security functions, such as user authentication.
Although not shown in
The core network 106/107/109 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d, 102e to access the PSTN 108, the Internet 110, or other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and the internet protocol (IP) in the TCP/IP internet protocol suite. The networks 112 may include wired or wireless communications networks owned or operated by other service providers. For example, the networks 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 the 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 communications 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 implementing methods, systems, and devices of NR SL Positioning, as disclosed herein. For example, the WTRU 102g shown in
Although not shown in
As shown in
The core network 106 shown in
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 circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, and 102c, and traditional land-line communications 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. The SGSN 148 may be connected to the GGSN 150. The SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, and 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between and the WTRUs 102a, 102b, and 102c, and IP-enabled devices.
The core network 106 may also be connected to the other networks 112, which may include other wired or wireless networks that are owned or operated by other service providers.
The RAN 104 may include eNode-Bs 160a, 160b, and 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs. 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 eNode-Bs 160a, 160b, and 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.
Each of the eNode-Bs 160a, 160b, and 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink or downlink, or the like. As shown in
The core network 107 shown in
The MME 162 may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via an SI interface and may serve 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 an initial attach of the WTRUs 102a, 102b, and 102c, or the like. The MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.
The serving gateway 164 may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via the SI interface. The serving gateway 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, and 102c. The serving gateway 164 may also perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, and 102c, managing and storing contexts of the WTRUs 102a, 102b, and 102c, or the like.
The serving gateway 164 may also be connected to the PDN gateway 166, which may provide the WTRUs 102a, 102b, and 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c, and IP-enabled devices.
The core network 107 may facilitate communications with other networks. For example, the core network 107 may provide the WTRUs 102a, 102b, and 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, and 102c and traditional land-line communications 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 networks 112, which may include other wired or wireless networks that are owned or operated by other service providers.
The RAN 105 may include gNode-Bs 180a and 180b. It will be appreciated that the RAN 105 may include any number of gNode-Bs. The gNode-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 integrated access and backhaul connection are used, the same air interface may be used between the WTRUs and gNode-Bs, which may be the core network 109 via one or multiple gNBs. The gNode-Bs 180a and 180b may implement MIMO, MU-MIMO, or digital beamforming technology. Thus, the gNode-B 180a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a. It should be appreciated that the RAN 105 may employ of other types of base stations such as an eNode-B. It will also be appreciated the RAN 105 may employ more than one type of base station. For example, the RAN may employ eNode-Bs and gNode-Bs.
The N3IWF 199 may include a non-3GPP Access Point 180c. It will be appreciated that the N3IWF 199 may include any number of non-3GPP Access Points. The non-3GPP Access Point 180c may include one or more transceivers for communicating with the WTRUs 102c over the air interface 198. The non-3GPP Access Point 180c may use the 802.11 protocol to communicate with the WTRU 102c over the air interface 198.
Each of the gNode-Bs 180a and 180b may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink or downlink, or the like. As shown in
The core network 109 shown in
In the example of
In the example of
The AMF 172 may be connected to the RAN 105 via an N2 interface and may serve as a control node. For example, the AMF 172 may be responsible for registration management, connection management, reachability management, access authentication, access authorization. The AMF may be responsible forwarding user plane tunnel configuration information to the RAN 105 via the N2 interface. The AMF 172 may receive the user plane tunnel configuration information from the SMF via an N11 interface. The AMF 172 may generally route and forward NAS packets to/from the WTRUs 102a, 102b, and 102c via an N1 interface. The N1 interface is not shown in
The SMF 174 may be connected to the AMF 172 via an N11 interface.
Similarly the SMF may be connected to the PCF 184 via an N7 interface, and to the UPFs 176a and 176b via an N4 interface. The SMF 174 may serve as a control node. For example, the SMF 174 may be responsible for Session Management, IP address allocation for the WTRUs 102a, 102b, and 102c, management and configuration of traffic steering rules in the UPF 176a and UPF 176b, and generation of downlink data notifications to the AMF 172.
The UPF 176a and UPF 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 UPF 176a and UPF 176b may also provide the WTRUs 102a, 102b, and 102c with access to other types of packet data networks. For example, Other Networks 112 may be Ethernet Networks or any type of network that exchanges packets of data. The UPF 176a and UPF 176b may receive traffic steering rules from the SMF 174 via the N4 interface. The UPF 176a and UPF 176b may provide access to a packet data network by connecting a packet data network with an N6 interface or by connecting to each other and to other UPFs via an N9 interface. In addition to providing access to packet data networks, the UPF 176 may be responsible packet routing and forwarding, policy rule enforcement, quality of service handling for user plane traffic, downlink packet buffering.
The AMF 172 may also be connected to the N3IWF 199, for example, via an N2 interface. The N3IWF facilitates a connection between the WTRU 102c and the 5G core network 170, for example, via radio interface technologies that are not defined by 3GPP. The AMF may interact with the N3IWF 199 in the same, or similar, manner that it interacts with the RAN 105.
The PCF 184 may be connected to the SMF 174 via an N7 interface, connected to the AMF 172 via an N15 interface, and to an Application Function (AF) 188 via an N5 interface. The N15 and N5 interfaces are not shown in
The UDR 178 may act as a repository for authentication credentials and subscription information. The UDR may connect with network functions, so that network function can add to, read from, and modify the data that is in the repository. For example, the UDR 178 may connect with the PCF 184 via an N36 interface. Similarly, the UDR 178 may connect with the NEF 196 via an N37 interface, and the UDR 178 may connect with the 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 authorize network functions to access of the UDR 178. For example, the UDM 197 may connect with the AMF 172 via an N8 interface, the UDM 197 may connect with the SMF 174 via an N10 interface. Similarly, the UDM 197 may connect with the AUSF 190 via an N13 interface. The UDR 178 and UDM 197 may be tightly integrated.
The AUSF 190 performs authentication related operations and connect with the UDM 178 via an N13 interface and to the AMF 172 via an N12 interface.
The NEF 196 exposes capabilities and services in the 5G core network 109 to Application Functions (AF) 188. Exposure may occur on the N33 API interface. The NEF may connect with an AF 188 via an N33 interface and it may connect with other network functions in order to expose the capabilities and services of the 5G core network 109.
Application Functions 188 may interact with network functions in the 5G Core Network 109. Interaction between the Application Functions 188 and network functions may be 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 external to the 5G Core Network 109 and deployed by enterprises that have a business relationship with the mobile network operator.
Network Slicing is a mechanism that may be used by mobile network operators to 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 the operator to create networks customized to provide optimized solutions for different market scenarios which demands diverse requirements, e.g., in the areas of functionality, performance and isolation.
3GPP has designed the 5G core network to support Network Slicing Network Slicing is a good tool that network operators can use to support the diverse set of 5G use cases (e.g., massive IoT, critical communications, V2X, and enhanced mobile broadband) which demand very diverse and sometimes extreme requirements. Without the use of network slicing techniques, it is likely that the network architecture would not be flexible and scalable enough to efficiently support a wider range of use cases need when each use case has its own specific set of performance, scalability, and availability requirements. Furthermore, introduction of new network services should be made more efficient.
Referring again to
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 a PSTN 108. For example, the core network 109 may include, or communicate with a short message service (SMS) service center that facilities communication via the short message service. For example, the 5G core network 109 may facilitate the exchange of non-IP data packets between the WTRUs 102a, 102b, and 102c and servers or applications functions 188. In addition, the core network 170 may provide the WTRUs 102a, 102b, and 102c with access to the networks 112, which may include other wired or wireless networks that are owned or operated by other service providers.
The core network entities described herein and illustrated in
WTRUS A, B, C, D, E, and F may communicate with each other over a Uu interface 129 via the gNB 121 if they are within the access network coverage 131. In the example of
WTRUs A, B, C, D, E, and F may communicate with RSU 123a or 123b via a Vehicle-to-Network (V2N) 133 or Sidelink interface 125b. WTRUs A, B, C, D, E, and F may communicate to a V2X Server 124 via a Vehicle-to-Infrastructure (V2I) interface 127. WTRUs A, B, C, D, E, and F may communicate to another UE via a Vehicle-to-Person (V2P) interface 128.
The processor 78 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 Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, or the like. The processor 78 may perform signal coding, data processing, power control, input/output processing, or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 78 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While FIG. 22F depicts the processor 78 and the transceiver 120 as separate components, it will be appreciated that the processor 78 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., the base station 114a of
In addition, although the transmit/receive element 122 is depicted in
The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are 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, for example NR and IEEE 802.11 or NR and E-UTRA, or to communicate with the same RAT via multiple beams to different RRHs, TRPs, RSUs, or nodes.
The processor 78 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 74, the keypad 126, or the display/touchpad/indicators 77 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit. The processor 78 may also output user data to the speaker/microphone 74, the keypad 126, or the display/touchpad/indicators 77. In addition, the processor 78 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 or the removable memory 132. The non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, or the like. The processor 78 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server that is hosted in the cloud or in an edge computing platform or in a home computer (not shown). The processor 78 may be configured to control lighting patterns, images, or colors on the display or indicators 77 in response to whether the setup of the NR SL Positioning in some of the examples described herein are successful or unsuccessful, or otherwise indicate a status of NR SL Positioning and associated components. The control lighting patterns, images, or colors on the display or indicators 77 may be reflective of the status of any of the method flows or components in the FIG.'s illustrated or discussed herein (e.g.,
The processor 78 may receive power from the power source 134 and may be configured to distribute or control the power to the 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, or the like.
The processor 78 may also be coupled to the 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, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 115/116/117 from a base station (e.g., base stations 114a, 114b) or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method.
The processor 78 may further be coupled to other peripherals 138, which may include one or more software or hardware modules that provide additional features, functionality, or wired or wireless connectivity. For example, the peripherals 138 may include various sensors such as an accelerometer, biometrics (e.g., finger print) sensors, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port or other interconnect interfaces, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, or the like.
The WTRU 102 may be included in other apparatus or devices, such as a sensor, consumer electronics, a wearable device such as a smart watch or smart clothing, a medical or eHealth device, a robot, industrial equipment, a drone, a vehicle such as a car, truck, train, or an airplane. The WTRU 102 may connect with other components, modules, or systems of such apparatus or devices via one or more interconnect interfaces, such as an interconnect interface that may comprise one of the peripherals 138.
In operation, processor 91 fetches, decodes, and executes instructions, and transfers information to and from other resources via the computing system's main data-transfer path, system bus 80. Such a system bus connects the components in computing system 90 and defines the medium for data exchange. System bus 80 typically may include data lines for sending data, address lines for sending addresses, and control lines for sending interrupts and for operating the system bus. An example of such a system bus 80 is the PCI (Peripheral Component Interconnect) bus.
Memories coupled to system bus 80 include random access memory (RAM) 82 and read only memory (ROM) 93. Such memories include circuitry that allows information to be stored and retrieved. ROMs 93 generally include stored data that cannot easily be modified. Data stored in RAM 82 may be read or changed by processor 91 or other hardware devices. Access to RAM 82 or ROM 93 may be controlled by memory controller 92. Memory controller 92 may provide an address translation function that translates virtual addresses into physical addresses as instructions are executed. Memory controller 92 may also provide a memory protection function that isolates processes within the system and isolates system processes from user processes. Thus, a program running in a first mode may access only memory mapped by its own process virtual address space; it cannot access memory within another process's virtual address space unless memory sharing between the processes has been set up.
In addition, computing system 90 may include peripherals controller 83 responsible for communicating instructions from processor 91 to peripherals, such as printer 94, keyboard 84, mouse 95, and disk drive 85.
Display 86, which is controlled by display controller 96, is used to display visual output generated by computing system 90. Such visual output may include text, graphics, animated graphics, and video. The visual output may be provided in the form of a graphical user interface (GUI). Display 86 may be implemented with a CRT-based video display, an LCD-based flat-panel display, gas plasma-based flat-panel display, or a touch-panel. Display controller 96 may include electronic components required to generate a video signal that is sent to display 86.
Further, computing system 90 may include communication circuitry, such as for example a wireless or wired network adapter 97, that may be used to connect computing system 90 to an external communications network or devices, such as the RAN 103/104/105, Core Network 106/107/109, PSTN 108, Internet 110, WTRUs 102, or Other Networks 112 of
It is 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 instructions, when executed by a processor, such as processors 78 or 91, cause the processor to perform or implement the systems, methods and processes described herein. Specifically, any of the steps, operations, or functions described herein may be implemented in the form of such computer executable instructions, executing on the processor of an apparatus or computing system configured for wireless or wired network communications. Computer readable storage media may 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 include, but are 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 may be used to store the desired information and which may be accessed by a computing system.
In describing preferred methods, systems, or apparatus of the subject matter of the present disclosure—NR SL Positioning—as illustrated in the Figures, specific terminology is employed for the sake of clarity. The claimed subject matter, however, is not intended to be limited to the specific terminology so selected.
The various techniques described herein may be implemented in connection with hardware, firmware, software or, where appropriate, combinations thereof. Such hardware, firmware, and software may reside in apparatus located at various nodes of a communication network. The apparatus may operate singly or in combination with each other to effectuate the methods described herein. As used herein, the terms “apparatus,” “network apparatus,” “node,” “device,” “network node,” or the like may be used interchangeably. In addition, the use of the word “or” is generally used inclusively unless otherwise provided herein. For example, NG-RAN or PA UE is interpreted as NG-RAN, PA UE, or PA UE and NG-RAN.
This written description may use examples for the disclosed subject matter, including the best mode, and also to enable any person skilled in the art to practice the disclosed subject matter, including making and using any devices or systems and performing any incorporated methods. The disclosed subject matter may include other examples that occur to those skilled in the art (e.g., skipping steps, combining steps, or adding steps between exemplary methods disclosed herein).
Methods, systems, and apparatus, among other things, as described herein may provide for discovering or communicating SL positioning. A method, system, computer readable storage medium, or apparatus may be configured to authorize and provision positioning service; authorize and provision SL target and PA UE discovery; trigger for location services request; discover and select PA UE; establish SL direct communications/PC5; and perform LCS procedures. The LCS procedures may include SL-PRS configuration or measurements. All combinations in this paragraph and the below paragraphs (including the removal or addition of steps) are contemplated in a manner that is consistent with the other portions of the detailed description.
Disclosed herein are the following methods and systems. Methods or system for target UE discovery, selection, and assistance of SL UEs and SL ranging/positioning configuration without Uu involvement. Methods or system for target UE discovery, selection, and assistance of SL UEs aided by the network (gNB, LMF, Uu involvement) to determine SL configuration and appropriate SL-PRS/SRS resource allocation. Methods or system for target UE discovery, selection, and assistance of SL UEs with and without instigating SL Direct Communications (PC5-RRC link) to the base station (e.g., gNB) Methods or system for Uu and SL procedure enhancements to support ranging and positioning for UEs and positioning assist entities equipped with a Distributed Antenna System (DAS).
Methods, systems, and apparatus, among other things, as described herein may provide for receiving sidelink (SL) positioning configuration information, wherein the SL positioning configuration information comprises an indication of whether the UE may use relative positioning or absolute positioning; and based on the SL positioning configuration information, performing a positioning task that comprises sending an indication of a use of relative positioning between the UE and a positioning assist (PA) UE or the UE and a controlling entity (CE). SL positioning configuration information may include SL positioning reference signal (PRS) type, PRS resources (SL, Uu), indication of whether the position is emergency positioning, QoS or KPI profile (e.g., threshold requirements) of the positioning, indication of authorization to perform SL in-coverage discovery or SL out-of-coverage discovery of a positioning assist (PA-UE) UE or a controlling entity (CE), one or more positioning service identifiers, one or more triggers for discovery of a PA-UE or a CE, one or more thresholds for the selection of one or more PA-UE, one or more thresholds for the selection of a CE, or positioning capability, among other things.
Methods, systems, and apparatuses, among other things, as described herein may be configured to receive, from a sidelink (SL) positioning controlling entity, sidelink positioning configuration; based on the received configuration, being triggered to perform a positioning task, and perform the positioning task, the performing of the positioning task comprises at least one of the tasks disclosed herein. A task may be associated with sending indication of a use of relative positioning between the UE and a positioning assist (PA) UE or the UE and a controlling entity (CE), positioning mode (UE-based, UE-assisted), SL positioning algorithm, positioning security parameters, or the following tasks. In addition, or alternative to, the tasks may include: discovery of CE, discovery of PA-UE, selection of CE; selection of PA-UE; reception of the position of a PA-UE, a CE or a reference UE; measurement of SL PRS, Uu PRS; calculation of the UE absolute position; calculation of the UE relative position; or report of SL PRS measurements or Uu PRS measurement to a PA UE or a CE. Other tasks may include positioning capability negotiation between the UE and the PA-UE, between the UE and the CE or between the UE and a reference UE, wherein the capability may include one or more of supported positioning type (e.g., absolute position, relative position), positioning algorithms, SL PRS types, or positioning mode (e.g., UE-based, UE-assisted). The SL positioning configuration information may include indication of whether the positioning is relative or absolute positioning, positioning mode (UE-based, UE-assisted), SL positioning algorithm, positioning security parameters, or the like. The target device may be the device for which an absolute position or a relative position is to be calculated. The device that executes the methods herein may be a positioning assist device or a positioning controlling device.
Methods, systems, and apparatuses, among other things, as described herein may provide for receiving sidelink (SL) positioning configuration information, wherein the SL positioning configuration information comprises: an indication of whether a user equipment (UE) may use relative positioning or absolute positioning, or an indication of a positioning quality of service (QOS) requirement associated with the UE; based on the SL positioning configuration information, performing a positioning task that comprises: sending an indication of use of relative positioning between the UE and a positioning assist UE, sending an indication of use of relative positioning between the UE and a controlling entity, or sending an indication that the UE meets the positioning QoS requirement, and sending a request for SL positioning to a positioning assist UE.
This application claims the benefit of U.S. Provisional Patent Application No. 63/271,435, filed on Oct. 25, 2021, entitled “Methods and Systems For NR SL Positioning,” the contents of which are hereby incorporated by reference herein.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/US2022/078649 | 10/25/2022 | WO |
| Number | Date | Country | |
|---|---|---|---|
| 63271435 | Oct 2021 | US |
