Patent Description:
Standards to support <NUM> wireless networks are being developed by the 3rd Generation Partnership Project (3GPP). In the first release of <NUM> (3GPP Release <NUM>), the <NUM> core network (5GC) is expected to support voice services and emergency calls. In some regions (e.g., US, Japan), supporting emergency calls may require supporting an accurate location of a mobile device. However, there may be no native <NUM> positioning support in the first release (Release <NUM>) of the Next Generation Radio Access network (NG-RAN) used to support <NUM> wireless access. While an emergency call instigated over <NUM> might be redirected via fallback to fourth-generation (<NUM>, or Long-Term Evolution (LTE)) where location support exists, the fallback may reduce the reliability of emergency calls (e.g. when <NUM> wireless coverage is not available) and may not comply with regulatory requirements in some countries. Therefore a solution is needed whereby an emergency call can be setup using <NUM> wireless access with location support but without location support using <NUM> wireless access positioning methods. Discussion Paper <NPL>, discloses using location solutions for EPC in a very similar manner in the NextGen Core (NGC) using entities the same as or analogous to those in EPC and with correspondingly similar procedures. This solution is referred to as the "traditional CP location solution". It is assumed that for a UE with <NUM> radio access, similar position methods will be supported by NGC as for EPC. For example, position methods such as A-GNSS and WLAN might be supported in an identical or almost identical manner (e.g. if WLAN access to NGC is supported). Other position methods such as OTDOA and ECID might be supported in an analogous manner but using difference reference signals and associated measurements. The exact position methods can be decided later by RAN. It is noted that allowing for new NG positioning protocols, does not rule out continuing use of LPP and/or LPPa (with suitable extensions).

Techniques described herein are directed toward enabling location support for <NUM> wireless access by utilizing existing LTE location support. More specifically, LTE positioning protocol (LPP) messages may be communicated between a user equipment (UE) and a location management function (LMF) in the 5GC via an NG-RAN for location support. The UE may also receive timing information and take measurements using existing LTE base stations.

Non-limiting and non-exhaustive aspects are described with reference to the following figures, wherein like reference numerals refer to like parts throughout the various figures unless otherwise specified.

Elements, stages, steps and actions with the same reference label in different drawings may correspond to one another (e.g. may be similar or identical to one another). Further, some elements in the various drawings are labelled using a numeric prefix followed by an alphabetic or numeric suffix. Elements with the same numeric prefix but different suffices may be different instances of the same type of element. The numeric prefix without any suffix is then used herein to reference any element with this numeric prefix. For example, different instances <NUM>-<NUM>, <NUM>-<NUM>, and <NUM>-<NUM> of an evolved Node B (eNB) are shown in <FIG>. A reference to an eNB <NUM> may then refer to any of eNB <NUM>-<NUM>, eNB <NUM>-<NUM>, and eNB <NUM>-<NUM>.

Several illustrative embodiments will now be described with respect to the accompanying drawings, which form a part hereof. The ensuing description provides embodiment(s) only, and is not intended to limit the scope, applicability or configuration of the disclosure. Rather, the ensuing description of the embodiment(s) will provide those skilled in the art with an enabling description for implementing an embodiment. It is understood that various changes may be made in the function and arrangement of elements without departing from the scope of this disclosure.

Techniques described herein are directed to providing location support for a UE that has wireless access to an NG-RAN. According to some embodiments, such a UE (with wireless access to an NG-RAN) may be located using (i) Radio Access Technology (RAT)-independent position methods (e.g., Assisted Global Navigation Satellite System (A-GNSS), WiFi, Bluetooth, sensors, etc.), and/or (ii) RAT-dependent position methods for Evolved Universal Terrestrial Radio Access (E-UTRA) (e.g., Enhanced Cell ID (ECID), Observed Time Difference Of Arrival (OTDOA), etc.), which do not depend on new types of location support for <NUM> wireless access. To manage the UE's location, the LTE Positioning Protocol (LPP) defined for supporting UE location over LTE in 3GPP Technical Specification (TS) <NUM> may be reused (with little or no change) for <NUM> wireless access by the UE. This may be enabled by transferring LPP messages between a UE and a 5GC location server (e.g. a Location Management Function (LMF)) using a transport protocol such as a <NUM> Non-Access Stratum (NAS) protocol (referred to herein as <NUM> NAS). Transport (e.g., <NUM> NAS) messages that are used to transport messages for other services (e.g., network access, mobility management, session management) may be transferred between an Access Management Function (AMF) in the 5GC and a UE via the NG-RAN as part of normal <NUM> operation. A suitable transport (e.g. <NUM> NAS) message or messages may then carry LPP messages between a UE and AMF with little or no extra impact to the NG-RAN. LPP messages may be transferred between an AMF and an LMF using a new 5GC protocol. The new 5GC protocol may be similar to the Location Services (LCS) Application Protocol (LCS AP) defined in 3GPP TS <NUM> that is used between a Mobility Management Function (MME) and an Enhanced Serving Mobile Location Center (E-SMLC) to support location of a UE with <NUM> (LTE) wireless access. This new 5GC protocol (for communication between an AMF and LMF) is referred to herein as "<NUM> LCS AP". The AMF may also tell the LMF (e.g., using the <NUM> LCS AP) that a UE has <NUM> wireless access and may provide the <NUM> serving cell ID to the LMF.

The use of LPP in the manner described above may allow existing positioning methods supported by LPP for LTE access by a UE to be reused for locating a UE with <NUM> wireless access. In some embodiments, for RAT-independent position methods, existing UE support may be reused, and/or part of the procedure described below in P1 to P4 may be used to allow a UE to make RAT-independent position measurements. In embodiments using E-UTRA RAT-dependent position methods (e.g. ECID and/or OTDOA), a UE is able to tune away from <NUM> wireless access to make LTE measurements. In such embodiments, the procedure described below in P1 to P4 is used.

Measurements obtained by the UE (e.g. as described above in P1-P4) may be returned to the LMF in an LPP message (e.g., sent to the AMF in a NAS transport message and sent by the AMF to the LMF using <NUM> LCS AP).

These techniques can have limited impact to UEs and zero or low impact to the NG-RAN if a request for an idle period and measurement gaps is supported by the NG-RAN for other types of measurements (e.g., <NUM> measurements to support cell change and handover). Additional details and embodiments are described below, with reference to the appended figures.

<FIG> is a diagram of a communication system <NUM> capable of implementing the techniques described herein, according to an embodiment. Here, the communication system <NUM> comprises a user equipment (UE) <NUM>, components of a <NUM> System (5GS) <NUM> comprising an NG-RAN <NUM> and 5GC <NUM>. NG-RAN <NUM> may also be referred to as a <NUM> Radio Access Network (<NUM> RAN) or as a Radio Access Network (RAN) for NR. The communication system <NUM> further comprises components of an evolved packet system (EPS) <NUM> supporting LTE wireless access, which includes an Evolved Universal Terrestrial Radio Access (E-UTRA) Network (E-UTRAN) <NUM> and an Evolved Packet Core (EPC) <NUM>. The communication system <NUM> may further utilize information from GNSS satellite vehicles (SVs) <NUM>. Additional components of the communication system <NUM> are described below. It will be understood that a communication system <NUM> may include additional or alternative components. EPS <NUM> may belong to or be managed by the same network operator who manages or owns 5GS <NUM> in some embodiments (or may be managed or owned by a different network operator in other embodiments).

It should be noted that <FIG> provides only a generalized illustration of various components, any or all of which may be utilized as appropriate, and each of which may be duplicated as necessary. Specifically, although only one UE <NUM> is illustrated, it will be understood that many UEs (e.g., hundreds, thousands, millions, etc.) may utilize the communication system <NUM>. Similarly, the communication system <NUM> may include a larger or smaller number of SVs <NUM>, eNBs <NUM>, gNBs <NUM>, ng-eNBs <NUM>, external clients <NUM>, and/or other components. A person of ordinary skill in the art will recognize many modifications to the components illustrated. The illustrated connections that connect the various components in the communication system <NUM> comprise data and signaling connections which may include additional (intermediary) components, direct or indirect physical and/or wireless connections, and/or additional networks. Furthermore, components may be rearranged, combined, separated, substituted, and/or omitted, depending on desired functionality.

The UE <NUM> may comprise and/or be referred to herein as a device, a mobile device, a wireless device, a mobile terminal, a terminal, a mobile station (MS), a Secure User Plane Location (SUPL) Enabled Terminal (SET), or by some other name. Moreover, UE <NUM> may correspond to a cellphone, smartphone, laptop, tablet, personal digital assistant (PDA), tracking device or some other portable or moveable device. Typically, though not necessarily, the UE <NUM> may support wireless communication using one or more Radio Access Technologies (RATs) such as using GSM, Code Division Multiple Access (CDMA), Wideband CDMA (WCDMA), LTE (e.g., the EPS <NUM>), High Rate Packet Data (HRPD), IEEE <NUM> WiFi (also referred to as Wi-Fi), Bluetooth® (BT), Worldwide Interoperability for Microwave Access (WiMAX), <NUM> new radio (NR) also referred to as just "<NUM>" (e.g., using the NG-RAN <NUM> and 5GC <NUM>), etc. The UE <NUM> may also support wireless communication using a Wireless Local Area Network (WLAN) which may connect to other networks (e.g. the Internet) using a Digital Subscriber Line (DSL) or packet cable for example. The use of or more of these RATs may enable the UE <NUM> to communicate with an external client <NUM> (via elements of 5GC <NUM> not shown in <FIG> or possibly via Gateway Mobile Location Center (GMLC) <NUM>) and/or enable the external client <NUM> to receive location information regarding the UE <NUM> (e.g. via GMLC <NUM>).

The UE <NUM> may comprise a single entity or may comprise multiple entities such as in a personal area network where a user may employ audio, video and/or data I/O devices and/or body sensors and a separate wireline or wireless modem. An estimate of a location of the UE <NUM> may be referred to as a location, location estimate, location fix, fix, position, position estimate or position fix, and may be geodetic, thus providing location coordinates for the UE <NUM> (e.g., latitude and longitude) which may or may not include an altitude component (e.g., height above sea level, height above or depth below ground level, floor level or basement level). Alternatively, a location of the UE <NUM> may be expressed as a civic location (e.g., as a postal address or the designation of some point or small area in a building such as a particular room or floor). A location of the UE <NUM> may also be expressed as an area or volume (defined either geodetically or in civic form) within which the UE <NUM> is expected to be located with some probability or confidence level (e.g., <NUM>%, <NUM>%, etc.). A location of the UE <NUM> may further be a relative location comprising, for example, a distance and direction or relative X, Y (and Z) coordinates defined relative to some origin at a known location which may be defined geodetically, in civic terms, or by reference to a point, area, or volume indicated on a map, floor plan or building plan. In the description contained herein, the use of the term location may comprise any of these variants unless indicated otherwise.

Base stations in the E-UTRAN <NUM> (a <NUM> RAN) comprise Evolved Node Bs (eNodeBs or eNBs) <NUM>-<NUM>, <NUM>-<NUM>, and <NUM>-<NUM> (collectively and generically referred to herein as eNBs <NUM>). Base stations in the NG-RAN <NUM> comprise NR NodeBs (gNBs) <NUM>-<NUM> and <NUM>-<NUM> (collectively and generically referred to herein as gNBs <NUM>) and next generation eNBs (ng-eNBs) <NUM>-<NUM> and <NUM>-<NUM> (collectively and generically referred to herein as ng-NBs <NUM>). Access to the LTE network supported by EPS <NUM> is provided to UE <NUM> via wireless communication between the UE <NUM> and one or more of the eNBs <NUM>. The eNBs <NUM> may provide wireless communications access to the EPC <NUM> on behalf of UE <NUM> using LTE. Similarly, access to the 5GS <NUM> is provided to UE <NUM> via wireless communication between the UE <NUM> and one or more of the gNBs <NUM>, which may provide wireless communications access to the 5GS <NUM> using <NUM> NR. In some embodiments, access to the 5GS <NUM> is provided to UE <NUM> via wireless communication between the UE <NUM> and one or more of the ng-eNBs <NUM>, which may provide wireless communications access to the 5GS <NUM> using LTE. Ng-eNBs <NUM> may provide LTE wireless access to UE <NUM> that is similar to or the same as LTE wireless access provided to UE <NUM> by eNBs <NUM> at a physical level. Furthermore, in some embodiments, NG-RAN <NUM> may contain gNBs <NUM> but no ng-eNBs <NUM> or may contain ng-eNBs <NUM> but no gNBs <NUM>. In addition, in some embodiments, EPS <NUM> may be absent.

In communication system <NUM>, location support for UE <NUM> may employ LPP transport between an LMF <NUM> and UE <NUM> using transport protocols such as a <NUM> NAS protocol and <NUM> LCS AP as described previously. Use of LPP and transport of LPP may be similar or the same both for access by UE <NUM> to 5GC <NUM> via gNBs <NUM> and for access by UE <NUM> to 5GC <NUM> via ng-eNBs <NUM>.

For LTE wireless access, the EPC <NUM> comprises a Mobility Management Entity (MME) <NUM>, which can function as the main signaling node in the EPC <NUM>, and may support mobility of UE <NUM> and provision of signaling access and voice bearer paths to UE <NUM>. For positioning functionality, the MME <NUM> can relay information to and from an Enhanced Serving Mobile Location Center (E-SMLC) <NUM>. E-SMLC <NUM> may support positioning of UE <NUM> (also referred to as location of UE <NUM>) when UE <NUM> accesses E-UTRAN <NUM> and may support position methods such as Assisted GNSS (A-GNSS), OTDOA, ECID, Real Time Kinematics (RTK) and/or WLAN positioning (also referred to as WiFi positioning) which are well known in the art. E-SMLC <NUM> may also process location services requests for UE <NUM> - e.g. received from MME <NUM>. EPC <NUM> may contain other elements not shown in <FIG> such as a Packet Data Network (PDN) Gateway and/or a GMLC, for example.

For NR (<NUM>) wireless access, the gNBs <NUM> can communicate directly or indirectly with an Access Management Function (AMF) <NUM>, which, for position functionality, communicates with the LMF <NUM>. Similarly, for LTE wireless access to NG-RAN <NUM>, the ng-eNBs <NUM> can communicate directly or indirectly with the AMF <NUM>. Further, gNBs <NUM> and/or ng-eNBs <NUM> may communicate directly with one another which may allow some gNBs <NUM> and/or some ng-eNBs <NUM> to communicate only indirectly with AMF <NUM> via one or more other gNBs <NUM> and/or ng-eNBs <NUM>. AMF <NUM> may support mobility of UE <NUM> including cell change and handover and may participate in supporting a signaling connection to UE <NUM> and possibly helping to establish data and voice bearers for UE <NUM>. LMF <NUM> may support positioning of UE <NUM> when UE accesses NG-RAN <NUM> and may support position methods such as Assisted GNSS (A-GNSS), OTDOA, ECID, RTK and/or WLAN positioning similar to E-SMLC <NUM>. LMF <NUM> may also process location services requests for UE <NUM> - e.g. received from AMF <NUM> or from GMLC <NUM>. In some embodiments, the LMF <NUM> may implement functionality similar to an E-SMLC such as E-SMLC <NUM> that would enable the LMF <NUM> to query eNBs <NUM> in the E-UTRAN <NUM> (e.g. using the LTE Positioning Protocol A (LPPa) defined in 3GPP TS <NUM>) and obtain assistance data from the eNBs <NUM> to support OTDOA positioning of the UE <NUM> when UE <NUM> has NR or LTE wireless access via NG-RAN <NUM>. Additionally or alternatively, this functionality may be enabled via the E-SMLC <NUM>. For example, LMF <NUM> may be combined with E-SMLC <NUM> in the same physical entity or may have communication access to E-SMLC <NUM>.

As illustrated in <FIG>, LMF <NUM> and eNBs <NUM> may communicate using LPPa, wherein LPPa messages are transferred between eNBs <NUM> and LMF <NUM> via MME <NUM> and E-SMLC <NUM>. Here, LPPa transport between E-SMLC <NUM> and eNBs <NUM> (via MME <NUM>) may be as defined for existing LTE location in 3GPP TS <NUM> and transport of LPPa messages between E-SMLC <NUM> and LMF <NUM> may be internal (e.g., if LMF <NUM> and E-SMLC <NUM> are combined) or may use a proprietary protocol if LMF <NUM> and E-SMLC <NUM> are separate. In embodiments where UE <NUM> accesses 5GC <NUM> via LTE access to an ng-eNB <NUM> in NG-RAN <NUM>, messages similar to LPPa may be transferred between ng-eNBs <NUM> and LMF <NUM> via AMF <NUM> (as shown by the dashed arrow <NUM> in <FIG>). The messages similar to LPPa transferred as shown by the dashed arrow <NUM> may be messages for an NR Positioning Protocol A (NRPPa) defined in 3GPP TS <NUM> which may support transfer of information identical to or similar to that transferred using LPPa.

As further shown in <FIG>, LPP messages may be exchanged between UE <NUM> and LMF <NUM> via AMF <NUM> and NG-RAN <NUM> (e.g., via either gNB <NUM>-<NUM> or ng-eNB <NUM>-<NUM> in NG-RAN <NUM>) as shown by the solid arrow <NUM> in <FIG>, For example, LPP messages may be transferred between LMF <NUM> and AMF <NUM> using a <NUM> LCS Application Protocol (AP) and may be transferred between AMF <NUM> and UE <NUM>, via a serving gNB <NUM> or serving ng-eNB <NUM> for UE <NUM>, using <NUM> NAS. Because the AMF <NUM> can relay LPP communication to and from UE <NUM> inside a <NUM> NAS message, the LPP communication may have little or no impact on the NG-RAN <NUM> (which may communicate the <NUM> NAS message as it would any other <NUM> NAS message).

The LPPa and NRPPa protocols may enable a location server to request and obtain location related information from a base station concerning either the location of a particular UE or location configuration for the base station. Location related information provided by the eNBs <NUM> to LMF <NUM> (e.g. via E-SMLC <NUM> and MME <NUM>) using LPPa may include timing information, information for PRS transmission by eNBs <NUM> (as described later in association with <FIG> and <FIG>), and location coordinates for eNBs <NUM>. Similarly, location related information provided by the ng-eNBs <NUM> to LMF <NUM> using NRPPa may include timing information, information for PRS transmission by ng-eNBs <NUM> (as described later in association with <FIG> and <FIG>), and location coordinates for ng-eNBs <NUM>. For example, in the case of LPPa, E-SMLC <NUM> or LMF <NUM> may send an LPPa message to eNB <NUM>-<NUM> via MME <NUM> (and possibly via E-SMLC <NUM> in the case of an LPPa message sent from LMF <NUM>) to request information related to the location of UE <NUM> (e.g. such as location measurements for ECID positioning obtained by eNB <NUM>-<NUM> or obtained by UE <NUM> and transferred to eNB <NUM>-<NUM>) or related to a location configuration of eNB <NUM>-<NUM> (e.g. such as a location of eNB <NUM>-<NUM> or a PRS configuration for eNB <NUM>-<NUM> for OTDOA positioning). ENB <NUM>-<NUM> may then obtain any requested location configuration information or location measurements (e.g. when location information for UE <NUM> is requested) and return the requested information back to E-SMLC <NUM> or LMF <NUM> via MME <NUM> (and possibly via E-SMLC <NUM> when the information was requested by LMF <NUM>). Use of NRPPa may occur in a similar manner with, for example, LMF <NUM> sending an NRPPa message to gNB <NUM>-<NUM> or to ng-eNB <NUM>-<NUM> via AMF <NUM> to request information related to the location of UE <NUM> or location configuration for gNB <NUM>-<NUM> or ng-eNB <NUM>-<NUM>, and with gNB <NUM>-<NUM> or ng-eNB <NUM>-<NUM> returning the requested information back to LMF <NUM> in another NRPPa message via AMF <NUM>.

In the case of an NRPPa message sent to ng-eNB <NUM>-<NUM>, LMF <NUM> may request information similar to or the same as that which can be requested from eNB <NUM>-<NUM> using LPPa: this information may thus comprise ECID location measurements for UE <NUM>, the location of ng-eNB <NUM>-<NUM> or PRS configuration information for ng-eNB <NUM>-<NUM> applicable to OTDOA positioning of UE <NUM>. In the case of an NRPPa message sent to gNB <NUM>-<NUM>, LMF <NUM> may request a serving cell identity (ID) for UE <NUM> or location measurements (e.g. measurements of Reference Signal Received Power (RSRP) or Reference Signal Received Quality (RSRQ) for LTE) obtained by UE <NUM> and provided to gNB <NUM>-<NUM> by UE <NUM> (e.g. using RRC). LMF <NUM> may also request (e.g. in a later 3GPP release), NR related location measurements obtained by gNB <NUM>-<NUM> for UE <NUM> or location configuration information for gNB <NUM>-<NUM> such as NR PRS configuration information for gNB <NUM>-<NUM>.

The LMF <NUM> can provide some or all of the location related information received (e.g. using LPPa and/or NRPPa) from eNBs <NUM>, ng-eNBs <NUM> and/or gNBs <NUM> to the UE <NUM> as assistance data in an LPP message sent to the UE <NUM> via the NG-RAN <NUM> and 5GC <NUM>.

An LPP message communicated from the LMF <NUM> to the UE <NUM> (e.g. via NG-RAN <NUM>) may instruct the UE <NUM> to do any of a variety of things, depending on desired functionality. For example, the LPP message could contain an instruction for the UE <NUM> to obtain measurements for GNSS (or A-GNSS), WLAN positioning, RTK, and/or OTDOA. In the case of OTDOA, the LPP message may tell the UE <NUM> to take one or more measurements (e.g. measurements of Reference Signal Time Difference (RSTD)) of particular eNBs <NUM> and/or ng-eNBs <NUM>. Thus, if the UE <NUM> is served by a gNB <NUM> or ng-eNB <NUM> in NG-RAN <NUM>, the UE <NUM> could behave as if it were being served by E-UTRAN <NUM> and EPC <NUM> (rather than by NG-RAN <NUM> and 5GC <NUM>) in the case of measurements of particular eNBs <NUM>. Similarly, if the UE <NUM> is served by a gNB <NUM> in NG-RAN <NUM>, the UE <NUM> could behave as if it were being served by an ng-eNB <NUM> in NG-RAN <NUM> in the case of measurements of particular ng-eNBs <NUM>. The UE <NUM> may then send measurements back to the LMF <NUM> in an LPP message (e.g., inside a <NUM> NAS message) via the NG-RAN <NUM>.

It is noted that identification of ng-eNBs <NUM> as part of NG-RAN <NUM> in <FIG> is partly a matter of terminology. For example, an ng-eNB <NUM>-<NUM> could be treated as being part of E-UTRAN <NUM> rather than as part of NG-RAN <NUM> and could be referred to as an eNB <NUM>-<NUM> rather than as an ng-eNB <NUM>-<NUM>. Such an eNB <NUM>-<NUM> could still be connected to AMF <NUM> rather than to MME <NUM>, as indicated by the dashed line <NUM>, to provide LTE wireless access to a UE <NUM> via 5GC <NUM> rather than via EPC <NUM>. In that case, the eNB <NUM>-<NUM> could function exactly the same as the ng-eNB <NUM>-<NUM>. In such a case, the eNB <NUM>-<NUM> could communicate with LMF <NUM> using NRPPa (or LPPa) rather than with E-SMLC <NUM> using LPPa, where NRPPa (or LPPa) messages may be transferred between eNB <NUM>-<NUM> and LMF <NUM> via AMF <NUM> and possibly via a gNB <NUM> (e.g. gNB <NUM>-<NUM>) as described later with reference to <FIG> for when UE <NUM> is served by ng-eNB <NUM>-<NUM>. Similarly, when UE <NUM> is served by eNB <NUM>-<NUM>, with eNB <NUM>-<NUM> providing LTE access to 5GC <NUM> rather than to EPC <NUM>, LPP messages may be transferred between UE <NUM> and LMF <NUM> via AMF <NUM>, eNB <NUM>-<NUM> and possibly a gNB <NUM> (e.g. gNB <NUM>-<NUM>) similarly to that described later in association with <FIG> for LPP message transfer when UE <NUM> is served by ng-eNB <NUM>-<NUM>.

As previously indicated, embodiments of the techniques provided herein can be utilized in systems having different architectures. <FIG> are illustrative examples of communication systems <NUM> and <NUM>, respectively, showing different architectures that may implement the techniques herein, according to some embodiments. The different architectures illustrated by <FIG> provide different base station arrangements for NG-RAN <NUM> and different ways of connecting base stations in NG-RAN <NUM> to 5GC <NUM> for communication system <NUM>. Thus, communication systems <NUM> and <NUM> can represent different variants of communication system <NUM>. Components of the communication systems <NUM> and <NUM> correspond to those illustrated in the communication system <NUM> illustrated in <FIG> and described above. These components include the UE <NUM>, ng-eNB <NUM>-<NUM>, gNB <NUM>-<NUM>, NG-RAN <NUM>, 5GC <NUM>, AMF <NUM>, and LMF <NUM>. Optional components, interfaces and protocols are illustrated with dashed lines, as described in more detail below. Here, an NR interface (NR-Uu), an LTE or enhanced or evolved LTE interface (eLTE-Uu), an AMF to NG-RAN interface (N2), an AMF to LMF interface (NLs), and a gNB to ng-eNB interface (Xn) (which may also be a gNB to gNB and a ng-eNB to ng-eNB interface) are shown as dashed or solid lines between components. Protocols LPP and NRPPa that are used between a pair of components are further illustrated by dashed and solid double arrows, where each arrow joins the pair of components. An arrow passing through an intermediate component illustrates where the intermediate component can relay messages for the protocol illustrated by the arrow. For example, as illustrated, all communication in <FIG> between the LMF <NUM> and other components are relayed via the AMF <NUM> which acts as an intermediate component. It will be understood by a person of ordinary skill in the art that the architectures illustrated in <FIG> may include additional and/alternative components (such as GMLC <NUM> and external client <NUM> of <FIG>), which are not illustrated. Moreover, it can be further noted that, although an NG-RAN <NUM> and 5GC <NUM> are illustrated, embodiments described herein may be implemented with other RAN and/or CORE components.

In communication system <NUM> in <FIG>, gNBs <NUM> are present in NG-RAN <NUM> and connect directly to AMFs in 5GC <NUM>, as exemplified by connection of gNB <NUM>-<NUM> in NG-RAN <NUM> to AMF <NUM> in 5GC <NUM>. When ng-eNBs <NUM> (e.g. the optional ng-eNB <NUM>-<NUM>) are not present in NG-RAN <NUM>, communication system <NUM> may be referred to as a standalone <NUM> (or NR) architecture, also referred to in 3GPP as "Option <NUM>". With this arrangement or option, LPP messages <NUM> can be exchanged between UE <NUM> and LMF <NUM> via gNB <NUM>-<NUM> and AMF <NUM>, and NRPPa messages <NUM> can be exchanged between gNB <NUM>-<NUM> and LMF <NUM> via AMF <NUM>. When ng-eNBs <NUM> (e.g. the optional ng-eNB <NUM>-<NUM>) are present in NG-RAN <NUM>, communication system <NUM> may be referred to as a standalone <NUM> (or NR) with non-standalone E-UTRA architecture, also referred to in 3GPP as "Option <NUM>". With this arrangement or option, when UE <NUM> is served by ng-eNB <NUM>-<NUM>, LPP messages <NUM> can be exchanged between UE <NUM> and LMF <NUM> via gNB <NUM>-<NUM>, ng-eNB <NUM>-<NUM> and AMF <NUM>, and NRPPa messages <NUM> can be exchanged between ng-eNB <NUM>-<NUM> and LMF <NUM> via gNB <NUM>-<NUM> and AMF <NUM>. With this (Option <NUM>) arrangement, LPP and NRPPa messages may not be transferred directly between AMF <NUM> and ng-eNB <NUM>-<NUM> but may instead be transferred via gNB <NUM>-<NUM> using the Xn interface to transfer the messages between gNB <NUM>-<NUM> and ng-eNB <NUM>-<NUM>.

<FIG>, similar to <FIG>, illustrates different embodiments that can be implemented depending on desired functionality. Here, however, the roles of gNB <NUM>-<NUM> and ng-eNB <NUM>-<NUM> are reversed. Thus, in communication system <NUM>, ng-eNBs <NUM> are present in NG-RAN <NUM> and connect directly to AMFs in 5GC <NUM>, as exemplified by connection of ng-eNB <NUM>-<NUM> in NG-RAN <NUM> to AMF <NUM> in 5GC <NUM>. When gNBs <NUM> (e.g. the optional gNB <NUM>-<NUM>) are not present in NG-RAN <NUM>, communication system <NUM> may be referred to as a standalone E-UTRA 5GS architecture, also referred to in 3GPP as "Option <NUM>". With this arrangement or option, LPP messages <NUM> can be exchanged between UE <NUM> and LMF <NUM> via ng-eNB <NUM>-<NUM> and AMF <NUM>, and NRPPa messages <NUM> can be exchanged between ng-eNB <NUM>-<NUM> and LMF <NUM> via AMF <NUM>. When gNBs <NUM> (e.g. the optional gNB <NUM>-<NUM>) are present in NG-RAN <NUM>, communication system <NUM> may be referred to as a standalone E-UTRA with non-standalone NR architecture, also referred to in 3GPP as "Option <NUM>". With this arrangement or option, when UE <NUM> is served by gNB <NUM>-<NUM>, LPP messages <NUM> can be exchanged between UE <NUM> and LMF <NUM> via gNB <NUM>-<NUM>, ng-eNB <NUM>-<NUM> and AMF <NUM>, and NRPPa messages <NUM> can be exchanged between gNB <NUM>-<NUM> and LMF <NUM> via ng-eNB <NUM>-<NUM> and AMF <NUM>. With this (Option <NUM>) arrangement, LPP and NRPPa messages may not be transferred directly between AMF <NUM> and gNB <NUM>-<NUM> but may instead be transferred via ng-eNB <NUM>-<NUM> using the Xn interface to transfer the messages between gNB <NUM>-<NUM> and ng-eNB <NUM>-<NUM>.

It can be noted that use of the existing LPP protocol for positioning of UE <NUM> with access to NG-RAN <NUM> as described and illustrated previously with reference to <FIG> could be adapted or replaced by new or modified protocols for NG-RAN <NUM> (or another RAN, if utilized). In some embodiments, adaptations might include an extension of LPP or a replacement of LPP which may be needed to support position methods in which UE <NUM> obtains measurements of NR signals transmitted by one or more gNBs <NUM>. Such NR related measurements could include measurements of RSRP, RSRQ, RSTD, round trip signal propagation time (RTT) and/or angle of arrival (AOA). In one embodiment, referred to as Alternative A1, LPP may be extended to support new NR RAT-dependent (and possible other RAT-independent) position methods such as NR RAT-dependent position methods similar to OTDOA or ECID for LTE access. In another embodiment, referred to as Alternative A2, an entirely new protocol (e.g. an NR Positioning Protocol (NPP or NRPP)) may be defined to be used instead of LPP, where the new protocol provides support for NR RAT-dependent and other RAT-independent position methods, In a further embodiment, referred to as Alternative A3, a new protocol (e.g. NPP or NRPP) may be defined that is restricted to supporting NR RAT-dependent position methods only and is used in combination with LPP when both NR RAT-dependent and RAT-independent positioning (and/or LTE RAT-dependent positioning) are needed. Alternative A3 may use one of three variants. In a first variant of A3, a message for the new protocol may be embedded inside an LPP message as a new External Protocol Data Unit (EPDU) according to the definition of an EPDU in 3GPP TS <NUM>. In a second variant of A3, an LPP message may be embedded inside a message for the new protocol, for example using an EPDU similar to the definition of an EPDU in 3GPP TS <NUM>. In a third variant of A3, the new protocol may be separate from (e.g. not embedded within or capable of embedding) LPP, but with an LMF <NUM> and UE <NUM> able to exchange a message or messages for both the new protocol and LPP using the same NAS transport container. In another embodiment, referred to as Alternative A4, a new protocol may be defined that embeds portions of LPP to support RAT-independent position methods and/or E-UTRA RAT-dependent position methods (e.g. via importing Abstract Syntax Notation One (ASN. <NUM>) data types from LPP).

While the different alternatives A1 to A4 above may be most applicable to positioning a UE <NUM> with NR wireless access to a gNB <NUM> in NG-RAN <NUM>, they also may be applicable to positioning a UE <NUM> with LTE access to an ng-eNB <NUM> in NG-RAN <NUM>, due to the possibility of using NR RAT-dependent position methods for gNBs <NUM> nearby to UE <NUM> whose signals are measurable by UE <NUM>.

<FIG> is a signaling flow diagram illustrating the various messages sent between components of the communication system <NUM> during a location session using LPP (also referred to as a session, an LPP session or an LPP location session) between the UE <NUM> and the LMF <NUM>, according to an embodiment. The signaling flow in <FIG> may apply when UE <NUM> has NR (<NUM>) wireless access to a gNB <NUM> in NG-RAN <NUM>, which in the example in <FIG> is assumed to be gNB <NUM>-<NUM>. The LPP session can be triggered by action <NUM>, when the LMF <NUM> receives a location request for UE <NUM>. Depending on the scenario and the type of location support in 5GC <NUM>, the location request may come to the LMF <NUM>, from the AMF <NUM>, or from the GMLC <NUM>. The LMF <NUM> may query AMF <NUM> for information for the UE <NUM> or the AMF <NUM> may send information for UE <NUM> to LMF <NUM> (e.g. if AMF <NUM> sends the location request at action <NUM> to LMF <NUM>) (not shown in <FIG>). The information may indicate that the UE <NUM> has NR wireless access to NG-RAN <NUM>, may provide a current NR serving cell for UE <NUM> (e.g. a cell supported by gNB <NUM>-<NUM> which may be a serving gNB for UE <NUM>) and/or may indicate that UE <NUM> supports location using LPP when UE <NUM> has NR wireless access (or when UE <NUM> has access to NG-RAN <NUM>). Some or all of this information may have been obtained by AMF <NUM> from UE <NUM> and/or from gNB <NUM>-<NUM> - e.g. when the UE <NUM> performs a registration with AMF <NUM> (e.g. using NAS).

To begin the LPP session (e.g. and based on an indication of UE <NUM> support for LPP with NR wireless access), the LMF <NUM> can send an LPP Request Capabilities message to the AMF <NUM> serving the UE <NUM> (e.g. using <NUM> LCS AP), at action <NUM>. The AMF <NUM> may include the LPP Request Capabilities message within a <NUM> NAS transport message, which is sent to the UE <NUM> at action <NUM> (e.g., via a NAS communication path in the NG-RAN <NUM>, as illustrated in <FIG>). The UE <NUM> may then respond to the AMF <NUM> by sending an LPP Provide Capabilities message to AMF <NUM>, also within a <NUM> NAS transport message, at action <NUM>. The AMF <NUM> may extract the LPP Provide Capabilities message from the <NUM> NAS transport message and relays the LPP provide capabilities message to the LMF <NUM> at action <NUM> (e.g. using <NUM> LCS AP).

Here, the LPP Provide Capabilities message sent at actions <NUM> and <NUM> can indicate the positioning capabilities of the UE <NUM> (e.g., position methods supported by the UE <NUM> such as A-GNSS positioning, RTK positioning, OTDOA positioning, ECID positioning, WLAN positioning, etc.) while accessing a <NUM> network using NR. This means that some of the positioning capabilities of the UE <NUM> could be different than when the UE <NUM> is accessing the EPC <NUM> via E-UTRAN <NUM> using LTE. For example, in some scenarios, although the UE <NUM> may have the capability of supporting OTDOA positioning for LTE (also referred to as OTDOA for E-UTRA) while accessing an LTE network, the UE <NUM> may not have the capability of supporting OTDOA positioning for LTE while accessing a <NUM> network using NR. If this is the case, then the UE <NUM> may not indicate in the LPP Provide Capabilities message sent at actions <NUM> and <NUM> that it has OTDOA positioning capabilities for LTE. In some other scenarios, UE <NUM> may be able to support LTE position methods such as OTDOA and/or ECID when accessing a <NUM> network using NR (e.g. based on the techniques described herein), in which case the LPP Provide Capabilities message sent at actions <NUM> and <NUM> may indicate this UE support. The positioning capabilities of UE <NUM> sent at actions <NUM> and <NUM> enable the LMF <NUM> to determine which capabilities the UE <NUM> has while accessing a <NUM> network.

With the positioning capabilities of the UE <NUM>, the LMF <NUM> can determine assistance data for the UE <NUM> to support one or more of the position methods indicated by UE <NUM> as supported. For example, if UE <NUM> indicates support for OTDOA for LTE at actions <NUM> and <NUM>, LMF <NUM> may send an NRPPa OTDOA Information Request message to an ng-eNB <NUM>-<NUM> at action <NUM> (relayed to the ng-eNB <NUM>-<NUM> via the AMF <NUM> at action <NUM>). The ng-eNB <NUM>-<NUM> may respond with an NRPPa OTDOA Information Response at action <NUM> (relayed to the LMF <NUM> via the AMF <NUM> at action <NUM>). LMF <NUM> may similarly send an LPPa OTDOA Information Request message to an eNB <NUM>-<NUM> at action <NUM> (relayed to the eNB <NUM>-<NUM> via the MME <NUM> at action <NUM>). The eNB <NUM>-<NUM> may respond with an LPPa OTDOA Information Response at action <NUM> (relayed to the LMF <NUM> via the AMF <NUM> at action <NUM>). It will be understood that similar communications between the LMF <NUM> and other eNBs <NUM> and/or other ng-eNBs <NUM> may occur to collect OTDOA assistance data and that in some scenarios, LMF <NUM> may request information (using LPPa) only from eNBs <NUM> or may request information (using NRPPa) only from ng-eNBs <NUM>. Furthermore, as indicated in <FIG> and described for <FIG>, communications between the eNBs <NUM> and the LMF <NUM> may be relayed via the E-SMLC <NUM>. The information provided by each eNB <NUM> and each ng-eNB <NUM> to LMF <NUM> in an LPPa or NRPPa OTDOA Information Response (e.g. at actions <NUM>-<NUM> and <NUM>-<NUM>) may include location coordinates of the eNB <NUM> or ng-eNB <NUM>, PRS timing information and PRS configuration information (e.g. PRS configuration parameters) for the eNB <NUM> or ng-eNB <NUM>, as described later for <FIG> and <FIG>.

The LMF <NUM> may then send some or all of the assistance data received at actions <NUM> and <NUM> to UE <NUM> (e.g. may send PRS configuration information for eNB <NUM>-<NUM> and/or ng-eNB <NUM>-<NUM>) via an LPP Provide Assistance Data message sent to the AMF <NUM> at action <NUM>, and relayed to the UE <NUM> in a <NUM> NAS transport message by AMF <NUM> at action <NUM>. This may be followed by an LPP Request Location Information message, again sent from the LMF <NUM> to AMF <NUM>, at action <NUM>, which is relayed to the UE <NUM> in a <NUM> NAS transport message by AMF <NUM>, and via gNB <NUM>-<NUM>, at action <NUM>. The LPP Request Location Information message may request one or more location measurements from UE <NUM> and/or a location estimate according to the position capabilities of UE <NUM> sent to LMF <NUM> at actions <NUM> and <NUM>. The location measurements may for example include Reference Signal Time Difference (RSTD) measurements for OTDOA for LTE, pseudorange or code phase measurements for A-GNSS, carrier phase measurements for RTK, WiFi measurements for WLAN positioning, and/or measurements of AOA, RSRP and/or RSRQ for ECID for LTE (also referred to as ECID for E-UTRA).

In response, at block <NUM>, the UE <NUM> may obtain some or all of the location measurements requested at actions <NUM> and <NUM>. In some embodiments, and if requested at actions <NUM> and <NUM>, UE <NUM> may also obtain a location estimate at block <NUM> based on the location measurements and possibly based also on some or all of the assistance data received at action <NUM>. The location measurements or the location estimate may be provided in an LPP Provide Location message, which may be sent by the UE <NUM> to the AMF <NUM>, via gNB <NUM>-<NUM>, in a <NUM> NAS transport message at action <NUM>. The AMF <NUM> may extract the LPP Provide Location message from the <NUM> NAS transport message, and relay it to the LMF <NUM> (e.g. using <NUM> LCS AP) at action <NUM>. With this information, the LMF <NUM> may determine or verify the UE location, at block <NUM>, and provide a location response containing the determined or verified location to the requesting entity at action <NUM>.

In <FIG>, the LMF <NUM> may request the UE <NUM> to obtain OTDOA RSTD measurements for LTE at actions <NUM> and <NUM>, and the OTDOA RSTD measurements obtained at block <NUM> may be obtained from ng-eNBs <NUM> (e.g. ng-eNB <NUM>-<NUM>) and/or from eNBs <NUM> (e.g. eNB <NUM>-<NUM>). This may present an issue in cases when the carrier frequency used for LTE wireless access by ng-eNBs <NUM> and/or by eNBs <NUM> is different than the carrier frequency of the <NUM> network for NR wireless access or when simply measuring ng-eNB <NUM> and/or eNB <NUM> wireless signals (e.g., PRS signals) prevents or obstructs normal NR wireless access by UE <NUM>. Moreover, LTE timing of ng-eNBs <NUM> in NG-RAN <NUM> and/or LTE timing of eNBs <NUM> in E-UTRAN <NUM> may be different than the timing used by gNBs <NUM> in NG-RAN <NUM>, making RSTD measurements of PRS signals for OTDOA (e.g. as described for <FIG> and <FIG>) difficult or impossible for UE <NUM>.

To address these issues, the UE <NUM> is configured to tune away from NR access to gNB <NUM>-<NUM> for a period of time (e.g., for <NUM>-<NUM>) to enable UE <NUM> to look for and find a suitable reference LTE cell (e.g., supported by ng-eNB <NUM>-<NUM> or by eNB <NUM>-<NUM>) that provides LTE coverage in the area of the UE <NUM>. Information regarding a particular reference LTE cell may be provided to the UE <NUM> by the LMF <NUM> at actions <NUM> and <NUM>. For example, prior to action <NUM>, LMF <NUM> may determine the reference LTE cell based on the NR serving cell for the UE - e.g. by choosing an LTE reference cell that has a similar or same coverage area. The UE <NUM> may obtain LTE timing (e.g. an LTE System Frame Number (SFN)) and system information from the reference LTE cell. In order to allow the UE <NUM> a period of time to tune away, the UE <NUM> requests an idle period from the serving gNB <NUM>-<NUM>. Additional details regarding this process are provided in <FIG>.

<FIG> is a signaling flow diagram illustrating messages communicated between various components of communication system <NUM> enabling a UE <NUM> to tune away from NR wireless access for a serving gNB <NUM> in a <NUM> network in order to gather OTDOA timing information from ng-eNBs <NUM> and/or eNBs <NUM> in an LTE network, according to an embodiment. <FIG> may correspond to (e.g. may partially or fully support) block <NUM> in <FIG>. It is noted that while <FIG> illustrates tuning away from NR wireless access to obtain OTDOA measurements for LTE, the same or a similar procedure could be used to enable a UE <NUM> to tune away from NR wireless access to obtain other types of location measurements such as measurements for ECID positioning for LTE, A-GNSS, RTK and/or WLAN positioning.

At action <NUM>, UE <NUM> sends an NR Radio Resource Control (RRC) idle period request to a gNB <NUM>-<NUM>. GNB <NUM>-<NUM> may typically be the serving gNB (or primary serving gNB) for UE <NUM>. The request includes the requested length of the idle period (e.g., <NUM>) and when the idle period should occur, sufficient to measure and obtain LTE timing information later at block <NUM>. Depending on desired functionality, the gNB <NUM>-<NUM> may reply by sending an RRC confirm idle period message at action <NUM>. (Otherwise, in some embodiments, the UE <NUM> can assume the request sent at action <NUM> was accepted. ) During the requested idle period, at block <NUM>, gNB <NUM>-<NUM> suspends NR transmission to UE <NUM> and suspends NR reception from UE <NUM> in order to allow UE <NUM> to tune away from NR wireless access during the idle period.

The UE <NUM> can then tune away from the <NUM> NR carrier frequency (e.g. for gNB <NUM>-<NUM>) during the idle period to an LTE carrier frequency supported by ng-eNBs <NUM> and/or by eNBs <NUM>. At block <NUM>, the UE <NUM> can then obtain LTE cell timing and a system frame number (SFN) for an OTDOA reference cell for ng-eNB <NUM>-<NUM> or eNB <NUM>-<NUM> during the idle period. The LTE cell timing and SFN for a reference cell supported by ng-eNB <NUM>-<NUM> or eNB <NUM>-<NUM> may be obtained by UE <NUM> from an RRC System Information Block (SIB) broadcast by ng-eNB <NUM>-<NUM> or eNB <NUM>-<NUM>, respectively, at action <NUM> or action <NUM>, respectively. For example, UE <NUM> may acquire and measure a Master Information Block (MIB) and a SIB broadcast by ng-eNB <NUM>-<NUM> or eNB <NUM>-<NUM>. The identity and a carrier frequency for the reference cell may have been previously provided to UE <NUM> by LMF <NUM> as part of the assistance data sent to UE <NUM> at actions <NUM> and <NUM>. The UE <NUM> may then tune back to NR wireless access to gNB <NUM>-<NUM>.

At block <NUM>, the UE <NUM> can convert the LTE timing of the PRS positioning occasions for reference and neighbor cells for ng-eNBs <NUM> and/or eNBs <NUM> provided by the LMF <NUM> (in the LPP assistance data sent at actions <NUM> and <NUM>) to corresponding NR timing for the gNB <NUM>-<NUM>. This may mean converting LTE PRS subframe timing as described later for <FIG> and <FIG> to equivalent NR timing (e.g. in terms of NR subframes, NR radio frames or other NR signaling units). In performing this conversion, UE <NUM> may determine NR measurements gaps (in terms of NR timing) suitable for measuring LTE PRS signals from ng-eNBs <NUM> and/or eNBs <NUM>.

As indicated in <FIG>, it can be noted that functions described at actions <NUM>-<NUM> and <NUM>-<NUM> and blocks <NUM>, <NUM> and <NUM> are optional, and may be used for OTDOA measurements, if desired. That is, in some embodiments the LMF <NUM> will provide the UE <NUM> with information regarding PRS signals transmitted by the ng-eNBs <NUM> and/or the eNBs <NUM>, including the times at which those PRS signals are transmitted. However, these times may be relative to LTE timing. So, by obtaining timing information from the LTE OTDOA reference cell (or some other LTE cell) at block <NUM>, the UE <NUM> can discover the LTE timing and corresponding absolute times (e.g. Global Positioning System (GPS) times) or local times (e.g. UE internal times) at which the PRS signals will be transmitted. This can allow the UE <NUM> to convert the LTE signal timing for PRS occasions to corresponding NR timing.

The actions performed at blocks <NUM> and <NUM> may be repeated by UE <NUM> for each separate PRS carrier frequency used by the reference and neighbor cells which UE <NUM> was requested to measure by LMF <NUM> at actions <NUM> and <NUM>, since typically ng-eNBs <NUM> and/or eNBs <NUM> would use a different LTE timing for each different carrier frequency but would be synchronized when using the same LTE carrier frequency as described later for <FIG> and <FIG>. This may enable UE <NUM> to determine the NR timing corresponding to the LTE timing for each separate LTE carrier frequency. However, if LMF <NUM> provides UE <NUM> with the relationship between LTE timing for each separate PRS carrier frequency (e.g. as supported by LPP and as described later in association with <FIG> and <FIG>), UE <NUM> may only need to obtain the NR timing corresponding to one PRS carrier frequency at blocks <NUM> and <NUM>, because the UE <NUM> can use the relationship between the LTE timing for each separate PRS carrier frequency to infer the NR timing corresponding to each PRS carrier frequency.

UE <NUM> may then send an NR RRC measurement gap request to gNB <NUM>-<NUM> at action <NUM> to request measurements gaps (e.g. which may comprise a series of periodic short periods of around <NUM>-<NUM>, in some embodiments) with respect to NR timing. GNB <NUM>-<NUM> may optionally confirm the request at action <NUM> (e.g. by sending an RRC confirmation message to UE <NUM>) or UE <NUM> may assume the request will be supported. During each of the measurement gaps, at block <NUM>, gNB <NUM>-<NUM> suspends NR transmission to UE <NUM> and suspends NR reception from UE <NUM> in order to allow UE <NUM> to tune away from NR wireless access during each measurement gap.

The UE <NUM> can then periodically (when each measurement gap occurs) tune away from NR access to gNB <NUM>-<NUM> to acquire and measure a Time of Arrival (TOA) for a PRS broadcast for a reference or neighbor cell for ng-eNB <NUM>-<NUM>, at action <NUM>, and acquire and measure a TOA for a PRS broadcast for a reference or neighbor cell for eNB <NUM>-<NUM>, at action <NUM>. UE <NUM> may then obtain an OTDOA RSTD measurement at block <NUM> from the difference of the two TOA measurements as described later for <FIG> and <FIG>. It is noted that in this example, UE <NUM> is assumed to measure a PRS broadcast in a cell for each of ng-eNB <NUM>-<NUM> and eNB <NUM>-<NUM> and with one of these cells being a reference cell for OTDOA, However, other scenarios are possible in which UE <NUM> measures a PRS broadcast in cells for a pair of eNBs <NUM> or a pair of ng eNBs <NUM> with one of these cells being a reference cell. Furthermore, in all scenarios, UE <NUM> may obtain additional TOA measurements during the measurement gaps for PRS broadcast for other neighbor cells by other ng-eNBs <NUM> and/or other eNBs <NUM> and may use these additional TOA measurements to determine additional RSTD measurements at block <NUM>. Additionally or instead, UE <NUM> may obtain other measurements at block <NUM> during the measurements gaps such as GNSS or RTK measurements for SVs <NUM>. This can be done until sufficient measurements are obtained or until a maximum response interval has expired. At action <NUM>, the UE <NUM> can then optionally send a RRC measurement gap stop message to the gNB <NUM>-<NUM> to advise gNB <NUM>-<NUM> that measurement gaps are no longer needed.

The UE <NUM> can then include the measurements in an LPP Provide Location message (e.g., at action <NUM>, continuing the process illustrated in <FIG>).

In one variant to the procedure shown in <FIG>, LMF <NUM> may provide the relationship between NR timing for gNB <NUM>-<NUM> and LTE timing (e.g. for an OTDOA reference cell for ng-eNB <NUM>-<NUM> or eNB <NUM>-<NUM>) to UE <NUM> in the assistance data sent at actions <NUM> and <NUM>. For example, LMF <NUM> may request and obtain information from gNB <NUM>-<NUM> using NRPPa by using the same or a similar procedure to that used to obtain OTDOA related information from ng-eNB <NUM>-<NUM> at actions <NUM>-<NUM>. If the information obtained from gNB <NUM>-<NUM> and the OTDOA related information obtained from ng-eNB <NUM>-<NUM> at actions <NUM>-<NUM> and/or from eNB <NUM>-<NUM> at actions <NUM>-<NUM> include timing information (e.g. NR timing information relative to an absolute time such as GPS time for gNB <NUM>-<NUM> and LTE timing relative to an absolute time for ng-eNB <NUM>-<NUM> and/or eNB <NUM>-<NUM>), then LMF <NUM> may be able to infer the relationship between NR timing and LTE timing and provide this as assistance data to UE <NUM> at actions <NUM> and <NUM>. In this case, UE <NUM> may not need to perform actions <NUM>-<NUM>, actions <NUM>-<NUM> and blocks <NUM> and <NUM>, and gNB <NUM>-<NUM> may not need to perform block <NUM>.

<FIG> is an illustration of the structure of an LTE subframe sequence with PRS positioning occasions, according to an embodiment. In <FIG>, time is represented horizontally (e.g., on an X axis) with time increasing from left to right, while frequency is represented vertically (e.g., on a Y axis) with frequency increasing (or decreasing) from bottom to top, as illustrated. As shown in <FIG>, downlink and uplink LTE Radio Frames <NUM> are of <NUM> duration each. For downlink Frequency Division Duplex (FDD) mode, Radio Frames <NUM> are organized into ten subframes <NUM> of <NUM> duration each. Each subframe <NUM> comprises two slots <NUM>, each of <NUM> duration.

In the frequency domain, the available bandwidth may be divided into uniformly spaced orthogonal subcarriers <NUM>. For example, for a normal length cyclic prefix using <NUM> spacing, subcarriers <NUM> may be grouped into a group of <NUM> subcarriers. Each grouping, which comprises <NUM> subcarriers <NUM>, in <FIG>, is termed a resource block and, in the example above, the number of subcarriers in the resource block may be written as <MAT> For a given channel bandwidth, the number of available resource blocks on each channel <NUM>, which is also called the transmission bandwidth configuration <NUM>, is indicated as <MAT> <NUM>. For example, for a <NUM> channel bandwidth in the above example, the number of available resource blocks on each channel <NUM> is given by.

In the architecture illustrated in <FIG>, an ng-eNB <NUM> and/or an eNB <NUM> may transmit a PRS (i.e. a downlink (DL) PRS) such as the PRS illustrated in <FIG> and (as described later) <FIG>, which may be measured and used for UE (e.g., UE <NUM>) position determination. Since transmission of a PRS by an ng-eNB <NUM> and/or eNB <NUM> is directed to all UEs within radio range, an ng-eNB <NUM> and/or eNB <NUM> can also be considered to broadcast a PRS.

A PRS, which has been defined in 3GPP LTE Release-<NUM> and later releases, may be transmitted by ng-eNBs <NUM> and/or eNBs <NUM> after appropriate configuration (e.g., by an Operations and Maintenance (O&M) server). A PRS may be transmitted in special positioning subframes that are grouped into positioning occasions (also referred to as PRS positioning occasions or as PRS occasions). For example, in LTE, a PRS positioning occasion can comprise a number NPRS of consecutive positioning subframes where the number NPRS may be between <NUM> and <NUM> (e.g. may include the values <NUM>, <NUM>, <NUM> and <NUM> as well as other values). The PRS positioning occasions for a cell supported by an ng-eNB <NUM> or eNB <NUM> may occur periodically at intervals, denoted by a number TPRS, of millisecond (or subframe) intervals where TPRS may equal <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, or <NUM>. As an example, <FIG> illustrates a periodicity of positioning occasions where NPRS equals <NUM> and TPRS is greater than or equal to <NUM>. In some embodiments, TPRS may be measured in terms of the number of subframes between the start of consecutive PRS positioning occasions.

Within each positioning occasion, a PRS may be transmitted with a constant power. A PRS can also be transmitted with zero power (i.e., muted). Muting, which turns off a regularly scheduled PRS transmission, may be useful when PRS signals between different cells overlap by occurring at the same or almost the same time. In this case, the PRS signals from some cells may be muted while PRS signals from other cells are transmitted (e.g. at a constant power). Muting may aid signal acquisition and RSTD measurement by a UE <NUM> for PRS signals that are not muted by avoiding interference from PRS signals that have been muted. Muting may be viewed as the non-transmission of a PRS for a given positioning occasion for a particular cell. Muting patterns may be signaled (e.g. using LPP) to UE <NUM> using bit strings. For example, in a bit string signaling a muting pattern, if a bit at position j is set to "<NUM>", then UE <NUM> may infer that the PRS is muted for a jth positioning occasion.

To further improve hearability of PRS, positioning subframes may be low-interference subframes that are transmitted without user data channels. As a result, in ideally synchronized networks, PRSs may receive interference from other cell PRSs with the same PRS pattern index (i.e., with the same frequency shift), but not from data transmissions. The frequency shift, in LTE, for example, is defined as a function of a PRS ID for a cell or Transmission Point (TP) (denoted as <MAT>) or as a function of a Physical Cell Identifier (PCI) (denoted as <MAT>) if no PRS ID is assigned, which results in an effective frequency re-use factor of <NUM>.

To improve hearability of a PRS further (e.g. when PRS bandwidth is limited such as with only <NUM> resource blocks corresponding to <NUM> bandwidth), the frequency band for consecutive PRS positioning occasions (or consecutive PRS subframes) may be changed in a known and predictable manner via frequency hopping. In addition, a cell supported by an ng-eNB <NUM> or an eNB <NUM> may support more than one PRS configuration, where each PRS configuration comprises a distinct sequence of PRS positioning occasions with a particular number of subframes (NPRS) per positioning occasion and a particular periodicity (TPRS). Further enhancements of a PRS may also be supported by an ng-eNB <NUM> or an eNB <NUM>.

OTDOA assistance data is usually provided to a UE <NUM> by a location server (e.g. E-SMLC <NUM> or LMF <NUM>) for a "reference cell" and one or more "neighbor cells" or "neighboring cells" relative to the "reference cell. " For example, the assistance data may provide the center channel frequency of each cell (also referred to as a carrier frequency), various PRS configuration parameters (e.g., NPRS, TPRS, muting sequence, frequency hopping sequence, PRS ID, PRS code sequence, PRS bandwidth), a cell global ID and/or other cell related parameters applicable to OTDOA.

PRS positioning by UE <NUM> may be facilitated by including the serving cell for the UE <NUM> in the OTDOA assistance data (e.g. with the reference cell indicated as being the serving cell). In the case of a UE <NUM> with NR wireless access, the reference cell may be chosen by the LMF <NUM> as some cell for an ng-eNB <NUM> or eNB <NUM> with good coverage at the expected approximate location of UE <NUM> (e.g. as indicated by the known NR serving cell for UE <NUM>).

OTDOA assistance data may also include "expected RSTD" parameters, which provide the UE <NUM> with information about the RSTD values the UE <NUM> is expected to measure at its current location between the reference cell and each neighbor cell together with an uncertainty of the expected RSTD parameter. The expected RSTD together with the uncertainty define a search window for the UE <NUM> within which the UE <NUM> is expected to measure the RSTD value (or a TOA value corresponding to an RSTD value). OTDOA assistance information may also include PRS configuration information parameters, which allow a UE <NUM> to determine when a PRS positioning occasion occurs on signals received from various neighbor cells relative to PRS positioning occasions for the reference cell, and to determine the PRS sequence transmitted from various cells in order to measure a signal Time of Arrival (TOA) or RSTD.

Using the RSTD measurements, the known absolute or relative transmission timing of each cell, and the known position(s) of ng-eNB <NUM> and/or eNB <NUM> physical transmitting antennas for the reference and neighboring cells, the UE <NUM>'s position may be calculated (e.g., by LMF <NUM> or by UE <NUM>). The RSTD for a neighbor cell "k" relative to a reference cell "Ref", may be given as (TOAk - TOARef). TOA measurements for different cells may then be converted to RSTD measurements (e.g. as defined in 3GPP TS <NUM> entitled "Physical layer; Measurements") and sent to the location server (e.g. LMF <NUM>) by the UE <NUM>. Using (i) the RSTD measurements, (ii) the known absolute or relative transmission timing of each cell, and (iii) the known position(s) of ng-eNB <NUM> and/or eNB <NUM> physical transmitting antennas for the reference and neighboring cells, the UE <NUM>'s position may be determined.

<FIG> illustrates further aspects of PRS transmission for a cell supported by an ng-eNB <NUM> or eNB <NUM>. <FIG> shows how PRS positioning occasions are determined by a System Frame Number (SFN), a cell specific subframe offset (ΔPRS) and the PRS Periodicity (TPRS) <NUM>. Typically, the cell specific PRS subframe configuration is defined by a "PRS Configuration Index" IPRS included in the OTDOA assistance data. The PRS Periodicity (TPRS) <NUM> and the cell specific subframe offset (ΔPRS) (e.g. as shown in <FIG>) are defined based on the PRS Configuration Index IPRS, in 3GPP TS <NUM> entitled "Physical channels and modulation," as exemplified in Table <NUM> below.

A PRS configuration is defined with reference to the System Frame Number (SFN) of a cell that transmits PRS. PRS instances, for the first subframe of the NPRS downlink subframes comprising a first PRS positioning occasion, may satisfy: <MAT> where,.

As shown in <FIG>, the cell specific subframe offset ΔPRS <NUM> may be defined in terms of the number of subframes transmitted starting from System Frame Number <NUM>, Slot Number <NUM><NUM> to the start of the first (subsequent) PRS positioning occasion. In <FIG>, the number of consecutive positioning subframes <NUM> (NPRS) equals <NUM>.

In some embodiments, when UE <NUM> receives a PRS configuration index IPRS in the OTDOA assistance data for a particular cell, UE <NUM> may determine the PRS periodicity TPRS and PRS subframe offset ΔPRS using Table <NUM>. The UE <NUM> may then determine the radio frame, subframe and slot when a PRS is scheduled in the cell (e.g. using equation (<NUM>)). The OTDOA assistance data may be determined by LMF <NUM> and includes assistance data for a reference cell, and a number of neighbor cells supported by ng-eNBs <NUM> and/or eNBs <NUM>.

Typically, PRS occasions from all cells in a network that use the same carrier frequency are aligned in time and may have a fixed known time offset relative to other cells in the network that use a different carrier frequency. In SFN-synchronous networks all ng-eNBs <NUM> and all eNBs <NUM> may be aligned on both frame boundary and system frame number. Therefore, in SFN-synchronous networks all cells supported by ng-eNBs <NUM> and eNBs <NUM> may use the same PRS configuration index for any particular frequency of PRS transmission. On the other hand, in SFN-asynchronous networks all ng-eNBs <NUM> and all eNBs <NUM> may be aligned on a frame boundary, but not system frame number. Thus, in SFN-asynchronous networks the PRS configuration index for each cell may be configured separately by the network so that PRS occasions align in time.

UE <NUM> may determine the LTE timing (also referred to as PRS timing) of the PRS occasions of the reference and neighbor cells for OTDOA positioning, if UE <NUM> can obtain the cell timing (e.g., SFN or Frame Number) of at least one of the cells (e.g., the reference cell) - e.g. as at block <NUM> in <FIG>. The LTE timing of the other cells may then be derived by UE <NUM>, for example based on the assumption that PRS occasions from different cells overlap.

<FIG> and <FIG> show how LTE PRS timing may be conveyed, converted, and/or measured at blocks <NUM>, <NUM> and <NUM> in <FIG>.

<FIG> is a flow diagram illustrating a method <NUM> of supporting location of a UE with <NUM> NR wireless access, according to an embodiment. It can be noted that, as with figures appended hereto, <FIG> is provided as a non-limiting example. Other embodiments may vary, depending on desired functionality. For example, the functional blocks illustrated in method <NUM> may be combined, separated, or rearranged to accommodate different embodiments. The method <NUM> may be performed by a UE such as the UE <NUM>. Means for performing the functionality of method <NUM> may include hardware and/or software means of a UE, such as the UE <NUM> for <FIG> and shown in <FIG> and described above.

The functionality at block <NUM> comprises receiving a first Long Term Evolution (LTE) Positioning Protocol (LPP) message from a location server such as a Location Management Function (e.g. LMF <NUM>), where the first LPP message comprises a location request and is received via a serving <NUM> base station such as a gNB (e.g. gNB <NUM>-<NUM>). Block <NUM> may correspond to action <NUM> in <FIG>. Means for performing the functionality at block <NUM> can include, for example, processing unit(s) <NUM>, bus <NUM>, memory <NUM>, wireless communication interface <NUM>, wireless communication antenna(s) <NUM>, and/or other hardware and/or software components of the UE <NUM> as shown in <FIG> and described below.

At block <NUM>, at least one location measurement is obtained, based on the first LPP message, where the at least one location measurement is a measurement for a Radio Access Technology (RAT) independent position method or a measurement for an Evolved Universal Terrestrial Radio Access (E-UTRA) position method. In some embodiments, the RAT-independent position method may comprise Assisted Global Navigation Satellite System (A-GNSS), Real Time Kinematics (RTK), Precise Point Positioning (PPP), Differential A-GNSS, Wireless Local Area Network (WLAN) (also referred to as WiFi positioning), Bluetooth, Sensors, or any combination thereof. The E-UTRA position method may comprise Observed Time Difference Of Arrival (OTDOA) for E-UTRA or Enhanced Cell ID (ECID) for E-UTRA. Block <NUM> may correspond to block <NUM> in <FIG>.

Means for performing the functionality at block <NUM> can include, for example, processing unit(s) <NUM>, bus <NUM>, memory <NUM>, wireless communication interface <NUM>, wireless communication antenna(s) <NUM>, and/or other hardware and/or software components of the UE <NUM> as shown in <FIG> and described below.

The functionality at block <NUM> includes determining location information based on the at least one location measurement. For example, the location information may comprise a location estimate for the UE. Alternatively, the location information may comprise the at least one location measurement. Block <NUM> may correspond to block <NUM> in <FIG>. Means for performing the functionality at block <NUM> can include, for example, processing unit(s) <NUM>, bus <NUM>, memory <NUM>, wireless communication interface <NUM>, wireless communication antenna(s) <NUM>, and/or other hardware and/or software components of the UE <NUM> as shown in <FIG> and described below.

The functionality at block <NUM> includes sending a second LPP message to the location server, where the second LPP message comprises the location information and is sent via the serving <NUM> base station. Block <NUM> may correspond to action <NUM> in <FIG>. Means for performing the functionality at block <NUM> can include, for example, processing unit(s) <NUM>, bus <NUM>, memory <NUM>, wireless communication interface <NUM>, wireless communication antenna(s) <NUM>, and/or other hardware and/or software components of the UE <NUM> as shown in <FIG> and described below.

Alternative embodiments of the method <NUM> may include additional features, depending on desired functionality. For instance, in some embodiments, the first LPP message is an LPP Request Location Information message and the second LPP message is an LPP Provide Location Information message. Some embodiments may further include receiving a third LPP message from the location server, where the third LPP message comprises assistance data for the RAT-independent position method or the E-UTRA position method and is received via the serving <NUM> base station, and where obtaining the at least one location measurement is based on the assistance data. The third LPP message may be an LPP Provide Assistance Data message (e.g. as at action <NUM> in <FIG>).

Some embodiments may further include receiving a fourth LPP message from the location server, where the fourth LPP message comprises a request for the LPP positioning capabilities of the UE and is received via the serving <NUM> base station, and sending a fifth LPP message to the location server. The fifth LPP message may comprise the LPP positioning capabilities of the UE when the UE has NR wireless access and is sent via the serving <NUM> base station. The fourth LPP message may comprise an LPP Request Capabilities message (e.g. as action <NUM> in <FIG>) and the fifth LPP message may comprise an LPP Provide Capabilities message (e.g. as at action <NUM> in <FIG>).

In some embodiments, the method <NUM> may further comprise sending a request for measurement gaps to the serving <NUM> base station (e.g. as at action <NUM> in <FIG>), and obtaining the at least one location measurement during a measurement gap (e.g. as at action <NUM>, action <NUM> or block <NUM> of <FIG>). In such embodiments, the request for measurement gaps may comprise an NR Radio Resource Control (RRC) message. Moreover, in some embodiments, the at least one location measurement may comprise a Reference Signal Time Difference (RSTD) measurement for OTDOA for E-UTRA, and the method may further comprise sending a request for an idle period to the serving <NUM> base station (e.g. as at action <NUM> in <FIG>), and obtaining LTE timing and/or a System Frame Number (SFN) for an OTDOA reference cell (e.g. for LTE) during the idle period (e.g. as at block <NUM> in <FIG>), where the request for measurement gaps is based on the LTE timing and/or the SFN (e.g. as described for block <NUM> for <FIG>). The request for an idle period may comprise an NR RRC message. The OTDOA reference cell may be a cell for an eNB (e.g. an eNB <NUM>) in an E-UTRAN (e.g. E-UTRAN <NUM>) or may be a cell for an ng-eNB (e.g. an ng-eNB <NUM>) in an NG-RAN (e.g. NG-RAN <NUM>), which may include the serving <NUM> base station.

Some embodiments may further comprise sending an indication to an Access Management Function (AMF) (e.g. AMF <NUM>), which may occur as part of Registration with the AMF, where the indication is an indication that the UE supports LPP with NR wireless access, and where the AMF transfers the indication to the location server. Additionally or alternatively, the first LPP message may be received in a Non-Access Stratum (NAS) transport message (e.g. a <NUM> NAS transport message) and the second LPP message may be sent in a NAS transport message (e.g. a <NUM> NAS transport message), e.g. as described for <FIG>.

<FIG> is a flow diagram illustrating a method <NUM> at a location server, such as an LMF (e.g. LMF <NUM>), for supporting location of a user equipment (UE) such as UE <NUM> with Fifth Generation (<NUM>) NR wireless access, according to an embodiment. It can be noted that, as with figures appended hereto, <FIG> is provided as a non-limiting example. Other embodiments may vary, depending on desired functionality. For example, the functional blocks illustrated in method <NUM> may be combined, separated, or rearranged to accommodate different embodiments. The method <NUM> may be performed by an LMF such as the LMF <NUM>. Means for performing the functionality of method <NUM> may include hardware and/or software means of a computer system, such as the computer system <NUM> shown in <FIG> and described in more detail below.

The functionality at block <NUM> includes comprises sending a first Long Term Evolution (LTE) Positioning Protocol (LPP) message to the UE, where the first LPP message comprises a location request and is sent via an Access Management Function (AMF) (e.g., AMF <NUM>) and a serving <NUM> base station for the UE (e.g. gNB <NUM>-<NUM>). Block <NUM> may correspond to action <NUM> in <FIG>. Means for performing the functionality at block <NUM> can include, for example, processing unit(s) <NUM>, bus <NUM>, communications subsystem <NUM>, wireless communication interface <NUM>, working memory <NUM>, operating system <NUM>, application(s) <NUM>, and/or other hardware and/or software components of the computer system <NUM> as shown in <FIG> and described below.

At block <NUM>, a second LPP message is received from the UE, where the second LPP message comprises location information for the UE and is received via the AMF and the serving <NUM> base station, and where the location information is based on at least one location measurement obtained by the UE. The at least one location measurement may be a measurement for a Radio Access Technology (RAT) independent position method or a measurement for an Evolved Universal Terrestrial Radio Access (E-UTRA) position method. In some embodiments, the RAT-independent position method may comprise Assisted Global Navigation Satellite System (A-GNSS), Real Time Kinematics (RTK), Precise Point Positioning, Differential A-GNSS, Wireless Local Area Network (WLAN), Bluetooth, Sensors, or any combination thereof. The E-UTRA position method may comprise Observed Time Difference Of Arrival (OTDOA) for E-UTRA, and/or Enhanced Cell ID (ECID) for E-UTRA. Block <NUM> may correspond to action <NUM> in <FIG>. Means for performing the functionality at block <NUM> can include, for example, processing unit(s) <NUM>, bus <NUM>, communications subsystem <NUM>, wireless communication interface <NUM>, working memory <NUM>, operating system <NUM>, application(s) <NUM>, and/or other hardware and/or software components of the computer system <NUM> as shown in <FIG> and described below.

At block <NUM>, the functionality includes determining a location estimate for the UE based on the location information. In some embodiments, the location information comprises the location estimate. In some other embodiments, the location information comprises the at least one location measurement. Block <NUM> may correspond to block <NUM> in <FIG>. Means for performing the functionality at block <NUM> can include, for example, processing unit(s) <NUM>, bus <NUM>, working memory <NUM>, operating system <NUM>, application(s) <NUM>, and/or other hardware and/or software components of the computer system <NUM> as shown in <FIG> and described below.

Alternative embodiments of the method <NUM> may have one or more additional features. For example, the first LPP message may comprise an LPP Request Location Information message and the second LPP message may comprise an LPP Provide Location Information message.

In some embodiments, the method <NUM> may further comprise sending a third LPP message to the UE, where the third LPP message comprises assistance data for the RAT-independent position method and/or the E-UTRA position method and is sent via the AMF and the serving <NUM> base station, and where the at least one location measurement is based at least in part on the assistance data. In these embodiments, the third LPP message may comprise an LTP Provide Assistance Data message (e.g. as at action <NUM> in <FIG>). In these embodiments, the at least one location measurement may be a location measurement for OTDOA for E-UTRA, where the assistance data comprises assistance data for at least one eNB (e.g. an eNB <NUM>) in an E-UTRAN (e.g. E-UTRAN <NUM>) or at least one ng-eNB (e.g. an eNB <NUM>) in an NG-RAN (e.g. NG-RAN <NUM>) which may include the serving <NUM> base station. In these embodiments, the assistance data may comprise configuration information for a PRS transmitted by the at least one eNB or by the at least one ng-eNB (e.g. as described for action <NUM> for <FIG>).

The method <NUM> may optionally comprise sending a fourth LPP message to the UE, where the fourth LPP message comprises a request for the LPP positioning capabilities of the UE and is sent via the AMF and the serving <NUM> base station, and receiving a fifth LPP message from the UE, where the fifth LPP message comprises the LPP positioning capabilities of the UE, when the UE has NR wireless access, and is received via the AMF and the serving <NUM> base station. In some embodiments, the fourth LPP message may comprise an LPP Request Capabilities message (e.g. as at action <NUM> in <FIG>) and the fifth LPP message may comprise an LPP Provide Capabilities message (e.g. as at action <NUM> in <FIG>). Moreover, the method <NUM> may optionally comprise receiving an indication from the AMF, where the indication is an indication that the UE supports LPP with NR wireless access and where sending the fourth LPP message is based on the indication.

<FIG> is a flow diagram illustrating a method <NUM> at a <NUM> base station such as a gNB for supporting location of a user equipment (UE) such as UE <NUM> with NR wireless access, according to an embodiment. It can be noted that, as with figures appended hereto, <FIG> is provided as a non-limiting example. Other embodiments may vary, depending on desired functionality. For example, the functional blocks illustrated in method <NUM> may be combined, separated, or rearranged to accommodate different embodiments. The method <NUM> may be performed by a gNB such as a gNB <NUM>. Means for performing the functionality of method <NUM> may include hardware and/or software means of a computer system, such as the computer system <NUM> shown in <FIG> and described in more detail below.

The functionality at block <NUM> includes sending a first LPP message received from an AMF (e.g. AMF <NUM>) to the UE. For example, block <NUM> may include receiving the first LPP message (e.g. an LPP Request Location Information message) inside a NAS transport message from the AMF (or from the AMF via an ng-eNB such as an ng-eNB <NUM>) and sending the first LPP message inside the NAS transport message to the UE as described previously in association with <FIG>. In an embodiment, the <NUM> base station may be a serving base station for the UE. Block <NUM> may correspond to support of action <NUM> by gNB <NUM>-<NUM> in <FIG>. Means for performing the functionality at block <NUM> can include, for example, processing unit(s) <NUM>, bus <NUM>, communications subsystem <NUM>, wireless communication interface <NUM>, antenna <NUM>, working memory <NUM>, operating system <NUM>, application(s) <NUM>, and/or other hardware and/or software components of the computer system <NUM> as shown in <FIG> and described below.

At block <NUM>, the functionality includes receiving a request for measurement gaps from the UE (e.g. as at action <NUM> in <FIG>). For example, the request for measurement gaps may comprise an NR Radio Resource Control (RRC) message. Means for performing the functionality at block <NUM> can include, for example, processing unit(s) <NUM>, bus <NUM>, communications subsystem <NUM>, wireless communication interface <NUM>, antenna <NUM>, working memory <NUM>, operating system <NUM>, application(s) <NUM>, and/or other hardware and/or software components of the computer system <NUM> as shown in <FIG> and described below.

At block <NUM>, the functionality includes suspending NR transmission to the UE and suspending NR reception from the UE during the measurement gaps, where the UE obtains at least one location measurement based on the first LPP message during the measurement gaps, and where the at least one location measurement is a measurement for a Radio Access Technology (RAT)-independent position method or a measurement for an Evolved Universal Terrestrial Radio Access (E-UTRA) position method. In some embodiments, the RAT-independent position method may comprise Assisted Global Navigation Satellite System (A-GNSS), Real Time Kinematics (RTK), Precise Point Positioning (PPP), Differential A-GNSS, Wireless Local Area Network (WLAN), Bluetooth, Sensors, or any combination thereof. Moreover, the E-UTRA position method may comprise Observed Time Difference Of Arrival (OTDOA) for E-UTRA and/or Enhanced Cell ID (ECID) for E-UTRA. Block <NUM> may correspond to block <NUM> in <FIG>. Means for performing the functionality at block <NUM> can include, for example, processing unit(s) <NUM>, bus <NUM>, communications subsystem <NUM>, wireless communication interface <NUM>, antenna <NUM>, working memory <NUM>, operating system <NUM>, application(s) <NUM>, and/or other hardware and/or software components of the computer system <NUM> as shown in <FIG> and described below.

At block <NUM>, the functionality includes transferring a second LPP message received from the UE to the AMF, where the second LPP message comprises location information for the UE, and where the location information is based on the at least one location measurement. For example, block <NUM> may include receiving the second LPP message (e.g. an LPP Provide Location Information message) inside a NAS transport message from the UE and sending the second LPP message inside the NAS transport message to the AMF (or sending the second LPP message to the AMF via an ng-eNB such as an ng-eNB <NUM>) as described previously in association with <FIG>. In one embodiment, the location information comprises a location estimate for the UE. In another embodiment, the location information comprises the at least one location measurement. Block <NUM> may correspond to support of action <NUM> by gNB <NUM>-<NUM> in <FIG>. Means for performing the functionality at block <NUM> can include, for example, processing unit(s) <NUM>, bus <NUM>, communications subsystem <NUM>, wireless communication interface <NUM>, antenna <NUM>, working memory <NUM>, operating system <NUM>, application(s) <NUM>, and/or other hardware and/or software components of the computer system <NUM> as shown in <FIG> and described below.

Alternative embodiments of the method <NUM> may have one or more additional features. For example, and as at action <NUM> in <FIG>, the method <NUM> may optionally comprise sending an RRC message to the UE, where the RRC message confirms the measurement gaps requested by the UE at block <NUM>. Moreover, in some embodiments, the at least one location measurement comprises a Reference Signal Time Difference (RSTD) measurement for OTDOA for E-UTRA. In these embodiments, the method <NUM> comprises receiving a request from the UE for an idle period (e.g. as at action <NUM> in <FIG>), and suspending NR transmission to the UE and suspending NR reception from the UE during the idle period (e.g. as at action <NUM> in <FIG>), where the UE obtains LTE timing and/or a System Frame Number (SFN) for an OTDOA reference cell during the idle period (e.g. as at block <NUM> in <FIG>), and where the request for measurement gaps is based on the LTE timing and/or on the SFN (e.g. as described for block <NUM> for <FIG>). In these embodiments, the request for an idle period comprises an NR Radio Resource Control (RRC) message. In these embodiments, the method <NUM> may further comprise sending an RRC message to the UE, where the RRC message confirms the idle period (e.g. as at action <NUM> in <FIG>).

<FIG> is a block diagram of an embodiment of a UE <NUM>, which can be utilized as described in the embodiments described above and in association with <FIG>. It should be noted that <FIG> is meant only to provide a generalized illustration of various components of UE <NUM>, any or all of which may be utilized as appropriate. In other words, because UEs can vary widely in functionality, they may include only a portion of the components shown in <FIG>. It can be noted that, in some instances, components illustrated by <FIG> can be localized to a single physical device and/or distributed among various networked devices, which may be disposed at different physical locations.

The UE <NUM> is shown comprising hardware elements that can be electrically coupled via a bus <NUM> (or may otherwise be in communication, as appropriate). The hardware elements may include a processing unit(s) <NUM> which may comprise without limitation one or more general-purpose processors, one or more special-purpose processors (such as digital signal processing (DSP) chips, graphics acceleration processors, application specific integrated circuits (ASICs), and/or the like), and/or other processing structure or means, which can be configured to perform one or more of the methods described herein. As shown in <FIG>, some embodiments may have a separate DSP <NUM>, depending on desired functionality. The UE <NUM> also may comprise one or more input devices <NUM>, which may comprise without limitation one or more touch screens, touch pads, microphones, buttons, dials, switches, and/or the like; and one or more output devices <NUM>, which may comprise without limitation, one or more displays, light emitting diode (LED)s, speakers, and/or the like.

The UE <NUM> might also include a wireless communication interface <NUM>, which may comprise without limitation a modem, a network card, an infrared communication device, a wireless communication device, and/or a chipset (such as a Bluetooth® device, an IEEE <NUM> device, an IEEE <NUM>. <NUM> device, a WiFi device, a WiMAX™ device, cellular communication facilities, etc.), and/or the like, which may enable the UE <NUM> to communicate via the networks described above with regard to <FIG>. The wireless communication interface <NUM> may permit data to be communicated with a network, eNBs, ng-eNBs, gNBs, and/or other network components, computer systems, and/or any other electronic devices described herein. The communication can be carried out via one or more wireless communication antenna(s) <NUM> that send and/or receive wireless signals <NUM>.

Depending on desired functionality, the wireless communication interface <NUM> may comprise separate transceivers to communicate with base stations (e.g., eNBs, ng-eNBs and/or gNBs) and other terrestrial transceivers, such as wireless devices and access points. The UE <NUM> may communicate with different data networks that may comprise various network types. For example, a Wireless Wide Area Network (WWAN) may be a Code Division Multiple Access (CDMA) network, a Time Division Multiple Access (TDMA) network, a Frequency Division Multiple Access (FDMA) network, an Orthogonal Frequency Division Multiple Access (OFDMA) network, a Single-Carrier Frequency Division Multiple Access (SC-FDMA) network, a WiMax (IEEE <NUM>), and so on. A CDMA network may implement one or more radio access technologies (RATs) such as cdma2000, Wideband-CDMA (WCDMA), and so on. Cdma2000 includes IS-<NUM>, IS-<NUM>, and/or IS-<NUM> standards. A TDMA network may implement Global System for Mobile Communications (GSM), Digital Advanced Mobile Phone System (D-AMPS), or some other RAT. An OFDMA network may employ LTE, LTE Advanced, New Radio (NR) and so on. <NUM>, LTE, LTE Advanced, NR, GSM, and WCDMA are described in documents from 3GPP. Cdma2000 is described in documents from a consortium named "3rd Generation Partnership Project <NUM>" (3GPP2). 3GPP and 3GPP2 documents are publicly available. A wireless local area network (WLAN) may also be an IEEE <NUM>. 11x network, and a wireless personal area network (WPAN) may be a Bluetooth network, an IEEE <NUM>. 15x, or some other type of network. The techniques described herein may also be used for any combination of WWAN, WLAN and/or WPAN.

The UE <NUM> can further include sensor(s) <NUM>. Such sensors may comprise, without limitation, one or more inertial sensors (e.g., accelerometer(s), gyroscope(s), and or other Inertial Measurement Units (IMUs)), camera(s), magnetometer(s), compass, altimeter(s), microphone(s), proximity sensor(s), light sensor(s), barometer, and the like, some of which may be used to complement and/or facilitate the position determination described herein.

Embodiments of the UE <NUM> may also include a GNSS receiver <NUM> capable of receiving signals <NUM> from one or more GNSS satellites (e.g., SVs <NUM>) using an GNSS antenna <NUM> (which may be combined in some implementations with antenna(s) <NUM>). Such positioning can be utilized to complement and/or incorporate the techniques described herein. The GNSS receiver <NUM> can extract a position of the UE <NUM> , using conventional techniques, from GNSS SVs (e.g. SVs <NUM>) of an GNSS system, such as Global Positioning System (GPS), Galileo, Glonass, Compass, Quasi-Zenith Satellite System (QZSS) over Japan, Indian Regional Navigational Satellite System (IRNSS) over India, Beidou over China, and/or the like. Moreover, the GNSS receiver <NUM> can use various augmentation systems (e.g., a Satellite Based Augmentation System (SBAS)) that may be associated with or otherwise enabled for use with one or more global and/or regional navigation satellite systems. By way of example but not limitation, an SBAS may include an augmentation system(s) that provides integrity information, differential corrections, etc., such as, e.g., Wide Area Augmentation System (WAAS), European Geostationary Navigation Overlay Service (EGNOS), Multi -functional Satellite Augmentation System (MSAS), GPS Aided Geo Augmented Navigation or GPS and Geo Augmented Navigation system (GAGAN), and/or the like. Thus, as used herein a GNSS may include any combination of one or more global and/or regional navigation satellite systems and/or augmentation systems, and GNSS signals may include GNSS, GNSS-like, and/or other signals associated with such one or more GNSS.

The UE <NUM> may further include and/or be in communication with a memory <NUM>. The memory <NUM> may comprise, without limitation, local and/or network accessible storage, a disk drive, a drive array, an optical storage device, a solid-state storage device, such as a random access memory ("RAM"), and/or a read-only memory ("ROM"), which can be programmable, flash-updateable, and/or the like. Such storage devices may be configured to implement any appropriate data stores, including without limitation, various file systems, database structures, and/or the like.

The memory <NUM> of the UE <NUM> also can comprise software elements (not shown), including an operating system, device drivers, executable libraries, and/or other code, such as one or more application programs, which may comprise computer programs provided by various embodiments, and/or may be designed to implement methods, and/or configure systems, provided by other embodiments, as described herein. Merely by way of example, one or more procedures described with respect to the functionality discussed above might be implemented as code and/or instructions executable by the UE <NUM> (and/or a processing unit within the UE <NUM>). In an aspect, then, such code and/or instructions can be used to configure and/or adapt a general purpose computer (or other device) to perform one or more operations in accordance with the described methods.

<FIG> is a block diagram of an embodiment of a computer system <NUM>, which may be used, in whole or in part, to provide the functions of one or more network components as described in the embodiments above (e.g., the LMF <NUM>, AMF <NUM>, gNBs <NUM>, ng-eNBs <NUM>, eNBs <NUM> etc.). It should be noted that <FIG> is meant only to provide a generalized illustration of various components, any or all of which may be utilized as appropriate. <FIG>, therefore, broadly illustrates how individual system elements may be implemented in a relatively separated or relatively more integrated manner. In addition, it can be noted that components illustrated by <FIG> can be localized to a single device and/or distributed among various networked devices, which may be disposed at different geographical locations.

The computer system <NUM> is shown comprising hardware elements that can be electrically coupled via a bus <NUM> (or may otherwise be in communication, as appropriate). The hardware elements may include processing unit(s) <NUM>, which may comprise without limitation one or more general-purpose processors, one or more special-purpose processors (such as digital signal processing chips, graphics acceleration processors, and/or the like), and/or other processing structure, which can be configured to perform one or more of the methods described herein. The computer system <NUM> also may comprise one or more input devices <NUM>, which may comprise without limitation a mouse, a keyboard, a camera, a microphone, and/or the like; and one or more output devices <NUM>, which may comprise without limitation a display device, a printer, and/or the like.

The computer system <NUM> may further include (and/or be in communication with) one or more non-transitory storage devices <NUM>, which can comprise, without limitation, local and/or network accessible storage, and/or may comprise, without limitation, a disk drive, a drive array, an optical storage device, a solid-state storage device, such as a random access memory ("RAM"), and/or a read-only memory ("ROM"), which can be programmable, flash-updateable, and/or the like. Such storage devices may be configured to implement any appropriate data stores, including without limitation, various file systems, database structures, and/or the like. Such data stores may include database(s) and/or other data structures used store and administer messages and/or other information to be sent to one or more devices via hubs, as described herein.

The computer system <NUM> may also include a communications subsystem <NUM>, which may comprise wireless communication technologies managed and controlled by a wireless communication interface <NUM>, as well as wired technologies (such as Ethernet, coaxial communications, universal serial bus (USB), and the like). The wireless communication interface <NUM> may send and receive wireless signals <NUM> (e.g. signals according to NR or LTE) via wireless antenna(s) <NUM>. Thus the communications subsystem <NUM> may comprise a modem, a network card (wireless or wired), an infrared communication device, a wireless communication device, and/or a chipset, and/or the like, which may enable the computer system <NUM> to communicate on any or all of the communication networks described herein to any device on the respective network, including a UE (e.g. UE <NUM>), other computer systems (e.g. an AMF <NUM>, a gNB <NUM>, an ng-eNB <NUM> and/or an eNB <NUM>), and/or any other electronic devices described herein. Hence, the communications subsystem <NUM> may be used to receive and send data as described in the embodiments herein.

In many embodiments, the computer system <NUM> will further comprise a working memory <NUM>, which may comprise a RAM or ROM device, as described above. Software elements, shown as being located within the working memory <NUM>, may comprise an operating system <NUM>, device drivers, executable libraries, and/or other code, such as one or more applications <NUM>, which may comprise computer programs provided by various embodiments, and/or may be designed to implement methods, and/or configure systems, provided by other embodiments, as described herein. Merely by way of example, one or more procedures described with respect to the method(s) discussed above might be implemented as code and/or instructions executable by a computer (and/or a processing unit within a computer); in an aspect, then, such code and/or instructions can be used to configure and/or adapt a general purpose computer (or other device) to perform one or more operations in accordance with the described methods.

A set of these instructions and/or code might be stored on a non-transitory computer-readable storage medium, such as the storage device(s) <NUM> described above. In some cases, the storage medium might be incorporated within a computer system, such as computer system <NUM>. In other embodiments, the storage medium might be separate from a computer system (e.g., a removable medium, such as an optical disc), and/or provided in an installation package, such that the storage medium can be used to program, configure, and/or adapt a general purpose computer with the instructions/code stored thereon. These instructions might take the form of executable code, which is executable by the computer system <NUM> and/or might take the form of source and/or installable code, which, upon compilation and/or installation on the computer system <NUM> (e.g., using any of a variety of generally available compilers, installation programs, compression/decompression utilities, etc.), then takes the form of executable code.

It will be additionally apparent to those skilled in the art that embodiments described herein may result in novel functionality at the UE, location server, and/or base station.

For example, embodiments may include a method of, means for, or device configured to perform functions at a location server to support location of a UE with <NUM> NR wireless access, where the functions include sending a first LPP message to the UE, wherein the first LPP message comprises a location request and is sent via an AMF and a serving <NUM> base station for the UE. Functions further include receiving a second LPP message from the UE, wherein the second LPP message comprises location information for the UE and is received via the AMF and the serving <NUM> base station, where the location information is based on at least one location measurement obtained by the UE, and where the at least one location measurement comprises a measurement for a RAT-independent position method or a measurement for an E-UTRA position method. The functions also include determining a location estimate for the UE based on the location information.

Alternative embodiments may additionally include one or more of the following features. The location information may comprise the location estimate or the at least one location measurement. The first LPP message may comprise an LPP Request Location Information message and the second LPP message may comprise an LPP Provide Location Information message. The RAT-independent position method may comprise Assisted Global Navigation Satellite System (A-GNSS), Real Time Kinematics (RTK), Precise Point Positioning, Differential A-GNSS, Wireless Local Area Network (WLAN), Bluetooth, Sensors, or any combination thereof. The E-UTRA position method may comprise Observed Time Difference Of Arrival (OTDOA) for E-UTRA, or Enhanced Cell ID (ECID) for E-UTRA, or any combination thereof. Functions may further include sending a third LPP message to the UE, where the third LPP message comprises assistance data for the RAT-independent position method or the E-UTRA position method and is sent via the AMF and the serving <NUM> base station, and where the at least one location measurement is based at least in part on the assistance data. The third LPP message may comprise an LPP Provide Assistance Data message. The least one location measurement may comprise a location measurement for OTDOA for E-UTRA, wherein the assistance data comprises assistance data for at least one evolved Node B (eNB) in an E-UTRA network (E-UTRAN) or at least one next generation eNB (ng-eNB) in a Next Generation Radio Access Network (NG-RAN), wherein the serving <NUM> base station is in the NG-RAN. The assistance data may comprise configuration information for a Positioning Reference Signal (PRS) transmitted by the at least one eNB or by the at least one ng-eNB. Functions may further comprise sending a fourth LPP message to the UE, where the fourth LPP message comprises a request for LPP positioning capabilities of the UE and is sent via the AMF and the serving <NUM> base station, and receiving a fifth LPP message from the UE, where the fifth LPP message comprises the LPP positioning capabilities of the UE when the UE has NR wireless access and is received via the AMF and the serving <NUM> base station. The fourth LPP message may comprise an LPP Request Capabilities message and the fifth LPP message comprises an LPP Provide Capabilities message. Functions may further comprise receiving an indication from the AMF, where the indication comprises an indication that the UE supports LPP with NR wireless access, and where sending the fourth LPP message is based on the indication.

In another example, embodiments may include a method of, means for, or device configured to perform functions at a <NUM> New Radio (NR) base station to support location of a UE with <NUM> NR wireless access. Here, the functions comprise sending a first Long Term Evolution (LTE) Positioning Protocol (LPP) message received from an access management function (AMF) to the UE, receiving a request for measurement gaps from the UE, suspending NR transmission to the UE and NR reception from the UE during the measurement gaps, where the UE obtains at least one location measurement based on the first LPP message during the measurement gaps, and where the at least one location measurement is a measurement for a Radio Access Technology (RAT)-independent position method or a measurement for an Evolved Universal Terrestrial Radio Access (E-UTRA) position method. Functions further comprise sending a second LPP message received from the UE to the AMF, where the second LPP message comprises location information for the UE, and where the location information is based on the at least one location measurement.

Alternative embodiments may additionally include one or more of the following features. The <NUM> NR base station may comprise a serving base station for the UE. The <NUM> NR base station may transfer the first LPP message and the second LPP message inside a Non-Access Stratum (NAS) transport message. The RAT-independent position method may comprise Assisted Global Navigation Satellite System (A-GNSS), Real Time Kinematics (RTK), Precise Point Positioning (PPP), Differential A-GNSS, Wireless Local Area Network (WLAN), Bluetooth, Sensors, or any combination thereof. The E-UTRA position method may comprise Observed Time Difference Of Arrival (OTDOA) for E-UTRA or Enhanced Cell ID (ECID) for E-UTRA, or any combination thereof. The location information may comprise a location estimate for the UE. The location information may comprise the at least one location measurement. The request for measurement gaps may comprise an NR Radio Resource Control (RRC) message. Functions may also comprise sending an RRC message to the UE, wherein the RRC message confirms the measurement gaps. The at least one location measurement may comprise a Reference Signal Time Difference (RSTD) measurement for OTDOA for E-UTRA, and functions further comprise receiving a request from the UE for an idle period, and suspending NR transmission to the UE and NR reception from the UE during the idle period, where the UE obtains LTE timing and a System Frame Number (SFN) for an OTDOA reference cell during the idle period, and where the request for measurement gaps is based on the LTE timing and the SFN. The request for an idle period comprises an NR Radio Resource Control (RRC) message. Functions may further comprise sending an RRC message to the UE, wherein the RRC message confirms the idle period.

With reference to the appended figures, components that may comprise memory may comprise non-transitory machine-readable media. The term "machine-readable medium" and "computer-readable medium" as used herein, refer to any storage medium that participates in providing data that causes a machine to operate in a specific fashion. In embodiments provided hereinabove, various machine-readable media might be involved in providing instructions/code to processing units and/or other device(s) for execution. Additionally or alternatively, the machine-readable media might be used to store and/or carry such instructions/code. In many implementations, a computer-readable medium is a physical and/or tangible storage medium. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Common forms of computer-readable media include, for example, magnetic and/or optical media, punchcards, papertape, any other physical medium with patterns of holes, a Random Access Memory (RAM), a Programmable Read-Only Memory (PROM), Erasable PROM (EPROM), a Flash-EPROM, any other memory chip or cartridge, a carrier wave as described hereinafter, or any other medium from which a computer can read instructions and/or code.

The methods, systems, and devices discussed herein are examples. Various embodiments may omit, substitute, or add various procedures or components as appropriate. For instance, features described with respect to certain embodiments may be combined in various other embodiments. Different aspects and elements of the embodiments may be combined in a similar manner. The various components of the figures provided herein can be embodied in hardware and/or software. Also, technology evolves and, thus, many of the elements are examples that do not limit the scope of the disclosure to those specific examples.

Reference throughout this specification to "one example", "an example", "certain examples", or "exemplary implementation" means that a particular feature, structure, or characteristic described in connection with the feature and/or example may be included in at least one feature and/or example of claimed subject matter. Thus, the appearances of the phrase "in one example", "an example", "in certain examples" or "in certain implementations" or other like phrases in various places throughout this specification are not necessarily all referring to the same feature, example, and/or limitation. Furthermore, the particular features, structures, or characteristics may be combined in one or more examples and/or features.

Some portions of the detailed description included herein are presented in terms of algorithms or symbolic representations of operations on binary digital signals stored within a memory of a specific apparatus or special purpose computing device or platform. In the context of this particular specification, the term specific apparatus or the like includes a general purpose computer once it is programmed to perform particular operations pursuant to instructions from program software. Algorithmic descriptions or symbolic representations are examples of techniques used by those of ordinary skill in the signal processing or related arts to convey the substance of their work to others skilled in the art. An algorithm is here, and generally, is considered to be a self-consistent sequence of operations or similar signal processing leading to a desired result. In this context, operations or processing involve physical manipulation of physical quantities. Typically, although not necessarily, such quantities may take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared or otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to such signals as bits, data, values, elements, symbols, characters, terms, numbers, numerals, or the like. It should be understood, however, that all of these or similar terms are to be associated with appropriate physical quantities and are merely convenient labels. Unless specifically stated otherwise, as apparent from the discussion herein, it is appreciated that throughout this specification discussions utilizing terms such as "processing," "computing," "calculating," "determining" or the like refer to actions or processes of a specific apparatus, such as a special purpose computer, special purpose computing apparatus or a similar special purpose electronic computing device. In the context of this specification, therefore, a special purpose computer or a similar special purpose electronic computing device is capable of manipulating or transforming signals, typically represented as physical electronic or magnetic quantities within memories, registers, or other information storage devices, transmission devices, or display devices of the special purpose computer or similar special purpose electronic computing device.

In the preceding detailed description, numerous specific details have been set forth to provide a thorough understanding of claimed subject matter. However, it will be understood by those skilled in the art that claimed subject matter may be practiced without these specific details. In other instances, methods and apparatuses that would be known by one of ordinary skill have not been described in detail so as not to obscure claimed subject matter.

Claim 1:
A method (<NUM>) at a user equipment, UE, (<NUM>) for supporting location of the UE (<NUM>) having Fifth Generation, <NUM>, wireless access, the method comprising:
receiving (<NUM>) a first Long Term Evolution, LTE, Positioning Protocol, LPP, message (<NUM>) from a location server, wherein the first LPP message (<NUM>) comprises a location request and is received via a serving <NUM> base station (<NUM>-<NUM>);
sending a <NUM> Radio Resource Control, RRC, message to the serving <NUM> base station (<NUM>-<NUM>), wherein the <NUM> RRC message comprises a request for an idle period in which the UE may tune away from said <NUM> wireless access, said request including a length of the idle period and when the idle period should occur;
obtaining (<NUM>) while being tuned away from said <NUM> wireless access at least one location measurement (<NUM>) based on the first LPP message (<NUM>), wherein the at least one location measurement (<NUM>) comprises a measurement for a Radio-Access-Technology-, RAT-independent positioning method or a measurement for an Evolved Universal Terrestrial Radio Access, E-UTRA, positioning method;
determining (<NUM>) location information based on the at least one location measurement (<NUM>); and
sending (<NUM>) a second LPP message (<NUM>) to the location server (<NUM>), wherein the second LPP message (<NUM>) comprises the location information and is sent via the serving <NUM> base station (<NUM>-<NUM>).