Tech-invite  3GPPspecsRELsGlossariesSIP
Info21222324252627282931323334353637384‑5x

full Contents for  TS 23.273  Word version:   16.3.0

Top   Up   Prev   Next
1…   4…   4.2a…   4.3…   5…   6…   6.1.2   6.2   6.3…   6.3.2…   6.4   6.5…   6.7…   6.8   6.9…   6.10…   6.11…   6.12…   6.13…   6.14…   7…   8…   A…   B…

 

5  High Level FeaturesWord-p. 23
5.1  LMF Selection
LMF selection functionality is used by the AMF to determine an LMF for location estimation of the target UE. If an LMF ID is available in the UE location context or provided by the UE, the AMF should first evaluate if the LMF identified by the LMF ID can be used. The LMF selection functionality is also supported by the LMF if it determines that it is unsuitable or unable to support location for the current UE access network or serving cell for the deferred 5GC-MT-LR procedure for periodic, or triggered location events.
LMF reselection is a functionality supported by AMF when necessary, e.g. due to UE mobility.
The AMF selects a new LMF if:
  • AMF determines that LMF identified by the LMF ID cannot be used; or
  • the LMF ID is not available in the UE location context; or
  • the LMF ID is not provided by the UE.
The LMF selection may be performed at the AMF or LMF based on the locally available information i.e. LMF profiles are configured locally at AMF or LMF, or by querying NRF.
LMF selection is performed when:
  • a location request is received at the AMF and the AMF determines to use the LMF for UE position estimation; or
  • the subscribed UE event reporting is received.
The following factors may be considered during the LMF selection:
  • LCS client type.
  • Requested Quality of Service information, e.g.:
    • LCS accuracy,
    • Response time (latency),
  • Access Type (3GPP /N3GPP).
  • NOTE:
    Location methods may differ depending on the Access Type, e.g. in the case of WLAN Access Location determination may just correspond to retrieval of IP addressing information from the N3IWF/TNGF; As another example, for Wireline access, Location determination may just correspond to retrieval of geo coordinates corresponding to a GLI as defined in TS 23.316, clause 4.7.8 or a HFC Node ID.
  • RAT type (i.e. 5G NR or eLTE) and/or the serving AN node (i.e. gNB or NG-eNB) of the target UE.
  • RAN configuration information.
  • LMF capabilities.
  • LMF load.
  • LMF location.
  • Indication of either a single event report or multiple event reports.
  • Duration of event reporting.
  • Network slicing information, e.g. S-NSSAI and/or NSI ID.
Up
5.1a  GMLC Discovery and SelectionWord-p. 24
More than one GMLC in the HPLMN can serve the location requests for a single UE. GMLC discovery and selection functionality is supported by AMF, LMF, NEF, LCS client and GMLC.
A LCS client may be configured with GMLC address(es). It may also determine the GMLC address by performing a DNS query.
A NEF, LMF, AMF or GMLC may be configured with GMLC address(es). Those NF may also query the NRF to get GMLC address(es).
In the following scenarios, information about the GMLC instance may be provided by UE, in such case, this GMLC instance is used:
  • In the deferred MT-LR procedure, when UE reports the detected event to the AMF, it may also include the (H)GMLC address.
  • In the MO-LR procedure, when UE initiates the LCS service request, it may also include the (H)GMLC address if the location estimation is reported to the (H)GMLC.
Up
5.2  3GPP access specific aspects
When 3GPP access type is selected, the positioning methods for 3GPP access defined in TS 38.305 apply.
Access Type Selection for LCS Service is defined in clause 5.3.2.
5.3  Non-3GPP Access Specific Aspects
5.3.1  Location Information for Non-3GPP Access
If the UE registered to non-3GPP access, following information can be regarded as UE location information:
Untrusted non-3GPP Access
Trusted non-3GPP Access
Wireline Access

UE Side N5CW device Side for Trusted WLAN Access 5G-RG side for Wireline Access
UE local IP address,
In the case of WLAN access, BSSID of the attached AP or BSSID of detected AP,
Civic address and/or geospatial location information (NOTE 1, NOTE 5, NOTE 6).

UE/N5CW device local IP address (NOTE 2).
In the case of WLAN access, BSSID of the attached AP or BSSID of detected AP,
Civic address and/or geospatial location information (NOTE 1, NOTE 5, NOTE 6).

Null

N3IWF Side for Untrusted non-3GPP Access; TNGF Side for trusted non-3GPP Access; TWIF Side for trusted WLAN Access; W-AGF Side for wireline Access
UE local IP address and optionally UDP or TCP source port (NOTE 2)

UE/N5CW device local IP address and optionally UDP or TCP source port (NOTE 2),
TNAP/TWAP Id (NOTE 2)

HFC node ID for 5G-CRG in TS 23.316, clause 10.1;
GLI for 5G-BRG in TS 23.316, clause 10.1.

AMF Side
UE local IP address and optionally UDP source port (NOTE 3).
Last known 3GPP access User Location Info (NOTE 4).

UE/N5CW device local IP address and optionally UDP source port (NOTE 2, NOTE 3).
Last known 3GPP access User Location Info (NOTE 4).
TNAP/TWAP Id (NOTE 2)

HFC node ID for 5G-CRG in TS 23.316, clause 10.1;
GLI for 5G-BRG in TS 23.316, clause 10.1

NOTE 1:
In the case of WLAN access, the UE may retrieve its location from a WLAN AP, prior or after association with the AP, requesting the Civic Location ANQP element, the Geospatial Location ANQP element or both as specified in IEEE Std 802.11-2012, using ANQP procedures described in HS2.0 Rel-12 specification.
NOTE 2:
More details can refer to TS 23.501, clause 5.6.2.
NOTE 3:
This location information can be provided by location change event, more details can refer to TS 23.502, clause 5.2.2.3.1.
NOTE 4:
This location information is also named as Last known Cell-Id, more details can refer to TS 23.501, clause 5.6.2.
NOTE 5:
Geospatial location information can be obtained if UE (e.g. laptop) has installed GNSS receiver, i.e. GPS.
NOTE 6:
Some Applications (e.g. Google Map) may map the WiFi AP's BSSID with the geospatial locations obtain through GPS when the UE switch on the GPS and WiFi simultaneously. When another UE detect the same AP, the Application will send the geospatial locations to the UE. Thus the UE obtain the geospatial locations even without switch on the GPS. If the Application map the geospatial locations to civic address, the UE can also obtain the civic address.

If the UE registered to 3GPP access and non-3GPP access simultaneously, following information can be regarded as UE location information:
  • All location information when the UE only registered to non-3GPP access,
  • All location information when the UE only registered to 3GPP access, more details can refer to TS 36.305.
Up
5.3.2  Access Type Selection for LCS ServiceWord-p. 25
The positioning of a UE can be performed via either 3GPP access network or non-3GPP access network.
For a MT-LR Location Service request, in order to select the positioning access type, the GMLC uses information retrieved from the UDM and optionally serving AMFs, e.g. access type, its serving AMF identity(ies), and UE connectivity state of this access, if available, and locally configured operator policy as follows:
  • If only one AMF identity is provided by the UDM, the GMLC selects this AMF for UE positioning.
  • When the UE is concurrently served by multiple PLMNs respectively for 3GPP access and non-3GPP access, multiple AMF identities with corresponding access types may be provided by the UDM, and the GMLC selects one access type and its associated AMF, which may be based on access type and its AMF, UE connectivity state per access type information, if this is retrieved from UDM or AMFs, PLMN identity, and/or locally configured operator policy. If the location estimation result provided by this AMF cannot fulfil the QoS requirements, the GMLC may reselect another access type and its associated AMF from the candidate list provided by the UDM to perform positioning.
When AMF receives a MT-LR Location Service request, the AMF shall provide to the LMF UE connectivity state per access type as well as the QoS requirement that are received from the GMLC.
When AMF receives the event report from the UE for a periodic or triggered MT-LR Location Service, the AMF may select a LMF or use the LMF indicated by the UE as described in clause 6.4 and clause 6.3.1 and may provide the UE connectivity state per access type to the LMF.
The LMF determines the positioning access type and positioning method based on the QoS requirement, UE/network positioning capability, and UE connectivity state per access type received from the AMF and the locally configured operator policy.
Up
5.4  UE LCS privacyWord-p. 26
5.4.1  General
An LCS client or AF may or may not be authorised to retrieve the UE location, e.g. for commercial use. UE LCS privacy is a feature which allows a UE and/or AF to control which LCS clients and AFs are and are not allowed access to UE location information. UE LCS privacy can be supported via subscription and via UE LCS privacy profile handling.
With subscription, privacy preferences for a UE are stored in a UE LCS privacy profile as part of UE subscription data in the UDM and queried from the UDM by another NF such as GMLC or NEF. The UDM may also store the UE privacy profile in the UDR. In this release of the specification, subscription of privacy preferences is restricted to the Call/Session unrelated Class as defined in the clause 5.4.2.2.3 and the PLMN Operator Class as defined in the clause 5.4.2.2.4.
With UE LCS privacy profile handling, the UE and/or AF can provide and update part of the UE privacy profile and provide it to the network as an update to the UDR. In this release of the specification, UE LCS privacy profile handling is restricted to the Location Privacy Indication as defined in the clause 5.4.2.3.
The UE LCS privacy profile is used to indicate whether LCS requests from LCS clients and AFs are allowed or disallowed, together with the POI as defined in clause 5.4.4.
NOTE:
In clause 5.4, even if the UE LCS privacy detail is only described for LCS client, the same detail is also applicable for AF, if no exception statement.
Up
5.4.2  Content of UE LCS Privacy Profile
5.4.2.1  General
The UE LCS privacy profile shall include information related to classes of LCS client, referred to as "privacy classes", which are permitted, or conditionally permitted, to obtain location information for the UE. Privacy classes are defined in clause 9.5.3 of TS 23.271, but not all classes defined in TS 23.271 are supported in this specification. Privacy classes are supported as described below. The differences between the Privacy classes for 5GS and those for EPS are described in Annex A.
The UE LCS privacy profile also includes the Location Privacy Indication, as defined in clause 5.4.2.3, which can be provided and updated by the UE and/or AFs.
Up
5.4.2.2  Privacy ClassesWord-p. 27
5.4.2.2.1  Universal Class
The universal class defined in clause 9.5.3.1 of TS 23.271 is not supported in this specification.
5.4.2.2.2  Call/Session related Class
The call/session related class defined in clause 9.5.3.2 of TS 23.271 is not supported in this specification.
5.4.2.2.3  Call/Session unrelated Class
The call/session unrelated class defined in clause 9.5.3.3 of TS 23.271 is supported for a 5GC-MT-LR. The subscription options for the Call/Session unrelated Class may be assigned to an identified value added LCS Client, AF, value added LCS Client group or service type as described in clause 7.1 and comprise one of the following alternatives:
  • positioning allowed without notifying the UE user (default case);
  • positioning allowed with notification to the UE user;
  • positioning requires notification and verification by the UE user; positioning is allowed only if granted by the UE user or if there is no response to the notification;
  • positioning requires notification and verification by the UE user; positioning is allowed only if granted by the UE user.
  • NOTE:
    LCS service types are defined in TS 22.071 and numeric values for LCS service types are listed in clause 17.7.8 of TS 29.002.
    A default subscription as described in TS 23.271, clause 9.5.3.3 is included in the UE LCS privacy profile for any value added LCS client or AF not otherwise identified for the Call/Session unrelated Class and defines one of the following alternatives:
  • positioning not allowed (default case);
  • positioning allowed with notification to the UE user;
  • positioning requires notification and verification by the UE user; positioning is allowed only if granted by the UE user or if there is no response to the notification;
  • positioning requires notification and verification by the UE user; positioning is allowed only if granted by the UE user.
The subscription options for the Call/Session unrelated Class may further indicate additional information for each identified value added LCS client, for each identified service type and for the unidentified value added LCS clients as follows:
  • A valid time period for positioning;
  • A valid geographic area for positioning.
The UE LCS privacy profile may also indicate that any unidentified value added LCS client or an LCS Client associated with an identified service type shall provide a codeword in order to locate the UE, where the codeword is verified by either a GMLC or the UE. When verification by a GMLC is indicated, a list of one or more codewords is included as part of the UE LCS privacy profile.
Up
5.4.2.2.4  PLMN Operator Class
The PLMN operator class defined in clause 9.5.3.4 of TS 23.271 is supported.
5.4.2.3  Location Privacy Indication (LPI)Word-p. 28
The Location Privacy Indication is not defined in TS 23.271. The Location Privacy Indication defines whether LCS requests for UE from any LCS clients are allowed or disallowed.
The LPI at least includes one of the following global settings (for all LCS clients and AFs):
  • Location for UE is disallowed (location for UE not allowed to any LCS client except where POI applies).
  • Location for UE is allowed (default setting, and LCS requests for UE from LCS clients are authorized based on their associated privacy classes as defined in clause 5.4.2.2).
NOTE:
Additional LPI values may be supported for additional differentiation of location request types.
The LPI also allows the following optional settings:
  • Valid time period for LPI, including start time and end time.
The LPI takes precedence on the subscribed privacy classes as defined in clause 5.4.2.2. The LPI allows a UE to override the location preference of the subscribed privacy classes. The usage of LPI is described in clause 6.1.2.
Up
5.4.3  Provision of UE LCS privacy profile
A generation or change to the LPI in UE LCS privacy profile is determined by the UE and provided to the network using N1 NAS message. It may be updated by UE any time.
An authorized AF is allowed to provision the LPI in UE LCS privacy profile for specific UE(s) via NEF.
NOTE:
The AF allowed to provision the UE LCS privacy profile is different from the AF sending location requests.
The LPI in UE LCS privacy profile may be provided or updated by the target UE during the 5GC-MT-LR and Deferred 5GC-MT-LR Procedure for Periodic, Triggered and UE Available Location Events. The updated profile is stored into the UDR by the UDM after the interaction with the AMF. The LPI in UE LCS privacy profile shall include an indication if location is allowed or disallowed and may include a valid time period for LPI as described in clause 5.4.2.3.
In addition, a notification is sent by the UDM in order to notify the subscribed consumer i.e. GMLC and NEF about the change of UE LCS privacy profile:
  • Target UE identity (one or both of GPSI and SUPI);
  • Updated UE LCS privacy profile.
Up
5.4.4  Privacy Override Indicator (POI)
The POI is used to determine whether the UE LCS privacy profile of the subscriber to be positioned shall be overridden by the request for location services. The POI is applicable only to regulatory services. The assignment of a POI value with an "override" or "not override" value in the LCS client profile (see clause 7.2.1) is done during the LCS client provisioning (out of scope of this specification). The type of LCS client requesting location information (i.e. emergency, law-enforcement etc.) shall determine the value of the POI assigned to the LCS client profile.
Up
5.4.5  LCS service authorization for an Immediate UE Location
UDM provides the UE LCS privacy profile to NEF and GMLC, if the information is available.
For a 5GC_MT_LR request for immediate location, the GMLC in the HPLMN, or the HGMLC when the UE is roaming, determines whether the LCS client or NF is authorized to retrieve UE location, based on the UE privacy profile.
NOTE 1:
The UE LCS privacy profiles are not sent to the VGMLC.
Authorization is determined by first verifying whether the location request is allowed according to the Location Privacy Indication (LPI) defined in clause 5.4.2.3. If the location request is not allowed, an error response is returned to the LCS client, AF, or NF. If the location request is allowed according to the LPI, authorization is next verified according to the Call/Session unrelated Class for an LCS Client or AF or according to the PLMN Operator Class for an NF.
For the Call/Session unrelated Class client types where POI does not apply, the HGMLC determines one of the following indications to be included in the location request forwarded to the serving AMF, or VGMLC in the case of roaming:
  • Location allowed without notification;
  • Location allowed with notification;
  • Location with notification and privacy verification; location allowed if no response;
  • Location with notification and privacy verification; location restricted if no response.
For PLMN Operator Class client types that are permitted to receive UE location information or where POI applies, a "location allowed without notification" is included.
For a Call/Session unrelated Class client type, which a geographic area restriction was included in the UE LCS privacy profile, the (H)GMLC performs an initial location by including a "location allowed without notification" indication in the location request sent to the VGMLC or AMF. The (H)GMLC then determines, based on the obtained location, whether location of the UE is allowed. If location of the UE is allowed subject to notification or verification, the (H)GMLC initiates a second location request to the VGMLC or serving AMF for the purpose of notification and/or verification only and includes one of the following indications in the second location request forwarded to the serving AMF, or VGMLC in the case of roaming:
  • Notification only
  • Notification and privacy verification only
When "Notification and privacy verification only" is included, the serving AMF shall report the result of privacy verification back to the (H)GMLC (i.e. location allowed, location not allowed or timeout on a response) and the (H)GMLC shall determine whether or not to return the location received for the first request back to the LCS client based or AF on this result.
For a direct NEF query to a serving AMF, or for an NEF query via the UDM, if GMLC is not involved, the NEF determines whether the AF is authorized to retrieve UE location, based on the UE LCS privacy profile.
NOTE 2:
Notification and verification are not supported for a direct NEF query to a serving AMF, or for an NEF query via the UDM. Consequently, when notification or verification are required, or may be required based on a geographic area restriction, an NEF shall forward a location request to a GMLC or return an error indication to the requesting AF.
Up
5.4.6  LCS service authorization for a Deferred UE LocationWord-p. 29
Support of UE LCS privacy for a deferred UE location is the same as that described in clause 5.4.5 for an immediate UE location with the differences and qualifications described in this clause.
An (H)GMLC or NEF shall subscribe to notification of a change in the UE LCS privacy profile from the UDM at the start of a deferred 5GC-MT-LR procedure and shall verify UE privacy both at the start of the deferred 5GC-MT-LR procedure and for each location result returned to an LCS client or AF based on the most recent UE LCS privacy profile received from the UDM.
If the UE LCS privacy profile indicates notification or verification of a location request is required for a particular value added LCS client, the (H)GMLC indicates this in the initial location request sent to the serving AMF and the serving AMF notifies the UE or verifies the location request with the UE, as for an immediate location request, when the UE first becomes reachable. The serving AMF also indicates the type of deferred location request in the NAS Location Notification Invoke Request sent to the UE. However, the location notification or verification is not repeated for each UE location in the case of a periodic or triggered 5GC-MT-LR.
For a value added LCS client, AF, value added LCS client group or LCS service type, for which a geographic area restriction was included, the (H)GMLC includes any request for notification or verification of the location request in the initial location request sent to the serving AMF. The (H)GMLC then determines whether a location result can be returned to the LCS client or AF based on whether the location result is or is not restricted by the geographic area restriction. If the location result is allowed by the geographic area restriction, the (H)GMLC does not perform a second location request to the serving AMF for the purpose of notification and/or verification only. If the location result is not allowed by the geographic area restriction, the (H)GMLC discards the location result without notifying the LCS client or AF.
Up
5.5  Location service exposureWord-p. 30
Location service can be exposed to the authorized control plane NF or the LCS client to obtain the UE location to enable their application and services using the MT-LR procedure. For the location service exposed to the AF which is not allowed to directly interact with the GMLC or AMF, CAPIF API may be used between NEF and the AF as described in clause 6.2.5.1 of TS 23.501.
For location service exposure, there are two types of location service requests as defined in clause 4.1a.4 and clause 4.1a.5:
  • Location Immediate Request (LIR); and
  • Location Deferred Request (LDR).
The following attributes may be included in the location service requests:
  • Target UE identity;
  • LCS Client identity or AF ID;
  • Service identity, if needed;
  • Codeword, if needed;
  • Type of Event definition, i.e. UE available, change of area, motion or periodic location, applicable to deferred location requests only;
  • Definitions for change of area type deferred location requests. Following parameters may be defined, if needed;
    1. Indication for event trigger, i.e. UE enters, leaves or is within requested target area;
    2. Indication of either a single event report or multiple event reports;
    3. Minimum time interval between area event reports, if multiple event reports are requested;
    4. Indication of the requested location estimate; i.e. whether the location estimate of the target UE should be contained in the change of area event report;
    5. Duration of event reporting;
    6. Maximum time interval between reports;
    7. Maximum sampling time for event detection;
  • Definitions for motion type deferred location requests. Following parameters may be defined, if needed;
    1. Linear distance threshold;
    2. Indication of either a single event report or multiple event reports;
    3. Minimum time interval between motion event reports, if multiple event reports are requested;
    4. Indication of the requested location estimate; i.e. whether the location estimate of the target UE should be contained in the motion event report;
    5. Duration of event reporting;
    6. Maximum time interval between reports;
    7. Maximum sampling time for event detection;
  • Definitions for periodic location type deferred location requests. Following parameters may be defined, if needed:
    1. Time interval between successive location reports;
    2. Total number of reports;
  • Start time, stop time (i.e. specifying the validity time of LCS request), if needed;
  • Interval, applicable to periodical requests only;
  • Requested LCS Quality of Service information, if needed, i.e. accuracy, response time and LCS QoS Class;
  • Requested type of location, i.e. "current location", "current or last known location" or "initial location" applicable to LIR only (current location is only available for LDR);
  • Velocity of the UE, if needed;
  • Priority, if needed;
  • Service coverage (i.e. E.164 country codes for geographic areas, ITU-T Recommendation E.164 [23]), if needed;
  • Requested maximum age of location, if needed;
  • Local coordinate reference system, if needed;
  • Target area, i.e. geographical area expressed as one of the following format, if needed.
    1. a shape defined in TS 23.032
    2. local coordinate system
    3. E.164 country code for a geographic area [23]
    4. PLMN identity
    5. geopolitical name of the area (e.g. London)
  • Response Method, if needed for legacy LCS Client using the OMA MLP protocol.
The following attributes may be included in the location service response:
  • Location indication of UE in geographical coordinates expressed as a shape as defined in TS 23.032 or local coordinate system;
  • Velocity of the UE as defined in TS 23.032, if requested and if available;
  • The information about the positioning method used to obtain the location estimate of the UE, if it is available at the LCS server and if needed;
  • Time stamp of location estimate;
  • Indication when UE enters, is within or leaves the Geographical area, if needed;
  • Acknowledgement for a deferred location request, if needed.
  • Request id, if needed.
  • Indication that the requested QoS was not met, if needed, only applicable if the request was for best effort class
  • Indication of a periodic event.
  • Indication of a motion event.
  • Indication that a deferred location request has been activated in a UE.
  • Indication of expiration of the maximum reporting interval for the area event or motion event.
In addition, the information attributes of the location service request may be used also in the location service response.
For a legacy LCS client in the core network, the LCS service request is sent to GMLC using Le interface.
For an AF not allowed to directly interact with the GMLC or AMF, the LCS service request is sent to NEF using the service based interface.
For an internal control plane NF, the LCS service request is sent to AMF or GMLC using the service based interface.
NOTE:
For regulatory services, any control plane NF can be LCS client.
To support location service exposure through NEF, when NEF receives a LCS service request, it determines based on the location accuracy of the QoS requirement, e.g. lower or higher than cell-ID level, on whether to invoke the GMLC service or the AMF service for the LCS service request.
Up
5.6  LCS ChargingWord-p. 32
Charging Information for LCS service is collected at GMLC and AMF. For roaming case, the Charging Information shall be collected in both home PLMN and visited PLMN for inter-operator charging purpose.
Charging mechanism for LCS service and the Charging Information collected at GMLC and at AMF are defined in TS 32.271 and TS 32.298.
5.7  Support of Concurrent Location Requests
5.7.1  General
Concurrent Location Requests occur when any entity (e.g. UE, AMF, LMF, GMLC, NEF):
  • Case A: receives/initiates multiple LCS requests (e.g. 5GC-MT LR, 5GC-MO LR, 5GC-NI LR) for the location estimate of the same target UE within a time period; or
  • Case B: receives/initiates one or more new LCS request(s) (e.g. 5GC-MT LR, 5GC-MO LR, 5GC-NI LR) for the location estimate of the same target UE during the location session to support the old LCS request(s).
In either case, if allowed by the QoS requirements and privacy settings, the entity may combine the concurrent location requests by fully executing one of the requests and using the ensuing location estimate result(s) to satisfy the other request(s) without fully executing the latter. When concurrent location requests are supported, each entity needs to ensure it correlates each location/position response with the associated request and different concurrent location requests shall be treated separately without any dependency on one another by any entity.
NOTE 1:
Combining of location requests is not allowed for a deferred 5GC-MT-LR for periodic or triggered location for privacy reasons (e.g. a target UE would not be aware that location event reports were being sent to multiple AFs and/or external LCS clients).
NOTE 2:
An entity (e.g. AMF, GMLC, NEF) may cache location information obtained for one location request and use this information to support later location requests for "current or last known location". This is not considered to be a case of concurrent location requests.
If the entity, either itself or in association with another entity, cannot support concurrent location requests or it can only support up to a certain number of concurrent location requests, it can reject or defer a new concurrent request or cancel one or more existing requests. For Case B, it can also allow the new location request to proceed concurrently with and separately from the previous requests.
LCS Client/AF priority and any other relevant priority information (e.g. UE subscription preferences) should be considered when rejecting or deferring a concurrent request or when cancelling one or more existing requests. In particular, location requests associated with emergency services or lawful interception clients should be given priority over other location requests.
Up
5.7.2  Combining location requests by an H-GMLC or NEFWord-p. 33
An H-GMLC or NEF may combine concurrent location requests (e.g. 5GC-MT LR, 5GC-MO LR, 5GC-NI LR) for the same target UE by executing only one request and using the ensuing location estimate result(s) to satisfy the other request(s). The conditions for this are as follows:
  • the H-GMLC must be able to fully resolve privacy requirements for the other location request(s) without requiring notification or verification by the UE (though notification only as in steps 17-23 of clause 6.1.2 could still be used in the case of location dependent privacy); and
  • the QoS for the other request(s) should be less strict than the QoS for the executed location request.
An H-GMLC may also combine concurrent location requests in the case of a bulk location request for a group of UEs as described in clause 6.8. In this case, location information for any UE in the group may be obtained from location information obtained from another concurrent location request for the same UE.
Up
5.7.3  Combining location requests by a V-GMLC
A V GMLC may combine concurrent 5GC-MT LR and 5GC-MO-LR related location requests for the same target UE provided it is clear and unambiguous for any 5GC-MT LR that will not be fully executed (e.g. from the contents of any location request received from the H GMLC) that no outstanding privacy related actions are required for the UE (e.g. no privacy notification and/or privacy verification interaction with the UE). QoS requirements must also be satisfied for the non-executed location requests.
5.7.4  Combining location requests by an AMF
An AMF may combine concurrent 5GC-MT LR, 5GC-MO LR and 5GC-NI LR location requests once any needed privacy related actions (e.g. UE notification and verification) have been performed for each 5GC-MT LR. (i.e. AMF may decide to not execute multiple positioning procedures for the concurrent location requests) QoS requirements must also be satisfied for the non-executed location requests.
5.7.5  Combining location requests by an LMF
An LMF may combine concurrent location requests for the same target UE provided QoS requirements can be satisfied for the non-executed location requests.
5.7.6  Combining location requests by a UE
A UE may combine concurrent location requests provided QoS requirements can be satisfied and provided any positioning procedures with an LMF remain supported according to the positioning protocol.
5.8  Interworking with the IMS
When the location service request is initiated by the LCS Client / AF for the location estimation of a target UE in an IMS session, a SIP-URI or a TEL-URL maybe included in the request to identify the target UE. In that case, the H-GMLC of the UE shall be able to convert the SIP-URI/TEL-URL into SUPI of the target UE.
NOTE 1:
The H-GMLC may query IMS-HSS or UDM to retrieve the SUPI of the target UE based on its SIP-URI/TEL-URL.
NOTE 2:
If multiple SUPIs are resolved for the SIP-URI/TEL-URL, the H-GMLC behaviour is out of scope of this specification.
Up

Up   Top   ToC