WO2025101583A1

WO2025101583A1 - Methods to enable sensing enablement services in 3gpp systems

Info

Publication number: WO2025101583A1
Application number: PCT/US2024/054688
Authority: WO
Inventors: Lu Liu; Quang Ly; Dale Seed; Catalina MLADIN
Original assignee: Convida Wireless LLC
Current assignee: Convida Wireless LLC
Priority date: 2023-11-06
Filing date: 2024-11-06
Publication date: 2025-05-15
Anticipated expiration: 2026-05-06

Abstract

Methods for enabling sensing enablement services in 3GPP systems are described herein. In one aspect, a method may include receiving, from a sensing enablement client and via a sensing enablement client registration procedure, sensing capability information of a hosting user equipment (UE); receiving, from the sensing enablement client and via the sensing enablement client registration procedure, characteristics information and consent policy of the hosting UE; receiving, from a consumer, a request for a sensing enablement service; sending, to a sensing data source, a request for configuring the sensing service; receiving sensing data/results and assistance information in response to the request for configuring the sensing service; generating sensing outputs comprising processed sensing results; and sending, to a notification target specified by the consumer, a message including the generated sensing outputs.

Description

METHODS TO ENABLE SENSING ENABLEMENT SERVICES IN 3GPP SYSTEMS

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims benefit of U.S. Provisional Application No. 63/596,342 titled “Methods to Enable Sensing Enablement Services in 3GPP Systems” filed November 6, 2023, the contents of which are hereby incorporated by reference in its entirety for any and all purposes.

BACKGROUND

[0002] 3 GPP wireless sensing is a technology enabler to acquire information about characteristics of an environment and/or objects within the environment (or area of interest). 3GPP sensing uses sensing signals in the form of radio waves to determine the presence, distance (range), angle, shape, velocity, or motion of objects. 3 GPP sensing relies on analyzing the transmissions, reflections, and scattering of wireless sensing signals, where the sensing signals may be transmitted and received by a RAN node or a UE. The object may be a 3GPP UE or non-3GPP device that is connected to the 3GPP network, or it may be a nonconnected object which passively reflects the sensing signals.

[0003] Sensing capabilities in the 3GPP network may provide new possibilities for enhanced usage of the telecommunication infrastructure in areas of object detection and tracking, environment monitoring and human motion monitoring. The capabilities may provide input to various verticals such as UAVs, smart home. V2X, and factories. Example use cases of 3GPP sensing may include: Object and intruder detection for smart home, on a highway, for railways, for factory, for predefined secure areas around critical infrastructure; Collision avoidance and trajectory tracking of UAVs, vehicles, AGVs; Automotive maneuvering and navigation; Public safely search and rescue: Rainfall monitoring and flooding; and Health and sports monitoring.

[0004] 3GPP wireless sensing may enable a wide variety of application use cases as previously described. However, a sensing sen ice has not yet been integrated into the 3GPP system. One aspect of a sensing service that is required is the exposure of the service to users via application clients and servers. The exposure of the sensing service will allow users to configure and to provide assistance information for the sensing sendee to obtain sensing data that may be utilized to generate sensing results to fulfill the desired requirements. This exposure is not currently supported and therefore users, via application clients and/or servers, are not able to access the sensing service.

[0005] FIG. 1 illustrates an example of sensing-based intruder detection where a user requests a sensing service to sense objects that appear in the vicinity around a house. In the example of FIG. 1, a user requests sensing service to provide intrusion and theft detection. The service is configured to perform sensing at a five-second interval. The user may have also scheduled a package delivery. The delivery person arrives at the house by car. The car is able to communicate with the 3GPP network and provides its identity and location information. The delivery person also has a cellphone that can communicate with the 3GPP network but is only willing to share their identity and location information to trusted entities (e.g. their car) and not willing to share their information with untrusted parties (in this case the user requesting for delivery service). The delivery person gets out of the car and leaves the package at the front door of the house. The sensing service detects a car is parking near the house and a person approaching the front door. After the package is left at the front door, the sensing sendee needs to be reconfigured to perform sensing at a lower interval (e.g. one- second interval) to detect thieves of the package.

[0006] In this example, although the sensing service may detect that a person is approaching the front door, it is not able to determine whether this is an intruder or a delivery person. Further, the sensing service is unable to determine whether a delivery person is expected to appear at the house or not without knowing the user has scheduled a delivery service. It can be observed that the sensing data/result associated with an object itself may not be sufficient to identify the object. Sensing data/result alone may not be sufficient to determine whether an object is of interest or not.

[0007] FIG. 2 illustrates an example of sensing-based object detection where a user requests a sensing service to sense objects that appear around a car. In the example in FIG. 2, the user requests for sensing service to detect objects that appear around the car while the car is driving on the road. The sensing area may change due to the car’s mobility. When the environment changes (e.g. it starts to rain and the road becomes slippery'), the sensing radius may need to be increased to accommodate for longer braking distance.

[0008] As can be seen from the examples in FIG. 1 and FIG. 2. the user’s requirements of a sensing service (e g. frequency or schedule of performing sensing, location or size of the sensing area or area of interest, or changes in the environment) may vary' from time to time due to the dynamic conditions or context of the sensing objects, sensing area, desired sensing results, and/or sensing environment. Currently there is a lack of sensing services to support the aforementioned use cases.

Summary

[0009] Methods for enabling sensing enablement sen-ices in 3GPP systems are described herein. In one aspect, a method of a sensing enablement server may include: receiving, from a sensing enablement client, sensing capability information of the hosting UE which may function as a sensing device, where the information may be received via a sensing enablement client registration procedure. The method may also include receiving, from a sensing enablement client, characteristics information and consent policy of the hosting UE which may function as or be associate with a sensing object, where the information may be received via a sensing enablement client registration procedure. The method may also include receiving, from a consumer, a request for sensing enablement service. In some cases, the consumer may be a VAL server. In some cases, the request may include sensing type, information of objects to be sensed, conditions to trigger sensing operations, sensing requirements, etc.

[0010] The method may also include sending, to a sensing data source, a request for configuring sensing service. In some cases, the sensing data source may be the 3GPP core network. In some cases, the sensing data source may be a UE functioning as a sensing device, and the request is sent via the sensing enablement client hosted on the UE. In some cases, the request may include sensing ID, suggested UEs that may function as sensing devices, information of objects to be sensed, sensing requirements, etc. In some cases, the sensing enablement server may send an updated request for configuring sensing service after determining to update the configuration.

[0011] The method may also include receiving sensing data/results and assistance information. In some cases, the sensing data/results and assistance information may be received from the 3GPP core network, sensing enablement clients, application enablement layer servers, VAL servers. The method may also include generating sensing outputs which may include processed sensing results. In some cases, the processed sensing results are generated by associating sensing results with assistance information. In some cases, the sensing enablement server may determine whether a sensed object is of interest to the consumer based on the assistance information received from the consumer or other entities. [0012] The method may also include sending, to a notification target specified by the consumer, a message including the generated sensing outputs.

[0013] In another aspect, a method may include sending, to a sensing enablement server, sensing capability information of the hosting UE which may function as a sensing device, wherein the information may be received via a sensing enablement client registration procedure. In some cases, the sensing enablement client may send updated information to the sensing enablement server when the sensing capability information changes.

[0014] The method may also include sending, to a sensing enablement server, characteristics information and consent policy of the hosting UE which may function as or be associate with a sensing object, wherein the information may be received via a sensing enablement client registration procedure. In some case, the sensing enablement client may send updated information to the sensing enablement server when the information or policy changes.

[0015] The method may also include receiving, from a consumer, a request for sensing enablement service and forwarding the request to the sensing enablement server. In some cases, the consumer may be a V AL client. In some cases, the request may include sensing type, information of objects to be sensed, conditions to trigger sensing operations, sensing requirements, etc.

[0016] The method may also include receiving, from the sensing enablement server, a request for configuring sensing service of the hosting UE. In some cases, the request may include sensing ID, information of objects to be sensed, sensing requirements, etc. In some cases, the sensing enablement client may forward the configuration information to one or more application clients hosted on the UE which may provide sensing capabilities.

[0017] The method may also include sending, to the sensing enablement server, sensing data/results and assistance information based on the received configuration request.

[0018] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to features that solve any or all disadvantages noted in any part of this disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] FIG. 1 depicts sensing-based intruder detection.

[0020] FIG. 2 depicts sensing-based object detection for mobile car.

[0021] FIG. 3 depicts transmissions of sensing signals and sensing data/results in a 3gpp svstem.

[0022] FIG. 4 depicts sensing input and output.

[0023] FIG. 5 depicts a sensing enablement service architecture.

[0024] FIG. 6 depicts a sensing enablement service procedure overview.

[0025] FIG. 7 depicts a sensing enablement client registration.

[0026] FIG. 8 depicts a sensing enablement service request.

[0027] FIG. 9 depicts a sensing service configuration.

[0028] FIG. 10 depicts a sensing service configuration via sensing enablement client.

[0029] FIG. 11 depicts a sensing input collection and sensing output reporting.

[0030] FIG. 12 depicts an example GUI for sensing enablement service request.

[0031] FIG. 13 depicts an example GUI for sensing outputs of object detection.

[0032] FIG. 14A depicts an example communications system in which the methods and apparatuses described and claimed herein may be an aspect of.

[0033] FIG. 14B depicts a block diagram of an example apparatus or device configured for wireless communications.

[0034] FIG. 14C depicts a system diagram of an example radio access network (RAN) and core network.

[0035] FIG. 14D depicts a system diagram of another example RAN and core network.

[0036] FIG. 14E depicts a system diagram of another example RAN and core network.

[0037] FIG. 14F depicts a block diagram of an example computing system.

[0038] FIG. 14G depicts a block diagram of another example communications system.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

[0039] FIG. 3 shows the sensing signals and sensing data/ result that can be transmitted among relevant entities within a proposed 3GPP system enabled with sensing capabilities. The proposed 3GPP system may include both 3GPP wireless sensing and other sensing technologies. [0040] A sensing device is a device or sensor that is capable of transmitting sensing signals and/or receiving reflected/refracted/diffracted/scattered sensing signals to collect sensing data and generate sensing results. Sensing data/result can be provided by either 3GPP UEs or non- 3GPP devices/sensors. The sensing data collected by the sensing devices can be transmitted via 3GPP or non-3GPP networks. Sensing devices may consist of UEs and RAN nodes as well as non-3GPP devices/sensors.

[0041] A sensing object is an object that may reflect/refract/diffract/scatter sensing signals and therefore is sensed by sensing devices. A sensing object does not need to be connected to the network (i.e., it may be passive object).

[0042] The sensing data/result is usually associated or combined with assistance information to generate processed sensing results. Assistance information may be provided to the sensing service and include characteristics of objects, UE identify information, approximate location/position of objects, sensing area, sensing result requirements, etc. As shown in FIG. 4, sensing data/result and assistance information are collected as sensing inputs, based on which sensing output, including processed sensing result and contextual information, can be generated and exposed to the service consumer (e.g., a VAL server), where contextual information may be exposed with the sensing results to provide context to the conditions under which the sensing results were derived. Depending on the sensing type, the required data or information for sensing input may differ.

Sensing Enablement Service Architecture

[0043] FIG. 5 illustrates a proposed architecture for supporting sensing enablement services within the context of a 3GPP system. The sensing enablement service architecture may support sensing enablement client(s) and server(s). A sensing enablement server may allows VAL servers to access the sensing capabilities provided by the 3GPP system. The sensing enablement server may also be accessed by sensing enablement client(s) on behalf of VAL clients which interface to the sensing enablement client(s). The sensing enablement server may interface to other functions and services in a 3GPP system, such as SEAL location management server/client, (application layer) data collection and coordination function, analytics serv ice (e.g. NWDAF, AD AES), etc.

[0044] The UE may be a sensing device, a sensing object, a sensing enablement service consumer, or a combination thereof. [0045] Via the interfaces shown in FIG. 5, the sensing enablement server and client may support one or more features defined herewithin. One or more of the interfaces may be mapped to existing interfaces defined in a 3GPP system. These existing interfaces may be enhanced with one or more of the features defined herewithin.

[0046] Note, one skilled in the art will recognize that the architecture shown in FIG. 5 is not intended to limit or exclude other possible architectural options for supporting sensing enablement services within a 3 GPP system. For example, alternatively the sensing enablement functionality may be realized as features of other services within a 3GPP system such as but not limited to a location management service, XR service, metaverse service, etc. [0047] Note that the sensing enablement sendees shown in FIG. 5 and described herein may also be deployed by a cloud service provider offering sensing services which may or may not communicate with a 3 GPP network. The cloud service provider may expose APIs for application servers or clients to access the sensing enablement service described herewithin.

[0048] Note, one skilled in the art will also recognize that the term client and server referenced throughout may be realized as software deployed on one or more network apparatuses comprising processor(s), memory, and network interface(s). The apparatuses may be deployed as cloud apparatuses, edge apparatuses, or device apparatuses. One or more servers and/or clients of the same or different ty pe may be deployed on a single apparatus. A single server or client may be split and deployed across multiple apparatuses. The functionality of one type of server or client may be combined or consolidated with the functionality of another type of server or client and deployed together with one another on one or more apparatuses.

Sensing Enablement Service Procedure

[0049] FIG. 6 provides an overview of the sensing enablement service procedure.

[0050] Step 1 : A UE acting as a sensing device and/or a sensing object and hosting a sensing enablement client may provide information to the sensing enablement server via a registration procedure. For example, the sensing enablement client on the UE may register to the sensing enablement server to provide such information. The information may include the sensing capability of the UE (as a sensing device), characteristics of the UE, the UE’s consent/authorization of being sensed (as a sensing object), etc. [0051] Step 2: A VAL server/client (or an application enablement layer server/client) may initiate a sensing enablement service request to the sensing enablement server/client. The request may specify information such as sensing requirements, when sensing should be triggered, what type of sensing is required, which area is to be sensed, what object is to be sensed, required KPI, etc.

[0052] Step 3: Based on the sensing enablement sen ice request, the sensing enablement server may determine the sensing service configuration and communicate with the sensing data sources, such as the core network and/or UEs (as sensing devices). The sensing enablement server may also interact with the other enablement layer entities to obtain information, based on which the sensing service configuration may be determined. The sensing enablement server may determine what sensing data/result and assistance information needs to be collected and generated with the corresponding data/information sources.

[0053] Step 4: The sensing enablement server/client may collect the required sensing data/result and assistance information from the corresponding sources. The sensing enablement server/client may further process the sensing results to generate sensing output. What data/information should be included in the sensing input and output may depend on the requested types of sensing.

[0054] Step 5: Due to dynamics in the network or UEs, the sensing enablement server may determine to update the sensing service configuration. The sensing enablement server may also determine to update the configuration based on sensing results.

[0055] Step 6: The sensing enablement server/client may generate a notification including the sensing output and send the notification to the requesting VAL server/client.

Sensing Enablement Client Registration

[0056] This section elaborates the details of sensing enablement client registration procedure (step 1 of FIG. 6).

[0057] Pre-condition: The sensing enablement client and/or server has been provisioned with information of the UE (by the VAL client/server or core network).

[0058] Step 1: The sensing enablement client on the UE may send a sensing enablement client registration request to the sensing enablement server. Alternatively, a sensing enablement client registration request may be initiated by a VAL sen' er or VAL client (not shown in the figure). The registration request may include information as shown in Table 1. One skilled in the art will recognize that a sensing enablement client registration request may be comprised of additional information elements not captured in Table 1, such as expiration time of the registration, security credentials for authorizing the requestor, etc. One skilled in the art will also recognize that a sensing enablement client may share this information with a sensing enablement server via other types of requests not shown in the figure.

Table 1. Sensing enablement client registration request

[0059] Step 2: The sensing enablement server processes the sensing enablement client registration request. The sensing enablement server may interact with other entities in the network to obtain further information of the UE. For example, the sensing enablement server may obtain UE's location information from the core network or a SEAL location management server. The sensing enablement server may create a sensing enablement client profile to maintain information of the sensing capabilities and requirements of the UE.

[0060] Step 3: The sensing enablement server sends a sensing enablement client registration response to the sensing enablement client. The response may include an indicator of whether the registration is successful and a registration ID for successful registration. One skilled in the art will recognize that other types of responses may be returned to the sensing enablement client if the request sent to the sensing enablement serv er was not a registration request.

[0061] If the sensing enablement clients are deployed in an edge data network, the sensing enablement client information can be provided to the sensing enablement service via an edge enabler client (EEC) registration procedure and exposed to the sensing enablement servers (as edge enablement servers or edge application servers). The information referred to in Table 1 may be grouped together as a sensing policy to be communicated within the edge enabler layer.

[0062] A registration update procedure may be performed if there are any changes to the sensing enablement client information (or the UE which hosts the sensing enablement client). Sensing Enablement Service Request

[0063] This section elaborates the details of sensing enablement service request procedure (step 2 of FIG. 6).

[0064] Step 1: The sensing enablement service consumer (e.g. VAL server/client, an application enablement layer server/client) may send a sensing enablement service (e.g., subscription) request to the sensing enablement server. If the consumer is a VAL client, the request may be sent to the sensing enablement client first and then forwarded to the sensing enablement server. The sensing enablement service request may include information shown in Table 2. One skilled in the art will recognize that sensing enablement service request may be comprised of additional information elements not captured in Table 2, such as expiration time of the request, security credentials for authorizing the requestor, etc.

Table 2. Sensing enablement service request

[0065] Step 2: The sensing enablement server processes the sensing enablement service request. The sensing enablement server may create a sendee instance profile to maintain information of the sensing enablement service instance associated with this request.

[0066] Step 3: The sensing enablement server sends a sensing enablement service response to the consumer. The response may include an indicator of whether the request is accepted and information of the corresponding service instance (e.g. ID, profile).

Sensing Service Configuration

[0067] After receiving a sensing enablement service request, the sensing enablement server may configure sensing services accordingly to perform sensing and generate sensing data/result This section elaborates the details of sensing service configuration procedure (step 3 and step 5 of FIG. 6).

[0068] The sensing enablement server may interact with the core network to configure the sensing services, as shown in FIG. 9.

[0069] Pre-condition: The sensing enablement server has been authorized to be able to configure the sensing services with the core network.

[0070] Step 1: Based on the received sensing enablement sendee request, the sensing enablement server determines the configuration of the required sensing services, such as what sensing data/result is required and the corresponding sources, what assistance information is required and the corresponding sources, when/where the sensing operations should be performed, which UEs should be used as sensing devices, etc. In order to determine the sensing service configuration, the sensing enablement server may perform operations such as the below.

[0071] The sensing enablement server may interact with other entities in the system to obtain information for determining the configuration. For example, in order to determine the sensing trigger conditions or sensing area, the sensing enablement server may obtain location information of one or more relevant UEs from location services.

[0072] The sensing enablement server may map the sensing types specified in the sensing enablement service request to the sensing IDs (APIs) defined by the core network. One sensing type may map to a combination of multiple sensing IDs.

[0073] The sensing enablement server may determine the sensing area where sensing is to be performed. If the sensing area is not specified in the sensing enablement service request, the sensing enablement server may identify the sensing area based on the sensing trigger conditions and/or other information in the request such as the location of the sensing object. [0074] The sensing enablement server may determine the sensing period of when sensing is to be performed. If the sensing period is not specified in the sensing enablement service request, the sensing enablement server may identify⁷ the sensing period based on the sensing trigger conditions and/or other information in the request.

[0075] The sensing enablement server may map the requirements defined in the sensing enablement service request to sensing requirements defined by the core network. For example, the sensing enablement server may determine how many sources are needed to generate/provide sensing data or results according to the performance requirements (e.g. required accuracy, granularity, confidence level).

[0076] The sensing enablement server may determine the sensing UEs (as sensing device) based on the sensing data source specified in the sensing enablement sendee request and/or sensing device information of the registered sensing UEs.

[0077] The sensing enablement server may provide sensing object information to the core network if needed.

[0078] The sensing enablement server may determine whether to directly collect sensing result from the core network, or to leverage data collection functions from the core network (e.g. NWDAF, DCCF), or a combination of different methods. If a data collection function is to be used, the sensing enablement server may configure the data collection function accordingly (e.g. creating a subscription).

[0079] One sensing enablement service request may result in more than one sensing service configurations. For example, the sensing area or sensing trigger condition may indicate that sensing data/result from different locations (sub-areas) are needed. The sensing enablement server may determine multiple sensing service configurations with each of them targeting one of the locations.

[0080] The sensing enablement server may coordinate and aggregate multiple sensing enablement service requests into one sensing service configuration, e.g. when the requests share the same sensing area or sensing period.

[0081] If non-3GPP sensing data/result is also needed to be collected, the sensing enablement server may determine when and where to collect the non-3GPP sensing data/result. For example, the sensing enablement server may determine that non-3GPP data can be collected from a UE or a repository, as specified by the consumer in the sensing enablement service request (“sensing data source’⁷).

[0082] Step 2: Based on the determined sensing service configuration, the sensing enablement server may send one or more sensing service configuration requests to the core network to request for sensing data/result. The sensing service configuration request may include information shown in Table 3. One skilled in the art will recognize that sensing service configuration request may be comprised of additional information elements not captured in Table 3. Table 3. Sensing service configuration request

[0083] Step 3: The sensing enablement server receives a sensing service configuration response.

[0084] Step 4: The sensing service configuration may need to be updated due to dynamics of UEs or the network such as:

[0085] • According to the trigger condition of the sensing enablement service request, the required sensing area or sensing schedule may change. The sensing enablement server may update the sensing area/schedule accordingly.

[0086] • The sensing UE’s capabilities may change, which may lead to an update of the sensing service configuration, such as replacing unavailable sensing UEs with available UEs, updating the list of suggested sensing UEs.

[0087] • The sensing service configuration may be updated as sensing data/result and assistance information is collected or sensing result is generated. For example, the sensing operation interval (sensing period) may be updated when an object is detected.

[0088] Step 5: The sensing enablement server may send a sensing service configuration request to the core network with updated configurations. [0089] Step 6: The sensing enablement server receives a sensing service configuration response.

[0090] The sensing enablement server may send a notification to the consumer or notification targets on the determined sendee configuration or updates of configuration. [0091] As shown in FIG. 9, the sensing enablement server may perform sensing service configuration with the core network, which is the sensing data source. The sensing enablement server may also perform a configuration procedure with the sensing enablement client to provide instructions to a UE (as sensing device) on collecting sensing data and generating sensing result, as shown in FIG. 10. It is assumed that the sensing enablement client has registered with the sensing enablement server of its support for sensing operations as described by FIG. 7.

[0092] Step 1: Similar to step 1 of FIG. 9, the sensing enablement server determines the configuration for the UE which is operating as a sensing device to provide sensing data/results.

[0093] Step 2: The sensing enablement server may send one or more sensing service configuration requests to the sensing enablement client hosted on the UE to request for sensing data/results. The request may include information shown in Table 3. After receiving the request, the sensing enablement client may send the configuration information to the application clients hosted on the UE which support sensing capabilities.

[0094] Step 3: The sensing enablement server receives a sensing service configuration response from the sensing enablement client.

[0095] Step 4: A sensing enablement client registration update procedure may be performed between the sensing enablement client and server when there are any changes to the sensing enablement client information or the UE, such as changes of sensing capability or availability.

[0096] Step 5: The sensing enablement client registration update procedure or other conditions (as described in step 4 of FIG. 9) may trigger an update of the sensing service configuration. The sensing enablement server may determine the updated configuration. [0097] Step 6: The sensing enablement server may send a sensing service configuration request to the sensing enablement client with updated configurations. The request may include information shown in Table 3. [0098] Step 7 : The sensing enablement server receives a sensing service configuration response from the sensing enablement client.

Sensing Input Collection and Output Reporting

[0099] After or during sensing service configuration, the sensing enablement server may collect and receive sensing data/result and assistance information from the core network and/or other entities in the vertical application layer and application enablement layer. This section elaborates the detailed procedure of collecting sensing input and generating sensing output (step 4 and step 6 of FIG. 6).

[00100] Pre-condition: The sensing devices have been configured to perform sensing and provide sensing result.

[00101] Step 1: The sensing enablement server may receive sensing results from the core network and/or sensing devices (e.g. UEs and non-3GPP devices). For example, the sensing enablement server may create a subscription to the core network and receive notifications which includes the sensing result. The sensing enablement server may also receive or request for other assistance information from the core network. Alternatively, the sensing enablement server may receive sensing results from data collection functions (e.g., NWDAF) in the core network if they have been configured to collect sensing result.

[00102] Step 2: The sensing enablement server may send a notification or request to the VAL server (which could be the consumer that is requesting the sensing enablement service) to request for assistance information. Details on what sensing assistance information is to be collected may depend on the sensing type and other requirements in the sensing enablement service request.

[00103] Step 3: The sensing enablement server may send a notification or request to other application enablement layer functions to request for assistance information, such as SEAL location service, AD AES, etc. The sensing enablement server may either receive sensing assistance information from such functions, or leverage data collection functions in the application enablement layer (e.g. AD AES, A-DCCF) to collect the required information. [00104] Step 4: The sensing enablement server may send a notification or request to the sensing enablement client to request assistance information from the UE. The sensing enablement server may also request sensing data/result from the UE via the sensing enablement client if the UE is capable of providing sensing data/result (such as non-3GPP sensing data). [00105] Step 5: The sensing enablement server processes the collected sensing inputs (sensing data/result and assistance information) to generate the required sensing output. Depending on the sensing type, the sensing enablement server may perform different operations to process the sensing inputs. The sensing enablement server may aggregate notifications and/or responses received from various entities to generate sensing outputs. The sensing enablement server may associate the sensing data/result with the specific context of various verticals or scenarios (which may be derived from the assistance information). Further, the sensing enablement server may perform operations according to the ‘"processing operations’’, and/or generate sensing outputs according to the required ‘'output format” specified in the sensing enablement service request.

[00106] Step 6: The sensing enablement server may send a notification of sensing output to the consumer and/or notification target according to the notification setting configured in the sensing enablement service request. In addition to sending notifications of sensing output, the sensing enablement server may send a notification to the consumer or notification target regarding the (update of) configuration of the sensing sendee, if required by the consumer. [00107] As shown in FIG. 11, the sensing input collection and/or processing may be performed mainly by the sensing enablement server. One skilled in the art will recognize that the operations of collecting sensing input and processing the collected data/information may also be performed by the sensing enablement client.

Sensing-Based Object Detection

[00108] This section describes detailed information of the sensing input, (default) sensing output and the corresponding procedure for sensing-based object detection.

[00109] When requesting for sensing-based object detection, the consumer may indicate in the sensing enablement service request:

[00110] • Sensing type = “object detection” or other sensing ty pes that may require the result of object detection;

[00111] • Description of the object to be detected or object of interest, e.g. size (height) of a human (intruder/thief), size and shape of an animal, size and velocity of a UAV;

[00112] • Description of objects that are not of interest, which are objects that are present or can be detected by sensing operations but will be excluded from the sensing output, e.g. a delivery person that is expected to appear at the front door (non-intruder), planned route of a UAV or aircraft; [00113] • Other information as described in Table 2.

[00114] In order to generate sensing output for object detection, the sensing enablement service may collect sensing inputs as listed in Table 4. Some of the sensing inputs may be provided by the consumer in the sensing enablement service (Table 2), and the rest of the information may be collected by the sensing enablement server (as shown in FIG. 11). In addition to sensing data/result, the sensing enablement service may collect assistance information which can be used to enhance sensing outputs by removing objects detected in the sensing area that are not of interest, providing value-added service.

Table 4. Sensing input for object detection

[00115] The sensing enablement service may process the sensing input and expose the generated result to the requesting consumer. The sensing enablement serv ice may associate the collected assistance information with objects detected in the sensing result. For example, the sensing enablement service may compare the characteristics of a detected object with the information of the object of interest or objects not of interest to determine whether the detected object is of interest to the consumer or should be excluded from the sensing output. The sensing enablement service may also use assistance information to associate a detected object with known entities to identify the object.

[00116] Table 5 shows an example sensing output of an object detection service. Table 5. Sensing output for object detection

[00117] Note that information in Table 5 may be organized or structured differently than as shown in the table, depending on the “output format” specified by the consumer in the sensing enablement service request. For example, the sensing output may record only the first time when the object of interest is detected and the instantaneous measurement taken at that time instance.

Example Solution for Use Case in FIG. 1

[00118] In this example, a user may request for sensing enablement service via a VAL client or server (consumer). The requesting VAL client/server may specify in the request for object detection as part of intruder detection for a home. The request may provide object characteristics such as the average measurements of a human body for the sensing object. The consumer may specify the sensing area to be the area around the user’s house such as the sizes of the front, side and back yards., and a sensing period, which may be set at five-second intervals. The consumer may further specify sensing exclusion events, which may be represented as a delivery service scheduled at around 5pm and providing the application ID of the delivery service. The consumer may further specify a sensing trigger condition that if a package (left by the delivery person) is detected in the sensing area, the sensing interval should be updated to one second.

[00119] At around 5pm, the sensing result may indicate a person and a vehicle appearing in the sensing area. The sensing enablement service may query the delivery serv ice (VAL server) if a vehicle is sent to the location at the sensing area and requests the UE identifier associated with the vehicle. The sensing enablement service may then look for location information of the vehicle UE (e.g. using location service from the 3GPP network) and determine the detected vehicle is associated the delivery' service. Alternatively, if the delivery vehicle has registered to the sensing enablement service as a sensing object, the sensing enablement service may determine the UE is (associated with) a delivery vehicle based on the sensing object information provided in the sensing enablement client registration request (UE identifier, object description).

[00120] After the delivery⁷, the package may be detected by the sensing enablement service, which may trigger the update of sensing service configuration. The sensing enablement service may send an updated sensing service configuration request specifying the updated sensing frequency. Optionally, the sensing enablement service may configure additional sensing UEs to the core network or configure sensing devices (which may provide non-3GPP sensing data/results) to support the increased sensing frequency.

Example Solution for Use Case in FIG. 2

[00121] In this example, the user may request for sensing enablement service via a VAL client or server (consumer). The requesting VAL client/server may specify the sensing area to be a circular area surrounding the user’s car, providing a UE identifier associated with the car. The consumer may further specify' that vehicles on the opposite lane and vehicles that are moving in the same direction at a speed within the speed limit are objects not of interest.

[00122] The sensing enablement service may determine the sensing area by first obtaining the location (and the predicted location) information of the user’s car, and then determining the radius of the sensing area based on the real-time weather conditions (which can be obtained by requesting from the VAL server). The sensing result may indicate that multiple vehicles are detected in the sensing area and provide information of their positions and velocities, then the sensing enablement service may filter out objects not of interest based on the consumer’s request. When the weather condition changes, the consumer may send an updated sensing enablement sendee request to increase the required sensing radius. As a result, the sensing enablement serv ice may update the sensing service configuration to change the radius of the sensing area.

Example Communications System

[00123] The 3rd Generation Partnership Project (3GPP) develops technical standards for cellular telecommunications network technologies, including radio access, the core transport network, and service capabilities - including work on codecs, security, and quality of service. Recent radio access technology (RAT) standards include WCDMA (commonly referred as 3G), LTE (commonly referred as 4G), LTE- Advanced standards, and New Radio (NR), which is also referred to as “5G”. 3GPP NR standards development is expected to continue and include the definition of next generation radio access technology (new RAT), which is expected to include the provision of new flexible radio access below 7 GHz, and the provision of new ultra-mobile broadband radio access above 7 GHz. The flexible radio access is expected to consist of a new, non-backwards compatible radio access in new spectrum below 7 GHz, and it is expected to include different operating modes that may be multiplexed together in the same spectrum to address a broad set of 3GPP NR use cases with diverging requirements. The ultra-mobile broadband is expected to include cmWave and mmWave spectrum that will provide the opportunity for ultra-mobile broadband access for, e.g., indoor applications and hotspots. In particular, the ultra-mobile broadband is expected to share a common design framework with the flexible radio access below 7 GHz, with cmWave and mmWave specific design optimizations.

[00124] 3GPP has identified a variety of use cases that NR is expected to support, resulting in a wide variety of user experience requirements for data rate, latency, and mobility. The use cases include the following general categories: enhanced mobile broadband (eMBB) ultrareliable low-latency Communication (URLLC). massive machine type communications (mMTC), network operation (e g., network slicing, routing, migration and interworking, energy savings), and enhanced vehicle-to-eveiything (eV2X) communications, which may include any of Vehicle-to-Vehicle Communication (V2V), Vehicle-to-Infrastructure Communication (V2I), Vehicle-to-Network Communication (V2N), Vehicle-to-Pedestrian Communication (V2P), and vehicle communications with other entities. Specific service and applications in these categories include, e.g., monitoring and sensor networks, device remote controlling, bi-directional remote controlling, personal cloud computing, video streaming, wireless cloud-based office, first responder connectivity , automotive ecall, disaster alerts, real-time gaming, multi-person video calls, autonomous driving, augmented reality, tactile internet, virtual reality, home automation, robotics, and aerial drones to name a few. All of these use cases and others are contemplated herein.

[00125] FIG. 14A illustrates an example communications system 100 in which the methods and apparatuses described and claimed herein may be an aspect of. As shown, the example communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, and/or 102g (which generally or collectively may be referred to as WTRU 102), a radio access netw ork (RAN) 103/104/105/103b/l 04b/l 05b, a core network 106/107/109, a public switched telephone network (PSTN) 108, the Internet 110, other networks 112, and V2X server (or ProSe function and server) 113, though it will be appreciated that the disclosed examples contemplate any number of WTRUs, base stations, networks, and/or network elements. Each ofthe WTRUs 102a, 102b, 102c, 102d, 102e, 102f, 102g may be any ty pe of apparatus or device configured to operate and/or communicate in a wireless environment. Although each WTRU 102a, 102b. 102c, 102d, 102e, 102f, 102g is depicted in FIGs 14A-14E as a hand-held wireless communications apparatus, it is understood that with the wide variety of use cases contemplated for 5G wireless communications, each WTRU may comprise or be embodied in any type of apparatus or device configured to transmit and/or receive wireless signals, including, by w ay of example only, user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a tablet, a netbook, a notebook computer, a personal computer, a wireless sensor, consumer electronics, a wearable device such as a smart watch or smart clothing, a medical or eHealth device, a robot, industrial equipment, a drone, a vehicle such as a car, truck, train, or airplane, and the like.

[00126] The communications system 100 may also include a base station 114a and a base station 114b. Base stations 114a may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 110, and/or the other networks 112. Base stations 114b may be any type of device configured to wiredly and/or wirelessly interface with at least one of the RRHs (Remote Radio Heads) 118a, 118b, TRPs (Transmission and Reception Points) 119a, 119b, and/or RSUs (Roadside Units) 120a and 120b to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 110, the other networks 112, and/or V2X server (or ProSe function and server) 113. RRHs 118a. 118b may be any type of device configured to wirelessly interface with at least one of the WTRU 102c, to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 110, and/or the other networks 112. TRPs 119a, 119b may be any ty pe of device configured to wirelessly interface with at least one of the WTRU 102d, to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 110, and/or the other networks 112. RSUs 120a and 120b may be any type of device configured to wirelessly interface with at least one of the WTRU 102e or 102f, to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 110, the other networks 112, and/or V2X server (or ProSe function and server) 113. By way of example, the base stations 114a, 1 14b may be a base transceiver station (BTS), aNode-B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a. 114b may include any number of interconnected base stations and/or network elements.

[00127] The base station 114a may be part of the RAN 103/104/105, which may also include other base stations and/or netw ork elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114b may be part of the RAN 103b/ 104b/ 105b, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a may be configured to transmit and/or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The base station 114b may be configured to transmit and/or receive wired and/or wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, the base station 114a may include three transceivers, e.g., one for each sector of the cell. In some cases, the base station 114a may employ multiple-input multiple output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.

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

[00129] The base stations 114b may communicate with one or more of the RRHs 118a, 118b, TRPs 119a, 119b, and/or RSUs 120a and 120b, over a wired or air interface

115b/l 16b/l 17b. which may be any suitable wired (e.g., cable, optical fiber, etc.) or wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). The air interface 115b/l 16b/l 17b may be established using any suitable radio access technology (RAT).

[00130] The RRHs 118a, 118b, TRPs 119a, 119b and/or RSUs 120a, 120b. may communicate with one or more of the WTRUs 102c, 102d, 102e, 102f over an air interface 1 15c/l 16c/l 17c, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). The air interface 115c/l 16c/l 17c may be established using any suitable radio access technology (RAT).

[00131] The WTRUs 102a, 102b, 102c, 102d, 102e, 102f, and/or 102g may communicate with one another over an air interface 115d/l 16d/l 17d (not shown in the figures), which may be any suitable wireless communication link (e.g.. radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). The air interface

1 15d/l 16d/l 17d may be established using any suitable radio access technology (RAT). [00132] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 103/104/105 and the WTRUs 102a, 102b. 102c. or RRHs 1 18a, 118b, TRPs 119a, 119b and RSUs 120a, 120b, in the RAN 103b/104b/105b and the WTRUs 102c, 102d, 102e, 102f, may implement a radio technology⁷ such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115/116/117 or 115c/l 16c/l 17c respectively using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink Packet Access (HSDPA) and/or High-Speed Uplink Packet Access (HSUPA). [00133] In some cases, the base station 114a and the WTRUs 102a, 102b, 102c, or RRHs 118a. 118b, TRPs 119a, 119b, and/or RSUs 120a, 120b, in the RAN 103b/104b/105b and the WTRUs 102c, 102d. may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 115/116/117 or 115c/l 16c/l 17c respectively using Long Term Evolution (LTE) and/or LTE-Advanced (LTE-A). In the future, the air interface 115/116/117 may implement 3GPP NR technology. The LTE and LTE-A technology includes LTE D2D and V2X technologies and interface (such as Sidelink communications, etc.) The 3GPP NR technology includes NR V2X technologies and interface (such as Sidelink communications, etc.)

[00134] In some cases, the base station 114a in the RAN 103/104/105 and the WTRUs 102a. 102b, 102c, or RRHs 118a, 118b, TRPs 119a. 119b and/or RSUs 120a. 120b, in the RAN 103b/l 04b/l 05b and the WTRUs 102c, 102d, 102e, 102f may implement radio technologies such as IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS- 2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM). Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[00135] The base station 114c in FIG. 14A may be a wireless router, Home Node B, Home eNode B. or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, and the like. In some cases, the base station 114c and the WTRUs 102e, may implement a radio technology such as IEEE 802. 11 to establish a wireless local area network (WLAN). In some cases, the base station 114c and the WTRUs 102d, may implement a radio technology such as IEEE 802. 15 to establish a wireless personal area network (WPAN). In some cases, the base station 114c and the WTRUs 102e, may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell. As shown in FIG. 14A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114c may not be required to access the Internet 110 via the core network 106/107/109.

[00136] The RAN 103/104/105 and/or RAN 103b/104b/105b may be in communication with the core network 106/107/109, which may be any type of netw ork configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. For example, the core network 106/107/109 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication.

[00137] Although not shown in FIG. 14A, it will be appreciated that the RAN 103/104/105 and/or RAN 103b/104b/105b and/or the core netw ork 106/107/109 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 103/104/105 and/or RAN 103b/l 04b/105b or a different RAT. For example, in addition to being connected to the RAN 103/104/105 and/or RAN 103b/104b/105b, which may be utilizing an E-UTRA radio technology , the core network 106/107/109 may also be in communication with another RAN (not shown) employing a GSM radio technology.

[00138] The core network 106/107/109 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d, 102e to access the PSTN 108, the Internet 110, and/or other networks 112. The PSTN 108 may include circuit-switched telephone netw orks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and the internet protocol (IP) in the TCP/IP internet protocol suite. The netw orks 112 may include wired or wireless communications networks owned and/or operated by other service providers. For example, the networks 112 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 103/104/105 and/or RAN 103b/104b/105b or a different RAT.

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

[00140] FIG. 14B is a block diagram of an example apparatus or device configured for wireless communications in accordance with the aspects illustrated herein, such as for example, a WTRU 102. As shown in FIG. 14B, the example WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 113, a display /touchpad/indicators 128, non-removable memory 130, removable memory 132. a power source 134. a global positioning system (GPS) chipset 136, and other peripherals 138. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an example. Also, in some cases the base stations 114a and 114b, and/or the nodes that base stations 114a and 114b may represent, such as but not limited to transceiver station (BTS), aNode-B, a site controller, an access point (AP), a home node-B, an evolved home node-B (eNodeB), a home evolved node-B (HeNB), a home evolved node-B gateway, and proxy nodes, among others, may include some or all of the elements depicted in FIG. 14B and described herein.

[00141] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While FIG. 14B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip. [00142] The transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 115/116/117. For example, in some cases, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In some cases, the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. In some cases, the transmit/receive element 122 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.

[00143] In addition, although the transmit/receive element 122 is depicted in FIG. 14B as a single element, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology⁷. Thus, in some cases, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115/116/117.

[00144] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802. 11 , for example.

[00145] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/mi crophone 124, the keypad 126, and/or the display/touchpad/indicators 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad/indicators 128. In addition, the processor 118 may access information from, and store data in. any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132. The non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other ty pe of memory storage device. The removable memory⁷ 132 may include a subscriber identity⁷ module (SIM) card, a memory⁷ stick, a secure digital (SD) memory card, and the like. In some cases, the processor 118 may access information from, and store data in, memory⁷ that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[00146] The processor 118 may receive pow er from the power source 134, and may be configured to distribute and/or control the power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries, solar cells, fuel cells, and the like. [00147] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to. or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 115/116/1 17 from a base station (e.g., base stations 114a, 114b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an aspect.

[00148] The processor 1 18 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 138 may include various sensors such as an accelerometer, biometrics (e.g., finger print) sensors, an e- compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port or other interconnect interfaces, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like. [00149] The WTRU 102 may be embodied in other apparatuses or devices, such as a sensor, consumer electronics, a wearable device such as a smart watch or smart clothing, a medical or eHealth device, a robot, industrial equipment, a drone, a vehicle such as a car, truck, train, or airplane. The WTRU 102 may connect to other components, modules, or systems of such apparatuses or devices via one or more interconnect interfaces, such as an interconnect interface that may comprise one of the peripherals 138.

[00150] FIG. 14C is a system diagram of the RAN 103 and the core network 106. As noted above, the RAN 103 may employ a UTRA radio technology to communicate with the WTRUs 102a, 102b. and 102c over the air interface 115. The RAN 103 may also be in communication with the core network 106. As shown in FIG. 14C, the RAN 103 may include Node-Bs 140a, 140b, 140c, which may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 115. The Node-Bs 140a. 140b, 140c may each be associated with a particular cell (not shown) within the RAN 103. The RAN 103 may also include RNCs 142a. 142b. It will be appreciated that the RAN 103 may include any number of Node-Bs and RNCs while remaining consistent with an aspect of the disclosure. [00151] As shown in FIG. 14C, the Node-Bs 140a, 140b may be in communication with the RNC 142a. Additionally, the Node-B 140c may be in communication with the RNC 142b. The Node-Bs 140a, 140b, 140c may communicate with the respective RNCs 142a, 142b via an lub interface. The RNCs 142a, 142b may be in communication with one another via an lur interface. Each of the RNCs 142a, 142b may be configured to control the respective Node-Bs 140a, 140b, 140c to which it is connected. In addition, each of the RNCs 142a, 142b may be configured to carry out or support other functionality, such as outer loop power control, load control, admission control, packet scheduling, handover control, macro-diversity, security functions, data encryption, and the like.

[00152] The core network 106 shown in FIG. 14C may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and/or a gateway GPRS support node (GGSN) 150. While each of the foregoing elements are depicted as part of the core network 106, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[00153] The RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an luCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices.

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

[00155] As noted above, the core network 106 may also be connected to the networks 112, which may include other wired or wireless netw orks that are owned and/or operated by other service providers.

[00156] FIG. 14D is a system diagram of the RAN 104 and the core netw ork 107. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b. and 102c over the air interface 116. The RAN 104 may also be in communication with the core netw ork 107. [00157] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an aspect of the disclosure. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In some cases, the eNode-Bs 160a, 160b, 1 0c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to. and receive wireless signals from, the WTRU 102a.

[00158] Each of the eNode-Bs 160a, 160b, and 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and/or downlink, and the like. As shown in FIG. 14D, the eNode-Bs 160a. 160b, 160c may communicate with one another over an X2 interface.

[00159] The core netw ork 107 shown in FIG. 14D may include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. While each of the foregoing elements are depicted as part of the core network 107, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

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

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

[00162] The serving gatew ay 164 may also be connected to the PDN gateway 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP- enabled devices.

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

[00164] FIG. 14E is a system diagram of the RAN 105 and the core network 109. The RAN 105 may be an access service network (ASN) that employs IEEE 802.16 radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 117. As will be further discussed below, the communication links between the different functional entities of the WTRUs 102a, 102b, 102c, the RAN 105, and the core network 109 may be defined as reference points.

[00165] As shown in FIG. 14E, the RAN 105 may include base stations 180a, 180b, 180c, and an ASN gateway 182, though it will be appreciated that the RAN 105 may include any number of base stations and ASN gateway s while remaining consistent with an aspect of the disclosure. The base stations 180a, 180b, 180c may each be associated with a particular cell in the RAN 105 and may include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 117. In some cases, the base stations 180a, 180b, 180c may implement MIMO technology. Thus, the base station 180a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a. The base stations 180a, 180b, 180c may also provide mobility management functions, such as handoff triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy enforcement, and the like. The ASN gateway 182 may serve as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 109. and the like.

[00166] The air interface 117 between the WTRUs 102a, 102b, 102c and the RAN 105 may be defined as an R1 reference point that implements the IEEE 802.16 specification. In addition, each of the WTRUs 102a, 102b, and 102c may establish a logical interface (not shown) with the core network 109. The logical interface between the WTRUs 102a, 102b, 102c and the core network 109 may be defined as an R2 reference point, which may be used for authentication, authorization, IP host configuration management, and/or mobility management.

[00167] The communication link between each of the base stations 180a, 180b, and 180c may be defined as an R8 reference point that includes protocols for facilitating WTRU handovers and the transfer of data between base stations. The communication link between the base stations 180a, 180b, 180c and the ASN gateway 182 may be defined as an R6 reference point. The R6 reference point may include protocols for facilitating mobility management based on mobility events associated with each of the WTRUs 102a, 102b, 102c. [00168] As shown in FIG. 14E, the RAN 105 may be connected to the core network 109. The communication link between the RAN 105 and the core network 109 may defined as an R3 reference point that includes protocols for facilitating data transfer and mobilitymanagement capabilities, for example. The core network 109 may include a mobile IP home agent (MIP-HA) 184, an authentication, authorization, accounting (AAA) server 186, and a gateway 188. While each of the foregoing elements are depicted as part of the core network 109, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[00169] The MIP-HA may be responsible for IP address management, and may enable the WTRUs 102a, 102b. and 102c to roam between different ASNs and/or different core networks. The MIP-HA 184 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The AAA sen- er 186 may be responsible for user authentication and for supporting user services. The gateway 188 may facilitate interworking with other networks. For example, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. In addition, the gateway 188 may provide the WTRUs 102a, 102b. 102c with access to the networks 112. which may include other wired or wireless networks that are owned and/or operated by other service providers. [00170] Although not shown in FIG. 14E, it will be appreciated that the RAN 105 may be connected to other ASNs and the core network 109 may be connected to other core networks. The communication link between the RAN 105 the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating the mobility of the WTRUs 102a, 102b, 102c betw een the RAN 105 and the other ASNs. The communication link between the core network 109 and the other core netw orks may be defined as an R5 reference, which may include protocols for facilitating interworking between home core networks and visited core networks.

[00171] The core network entities described herein and illustrated in FIGs 14A, 14C, 14D, and 14E are identified by the names given to those entities in certain existing 3GPP specifications, but it is understood that in the future those entities and functionalities may be identified by other names and certain entities or functions may be combined in future specifications published by 3GPP, including future 3GPP NR specifications. Thus, the particular network entities and functionalities described and illustrated in FIGs 14A, 14B, 14C, 14D, and 14E are provided by way of example only, and it is understood that the subject matter disclosed and claimed herein may be embodied or implemented in any similar communication system, whether presently defined or defined in the future.

[00172] FIG. 14F is a block diagram of an exemplary computing system 90 in which one or more apparatuses of the communications netw orks illustrated in FIGs 14A, 14C, 14D and 14E may be embodied, such as certain nodes or functional entities in the RAN 103/104/105, Core Network 106/107/109, PSTN 108, Internet 110, or Other Networks 112. Computing system 90 may comprise a computer or server and may be controlled primarily by computer readable instructions, w hich may be in the form of software, w herever, or by whatever means such software is stored or accessed. Such computer readable instructions may be executed within a processor 91, to cause computing system 90 to do work. The processor 91 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC). a state machine, and the like. The processor 91 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the computing system 90 to operate in a communications network. Coprocessor 81 is an optional processor, distinct from main processor 91, that may perform additional functions or assist processor 91. Processor 91 and/or coprocessor 81 may receive, generate, and process data related to the methods and apparatuses disclosed herein.

[00173] In operation, processor 91 fetches, decodes, and executes instructions, and transfers information to and from other resources via the computing system’s main data- transfer path, system bus 80. Such a system bus connects the components in computing system 90 and defines the medium for data exchange. System bus 80 typically includes data lines for sending data, address lines for sending addresses, and control lines for sending interrupts and for operating the system bus. An example of such a system bus 80 is the PCI (Peripheral Component Interconnect) bus.

[00174] Memories coupled to system bus 80 include random access memory (RAM) 82 and read only’ memory (ROM) 93. Such memories include circuitry that allows information to be stored and retrieved. ROMs 93 generally contain stored data that cannot easily be modified. Data stored in RAM 82 may be read or changed by processor 91 or other hardware devices. Access to RAM 82 and/or ROM 93 may be controlled by memory controller 92. Memory controller 92 may provide an address translation function that translates virtual addresses into physical addresses as instructions are executed. Memory controller 92 may also provide a memory⁷ protection function that isolates processes within the system and isolates system processes from user processes. Thus, a program running in a first mode may access only memory mapped by its own process virtual address space; it cannot access memory within another process’s virtual address space unless memory sharing between the processes has been set up.

[00175] In addition, computing system 90 may contain peripherals controller 83 responsible for communicating instructions from processor 91 to peripherals, such as printer 94, keyboard 84, mouse 95, and disk drive 85.

[00176] Display 86, which is controlled by display controller 96, is used to display visual output generated by computing system 90. Such visual output may include text, graphics, animated graphics, and video. The visual output may be provided in the form of a graphical user interface (GUI). Display 86 may be implemented with a CRT-based video display, an LCD-based flat-panel display, gas plasma-based flat-panel display, or a touch-panel. Display controller 96 includes electronic components required to generate a video signal that is sent to display 86. [00177] Further, computing system 90 may contain communication circuitry, such as for example a network adapter 97, that may be used to connect computing system 90 to an external communications network, such as the RAN 103/104/105, Core Network 106/107/109, PSTN 108, Internet 110, or Other Networks 1 12 of FIGs 14A, 14B, 14C, 14D, and 14E, to enable the computing system 90 to communicate with other nodes or functional entities of those networks. The communication circuitry, alone or in combination with the processor 91. may be used to perform the transmitting and receiving steps of certain apparatuses, nodes, or functional entities described herein.

[00178] FIG. 14G illustrates an example communications system 1 11 in which the methods and apparatuses described and claimed herein may be an aspect of. As shown, the example communications system 111 may include wireless transmit/receive units (WTRUs) A, B, C, D, E. F, a base station, a V2X server, and a RSUs A and B, though it will be appreciated that the disclosure contemplates any number of WTRUs, base stations, networks, and/or network elements. One or several or all WTRUs A, B, C, D, E can be out of range of the network (for example, in the figure out of the cell coverage boundary show n as the dash line). WTRUs A, B, C form a V2X group, among which WTRU A is the group lead and WTRUs B and C are group members. WTRUs A, B, C, D, E, F may communicate over Uu interface or Sidelink (PC5) interface.

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

Definitions

[00180] Provided below are definitions for abbreviations found within the body of the disclosure.

[00181] Provided below are definitions for terms found within the body of the disclosure.

Claims

What is claimed:

1. An apparatus comprising: one or more processors; memory; and a set of computer-executable instructions stored in the memory that, when executed by the one or more processors, cause: receiving, from a consumer, a request for a sensing enablement service, wherein the request comprises descriptions of a target object to be detected; sending, to a sensing data source, a request for configuring the sensing data source based on the request for a sensing enablement service; receiving sensing results in response to the request for configuring the sensing data source; generating sensing outputs based on at least the received sensing results, wherein the sensing outputs comprises an indicator of whether the target obj ect is detected; and sending, to a notification target specified by the consumer, a message comprising the generated sensing outputs.

2. The apparatus of claim 1, wherein the consumer comprises an application server.

3. The apparatus of claim 1, wherein the descriptions of the target object comprise one or more of a size of the target object, a shape of the target object, a location of the target object, an identifier of a UE associated with the target object, an identifier of an application associated with the target object, or a combination thereof.

4. The apparatus of claim 1, wherein the request for a sensing enablement service further comprises information of objects other than the target object potentially detected by the sensing data source.

5. The apparatus of claim 1 , wherein the request for a sensing enablement service further comprises information of an area to be sensed.

6. The apparatus of claim 1, wherein the request for a sensing enablement service further comprises information of a time period to perform sensing.

7. The apparatus of claim 1 , wherein the request for a sensing enablement service further comprises information of conditions to trigger sensing.

8. The apparatus of claim 1, wherein the sensing data source comprises a 3GPP sensing function.

9. The apparatus of claim 1, wherein the sensing data source comprises a UE.

10. The apparatus of claim 1, wherein the message sent to the notification target further comprises location and mobility information of the detected object.

11. A method comprising: receiving, from a consumer, a request for a sensing enablement service, wherein the request comprises descriptions of a target object to be detected; sending, to a sensing data source, a request for configuring the sensing data source based on the request for a sensing enablement service; receiving sensing results in response to the request for configuring the sensing data source; generating sensing outputs based on at least the received sensing results, wherein the sensing outputs comprises an indicator of whether the target object is detected; and sending, to a notification target specified by the consumer, a message comprising the generated sensing outputs.

12. The method of claim 11, wherein the consumer comprises an application server.

13. The method of claim 11, wherein the descriptions of the target object comprise one or more of a size of the target object, a shape of the target object, a location of the target object, an identifier of a UE associated with the target object, an identifier of an application associated with the target object, or a combination thereof.

14. The method of claim 11, wherein the request for a sensing enablement service further comprises information of objects other than the target object potentially detected by the sensing data source.

15. The method of claim 11, wherein the request for a sensing enablement service further comprises information of an area to be sensed.

16. The method of claim 11, wherein the request for a sensing enablement service further comprises information of a time period to perform sensing.

17. The method of claim 11, wherein the request for a sensing enablement service further comprises information of conditions to trigger sensing.

18. The method of claim 11, wherein the sensing data source comprises a 3GPP sensing function.

19. The method of claim 1 1, wherein the sensing data source comprises a UE.

20. The method of claim 11, wherein the message sent to the notification target further comprises location and mobility information of the detected object.