Sidelink (SL) positioning WTRU authorization and privacy enhancement

Abstract

A sidelink positioning key management function (SLPKMF) may receive a discovery request, for example from a WTRU. The discovery request may include an indication of a WTRU role requested for performing an operation related to SL communications. The SLPKMF may determine a WTRU SL location policy and / or a user location privacy profile associated with the WTRU. The SLPKMF may determine that the WTRU role requested is authorized. For example, The SLPKMF may determine, based on the WTRU SL location policy and / or the user location privacy profile, that the WTRU role requested is authorized. The SLPKMF may determine that the WTRU role requested is not authorized, for example based on the WTRU SL location policy and / or the user location privacy profile. The SLPKMF may assign the WTRU role, for example if the SLPKMF may determines that the WTRU role requested is authorized.

Description

SIDELINK (SL) POSITIONING WTRU AUTHORIZATION AND PRIVACY ENHANCEMENTCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of United States Provisional Application No. 63 / 553,909 filed on February 15, 2024, the entire contents of which are incorporated herein by reference.BACKGROUND

[0002] Integrated sensing for enhancement of wireless systems may provide service (e.g. sensing service or SL positioning service) addressing different target verticals / applications (e.g., autonomous / assisted driving, V2X, UAVs, 3D map, smart city, smart home, factories, healthcare, maritime sector, etc.).

[0003] For integrated sensing, there may be a process of collecting sensing measurement data which is data collected about radio / wireless signals impacted (e.g., reflected, refracted, diffracted) by an object or environment of interest for sensing purposes and derive sensing results from processing sensing measurement data. And there may be an area defined for sensing, so called sensing service area location, which is an area location whether with or without obstacle, the wireless system may provide sensing service with certain quality.SUMMARY

[0004] A sidelink (SL) positioning key management function (SLPKMF) may receive a discovery request. The discovery request may include an indication of a WTRU role requested. The SLPKMF may send a request for a wireless transmit / receive unit (WTRU) policy control and receive a response. The request for a WTRU SL location policy control may include a WTRU ID and the response may include a WTRU SL location policy. The SLPKMF may send a data repository query request and receive a response. The data repository query request may include a WTRU ID. The SLPKMF may further determine the WTRU role requested and policy need based on the WTRU SL location policy and a user location privacy profile from unified data management (UDM). SLPKMF may also send a discovery response and receive update information.

[0005] In an example, the discovery response may include role assigned, authorization token, or authorization scope, or a privacy control list. The authorization update may include the role assigned, the authorization token, the authorization scope, or the privacy control list.

[0006] In another example, the data repository query response may include a location privacy profile or a user consent condition.

[0007] In one embodiment, upon determining that the WTRU role requested is authorized, the SLPKMF may assign the WTRU role requested to the WTRU along with a privacy control list.

[0008] The SLPKMF may receive a discovery request, for example from a WTRU. The discovery request may include an indication of a WTRU role requested for performing an operation related to SL communications. The SLPKMF may determine a WTRU SL location policy and / or a user location privacy profile associated with the WTRU. The SLPKMF may determine that the WTRU role requested is authorized. For example, The SLPKMF may determine, based on the WTRU SL location policy and / or the user location privacy profile, that the WTRU role requested is authorized. The SLPKMF may determine that the WTRU role requested is not authorized, for example based on the WTRU SL location policy and / or the user location privacy profile. The SLPKMF may assign the WTRU role, for example if the SLPKMF may determines that the WTRU role requested is authorized.

[0009] The SLPKMF may generate a privacy control list. The privacy control list may be configured to control privacy between at least two WTRUs, for example the at least two WTRUs having different roles when performing an operation related to SL communications. The SLPKMF may send a discovery response to the WTRU. The discovery response may include an indication of authorization of the WTRU role requested for performing the operation related to SL communications. The discovery request may include one or more of a time for role authorization, a location, an area, a duration, and / or a starting time. The SLPKMF may receive policy information from a policy control function (PCF). The SLPKMF may determine the WTRU SL location policy and / or user location policy profile based on the policy information.

[0010] The SLPKMF may send a request message, for example to a user data repository (UDR) entity. The request may include an indication of an identifier (ID) of the WTRU. The SLPKMF may receive a response message, for example from the UDR entity. The response message may include an indication of the user location privacy profile. The SLPKMF may receive the user location privacy profile, for example from a unified data management (UDM) entity. The privacy control list may include one or more of a first list of one or more first WTRUs authorized for the operation related to SL communications and / or a second list of one or more second WTRUs not authorized for the operation related to SL communications.

[0011] The WTRU may include a first WTRU and / or the discovery request may include a first discovery request. A second WTRU may be included in the first list of the one or more first WTRUs authorized for the operation related to SL communications. The SLPKMF may, for example based on the second WTRUbeing in the first list of the one or more first WTRUs authorized for the operation related to SL communications, receive a second discovery request from the second WTRU. The second discovery request may include a second WTRU role requested for performing an operation related to SL communications.

[0012] The privacy control list may additionally, or alternatively include an indication of one or more of WTRU group identifier (ID), a range of WTRUs, and / or WTRUs associated with a network. The SLPKMF may receive update information, for example from a policy control function (PCF). The SLPKMF may determine, for example based on the update information, that the WTRU role requested is authorized. The SLPKMF may send an update response, for example to the WTRU. The update response may include an indication of authorization of the WTRU role requested for performing the operation related to SL communications.BRIEF DESCRIPTION OF THE DRAWINGS

[0013] FIG. 1A is a system diagram illustrating an example communications system in which one or more disclosed embodiments may be implemented.

[0014] FIG. 1 B is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A according to an embodiment.

[0015] FIG. 1C is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communications system illustrated in FIG. 1 A according to an embodiment.

[0016] FIG. 1 D is a system diagram illustrating a further example RAN and a further example CN that may be used within the communications system illustrated in FIG. 1 A according to an embodiment.

[0017] FIG. 2 is an example network architecture.

[0018] FIG. 3 is an example diagram of pedestrian / animal intrusion detection.

[0019] FIG. 4 is an example diagram of intruder detection in surroundings of a smart home.

[0020] FIG. 5 is a diagram illustrating an example base station and WTRU with object detection.

[0021] FIG. 6 illustrates an example of a SL role assignment procedure.

[0022] FIG. 7 illustrates an example process of peer WTRU authorization and role negotiation during discovery.

[0023] FIG. 8 illustrates an example process of SL position WTRU role negotiation and role authorization after discovery.DETAILED DESCRIPTION

[0024] FIG. 1A is a diagram illustrating an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail unique-word DFT-Spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank multicarrier (FBMC), and the like.

[0025] As shown in FIG. 1A, the communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a RAN 104 / 113, a CN 106 / 115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a “station” and / or a “ST A”, may be configured to transmit and / or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and / or other wireless devices operating in an industrial and / or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and / or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c and 102d may be interchangeably referred to as a WTRU.

[0026] The communications systems 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106 / 115, the I nternet 110, and / or the other networks 112. 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 gNB, a NR NodeB, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0027] The base station 114a may be part of the RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and / or the base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for a wireless service to a specific geographical area that may be relatively fixed or that may change over time. 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 one embodiment, the base station 114a may include three transceivers, i.e., one for each sector of the cell. In an embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in desired spatial directions.

[0028] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

[0029] More specifically, as noted above, 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, and the like. For example, the base station 114a in the RAN 104 / 113 and the WTRUs 102a, 102b, 102c 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 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink (DL) Packet Access (HSDPA) and / or High-Speed UL Packet Access (HSUPA).

[0030] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the airinterface 116 using Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-Advanced Pro (LTE-A Pro).

[0031] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR Radio Access , which may establish the air interface 116 using New Radio (NR).

[0032] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, for instance using dual connectivity (DC) principles. Thus, the air interface utilized by WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., a eNB and a gNB).

[0033] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, 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), and the like.

[0034] The base station 114b in FIG. 1 A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a roadway, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR etc.) to establish a picocell or femtocell. As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the CN 106 / 115.

[0035] The RAN 104 / 113 may be in communication with the CN 106 / 115, which may be any type of network configured to provide voice, data, applications, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have varying quality of service (QoS)requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106 / 115 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although not shown in FIG. 1A, it will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which may be utilizing a NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0036] The CN 106 / 115 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or the 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 / or the internet protocol (IP) in the TCP / IP internet protocol suite. The networks 112 may include wired and / or wireless communications networks owned and / or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 / 113 or a different RAT.

[0037] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links). For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0038] FIG. 1 B is a system diagram illustrating an example WTRU 102. As shown in FIG. 1 B, the WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138, among others. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0039] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. While FIG. 1B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0040] The transmit / receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 116. For example, in one embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In an embodiment, the transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit / receive element 122 may be configured to transmit and / or receive both RF and light signals. It will be appreciated that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0041] Although the transmit / receive element 122 is depicted in FIG. 1 B as a single element, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.

[0042] 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, such as NR and IEEE 802.11 , for example.

[0043] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 may also outputuser data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and / 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, and the like. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0044] The processor 118 may receive power from the power source 134, and may be configured to distribute and / 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 (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

[0045] The processor 118 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 116 from a base station (e.g., base stations 114a, 114b) and / 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 locationdetermination method while remaining consistent with an embodiment.

[0046] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs and / or video), a universal serial bus (USB) port, 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, a Virtual Reality and / or Augmented Reality (VR / AR) device, an activity tracker, and the like. The peripherals 138 may include one or more sensors, the sensors may be one or more of a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor; an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

[0047] The WTRU 102 may include a full duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for both the UL (e.g., for transmission) and downlink (e.g., for reception) may be concurrent and / or simultaneous. The full duplex radio may include an interference management unit 139 to reduce and or substantially eliminate self-interference via either hardware (e.g., a choke) or signal processing via a processor (e.g., a separate processor (not shown) or via processor 118). In an embodiment, the WRTU 102 may include a half-duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for either the UL (e.g., for transmission) or the downlink (e.g., for reception)).

[0048] FIG. 1C is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0049] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and / or receive wireless signals from, the WTRU 102a.

[0050] Each of the eNode-Bs 160a, 160b, 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 UL and / or DL, and the like. As shown in FIG. 1 C, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.

[0051] The CN 106 shown in FIG. 1 C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. While each of the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0052] The MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 mayprovide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

[0053] The SGW 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via the S1 interface. The SGW 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions, such as anchoring user planes during inter- eNode B handovers, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

[0054] The SGW 164 may be connected to the PGW 166, which may provide the WTRUs 102a, 102b, 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.

[0055] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and / or wireless networks that are owned and / or operated by other service providers.

[0056] Although the WTRU is described in FIGS. 1 A-1 D as a wireless terminal, it is contemplated that in certain representative embodiments that such a terminal may use (e.g., temporarily or permanently) wired communication interfaces with the communication network.

[0057] In representative embodiments, the other network 112 may be a WLAN.

[0058] A WLAN in Infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have an access or an interface to a Distribution System (DS) or another type of wired / wireless network that carries traffic in to and / or out of the BSS. Traffic to STAs that originates from outside the BSS may arrive through the AP and may be delivered to the STAs. Traffic originating from STAs to destinations outside the BSS may be sent to the AP to be delivered to respective destinations. Traffic between STAs within the BSS may be sent through the AP, for example, where the source STA may send traffic to the AP and the AP may deliver the traffic to the destination STA. The traffic between STAs within a BSS may be considered and / or referred to as peer-to- peer traffic. The peer-to-peer traffic may be sent between (e.g., directly between) the source anddestination STAs with a direct link setup (DLS). In certain representative embodiments, the DLS may use an 802.11 e DLS or an 802.11 z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and the STAs (e.g., all of the STAs) within or using the IBSS may communicate directly with each other. The IBSS mode of communication may sometimes be referred to herein as an “ad- hoc” mode of communication.

[0059] When using the 802.11 ac infrastructure mode of operation or a similar mode of operations, the AP may transmit a beacon on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width via signaling. The primary channel may be the operating channel of the BSS and may be used by the STAs to establish a connection with the AP. In certain representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) may be implemented, for example in in 802.11 systems. For CSMA / CA, the STAs (e.g., every ST A), including the AP, may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular ST A, the particular STA may back off. One STA may transmit at any given time in a given BSS.

[0060] High Throughput (HT) STAs may use a 40 MHz wide channel for communication, for example, via a combination of the primary 20 MHz channel with an adjacent or nonadjacent 20 MHz channel to form a 40 MHz wide channel.

[0061] Very High Throughput (VHT) STAs may support 20MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. The 40 MHz, and / or 80 MHz, channels may be formed by combining contiguous 20 MHz channels. A 160 MHz channel may be formed by combining 8 contiguous 20 MHz channels, or by combining two non-contiguous 80 MHz channels, which may be referred to as an 80+80 configuration. For the 80+80 configuration, the data, after channel encoding, may be passed through a segment parser that may divide the data into two streams. Inverse Fast Fourier Transform (IFFT) processing, and time domain processing, may be done on each stream separately. The streams may be mapped on to the two 80 MHz channels, and the data may be transmitted by a transmitting STA. At the receiver of the receiving STA, the above described operation for the 80+80 configuration may be reversed, and the combined data may be sent to the Medium Access Control (MAC).

[0062] Sub 1 GHz modes of operation are supported by 802.11 af and 802.11 ah. The channel operating bandwidths, and carriers, are reduced in 802.11 af and 802.11 ah relative to those used in 802.11 n, and 802.11ac. 802.11 af supports 5 MHz, 10 MHz and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11 ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWSspectrum. According to a representative embodiment, 802.11 ah may support Meter Type Control / Machine- Type Communications, such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, for example, limited capabilities including support for certain and / or limited bandwidths. The MTC devices may include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[0063] WLAN systems, which may support multiple channels, and channel bandwidths, such as 802.11 n, 802.11 ac, 802.11 af, and 802.11 ah, include a channel which may be designated as the primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by a STA, from among all STAs in operating in a BSS, which supports the smallest bandwidth operating mode. In the example of 802.11 ah, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support a 1 MHz mode, even if the AP, and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Allocation Vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (which supports a 1 MHz operating mode), transmitting to the AP, the entire available frequency bands may be considered busy even though a majority of the frequency bands remains idle and may be available.

[0064] In the United States, the available frequency bands, which may be used by 802.11 ah, are from 902 MHz to 928 MHz. In Korea, the available frequency bands are from 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are from 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.11 ah is 6 MHz to 26 MHz depending on the country code.

[0065] FIG. 1 D is a system diagram illustrating the RAN 113 and the CN 115 according to an embodiment. As noted above, the RAN 113 may employ an NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 may also be in communication with the CN 115.

[0066] The RAN 113 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 113 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, gNBs 180a, 108b may utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a, for example, may use multiple antennas totransmit wireless signals to, and / or receive wireless signals from, the WTRU 102a. In an embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum while the remaining component carriers may be on licensed spectrum. In an embodiment, the gNBs 180a, 180b, 180c may implement Coordinated Multi-Point (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

[0067] The WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using transmissions associated with a scalable numerology. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using subframe or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing varying number of OFDM symbols and / or lasting varying lengths of absolute time).

[0068] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c without also accessing other RANs (e.g., such as eNode-Bs 160a, 160b, 160c). In the standalone configuration, WTRUs 102a, 102b, 102c may utilize one or more of gNBs 180a, 180b, 180c as a mobility anchor point. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration WTRUs 102a, 102b, 102c may communicate with / connect to gNBs 180a, 180b, 180c while also communicating with / connecting to another RAN such as eNode-Bs 160a, 160b, 160c. For example, WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In the non-standalone configuration, eNode-Bs 160a, 160b, 160c may serve as a mobility anchor for WTRUs 102a, 102b, 102c and gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for servicing WTRUs 102a, 102b, 102c.

[0069] Each of the gNBs 180a, 180b, 180c 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 UL and / or DL, support of network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data towards User Plane Function (UPF) 184a, 184b, routing of control planeinformation towards Access and Mobility Management Function (AMF) 182a, 182b and the like. As shown in FIG. 1 D, the gNBs 180a, 180b, 180c may communicate with one another over an Xn interface.

[0070] The CN 115 shown in FIG. 1 D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While each of the foregoing elements are depicted as part of the CN 115, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0071] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and may serve as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling of different PDU sessions with different requirements), selecting a particular SMF 183a, 183b, management of the registration area, termination of NAS signaling, mobility management, and the like. Network slicing may be used by the AMF 182a, 182b in order to customize CN support for WTRUs 102a, 102b, 102c based on the types of services being utilized WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for machine type communication (MTC) access, and / or the like. The AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0072] The SMF 183a, 183b may be connected to an AMF 182a, 182b in the CN 115 via an N11 interface. The SMF 183a, 183b may also be connected to a UPF 184a, 184b in the CN 115 via an N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions, such as managing and allocating WTRU IP address, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notifications, and the like. A PDU session type may be IP-based, non-IP based, Ethernet-based, and the like.

[0073] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N3 interface, which may provide the WTRUs 102a, 102b, 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 UPF 184, 184b may perform other functions, such as routing and forwardingpackets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, and the like.

[0074] The CN 115 may facilitate communications with other networks. For example, the CN 115 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 115 and the PSTN 108. In addition, the CN 115 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and / or wireless networks that are owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to a local Data Network (DN) 185a, 185b through the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0075] In view of Figures 1A-1 D, and the corresponding description of Figures 1A-1 D, one or more, or all, of the functions described herein with regard to one or more of: WTRU 102a-d, Base Station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-ab, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any other device(s) described herein, may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, the emulation devices may be used to test other devices and / or to simulate network and / or WTRU functions.

[0076] The emulation devices may be designed to implement one or more tests of other devices in a lab environment and / or in an operator network environment. For example, the one or more emulation devices may perform the one or more, or all, functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network in order to test other devices within the communication network. The one or more emulation devices may perform the one or more, or all, functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. The emulation device may be directly coupled to another device for purposes of testing and / or may performing testing using over-the-air wireless communications.

[0077] The one or more emulation devices may perform the one or more, including all, functions while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be utilized in a testing scenario in a testing laboratory and / or a non-deployed (e.g., testing) wired and / or wireless communication network in order to implement testing of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and / orwireless communications via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0078] A network may include a SLPKMF. The SLPKMF may receive a role assignment request. For example, the SLPKMF may receive the role assignment request from a from a SL positioning WTRU. The SL positioning WTRU may send the role assignment request for participating in a SL position process, for example in the role requested. The request may additionally, or alternatively, include an indication of (e.g., other) authorization information. The authorization information may be used for authorization of the WTRU role requested. The authorization may include one or more of a time for role authorization, a location, an area, a duration, and / or a starting time.

[0079] The SLPKMF may determine the role requested and / or privacy profile (e.g., need) for the role, for example based on an SL positioning policy. The SLPKMF may receive the SL positioning policy from a policy control function (PCF). The SL positioning policy may include one or more conditions. The one or more conditions may be used by the SLPKMF to determine the role assignment and / or a scope of the role. The scope of the role may include a network, a time, a location, an area, a valid duration, and / or a privacy related restriction (e.g., which entities may be exposure the WTRU privacy information), etc. The scope of the role may include that the role is associated with validity for the WTRU, for example a valid area for the WTRU. The SLPKMF may additionally, or alternatively, retrieve a location privacy profile. For example, the SLPKMF may receive the location privacy profile from a UDM. The location privacy profile may include one or more SL positioning subscription parameters and / or one or more (e.g., other) authorization parameters.

[0080] The SLPKMF may assign the role to the WTRU, for example if the role requested is authorized. The SLPKMF may generate a privacy control list. The privacy control list may be configured to control the privacy between WTRUs having different roles, for example in an SL positioning process when performing an operation related to SL communications. For example, the privacy control list may be configured such that WTRU2 acting as reference WTRU may exclude the WTRU1 as a SL positioning client. The privacy control list may control the privacy between different roles in the SL positioning process, such as other WTRUs acting as peer roles in a SL positioning service. For example, one or more (e.g., specific) WTRUs may be excluded and / or included from the privacy control list. The privacy control list may include a white / authorized list and / or a black / unauthorized list. One or more (e.g., specific) WTRUs may be (e.g., explicitly) included in the list authorized list and / or the unauthorized list. For example, the one or more WTRUs included in the authorized list and / or the unauthorized list may be associated with a WTRU group, a range of WTRUs, and / or a specific network, etc. In some examples a WTRU not included in the privacycontrol list (e.g., authorized list and / or the unauthorized list) may be associated with (e.g., have) a default action. The default action may be deny, allow, or request explicit user consent.

[0081] A WTRU may have an SL positioning server WTRU role. The SL positioning server WTRU role may be a critical role in the SL positioning process. The SL positioning server WTRU may have a large security impact, for example if the SL positioning server WTRU role is assigned to a malicious WTRU. The SLPKMF may have include a strict rule for assigning the SL positioning server role to a WTRU. For example, the SLPKMF may assign the SL positioning server role to a WTRU based on (e.g., strict) security criteria. The security criteria may include a referral, a history, third party information, allowed / white list, and / or WTRU trustworthiness, etc.

[0082] The 5GC (e.g., SLPKMF) may reject the request (e.g., role request), for example if the role requested is not authorized. The 5GC may additionally, or alternatively, assign the WTRU a role that may be (e.g., is possible to be) authorized (e.g., roles provided by AF) and / or assign the WTRU a role that is pre-authorized. The SLPKMF may send the authorized positioning role, for example to the (e.g., requesting) WTRU. The SLPKMF may send the authorized positioning role with an authorization token and / or (e.g., other) security parameters. The parameters sent back to the (e.g., requesting) WTRU may be digitally signed by the SLPKMF. The WTRU may validate the digital signature.

[0083] A first WTRU may be referred to as WTRU-1 and / or a second WTRU may be referred to as WTRU- 2. WTRU-1 may start the role negotiation with the WTRU-2, for example by sending a discovery message. Negotiation information may be embedded in the discovery message. The negotiation information may be specified as the PC5 discovery for SL positioning peer WTRU discovery. The negotiation information may include a role-1 that the WTRU-1 is acting as, an authorization token, a token scope, and / or the role requested from the WTRU-2 (e.g., role-2). A WTRU may include a role as one or more of a SL reference WTRU, a SL positioning client WTRU, a SL positioning server WTRU, and / or a target WTRU. For example, role-1 and / or role-2 may include a role of a SL reference WTRU, a SL positioning client WTRU, a SL positioning server WTRU, and / or a target WTRU.

[0084] WTRU-2 may check the authorization of the WTRU-1 , for example by checking a privacy control list. WTRU-2 may respond to WTRU-1, for example if WTRU-1 is authorized to receive the location info exposure from WTRU-2. For example, WTRU-1 may be authorized to receive the location exposure from WTRU-2 if WTRU-1 is on the allowed entity list (e.g., privacy control list) for role-2. The WTRU-2 may respond to WTRU-1 with a WTRU-2 assigned role. WTRU-2 may request role-2 from the SLPKMF, forexample if WTRU-2 is in cellular coverage and / or if WTRU-2 has not requested (e.g., does not have) role-2 assigned by the SLPKMF.

[0085] The network and / or WTRU-2 may send a message to WTRU-1 that WTRU-2 is not authorized and / or that WTRU-1 should request another WTRU, for example if WTRU-2 does not have the privileges for the WTRU-1 role requested. For example, a discovery request may be sent to multiple candidate WTRUs. The WTRU-1 may determine a best candidate, for example when multiple discovery responses are received (e.g., from multiple candidate WTRUs). WTRU-2 may reject the request from WTRU-1, for example if WTRU-2 is not in coverage. For example, WTRU-2 may send a message rejecting the request including a cause code specifying that WTRU-2 is out of coverage. WTRU-2 may respond with a code to indicate that WTRU-2 will try again when connectivity to the core network reestablished, and / or respond with a code indicating that WTRU-1 request again later. If WTRU-1 successfully authorizes WTRU-2 with WTRU-2 role-2 for example, WTRU-1 and WTRU-2 may engage in a SL positioning service. For example, WTRU-1 and WTRU-2 may engage in a SL positioning service with (e.g., respective) roles assigned by the SLPKMF.

[0086] Systems and methods may utilize a network, for example a 5G network. FIG. 2 is an example network architecture 200. The network architecture 200 may be of a 5G or NextGen network. A WTRU may communicate with an access network (AN) 202, for example a radio access network (RAN) 202. The RAN 202 may include a 5G RAT and / or Evolved E-UTRA, for example that connects to the NextGen core network.

[0087] An access control and mobility management function (AMF) 204 may include one or more function. The one or more function may include registration management, connection management, reachability management, and / or mobility management, etc. The WTRU may communicate with the A F 204 over an N1 interface.

[0088] A session management function (SMF) 206 may include one or more function. The one or more function may include session management (e.g., including session establishment, modify and / or release), WTRU IP address allocation, and / or selection and / or control of UP function, etc.

[0089] A User plane function (UPF) 208 may include one or more function. The one or more function may include packet routing and / or forwarding, packet inspection, and / or traffic usage reporting, etc. The UPF 208 may communicate with a data network (DN) 218, for example over an N6 interface.

[0090] The AMF 204 may communicate with an authentication server function (AUSF) 214, for example over an N12 interface. Additionally, or alternatively, the AMF 204 may communicate with a unified datamanagement function (UDM) 2016, for example over an N8 interface. The AUSF 214 may communicate with the UDM 216, for example over an N13 interface. The AMF 204 may communicate with a session management function (SMF) 206, for example over an N11 interface. Additionally, or alternatively, the AMF 204 may communicate with a policy control function (PCF) 212, for example over an N15 interface. The SMF 206 may communicate with the PCF 212, for example over an N7 interface. Additionally, or alternatively, the SMF 206 may communicate with the UDM 216, for example over an N10 interface. The PCF 212 may communicate with an application function (AF) 210, for example over an N5 interface.

[0091] Systems and methods may implement integrated sensing. Integrated sensing may be implemented for enhancement of wireless systems to provide sensing services addressing different target verticals / applications. Example vertical / applications may include autonomous / assisted driving, V2X, UAVs, 3D map, smart city, smart home, factories, healthcare, and / or maritime sector, etc. Sensing as herein may include a service. For example a service may include a sensing service and / or a SL positioning service.

[0092] Integrated sensing may include collecting sensing measurement data. Sensing measurement data may include data collected regarding radio / wireless signals impacted (e.g, reflected, refracted, and / or diffracted) by an object and / or environment of interest for sensing purposes. Integrated sensing may include deriving sensing results from processing sensing measurement data. An area defined for sensing, for example a sensing service area location. The area may be an area location with or without an obstacle.

[0093] FIG. 3 is an example diagram 300 of pedestrian / animal intrusion detection. A core network 302 may receive sensing measurement data, for example from one or more base stations 304. A base station 304 may collect sensing measurement data including data collected from radio / wireless signals impacted (e.g., reflected, refracted, diffracted) by an object 306 and / or environment of interest. Example objects 306 may include a vehicle, an animal, and / or a person. An area 308, for example around a home 310, and / or a roadway 312 may be defined for sensing, (e.g, sensing service area location). The area 308 and / or the roadway 312 may include one or more objects 306 which may be sensed (e.g, detected). The base station 304 may sense the object 306 in the area 308 or roadway 312, for example by collecting from radio / wireless signals impacted (e.g, reflected, refracted, diffracted) by an object 306. The base station 304 may (e.g, then) send sensing measurement data to the core network 302. The core network 302 may be configured to derive sensing results, for example by processing sensing measurement data. Additionally, or alternatively, the core network 302 may send the measurement data to a detection element 314 (e.g, intrusion detection) for processing.

[0094] FIG. 4 is an example diagram 400 of intruder detection in surroundings of a smart home. A base station 404 and / or WTRU 401 may detect the intrusion, for example in a sensing area. The base station 404 may detect an intrusion into the sensing area, for example in collaboration with one or more WTRUs 401 . For example, the base station 404 and / or the WTRU 401 may collect sensing measurement data including data collected from radio / wireless signals impacted by an object 406 and / or environment of interest. The base station 404 and / or the WTRU 401 may send a sensing signal 403, for example into the sensing area. The radio / wireless signals impacted by the object 406 may include a reflected signal 405 (e.g., of the sensing signal 403). The base station 404 and / or the WTRU 401 may send a sensing measurement, for example to a network. The network may process the sensing measurement, for example to detect intrusion.

[0095] FIG. 5 is a diagram 500 illustrating an example base station 502 and WTRU 501 with object detection. Systems and methods may be configured for transparent sensing. In transparent sensing, sensing data may be captured by the WTRU 501 and / or communicated, for example so that 5GS is aware of the sensing information. A user terminal (e.g., WTRU 501) may acquire sense signals from (e.g., many) 3GPP and / or non-3GPP devices. 5GC may determine (e.g., various) available sensing services, for example by processing collated sensing data.

[0096] Sensing and / or data may be related to a mobile originated location request (MO-LR). There may be exposure via a control plane, for example that may reuse an authorization procedure for a MO-LR. An AMF may check subscription details regarding whether the WTRU is allowed to use the MO-LR service, for example in a MO-LR procedure.

[0097] There may be no privacy check for MO-LR. For example, a MO-LR procedure may not implement such a check. A SL positioning client WTRU may use an MO-LR procedure for a SL exposure service, for example in ranging. A SL mobile terminating location request (SL-MT-LR) procedure may be triggered, for example when the SL positioning client WTRU used the MO-LR procedure for the SL exposure service. The SL-MT-LR procedure may be triggered by a (e.g., serving) AMF. The SL-MT-LR procedure may specify that the network should check the privacy details by checking the privacy profile.

[0098] A (e.g., current) privacy profile may be configured to check whether a location services (LCS) client and / or application function (AF) is authorized (e.g. allowed) or not authorized (e.g., not allowed) to retrieve a location of the WTRU, for example either with a WTRU notification or without a WTRU notification. A privacy profile check may be reused for a SL-MT-LR procedure. In some examples a (e.g., current) location privacy profile check may be performed, for example for an LCS Client, an AF, and / or a SL positioningclient WTRLI when triggering the SL-MT-LR, for example as there may not be another / a different privacy check procedure. The location privacy profile check may be performed via a list of which LCS Client(s) and / or AF(s) that are allowed to acquire location information of the (e.g., particular) WTRU.

[0099] There may be specified network-based and / or assisted ranging / SL positioning, for example where a location management function (LMF) may be utilized for ranging / SL positioning of one or more WTRUs. The network-based and / or assisted ranging / SL positioning procedure may not include a privacy check of the client WTRU. In some examples, there may be no procedure specified to check the privacy information including WTRU position and / or ID exposure to other WTRUs. Example other WTRUs may include a reference WTRU, a located WTRU, and / or a SL positioning server WTRU.

[0100] Systems and methods herein may expand the location privacy parameter, for example by adding a SL client WTRU ID. For example, systems and methods may add the SL client WTRU ID as the location client in the user subscription parameter location privacy profile. Some systems and methods may be static, unscalable, and / or hard to predict additions in advance. Additionally, or alternatively, the WTRU subscriber may not know the application layer client WTRU ID. In some examples, there may be a potential privacy violation by the other SL positioning related WTRUs, such as a SL positioning server WTRU, a located WTRU, and / or a reference WTRU, etc.

[0101] A location procedure may involve WTRUs, for example for a WTRU-only operation SL positioning. The location procedure but may not involve network function (NF), for example for a WTRU-only operation SL positioning. A (e.g., supplementary) reference signal received power (RSRP) message(s) may be sent over PC5, for example to support the privacy check in WTRU-only operation. The RSRP message may include user information of the client WTRU. In some examples the peer may not (e.g., be able to) authenticate the client WTRU ID. The client WTRU ID may (e.g., therefore) be subject to spoofing attacks.

[0102] The SLPKMF may assign the WTRU role, for example dynamically. Additionally, or alternatively, the SLPKMF may assign the WTRU role based on a time, a location, a network, a SL position policy, and / or a WTRU location privacy profile.

[0103] Systems and methods may be implemented to enforce the target WTRU privacy exposure to another WTRU. Example WTRUs include a SL positioning client WTRU, a SL positioning server WTRU, a located WTRU, and / or a reference WTRU. Systems and methods may additionally, or alternatively be implemented to enforce target WTRU privacy exposure to another WTRU in different roles.

[0104] Sensing NFs may be performed as herein. To enable integrated sensing for example, there may be network functions collectively called a sensing NF. Sensing NFs may include an integrated sensingassistance NF (ISANF) and / or a sensing operation management function (SOMF). ISANF and / or SOMF may be logical entities and / or may be collocated with another entity. For example, an ISANF may be collocated with a network exposure function (NEF); a ISANF and a SOMF may both be collocated with a NEF; a SOMF may be collocated with an AMF; and / or a SOMF may be collocated with a RAN.

[0105] An ISANF may oversee interactions with an AF for a sensing service. The ISANF may receive and / or understand the service request from the AF and / or may determine (e.g., derive) a corresponding requested sensing mechanism. Based on the sensing mechanism for example, the ISANF may send and / or forward the request to (e.g., the relevant) NFs (e.g., within 5GC). The NFs may serve the region of interest and / or requested entities, for example such as WTRUs. When the AF is a third party application which is not a trusted entity of the network (e.g., 5GS) for example, the AF and / or ISANF may communicate through a network exposure function (NEF).

[0106] A SOMF may coordinate a sensing operation between a base station (BS) and one or more WTRUs. The SOMF may determine (e.g., derive) coordination information for the sensing operation, for example based on information received from the AMF, the BS, and / or the WTRUs. The information may include a requested sensing region, a BS list, a WTRU list, and / or a requested sensing mechanism with QoS requirement. For example, a SOMF may decide the role of sensing operation. The role of the sensing operation may include sender(s) of sensing signal(s), receiver(s) of sensing signal(s), an entity to collect the sensing measurement data, and / or an entity to calculate sensing result. The SOMF may decide a sensing period and / or a waveform of a sensing signal. Additionally, or alternatively, the SOMF may request that the BS and / or sender resource assignment send the sensing signal at the sensing period.

[0107] The SLPKMF may include a logical function that handles network related operations, for example for generation and / or provisioning of security materials used for ranging / SL positioning services. The SLPKMF may be a standalone entity or may be collocated, for example with a 5G PKMF. The SLPKMF may support functionalities supported by a 5G PKMF. Additionally, or alternatively, the SLPKMF may support key management for secure unicast direct link establishment between the WTRUs for ranging / SL positioning services provided by network. The SLPKMF may support WTRU role authorization, for example via the UDM. The SLPKMF may support key management for protection of a SL positioning protocol (SLPP) signaling broadcast / groupcast. An address of the SLPKMF may be preconfigured on the WTRU and / or provisioned, for example by the policy control function (PCF) to the WTRU. A WTRU role assignment may be based on WTRU SL location policy, location privacy profile, and / or other attributes.

[0108] The SLPKMF may assign a positioning authorized role, for example in an authorization token. The SLPKMF may assign a positioning authorized role when the request been authorized. The SLPKMF may determine the role requested and / or privacy need for the role, for example based on the SL positioning policy and / or user location privacy profile. If the role requested is authorized for example, the SLPKMF may assign the role to the WTRU. A privacy control list may be used to control the privacy between different roles in the SL positioning process. For example (e.g. , other) WTRUs and / or (e.g. , other) WTRU roles may be included or excluded from the privacy control list. The privacy control list may be configured to control the privacy between WTRUs having different roles, for example in an SL positioning process when performing an operation related to SL communications The authorization sent back to the requester may be digitally signed, for example by the SLPKMF.

[0109] A WTRU may send a discovery request. The discovery request may indicate (e.g., other) information for authorization, for example a time for which the role should be authorized. If the role is not authorized for example, the 5GC may reject the request. The 5GC may additionally, or alternatively, assign the WTRU a role that may be (e.g., is possible to be) authorized (e.g., roles provided by AF) and / or assign the WTRU a role that is pre-authorized.

[0110] A WTRU may have an SL positioning server WTRU role. The SL positioning server WTRU role may be a critical role in the SL positioning process. The SLPKMF may have include a strict rule for assigning the SL positioning server role to a WTRU. For example, the SLPKMF may assign the SL positioning server role to a WTRU based on (e.g., strict) security criteria. The security criteria may include a referral, a history, third party information, allowed / white list, and / or WTRU trustworthiness, etc.

[0111] During discovery for example, the WTRU(s) may exchange the SL positioning role. Additionally, or alternatively, the WTRU(s) may exchange other roles, for example of other WTRU(s). Authorization and / or privacy may be checked, for example during the discovery. If the target WTRU privacy check is negative for example, the discovery procedure may end. If another WTRU acting as SL reference WTRU has a privacy check negative for example, the (e.g., other) WTRU(s) may not be included in the SL positioning procedure. A discovery response may include (e.g., other) conditions. For example, the (e.g., other) conditions may be used to determine whether the authorization is valid. Example conditions may include a time for which the role is authorized and / or a geo location, an indication of authorization of the WTRU role requested for performing the operation related to SL communications

[0112] FIG. 6 illustrates an example of a SL role assignment procedure 600. A WTRU 602, for example a SL positioning WTRU, may send a discovery request at 612. The WTRU 602 may send the discoveryrequest to a SLPKMF 604. The discovery request may include an indication of a WTRU role requested (e.g., for performing an operation related to SL communications). The SLPKMF 604 may receive the discovery request (e.g., role assignment request) from a WTRU 602 that intends to participate in a SL positioning process, for example acting as the role requested. The request may include additionally, or alternatively an indication of one or more of a time for role authorization, a location, an area, a duration, and / or a starting time.

[0113] The SLPKMF 604 may determine a WTRU SL location policy and / or a user location privacy. The WTRU SL location policy and / or the user location privacy profile may be associated with the WTRU 602. The SLPKMF 604 may determine the WTRU SL location policy and / or the user location privacy profile based on policy information. The SLPKMF 604 may receive the policy information form a PCF 606. The SLPKMF 604 may determine the role requested and / or privacy profile (e.g., need) for the role, for example based on an SL positioning policy. The SLPKMF 604 may receive the SL positioning policy from a PCF 606. For example, at 614 the SLPKMF 604 may send an Npcf_WTRUPolicycontrol_Create message to the PCF 606. The PCF 606 may at 616, in response for example, send a Npcf_WTRUPolicycontrol_Create Response. The Npcf_WTRUPolicycontrol_Create Response may include an indication of a WTRU SL location policy. The PCF 606 may send the Npcf_WTRUPolicycontrol_Create Response to the SLPKMF 604.

[0114] The SL positioning policy may include one or more conditions. The one or more conditions may be used by the SLPKMF 604 to determine the role assignment and / or a scope of the role. The scope of the role may include a network, a time, a location, an area, a valid duration, and / or a privacy related restriction (e.g., which entities may be exposure the WTRU privacy information), etc. The scope of the role may be that the role associated with validity for the WTRU 602, for example a valid area for the WTRU 602.

[0115] The SLPKMF 604 may additionally, or alternatively, retrieve a location privacy profile. For example, the SLPKMF may receive the location privacy profile from a UDM and / or a user data repository (UDR) 610. For example, at 618 the SLPKMF 604 may send a Nudr_DataRepository_Query request to the UDR 610 (e.g., via one or more NFs 608). The Nudr_DataRepository_Query request may include an indication of the WTRU ID. At 620 the UDR 610 may send a Nudr_DataRepoistory_Query Response, for example to the SLPKMF 604 (e.g., via one or more NFs 608). The Nudr_DataRepoistory_Query Response may include an indication of one or more of a location privacy profile, authorization data, and / or user consent conditions. The location privacy profile may include one or more SL positioning subscription parameters and / or one or more (e.g., other) authorization parameters.

[0116] At 622 the SLPKMF 604 may determine the role requested and / or the privacy profile (e.g., need) for the role. The SLPKMF 604 may determine that the WTRU role requested is authorized, for example based on the WTRU SL location policy and / or the user location privacy policy. In some examples, the SLPKMF may determine that the WTRU role requested is not authorized, for example based on the WTRU SL location policy and / or the user location privacy policy. The SLPKMF 604 may determine the requested role and / or privacy profile (e.g., need) for the role, for example based on the policy (e.g., positioning policy) from PCF 606, the (e.g., location) privacy profile (e.g., user privacy profile) from a UDM and / or a user data repository (UDR) 610, and / or other authorization information. If the requested role(s) along and / or (e.g., associated) contextual parameters are authorized for example, the SLPKMF 604 may assign the role(s) to the WTRU(s) associated with the contextual parameters. The role(s) and / or contextual parameters may be sent back to the requester digitally signed. For example, the SLPKMF 604 may send the (e.g., digitally signed) contextual parameters to the WTRU 602.

[0117] The SLPKMF 604 may determine role assignment (e.g., to one or more WTRUs) and / or may determine the scope of the role(s). For example, the scope of the role(s) may include a network, a time, a location, an area, a valid duration, and / or a privacy related restriction (e.g., which entities may be exposure the WTRU privacy information), etc. If the role(s) is not authorized for example, the 5GC may reject the request and / or assign a role(s). The assigned role may be a different role than the role requested and / or not authorized.

[0118] Additionally, or alternatively, at 622 the SLPKMF 604 may assign the role to the WTRU and / or generate a privacy control list. The SLPKMF 604 may assign the role to the WTRU 602, for example if the role requested is authorized. The SLPKMF 604 may generate the privacy control list. The privacy control list may be configured to control the privacy between different roles, for example in an SL positioning process. For example, the privacy control list may be configured such that a WTRU (e.g., WTRU2) acting as a reference WTRU may exclude a WTRU (e.g., WTRU1) as a SL positioning client.

[0119] The privacy control list may control (e.g., be used to control) the privacy between different roles in the SL positioning process, such as other WTRUs acting as peer roles in a SL positioning service. For example, one or more (e.g., specific) WTRUs may be excluded and / or included from the privacy control list. The privacy control list may include a white / authorized list and / or a black / unauthorized list. One or more (e.g., specific) WTRUs may be (e.g., explicitly) included in the list authorized list and / or the unauthorized list. For example, the one or more WTRUs included in the authorized list and / or the unauthorized list may be associated with a WTRU group, a range of WTRUs, and / or a specific network, etc. In some examples aWTRU not included in the privacy control list (e.g., authorized list and / or the unauthorized list) may be associated with (e.g., have) a default action. The default action may be deny, allow, or request explicit user consent.

[0120] A WTRU may have an SL positioning server WTRU role. The SL positioning server WTRU role may be a critical role in the SL positioning process. The SL positioning server WTRU may have large security impact, for example if the SL positioning server WTRU role is assigned to a malicious WTRU. The SLPKMF may have include a strict rule for assigning the SL positioning server role to a WTRU. For example, the SLPKMF may assign the SL positioning server role to a WTRU based on (e.g., strict) security criteria. The security criteria may include a referral, a history, third party information, allowed / white list, and / or WTRU trustworthiness, etc.

[0121] At 624 the SLPKMF 604 may send a discovery response to the WTRU 602. The discovery response may include an indication of one or more of a role assigned and / or an authorization of the WTRU role requested for performing the operation related to SL communications. In an example, the discovery response may include an authorization token, an authorization scope, and / or a privacy control list. The 5GC (e.g., SLPKMF 604) may additionally, or alternatively, assign the WTRU 602 a role that may be (e.g., is possible to be) authorized (e.g., roles provided by AF) and / or assign the WTRU 602 a role that is preauthorized. The SLPKMF 604 may send the authorized positioning role, for example to the (e.g., requesting) WTRU 602. The SLPKMF 604 may send the authorized positioning role with an authorization token and / or (e.g., other) security parameters. The parameters sent back to the (e.g., requesting) WTRU may be digitally signed by the SLPKMF 604. The WTRU 602 may validate the digital signature. The 5GC (e.g., SLPKMF 604) may reject the request (e.g., role request), for example if the role requested is not authorized.

[0122] At 626 the SLPKMF 604 may receive update information, for example from the PCF 606. The SLPKMF 604 may determine, for example based on the update information, that the WTRU role requested is authorized or unauthorized. The SLPKMF 604 may send an update response, for example to the WTRU 602. The update response may include an indication of authorization of the WTRU role requested for performing the operation related to SL communications. For example, at 628 the SLPKMF 604 may send an authorization update to the WTRU 602. The SLPKMF 604 may send an update of the authorized positioning role in an authorization token back to the role requesting WTRU. The parameters sent back to the requester may be digitally signed by the SLPKMF that can be validated by the token consumer. Theauthorization update may include an indication of one or more of a role assigned, an authorization token, an authorization scope, and / or a privacy control list.

[0123] FIG. 7 illustrates an example process 700 of peer WTRU authorization and role negotiation during discovery. During discovery, one or more WTRUs (e.g., WTRU-1 702 and WTRU-2 704) may exchange the SL positioning role, WTRU(s) act(s), and / or (e.g., required) role(s) by other WTRUs. Authorization and / or privacy may be checked during discovery. If the target WTRU privacy check is negative for example, the process 700 may stop. If any other WTRU acting as SL reference WTRU has a negative privacy check, the WTRU(s) may not be included in a SL positioning procedure. The discovery response may include other conditions under which the authorization is valid in the scope (e.g., time the role is authorized for, the geo location).

[0124] A peer WTRU may authorize and / or negotiate roles during discovery. For example, after a SL positioning WTRU requests the role assignment from the SLPKMF, the SL positioning WTRU may receive the authorized role assignment from the SLPKMF (e.g., with the role requested and privacy control list). The privacy control list may be used to control the privacy between different roles in the SL positioning process. For example, other WTRUs acting as other roles may be excluded from the authorization list.

[0125] Embedded in the discovery messages for example, the WTRU(s) may exchange the SL positioning role the WTRU(s) intended to act and / or (e.g., required) role(s) by other peer WTRUs. The authorization and / or privacy may be checked during discovery. If the target WTRU privacy check is negative for example (e.g., if the target WTRU’s location information is restricted from the SL positioning client WTRU, SL positioning server WTRU, and / or other SL positioning WTRUs that can receive the target WTRU’s privacy information) the process 700 may stop. If a WTRU privacy check is negative and the WTRU acts as SL positioning server / reference / located WTRU and the WTRU’s role may be replaced by another entity acting as the same role, the process 700 may proceed. For example, the process 700 may proceed by excluding the WTRU(s) whose privacy is / are restricted by the target WTRU. After negotiation, a (e.g., discover) WTRU and (e.g., discoveree) WTRU may start a SL positioning procedure.

[0126] WTRU-1 702 and / or WTRU-2 704 may, at 710, subscribe to a service (e.g. sensing service and / or SL positioning service) and / or request a role assigned. For example, WTRU-1 702 and / or WTRU-2 704 may subscribe to the service (e.g. sensing service and / or SL positioning service) and / or request the role assigned when in coverage. Additionally, or alternatively, WTRU-1 702 and / or WTRU-2 704 may request authorization and / or a privacy control list, for example from a SLPKMF 706. Service (e.g. sensing service and / or SL positioning service) participating WTRUs (e.g., WTRU-1 702 and / or WTRU-2 704) maysubscribe to the service (e.g. sensing service and / or SL positioning service) and / or request the role assigned, for example as described herein. The WTRUs (e.g., WTRU-1 702 and / or WTRU-2 704) may receive the authorization of the role requested, for example in an authorization token and / or privacy control list from the SLPKMF 706.

[0127] WTRU-1 702 may start a role negotiation with WTRU-2 704. For example, at 712 WTRU-1 702 may send a discovery request message to WTRU-2 706. Negotiation information may be included (e.g., embedded) in the discovery request message, for example as a PC5 discovery for the SL positioning peer WTRU discovery. The negotiation information may include role-1 (e.g., that the WTRU-1 is acting as), WTRU-1 meta data (e.g., security data and / or location data), an authorization token and / or token scope, and / or an indication of a role requested from the WTRU-2 704 (role-2).

[0128] At 714 WTRU-2 704 may check the authorization of WTRU-1 702, and / or the meta data, that for example may be used during role negotiation. If the WTRU-1 702 is authorized to receive the location information exposure from the WTRU-2 704 for example, WTRU-2 704 may respond back to WTRU-1 702 with the WTRU’s assigned role. WTRU-2 704 may check the authorization of WTRU-1 702 by checking if WTRU-1 702 is on the privacy control list (e.g., allowed entity list / white list) for role-1. If for example WTRU- 2 704 has not requested role-2 assigned by the SLPKMF 706, WTRU-2 704 may request role-2 from the SLPKMF 706 (e.g., if WTRU-2 704 is in coverage). For example, WTRU-2 704 may request role-2 from the SLPKMF 706 at 716.

[0129] The network (e.g., SLPKMF 706 and / or PCF / UDM 708) and / or WTRU-2 704 may send a message to WTRU-1 702 that WTRU-2 704 is not authorized and / or that WTRU-1 702 should request another WTRU, for example if WTRU-2 704 does not have the privileges for the WTRU-1 702 role requested. For example, a discovery request may be sent to multiple candidate WTRUs. The WTRU-1 702 may determine a best candidate, for example when multiple discovery responses are received (e.g., from multiple candidate WTRUs). WTRU-2 704 may reject the request from WTRU-1 702, for example if WTRU-2 704 is not in coverage. If the WTRU-2 704 is in coverage for example, WTRU-2 704 may optionally reject the request (e.g., with a cause code specifying that WTRU-2 704 is out of coverage), respond with a code to indicate that WTRU-2 704 will try again when connectivity to the core network is reestablished, and / or respond with a code to request WTRU-1 702 try again later.

[0130] At 718 WTRU-2 704 may send a discovery response to WTRU-1 702. For example if WTRU-2 704 authorizes the request from WTRU-1 702 and / or role-1 is authorized by WTRU-2 704, WTRU-2 704 may send the discovery response. WTRU-2 704 may send the discovery response to WTRU-1 702 including anindication of WTRU-2’s 704 confirmed role-2 and / or the meta data of WTRU-2 704. WTRU-2 704 may (e.g., otherwise) send a rejection message to WTRU-1 702 and / or include the rejection reason in the rejection message. For example, WTRU-1 702 may perform role negotiation with other candidate WTRUs.

[0131] WTRU-1 702 may verify authorization of WTRU-2 704 at 720. For example, WTRU-1 may check that WTRU-2 704 is not on WTRU-1 privacy control list / privacy blocking list as role-2. If WTRU-2 704 is not authorized for example, WTRU-1 702 may perform the role negotiation procedure with other WTRUs (e.g., as described herein).

[0132] At 722 WTRU-1 702 and WTRU-2 704 may engage in the SL positioning service, for example with respective roles assigned by the SLPKMF 706. For example WTRU-1 702 and WTRU-2 704 may engage in the SL positioning service if WTRU-1 702 successfully authorizes WTRU-2 704 with WTRU-2 role-2 (e.g., at 720).

[0133] FIG. 8 illustrates an example process 800 of SL position WTRU role negotiation and role authorization after discovery. The role exchange and authorization may be after discovery. Discovery may be performed as in PC5 communications. Once the WTRUs have discovered each other and / or connection is established for example, WTRUs may (e.g., then) perform role negotiation. The WTRUs may perform role negotiation over PC5, for example using any of the existing PC5 signaling messages and / or using the defined messages (e.g., role negotiation request / response message(s)). The WTRUs may perform additional communications / actions after the role negotiation and / or security connection setup.

[0134] WTRU-1 802 and / or WTRU-2 804 may, at 810, subscribe to a service (e.g. sensing service and / or SL positioning service) and / or request a role assigned. For example, WTRU-1 802 and / or WTRU-2 804 may subscribe to the sensing services and / or request the role assigned when in coverage. Additionally, or alternatively, WTRU-1 802 and / or WTRU-2 804 may request authorization and / or a privacy control list, for example from a SLPKMF 806.

[0135] At 812 WTRU-1 802 and WTRU-2 804 may perform discovery and connection. WTRU-1 802 may initiate discovery and connection by sending a discovery request message to WTRU-2 804. Discovery and connection may be as described herein. At 814 WTRU-1 802 may start a role negotiation with WTRU-2 804. Negotiation information may be included (e.g., embedded) in the discovery request message, for example as a PC5 discovery for the SL positioning peer WTRU discovery. The negotiation information may include role-1 (e.g., that the WTRU-1 802 is acting as), WTRU-1 802 meta data (e.g., security data and / or location data), an authorization token and / or token scope, and / or an indication of a role requested from the WTRU-2 804 (role-2).

[0136] At 816 WTRU-2 804 may check the authorization of WTRU-1 802, and / or the meta data, that for example may be used during role negotiation. If the WTRU-1 802 is authorized to receive the location information exposure from WTRU-2 804 for example, WTRU-2 804 may respond back to WTRU-1 802 with the WTRU’s assigned role. WTRU-2 804 may check the authorization of WTRU-1 802 by checking if WTRU-1 802 is on the privacy control list (e.g., allowed entity list / white list) for role-1. If for example WTRU- 2 804 has not requested role-2 assigned by the SLPKMF 806, WTRU-2 804 may request the role-2 from the SLPKMF 706 (e.g., if WTRU-2 704 is in coverage). For example, WTRU-2 804 may request the role-2 from the SLPKMF 806 at 818.

[0137] At 820 WTRU-2 804 may send a role negotiation response to WTRU-1 802. For example WTRU-2 804 may send an indication of role-2 and / or meta data (e.g., for WTRU-1 802 and / or WTRU-2 804). WTRU- 1 802 may verify authorization of WTRU-2 804 at 822. For example, WTRU-1 802 may verify the authorization of WTRU-2 804 and / or validate role-2 (e.g., as described herein).

[0138] At 824 WTRU-1 802 and WTRU-2 804 may engage in the SL positioning service, for example with respective roles assigned by the SLPKMF 806. For example WTRU-1 802 and WTRU-2 804 may engage in the SL positioning service if WTRU-1 802 successfully authorizes WTRU-2 804 with WTRU-2 role-2 (e.g., at 822).

Claims

CLAIMS:1 . A sidelink (SL) positioning key management function (SLPKMF) comprising: a processor configured to: receive a discovery request from a wireless transmit / receive unit (WTRU), wherein the discovery request comprises an indication of a WTRU role requested for performing an operation related to SL communications; determine a WTRU SL location policy and a user location privacy profile associated with the WTRU; determine, based on the WTRU SL location policy and the user location privacy profile, that the WTRU role requested is authorized; assign the WTRU role to the WTRU and generate a privacy control list configured to control privacy between at least two WTRUs having different roles when performing an operation related to SL communications; and send a discovery response to the WTRU, the discovery response comprising an indication of authorization of the WTRU role requested for performing the operation related to SL communications.

2. The SLPKMF of claim 1 , wherein the discovery request comprises at least one of a time for role authorization, a location, an area, a duration, or a starting time.

3. The SLPKMF of claim 1 , wherein the processor is configured to receive policy information from a policy control function (PCF), and wherein the processor is configured to determine the WTRU SL location policy and user location policy profile based on the policy information.

4. The SLPKMF of claim 3, wherein the processor is configured to: send a request message to a user data repository (UDR) entity, the request comprising an indication of an identifier (ID) of the WTRU; and receive a response message from the UDR entity, the response message comprising an indication of the user location privacy profile.

5. The SLPKMF of claim 1 , wherein the processor is configured to receive the user location privacy profile from a unified data management (UDM) entity.

6. The SLPKMF of claim 1 , wherein the privacy control list comprises at least one of a first list of one or more first WTRUs authorized for the operation related to SL communications or a second list of one or more second WTRUs not authorized for the operation related to SL communications.

7. The SLPKMF of claim 6, wherein the WTRU comprises a first WTRU and the discovery request comprises a first discovery request, wherein a second WTRU is comprised in the first list of the oneor more first WTRUs authorized for the operation related to SL communications, and wherein the processor is configured to, based on the second WTRU being comprised in the first list of the one or more first WTRUs authorized for the operation related to SL communications, receive a second discovery request from the second WTRU, wherein the second discovery request comprises an indication of a second WTRU role requested for performing an operation related to SL communications.

8. The SLPKMF of claim 1 , wherein the privacy control list further comprises an indication of at least one of a WTRU group identifier (ID), a range of WTRUs, or WTRUs associated with a network.

9. The SLPKMF of claim 1 , wherein the processor is configured to receive update information from a policy control function (PCF), and wherein the processor is configured to determine, based on the update information, that the WTRU role requested is authorized.

10. The SLPKMF of claim 9, wherein the processor is configured to send an update response to the WTRU, the update response comprising an indication of authorization of the WTRU role requested for performing the operation related to SL communications.

11. A method performed by a sidelink (SL) positioning key management function (SLPKMF), the method comprising: receiving a discovery request from a wireless transmit / receive unit (WTRU), wherein the discovery request comprises an indication of a WTRU role requested for performing an operation related to SL communications; determining a WTRU SL location policy and a user location privacy profile associated with the WTRU; determining, based on the WTRU SL location policy and the user location privacy profile, that theWTRU role requested is authorized; assigning the WTRU role to the WTRU and generating a privacy control list configured to control privacy between at least two WTRUs having different roles when performing an operation related to SL communications; and sending a discovery response to the WTRU, the discovery response comprising an indication of authorization of the WTRU role requested for performing the operation related to SL communications.

12. The method of claim 11 , wherein the discovery request comprises at least one of a time for role authorization, a location, an area, a duration, or a starting time.

13. The method of claim 11 , comprising receiving policy information from a policy control function (PCF), and determining the WTRU SL location policy and user location policy profile based on the policy information.

14. The method of claim 13, comprising: sending a request message to a user data repository (DDR) entity, the request comprising an indication of an identifier (ID) of the WTRU; and receiving a response message from the UDR entity, the response message comprising an indication of the user location privacy profile.

15. The method of claim 11 , comprising receiving the user location privacy profile from a unified data management (UDM) entity.

16. The method of claim 11 , wherein the privacy control list comprises at least one of a first list of one or more first WTRUs authorized for the operation related to SL communications or a second list of one or more second WTRUs not authorized for the operation related to SL communications.

17. The method of claim 16, wherein the WTRU comprises a first WTRU and the discovery request comprises a first discovery request, wherein a second WTRU is comprised in the first list of the one or more first WTRUs authorized for the operation related to SL communications, and wherein the method comprises, based on the second WTRU being comprised in the first list of the one or more first WTRUs authorized for the operation related to SL communications, receiving a second discovery request from the second WTRU, wherein the second discovery request comprises an indication of a second WTRU role requested for performing an operation related to SL communications.

18. The method of claim 11 , wherein the privacy control list further comprises an indication of at least one of a WTRU group identifier (ID), a range of WTRUs, or WTRUs associated with a network.

19. The method of claim 11 , comprising receiving update information from a policy control function (PCF), and wherein the method comprises determining, based on the update information, that the WTRU role requested is authorized.

20. The method of claim 19, comprising sending an update response to the WTRU, the update response comprising an indication of authorization of the WTRU role requested for performing the operation related to SL communications.

Images