Physical layer security enhancement for integrated sensing and communication authentication for BI-static systems

Abstract

Systems, methods, processors, and circuitries are provided for securing a sensing-related signal for use in providing sensing services to a target user equipment (UE). In one example, a method includes identify a sensing token associated with the target UE and selectively receiving a sensing-related signal from the target UE based whether the sensing-related signal carries the sensing token.

Description

PHYSICAL LAYER SECURITY ENHANCEMENT FOR INTEGRATED SENSING AND COMMUNICATION AUTHENTICATION FOR BI-STATIC SYSTEMSFIELD

[0001] This disclosure relates to wireless communication networks including techniques for improving the security of integrated sensing and communication (ISAC) networks.BACKGROUND

[0002] As the number of mobile devices within wireless networks, and the demand for mobile data traffic continue to increase, changes are made to system requirements and architectures to better address current and anticipated demands. For example, some wireless communication networks may be developed to implement fifth generation (5G) or new radio (NR) technology, sixth generation (6G) technology, and so on. An aspect of such technology includes improvements to wireless communication networks to provide object detection and / or tracking features.BRIEF DESCRIPTION OF THE DRAWINGS

[0003] The present disclosure will be readily understood and enabled by the detailed description and accompanying figures of the drawings. Like reference numerals may designate like features and structural elements. Figures and corresponding descriptions are provided as non-limiting examples of aspects, implementations, etc., of the present disclosure, and references to "an" or “one” aspect, implementation, etc., may not necessarily refer to the same aspect, implementation, etc., and may mean at least one, one or more, etc.

[0004] FIG. 1 is a functional block diagram of an example wireless communication network that includes provides a sensing function, in accordance with various aspects disclosed.

[0005] FIG. 2A illustrates a wireless communication network operating in a mono-static sensing mode, in accordance with various aspects disclosed.

[0006] FIG. 2B illustrates a wireless communication network operating in a bi-static sensing mode, in accordance with various aspects disclosed.

[0007] FIG. 3 illustrates an example key hierarchy, in accordance with various aspects disclosed.

[0008] FIG. 4 is a flow diagram of an example access stratum security mode command (AS SMC) process, in accordance with various aspects disclosed.

[0009] FIG. 5 is a flow diagram of an example process for generating a physical key (KPHY) , in accordance with various aspects disclosed.

[0010] FIG. 6 is a flow diagram of an example process for generating a sidelink key (KNRP) , in accordance with various aspects disclosed.

[0011] FIGs. 7A and 7B are a flow diagrams of example processes for generating a sensing function-related key (KSHARE_SF) , in accordance with various aspects disclosed.

[0012] FIG. 8 is a flow diagram of an example process for securing sensing-related signals, in accordance with various aspects disclosed.

[0013] FIG. 9 is a flow diagram of an example process for securing sensing-related signals, in accordance with various aspects disclosed.

[0014] FIG. 10 is a flow diagram of an example process for securing sensing-related signals, in accordance with various aspects disclosed.

[0015] FIG. 11 is a flow diagram of an example method for securing sensing-related signals, in accordance with various aspects disclosed.

[0016] FIG. 12 is a flow diagram of an example method for securing sensing-related signals, in accordance with various aspects disclosed.

[0017] FIG. 13 is a flow diagram of an example method for securing sensing-related signals, in accordance with various aspects disclosed.

[0018] FIG. 14 is a functional block diagram of a wireless communication network, in accordance with various aspects described.

[0019] FIG. 15 illustrates a simplified block diagram of a user equipment device, in accordance with various aspects described.DETAILED DESCRIPTION

[0020] The following detailed description refers to the accompanying drawings. Like reference numbers in different drawings may identify the same or similar features, elements, operations, etc. Additionally, the present disclosure is not limited to the following description as other implementations may be utilized, and structural or logical changes made, without departing from the scope of the present disclosure.

[0021] Next generation wireless networks such as cellular and WiFi networks, are being designed to provide sensing capabilities in addition to communication between network devices such as user equipment (UEs) and radio access network (RAN) nodes. To support sensing, the network devices transmit, receive, and also measure sensing-related signals. The network devices provide sensing data to a sensing function implemented locally (e.g., in a RAN node) , in a core network, or distributed between the local and core networks. The sensing data may be used to by the sensing function to provide sensing services to a target UE. Sensing services may include, for example, rendering a visual representation of a target UE in the environment or  providing positioning assistance for the target UE. The sensing services may also include detecting and tracking non-connected objects such as humans, unmanned aerial vehicles, and inanimate objects.

[0022] FIG. 1 illustrates an example non-roaming architecture 100 that includes a local network 105, such as a RAN or portion of a RAN, that is coupled to a core network (CN) 130, and a sensing function SF 160. A UE 110 can operate in a non-roaming architecture (e.g., non-roaming architecture 100) of a wireless network or a roaming architecture of the wireless network. The UE 110 operating in the non-roaming architecture 100 can concurrently access the local data network provided by the local network 105 and a central data network supported by the CN 130. The UE 110 operating in a roaming architecture may have limited access to the local data network or the central data network according to a differing arrangement of network functions to support roaming features, and limited access to some network functions relative to the non-roaming architecture 200. For example, UE 110 access to CN 130 may be limited by a security edge protection proxy (SEPP) while the UE 110 is roaming where some non-roaming network functions or users are isolated, or protected, from the roaming UE 110 by the SEPP. Solutions provided herein relate to the non-roaming architecture 100.

[0023] In the illustrated example, the architecture includes a sensing function (SF) 160 having a user plane component SF-U 160b that is integrated in a local network node (e.g., a RAN node or base station 120) and a control plane component SF-C 160a that is implemented in a core network (CN) 130. In other examples, the functional components of the sensing function may be distributed differently between the local network and the core network or located entirely in either the local network or the core network.

[0024] The CN 130 include an access and mobility management function (AMF) 132, a policy control function (PCF) 135, a network data analytics function (NWDAF) 136, a network exposure function (NEF) 137, and an application function (AF) 138. The CN 130 provides an NS1 interface to pass sensing-related information between the SF-C 160a and the SF-U 160b for sensing configuration and sensing data processing. The PCF 135, NWDAF 136, NEF 137, and AF 138 provide sensing-related information including one or more of sensing authentication information, sensing policy information, sensing management information, sensing requirement information, sensing application information, wireless network data analysis for sensing, network capability for sensing, and the like.

[0025] The AMF 132 is a network element within the CN 130 that provides registration management, connection management, reachability management, mobility management and next generation application protocols (NGAP) signaling. The AMF 132 provides services in  communications between the CN 130 and the UE 110 via an N1 interface and the base station 120 via an N2 interface

[0026] The PCF 135 provides policies associated with mobility management and session management. Mobility management can be associated with UE 110 mobility in radio resource control (RRC) states (e.g., Idle and Connected modes) . Session management policies can be associated with mechanisms to manage subscriber limits and quality of service (QoS) of a packet data network (PDN) session. As such, the PCF 135 can provide policy related information for sensing services and functions associated with the SF 160. For example, policy data from the PCF 135 can be used by the SF 160 to determine a sensing configuration or used by the SF 160 when processing sensing data. As such, the PCF 135 can provide sensing-related policy information to SF 160.

[0027] The NWDAF 136 can establish interfaces and protocols with one or more components of the CN 130 including the PCF 135 via an N23 interface, AMF 132 via an INTB interface, NEF 137 via an INTA interface, and AF 138 via the INTA interface, and can retrieve data from the CN 130 components and perform analysis on the retrieved data. The NWDAF 136 can provide information including analysis of data or instructions from one or more CN 130 components for the SF 160. As such, the NWDAF 136 can provide sensing-related data to the SF 160.

[0028] The NEF 137 provides information regarding the capability of network functions within the wireless network to external network functions or applications. For example, the NEF 137 can report the network monitoring capability of the wireless network to external applications. As such, the NEF 137 can provide capability information of the wireless network for the SF 160 to use to determine the sensing configuration or to process sensing data.

[0029] The AF 138 can be configured as an application server providing application support for services and information. For example, the AF 138 can provide application information for video streaming. As such, the AF 138 can provide application information, or application sensing information, from the wireless network to the SF 160 to use to determine the sensing configuration or to process sensing data.

[0030] SF-U 160b provides sensing data signaling and sensing processing results that can include a sensing processing report or sensing commands to the SF-C 160a by way of an NS1 interface. The SF-C 160a provides sensing control signaling (e.g., sensing-related policy information, sensing relation application information, sensing-related data, etc…) , sensing service request signaling, sensing service response signaling, and sensing processing result signaling to the AMF 132 via an NS2 interface.

[0031] The SF-U 160b is located outside of the CN 130 and is locally integrated with the local network 105. In some aspects, the SF-U 160b is located within the base station 120 or an edge (e.g. edge server) . A dashed box 120 containing base station 120 and SF-U 160b represents that the SF 160-b can be integrated in the base station 120.

[0032] The SF-U 160b provides locally integrated sensing services such as retrieving sensing data, processing sensing data, and transmitting sensing data results and interacts directly with the base station 120 and the AMF 132, indirectly with the UE 110 through the base station 120 via Uu interface, and indirectly with the PCF 135, NWDAF 136, NEF 137, and AF 138 through the SF-C 160a and the AMF 132. By locally integrating the SF-U 160b, sensing data can be split among local components such as terminals, base stations, and edge servers, for example, by a plurality of SFs. Local integration of the SF-U can enable ISAC for wireless networks while increasing QoS by minimizing CN 130 network overhead and latency of sensing signaling by locating the SF-U 168b within the local network 105 relative to central integration of the SF-C 168a in the CN 130.

[0033] FIG. 2A illustrates a wireless communication network 200 configured to provide sensing services to a target UE 210. The network 200 includes a transmitter / receiver (TX / RX) device 220 that is connected to the sensing function in the core network (SF-C) 230. The TX / RX SN device 220 may be a transmit / receive point (TRP) associated with a base station or RAN node. In this case, the TX / RX device 220 may include components that implement the SF-U. The TX / RX SN device 220 may be a UE type device that communicates with the CN by way of a RAN node. In this case, the TX / RX device 220 will provide data to an SF-U implemented in a RAN node to which the TX / RX device 220 is connected. The dotted line around SF-U in FIG. 2A indicates that the SF-U may be implemented in the TX / RX device 220 or in a device to which the TX / RX SN device 220 is connected.

[0034] The network 200 may include other local devices, such as sensing clusters (not shown) , that provide sensor data to the SF-C 203 for supporting the sensing function. The collection of devices that provide sensor data and / or communicate with the target UE 210 to provide sensing services to the target UE may be referred to individually as sensing network (SN) devices and collectively as a sensing network with respect to the target UE 210. The target UE 210 may be a UE that has subscribed to a sensing function or is running an application that is authorized to access the sensing function, or has been in any way authorized to receive sensing-related signals by an acceptable security mechanism.

[0035] UEs 210-E1 and 210-E2 are not part of a sensing network that is providing sensing services to the target UE 210. UEs 210-E1 and 210-E2 will be referred to as eavesdropper devices. The eavesdropper devices are devices that should not have access to communications  with the target UE. The eavesdropper devices may or may not be subscribers to the sensing service but in either case the communications between the TX / RX SN device 220 and the target UE 210 should not be received or decodable by the eavesdropper devices. However, the eavesdropper devices should be detected by the sensing network for use in providing the sensing service to the target UE. For example, the sensing network may provide information about the detected eavesdropper devices to the target UE to enable null steering and secure beamforming, which enhances physical layer (PHY) security.

[0036] The TX / RX SN device 220 is performing a mono-static sensing technique. In mono-static sensing, the same device transmits a sensing signal to the target UE and receives a sensing response signal from the target UE. The terms “sensing signal” and “sensing response signal” or the more general “sensing-related signals” are used herein as general terms that encompass any signals that communicate information used to support the sensing function. The sensing-related signals may be PHY signals that include signal components that are optimized for sensing as compared to communication such as frequency-modulated continuous wave (FMCW) “chirp” signals. The sensing-related signals may carry measurement or computation results such as angle of arrival (AoA) or ranging related information. The sensing-related signals may include components carrying configuration information such as timing information for a particular sensing session. Sensing-related signals may be hybrid signals that carry sensing-related components as well as communication related components.

[0037] FIG. 2B illustrates a communication network 250 in that includes a TX device 220-1 that transmits a sensing signal to the target UE 210 and a different RX SN device 220-2 that receives a sensing response signal from the target UE 210. The TX device 220-1 and / or the RX SN device 220-2 may be different transmit / receive points (TRPs) associated with the same or different base stations. In this case, the TX device 220-1 and / or the RX device 220-2may include components that implement the SF-U. The TX device 220-1 and / or the RX SN device 220-2 may be a user device (e.g., a UE) that communicates with the CN by way of a RAN node. In this case, the TX device 220-1 and / or the RX SN device 220-2 will provide data to an SF-U implemented in a RAN node to which the TX device 220-1 and / or the RX SN device 220-2 is connected.

[0038] The potential presence of eavesdropper devices raises several security concerns in both the network 200 of FIG. 2A and the network 250 of FIG. 2B . For example, while the sensing network should be able to detect the presence of the eavesdropper devices, the eavesdropper devices should not be able to receive information in the sensing signal intended for the target UE 210. An eavesdropper device may be closer to the TX / RX SN device 220 or TX SN device 220-1 than the target UE 210 and thus the sensing signal may have significant  strength in the proximity of the eavesdropper device. Similarly, the sensing response signal may have significant strength in the proximity of an eavesdropper device. Further, a malicious eavesdropper device may transmit an unauthorized sensing response signal that is received by the TX / RX SN device 220 or RX SN device 220-2. If the TX / RX SN device 220 or RX SN device 220-2 mistakes the unauthorized sensing response signal for a sensing response signal from the target UE the performance of the sensing function with respect to the target UE 210 may be degraded.

[0039] Described herein are systems, methods, and circuitries that provide techniques for enhancing the security of sensing-related signals. For example, techniques are provided for generating a sensing function-related token (herein “TS” ) associated with a particular target UE. The TS may be carried by sensing-related signals between the sensing network and the target UE. In this manner, an eavesdropper device may be prevented from receiving or decoding a sensing-related signal and an eavesdropper device is prevented from generating signals that mimic sensing-related signals transmitted to or received from the target UE. The sensing-related signals may carry or include the TS in many different ways. For example, the sensing-related signals may be manipulated in the physical layer based on the TS (e.g., scrambled, modulated, or encoded based on the TS) .

[0040] The TS may be generated based on an input key, called KSHARE herein, which may be derived in several ways. For example, KSHARE may be generated by an authentication and key management (AKA) or extensible authentication protocol (EAP) -AKA’ process, a physical layer key (KPHY) derived between a UE and RAN node between which an secure AS connection has been made, a sidelink related key (KNRP) , a sensing function-based key KSHARE_SF that is derived between a sensing network device and a target UE based on authentication by the sensing function, and so on.

[0041] AKA / EAP-AKA’ Related Keys

[0042] In some examples, KSHARE used to generate TS is a key derived during a fifth generation system (5GS) authentication and key management (AKA) or extensible authentication protocol (EAP) -AKA’ process. The keys related to authentication in these processes are a root key K and cipher key / integrity key (CK / IK) . In case of EAPAKA', the keys CK', IK' are derived from CK, IK. FIG. 3 illustrates an example key generation hierarchy 300 of network devices. The key generation outlined in FIG. 3 is performed when a UE is registered to the network.

[0043] The key generation hierarchy 300 includes a network side 302 (which corresponds to a base station and / or a core network) and a user equipment (UE) side 304 (which corresponds to a UE) . The key generation hierarchy 300 further includes a home public land mobile network  (HPLMN) portion 306 and a serving network portion 308. Keys illustrated in the key generation hierarchy 300 in the HPLMN portion 306 may be keys utilized between the UE and an HPLMN serving the UE. Keys illustrated in the key generation hierarchy 300 in the serving network portion 308 may be keys utilized between the UE and a serving network serving the UE. The key generation hierarchy includes a key for “Authentication Server Function” (KAUSF) in a home network, that is derived by CK’ and IK. ’ The key generation hierarchy further includes a KSEAF: Anchor key “Security Anchor Function, ” which is derived by KAUSF. The key generation hierarchy further includes a key for access and mobility management function (AMF) (KAMF) in serving network, which is derived by KSEAF. The key generation hierarchy may further include keys for NAS signaling, including KNASint and KNASenc. The key generation hierarchy may further include a key for NG-RAN (KgNB) , from which are derived keys for radio resource control (RRC)  / User Plane traffic for encryption or integrity, including KRRCint, KRRCenc, KUPint and KUPenc.

[0044] The key generation hierarchy 300 uses as its input a root key (K) that is stored in a USIM and known by the HPLMN. A CK and an IK is derived from the K. A KAUSF is derived from the CK and the IK. Further, a KSEAF is derived from the KAUSF. A KN3IWF, a KgNB, NH, a KNASint, and a KNASenc are derived from the KAMF. A KRRCint, a KRRCenc, a KUPint, and a KUPenc are derived from the KgNB, NH. In some examples, the key KgNB or a different key generated during the key generation hierarchy 300 is used as KSHARE for deriving TS as will be described in more detail below.

[0045] PHY Layer Key (KPHY)

[0046] FIGs. 4 and 5 illustrate procedures that may be used to establish a physical layer key (KPHY) between two network devices, such as a base station and a UE. FIG. 4 illustrates an example access stratum (AS) security mode command procedure 400 in accordance with some embodiments that may be performed based on KgNB to establish security between a base station and a UE . In particular, FIG. 4 illustrates example security architecture and procedures for a fifth generation (5G) system.

[0047] When a UE registers to a network, the UE first establishes security with the CN using a NAS security mode command procedure. After the NAS security mode command procedure is complete, the AMF activates the NAS integrity protection in 406 before sending an AS security mode command message. For example, the base station may start a radio resource control (RRC) integrity protection operation at 406.

[0048] At 408 an AS security mode command message is sent from the base station to the UE. The AS security mode command message 408 may contain selected RRC and user plane (UP) encryption and integrity algorithms and a physical layer security policy. This AS security  mode command message 408 may be integrity protected with RRC integrity key based on the base station key (KgNB) .

[0049] At 412, the base station activates the RAN downlink ciphering after sending the AS security mode command message 408. For example, the base station may start RRC downlink ciphering in 412.

[0050] The UE verifies the integrity protection of the AS security mode command message 408 using KgNB in 410. For example, the UE may verify AS security mode command (SMC) integrity in 410. If the verification is successful, the UE may start RRC integrity protection and RRC downlink deciphering.

[0051] The UE transmits an AS security mode complete message 414 to the base station 404. The AS security mode complete message 414 serves as an ACK / NACK with respect to the AS security mode command, including the physical layer security policy indicated in the AS security mode command. The AS security mode complete message may be integrity protected with the selected RRC algorithm indicated in the AS security mode command message 408 and an RRC integrity key based on KgNB. The UE starts RRC uplink ciphering in 416 and the base station starts RRC uplink deciphering at 417.

[0052] Once the security mode command procedure is complete, and a secure connection has been established between the UE and the base station, a physical layer key (KPHY) may be generated by the UE and base station. FIG. 5 outlines an example procedure for generating a physical layer key (KPHY) which may be performed after the AS security mode complete message is transmitted and UL ciphering by the UE and deciphering by the base station is begun as illustrated in FIG. 4.

[0053] At 518 the base station sends a configuration of physical layer key generation message to the UE. The contents of the configuration may include configuration of downlink reference signal, configuration of uplink reference signal, and / or configuration of physical layer key generation. A container of the configuration may be a dedicated RRC message.

[0054] At 520 the UE sends ACK of the configuration message to the base station. It is possible that the UE may send a modified configuration with base station (e.g., modifying the periodicity of downlink (DL)  / uplink (UL) reference signals) .

[0055] The procedure 500 may include a number of DL / UL reference signal transmissions based on the configuration transmitted at 518. At 522 a first DL reference signal transmission occurs and at 524 a first UL reference signal transmission occurs. At 526 a final DL reference signal transmission occurs and at 528 a final UL reference signal transmission occurs. The DL / UL reference signal transmissions may be paired transmissions, where one DL reference signal transmission has the corresponding UL reference signal transmission. It is possible that a  DL reference signal is transmitted before or after a UL reference signal, depending on the configuration of DL / UL reference signal. It is possible DL / UL reference signals are periodic, with or without ON / OFF duration.

[0056] In 530, the UE may collect measurement results. At 532, the base station may collect measurement results.

[0057] The procedure 500 may include synchronization for physical layer key generation. At 534 synchronization for physical layer key generation messages may be transmitted from the UE to base station and / or from base station to UE. In the illustrated example, the synchronization for physical layer key generation message 534 is transmitted from the UE to the base station. This message may be triggered when a certain number of DL / UL reference signal transmissions have occurred depending on configuration.

[0058] Contents of the synchronization for physical layer key generation message 534 may include a bitmap of length being the number of DL (or UL) reference signal transmissions from the previous synchronization message or from the beginning of the DL reference signal transmissions. The bitmap may include a bit of ‘0’ that indicates the corresponding DL (or UL) reference signal measurement is successful or reliable, or a bit of ‘1’ that indicates the corresponding DL (or UL) reference signal measurement is unsuccessful or not reliable. In a first alternative, a container for the physical layer key generation message 634 may include a medium access control (MAC) control element (CE) . The length of the MAC CE may be limited. In a second alternative, a container for the physical layer key generation message 534 may include a dedicated RRC message.

[0059] At 536, the UE may proceed with the measurement results. At 538, the base station may proceed with the measurement results.

[0060] The procedure 500 may use assistant information for physical layer key generation. At 540 assistant information can be transmitted either from the UE to the base station or from the base station to the UE, depending on the configuration transmitted at 518. Contents of the assistant information may include cyclic redundancy check (CRC) bits of polar codes or syndrome bits of low-density parity-check (LDPC) codes, and / or quantization error bits. A container for the assistant information for physical layer key generation message may be a MAC CE in a first alternative or a dedicated RRC message in a second alternative.

[0061] At 542, the UE may proceed with KPHY generation. At 544, base station may proceed with KPHY generation.

[0062] The procedure 500 may include alignment of the physical layer key KPHY. At 546 an alignment of physical layer key message may be transmitted from the UE to the base station and the base station may send ACK or NACK for the alignment results. Alternatively, the  alignment of physical layer key message may be transmitted by the base station to the UE, and the UE may send ACK or NACK for the alignment results. The contents of the alignment of physical layer key message may include a bit sequence which is derived from the physical layer key. The container of the alignment of physical layer key message may be a MAC CE in a first alternative or a dedicated RRC message in a second alternative.

[0063] Approaches herein may include one or more of the following features for the configuration of the physical layer key generation. For example, the following features may be included in a configuration of the configuration of physical layer key generation message 518. The base station may send configuration of physical layer key generation to the UE.

[0064] The configuration of physical layer key generation may include configuration of downlink reference signal. The configuration of downlink reference signal may include a type of downlink reference signal to be utilized for synchronization. In a first alternative, the type of downlink reference signal may be channel state information-reference signal (CSI-RS) (e.g., periodical CSI-RS, semi-persistent CSI-RS) . In a second alternative, the type of downlink reference signal may be a new reference signal for measurements. In a third alternative, the type of downlink reference signal may be a synchronization signal block (SSB) . For these reference signals, channel state information (CSI) feedback may not be necessary.

[0065] The configuration of physical layer key generation may include downlink reference signal time domain resources to be utilized for synchronization.

[0066] In a first alternative (which may be referred to as “Alt A-1” ) , the downlink reference signal time domain resources may include periodic downlink (DL) reference signals. The periodicity of the periodic DL reference signals may depend on wireless channel condition, such as the periodicity may be larger than the channel coherence time and / or the periodicity may depend on the base station’s estimation of channel coherence time or may depend on the UE’s report on channel coherence time. The indication of the periodic DL reference signals may include slots with the DL reference signal (e.g., periodicity and offset) , symbols with the DL reference signal, and / or a starting time of the periodic DL reference signal.

[0067] In a second alternative (which may be referred to as “Alt A-2” ) , the downlink reference signal time domain resources may include periodic DL reference signals with activation and deactivation.

[0068] In a third alternative (which may be referred to as “Alt B-1” ) , the downlink reference signal time domain resources may include intermittent DL reference signals. The intermittent DL reference signals may be implemented for the purpose of power saving and matching secret key refreshing rate. The indication of the intermittent DL reference signals may include ON duration and OFF duration with DL reference signal transmissions.

[0069] In a fourth alternative (which may be referred to as “Alt B-2” ) , the downlink reference signal time domain resources may include intermittent DL reference signal with activation and deactivation.

[0070] The configuration of physical layer key generation may include configuration of uplink reference signal. The configuration of uplink reference signal may include a type of uplink reference signal to be utilized for synchronization. In a first alternative, the type of uplink reference signal may be semi-persistent (SPS) (e.g., periodical SPS, semi-persistent SPS) . In a second alternative, the type of uplink reference signal may be a new reference signal for measurements.

[0071] The configuration of physical layer key generation may include uplink reference signal time domain resources to be utilized for synchronization.

[0072] In a first alternative (which may be referred to as “Alt A-1” ) , the uplink reference signal time domain resources may include periodic UL reference signals. The indication of the uplink reference signal time domain reference signals may include slots with uplink (UL) reference signal (e.g., periodicity and offset) , symbols with UL reference signal, and / or a starting time of periodic UL reference signal.

[0073] In a second alternative (which may be referred to as “Alt A-2” ) , the uplink reference signal time domain resources may include periodic UL reference signal with activation and deactivation.

[0074] In a third alternative (which may be referred to as “Alt B-1” ) , the uplink reference signal time domain resources may include intermittent UL reference signals. The intermittent UL references signals may be implemented for the purpose of power saving and matching secret key refreshing rate. The indication of the intermittent UL reference signals may include ON duration and OFF duration with UL reference signal transmissions.

[0075] In a fourth alternative (which may be referred to as “Alt B-2” ) , the uplink reference signal time domain resources may include intermittent UL reference signals with activation and deactivation.

[0076] The configuration of physical layer key generation may include linkage between UL reference signals and DL reference signals. The periodicity of UL reference signal may be equal to periodicity of DL reference signal. The ON duration and OFF duration for UL reference signal transmissions may equal to those for DL reference signal transmissions. Small offset may be possible between the UL ON duration and the DL ON duration. Time gap between the UL reference signal and the DL reference signal may be small enough, such as at least less than half of the channel coherence time.

[0077] The configuration of physical layer key generation may include error correction  codes and / or error correction code information for the error correction codes. The error correction code information may include quantization information, such as the number of bits to be extracted from each channel estimation.

[0078] The error correction code information may include a type of error correction codes. In a first alternative, the type of error correction codes may be polar code. For the first alternative, the error correction codes can be the same or different from the channel codes used for control channel. In a second alternative, the type of error correction codes may be low-density parity-check (LDPC) code. For the second alternative, the error correction codes can be the same or different from the channel codes used for data channel. The configuration between polar code and LDPC code may depend on UE capability report.

[0079] The error correction code information may include block length, code rate, and / or rate matching schemes of error correction codes. Alternatively, the block length, code rate and rate matching schemes can be pre-defined. The block length of error correction codes may be used to determine the triggering of synchronization of physical layer key generation.

[0080] The configuration of physical layer key generation may include assistance information for physical layer key generation. The assistance information may include a transmitter of the assistance information (i.e., from the base station or from the UE) , a number of quantization error bits, and / or a number of syndrome bits or cyclic redundancy check (CRC) bits.

[0081] The configuration of physical layer key generation may include a universal hashing function for key generation. The universal hashing function may include a ratio of universal hashing including the number of input bits and the number of output bits.

[0082] The configuration of physical layer key generation may include key verification information. The key verification information may include number and location of the key bits used for verification purpose.

[0083] The physical layer key KPHY may be used as KSHARE for deriving TS as will be described in more detail below.

[0084] Sidelink key (KNRP)

[0085] When two UEs are exchanging sensing-related signals using sidelink communication, KSHARE for determining the TS may be a sidelink key. In one example, the sidelink key is KNRP, which may be derived according the example process 600 outlined in FIG. 6. This process may be used to secure a PC5 unicast link between UE1 and UE2. At each step of the process, Key_Est_Info contains the different data that is used for key establishment. Such data is transparent to the PC5 layer (i.e., the PC5 layer does not need to understand the content of Key_Est_Info) . The process 600 may be used to establish an initial key or perform re-keying. When UE1 determines that it needs to establish a PC5 connection with another UE, UE1  sends the Direct Communication Request message at 610 and this message is received by UE2. In case of re-keying an existing connection with UE2, UE1 sends a Direct Re-Keying Request message to UE2 at 610. The Direct Communication Request message includes the Key_Est_Info unless UE1’s signaling integrity policy is not needed. In the former case the message transmitted at 610 may include Key_Est_Info. The Direct Re-Keying Request message includes Key_Est_Info unless the Null integrity algorithm is currently in use.

[0086] At 620 and 625, optional messages may be exchanged multiple times depending on the authentication method used. At 620, UE2 sends a Direct Authentication and Key Establishment message including Key_Est_Info to UE1. At 625, UE1 responds with a Direct Authentication and Key Establishment Response message including the Key_Est_Info to UE2.

[0087] When UE2 decides to activate unicast signaling protection, UE2 calculates KNRP. At 630 UE2 transmits a Direct Security Mode Command message to UE1. These messages include Key_Est_Info if needed by the authentication method being used and contain the MSB of a KNRP ID corresponding to the calculated KNRP unless the Null integrity algorithm is selected by UE2. The MSB of the KNRP ID are chosen so that they uniquely identify KRNP at UE2.

[0088] On receiving the Direct Security Mode Command, UE1 calculates KNRP based on Key_Est_Info (if provided) . Unless the Null integrity algorithm is selected by UE2, UE1 chooses the LSB of KNRP ID so that the LSB uniquely identify KNRP at UE1. UE1 forms a KNRP ID based on the MSB of the KNRP ID received from UE2 and its chosen LSB and stores the complete KNRP ID with KNRP. At 640, UE1 sends a Direct Security Mode Complete message to UE2 that contains the LSB of the KNRP ID. UE2 forms a KNRP ID with its chosen MSB and the received LSB and stores the complete KNRP ID with KNRP. This sidelink key KNRP and / or KNRP ID may be used as sidelink-related input key to generate TS as will described below.

[0089] Sensing Function-Based Key (KSHARE_SF)

[0090] A new sensing function-based key derivation process may be supported by wireless devices that are providing or receiving sensing services. FIG. 7A is a message flow diagram outlining a process 700 by which a sensing network (SN) device (e.g., a TRP or UE providing SF-U functions) and a target UE may negotiate a sensing function-based shared key (KSHARE_SF) that can be used to generate the TS.

[0091] At 710 the SN device and the target UE exchange subscription IDs. The subscription IDs may be mapped to a particular device by the SF-C in the core network. This exchange of subscription IDs may occur when the SN device discovers the target UE and vice versa.

[0092] At 720, the SN device provides the target UE’s subscription ID to the SF-C to  confirm that the target UE is an authenticated UE for the sensing function. At 730, the SF-C confirms or does not confirm that the target UE is authenticated for access to the sensing function. In some instances, the SF-C of the SN device and the SF-C of the target UE may not be the same. To address this possibility, the subscription ID may indicate an associated SF-C so that subscription ID confirmation requests may be routed to the correct SF-C. Dashed line operation 725 indicates the routing of the target UE subscription ID confirmation request between the SF-C of the SN device to the SF-C of the target UE and the transmission of confirmation of the target UE’s subscription ID to the SN device SF-C. In other examples, the confirmation of the target UE’s subscription ID may be performed locally by the SF-U portions of the sensing function in the same manner as illustrated for operations 720, 725, 730.

[0093] In some examples, not shown, the target UE may perform operations similar to operations 720, 725, 730 to authenticate the SN device as a valid sensing function partner prior to participating in a key negotiation process with the SN device at 740.

[0094] At 740, when the sensing function has confirmed the subscription ID of the target UE, the SN device and the target UE negotiate a shared sensing function-based key (KSHARE_SF) known only to these two devices. In some examples, the devices use a Diffie-Hellmann (DH) key negotiation procedure to derive KSHARE_SF. One advantageous feature of the DH process is that neither device knows the underlying key used by the other device to derive the shared key. However, any suitable key derivation process may be used to derive KSHARE_SF based on the trust established by the sensing function’s confirmation of the target UE’s subscription. The sensing function-based key KSHARE_SF may be used as KSHARE to derive the TS as will be described below.

[0095] FIG. 7B is a message flow diagram outlining an alternative process 700’ by which a sensing network (SN) device (e.g., a TRP or UE providing SF-U functions) and a target UE may negotiate a sensing function-based shared key (KSHARE_SF) that can be used to generate the TS.

[0096] At 710 the SN device and the target UE exchange subscription IDs. The subscription IDs may be mapped to a particular device by the SF-C in the core network. This exchange of subscription IDs may occur when the SN device discovers the target UE and vice versa.

[0097] At 720, the SN device provides the target UE’s subscription ID to the SF-C to confirm that the target UE is an authenticated UE for the sensing function and request KSHARE_SF for the target UE. At 750, the SF of the SN device and the SF of the target UE negotiate KSHARE_SF.

[0098] At 760, the sensing function of the target UE transmits KSHARE_SF to the target UE in a protected message. At 770, the sensing function of the SN device transmits  KSHARE_SF to the SN device in a protected message. The sensing function-based key KSHARE_SF may be used as KSHARE to derive the TS as will be described below.

[0099] Token-Based Secure Sensing-Related Signals in Bi-Static Mode

[0100] Referring briefly back to FIG. 2B, recall that bi-static sensing mode refers to the scenario in which one SN device (TX SN Device 220-1) transmits sensing signals to the target UE and another SN device (RX SN device 220-2) selectively receives sensing response signals from the target UE. Sensing signals and sensing response signals and any other signals or messages that carry information related to a sensing function or sensing services may be referred to collectively as “sensing-related signals” .

[0101] FIG. 8 illustrates one example technique that may be used to secure sensing-related signals in a bi-static sensing mode using a sensing-related token. At 810, an authenticating SN device authenticates the target UE. During or after authentication, the authenticating SN device and the target UE generate KSHARE according to any of the processes described above with reference to FIGs. 3-7B. For example, KSHARE may be KGNB, KPHY, KNRP, or KSHARE_SF. It is noted that the authenticating SN may be either the TX SN device or the RX SN device. Both options are described in more detail below.

[0102] At 830, the authenticating SN device and the target UE generate a TS based on KSHARE. The TS may be derived based on KSHARE according to any one of many suitable techniques. For example, the TS may be derived based on a HASH function of KSHARE. The TS may be derived based on a HASH function of a subscription ID of the target UE that is performed based on KSHARE. The TS may be derived by encrypting the subscription ID of the target UE based on KSHARE. In some examples, TS may be the same as KSHARE (e.g., the function used to generate TS from the input key may be “=” ) .

[0103] After the sensing token for the target UE has been generated, sensing-related signals (e.g., sensing response signals) transmitted from the target UE to the RX SN device may be secured based on the sensing token. At 850 the target UE transmits, to the RX SN device, sensing-related signals that carry the TS (e.g., by coding, modulation, and so on) . It is noted that the RX SN device may be the same SN device as the authenticating SN device. In other words, the RX SN device may have generated KSHARE and the TS with the target UE at 810 and 830 and as such is in possession of the TS.

[0104] As will be described below, in some examples, the TX SN device serves as the authenticating SN device and in these cases the TX SN device may provide the TS to the RX SN device or the sensing function or verify a TS generated by the RX SN device and the target UE.

[0105] At 865 the RX SN device selectively receives sensing-related signals based on the TS. This may mean that the RX SN device is unable to receive or decode a sensing-related  signal that does not carry the TS generated at 830 or that the RX SN device rejects (e.g., refrains from processing) sensing-related signals that do not carry the TS generated at 830. The sensing-related signals are thus secured based on TS and the sensing function is protected from unauthorized access by a non-subscribing or otherwise unauthenticated UE.

[0106] Bi-Static Sensing Authentication Techniques-TX SN Device as Authenticating SN Device

[0107] FIG. 9 illustrates one example technique that may be used to generate a TS for securing sensing-related signals when the TX SN device (e.g., 220-1 of FIG. 2B) in a bi-static sensing mode acts as the authenticating SN device. The TX SN device may be either a TRP (denoted TRP1) or a UE (denoted UE1) . Likewise, the RX SN device may be either a TRP (denoted TRP2) or a UE (denoted UE2) . Differences in the solutions based on whether the TX RN device or the RX SN device is a TRP or a UE will be noted.

[0108] At 905, the TX SN device transmits a sensing-related signal to the target UE. The sensing related signal may include an identifier for the TX SN device, such as, for example, a TRP ID or UE ID. At 910, the TX SN device performs an authentication procedure with the target UE and the TX SN device and the target UE identify or generate KSHARE.

[0109] For example, when the TX SN device is a TRP (TRP1) , the may check whether the TRP has established access stratum security mode command-based authentication (AS SMC) with the target UE. Example processes for establishing AS SMC are outlined in FIGs. 3 and 4. Recall that several AKA / EAP-AKA’ related keys are established prior to the establishment of AS SMC. For example, KGNB is established between the TRP1 and the UE prior to establishment of AS SMC. Thus, if the TRP has established AS SMC with the target UE, the TRP will be in possession of at least one AKA / EAP-AKA’ related key with the target UE, for example, KGNB. If TRP1 has not established AS SMC with the target UE, TRP1 may trigger the target UE to start a registration request with the AMF. One example of the registration request process is outlined in 3GPP TS 33.501 clause 6.1.1. Alternatively, TRP1 may send notification to the AMF to trigger a primary authentication process with the target UE. One example of the primary authentication process is outlined in 3GPP TS 33.501 clause 6.1.3. As a result of registration process or the primary authentication process TRP1 and the target UE will be in possession of at least one AKA / EAP-AKA’ related key with the target UE, for example, KGNB. This key, KGNB, may be used as KSHARE.

[0110] In other examples, the TX SN device (UE1 or TRP1) may check to see if the TX SN device has already established a physical layer key with the target UE. One example of a physical layer key is KPHY. If the TX SN device has not already established KPHY with the target UE, then TX SN device and the target UE may generate KPHY, for example, as outlined with reference to FIG. 5. KPHY may be used as KSHARE.

[0111] If the TX SN device is a UE (UE1) , UE1 may check to see if UE1 has already established a sidelink key with the target UE. One example of a sidelink key is KNRP or KNRP ID. If UE1 has not already established a sidelink key with the target UE, then the TX SN device and the target UE may generate a sidelink key, for example, as outlined with reference to FIG. 6. The sidelink key or KNRP may be used as KSHARE.

[0112] In other examples, the TX SN device (UE1 or TRP1) may check to see if the TX SN device has already established a sensing function-related key (e.g., KSHARE_SF) with the target UE. If the TX SN device has not already established a sensing function-related key with the target UE, then the TX SN device and the target UE may generate a sensing function-related key for example, by deriving KSHARE_SF as outlined with reference to FIG. 7A or 7B. KSHARE_SF may be used as KSHARE.

[0113] At 930, the TX SN device and the target UE generate a TS based on input key established at 910. The TS may be derived based on KSHARE according to any one of many suitable techniques. For example, the TS may be derived based on a HASH function of KSHARE. The TS may be derived based on a HASH function of a subscription ID of the target UE that is performed based on KSHARE. The TS may be derived by encrypting the subscription ID of the target UE based on KSHARE. In some examples, TS may be the same as KSHARE (e.g., the function used to generate TS from the input key may be “=” ) .

[0114] At 950 the target UE transmits a sensing-related signal that carries the TS to the RX SN device (e.g., by coding, modulation, or indicated in a special sensing-related signal message, and so on) . The sensing-related signal transmitted at 950 includes an identifier of the TX SN device (e.g., UE1 ID or TRP1 ID) , an ID of the target UE, and the sensing token (TS) generated at 930. At 960, the RX SN device transmits a verification request message to the TX SN device based on the TX SN device ID included in the sensing-related signal received at 950. The verification request message indicates the target UE ID and TS. At 965, if the target UE is authenticated and associated with the TS provided in the verification request, the TX SN device transmits a verification response message that includes the TS generated at 930 which matches the TS included in the verification request message. When the TX SN device is a TRP (TRP1) , messages transmitted at 950 and 955 may be protected Xn messages. When the TX SN device is a UE (UE1) , messages transmitted at 950 and 955 may be protected Uu messages.

[0115] At 968, the RX SN accepts the sensing-related signal received at 950 and stores the TS for the target UE for use in receiving sensing-related signals from the target UE. The RX SN device may process information received in the sensing-related signal for providing sensing services to the target UE and / or provide the information to an SF-C.

[0116] After TS has been established for the target UE, at 970 the TX SN device may  transmit sensing-related signals to the target UE that carry the TS. At 975 the target UE may selectively receive sensing signals based on the TS. This may mean that the target UE is unable to receive or decode a sensing-related signal that does not carry the TS generated at 930 or that the target UE rejects (e.g., refrains from processing) sensing-related signals that do not carry the TS generated at 930. In this manner, the target UE is protected from malicious or superfluous sensing signals. In other examples, the sensing-related signals transmitted by the TX SN are not secured with TS (e.g., do not carry TS) and only the RX SN device checks for TS in received sensing-related signals.

[0117] At 980 the target UE transmits sensing-related signals (e.g., sensing response signals) that carry the TS. At 985 the RX SN device selectively receives sensing-related signals based on the TS. This may mean that the RX SN device is unable to receive or decode a sensing-related signal that does not carry the TS generated at 930 or that the RX SN device rejects (e.g., refrains from processing) sensing-related signals that do not carry the TS generated at 930. The sensing-related signals are thus secured based on TS and the sensing function is protected from unauthorized access by a non-subscribing or otherwise unauthenticated UE.

[0118] Bi-Static Sensing Authentication Techniques-RX SN Device as Authenticating SN Device

[0119] FIG. 10 illustrates one example technique that may be used to generate a TS for securing sensing-related signals when the RX SN device (e.g., 220-2 of FIG. 2B) in a bi-static sensing mode acts as the authenticating SN device. The TX SN device may be either a TRP (denoted TRP1) or a UE (denoted UE1) . Likewise, the RX SN device may be either a TRP (denoted TRP2) or a UE (denoted UE2) . Differences in the solutions based on whether the TX RN device or the RX SN device is a TRP or a UE will be noted.

[0120] At 1005, the TX SN device transmits a sensing-related signal to the target ID. The sensing-related signal may include an identifier for the SN device, such as, for example, a TRP ID or UE ID. It is noted that the sensing-related signal transmitted at 1005 may be received by any proximate UE. Thus, the sensing-related signal may be a general sensing-related signal that is not intended for a specific target UE such as a positioning reference signal.

[0121] In response, at 1008, the target UE transmits a sensing-related signal to the RX SN device. The sensing-related signal transmitted at 1008 includes the TX SN ID and the target UE ID. At 1010, the RX SN device performs an authentication procedure with the target UE and the RX SN device and the target UE identify or generate KSHARE.

[0122] For example, when the RX SN device is a TRP (TRP2) , the may check whether TRP2 has established access stratum security mode command-based authentication (AS SMC) with the target UE. Example processes for establishing AS SMC are outlined in FIGs. 3 and 4. Recall that several AKA / EAP-AKA’ related keys are established prior to the establishment of  AS SMC. For example, KGNB is established between the TRP2 and the target UE prior to establishment of AS SMC. Thus, if TRP2 has established AS SMC with the target UE, TRP2 will be in possession of at least one AKA / EAP-AKA’ related key with the target UE, for example, KGNB. If TRP2 has not established AS SMC with the target UE, TRP2 may trigger the target UE to start a registration request with the AMF. One example of the registration request process is outlined in 3GPP TS 33.501 clause 6.1.1. Alternatively, TRP2 may send notification to the AMF to trigger a primary authentication process with the target UE. One example of the primary authentication process is outlined in 3GPP TS 33.501 clause 6.1.3. As a result of registration process or the primary authentication process TRP2 and the target UE will be in possession of at least one AKA / EAP-AKA’ related key with the target UE, for example, KGNB. This key, KGNB, may be used as KSHARE.

[0123] In other examples, the RX SN device (UE2or TRP2) may check to see if the RX SN device has already established a physical layer key with the target UE. One example of a physical layer key is KPHY. If the RX SN device has not already established KPHY with the target UE, then the RX SN device and the target UE may generate KPHY, for example, as outlined with reference to FIG. 5. KPHY may be used as KSHARE.

[0124] If the RX SN device is a UE (UE2) , UE2 may check to see if UE2 has already established a sidelink key with the target UE. One example of a sidelink key is KNRP. If UE2 has not already established a sidelink key with the target UE, then UE2 and the target UE may generate a sidelink key, for example, as outlined with reference to FIG. 6. The sidelink key or KNRP may be used as KSHARE.

[0125] In other examples, the RX SN device (UE2 or TRP2) may check to see if the RX SN device has already established a sensing function-related key (e.g., KSHARE_SF) with the target UE. If the RX SN device has not already established a sensing function-related key with the target UE, then the RX SN device and the target UE may generate a sensing function-related key for example, by deriving KSHARE_SF as outlined with reference to FIG. 7A or 7B. KSHARE_SF may be used as KSHARE.

[0126] At 1030, the RX SN device and the target UE generate a TS based on input key established at 1010. The TS may be derived based on KSHARE according to any one of many suitable techniques. For example, the TS may be derived based on a HASH function of KSHARE. The TS may be derived based on a HASH function of a subscription ID of the target UE that is performed based on KSHARE. The TS may be derived by encrypting the subscription ID of the target UE based on KSHARE. In some examples, TS may be the same as KSHARE (e.g., the function used to generate TS from the input key may be “=” ) .

[0127] At 1068, the RX SN accepts the sensing-related signal received at 1008 and stores  the TS for the target UE for use in receiving sensing-related signals from the target UE. The RX SN device may process information received in the sensing-related signal for providing sensing services to the target UE and / or provide the information to an SF-C.

[0128] After TS has been established for the target UE, at 1070 the TX SN device may transmit sensing-related signals to the target UE. Theses sensing-related signals need not carry the TS.

[0129] At 1080 the target UE transmits sensing-related signals (e.g., sensing response signals) that carry the TS to the RX SN device. At 1085 the RX SN device selectively receives sensing-related signals based on the TS. This may mean that the RX SN device is unable to receive or decode a sensing-related signal that does not carry the TS generated at 1030 or that the RX SN device rejects (e.g., refrains from processing) sensing-related signals that do not carry the TS generated at 1030. The sensing-related signals are thus secured based on TS and the sensing function is protected from unauthorized access by a non-subscribing or otherwise unauthenticated UE.

[0130] FIG. 11 is a flow diagram outlining an example method 1100 for securing a sensing-related signal. The method 1100 may be performed, for example, by an RX SN device of FIGs. 8-10. The sensing-related signal may be transmitted from a target UE to an RX SN device 220-2 as illustrated in FIG. 2B. The TX SN device may be, for example, a TRP or UE that implements a sensing function that provides sensing services to the target UE. The sensing-related signal may be, for example, sensing response signal, as outlined with reference to FIG. 2B.

[0131] The method includes, at 1110, identifying a sensing token associated with a target UE. The identifying may be performed by, for example, reading memory that stores sensing tokens mapped to target UEs. The identifying may include checking to see whether a sensing token is stored for the target UE and, when no sensing token is found, determining a sensing token according to any of the techniques disclosed herein.

[0132] At 1120, the method includes selectively receiving a sensing-related signal that carries the sensing token. The sensing-related signal may carry the sensing token by way of scrambling, encoding, modulating, and so on. Selectively receiving may include, for example, being unable to or refraining from receiving or processing a received sensing-related signal that does not carry the sensing token.

[0133] In some examples, as illustrated in FIG. 10, the method includes deriving the sensing token based on KSHARE. The method may include receiving KSHARE from a sensing function (e.g., KSHARE_SF as illustrated in FIG. 13) . Alternatively, the method may include generating KSHARE based on an AKA / EAP-AKA’-related key (e.g., KGNB as illustrated in FIGs. 3 and 4) or a sidelink-related key shared between a SN device and the target UE (e.g., KNRP or KNRP  ID as illustrated in FIG. 6) . The method may include deriving a physical layer key based on reference signals exchanged between the sensing network device and the target UE (e.g., KPHY as illustrated in FIG. 5. The method may include deriving a sensing function-related key (e.g., KSHARE_SF as illustrated in FIGs. 7A and 7B) .

[0134] In some examples, as illustrated in FIG. 9, the method 1100 includes receiving indication of the sensing token, target UE ID, and a SN device ID from the target UE. The method also includes transmitting a verification request message to a SN device based on the SN device ID. The verification request message indicates the sensing token and the target UE ID. In response to receiving a verification response message from the SN device, the sensing token is identified as being associated with the target UE. The method may include transmitting the verification request message or receiving the verification response message by way of a protected Uu message or a protected Xn message.

[0135] FIG. 12 is a flow diagram outlining an example method 1200 for securing a sensing-related signal. The method 1200 may be performed, for example, by a TX SN device of FIGs. 8-10. The sensing-related signal may be transmitted from the TX SN device 220-1 to a target UE as illustrated in FIG. 2B. The TX SN device may be, for example, a TRP or UE that implements a sensing function that provides sensing services to the target UE. The sensing-related signal may be, for example, sensing signal, as outlined with reference to FIG. 2B.

[0136] The method includes, at 1210, identifying a sensing token associated with a target UE. The identifying may be performed by, for example, reading memory that stores sensing tokens mapped to target UEs. The identifying may include checking to see whether a sensing token is stored for the target UE and, when no sensing token is found, determining a sensing token according to any of the techniques disclosed herein.

[0137] At 1220, the method includes transmitting a sensing-related signal that carries the sensing token. The sensing-related signal may carry the sensing token by way of scrambling, encoding, modulating, and so on.

[0138] In some examples, as illustrated in FIG. 10, the method includes deriving the sensing token based on KSHARE. The method may include receiving KSHARE from a sensing function (e.g., KSHARE_SF as illustrated in FIG. 13) . Alternatively, the method may include generating KSHARE based on an AKA / EAP-AKA’-related key (e.g., KGNB as illustrated in FIGs. 3 and 4) or a sidelink-related key shared between a SN device and the target UE (e.g., KNRP or KNRP ID as illustrated in FIG. 6) . The method may include deriving a physical layer key based on reference signals exchanged between the sensing network device and the target UE (e.g., KPHY as illustrated in FIG. 5. The method may include deriving a sensing function-related key (e.g., KSHARE_SF as illustrated in FIGs. 7A and 7B) .

[0139] In some examples, as illustrated in FIG. 9, the method 1200 includes first transmitting a SN device ID of the TX SN device to the target UE. The method also includes receiving a verification request message from an RX SN device. The verification request message indicates the sensing token and the target UE ID. In response to receiving the verification request message, the method may include determining whether the sensing token is associated with the target UE and when the sensing token is associated with the target UE, transmitting a verification response message to the RX SN device. The method may include receiving the verification request message or transmitting the verification response message by way of a protected Uu message or a protected Xn message.

[0140] FIG. 13 is a flow diagram outlining an example method 1300 for securing a sensing-related signal. The method 1300 may be performed, for example, by a target UE device of FIGs. 8-10. The sensing-related signal may be transmitted from the target UE to a TX SN device 220-1 as illustrated in FIG. 2B. The RX SN device may be, for example, a TRP or UE that implements a sensing function that provides sensing services to the target UE. The sensing-related signal may be, for example, sensing response signal, as outlined with reference to FIG. 2B.

[0141] The method includes, at 1310, identifying a sensing token associated with a target UE. The identifying may be performed by, for example, reading memory that stores sensing tokens. The identifying may include checking to see whether a sensing token is stored and, when no sensing token is found, determining a sensing token according to any of the techniques disclosed herein.

[0142] At 1320, the method includes transmitting a sensing-related signal that carries the sensing token. The sensing-related signal may carry the sensing token by way of scrambling, encoding, modulating, and so on.

[0143] In some examples, as illustrated in FIG. 10, the method includes deriving the sensing token based on KSHARE that is shared with a TX SN device. The method may include generating KSHARE based on an AKA / EAP-AKA’-related key (e.g., KGNB as illustrated in FIGs. 3 and 4) or a sidelink-related key shared between the TX SN device and the target UE (e.g., KNRP or KNRP ID as illustrated in FIG. 6) . The method may include deriving a physical layer key based on reference signals exchanged between the TX SN device and the target UE (e.g., KPHY as illustrated in FIG. 5. The method may include deriving a sensing function-related key (e.g., KSHARE_SF as illustrated in FIGs. 7A and 7B) .

[0144] The method may include, transmitting an indication of the sensing token, a target UE ID, and a TX SN device ID to the RX SN device.

[0145] Above are several flow diagrams outlining example methods and exchanges of  messages. In this description and the appended claims, use of the term “determine” with reference to some entity (e.g., parameter, variable, and so on) in describing a method step or function is to be construed broadly. For example, “determine” is to be construed to encompass, for example, receiving and parsing a communication that encodes the entity or a value of an entity. “Determine” should be construed to encompass accessing and reading memory (e.g., lookup table, register, device memory, remote memory, and so on) that stores the entity or value for the entity. “Determine” should be construed to encompass computing or deriving the entity or value of the entity based on other quantities or entities. “Determine” should be construed to encompass any manner of deducing or identifying an entity or value of the entity.

[0146] As used herein, the term identify when used with reference to some entity or value of an entity is to be construed broadly as encompassing any manner of determining the entity or value of the entity. For example, the term identify is to be construed to encompass, for example, receiving and parsing a communication that encodes the entity or a value of the entity. The term identify should be construed to encompass accessing and reading memory (e.g., device queue, lookup table, register, device memory, remote memory, and so on) that stores the entity or value for the entity.

[0147] As used herein, the term encode when used with reference to some entity or value of an entity is to be construed broadly as encompassing any manner or technique for generating a data sequence or signal that communicates the entity to another component.

[0148] As used herein, the term select when used with reference to some entity or value of an entity is to be construed broadly as encompassing any manner of determining the entity or value of the entity from amongst a plurality or range of possible choices. For example, the term select is to be construed to encompass accessing and reading memory (e.g., lookup table, register, device memory, remote memory, and so on) that stores the entities or values for the entity and returning one entity or entity value from amongst those stored. The term select is to be construed as applying one or more constraints or rules to an input set of parameters to determine an appropriate entity or entity value. The term select is to be construed as broadly encompassing any manner of choosing an entity based on one or more parameters or conditions.

[0149] As used herein, the term derive when used with reference to some entity or value of an entity is to be construed broadly. “Derive” should be construed to encompass accessing and reading memory (e.g., lookup table, register, device memory, remote memory, and so on) that stores some initial value or foundational values and performing processing and / or logical / mathematical operations on the value or values to generate the derived entity or value for the entity. The term derive should be construed to encompass computing or calculating the entity or value of the entity based on other quantities or entities. The term derive should be  construed to encompass any manner of deducing or identifying an entity or value of the entity.

[0150] As used herein, the term indicate when used with reference to some entity (e.g., parameter or setting) or value of an entity is to be construed broadly as encompassing any manner of communicating the entity or value of the entity either explicitly or implicitly. For example, bits within a transmitted message may be used to explicitly encode an indicated value or may encode an index or other indicator that is mapped to the indicated value by prior configuration. The absence of a field within a message may implicitly indicate a value of an entity based on prior configuration.

[0151] Wireless Network and Device Overview

[0152] FIG. 14 is an example network 1400 according to one or more implementations described herein. Example network 1400 may include UEs 1410-1, 1410-2, etc. (referred to collectively as “UEs 1410” and individually as “UE 1410” ) , a radio access network (RAN) 1420, a core network (CN) 1430, application servers 1440, and external networks 1450. See also target UE 210, TX / RX SN device 220, TX SN device 220-1, and / or RX SN device 220-2 of FIG. 2A and 2B.

[0153] The systems and devices of example network 1400 may operate in accordance with one or more communication standards, such as 2nd generation (2G) , 3rd generation (3G) , 4th generation (4G) (e.g., long-term evolution (LTE) ) , and / or 5th generation (5G) (e.g., new radio (NR) ) communication standards of the 3rd generation partnership project (3GPP) . Additionally, or alternatively, one or more of the systems and devices of example network 1400 may operate in accordance with other communication standards and protocols discussed herein, including future versions or generations of 3GPP standards (e.g., sixth generation (6G) standards, seventh generation (7G) standards, etc. ) , institute of electrical and electronics engineers (IEEE) standards (e.g., wireless metropolitan area network (WMAN) , worldwide interoperability for microwave access (WiMAX) , etc. ) , and more.

[0154] As shown, UEs 1410 may include smartphones (e.g., handheld touchscreen mobile computing devices connectable to one or more wireless communication networks) . Additionally, or alternatively, UEs 1410 may include other types of mobile or non-mobile computing devices capable of wireless communications, such as personal data assistants (PDAs) , pagers, laptop computers, desktop computers, wireless handsets, watches etc. In some implementations, UEs 1410 may include internet of things (IoT) devices (or IoT UEs) that may comprise a network access layer designed for low-power IoT applications utilizing short-lived UE connections. Additionally, or alternatively, an IoT UE may utilize one or more types of technologies, such as machine-to-machine (M2M) communications or machine-type communications (MTC) (e.g., to exchanging data with an MTC server or other device via a public land mobile network (PLMN) ) ,  proximity-based service (ProSe) or device-to-device (D2D) communications, sensor networks, IoT networks, and more. Depending on the scenario, an M2M or MTC exchange of data may be a machine-initiated exchange, and an IoT network may include interconnecting IoT UEs (which may include uniquely identifiable embedded computing devices within an Internet infrastructure) with short-lived connections. In some scenarios, IoT UEs may execute background applications (e.g., keep-alive messages, status updates, etc. ) to facilitate the connections of the IoT network.

[0155] UEs 1410 may communicate with one another via one or more wireless channels 1415, each of which may comprise a physical communications interface  / layer. The connection may include an M2M connection, MTC connection, D2D connection, SL connection, etc. The connection may involve a PC5 interface. In some implementations, UEs 1410 may be configured to discover one another, negotiate wireless resources between one another, and establish connections between one another, without intervention or communications involving RAN node 1422 or another type of network node. In some implementations, discovery, authentication, resource negotiation, registration, etc., may involve communications with RAN node 1422 or another type of network node.

[0156] UEs 1410 may communicate and establish a connection with (e.g., be communicatively coupled) with RAN 1420, which may involve one or more wireless channels 1414-1 and 1414-2, each of which may comprise a physical communications interface  / layer. UEs 1410 may use stored instructions and information that enable the UE 1410 secure sensing-related signals using a sensing token as described above with reference to FIGs. 1-14.

[0157] As shown, UE 1410 may also, or alternatively, connect to access point (AP) 1416 via connection interface 1418, which may include an air interface enabling UE 1410 to communicatively couple with AP 1416. AP 1416 may comprise a wireless local area network (WLAN) , WLAN node, WLAN termination point, etc. The connection 1418 may comprise a local wireless connection, such as a connection consistent with any IEEE 702.11 protocol, and AP 1416 may comprise a wireless fidelity  router or other AP. While not explicitly depicted in FIG. 14, AP 1416 may be connected to another network (e.g., the Internet) without connecting to RAN 1420 or CN 1430.

[0158] RAN 1420 may include one or more RAN nodes 1422-1 and 1422-2 (referred to collectively as RAN nodes 1422, and individually as RAN node 1422 that enable channels 1214-1 and 1214-2 to be established between UEs 1210 and RAN 1220. See also TX / RX SN device 220, TX SN device 220-1, and / or RX SN device 220-2 of FIG. 2A and 2B, which may be RAN nodes 1422.

[0159] RAN nodes 1422 may include network access points configured to provide radio baseband functions for data and / or voice connectivity between users and the network based on  one or more of the communication technologies described herein (e.g., 2G, 3G, 4G, 5G, WiFi, etc. ) . As examples therefore, a RAN node may be an E-UTRAN Node B (e.g., an enhanced Node B, eNodeB, eNB, 4G base station, etc. ) , a next generation base station (e.g., a 5G base station, NR base station, next generation eNBs (gNB) , etc. ) . RAN nodes 1422 may include a roadside unit (RSU) , a transmission reception point (TRxP or TRP) , and one or more other types of ground stations (e.g., terrestrial access points) . In some scenarios, RAN node 1422 may be a dedicated physical device, such as a macrocell base station, and / or a low power (LP) base station for providing femtocells, picocells or the like having smaller coverage areas, smaller user capacity, or higher bandwidth compared to macrocells.

[0160] As described herein, a RAN node (e.g., base station) 1422 may store instructions and information that enable the RAN node to secure sensing-related signals using a sensing token as described above with reference to FIGs. 1-14.

[0161] In some implementations, a downlink resource grid may be used for downlink transmissions from any of the RAN nodes 1422 to UEs 1410, and uplink transmissions may utilize similar techniques. The grid may be a time-frequency grid (e.g., a resource grid or time-frequency resource grid) that represents the physical resource for downlink in each slot. Such a time-frequency plane representation is a common practice for OFDM systems, which makes it intuitive for radio resource allocation. Each column and each row of the resource grid corresponds to one OFDM symbol and one OFDM subcarrier, respectively. The duration of the resource grid in the time domain corresponds to one slot in a radio frame. The smallest time-frequency unit in a resource grid is denoted as a resource element. Each resource grid comprises resource blocks, which describe the mapping of certain physical channels to resource elements. Each resource block may comprise a collection of resource elements (REs) ; in the frequency domain, this may represent the smallest quantity of resources that currently may be allocated. There are several different physical downlink channels that are conveyed using such resource blocks.

[0162] The RAN nodes 1422 may be configured to communicate with one another via interface 1423. In implementations where the system is an LTE system, interface 1423 may be an X2 interface. In NR systems, interface 1423 may be an Xn interface. The X2 interface may be defined between two or more RAN nodes 1422 (e.g., two or more eNBs  / gNBs or a combination thereof) that connect to evolved packet core (EPC) or CN 1430, or between two eNBs connecting to an EPC.

[0163] As shown, RAN 1420 may be connected (e.g., communicatively coupled) to CN 1430. CN 1430 may comprise a plurality of network elements 1432, which are configured to offer various data and telecommunications services to customers / subscribers (e.g., users of UEs  1410) who are connected to the CN 1430 via the RAN 1420. In some implementations, CN 1430 may include an evolved packet core (EPC) , a 5G CN, and / or one or more additional or alternative types of CNs. The components of the CN 1430 may be implemented in one physical node or separate physical nodes including components to read and execute instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) . As described herein, the CN may store instructions and information that enable the CN to provide a sensing function to a target UE as described above with reference to FIGs. 1-14. As shown, CN 1430, application servers 1440, and external networks 1450 may be connected to one another via interfaces 1434, 1436, and 1438, which may include IP network interfaces.

[0164] FIG. 15 is a diagram of an example of components of a network device according to one or more implementations described herein. In some implementations, the device 1500 can include application circuitry 1502, baseband circuitry 1504, RF circuitry 1506, front-end module (FEM) circuitry 1508, one or more antennas 1510, and power management circuitry (PMC) 1512 coupled together at least as shown. The components of the illustrated device 1500 can be included in a UE or a RAN node. In some implementations, the device 1500 can include fewer elements (e.g., a RAN node may not utilize application circuitry 1502, and instead include a processor / controller to process IP data received from a CN or an Evolved Packet Core (EPC) ) . In some implementations, the device 1500 can include additional elements such as, for example, memory / storage, display, camera, sensor (including one or more temperature sensors, such as a single temperature sensor, a plurality of temperature sensors at different locations in device 1500, etc. ) , or input / output (I / O) interface. In other implementations, the components described below can be included in more than one device (e.g., said circuitries can be separately included in more than one device for Cloud-RAN (C-RAN) implementations) .

[0165] The application circuitry 1502 can include one or more application processors. For example, the application circuitry 1502 can include circuitry such as, but not limited to, one or more single-core or multi-core processors. The processor (s) can include any combination of general-purpose processors and dedicated processors (e.g., graphics processors, application processors, etc. ) . The processors can be coupled with or can include memory / storage and can be configured to execute instructions stored in the memory / storage to enable various applications or operating systems to run on the device 1500. In some implementations, processors of application circuitry 1502 can process IP data packets received from an EPC.

[0166] The baseband circuitry 1504 can include circuitry such as, but not limited to, one or more single-core or multi-core processors. The baseband circuitry 1504 can include one or more baseband processors or control logic to process baseband signals received from a receive signal path of the RF circuitry 1506 and to generate baseband signals for a transmit signal path of the  RF circuitry 1506. Baseband circuity 1504 can interface with the application circuitry 1502 for generation and processing of the baseband signals and for controlling operations of the RF circuitry 1506. For example, in some implementations, the baseband circuitry 1504 can include a 3G baseband processor 1504A, a 4G baseband processor 1504B, a 5G baseband processor 1504C, or other baseband processor (s) 1504D for other existing generations, generations in development or to be developed in the future (e.g., 5G, 6G, etc. ) .

[0167] The baseband circuitry 1504 (e.g., one or more of baseband processors 1504A-D) can handle various radio control functions that enable communication with one or more radio networks via the RF circuitry 1506. In other implementations, some or all of the functionality of baseband processors 1504A-D can be included in modules stored in the memory 1504G and executed via a Central Processing Unit (CPU) 1504E. In some implementations, the baseband circuitry 1504 can include one or more audio digital signal processor (s) (DSP) 1504F.

[0168] In some implementations, memory 1504G may store instructions and information that enable the device 1500 to secure sensing-related signals using a sensing token.

[0169] RF circuitry 1506 can enable communication with wireless networks using modulated electromagnetic radiation through a non-solid medium. In various implementations, the RF circuitry 1506 can include switches, filters, amplifiers, etc. to facilitate the communication with the wireless network. RF circuitry 1506 can include a receive signal path which can include circuitry to down-convert RF signals received from the FEM circuitry 1508 and provide baseband signals to the baseband circuitry 1504. RF circuitry 1506 can also include a transmit signal path which can include circuitry to up-convert baseband signals provided by the baseband circuitry 1504 and provide RF output signals to the FEM circuitry 1508 for transmission.

[0170] In some implementations, the receive signal path of the RF circuitry 1506 can include mixer circuitry 1506A, amplifier circuitry 1506B and filter circuitry 1506C. In some implementations, the transmit signal path of the RF circuitry 1506 can include filter circuitry 1506C and mixer circuitry 1506A. RF circuitry 1506 can also include synthesizer circuitry 1506D for synthesizing a frequency for use by the mixer circuitry 1506A of the receive signal path and the transmit signal path.

[0171] Examples herein can include subject matter such as a method, means for performing acts or blocks of the method, at least one machine-readable medium including executable instructions that, when performed by a machine or circuitry (e.g., a processor (e.g., processor , etc. ) with memory, an application-specific integrated circuit (ASIC) , a field programmable gate array (FPGA) , or the like) cause the machine to perform acts of the method or of an apparatus or system for concurrent communication using multiple communication technologies according to  implementations and examples described.

[0172] Examples

[0173] Example 1 is a baseband processor, including a memory configured to store instructions and a processor coupled to the memory and, when executing instructions, configured to identify a sensing token associated with a target user equipment (UE) ; and selectively receive a sensing-related signal from the target UE based whether the sensing-related signal carries the sensing token.

[0174] Example 2 includes the subject matter of example 1, including or omitting optional subject matter, wherein the sensing-related signal is scrambled, coded, or modulated based on the sensing token.

[0175] Example 3 includes the subject matter of any examples 1-2, including or omitting optional subject matter, wherein the processor is further configured to receive indication of the sensing token, target UE ID, and a sensing network (SN) device ID from the target UE; transmit a verification request message to a SN device based on the SN device ID, wherein the verification request message indicates the sensing token and the target UE ID; and in response to receiving a verification response message from the SN device, identifying the sensing token as being associated with the target UE.

[0176] Example 4 includes the subject matter of example 3, including or omitting optional subject matter, wherein the processor is further configured to transmit the verification request message or receive the verification response message by way of a protected Uu message or a protected Xn message.

[0177] Example 5 includes the subject matter of example 1, including or omitting optional subject matter, wherein the processor is configured to derive the sensing token based on an input key.

[0178] Example 6 includes the subject matter of example 5, including or omitting optional subject matter, wherein the processor is configured to derive the sensing token based on a function that includes the input key or a subscriber ID of the target UE as an input or an encryption of the subscriber ID of the target UE using the input key.

[0179] Example 7 includes the subject matter of example 5, including or omitting optional subject matter, wherein the processor is configured to generate the input key based on an AKA / EAP-AKA’-related key or a sidelink-related key shared between a SN device and the target UE, a physical layer key shared between the SN device and the target UE, or a sensing function-related key shared between the SN device and the target UE.

[0180] Example 8 is a baseband processor, including a memory configured to store instructions and a processor coupled to the memory and, when executing instructions, configured  to identify a sensing token associated with a target user equipment (UE) ; and transmit a sensing-related signal to the target UE that carries the sensing token.

[0181] Example 9 includes the subject matter of example 8, including or omitting optional subject matter, wherein the sensing-related signal is scrambled, coded, or modulated based on the sensing token.

[0182] Example 10 includes the subject matter of any of examples 8-9, including or omitting optional subject matter, wherein the processor is configured to derive the sensing token based on an input key.

[0183] Example 11 includes the subject matter of example 10, including or omitting optional subject matter, wherein the processor is configured to derive the sensing token based on a HASH function that includes the input key or a subscriber ID of the target UE as an input or an encryption of the subscriber ID of the target UE using the input key.

[0184] Example 12 includes the subject matter of example 10, including or omitting optional subject matter, further configured to generate the input key based on an AKA / EAP-AKA’-related key or a sidelink-related key shared between a SN device and the target UE, a physical layer key shared between the SN device and the target UE, or a sensing function-related key shared between the SN device and the target UE.

[0185] Example 13 includes the subject matter of example 10, including or omitting optional subject matter, wherein the processor is further configured to receive a verification request message from a SN device, wherein the verification request message indicates the sensing token and a target UE ID of the target UE; and in response to receiving the verification request message, determine whether the sensing token is associated with the target UE and when the sensing token is associated with the target UE, transmit a verification response message to the SN device.

[0186] Example 14 includes the subject matter of example 13, including or omitting optional subject matter, wherein the processor is further configured to receive the verification request message or transmit the verification response message by way of a protected Uu message or a protected Xn message.

[0187] Example 15 is a baseband processor, including a memory configured to store instructions and a processor coupled to the memory and, when executing instructions, configured to identify a sensing token associated with a target user equipment (UE) ; and transmit a sensing-related signal that carries the sensing token to a first sensing network (SN) device.

[0188] Example 16 includes the subject matter of example 15, including or omitting optional subject matter, wherein the sensing-related signal is scrambled, coded, or modulated based on the sensing token.

[0189] Example 17 includes the subject matter of any of examples 15-16, including or omitting optional subject matter, wherein the processor is configured to derive the sensing token based on an input key shared with a second SN device.

[0190] Example 18 includes the subject matter of example 17, including or omitting optional subject matter, wherein the processor is configured to derive the sensing token based on a HASH function that includes the input key or a subscriber ID of the target UE as an input or an encryption of the subscriber ID of the target UE using the input key.

[0191] Example 19 includes the subject matter of example 17, including or omitting optional subject matter, further configured to generate the input key based on an AKA / EAP-AKA’-related key or a sidelink-related key shared between the second SN device and the target UE, a physical layer key shared between the second SN device and the target UE, or a sensing function-related key shared between the second SN device and the target UE .

[0192] Example 20 includes the subject matter of example 17, including or omitting optional subject matter, wherein the processor is further configured to transmit indication of the sensing token, a target UE ID, and a SN device ID of the second SN device to the first SN device.

[0193] Example 21 is a method that includes functions corresponding to the operations performed by a baseband processor of examples 1-20.

[0194] Example 22 is an apparatus that includes means for performing functions corresponding to the operations performed by the baseband processor of any of examples 1-20.

[0195] Example 23 is a UE that includes the baseband processor of any of examples 1-20.

[0196] Example 24 is a base station that includes the baseband processor of any of examples 1-20.

[0197] The above description of illustrated examples, implementations, aspects, etc., of the subject disclosure, including what is described in the Abstract, is not intended to be exhaustive or to limit the disclosed aspects to the precise forms disclosed. While specific examples, implementations, aspects, etc., are described herein for illustrative purposes, various modifications are possible that are considered within the scope of such examples, implementations, aspects, etc., as those skilled in the relevant art can recognize.

[0198] While the methods are illustrated and described above as a series of acts or events, it will be appreciated that the illustrated ordering of such acts or events are not to be interpreted in a limiting sense. For example, some acts may occur in different orders and / or concurrently with other acts or events apart from those illustrated and / or described herein. In addition, not all illustrated acts may be required to implement one or more aspects or embodiments of the disclosure herein. Also, one or more of the acts depicted herein may be carried out in one or more separate acts and / or phases. In some embodiments, the methods illustrated above may be  implemented in a computer readable medium using instructions stored in a memory. Many other embodiments and variations are possible within the scope of the claimed disclosure.

[0199] The term “couple” is used throughout the specification. The term may cover connections, communications, or signal paths that enable a functional relationship consistent with the description of the present disclosure. For example, if device A generates a signal to control device B to perform an action, in a first example device A is coupled to device B, or in a second example device A is coupled to device B through intervening component C if intervening component C does not substantially alter the functional relationship between device A and device B such that device B is controlled by device A via the control signal generated by device A.

[0200] It is well understood that the use of personally identifiable information should follow privacy policies and practices that are generally recognized as meeting or exceeding industry or governmental requirements for maintaining the privacy of users. In particular, personally identifiable information data should be managed and handled so as to minimize risks of unintentional or unauthorized access or use, and the nature of authorized use should be clearly indicated to users.

Claims

1.A baseband processor, comprising a memory configured to store instructions and a processor coupled to the memory and, when executing instructions, configured to:identify a sensing token associated with a target user equipment (UE) ; andselectively receive a sensing-related signal from the target UE based whether the sensing-related signal carries the sensing token.2.The baseband processor of any of claim 1, wherein the sensing-related signal is scrambled, coded, or modulated based on the sensing token.3.The baseband processor of any of claims 1-2, wherein the processor is further configured toreceive indication of the sensing token, target UE ID, and a sensing network (SN) device ID from the target UE;transmit a verification request message to a SN device based on the SN device ID, wherein the verification request message indicates the sensing token and the target UE ID; andin response to receiving a verification response message from the SN device, identifying the sensing token as being associated with the target UE.4.The baseband processor of claim 3, wherein the processor is further configured to transmit the verification request message or receive the verification response message by way of a protected Uu message or a protected Xn message.5.The baseband processor of claim 1, wherein the processor is configured to derive the sensing token based on an input key.6.The baseband processor of claim 5, wherein the processor is configured to derive the sensing token based on a function that includes the input key or a subscriber ID of the target UE as an input or an encryption of the subscriber ID of the target UE using the input key.7.The baseband processor of claim 5, further configured to generate the input key based on an AKA / EAP-AKA’-related key or a sidelink-related key shared between a SN device and the target UE, a physical layer key shared between the SN device and the target UE, or a sensing function-related key shared between the SN device and the target UE.8.A baseband processor, comprising a memory configured to store instructions and a processor coupled to the memory and, when executing instructions, configured to:identify a sensing token associated with a target user equipment (UE) ; andtransmit a sensing-related signal to the target UE that carries the sensing token.9.The baseband processor of any claim 8, wherein the sensing-related signal is scrambled, coded, or modulated based on the sensing token.10.The baseband processor of any of claims 8-9, wherein the processor is configured to derive the sensing token based on an input key.11.The baseband processor of claim 10, wherein the processor is configured to derive the sensing token based on a function that includes the input key or a subscriber ID of the target UE as an input or an encryption of the subscriber ID of the target UE using the input key.12.The baseband processor of claim 10, further configured to generate the input key based on an AKA / EAP-AKA’-related key or a sidelink-related key shared between a SN device and the target UE, a physical layer key shared between the SN device and the target UE, or a sensing function-related key shared between the SN device and the target UE .13.The baseband processor of claim 10, wherein the processor is further configured toreceive a verification request message from a SN device, wherein the verification request message indicates the sensing token and a target UE ID of the target UE; andin response to receiving the verification request message, determine whether the sensing token is associated with the target UE and when the sensing token is associated with the target UE, transmit a verification response message to the SN device.14.The baseband processor of claim 13, wherein the processor is further configured to receive the verification request message or transmit the verification response message by way of a protected Uu message or a protected Xn message.15.A baseband processor, comprising a memory configured to store instructions and a processor coupled to the memory and, when executing instructions, configured to:identify a sensing token associated with a target user equipment (UE) ; andtransmit a sensing-related signal that carries the sensing token to a first sensing network (SN) device.16.The baseband processor of any claim 15, wherein the sensing-related signal is scrambled, coded, or modulated based on the sensing token.17.The baseband processor of any of claims 15-16, wherein the processor is configured to derive the sensing token based on an input key shared with a second SN device.18.The baseband processor of claim 17, wherein the processor is configured to derive the sensing token based on a function that includes the input key or a subscriber ID of the target UE as an input or an encryption of the subscriber ID of the target UE using the input key.19.The baseband processor of claim 17, further configured to generate the input key based on an AKA / EAP-AKA’-related key or a sidelink-related key shared between the second SN device and the target UE, a physical layer key shared between the second SN device and the target UE, or a sensing function-related key shared between the second SN device and the target UE .20.The baseband processor of claim 17, wherein the processor is further configured totransmit indication of the sensing token, a target UE ID, and a SN device ID of the second SN device to the first SN device.

Images