Managing sensing service in a wireless network

Abstract

A method to be performed by a sensing function (SF) entity is provided. The method includes receiving, from a user equipment (UE), a sensing session establishment request. The method includes determining, in response to the sensing session establishment request and based on registration information of the UE, a sensing authorization response. The method includes transmitting, to the UE, the sensing authorization response. A method to be performed by a UE is also provided. The method includes registering with a core network comprising an SF entity. The method includes transmitting, to the SF entity, a sensing session establishment request. The method includes receiving, from the SF entity, a sensing authorization response determined based on registration information of the UE. The method includes, in response to determining, based on the sensing authorization response, that the UE is authorized to establish a sensing session, establishing the sensing session with the SF entity.

Description

MANAGING SENSING SERVICE IN A WIRELESS NETWORKBACKGROUND

[0001] Wireless communication networks provide integrated communication platforms and telecommunication services to wireless user devices. Example telecommunication services include telephony, data (e.g., voice, audio, and / or video data) , messaging, and / or other services. The wireless communication networks have wireless access nodes that exchange wireless signals with the wireless user devices using wireless network protocols, such as protocols described in various telecommunication standards promulgated by the Third Generation Partnership Project (3GPP) . Example wireless communication networks include time division multiple access (TDMA) networks, frequency-division multiple access (FDMA) networks, orthogonal frequency-division multiple access (OFDMA) networks, Long Term Evolution (LTE) , and Fifth Generation New Radio (5G NR) . The wireless communication networks facilitate mobile broadband service using technologies such as OFDM, multiple input multiple output (MIMO) , advanced channel coding, massive MIMO, beamforming, and / or other features.

[0002] A wireless user device, such as a user equipment (UE) , may use a wireless communication network, such as a radio access network (RAN) , to communicate with an access node, such as a base station. The base station may further be in communication with a core network (CN) , such as a 5th Generation Core network (5GC) , which may be implemented on one or more network entities (e.g., network servers) to perform one or more network functions.SUMMARY

[0003] In accordance with one aspect of the present disclosure, a method to be performed by a sensing function (SF) entity is provided. The method includes receiving, from a user equipment (UE) , a sensing session establishment request. The method includes determining, in response to the sensing session establishment request and based on registration information of the UE, a sensing authorization response. The method includes transmitting, to the UE, the sensing authorization response.

[0004] In some implementations, determining the sensing authorization response includes: accessing a memory of the SF entity to obtain UE registration information; and determining, based on the UE registration information, the sensing authorization response.

[0005] In some implementations, the method further includes obtaining the UE registration information from a unified data management (UDM) entity; and storing the UE registration information in the memory.

[0006] In some implementations, determining the sensing authorization response includes: transmitting, to a UDM entity, a UE authorization check request; receiving, from the UDM entity, a UE authorization check response; and determining, based on the UE authorization check response, the sensing authorization response.

[0007] In some implementations, the UE authorization check response is generated by the UDM entity based on UE registration information stored in a memory of the UDM entity.

[0008] In some implementations, the sensing authorization response indicates that the UE is authorized to establish a sensing session with the SF. The method further includes establishing the sensing session between the UE and the SF.

[0009] In some implementations, the sensing authorization response indicates that the UE is not authorized to establish a sensing session with the SF.

[0010] In some implementations, the method further includes receiving, from the UE, a sensing revocation request to revoke a sensing service established according to the sensing session establishment request; removing UE registration information from the memory of the SF entity; and transmitting a UE registration update message to the UDM entity.

[0011] In some implementations, the sensing revocation request includes an identifier of the UE.

[0012] In some implementations, the method further includes receiving, from the UE, a first sensing revocation request to revoke a sensing service established according to the sensing session establishment request; and transmitting, to the UDM entity, a second sensing revocation request to revoke the sensing service. The second sensing revocation request causes the UDM entity to remove the UE registration information from the memory of the UDM entity.

[0013] In some implementations, the method further includes accessing a memory of the SF entity to obtain consent information for sharing sensing data; and in response to determining, based on the consent information, that the UE consents sharing the sensing data with a third-party device, transmitting a message to the third-party device. The message includes the sensing data and an identifier of the UE.

[0014] In some implementations, the method further includes obtaining, from a UDM entity, consent information for sharing sensing data; and in response to determining, based on the consent information, that the UE consents sharing the sensing data with a third-party device, transmitting a message to the third-party device. The message includes the sensing data and an identifier of the UE.

[0015] In accordance with another aspect of the present disclosure, a method to be performed by a UE is provided. The method includes registering with a core network including an SF entity. The method includes transmitting, to the SF entity, a sensing session establishment request. The method includes receiving, from the SF entity, a sensing authorization response determined based on registration information of the UE. The method includes, in response to determining, based on the sensing authorization response, that the UE is authorized to establish a sensing session, establishing the sensing session with the SF entity.

[0016] In some implementations, the method further includes transmitting, to the SF entity, a sensing revocation request to revoke the sensing session. The sensing revocation request causes the core network to remove the UE registration information; and terminating the sensing session with the SF entity.

[0017] In some implementations, the sensing revocation request causes the core network to remove the UE registration information from at least one of: a memory of the SF entity, or a memory of a UDM entity.

[0018] In some implementations, the sensing revocation request causes the core network to remove consent information for sharing sensing data.

[0019] In some implementations, the method further includes transmitting, to the SF entity, consent information for sharing sensing data from the sensing session with a third-party device.

[0020] One or more operations of the above methods can be performed by one or more processors of a network entity or a UE.

[0021] The details of one or more embodiments of these systems and methods are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of these systems and methods will be apparent from the description and drawings, and from the claims.

[0022] BRIEF DESCRIPTION OF THE FIGURES

[0023] FIG. 1 illustrates a wireless network, according to some implementations.

[0024] FIG. 2 illustrates some network functions of a CN in communication with a RAN and a UE in a wireless communication network, according to some implementations.

[0025] FIGs. 3A and 3B each illustrate an example procedure of sensing session authorization, according to some implementations.

[0026] FIGs. 4A and 4B each illustrate an example procedure of sensing session revocation, according to some implementations.

[0027] FIGs. 5A and 5B each illustrate an example procedure of sharing sensing data, according to some implementations.

[0028] FIGs. 6A-6F each illustrate a flowchart of an example method, according to some implementations.

[0029] FIG. 7 illustrates an example UE, according to some implementations.

[0030] FIG. 8 illustrates an example access node, according to some implementations.DETAILED DESCRIPTION

[0031] In some communications systems, a CN can configure a RAN to perform sensing with a UE using hardware sensing resources of the RAN, such as transmitters and receivers of a base station corresponding to the RAN. To efficiently utilize the sensing resources and protect the integrity of communication, it is desirable to have a mechanism such that the CN can authorize the use of sensing resources and revoke such authorization. It is also desirable to have a mechanism such that the CN can determine whether to share sensing data obtained from a sensing session with a third-party device based on the UE’s consent. Here, a third-party device may be another UE, server, or network entity in communication with the CN with potential access to some of the CN’s data. For example, a network operator or network service provider may collect sensing data from the UE, and upon the UE’s consent, share the sensing data with another UE that is subscribed to receive the sensing data, e.g., for business or technical purposes.

[0032] This disclosure provides techniques directed to the above. As discussed below, implementations of this disclosure allow the UE to communicate information about sensing authorization, revocation, and consent to data sharing with a CN, and allow the CN to manage the sensing accordingly. With one or more features described below, implementations of this disclosure improve efficiency of sensing resource utilization and improve integrity and privacy of sensing data.

[0033] FIG. 1 illustrates a wireless network 100, according to some implementations. The wireless network 100 includes a UE 102 and a base station 104 connected via one or more channels 106A, 106B across an air interface 108. The UE 102 and base station 104 communicate using a system that supports controls for managing the access of the UE 102 to a network via the base station 104. The base station 104 may be communicatively connected to a CN, which is described later with reference to FIG. 2.

[0034] In some implementations, the wireless network 100 may be a Non-Standalone (NSA) network that incorporates Long Term Evolution (LTE) and Fifth Generation (5G) New Radio (NR) communication standards as defined by the Third Generation Partnership Project (3GPP) technical specifications (TSs) . For example, the wireless network 100 may be a E-UTRA (Evolved Universal Terrestrial Radio Access) -NR Dual Connectivity (EN-DC) network, or an NR-EUTRA Dual Connectivity (NE-DC) network. In some other implementations, the wireless network 100  may be a Standalone (SA) network that incorporates only 5G NR. Furthermore, other types of communication standards are possible, including future 3GPP systems (e.g., Sixth Generation (6G) ) , Institute of Electrical and Electronics Engineers (IEEE) 802.11 technology (e.g., IEEE 802.11a; IEEE 802.11b; IEEE 802.11g; IEEE 802.11-2007; IEEE 802.11n; IEEE 802.11-2012; IEEE 802.11ac; or other present or future developed IEEE 802.11 technologies) , IEEE 802.16 protocols (e.g., WMAN, WiMAX, etc. ) , or the like. While aspects may be described herein using terminology commonly associated with 5G NR, aspects of the present disclosure can be applied to other systems, such as 3G, 4G, and / or systems subsequent to 5G (e.g., 6G) .

[0035] In the wireless network 100, the UE 102 and any other UE in the system may be, for example, any of laptop computers, smartphones, tablet computers, machine-type devices such as smart meters or specialized devices for healthcare, intelligent transportation systems, or any other wireless device. In network 100, the base station 104 provides the UE 102 network connectivity to a broader network (not shown) . This UE 102 connectivity is provided via the air interface 108 in a base station service area provided by the base station 104. In some implementations, such a broader network may be a wide area network operated by a cellular network provider, or may be the Internet. Each base station service area associated with the base station 104 is supported by one or more antennas integrated with the base station 104. The service areas can be divided into a number of sectors associated with one or more particular antennas. Such sectors may be physically associated with one or more fixed antennas or may be assigned to a physical area with one or more tunable antennas or antenna settings adjustable in a beamforming process used to direct a signal to a particular sector.

[0036] The UE 102 includes control circuitry 110 coupled with transmit circuitry 112 and receive circuitry 114. The transmit circuitry 112 and receive circuitry 114 may each be coupled with one or more antennas. The control circuitry 110 may include various combinations of application-specific circuitry and baseband circuitry. The transmit circuitry 112 and receive circuitry 114 may be adapted to transmit and receive data, respectively, and may include radio frequency (RF) circuitry and / or front-end module (FEM) circuitry.

[0037] In various implementations, aspects of the transmit circuitry 112, receive circuitry 114, and control circuitry 110 may be integrated in various ways to implement the operations described herein. The control circuitry 110 may be adapted or configured to perform various operations,  such as those described elsewhere in this disclosure related to a UE. For instance, the control circuitry 110 can control the transmit circuitry 112 and the receive circuitry 114 to request establishing or revoking a sensing session, perform sensing, and consent sharing the sensing data with a third-party device.

[0038] The transmit circuitry 112 can perform various operations described in this specification. Additionally, the transmit circuitry 112 may transmit using a plurality of multiplexed uplink physical channels. The plurality of uplink physical channels may be multiplexed, e.g., according to time division multiplexing (TDM) or frequency division multiplexing (FDM) along with carrier aggregation. The transmit circuitry 112 may be configured to receive block data from the control circuitry 110 for transmission across the air interface 108.

[0039] The receive circuitry 114 can perform various operations described in this specification. Additionally, the receive circuitry 114 may receive a plurality of multiplexed downlink physical channels from the air interface 108 and relay the physical channels to the control circuitry 110. The plurality of downlink physical channels may be multiplexed, e.g., according to TDM or FDM along with carrier aggregation. The transmit circuitry 112 and the receive circuitry 114 may transmit and receive, respectively, both control data and content data (e.g., messages, images, video, etc. ) structured within data blocks that are carried by the physical channels.

[0040] FIG. 1 also illustrates the base station 104. In some implementations, the base station 104 may be a 5G RAN, a next generation RAN, a E-UTRAN, a non-terrestrial cell, or a legacy RAN, such as a UTRAN. As used herein, the term “5G RAN” or the like may refer to the base station 104 that operates in an NR or 5G wireless network 100, and the term “E-UTRAN” or the like may refer to a base station 104 that operates in an LTE or 4G wireless network 100. The UE 102 utilizes connections (or channels) 106A, 106B, each of which includes a physical communications interface or layer.

[0041] The base station 104 circuitry may include control circuitry 116 coupled with transmit circuitry 118 and receive circuitry 120. The transmit circuitry 118 and receive circuitry 120 may each be coupled with one or more antennas that may be used to enable communications via the air interface 108. The transmit circuitry 118 and receive circuitry 120 may be adapted to transmit and receive data, respectively, to any UE connected to the base station 104. The receive circuitry 120 may receive a plurality of uplink physical channels from one or more UEs, including the UE 102.

[0042] In FIG. 1, the one or more channels 106A, 106B are illustrated as an air interface to enable communicative coupling, and can be consistent with cellular communications protocols, such as a UMTS protocol, a 3GPP LTE protocol, an Advanced long term evolution (LTE-A) protocol, a LTE-based access to unlicensed spectrum (LTE-U) , a 5G protocol, a NR protocol, an NR-based access to unlicensed spectrum (NR-U) protocol, and / or any other communications protocol (s) . In implementations, the UE 102 may directly exchange communication data via a ProSe interface. The ProSe interface may alternatively be referred to as a sidelink (SL) interface and may include one or more logical channels, including but not limited to a Physical Sidelink Control Channel (PSCCH) , a Physical Sidelink Discovery Channel (PSDCH) , and a Physical Sidelink Broadcast Channel (PSBCH) .

[0043] FIG. 2 illustrates some network functions of a CN 210 in communication with a RAN 204 and a UE 202 in wireless communication network 200, according to some implementations. CN 210 can provide, e.g., 5GC service to UE 202 via RAN 204. In wireless communication network 200, UE 202 can be similar to UE 102 of FIG. 1, and RAN 204 can be managed by a base station that is similar to base station 104 of FIG. 1.

[0044] CN 210 has a plurality of network entities configured to perform network functions. In some implementations, the network entities are implemented on separate hardware circuits and / or computers. In some alternative implementations, some or all of the network entities are integrated on the same circuit and / or computer. In some alternative implementations, the network entities are virtually implemented as software code.

[0045] The network entities may be referred to according to their corresponding network functions. In the example of wireless communication network 200, the network entities include: access and mobility management function (AMF) 216, unified data management (UDM) 218, policy control function (PCF) 220, sensing function (SF) 212, network data analytics function (NWDAF) 222, user plane function (UPF) 224, and network exposure function or application function (NEF / AF) 214. Other CNs may have fewer or more network entities. The description below primarily focuses on SF 212 and its interaction with UDM 218. SF 212 can be implemented according to the descriptions in U.S. Patent Application No. 18 / 355,823, which is incorporated herein by reference.

[0046] SF 212 can manage various aspects of sensing involving CN 210 and UE 202. In some implementations, SF 212 is partitioned between user plane SF SF-U and control plane SF SF-C. SF-U can be configured to receive and process sensing data. SF-C can be configured to process control plane signals for sensing integration (e.g., integration of sensing data with cellular communication data) . SF-C can be implemented in CN 210 (e.g., physically attached to the hardware of CN 210) for efficient interaction with other network functions, whereas SF-U can be implemented local to RAN 204 (e.g., physically attached to the hardware of a corresponding base station) to reduce sensing data transmission distance and provide localized sensing data processing capability.

[0047] UDM 218 can be configured to store and manage subscription information of UE 202, such as UE 202’s subscription to certain network services provided by the operator of CN 210. In addition, as described below, UDM 218 can be configured to store UE authorization information for sensing service and determine the validity of the authorization. UDM 218 can also be configured to store UE consent information for sharing sensing data with third-party devices and verify that the consent information is valid (e.g., within a validity duration) .

[0048] FIGs. 3A and 3B each illustrate an example procedure, 300A and 300B, respectively, for sensing session authorization, according to some implementations. Procedures 300A and 300B involve UE 302 and RAN 304, which can be similar to UE 202 and RAN 204, respectively, of FIG. 2. Procedures 300A and 300B also involve SF 312, UDM 318, and authentication server function (AUSF) 311, which are components of a CN similar to CN 210 of FIG. 2. For example, SF 312 and UDM 318 can be similar to SF 212 and UDM 218, respectively. RAN 304 can provide cellular service for UE 302 to communicate with the CN.

[0049] As shown in FIG. 3A for procedure 300A, at 341 UE 302 registers with AUSF 311 for sensing service. For example, UE 302 can provide registration information, such as UE identifier (ID) and UE sensing information, to AUSF 311, which authenticates whether UE 302 is allowed to perform sensing with the CN. The registration procedure between UE 302 and the CN (e.g., AUSF 311 that is included in the CN) can be similar to the registration procedure described in §4.2.2.2 of 3GPP TS 23.502, Release 18, which is incorporated herein by reference.

[0050] At 342, UDM 318 obtains UE registration information for sensing service provided by UE 302 and stores the UE registration information. UDM 318 can manage a registry with UE  registration information from UE 302 and other UEs registered for sensing with the CN. Along with the UE registration information for sensing service, UDM 318 can store other subscription information of UE 302, such as UE 302’s access authorization based on its roaming status.

[0051] At 343, following the UE 302’s registration, UDM 318 synchronizes with SF 312 and provides the UE registration information of UE 302 to SF 312, along with the registration information of other UEs stored in the registry of the UDM. As such, SF 312 can have a complete list of UEs that are registered for sensing service. SF 312 can also obtain the other subscription information of UE 302 from UDM 318. SF 312 can store the registration and subscription information obtained from UDM 318 in a memory of SF 312.

[0052] At 344, UE 302 transmits a sensing session establishment request to the CN. The sensing session establishment request can indicate to SF 312 that UE 302 requests to establish a session to perform sensing using the resources of the CN. In the sensing session establishment request, UE 302 can provide information such as the ID of UE 302, the sensors to be used, the duration of the requested sensing session, and / or the validity period of the request.

[0053] At 345, SF 312 checks the UE registration information stored in its memory to determine whether to authorize establishment of the sensing session. For example, if UE 302 is not found in the registration information stored by SF 312, then SF 312 can deny the sensing session establishment request; otherwise, SF 312 can grant the request and authorize the establishment of the sensing session. In making the determination, SF 312 can also consider various other factors, such as the availability of the requested sensing resources, the communication bandwidth of RAN 304, the priority of the requested sensing session, the services subscribed for by UE 302, etc.

[0054] At 346, SF 312 sends a sensing session establishment response to indicate whether UE 302 is authorized to establish the requested sensing session. Upon receiving the authorization in positive, UE 302 can start the sensing session using the sensing resources managed by the CN. Otherwise, UE 302 can determine that its request has been denied.

[0055] Procedure 300B shown in FIG. 3B provides another option for sensing session authorization. In this procedure, at 361-363, UE 302 registers with the CN and transmits a sensing session establishment request. These operations can be similar to those of 341, 342, and 344 of procedure 300A. However, as described below, different from procedure 300A, SF 312 in  procedure 300B does not obtain the UE registration information from UDM 318. Instead, the UE registration information, along with other subscription information, is stored in a memory of UDM 318.

[0056] At 364, upon receiving the sensing session establishment request, SF 312 transmits a UE authorization check request to UDM 318. In response, UDM 318 checks the UE registration information stored in its memory to determine whether to authorize establishment of the sensing session. The checking and determination performed by UDM 318 at 364 of procedure 300B can be similar to those performed by SF 312 at 345 of procedure 300A.

[0057] At 365, UDM 318 sends a UE authorization check response to indicate its decision to SF 312. At 366, SF 312 sends a sensing session establishment response based on the decision of UDM 318. Upon receiving the authorization in positive, UE 302 can start the sensing session using the sensing resources managed by the CN. Otherwise, UE 302 can determine that its request has been denied.

[0058] As described above, procedures 300A and 300B each provide a way for the CN, in particular SF 312, to determine the authorization for UE 302 to perform sensing use the sensing resources of the CN. Although the two procedures differ in which network entity stores UE registration information, both procedures provide mechanisms to prevent unauthorized use of sensing resources.

[0059] FIGs. 4A and 4B each illustrate an example procedure, 400A and 400B, respectively, for UE sensing session revocation, according to some implementations. Procedures 400A and 400B involve UE 402 and RAN 404, which can be similar to UE 202 and RAN 204, respectively, of FIG. 2. Procedures 400A and 400B also involve SF 412, UDM 418, and authentication server function (AUSF) 411, which are components of a CN similar to CN 210 of FIG. 2. For example, SF 412 and UDM 418 can be similar to SF 212 and UDM 218, respectively. RAN 404 can provide cellular service for UE 402 to communicate with the CN. Both procedures 400A and 400B can be executed upon UE 402’s registration with the CN and establishment of a sensing session authorized by the CN, the operations of which can be similar to those described with reference to FIGs. 3A or 3B. For example, procedure 400A can be executed after establishment of a sensing session according to procedure 300A, in which UE registration information is stored in a memory of SF 312, whereas procedure 400B can be executed after establishment of a sensing session  according to procedure 300B, in which UE registration information is stored in a memory of UDM 318.

[0060] In procedure 400 shown in FIG. 4A, at 441, UE 402 (which has established a sensing session as described with respect to procedure 300A) transmits a sensing revocation request to SF 412. In the sensing revocation request, UE 402 can indicate its desire to revoke the registration for sensing service with CN such that it will no longer perform sensing with the CN. The revocation can include withdrawal of UE 402’s consent for the CN to share the sensing results with any third-party devices. The sensing revocation request can include an ID of UE 402.

[0061] Upon receiving the sensing revocation request from UE 402, SF 412 removes the registration information of UE 402 from the memory of SF 412 at 442. The removal can be implemented as deleting the entry corresponding to UE 402 from the registry managed by SF 412, or can be implemented as marking the entry corresponding to UE 402 as removed or revoked in the registry. As such, UE 402 is unregistered from the sensing service provided by the CN, and the authorization for sensing is effectively revoked.

[0062] At 443, UDM 418 updates its stored UE registration information when the sensing service with UE 402 expires. For example, during UE registration operations, UE 402 or the CN can specify a validity period of the sensing service. Upon expiration of the validity period, UDM 418 can, at 444, obtain updated UE registration information from SF 412 to determine whether to renew the sensing service. If SF 412 still has valid registration information of UE 402, UDM 418 can renew the validity period of the sensing service provided to UE 402. If SF 412 no longer has valid registration information of UE 402, UDM 418 can update its own registry to reflect the removal of UE 402’s registration information by SF 412.

[0063] In the procedure 400B shown in FIG. 4B, at 461, UE 402 (which has established a sensing session as described with respect to procedure 300B) transmits a sensing revocation request, referred to as a first sensing revocation request, to SF 412. The transmission of the first sensing revocation request can be similar to that described in operation 441 of procedure 400A.

[0064] Upon receiving the first sensing revocation request from UE 402, SF 412 transmits a second sensing revocation request to UDM 418 at 462. The second sensing revocation request can have the same or similar information as indicated in the first sensing revocation request, such as  an ID of UE 402. In the second sensing revocation request, SF 412 informs UDM 418 that UE 402 requests to revoke its registration for sensing service with the CN.

[0065] At 463, UDM 418 updates its stored UE registration information when the sensing service with UE 402 expires. The operations at 463 can be similar to those at 443 and 444 of procedure 400A.

[0066] As described above, procedures 400A and 400B each provide a way for the CN to remove UE 402’s registration for sensing service in response to a revocation request by UE 402. Although the two procedures differ in network entity that stores and removes UE registration information, both procedures provide mechanisms to efficiently manage the sensing resources of the CN.

[0067] FIGs. 5A and 5B each illustrate an example procedure, 500A and 500B, respectively, of sharing sensing data, according to some implementations. Procedures 500A and 500B involve UE 502 and RAN 504, which can be similar to UE 202 and RAN 204, respectively, of FIG. 2. Procedures 500A and 500B also involve SF 512, UDM 518, and authentication server function (AUSF) 511, which are components of a CN similar to CN 210 of FIG. 2. For example, SF 512 and UDM 518 can be similar to SF 212 and UDM 218, respectively. RAN 504 can provide cellular service for UE 502 to communicate with the CN. The sensing data in procedures 500A and 500B is shared with third-party device 520. Both procedures 500A and 500B can be executed upon UE 502’s registration with the CN and establishment of a sensing session authorized by the CN, the operations of which can be similar to those described with reference to FIGs. 3A or 3B.

[0068] Procedure 500A shown in FIG. 5A can be executed in scenarios where SF 512 stores UE 502’s consent information of sharing sensing data with third-party devices. At 541, SF 512 checks its memory for UE 502’s consent information. The consent information can be “blanket” consent information that allows or disallows sharing of UE 502’s sensing data indiscriminately with any third-party devices. Alternatively, the consent information can allow sharing of UE 502’s sensing data with some trusted third-party devices while disallowing sharing with other distrusted third-party devices. The policy for distinguishing trust and distrusted third-party devices can be based on, e.g., the operator of a third-party device, the identifier of the third-party device, the network address of the third-party device, the nature or type of the sensing data to be shared, the duration of sharing, the presence of any certificate files of the trustworthiness of the third-party device, and / or the configuration of the CN. In some implementations, the consent information has limited  validity period. For example, UE 502 can consent to sharing for a limited period, after which the consent becomes invalid.

[0069] At 542, after SF 512 verifies that UE 502 consents to sharing sensing data with third-party device 520 and the consent is valid, SF 512 transmits the sensing data of UE 502 to third-party device 520. The transmission can be via, e.g., RAN 504, another RAN communicatively coupled to SF 512, or a backhaul link between the CN and another CN. The shared sensing data can include the ID of UE 502. If, after checking, SF 512 determines that UE 502 does not have valid consent for sharing sensing data with third-party device 520, then SF 512 does not perform 542.

[0070] Procedure 500B shown in FIG. 5B can be executed in scenarios where UDM 518 stores UE 502’s consent information of sharing sensing data with third-party devices. At 561, SF 512 transmits a UE consent check request to UDM 518. In the UE consent check request, SF 512 can inquire about UE 502’s consent information about sharing sensing data with third-party device 520.

[0071] At 562, UDM 518 checks its memory for the requested consent information and responds to the inquiry of SF 512. In the response, UDM 518 can indicate whether there is valid consent information from UE 502 for sharing sensing data with third-party device 520.

[0072] At 563, after determining, based on UDM 518’s response, that there is valid consent information from UE 502 for sharing the sensing data with third-party device 520, SF 512 transmits the sensing data of UE 502 to third-party device 520. The transmission can be similar to that performed at 542 of procedure 500A. If UDM 518’s response indicates that UE 502 does not have valid consent for sharing sensing data with third-party device 520, then SF 512 does not perform 563.

[0073] As described above, procedures 500A and 500B each provide a way for the CN to verify UE 502’s consent for sharing sensing data with third-party device 520. Although the two procedures differ in network entity that stores UE 502’s consent information, both procedures provide mechanisms to improve sensing data privacy of UE 502.

[0074] FIG. 6A illustrates a flowchart of an example method 600A, according to some implementations. For clarity of presentation, the description that follows generally describes method 600A in the context of the other figures in this description. For example, method 600A  can be performed by SF 212 of FIG. 2. It will be understood that method 600A can be performed, for example, by any suitable system, environment, software, hardware, or a combination of systems, environments, software, and hardware, as appropriate. In some implementations, various steps of method 600A can be run in parallel, in combination, in loops, or in any order.

[0075] At 602, method 600A involves receiving, from a UE, a sensing session establishment request. The sensing session establishment request can be similar to that transmitted by UE 302 at 344 of FIG. 3A or at 363 of FIG. 3B.

[0076] At 604, method 600A involves determining, in response to the sensing session establishment request and based on registration information of the UE, a sensing authorization response. The determination can be similar to that described above at with reference to operation 345 of FIG. 3A or operation 364 of FIG. 3B.

[0077] At 606, method 600A involves transmitting, to the UE, the sensing authorization response. The sensing authorization response can be similar to that transmitted to UE 302 at 346 of FIG. 3A or at 366 of FIG. 3B.

[0078] FIG. 6B illustrates a flowchart of an example method 600B, according to some implementations. For clarity of presentation, the description that follows generally describes method 600B in the context of the other figures in this description. For example, method 600B can be performed by UE 202 of FIG. 2. It will be understood that method 600B can be performed, for example, by any suitable system, environment, software, hardware, or a combination of systems, environments, software, and hardware, as appropriate. In some implementations, various steps of method 600B can be run in parallel, in combination, in loops, or in any order.

[0079] At 632, method 600B involves registering with a core network including an SF entity. The registration can be similar to that described above with reference to operation 341 of FIG. 3A or operation 361 of FIG. 3B.

[0080] At 634, method 600B involves transmitting, to the SF entity, a sensing session establishment request. The sensing session establishment request can be similar to that transmitted by UE 302 at 344 of FIG. 3A or at 363 of FIG. 3B.

[0081] At 636, method 600B involves receiving, from the SF entity, a sensing authorization response determined based on registration information of the UE. The sensing authorization response can be similar to that transmitted to UE 302 at 346 of FIG. 3A or at 366 of FIG. 3B.

[0082] At 638, method 600B involves, in response to determining, based on the sensing authorization response, that the UE is authorized to establish a sensing session, establishing the sensing session with the SF entity.

[0083] FIG. 6C illustrates a flowchart of an example method 600C, according to some implementations. For clarity of presentation, the description that follows generally describes method 600C in the context of the other figures in this description. For example, method 600C can be performed by SF 212 of FIG. 2. It will be understood that method 600C can be performed, for example, by any suitable system, environment, software, hardware, or a combination of systems, environments, software, and hardware, as appropriate. In some implementations, various steps of method 600C can be run in parallel, in combination, in loops, or in any order. One or more operations of method 600C can be similar to those of procedure 400A of FIG. 4A.

[0084] At 642, method 600C involves receiving, from the UE, a sensing revocation request to revoke a sensing session established in response to the sensing authorization response.

[0085] At 644, method 600C involves removing UE registration information from the memory of the SF entity.

[0086] At 646, method 600C involves transmitting a UE registration update message to the UDM entity.

[0087] FIG. 6D illustrates a flowchart of an example method 600D, according to some implementations. For clarity of presentation, the description that follows generally describes method 600D in the context of the other figures in this description. For example, method 600D can be performed by SF 212 of FIG. 2. It will be understood that method 600D can be performed, for example, by any suitable system, environment, software, hardware, or a combination of systems, environments, software, and hardware, as appropriate. In some implementations, various steps of method 600D can be run in parallel, in combination, in loops, or in any order. One or more operations of method 600D can be similar to those of procedure 400B of FIG. 4B.

[0088] At 652, method 600D involves receiving, from the UE, a first sensing revocation request to revoke a sensing session established in response to the sensing authorization response.

[0089] At 654, method 600D involves transmitting, to the UDM entity, a second sensing revocation request to revoke the sensing session. The second sensing revocation request causes the UDM entity to remove the UE registration information from the memory of the UDM entity.

[0090] FIG. 6E illustrates a flowchart of an example method 600E, according to some implementations. For clarity of presentation, the description that follows generally describes method 600E in the context of the other figures in this description. For example, method 600E can be performed by SF 212 of FIG. 2. It will be understood that method 600E can be performed, for example, by any suitable system, environment, software, hardware, or a combination of systems, environments, software, and hardware, as appropriate. In some implementations, various steps of method 600E can be run in parallel, in combination, in loops, or in any order. One or more operations of method 600E can be similar to those of procedure 500A of FIG. 5A.

[0091] At 662, method 600E involves accessing a memory of the SF entity to obtain consent information for sharing sensing data.

[0092] At 664, method 600E involves transmitting a message to the third-party device in response to determining, based on the consent information, that the UE consents sharing the sensing data with a third-party device. The message includes the sensing data and an identifier of the UE.

[0093] FIG. 6F illustrates a flowchart of an example method 600F, according to some implementations. For clarity of presentation, the description that follows generally describes method 600F in the context of the other figures in this description. For example, method 600F can be performed by SF 212 of FIG. 2. It will be understood that method 600F can be performed, for example, by any suitable system, environment, software, hardware, or a combination of systems, environments, software, and hardware, as appropriate. In some implementations, various steps of method 600F can be run in parallel, in combination, in loops, or in any order. One or more operations of method 600F can be similar to those of procedure 500B of FIG. 5B.

[0094] At 672, method 600F involves obtaining, from a unified data management (UDM) entity, consent information for sharing sensing data.

[0095] At 674, method 600F involves transmitting a message to the third-party device in response to determining, based on the consent information, that the UE consents sharing the sensing data with a third-party device. The message includes the sensing data and an identifier of the UE.

[0096] FIG. 7 illustrates an example UE 700, according to some implementations. The UE 700 may be similar to and substantially interchangeable with UE 102 of FIG. 1.

[0097] The UE 700 may be any mobile or non-mobile computing device, such as, for example, mobile phones, computers, tablets, industrial wireless sensors (for example, microphones, pressure sensors, thermometers, motion sensors, accelerometers, inventory sensors, electric voltage / current meters, etc. ) , video devices (for example, cameras, video cameras, etc. ) , wearable devices (for example, a smart watch) , relaxed-IoT devices.

[0098] The UE 700 may include processors 702, RF interface circuitry 704, memory / storage 706, user interface 708, sensors 710, driver circuitry 712, power management integrated circuit (PMIC) 714, one or more antenna (s) 716, and battery 718. The components of the UE 700 may be implemented as integrated circuits (ICs) , portions thereof, discrete electronic devices, or other modules, logic, hardware, software, firmware, or a combination thereof. The block diagram of FIG. 7 is intended to show a high-level view of some of the components of the UE 700. However, some of the components shown may be omitted, additional components may be present, and different arrangement of the components shown may occur in other implementations.

[0099] The components of the UE 700 may be coupled with various other components over one or more interconnects 720, which may represent any type of interface, input / output, bus (local, system, or expansion) , transmission line, trace, optical connection, etc. that allows various circuit components (on common or different chips or chipsets) to interact with one another.

[0100] The processors 702 may include processor circuitry such as, for example, baseband processor circuitry (BB) 722A, central processor unit circuitry (CPU) 722B, and graphics processor unit circuitry (GPU) 722C. The processors 702 may include any type of circuitry or processor circuitry that executes or otherwise operates computer-executable instructions, such as program code, software modules, or functional processes from memory / storage 706 to cause the UE 700 to perform operations as described herein.

[0101] In some implementations, the baseband processor circuitry 722A may access a communication protocol stack 724 in the memory / storage 706 to communicate over a 3GPP compatible network. In general, the baseband processor circuitry 722A may access the communication protocol stack to: perform user plane functions at a physical (PHY) layer, medium access control (MAC) layer, radio link control (RLC) layer, packet data convergence protocol (PDCP) layer, service data adaptation protocol (SDAP) layer, and PDU layer; and perform control plane functions at a PHY layer, MAC layer, RLC layer, PDCP layer, RRC layer, and a non-access stratum layer. In some implementations, the PHY layer operations may additionally / alternatively be performed by the components of the RF interface circuitry 704. The baseband processor circuitry 722A may generate or process baseband signals or waveforms that carry information in 3GPP-compatible networks. In some implementations, the waveforms for NR may be based cyclic prefix orthogonal frequency division multiplexing (OFDM) “CP-OFDM” in the uplink or downlink, and discrete Fourier transform spread OFDM “DFT-S-OFDM” in the uplink.

[0102] The memory / storage 706 may include one or more non-transitory, computer-readable media that includes instructions (for example, communication protocol stack 724) that may be executed by one or more of the processors 702 to cause the UE 700 to perform various operations described herein. The memory / storage 706 include any type of volatile or non-volatile memory that may be distributed throughout the UE 700. In some implementations, some of the memory / storage 706 may be located on the processors 702 themselves (for example, L1 and L2 cache) , while other memory / storage 706 is external to the processors 702 but accessible thereto via a memory interface. The memory / storage 706 may include any suitable volatile or non-volatile memory such as, but not limited to, dynamic random access memory (DRAM) , static random access memory (SRAM) , erasable programmable read only memory (EPROM) , electrically erasable programmable read only memory (EEPROM) , Flash memory, solid-state memory, or any other type of memory device technology.

[0103] The RF interface circuitry 704 may include transceiver circuitry and radio frequency front module (RFEM) that allows the UE 700 to communicate with other devices over a radio access network. The RF interface circuitry 704 may include various elements arranged in transmit or receive paths. These elements may include, for example, switches, mixers, amplifiers, filters, synthesizer circuitry, control circuitry, etc.

[0104] In the receive path, the RFEM may receive a radiated signal from an air interface via antenna (s) 716 and proceed to filter and amplify (with a low-noise amplifier) the signal. The signal may be provided to a receiver of the transceiver that downconverts the RF signal into a baseband signal that is provided to the baseband processor of the processors 702.

[0105] In the transmit path, the transmitter of the transceiver up-converts the baseband signal received from the baseband processor and provides the RF signal to the RFEM. The RFEM may amplify the RF signal through a power amplifier prior to the signal being radiated across the air interface via the antenna (s) 716. In various implementations, the RF interface circuitry 704 may be configured to transmit / receive signals in a manner compatible with NR access technologies.

[0106] The antenna (s) 716 may include one or more antenna elements to convert electrical signals into radio waves to travel through the air and to convert received radio waves into electrical signals. The antenna elements may be arranged into one or more antenna panels. The antenna (s) 716 may have antenna panels that are omnidirectional, directional, or a combination thereof to enable beamforming and multiple input, multiple output communications. The antenna (s) 716 may include microstrip antennas, printed antennas fabricated on the surface of one or more printed circuit boards, patch antennas, phased array antennas, etc. The antenna (s) 716 may have one or more panels designed for specific frequency bands including bands in FR1 or FR2.

[0107] The user interface 708 includes various input / output (I / O) devices designed to enable user interaction with the UE 700. The user interface 708 includes input device circuitry and output device circuitry. Input device circuitry includes any physical or virtual means for accepting an input including, inter alia, one or more physical or virtual buttons (for example, a reset button) , a physical keyboard, keypad, mouse, touchpad, touchscreen, microphones, scanner, headset, or the like. The output device circuitry includes any physical or virtual means for showing information or otherwise conveying information, such as sensor readings, actuator position (s) , or other like information. Output device circuitry may include any number or combinations of audio or visual display, including, inter alia, one or more simple visual outputs / indicators (for example, binary status indicators such as light emitting diodes “LEDs” and multi-character visual outputs) , or more complex outputs such as display devices or touchscreens (for example, liquid crystal displays “LCDs, ” LED displays, quantum dot displays, projectors, etc. ) , with the output of characters,  graphics, multimedia objects, and the like being generated or produced from the operation of the UE 700.

[0108] The sensors 710 may include devices, modules, or subsystems whose purpose is to detect events or changes in its environment and send the information (sensor data) about the detected events to some other device, module, subsystem, etc. Examples of such sensors include, inter alia, inertia measurement units including accelerometers, gyroscopes, or magnetometers; microelectromechanical systems or nanoelectromechanical systems including 3-axis accelerometers, 3-axis gyroscopes, or magnetometers; level sensors; temperature sensors (for example, thermistors) ; pressure sensors; image capture devices (for example, cameras or lensless apertures) ; light detection and ranging sensors; proximity sensors (for example, infrared radiation detector and the like) ; depth sensors; ambient light sensors; ultrasonic transceivers; microphones or other like audio capture devices; etc.

[0109] The driver circuitry 712 may include software and hardware elements that operate to control particular devices that are embedded in the UE 700, attached to the UE 700, or otherwise communicatively coupled with the UE 700. The driver circuitry 712 may include individual drivers allowing other components to interact with or control various input / output (I / O) devices that may be present within, or connected to, the UE 700. For example, driver circuitry 712 may include a display driver to control and allow access to a display device, a touchscreen driver to control and allow access to a touchscreen interface, sensor drivers to obtain sensor readings of sensors 710 and control and allow access to sensors 710, drivers to obtain actuator positions of electro-mechanic components or control and allow access to the electro-mechanic components, a camera driver to control and allow access to an embedded image capture device, audio drivers to control and allow access to one or more audio devices.

[0110] The PMIC 714 may manage power provided to various components of the UE 700. In particular, with respect to the processors 702, the PMIC 714 may control power-source selection, voltage scaling, battery charging, or DC-to-DC conversion.

[0111] In some implementations, the PMIC 714 may control, or otherwise be part of, various power saving mechanisms of the UE 700. A battery 718 may power the UE 700, although in some examples the UE 700 may be mounted deployed in a fixed location, and may have a power supply coupled to an electrical grid. The battery 718 may be a lithium ion battery, a metal-air battery, such  as a zinc-air battery, an aluminum-air battery, a lithium-air battery, and the like. In some implementations, such as in vehicle-based applications, the battery 718 may be a typical lead-acid automotive battery.

[0112] FIG. 8 illustrates an example access node 800 (e.g., a base station or gNB) , according to some implementations. The access node 800 may be similar to and substantially interchangeable with base station 104. The access node 800 may include processors 802, RF interface circuitry 804, core network (CN) interface circuitry 806, memory / storage circuitry 808, and one or more antenna (s) 810.

[0113] The components of the access node 800 may be coupled with various other components over one or more interconnects 812. The processors 802, RF interface circuitry 804, memory / storage circuitry 808 (including communication protocol stack 814) , antenna (s) 810, and interconnects 812 may be similar to like-named elements shown and described with respect to FIG. 7. For example, the processors 802 may include processor circuitry such as, for example, baseband processor circuitry (BB) 816A, central processor unit circuitry (CPU) 816B, and graphics processor unit circuitry (GPU) 816C.

[0114] The CN interface circuitry 806 may provide connectivity to a core network, for example, a 5th Generation Core network (5GC) using a 5GC-compatible network interface protocol such as carrier Ethernet protocols, or some other suitable protocol. Network connectivity may be provided to / from the access node 800 via a fiber optic or wireless backhaul. The CN interface circuitry 806 may include one or more dedicated processors or FPGAs to communicate using one or more of the aforementioned protocols. In some implementations, the CN interface circuitry 806 may include multiple controllers to provide connectivity to other networks using the same or different protocols.

[0115] As used herein, the terms “access node, ” “access point, ” or the like may describe equipment that provides the radio baseband functions for data and / or voice connectivity between a network and one or more users. These access nodes can be referred to as BS, gNBs, RAN nodes, eNBs, NodeBs, RSUs, TRxPs or TRPs, and so forth, and can include ground stations (e.g., terrestrial access points) or satellite stations providing coverage within a geographic area (e.g., a cell) . As used herein, the term “NG RAN node” or the like may refer to an access node 800 that operates in an NR or 5G system (for example, a gNB) , and the term “E-UTRAN node” or the like may refer  to an access node 800 that operates in an LTE or 4G system (e.g., an eNB) . According to various implementations, the access node 800 may be implemented as one or more of a dedicated physical device such as a macrocell base station, and / or a low power (LP) base station for providing femtocells, picocells or other like cells having smaller coverage areas, smaller user capacity, or higher bandwidth compared to macrocells.

[0116] In some implementations, all or parts of the access node 800 may be implemented as one or more software entities running on server computers as part of a virtual network, which may be referred to as a CRAN and / or a virtual baseband unit pool (vBBUP) . In V2X scenarios, the access node 800 may be or act as a “Road Side Unit. ” The term “Road Side Unit” or “RSU” may refer to any transportation infrastructure entity used for V2X communications. An RSU may be implemented in or by a suitable RAN node or a stationary (or relatively stationary) UE, where an RSU implemented in or by a UE may be referred to as a “UE-type RSU, ” an RSU implemented in or by an eNB may be referred to as an “eNB-type RSU, ” an RSU implemented in or by a gNB may be referred to as a “gNB-type RSU, ” and the like.

[0117] Various components may be described as performing a task or tasks, for convenience in the description. Such descriptions should be interpreted as including the phrase “configured to. ” Reciting a component that is configured to perform one or more tasks is expressly intended not to invoke 35 U.S.C. § 112 (f) interpretation for that component.

[0118] As described above, one aspect of the present technology may relate to the gathering and use of data available from specific and legitimate sources to allow for interaction with a second device for a data transfer. The present disclosure contemplates that in some instances, this gathered data may include personal information data that uniquely identifies or can be used to identify a specific person. Such personal information data can include demographic data, location-based data, online identifiers, telephone numbers, email addresses, home addresses, data or records relating to a user’s health or level of fitness (e.g., vital signs measurements, medication information, exercise information) , date of birth, or any other personal information.

[0119] The present disclosure recognizes that the use of such personal information data, in the present technology, can be used to the benefit of users. For example, the personal information data can be used to provide for secure data transfers occurring between a first device and a second  device. The personal information data may further be utilized for identifying an account associated with the user from a service provider for completing a data transfer.

[0120] The present disclosure contemplates that those entities responsible for the collection, analysis, disclosure, transfer, storage, or other use of such personal information data will comply with well-established privacy policies and / or privacy practices. In particular, such entities would be expected to implement and consistently apply privacy practices that are generally recognized as meeting or exceeding industry or governmental requirements for maintaining the privacy of users. Such information regarding the use of personal data should be prominent and easily accessible by users, and should be updated as the collection and / or use of data changes. Personal information from users should be collected for legitimate uses only. Further, such collection / sharing should occur only after receiving the consent of the users or other legitimate basis specified in applicable law. Additionally, such entities should consider taking any needed steps for safeguarding and securing access to such personal information data and ensuring that others with access to the personal information data adhere to their privacy policies and procedures. Further, such entities can subject themselves to evaluation by third parties to certify their adherence to widely accepted privacy policies and practices. In addition, policies and practices should be adapted for the particular types of personal information data being collected and / or accessed and adapted to applicable laws and standards, including jurisdiction-specific considerations that may serve to impose a higher standard. For instance, in the US, collection of or access to certain health data may be governed by federal and / or state laws, such as the Health Insurance Portability and Accountability Act (HIPAA) ; whereas health data in other countries may be subject to other regulations and policies and should be handled accordingly.

[0121] Despite the foregoing, the present disclosure also contemplates embodiments in which users selectively block the use of, or access to, personal information data. That is, the present disclosure contemplates that hardware and / or software elements can be provided to prevent or block access to such personal information data. For example, the present technology can be configured to allow users to select to “opt in” or “opt out” of participation in the collection of personal information data during registration for services or anytime thereafter. For example, a user may “opt in” or “opt out” of having information associated with an account of the user stored on a user device and / or shared by the user device. In addition to providing “opt in” and “opt out”  options, the present disclosure contemplates providing notifications relating to the access or use of personal information. For instance, a user may be notified upon downloading an application that their personal information data will be accessed and then reminded again just before personal information data is accessed by the application. In some instances, the user may be notified upon initiation of a data transfer of the device accessing information associated with the account of the user and / or the sharing of information associated with the account of the user with another device.

[0122] Moreover, it is the intent of the present disclosure that personal information data should be managed and handled in a way to minimize risks of unintentional or unauthorized access or use. Risk can be minimized by limiting the collection of data and deleting data once it is no longer needed. In addition, and when applicable, including in certain health related applications, data de-identification can be used to protect a user’s privacy. De-identification may be facilitated, when appropriate, by removing identifiers, controlling the amount or specificity of data stored (e.g., collecting location data at city level rather than at an address level) , controlling how data is stored (e.g., aggregating data across users) , and / or other methods such as differential privacy.

[0123] Therefore, although the present disclosure broadly covers use of personal information data to implement one or more various disclosed embodiments, the present disclosure also contemplates that the various embodiments can also be implemented without the need for accessing such personal information data. That is, the various embodiments of the present technology are not rendered inoperable due to the lack of all or a portion of such personal information data. For example, content can be selected and delivered to users based on aggregated non-personal information data or a bare minimum amount of personal information, such as the content being handled only on the user’s device or other non-personal information available to the content delivery services.

[0124] Although the embodiments above have been described in considerable detail, numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications.

Claims

1.A method to be performed by a sensing function (SF) entity, the method comprising:receiving, from a user equipment (UE) , a sensing session establishment request;determining, in response to the sensing session establishment request and based on registration information of the UE, a sensing authorization response; andtransmitting, to the UE, the sensing authorization response.2.The method of claim 1, wherein determining the sensing authorization response comprises:accessing a memory of the SF entity to obtain UE registration information; anddetermining, based on the UE registration information, the sensing authorization response.3.The method of claim 2, further comprising:obtaining the UE registration information from a unified data management (UDM) entity; andstoring the UE registration information in the memory.4.The method of claim 1, wherein determining the sensing authorization response comprises:transmitting, to a unified data management (UDM) entity, a UE authorization check request;receiving, from the UDM entity, a UE authorization check response; anddetermining, based on the UE authorization check response, the sensing authorization response.5.The method of claim 4, wherein the UE authorization check response is generated by the UDM entity based on UE registration information stored in a memory of the UDM entity.6.The method of claim 1, wherein the sensing authorization response indicates that the UE is authorized to establish a sensing session with the SF, and where in the method further comprises establishing the sensing session between the UE and the SF.7.The method of claim 1, wherein the sensing authorization response indicates that the UE is not authorized to establish a sensing session with the SF.8.The method of claim 3, further comprising:receiving, from the UE, a sensing revocation request to revoke a sensing service established according to the sensing session establishment request;removing UE registration information from the memory of the SF entity; andtransmitting a UE registration update message to the UDM entity.9.The method of claim 8, wherein the sensing revocation request comprises an identifier of the UE.10.The method of claim 5, further comprising:receiving, from the UE, a first sensing revocation request to revoke a sensing service established according to the sensing session establishment request; andtransmitting, to the UDM entity, a second sensing revocation request to revoke the sensing service, wherein the second sensing revocation request causes the UDM entity to remove the UE registration information from the memory of the UDM entity.11.The method of claim 10, wherein the sensing revocation request comprises an identifier of the UE.12.The method of claim 1, further comprising:accessing a memory of the SF entity to obtain consent information for sharing sensing data; andin response to determining, based on the consent information, that the UE consents sharing the sensing data with a third-party device, transmitting a message to the third-party device, wherein the message comprises the sensing data and an identifier of the UE.13.The method of claim 1, further comprising:obtaining, from a unified data management (UDM) entity, consent information for sharing sensing data; andin response to determining, based on the consent information, that the UE consents sharing the sensing data with a third-party device, transmitting a message to the third-party device, wherein the message comprises the sensing data and an identifier of the UE.14.A method to be performed by a user equipment (UE) , the method comprising:registering with a core network comprising a sensing function (SF) entity;transmitting, to the SF entity, a sensing session establishment request;receiving, from the SF entity, a sensing authorization response determined based on registration information of the UE; andin response to determining, based on the sensing authorization response, that the UE is authorized to establish a sensing session, establishing the sensing session with the SF entity.15.The method of claim 14, further comprising:transmitting, to the SF entity, a sensing revocation request to revoke the sensing session, wherein the sensing revocation request causes the core network to remove the UE registration information; andterminating the sensing session with the SF entity.16.The method of claim 15, wherein the sensing revocation request causes the core network to remove the UE registration information from at least one of: a memory of the SF entity, or a memory of a unified data management (UDM) entity.17.The method of claim 15, wherein the sensing revocation request causes the core network to remove consent information for sharing sensing data.18.The method of claim 14, further comprising transmitting, to the SF entity, consent information for sharing sensing data from the sensing session with a third-party device.19.A network entity comprising one or more processors configured to execute instructions that cause the network entity to perform the method of any of claims 1-13.20.A user equipment (UE) comprising one or more processors configured to execute instructions that cause the UE to perform the method of any of claims 14-18.

Images