[AA-4.1-a] [AA-4.1-b]

This sub-clause specifies the functional requirements for any application enablers referred in the TR. [AR-4.2-a] [AR-4.2-b] [AR-4.2-c] [AR-4.2-d] [AR-4.2-e] [AR-4.2-f] [AR-4.2-g] [AR-4.2-h] [AR-4.2-i] [AR-4.2-j]

Geofencing is a type of location-based marketing and advertising. A mobile app or software uses e.g. the Global Positioning System (GPS), radio frequency identification (RFID), Wi-Fi or cellular data to define a virtual geographical boundary and trigger a specific alert or push notification when a device enters or exits that boundary. This boundary is known as a geofence. Furthermore, Geofencing also has a widespread use in the industrial field. In Rel-17 and Rel-18, the Location Management architecture and functional model in SEAL have introduced and supported the "Location report trigger with location area criteria", "Monitoring Location Deviation" and "Location area monitoring" functions and procedures related to Geofencing. However, they are still gaps to fulfil the requirements for Geofencing. For example, how to trigger the location alert or push notification to users in case a device enters or exits the boundary which has been established before. None of the existing LM function related to Geofencing supports to report UE status when the network is unable to determine UE location (e.g., UE power off, network connectivity issue). This exposure capability is essential for application to know in Geofencing.Geofencing may be dynamic (in time and location) and it is needed to support more cases. E.g., A person may forget to bring wearable device or wallet when leaving home. Currently, SEAL LM does not fully support such dynamic Geofencing with target UE(s) under monitoring. So to support the Geofencing which is one of value-added location services, the following aspects need to be studied:

• How to provision/update/revoke the Geofencing services.
• How to trigger the location alert or push notification to VAL UEs/users.
• How to provide more UE status in Geofencing service.
• How to support dynamic Geofencing.
• How to support the above identified functions based on the functions and procedures as defined in the SEAL-LM and/or other application enabler architecture.

Activity history can help keep track of the things you do on your device, such as the apps and services you use, the files you open, and the websites you browse. In the enterprise, the role of history tracing is mainly reflected in management and event backtracking. In the current positioning system for personnel safety management, the historical track function is one of the more important functions besides real-time positioning, and its main functions are embodied in personnel management and event backtracking. For example, when and where the inspection personnel perform the inspection work, they can view it through the historical behavior track combined with the video system. The positioning system will also provide the inspection route planning function, which can better assist the inspection work in management. According to the historical track, it can achieve job supervision and ensure that the work flow conforms to the job management standards. In Rel-17 and Rel-18, the Location Management architecture and functional model in SEAL has introduced and supported the retrieval of the UE location report in real-time or based on the event-triggered in the LM server. However, it doesn't support the history tracing request or playback which is very important and useful both for the individuals and companies. To support the history tracing request/playback which is one of value-added location services, the following aspects need to be studied:

• How to provision/update/revoke the history tracing request/playback service.
• Whether and how the existing application enablers support the above functions.

The TS 22.261 has specified low latency and high accuracy positioning requirements of 5G for the support of V2X, Rail communication, etc. And the TS 22.104 also has specified low power, high accuracy positioning use cases and example scenarios for Industrial IoT devices. These applications all request the location requirements with high-level/strict LCS QoS that the 3GPP system should meet. According to TS 23.273, the LCS Quality of Service is characterized by 3 key attributes: LCS QoS Class, Accuracy, and Response time. Based on TS 22.071, the Accuracy and Response time are application driven and can be negotiated between the 3GPP network and the application server. To improve the LCS QoS, the 5G-enabled Fused Location Service (5GFLS) has been studied in SA6 Rel-18 to aggregate the UE location information from multiple data sources. And the Application Data Analytics Enablement Service(ADAES) also studied how to enable application layer analytics enablement to allow a VAL server to be notified based on analytics whether the accuracy of a location can be met for a given application and optionally for a given UE/group route. Besides, some additional positioning methods (e.g. Ranging, UE location report via user plane, GNSS assistance, etc.) have been introduced and specified in TS 23.273 to further improve the LCS QoS that the existing application enabler should consider utilizing to meet the strict LCS QoS requirements from vertical applications. To further improve Location QoS, especially for location accuracy and latency (service response time) in application layer, the following aspects need to be studied:

• How to provide more accurate UE location reports and/or reduce the service latency (service response time) to VAL server utilizing the existing positioning methods.
• How to improve the LCS QoS based on the procedures and functions as defined in the current SEAL-LM architecture and/or other related application enablers if needed.

In Rel-17 and Rel-18, the Location Management architecture and functional model in SEAL has introduced to support the "Monitoring Location Deviation" and "Location area monitoring" functions and procedures. Utilizing these functions, the LM server could monitor the VAL UE's location information periodically and notify the VAL server when the VAL UE relationship (e.g. inside or outside) to the area of interest along with current location information of the VAL UE. However, it's not enough to analyse the location information further to provide more value-added location services. For example, for personnel management scenario, besides to monitor the person who is moving in/out the office, statistic his/her time period in the office is also important. It's needed to statistic the time information of the first entering and the last leaving the office, the times to re-enter and re-leave the office for some special employee, etc. The application enabler related to location should support to statistic the location information based on time/area domain and then expose them to the vertical applications. In addition, the following statistics and prediction related to UE location are useful for vertical applications (including but not limited to):

1. time duration for UE staying in an area.
2. UE density prediction in an area.
3. UE group route.
4. UE group member deviation from group (leaving the herd)

Another value-added use case is for heatmap service. It's not sufficient to only collect the location information based on the current SEAL-LM architecture and functions to fulfil the heatmap service requirements. E.g. if the road congestion needs to be showed, the velocity of the vehicles may be monitored as well as the location of the vehicles. So to support the location information statistic and location data collection with additional parameters, the following aspects need to be studied:

• Whether and how to expose the location data information per the e.g. time/area/space granularity in application enabled layer including statistics and prediction.
• Whether and how to expose the location data in one area of interest with additional parameters from the requirements of the VAL server, e.g. the velocity of the vehicles.
• Whether and how to support above functions based on the existing functions and procedures as defined in the SEAL-LM and/or other application enabled architecture.

Ranging-based services are the applications utilizing the distance between two UEs and/or the direction of one UE from the other one. In 3D case, direction includes horizontal direction and elevation direction. Ranging-based services can apply to a variety of verticals, such as smart home, smart city, smart transportation, smart retail, and industry 4.0. Some ranging-based services can only require the distance measurement, some can only require direction measurement, others can require both distance and direction measurement. From network perspective, 3GPP currently focuses on aspects related to the authorization, provisioning, and discovery of UEs supporting or assisting ranging services. From enablement layer perspective, the issues which can be part of the study are the following:

• How to support the selection and configuration of VAL UEs acting as reference UEs?
• Whether and how the enabler layer can support exposing ranging information to 3rd party consumers?

There are several scenarios about multiple UEs with standalone USIMs may share the same location. Such as a multi-USIM UE, a vehicle with multiple vehicle-mounted devices, wearable devices belonging to a person, etc. There is a common characteristic for these scenarios that these multiple UEs with standalone USIMs could share similar locations. So the location enabler in the application layer should consider utilizing the common characteristic to optimize the location service operations. The Figure 5.6.1-1 just lists an example to show how application enabler (e.g. LMS) handles if multiple USIMs belonging to one user share the same location. E.g. if one person wears the watch (USIM2) and the mobile phone (USIM1) at the same time, both of them could report the person's location information to the LM Server respectively. Then the LM Server could estimate both of location information to get an accurate location data for the person. Further, there is no need for the LM Server to obtain the location for the watch separately if the location of the mobile phone has been known to the LM Server, which could reduce the signaling messages, save energy and power.

To support the above scenarios, the following aspects from the application enabler perspective need to be studied:

• How to identify the multiple UEs with standalone USIMs could share the same location data in the application enabled layer.
• How to select the proper UE among multiple UEs to obtain the UE location data to expose to the VAL server.
• Whether and how the existing application enablers support the above function.