Method and apparatus for supporting location services via a home node b (hnb)

This application claims the priority of US Patent Provisional Application No. 61/324156 entitled "HNB Location" filed on April 14, 2010, and the above provisional application is assigned to the assignee of this application. And the whole is incorporated herein by reference.

The present disclosure relates to communications in general, and more specifically to techniques for supporting location-fixing services via Home Node B (HNB) in wireless networks.

HNB is an increasingly widespread home base station that is becoming more widely deployed in various locations such as homes, offices, stores, and apartments (femtocells). Or sometimes called a femto base station). These HNBs typically act as base stations for wireless network operators (usually using licensed radio frequencies) to improve wireless coverage, improve throughput, and / or network operators and / or. Alternatively, it can be used to realize other benefits to the user. Unlike macro base stations, which are carefully deployed in specific locations and managed by network operators, HNB can be deployed freely and unplanned by users at any location.

HNB can support communication for one or more user devices (UEs) in coverage. It may be desirable to know the location of the HNB or the UE that communicates with the HNB. For example, there is an HNB within a geographic area where the associated network operator has a license to use the radio frequencies supported by the HNB, for example, the HNB is allowed to operate in its current location. ) It may be necessary to know the location of the HNB to confirm that. As another example, a UE user may use the UE to make an emergency call. The position of the UE is then determined and that position can be used to send emergency assistance to the user. There are many other situations in which it is useful or necessary to know the location of the UE or HNB.

<p> The device (eg, HNB or UE) may have the ability to automatically locate itself without any assistance from the network. For example, the device can support a single Global Navigation Satellite System (GNSS) and can determine its position based on signals received from satellites within the GNSS. Position estimation obtained by a single GNSS can have high accuracy. However, a single GNSS can have some drawbacks, such as a relatively long initial position calculation time (TTFF) and the inability to detect satellites with very low signal strength. Therefore, a technique for HNB and UE that can improve performance over a single GNSS may be highly desired.</p>

<p> Techniques for supporting location-fixing services for HNB and UEs communicating with HNB are described herein. The positioning service may include assisted GNSS (A-GNSS), which may have some advantages over a single GNSS.</p><p> In some embodiments, the positioning service for the UE communicating with the HNB is supported by inter-working the HNB between the user plane positioning method and the control plane positioning method. obtain. In one design, the HNB can receive a request for a positioning service for the UE. HNB can communicate with the positioning server via the user plane positioning method to support the positioning service for the UE. The HNB can also communicate with the UE via the control plane positioning method to support positioning services for the UE. As described below, the HNB can switch between the user plane positioning method and the control plane positioning method. This method may also be performed by another network entity (other than HNB) to support the positioning service for the UE.</p><p> In another aspect, the positioning server can be used to support positioning services and A-GNSS for HNB and UE. The positioning server may be coupled to the HNB gateway (HNB GW), which can be considered by the positioning server as a radio network controller (RNC). In one design, the HNB can receive a request for a positioning service for the UE. HNB can exchange Positioning Calculation Application Part (PCAP) messages with the positioning server via HNG GW to support positioning services for UEs. PCAP messages can be transported between (i) HNB and HNB GW in the first protocol message and (ii) between HNB GW and the location server in the second protocol message. HNB can exchange Radio Resource Control (RRC) messages with the UE to support positioning services for the UE.</p><p> Various aspects and features of the present disclosure will be described in more detail below.</p>

<figref num="1">It is a figure which shows an exemplary wireless network.</figref><figref num="2">It is a figure which shows the message flow for supporting the position-fixing service for UE by the switching operation by HNB between the position-fixing method of a user plane and the position-fixing method of a control plane.</figref><figref num="2A">Continuing with FIG. 2, it is a diagram showing a message flow for supporting a position-fixing service for a UE by a switching operation by HNB between a user plane position-fixing method and a control plane position-fixing method.</figref><figref num="3">It is a figure which shows another exemplary wireless network.</figref><figref num="4">It is a figure which shows the exemplary protocol stack in the various network entities of FIG.</figref><figref num="5">It is a figure which shows the message flow for supporting A-GNSS for UE.</figref><figref num="5A">Following FIG. 5, it is a diagram showing a message flow for supporting A-GNSS for UE.</figref><figref num="6">It is a figure which shows the message flow for continuing the position-fixing procedure of a UE during a handover in HNB GW.</figref><figref num="6A">Continuing from FIG. 6, it is a diagram showing a message flow for continuing the UE positioning procedure during the handover in the HNB GW.</figref><figref num="7">It is a figure which shows the message flow for supporting A-GNSS for HNB.</figref><figref num="8">It is a figure which shows the process for supporting the position-fixing service for UE.</figref><figref num="9">It is a figure which shows the process for supporting the position-fixing service for UE.</figref><figref num="10">It is a figure which shows the process for supporting the position-fixing service for UE.</figref><figref num="11">It is a figure which shows the process for supporting the position-fixing service for HNB.</figref><figref num="12">It is a block diagram of UE and various network entities.</figref>

The techniques described herein to support position-fixing services for devices (eg, HNB and UE) are the 3rd Generation Partnership Project (3GPP) and the 3rd Generation Partnership Project 2 (3rd Generation Partnership Project). It can be used for a variety of wireless networks and technologies, including those defined by an organization named 3GPP2). For example, the technology is a wideband code division multiple access (WCDMA) network that implements Universal Terrestrial Radio Access (UTRA) as defined by 3GPP, and a Long Term that implements Evolved Universal Terrestrial Radio Access (E-UTRA) as defined by 3GPP. It can be used for Evolution (LTE) networks and the like. WCDMA is part of the Universal Mobile Telecommunication System (UMTS). LTE is 3GPP Evolved Packet It is part of System (EPS). WCDMA, LTE, UTRA, E-UTRA, UMTS and EPS are described in documents from 3GPP. The technology can also be used for other wireless networks (eg, 3GPP and 3GPP2 networks) and other wireless technologies.

The techniques described herein can also be used for various user and control plane positioning methods / architectures that can support positioning services. Positioning server refers to any service that is based on or related to location information. The position information may include any information related to the position of the device, such as position estimation, measurement results, and so on. Positioning services may include positioning, which refers to the ability to determine the geographic location of a target device. Positioning services may also include positioning assisting actions, such as transferring assistive data to the UE to assist the UE in making position-related measurements and determining its position.

A user plane positioning method is a positioning method or system that sends a message for a positioning service through the user plane. The user plane is a mechanism for transporting signaling and data for higher layer applications and utilizing the bearer of the user plane, which is typically the User Datagram Protocol (UDP), a transmission control protocol. Implemented by standard protocols such as (TCP) and Internet Protocol (IP). The control plane positioning method is a positioning method that sends a message for a positioning service via the control plane. The control plane is a mechanism for carrying signaling for higher layer applications and is typically implemented by network-specific protocols, interfaces, and signaling messages. Messages that support location-fixing services are carried as part of signaling in control-plane position-solving methods and as part of traffic data (from a network perspective) in user-plane position-fixing methods. However, the content of the message may be the same or similar in both the user plane positioning method and the control plane positioning method. Examples of user plane positioning methods include Secure User Plane Location (SUPL) by the Open Mobile Alliance (OMA). Some examples of control plane positioning methods are described in (i) 3GPP TS23.271, TS43.059, TS25.305 and TS36.305, and 3GPP control plane positioning methods, as well as ( ii) There is a 3GPP2 control plane positioning method described in IS-881 and X.S0002.

The techniques described herein are defined by (i) 3GPP, LTE Positioning Protocol (LPP), Radio Resource LCS Protocol (RRLP), and Radio Resource Control (RRC), (ii) 3GPP2. It can also be used for various positioning protocols such as C.S0022 (also known as IS-801) and (iii) LPP Extensions (LPPe) as defined by OMA. Positioning protocols can be used to coordinate and control the positioning of devices. The positioning protocol can define (i) the procedures that can be performed by the positioning server and the device being positioned, and (ii) the communication or signaling between the device and the positioning server.

Figure 1 shows a wireless network 100 that supports communication and positioning services. The HNB 120 may be deployed by the user at any location (eg, home) to support wireless communication for the UE within the coverage of the HNB 120. HNB can also be called a home base station, a femto access point (FAP), a Home evolved Node B (HeNB), and the like. The HNB120 can support wireless access using WCDMA or some other wireless technology.

The Home Management System (HMS) 124 can configure the HNB 120 and other HNBs for operation, for example, as defined by the network operator to which the HNB 120 is registered. The HNB gateway (GW) 130 may be coupled to the HNB 120 and other HNBs and can support switching operations between the HNB and other network entities. The backbone network 150 may include various network entities that support various functions and services for the wireless network 100. For example, Core Network 150 is Mobile Switching Center (MSC), Serving GPRS Support It can include Node (SGSN) and / or other network entities. MSCs can perform switched functions for circuit-switched (CS) calls and can also route short message service (SMS) messages. The SGSN can perform signaling, switching and routing functions for UE packet-switched (PS) -type connections and sessions. The backbone network 150 may have access to other networks, such as other wireless networks and / or the Internet.

Home SUPL Location Platform (H-SLP) 140 can support positioning and positioning services. The H-SLP140 may include a SUPL Location Center (SLC) and, in some cases, a SUPL Positioning Center (SPC). The SLC can perform various functions for the position-fixing service, adjust the operation of the SUPL, and interact with the SUPL-enabled terminal (SET). The SPC can support the positioning of the SET and the delivery of assistive data to the SET and may respond to the messages and procedures used for location calculations. The location-based service (LCS) client 160 may be an entity that wants location information and can communicate with network entities in the backbone network 150 to obtain location information. The LCS client 160 may be outside the UE (as shown in FIG. 1) and communicate with the backbone network 150, may be present in the UE, or may be communicating with the UE.

For simplicity, FIG. 1 shows only some network entities that may exist in wireless network 100. The wireless network 100 may include other network entities. For example, a security gateway (SeGW) may be coupled between the HNB 120 and the HNB GW 130 and can provide security for access through the HNB 120 (eg, security for other parts of the network). The wireless network 100 may also include a radio network controller (RNC), a base station controller (BSC), a base station, a Mobility Management Entity (MME), etc., which are the features described in the published documents from 3GPP and 3GPP2. Can be executed.

UE110 may be one of many UEs supported by wireless network 100. The UE110 may be fixed or mobile and may also be referred to as a base station, terminal, access terminal, subscriber unit, station, SET or the like. The UE110 may be a mobile phone, personal digital assistant (PDA), wireless device, wireless modem, laptop computer, smartphone, netbook, smartbook, tablet, telemetry device, tracking device, and the like. UE110 may be able to communicate with HNB and macro base stations to obtain communication services. UE110 also supports one or more positioning methods such as A-GNSS, Observed Time Difference of Arrival (OTDOA), Uplink Time DIfference of Arrival (U-TDOA), Enhanced Cell Identity (E-CID), etc. can do. Any of these positioning methods can be used to determine the position of the UE 110.

The UE 110 and / or HNB 120 can receive and measure signals from one or more satellites 190 and obtain pseudo-distance measurement results for the satellites. Satellite 190 may be part of a GNSS, which may be the US Global Positioning System (GPS), the European Galileo system, the Russian GLONASS system, or some other GNSS. As used herein, the term "GNSS" generally refers to any satellite system or any combination of satellite systems that supports positioning, such as GPS, Galileo, GLONASS, and the like. UE110 and / or HNB120 measure signals from macro base stations and / or HNB (not shown in FIG. 1), timing measurement results, signal strength measurement results, signal quality measurement results, and / or, It is also possible to obtain identification information of the base station and / or HNB. The satellite, base station, and / or HNB measurements, and in some cases the base station and / or HNB identification information, can be used to derive a position estimate for the UE 110 or HNB 120. Position estimation can also be called location estimation, location determination, and the like.

The HNB120 can support a single GNSS and may be able to determine its position based on the capabilities of the single GNSS. UE110 can also support a single GNSS and may be able to determine its own position based on the capabilities of the single GNSS. Alternatively, if the UE 110 does not support a single GNSS, the position of the UE 110 may be estimated based on the position of the HNB 120. In either case, a single GNSS can provide accurate position estimation, but it can have some drawbacks. For example, a single GNSS may require the best satellite signal strength to be about -145 dBm or higher in order to demodulate navigation data. Furthermore, the initial position calculation time (TTFF) of a single GNSS can be on the order of several minutes or more when the signal strength is small.

Assisted GNSS (A-GNSS) can achieve better performance than single GNSS and / or can improve some of the shortcomings of single GNSS. With A-GNSS, devices can obtain support data for satellites from the network and use the support data to search for and capture satellites. Assistance data can allow the device to detect satellites more quickly, detect satellites with lower received signal levels, eliminate the need to demodulate satellite navigation data, and so on. For example, A-GNSS can operate even when the signal strength of the best satellite is about -155 dBm, which can be about 10 dB advantage over a single GNSS. In A-GNSS, TTFF can be on the order of tens of seconds instead of minutes in the case of a single GNSS. Increased sensitivity and reduced minimum signal strength in A-GNSS may be particularly desirable for HNBs, which are often deployed indoors. By shortening the TTFF, a better user experience can be provided.

In some embodiments, the positioning service for the UE communicating with the HNB may be supported by switching the HNB between the user plane positioning method and the control plane positioning method. HNB can support user plane positioning methods such as SUPL. The UE can support control plane positioning methods and RRC positioning protocols from 3GPP. The HNB can switch and allow the UE to obtain network assistance for positioning and positioning services via SUPL.

Figure 2 shows the design of the message flow 200 to support the positioning service for UE110 and A-GNSS by switching between the user plane positioning method and the control plane positioning method by HNB120. Can support WCDMA wireless connection. The UE 110 can establish a signaling connection with the HNB 120 (eg, after being contacted by the HNB 120 for the purpose of obtaining a position) and can provide the HNB 120 with positioning capability (step 1). For example, UE 110 is included in the UE Radio Access Capability Information Element (IE) in the RRC Connection Setup Complete message when a signaling connection to HNB 120 is established, as defined in 3GPP TS25.331. Positioning Capability In IE, it is possible to provide positioning capability to HNB120. UE positioning capabilities include (i) positioning methods supported by UE110 (eg, UE-backed A-GNSS, UE-based A-GNSS, UE-backed OTDOA, UE-based OTDOA, etc.), and , (Ii) If A-GNSS is supported, it may include certain GNSS systems and GNSS signals supported by UE110.

The LCS client 160 may wish to obtain the location of the UE 110 and may send a request to a network entity within the backbone network 150. The request may include the required Quality of Service (QoS) or Quality of Positioning (QoP). The backbone network 150 can then send a Radio Access Network Application Part (RANAP) Location Reporting Control message requesting information about the location of the UE 110 (step 2). RANAP is a protocol used for the Iu interface between the backbone network 150 and the HNB GW130. RANAP Location Reporting Control messages can include the required QoP or QoS and can be transported in Signaling Connection Control Part (SCCP) Data Form 1 (DT1) for transport from backbone network 150 to HNB GW130. HNB The GW130 can receive SCCP DT1 messages from the backbone network 150 and can transfer RANAP Location Reporting Control messages in the RANAP User Adaptation (RUA) Direct Transfer message to HNB120 (step 3). RUA is the protocol used for the Iuh interface between HNB120 and HNB GW130 and is defined in 3GPP TS 25.468. The HNB120 can receive the RUA Direct Transfer message, expand the RANAP Location Reporting Control message, and determine that information about the location of the UE110 is requested.

The HNB 120 may support SUPL and may be able to communicate with the H-SLP140 for positioning and positioning services. Communication between the HNB 120 and the H-SLP 140 may be via a direct signaling link, or through one or more networks and / or network entities such as the HNB GW130, backbone network 150, the Internet, etc. It may be through. The HNB120 also communicates with the UE110 via RRC and controls plane positioning methods such as 3GPP. Positioning and positioning services for the UE 110 may be supported according to the positioning method defined in TS25.305. In one design, the HNB 120 can switch between SUPL and 3GPP control plane positioning methods to support positioning and positioning services for the UE 110. In the switching operation, the HNB 120 can communicate with the H-SLP 140 as if the HNB 120 was a UE 110. Alternatively, the HNB 120 can communicate with the H-SLP 140 as a registered SET of the H-SLP 140, but can show the positioning capability of the UE 110 to the H-SLP 140 instead of the positioning capability of the HNB 120. The HNB120 can also transfer the related information received from the H-SLP140 to the UE110, and can transfer the related information received from the UE110 to the H-SLP140.

The HNB120 can establish a secure IP connection to the H-SLP140 (step 4). The HNB120 can establish this secure IP connection with its own security and identity information, for example, the HNB120 appears to the H-SLP140 to be a SUPL SET that participates in the SUPL service by the H-SLP140. obtain. The HNB120 can then send a SUPL START message to initiate a positioning session with the H-SLP140 (step 5). SUPL The START message may include session ID, cell ID, positioning capability, desired QoP, and so on. The session ID can be used to identify the positioning session. The cell ID can be the cell identifier (ID) of the HNB 120, the cell ID of a nearby macro cell, or both. Positioning capability may include some or all of the positioning methods supported by UE110 reported to HNB120 in step 1. Positioning capabilities may also indicate positioning protocols supported by (i) HNB120 instead of UE110, or (ii) UE110 instead of HNB120, or (iii) both HNB120 and UE110. For WCDMA connectivity and control plane positioning, the UE 110 typically supports only the RRC positioning protocol. The positioning protocol for case (i) may include RRLP or LPP, and the positioning protocol for case (ii) and case (iii) may include RRC. The desired QoP may be the same as that received by the HNB 120 in step 3. SUPL The sender of a START message typically includes the sender's positioning capabilities and the QoP desired by the sender. However, the HNB 120 can act as a proxy to assist in positioning the UE 110 and LCS client 160, thus providing the positioning capability of the UE 110 (rather than the positioning capability of the HNB 120) and the QoP desired by the LCS client 160. Can be included in SUPL START messages. HNB120 can also indicate support for one or more positioning protocols supported by HNB120, but not supported by UE110 (in case (i) above), or (in case (ii) and (iii) above). ) Can also indicate that the UE 110 may indicate support for one or more positioning protocols supported by the UE 110. The H-SLP140 can receive the SUPL START message, select one of the supported positioning methods, and return a SUPL RESPONSE message that may include the session ID, the selected positioning method, etc. (step 6).

The HNB120 provides session IDs, requests for assistive data for A-GNSS, positioning capabilities such as in step 5, HNB cell IDs and / or nearby macrocell IDs, and, in some cases, other information to H-SLP140. A SUPL POS INIT message that can be included can be sent (step 7). The H-SLP140 can then return a SUPL POS message that may include a session ID, a positioning message containing the requested assistance data, and possibly a measurement request (step 8). The positioning message may comply with one of the positioning protocols included in the positioning capability sent in step 5 and / or step 7. For example, if RRLP is included in the positioning capability, the positioning message may be an RRLP Measure Position Request message as shown in FIG. Alternatively, the positioning message is some other message for RRLP (eg Assistance). It can be a Data message) or a message for some other positioning protocol (not shown in Figure 2). When the H-SLP140 begins to use a particular positioning protocol in step 8, the same positioning protocol typically sends other positioning messages transferred between the HNB 120 and the H-SLP140 for this SUPL positioning session. Used to encode (eg in step 12).

The HNB 120 can obtain support data from the positioning message included in the SUPL POS message, and can send the support data to the UE 110 in the RRC Measurement Control message (step 9). If the positioning message does not comply with the RRC positioning protocol (for example, it was an RRLP Measure Position Request message as shown in Figure 2), the HNB 120 decodes the positioning message, deploys support data, and RRC. Support data can be sent with Measurement Control messages. Conversely, if the positioning message was already an RRC Measurement Control message, the HNB 120 may send this message with little or no conversion or modification.

UE110 can obtain GNSS measurement results (that is, satellite measurement results) based on the support data (step 10). UE110 may or may not be able to determine position estimation based on GNSS measurement results. The UE 110 can send an RRC Measurement Report message to the HNB 120, which may include the GNSS measurement results or position estimates obtained by the UE 110 (step 11). The HNB120 can then transfer the GNSS measurement result or position estimation in the RRLP Measure Position Response message, and the RRLP Measure Position Response message can be carried in the SUPL POS message sent to the H-SPL140 (step). 12). In step 12, the HNB 120 decodes the RRC Measurement Report message received from the UE 110, expands the GNSS measurement result or position estimate, and applies the GNSS measurement result or position estimate to the RRLP Measure Position. It can be sent in a Response message. However, if the HNB110 showed support for RRC in step 8 and had already received the RRC Measurement Control message from the H-SLP140, the HNB120 would send the RRC Measurement Report message received from the UE in step 11. It can be transferred to the H-SLP140 in step 12 with little or no conversion or modification. When the GNSS measurement result is transmitted to the H-SLP140, the H-SLP140 can calculate the position estimation of the UE 110 based on the GNSS measurement result. The H-SLP140 can then send a SUPL END message, which may include a position estimate calculated by the H-SLP140 (step 13). Once the position estimate has been sent to the H-SLP140, the H-SLP140 can simply return a SUPL END message.

The HNB 120 can receive the position estimation of the UE 110 from either the UE 110 in step 11 or the H-SLP 140 in step 13. The HNB 120 can send a UE110 location estimate in the RANAP Location Report message, and the RANAP Location Report message can be carried in the RUA Direct Transfer message sent to the HNB GW130 (step 14). The HNB GW130 can forward the RANAP Location Report message in the SCCP DT1 message to the backbone network 150 (step 15). The backbone network 150 can then transfer the location estimation to the LCS client 160.

For simplicity, Figure 2 shows the transfer of A-GNSS assisted data from H-SLP140 to UE110 in steps 8 and 9. The UE110 may determine in step 10 that the UE110 needs new support data. In this case, the UE 110 can send a request for new support data to the HNB 120, which can forward the request in a SUPL POS message to the H-SLP140. The HNB 120 can then receive a SUPL POS message containing the new support data from the H-SLP140, for example, transferring the new support data to the UE 110 in a manner similar to steps 8 and 9 in Figure 2. Can be done.

As shown in FIG. 2, the network operator can support both the control plane positioning method and the user plane positioning method. The HNB120 can switch between SUPL and 3GPP control plane positioning methods to support UE110 positioning. Further, the HNB 120 can switch between the RRLP positioning protocol used by SUPL and the RRC positioning protocol used by UE110. If the H-SLP140 uses RRC instead of RRLP (this can happen if HNB120 includes RRC support as part of its positioning capabilities in steps 5 and 7), switching between RRLP and RRC is required. Instead, the HNB 120 can transport RRC positioning messages between the UE 110 and the H-SLP 140 with little or no translation or modification. In either case, the switching operation by the HNB 120 may allow the position of the UE to be explicitly obtained (eg, by A-GNSS) without the need to use the position of the HNB as the position of the UE.

When the HNB120 receives a control plane positioning request from a network entity (eg MSC or SGSN) for UE positioning, the HNB120 will take the H-SLP140 (or possibly another network) of the HNB120's own network. SUPL positioning session by SLP) can be triggered. The HNB120 can indicate to the H-SLP140 that the HNB120 supports the same positioning methods that the UE110 supports (eg A-GNSS) and can request support data for the A-GNSS. The HNB120 can transfer the support data received from the H-SLP140 to the UE110. If the UE110 requests more support data (eg using RRC), the HNB 120 can use the RRLP to send the request to the H-SLP140 and the new support data received from the H-SLP140. Can be transferred to UE110. Similarly, the HNB120 SUPLs more position-related measurement results or another request for another position estimate from the UE110. Upon receiving from the H-SLP140 in the positioning message carried in the POS message, the HNB120 will either (if the positioning protocol used by the H-SLP140 is not RRC, translate the request into an RRC message, or the RRC This request can be forwarded to UE110 (by forwarding the request, if used). The HNB 120 can return the measurement results or position estimates related to the obtained position to the H-SLP140, as in steps 8-12.

When the HNB 120 receives a position-related measurement or position estimate from the UE 110, the HNB 120 retains any position estimates and obtains any position-related measurement results, such as RRLP (as shown in Figure 2), or something else. It can be transferred to the H-SLP140 using the positioning protocol (not shown in Figure 2) and SUPL. The H-SLP140 can calculate the position estimate of the UE110 based on the position-related measurements (if given) and can return the position estimate to the HNB120 in the SUPL END message. The HNB 120 can send the position estimates received from the UE 110 or H-SLP 140 to the requesting network entity (eg MSC or SGSN).

Figure 2 shows the positioning of UE110 using A-GNSS. The exemplary procedure shown in FIG. 2 is also by (i) requesting and returning support data for other positioning methods in steps 7-9, and (ii) other positioning methods in steps 8-12. To position the UE 110 in addition to or instead of A-GNSS by requesting and returning measurement results or position estimates for the UE 110 using such other positioning methods (eg, OTDOA or E-CID). , Can be used. In addition, FIG. 2 may show the use of SUPL 1.0 or SUPL 2.0 between HNB120 and H-SLP140. Other versions of SUPL (eg, SUPL 3.0) can be used by using other SUPL messages and parameters in one or more of steps 5, 6, 7, 8, 12 and 13. HNB120 and HNB Positioning the UE in the macrocell by replacing the GW130, as well as the link between them, with a single RNC and removing steps 3 and 14 to switch between SUPL and control plane positioning in the RNC instead of the HNB120. You can get the procedure for. The principle of switching between user plane positioning and control plane positioning acts as an anchor point for control plane positioning, eg, in other entities that can be used as MSC, SGSN, or MME. Can also be used.

Figure 2 shows a design that supports A-GNSS for UE110. A-GNSS can be supported for HNB120 in various ways. In one design, the HNB120 can query the H-SLP140 to get its position using SUPL. The HNB120 can trigger a SUPL positioning session with the H-SLP140 and can act as a SET when interacting with the H-SLP140 using the SUPL. In another design, the HMS124 can provide the HNB120 with supporting data for A-GNSS, for example, using proprietary signaling methods, which allows the HNB120 to make its own from the GNSS measurements made by the HNB120. You will be able to get the position. In yet another design, a proprietary server (eg, a server provided by the manufacturer of HNB120 or an OEM of that manufacturer) may first or later provide support data to HNB120. The HNB120 can also acquire support data by other methods. The HNB120 can perform positioning using assistive data acquired via any suitable mechanism.

In another aspect, a Standalone Serving Mobile Location Center (SAS) or some other location-fixing server can be used to support position-fixing services and A-GNSS for HNB and UE. SAS may typically be used in 3GPP networks and may be coupled to RNCs via the Iupc interface and can support positioning for UEs communicating with 3GPP networks. However, to support HNB and UE positioning, SAS may be coupled to HNB GW, which can be considered as RNC by SAS.

Figure 3 shows a wireless network 300 that supports communication and positioning services. Within the coverage of these HNBs, the HNBs 320 and 322 may be deployed in various locations (eg, upstairs of a building) by one or more users to support UE wireless communication. The HMS324 can configure the HNB320 and 322 for operation. The HNB GW330 may be coupled to the HNB 320 and 322 and can support switching operations between the HNB and other network entities. The SAS340 can support positioning services and positioning for UEs communicating with network 300. Core network 350 includes MSC / SGSN352 and Gateway Mobile Location May include Center (GMLC) 354. The GMLC354 can perform various functions to support the positioning service, interface with the LCS client 360, and provide services such as subscriber privacy, authorization, authentication, billing, etc. For simplicity, FIG. 3 shows only some network entities that may be present in the wireless network 300. The wireless network 300 may include other network entities. The UE 310 may be one of the many UEs supported by the wireless network 300.

Figure 4 shows an exemplary protocol stack in HNB320, HNB GW330, and SAS340. HNB320 and SAS340 can communicate between terminals via the Positioning Calculation Application Part (PCAP), and PCAP can be at the top of the protocol stack for HNB320 and SAS340. PCAP is a protocol used to support positioning with a 3GPP control plane for WCDMA connections and can be used between RNCs and SAS. PCAP is defined in the published 3GPP TS 25.453. The protocol stack for the HNB 320 and HNB GW 330 via the Iuh interface can include the RUA or PCAP User Adaptation (PUA) protocol, Stream Control Transmission Protocol (SCTP), IP, data link layer, and physical layer. HNB via Iupc interface The protocol stack for GW330 and SAS340 can include SCCP, MTP3-User Adaptation (M3UA), SCTP, IP, data link layer, and physical layer.

As shown in Figure 4, PCAP may be added to the control plane, and PCAP messages can be transported via HNB GW330 using PUA / RUA on the Iuh interface and SCCP on the Iupc interface. The HNB GW330 may terminate the Iupc protocol under the PCAP for the SAS 340 and may terminate the Iuh protocol under the PCAP for the HNB 320. Although not shown in Figure 4, the HNB GW330 may also terminate the Iu protocol underneath the RANAP from the MSC / SGSN352.

When the HNB320 first accesses the network 300, location-related information can be validated and configured on the HNB320. The HNB320 can report the positioning capability to the HMS324. The HMS324 can configure which positioning capabilities can be used, such as A-GNSS, E-CID, broadcast, RNC-centric mode vs. SAS-centric mode. The HMS324 can also provide the HNB320 with the identification information and capabilities of the SAS340 and / or other SAS that may be accessible from the HNB GW330. The HNB320 can utilize SAS340 to more accurately determine its position and report or update this position on the HMS324. Alternatively, the HNB 320 may be registered with the HNB GW 330, which can perform the functions described above.

In one design, the SAS340 can store a database of HNB information for HNBs that can be served by the SAS340. The HNB information stored by SAS340 for the HNB320 is a cell global ID that can uniquely identify the HNB320, the position coordinates of the HNB320, the cell IDs of nearby cells near the HNB320 and, in some cases, the signal strength, the positioning capability of the HNB320, etc. Can include (CGI). The HNB320 may transmit HNB information to the SAS340 when the HNB320 is first initialized, when the HNB320 registers with the HNB GW330, when the HNB320 changes position, and so on, or periodically. In one design, the HNB 320 can send HNB information in a new connectionless PCAP message to the SAS 340. In another design, the HNB320 has an existing PCAP message to the SAS340 (for example, the PCAP Position Initiation). In the Request message), you can send HNB information to get position-fixing support from SAS. The HNB320 can identify that the information sent to the SAS340 (eg, in the PCAP Position Initiation Request message) is associated with the HNB320 by including an identification parameter in the message. The identification parameter is International Mobile Subscriber Identity (IMSI) or International Mobile Equipment. It may include an Identity (IMEI) and may store a string of numbers that belongs to a set of strings as provided by the network 300 administrator to identify the HNB. If this set of columns of numbers (for example, defined by a range of values) is preconfigured with the SAS340, the SAS340 will be able to recognize the discriminant parameters and will use the information in the PCAP message. , Can be inferred to be related to HNB. This allows existing PCAP messages and parameters to be used to carry HNB information from the HNB 320 to the SAS 340, eliminating the need to standardize and implement new PCAP messages and parameters. .. The HNB 320 can also transmit HNB information to the SAS 340 in other ways. The SAS340 may store HNB information as semi-persistent or semi-static information.

Figure 5 shows the design of Message Flow 500 to support positioning services and A-GNSS for UE310 using SAS340. The UE310 can be associated with the HNB320 (for example, in some cases after being contacted by the network 300 for the purpose of obtaining a location, it can establish a signaling connection with the HNB320) and provide the HNB320 with positioning capability. Can be done (step 1). The LCS client 360 may wish to obtain the location of the UE 310 and may send a request to the GMLC354 in the backbone network 350. The backbone network 350 can send a RANAP Location Reporting Control message in the SCCP DT1 message requesting information about the location of the UE 310 (step 2). The HNB GW330 can receive SCCP DT1 messages from the backbone network 350 and in the RUA Direct Transfer message to the HNB 320, RANAP Location Reporting. Control messages can be forwarded (step 3).

The HNB320 can receive the RUA Direct Transfer message, expand the RANAP Location Reporting Control message, and determine that information about the location of the UE310 is requested. The HNB 320 can then send a PCAP Position Initiation Request message in the PUA Connect message to the HNB GW330 to initiate a SAS340 positioning session (step 4). PUA Connect messages may also contain SAS (eg SAS340) identification information. The PCAP Position Initiation Request message can include cell IDs (eg, cell IDs of HNB320 or nearby macrocells visible to HNB320), UE positioning capabilities (eg A-GNSS), and so on. HNB GW330 can receive PUA Connect messages from HNB320 and in the SCCP Connection Request (CR) message to SAS340, PCAP Position You can forward the Initiation Request message (step 5). The HNB GW330 can determine the SAS 340 from any SAS identity contained in the PUA Connect message, or otherwise (for example, by default only one SAS is connected to the HNB GW330).

The SAS340 can receive the PCAP Position Initiation Request message and can initiate the A-GNSS positioning procedure by sending the PCAP Position Activation Request message within the SCCP Connection Confirm (CC) message (step). 6). The PCAP Position Activation Request message may include a request for A-GNSS positioning, support data for A-GNSS, and so on. The HNB GW330 can receive SCCP CC messages from SAS340 and can transfer the PCAP Position Activation Request message in the PUA Direct Transfer message to HNB120 (step 7).

The HNB320 can obtain information from the PCAP Position Activation Request message and can send the A-GNSS positioning request and assistance data in the RRC Measurement Control message to the UE310 (step 8). UE310 can obtain GNSS measurement results based on the support data (step 9). UE310 may or may not be able to obtain position estimation based on the GNSS measurement results. The UE 310 can send an RRC Measurement Report message to the HNB 320, which may include the GNSS measurement results or position estimates obtained by the UE 310 (step 10). The HNB320 can then transfer the GNSS measurement result or position estimation in the PCAP Position Activation Response message, and the PCAP Position Activation Response message can be carried in the PUA Direct Transfer message sent to the HNB GW330 (step). 11). HNB The GW330 can receive the PUA Direct Transfer message from the HNB320 and can transfer the PCAP Position Activation Response message in the SCCP DT1 message to the SAS340 (step 12).

The SAS340 can receive GNSS measurement results or position estimates from PCAP Position Activation Response messages. The SAS340 can calculate the position estimates for the UE 310 and / or verify the position estimates for the UE 310 based on the GNSS measurement results. The SAS340 can then send a position estimate calculated and / or verified by the SAS340 in the PCAP Position Initiation Response message, and the PCAP Position Initiation Response message is in the SCCP DT1 message sent to the HNB330. Can be transported (step 14). The HNB GW330 can receive SCCP DT1 messages from SAS340 and can forward PCAP Position Initiation Response messages in PUA Direct Transfer messages to HNB320 (step 15).

The HNB320 can receive a position estimate of the UE310 from the UE310 in step 10 or from the SAS340 in step 15. The HNB320 can terminate the SAS340 positioning session by sending a PUA Disconnect message to the HNB GW330 (step 16), and the HNB GW330 can send an SCCP Released (RLSD) message to the SAS340. (Step 17). The SAS340 can return an SCCP Release Complete (RLC) message (step 18).

The HNB320 can send a UE310 location estimate in the RANAP Location Report message, and the RANAP Location Report message can be carried in the RUA Direct Transfer message sent to the HNB GW330 (step 19). The HNB GW330 can forward the RANAP Location Report message in the SCCP DT1 message to the backbone network 350 (step 20).

In FIG. 5, the SAS 340 can send support data for A-GNSS to the UE 310 in steps 6-8. UE310 can determine that UE310 needs new support data in step 9. In this case, the UE 310 can send a request for support data to the SAS 340 via the HNB 320. Then, steps 6 to 12 are executed, and new support data can be provided to UE310. Similarly, the SAS340 can determine in step 13 that the SAS340 needs more position-related measurements or other position estimates. The SAS340 then performs steps 6-12 again to (i) send more assistive data and another request for position measurement or position estimation to the UE310 via the HNB320, and (ii) position. Measurement results or position estimates related to can be received from the UE 310 via the HNB 320. In step 5 (for example, in step 4 PCAP Position Initiation) If the SAS340 can recognize the request as coming from the HNB320 (by including the IMSI or IMEI for the HNB320 in the Request) and the SAS340 already has the exact location of the HNB320, the SAS340 will step. You can skip 6 to 13 and return the position of the HNB 320 to the HNB 320 in steps 14 and 15. Given that the coverage area of any HNB is small, the location of the HNB can be a good approximation to the location of the UE 310, given that the UE 310 is usually close to the HNB 320. Alternatively, if the SAS 340 cannot obtain the position of the UE 310 with sufficient accuracy from any measurement results or position estimates provided to the SAS 340 in steps 11 and 12, the SAS 340 will perform steps 6 to 13 and then step 14 In and 15, the position of the HNB 320 may be returned to the HNB 320 as an approximation of the position of the UE 310. This can be useful if the UE 310 does not give accurate position measurements (eg, if the UE 310 is inside a building).

As described above, the designs in Figures 4 and 5 can support positioning services and A-GNSS for UE310. These designs can also support other UE-supported and UE-based positioning methods, such as OTDOA and E-CID. These designs can also locate the HNB 320, supporting positioning methods supported by A-GNSS, E-CID, and other networks. These designs can be used in SAS centric mode (shown in Figure 5) or RNC centric mode. In RNC centric mode, the HNB320 controls the positioning procedure rather than the SAS340, and the RRC messages in Figure 5 (steps 8 and 10) may remain the same, but different PCAP messages are in the PCAP message in Figure 5. Alternatively, it can be exchanged between HNB320 and SAS340 (steps 4, 5, 6, 7, 12 and 14).

In the design shown in Figures 4 and 5, the HNB320 can switch between PCAP and RRC messages. The HNB320 can receive PCAP messages from SAS340 and can forward relevant information in RRC positioning messages to UE110. The HNB320 can also receive RRC positioning messages from UE110 and forward relevant information in PCAP messages to SAS340.

In the design shown in Figures 4 and 5, the HNB GW330 can support the transfer of PCAP messages between the HNB 320 and SAS 340, using PUAs, for example as shown in Figures 4 and 5. The HNB GW330 can receive PCAP messages sent by SAS340 in SCCP messages and forward these PCAP messages in PUA messages to HNB320 (as shown in Figure 5) and / or RUA messages. can do. The HNB GW330 can also receive PCAP messages sent by the HNB 320 in PUA messages (as shown in Figure 5) and can forward these PCAP messages in the SCCP message to SAS340. it can.

In one design, the RUA can be extended to transport PCAP messages. In another design, the PUA can be defined to transport PCAP messages between the HNB 320 and the HNB GW 330 (eg, as shown in Figure 5). This design can be implemented simply as it avoids affecting RANAP support. PUA may have certain properties that may differ from RUA. For example, a PUA may have one or more of the following properties: · Carry PCAP messages instead of RANAP messages · Does not include references to specific UEs · Supports transaction IDs for connectionless PCAP messages · Supports multiple SAS

In one design, the HNB GW does not need to be aware of the UE association, so the PUA message does not have to be explicitly associated with a particular UE. In addition, HNB can use PUA messages to transport PCAP messages to SAS for the location of HNB. In that case, the PUA message associated with the UE is not possible because there is no UE to position.

In one design, connectionless and possibly connection-oriented PCAP messages sent by the HNB320 may store a unique PCAP transaction ID. If PCAP response and PCAP request messages are transported between HNB GW330 and SAS340 using connectionless SCCP and possibly connection-oriented SCCP, the PCAP transaction ID will make the PCAP response message the PCAP request message. Can be used at the PCAP level to associate. If the HNB 320 sends a PUA request to the HNB GW330 for a specific SAS unique transaction ID, the PCAP transaction ID can be managed and assigned by the HNB GW330 and given to the HNB 320 using the PUA. The SAS340 can see the HNB GW330 as an RNC and cannot recognize various HNBs, such as the HNB320 behind the HNB GW330. Therefore, SAS340 is HNB GW33 support a single set of transaction IDs for 0. Different HNBs, such as HNB320 and HNB322, should not use the same PCAP transaction ID as they can cause errors. For example, a connectionless PCAP response message from SAS340 destined for HNB320 may be incorrectly routed by HNB GW330 to HNB322. The HNB 320 can obtain a unique PCAP transaction ID from the HNB GW330, and after a certain period of time, it can send a PUA message to the HNB GW330 to release the transaction ID, which will cause the HNB GW330 to separate later. It is possible to assign that PCAP transaction ID to an HNB (eg HNB322). By sending a unique PCAP transaction ID to the HNB 320 for connectionless PCAP messages, the HNB GW 330 will HNB from the HNB 320 to the SAS 340 to verify that the PCAP transaction ID is unique. Eliminates the need to inspect connectionless PCAP messages transported through the GW330. This eliminates the need for the HNB GW330 to support some of the PCAP protocols. However, the HNB GW330 inspects any connectionless PCAP response message sent by SAS340 to the HNB320 and routes the PCAP message to the HNB320 instead of any other HNB like the HNB322. You may get it.

For connection-oriented PCAP messages, an SCCP connection can be established between the HNB GW330 and SAS340 to transport these messages. The SCCP connection helps (i) associate the PCAP response message sent from SAS340 to HNB320 with the previous PCAP request message sent from HNB320 to SAS340, and (ii) routes the PCAP response message to the correct HNB. Can be used for Therefore, the HNB GW330 does not need to inspect such connection-oriented PCAP messages sent by SAS340 in order to route them to the correct HNB. However, unless SAS340 allows the transaction ID of connection-oriented PCAP messages to be unique for each SCCP connection, the mechanism for HNB 320 to request a unique PCAP transaction ID from HNB GW330 remains. Can be used. In this latter case, the HNB 320 can assign the PCAP transaction ID itself without the assistance of the HNB GW330.

In one alternative design, the HNB GW330 can convert between the PCAP transaction ID assigned by the HNB 320 and the PCAP transaction ID found by the SAS 340. In this design, the HNB 320 manages a unique PCAP transaction ID and can insert the appropriate transaction ID X into any PCAP request message sent to the SAS 340 via the HNB GW330. The HNB GW330 can then replace transaction ID X with another transaction ID Y that is unique to the interface between HNB GW330 and SAS340, and then forward the PCAP request message to SAS340. Later, the SAS340 can send back a PCAP response message for this PCAP request carrying the same transaction ID Y. The HNB GW then inspects the PCAP response and sets transaction ID Y to transaction ID. It can be replaced by an X and the PCAP response message can be routed back to the HNB320. With this alternative design, the HNB GW330 can support more of the PCAP protocol, but the scope of PUA support by the HNB 320 and HNB GW 330 can be narrowed (for example, the HNB 320 may not be able to request a PCAP transaction ID from the HNB GW 330). ..

For PCAP transactions to HNB320 initiated by SAS340, the PCAP transaction ID can be transferred between SAS340 and HNB320 without being translated or modified by HNB GW330. This is because the SAS340 can ensure that the transaction ID is unique for each type of PCAP procedure.

In one design, the PUA may have one or more of the following functions: · Control or report the setup of SCCP connections and release SCCP connections through the Iupc interface for connection-oriented PCAP message transport. -Transfer connection-oriented PCAP messages · Use a local identifier in the PUA message to identify the SCCP connection associated with a particular HNB on the Iupc interface. · Transport connectionless PCAP messages and manage PCAP transaction ID assignments · Identify the SAS when multiple SASs connect to the HNB GW (for example, allow the HNB to select a particular SAS for a new PCAP procedure)

In one design, a set of PUA messages may be supported and may include one or more of the following PUA messages: PUA Connect Messages-Used to set up SCCP connections between HNB GW and SAS, or to report setup, for transporting connection-oriented PCAP messages from or to HNB. · Direct Transfer Message-Used to transfer connection-oriented PCAP messages between HNB GW and HNB. Disconnect message-used to release the SCCP connection between the HNB GW and SAS, or to report the release of the SCCP connection. · Request Transaction ID Message-Sent by HNB to HNB GW to obtain a unique PCAP Transaction ID for connectionless PCAP messages. · Return Transaction ID Message-HNB by HNB to return the PCAP transaction ID to a common storage location for PCAP transaction IDs managed by HNB GW. Sent to GW · Connectionless Transfer Message-Used to transfer connectionless PCAP messages between HNB and HNB GW HNB Transfer Message-Used to support continued UE positioning after a GW handover within the HNB, which begins after the UE positioning procedure is initiated by the source HNB for handover.

Each PUA message may contain any number of parameters in any suitable format. In one design, PUA Connect messages can include PCAP messages, local PUA references to SCCP connections between HNB GW and SAS, SAS IDs when there are multiple SASs, and so on. The HNB GW can manage the association between the local PUA connection reference used between the HNB GW and the HNB and the SCCP connection between the HNB GW and the SAS. PUA Direct Transfer messages can include connection-oriented PCAP messages and references to local PUA connections. If there are multiple SASs, the PUA Connectionless Transfer message may include a connectionless PCAP message and a SAS ID.

In another design, the various capabilities, messages and parameters disclosed above may be included in the RUA to support UE310 or HNB320 positioning using PCAP between HNB320 and SAS340. In this design, PCAP messages are transported between HNB320 and HNB GW330 using RUA instead of PUA.

UE310 can perform the positioning procedure by HNB320, for example, as shown in FIG. The UE 310 may be mobile and may be handed over from the source HNB 320 to the target HNB 322 during the positioning procedure. Both HNB 320 and 322 may be coupled to the same HNB GW 330 and a handover within the HNB GW may be performed for the UE 310. In one design, the source HNB320 (i) sends a PCAP Abort message to the SAS340 for any ongoing SAS-centric position-fixing session, and (ii) sends a RANAP Location Report message with the cause of the error MSC /. By sending to SGSN352, the positioning procedure for UE310 can be completed. Then, after the UE 310 is handed over to the target HNB322, a new position-fixing procedure can be started.

In another design, the ongoing positioning procedure for UE310 via source HNB320 may be continued via HNB322. In one design, the HNB GW330 can indicate to the source HNB320 whether the handover of the UE310 is done inside the HNB GW. The source HNB320 can then decide whether to abort the positioning procedure or continue the positioning procedure via the target HNB322. In one design, once the continuation of the positioning procedure is determined, the source HNB 320 can transfer the position state information for the UE 310 to the target HNB 322 via the HNB GW 330. Any SAS-centric positioning session can continue through the target HNB322, which can update the SAS340 with the new cell ID of the HNB322. If the UE310 handover fails for any reason, the source HNB320 can continue the positioning procedure for the UE310.

FIG. 6 shows the design of the message flow 600 to continue the UE310 positioning procedure in a handover within the HNB GW. The UE 310 may first communicate with the HNB 320, which may have an ongoing position-fixing procedure with the SAS 340 for the UE 310 (step 1). The HNB 320 can decide to perform the relocation for the handover of the UE 310 to the HNB 322 (step 2). The HNB 320 can then send the RANAP Relocation Required message in the RUA Direct Transfer message to the HNB GW330 (step 3). HNB GW330 can trigger the registration of UE310 at target HNB322 (step 4). The HNB GW330 can return a RANAP Relocation Command message, which is included in the RUA Direct Transfer message to the HNB 320. It can include an indication of handover within the GW (step 5).

The HNB320 can be determined by continuing the positioning procedure for the UE310 (step 6). The HNB 320 can then send a PUA HNB Transfer message containing position status information for the position determination procedure to the HNB GW 330 (step 7). The HNB GW330 can forward the PUA HNB Transfer message to the HNB 322 (step 8).

At any time after the decision to perform the relocation in step 5, the HNB 320 may send a Physical Channel Reconfiguration message to the UE 310 (step 9). This message can indicate the UE 310 handover to the HNB 322. The UE 310 can then perform uplink synchronization to the HNB 322 (step 10).

After receiving the uplink synchronization in step 10, the HNB 322 can send a RANAP Relocation Complete message in the RUA Direct Transfer message to the HNB GW330 (step 11). The HNB GW330 can then send a RANAP Iu Release Command message in the RUA Direct Transfer message to the HNB 320 (step 12). The HNB320 can return the RANAP Iu Release Complete message in the RUA Disconnect message to the HNB GW330 (step 13).

To continue the positioning procedure for UE310, HNB322 can send a PCAP Position Parameter Modification message, which is a new HNB322 message in the PUA Direct Transfer message to HNB GW330. Cell ID can be included (step 14). The HNB GW330 can forward the PCAP Position Parameter Modification message in the SCCP DT1 message to the SAS 340 using the same SCCP connection previously assigned to the HNB 320 for the positioning of the first UE. .. The positioning procedure can then be continued between the HNB 322 and the SAS 340 via the HNB GW330 (step 16). HNB The GW330 can continue to use any state information previously associated with the HNB320 (eg SCCP connection information) for the Iupc interface with the SAS340 for support of the positioning procedure, which was transferred to the HNB322. ..

In general, the position-state information transferred by the source HNB 320 to the target HNB 322 may include any information that may be useful or necessary to continue the positioning procedure for the UE 310. In one design, the position-state information applies to the required QoS, required priority, speed requirements, the overall length of the position-fixing procedure in the HNB 320, and any details that apply to any periodic requirements (eg,). It may include information previously provided to the HNB 320 in the original location request from the backbone network 350, such as, the number of periodic location reports completed so far). In one design, when SAS Centric mode is used, the position state information is the PCAP transaction ID used by the HNB 320 and the local connection used between the HNB 320 and the HNB GW 330 for the PCAP Position Initiation Request message. References may be included.

In one design, the position state information may include one or more of the following for each ongoing SAS centric positioning method performed by the SAS 340 in the HNB 320 for the UE 310: -Type of positioning method (for example, A-GNSS or OTDOA supported by UE) · PCAP transaction ID used by SAS340 in PCAP Position Activation Request messages · Required response time and current elapsed time for positioning method -Information obtained so far about positioning methods (eg ODTOA) (eg measurement results from UE310)

If the source HNB320 is the reference cell for the OTDOA measurement, the positioning session for the OTDOA may be aborted because the UE 310 may not be able to obtain the OTDOA measurement for the HNB320 after the handover. Therefore, it could be simpler to always stop OTDOA on the target side HNB322 and not transfer detailed information from the source HNB320. The positioning procedure can be terminated in the SAS340 when a new cell ID is received from the target HNB322, so that the information for the U-TDOA is the position state information (eg, the information for the CELL_FACH state, if applicable). ) Does not have to be included.

In one design, the assumption is that the source HNB320 sent an RRC Measurement Control message to the UE310 for any ongoing UE-assisted or UE-based positioning method such as A-GNSS or OTDOA. Can be In this case, the target HNB322 does not need to send the RRC Measurement Control message to UE310. If the source HNB320 has not sent an RRC Measurement Control message, the source HNB320 or target HNB322 may send a PCAP Position Activation Failure message to the SAS340.

FIG. 5 shows a design that supports positioning services and A-GNSS and / or other positioning methods for UE310. A-GNSS and / or other positioning methods for the HNB320 may be supported in a similar manner so that the location of the HNB320 can be determined. The HNB320 can continue to use PCAP and PUA as described above. However, instead of interacting with UE310 to provide assistive data for A-GNSS and obtain GNSS measurement results or position estimates, HNB320 may assume the role of UE and in some cases receive from SAS340. With the help of assisted data provided, GNSS and / or other (eg, OTDOA) measurements may be made and / or position estimates may be obtained. In this case, the HNB 320 does not need to switch between PCAP and RRC, but PCAP can be used as the positioning protocol instead. From the perspective of the HNB GW330 and SAS340, the positioning of the HNB320 can look the same or almost the same as the positioning of the UE310, so it requires little or no additional support.

Figure 7 shows the design of Message Flow 700 to support positioning services and A-GNSS for HNB320 using SAS340. The HNB320 or HMS324 can determine that the location of the HNB320 is required (step 1). The HNB320 can send a PCAP Position Initiation Request message in the PUA Connect message to the HNB GW330 to initiate a SAS340 positioning session (step 2). PUA Connect messages may also contain SAS (eg SAS340) identification information. The PCAP Position Initiation Request message may include cell IDs (eg, cell IDs of nearby macro cells visible in HNB320), HNB320 positioning capabilities (eg A-GNSS), and so on. The HNB GW330 can forward the PCAP Position Initiation Request message in the SCCP CR message to the SAS340 (step 3). HNB The GW330 can determine the SAS340 from any SAS identity contained in the PUA Connect message, or otherwise (for example, by default only one SAS is connected to the HNB GW330). The SAS340 can receive the PCAP Position Initiation Request message and by sending a PCAP Position Activation Request message that may contain support data for A-GNSS in the SCCP CC message sent to the HNB GW330. You can start the A-GNSS positioning procedure (step 4). The HNB GW330 can transfer the PCAP Position Activation Request message in the PUA Direct Transfer message to the HNB 320 (step 5).

The HNB320 can receive a PCAP Position Activation Request message, for example, a GNSS measurement result can be obtained based on the support data received from the SAS340 (step 6). The HNB320 may or may not be able to obtain position estimation based on the GNSS measurement results and the support data received in step 5. The HNB320 may send a PCAP Position Activation Response message, which may include GNSS measurement results and / or position estimates in the PUA Direct Transfer message sent to the HNB GW330 (step 7). ). The HNB GW330 can forward the PCAP Position Activation Request message in the SCCP DT1 message to SAS340 (step 8).

The SAS340 can receive GNSS measurement results and / or position estimates from PCAP Position Activation Response messages. The SAS340 can calculate the HNB320 position estimation (if given) and / or verify the HNB320 position estimation based on the GNSS measurement results (step 9). The SAS340 can then send a position estimate calculated and / or validated by the SAS340 in the PCAP Position Initiation Response message, and the PCAP Position Initiation Response message is carried in the SCCP DT1 message to the HNB 330. Can be done (step 10). The HNB GW330 can transfer the PCAP Position Initiation Response message in the PUA Direct Transfer message to the HNB 320 (step 11).

The HNB 320 can terminate the SAS340 positioning session by sending a PUA Disconnect message to the HNB GW330 (step 12), and the HNB GW330 can send an SCCP Released message to the SAS340 (step 13). ). The SAS340 can return an SCCP Release Complete (RLC) message (step 14). The HNB320 can store its own position estimates and / or provide position estimates to the HMS324.

In Figure 7, the SAS340 can send support data for A-GNSS to the HNB320 in steps 4 and 5. The HNB320 can determine in step 6 that the HNB320 needs new support data. In this case, the HNB 320 can send a request for support data to the SAS 340. Then, steps 4 to 8 can be executed to provide new support data to the HNB 320. Similarly, in FIG. 7, the SAS340 can determine in step 9 that the SAS340 needs further measurement results or another position estimate, and steps 4-8 to obtain a measurement result or position estimate from the HNB 320. Can be repeated.

Although Figure 7 shows the use of A-GNSS, SAS340 may call one or more additional or alternative positioning methods in steps 4-8. For example, the SAS340 may call OTDOA and include support data for OTDOA in the PCAP Position Activation messages sent in steps 4 and 5. Then, the HNB320 can obtain the OTDOA measurement result or the position estimation based on the OTDOA measurement result in step 6, and in steps 7 and 8, the OTDOA measurement result or position estimation is sent to SAS340 in the PCAP Position Activation Response message. Can be returned. The HNB320 is also sent to the SAS340 in steps 2 and 3 for the PCAP Position Initiation. The Request message may also include the identification information of the HNB 320 itself (eg IMSI or IMEI). This identity belongs to any of several HNBs, or in particular to the HNB 320, depending on the preconfiguration of the HNB 320 identifier (eg, the broader set of HNB identifiers) by the network 300 administrator in SAS340. Can be recognized by SAS340. The SAS340 uses this known identification information to call a positioning method and provide more appropriate support data for HNB (eg HNB320) positioning than UE (eg UE310) positioning, step 4. Can be provided to HNB320 in and 5. The SAS340 also has other pre-obtained and stored information for the HNB320 (eg, previous position estimation of the HNB320), or other configured for the HNB320 to support a new position-fixing session. Information (eg, positioning capability) can be retrieved.

In one design, the message flow 700 can be aided by any changes to PCAP, as well as any related changes to positioning in the HNB 320 and SAS 340. The PCAP message may include an indication of the HNB and / or some other HNB identity (eg, not the IMSI or IMEI). The SAS340 can use known HNB characteristics and / or previously obtained HNB information (eg, information provided by HNB320 after HNB320 has registered with HNB GW330) to improve position-fixing support. .. The SAS340 can also update the SAS340 information about the HNB320 with any new location available for the HNB320. The cell ID IE in the PCAP Position Initiation Request message may be for a nearby macro cell if the signal strength is good. Alternatively, a rough position estimate for the HNB320, in the absence of such a macrocell, would be a PCAP message (eg, the PCAP Position in steps 2 and 3). It may be provided in the Initiation Request message). In OTDOA, macro reference cells (eg, any macro cell provided by HNB320) may be suitable for OTDOA measurements. In the E-CID, only the measurements defined for the UE may be provided to the SAS340, but these measurements can be provided to the SAS340 by the HNB320 as if the HNB320 were the UE. In A-GNSS, any fine time assistance (FTA) from SAS340 can be provided for nearby macrocells visible to HNB320.

In another design, the message flow 700 is served by the HNB320 and co-located with the HNB320 (for example, the round-trip time (RTT) is 0) to avoid impact on the PCAP and SAS340. , Can be assisted by emulating HNB320.

In one design, the HNB320 is information for A-GNSS, OTDOA, and / or other positioning methods (eg, to assist in the positioning of UEs served by or near the HNB320. Support data) can be requested from SAS340. The request and the requested information may be transmitted in a PCAP message, which may be forwarded by the HNB GW330 using PUA and SCCP. For example, the request can be sent in a PCAP Information Exchange Initiation Request message. The requested information can be found in the PCAP Information Exchange Initiation Response message or in the PCAP Information. Can be sent regularly in Report messages. The HNB 320 can broadcast the information received from the SAS 340 to the UE for use by the UE (eg UE 310) in positioning. A decision as to whether to support broadcasting can be made, for example, when the HNB 320 registers with the HMS 324.

Figure 8 shows the design of the process 800 to support the positioning service for the UE. Process 800 can be performed by a network entity, which can be HNB, MSC, SGSN, RNC, MME, BSC, etc. For example, the network entity may be the HNB 120 in the message flow 200 of FIG.

The network entity can receive a request for a positioning service for the UE (block 812). Network entities can communicate with a positioning server (eg H-SLP) via a user plane positioning method (eg SUPL) to support positioning services for the UE (block 814). Network entities can communicate with the UE via control plane positioning methods (eg, 3GPP control plane positioning methods) and support positioning services for the UE (block 816). Network entities can switch between user plane positioning and control plane positioning (block 818).

Positioning services may include positioning to locate the UE (eg, by a positioning method assisted by A-GNSS or some other network), delivery of assistive data to the UE, and the like. The network entity can obtain a position estimate for the UE from the location server or UE (block 820). The network entity can return a position estimate for the UE in response to the request (block 822).

In one design, the network entity can receive a first message for the user plane positioning method from the positioning server and send a second message for the control plane positioning method to the UE. be able to. The network entity can transfer at least some of the information in the first message to the second message. The network entity can receive a third message from the UE for the control plane positioning method and can send a fourth message for the user plane positioning method to the positioning server. The network entity can transfer at least some of the information in the third message to the fourth message. In one design, the first and fourth messages may be for the RRC positioning protocol and the second and third messages may be for the RRC positioning protocol.

In one design, the network entity can act as a UE to communicate with the positioning server, providing the UE's capabilities to the positioning server. The positioning server can provide assistance (eg, delivery of assistance data, calculation or verification of position estimation, etc.) based on the positioning capability of the UE.

Figure 9 shows the design of process 900 to support the positioning service for the UE. Process 900 may be performed by HNB (as described below) or some other entity. For example, the HNB may be the HNB 320 in the message flow 500 of FIG.

The HNB can receive a request for a positioning service for the UE (block 912). The HNB can exchange PCAP messages with a positioning server (eg SAS) via the HNB GW to support positioning services for the UE (block 914). A PCAP message is (i) a message of the first protocol (eg PUA or RUA) between HNB and HNB GW, and (ii) a second protocol (eg SCCP) between HNB GW and the positioning server. Can be transported with the message of. The HNB can exchange RRC messages with the UE to support positioning services for the UE (block 916).

Positioning services may include positioning to locate the UE (eg, by a positioning method assisted by A-GNSS or some other network), delivery of assistive data to the UE, and the like. The HNB can obtain position estimation for the UE from the positioning server or the UE (block 918). The HNB can return a position estimate for the UE in response to the request (block 920).

In one design, the HNB can receive the first PCAP message from the positioning server and send the first RRC message to the UE. The first RRC message may include positioning request and / or support data, which can be obtained from the first PCAP message. In one design, the HNB can receive a second RRC message from the UE and send a second PCAP message to the positioning server. The PCAP message may include measurement results generated by the UE and / or position estimates for the UE, which can be obtained from the RRC message.

In one design, PCAP messages can be transferred between HNB and HNB GW in PUA messages. In one design, PCAP messages can be transactional messages, and PUA messages can be associated with connection-oriented or connectionless transport over SCCP. PUA messages can include a location server (eg SAS), a transaction identifier, a local connection reference, a PCAP message, or a combination thereof.

In one design, the HNB can send information about the HNB itself to the positioning server. This information may include the cell global identifier of the HNB, the location of the HNB, the ID of at least one cell of at least one neighboring cell, the positioning capability of the HNB, and so on.

FIG. 10 shows the design of process 1000 to support the positioning service for the UE. Process 1000 may be performed by a first HNB (as described below) or some other entity. For example, the first HNB may be the source HNB 320 in the message flow 600 of FIG.

The first HNB can perform the positioning procedure by the positioning server and support the positioning service for the UE to communicate with the first HNB (block 1012). Positioning services may include positioning to locate the UE (eg, by a positioning method assisted by A-GNSS or some other network), delivery of assistive data to the UE, and the like. The first HNB can obtain instructions for handing over the UE from the first HNB to the second HNB (block 1014). Both the first HNB and the second HNB can interface with the same HNB GW and communicate with the position-fixing server via the HNB GW. The first HNB can transfer position state information to the second HNB (block 1016). The position-state information may include at least one positioning method used in the positioning procedure, information obtained for each positioning method, information related to position reporting, and / or other information. The positioning procedure can be continued by the second HNB and the positioning server based on the position state information provided by the first HNB.

The first HNB can determine whether the position-fixing procedure should be aborted or continued after the UE's handover to the second HNB. The first HNB can transfer the position state information to the second HNB in response to the decision to continue the positioning procedure. The first HNB may determine that the UE handover from the first HNB to the second HNB has failed. In that case, the first HNB can continue the position-fixing procedure by the position-fixing server when it is determined that the UE handover has failed.

Figure 11 shows the design of process 1100 to support the positioning service for HNB. Process 1100 may be performed by HNB (as described below) or some other entity. For example, the HNB may be the HNB 320 in the message flow 700 of FIG. The HNB can exchange PCAP messages with the positioning server (eg, via the HNB GW) for HNB positioning (block 1112). PCAP messages are (i) messages of the first protocol (eg PUA) between HNB and HNB GW, and (ii) messages of the second protocol (eg SCCP) between HNB GW and the positioning server. Can be transferred at. The HNB can determine its position based on the PCAP message (block 1114).

FIG. 12 shows a block diagram of the design of UE1210, HNB / home base station 1220, HNB GW1230, and position-fixing server 1240. UE1210 may be UE110 of FIG. 1 or UE310 of FIG. The HNB 1220 may be the HNB 120 of FIG. 1 or the HNB 320 of FIG. The HNB GW1230 may be the HNB GW130 of FIG. 1 or the HNB GW330 of FIG. The positioning server 1240 may be the H-SLP140 of FIG. 1 or the SAS340 of FIG. For simplicity, Figure 12 shows (i) UE1210 with one controller / processor 1212, one memory 1214, and one transmitter / receiver (TMTR / RCVR) 1216, (ii) HNB1220. For one controller / processor 1222, one memory (Mem) 1224, one transmitter / receiver 1226, and one communication (Comm) unit 1228, (iii) HNB. One controller / processor 1232, one memory 1234, and one communication unit 1236 for the GW1230, and (iv) one controller / processor 1242, one memory 1244, and (iv) for the locator server 1240. One communication unit 1246 is shown. In general, each entity may include any number of controllers, processors, memory, transmitters / receivers, communication units, and the like.

On the downlink, the HNB1220 can send traffic data, signaling, broadcast information, and pilot signals to the UE within the coverage of the HNB1220. These various types of data can be processed by processor 1222, tuned by transmitter 1226, and transmitted downlink. In UE1210, downlink signals from HNB1220 and / or other base stations are received via the antenna, tuned by receiver 1216, processed by processor 1212, and transmitted by HNB1220 and / or other base stations. Various kinds of information can be recovered. Processor 1212 can perform processing for the UE in the message flows of Figures 2, 5, and 6. Memories 1214 and 1224 can store program code and data for UE1210 and HNB1220, respectively. On the uplink, the UE1210 can send traffic data, signaling, and pilot signals to the HNB1220 and / or the base station. These various types of data can be processed by processor 1212, tuned by transmitter 1216, and transmitted over the uplink. In the HNB1220, uplink signals from UE1210 and other UEs are received and tuned by receiver 1226 and further processed by processor 1222 to recover various types of information transmitted by UE1210 and other UEs. Can be done. Processor 1222 performs or directs processing 800 of FIG. 8, processing 900 of FIG. 9, processing 1000 of FIG. 10, processing 1100 of FIG. 11, and / or other processing for the techniques described herein. can do. Processor 1222 can also perform processing for the HNB 120 or 320 in the message flows of Figures 2, 5, 6 and 7. HNB1220 is used for other network entertainment via communication unit 1228.

Within the HNB GW1230, the processor 1232 supports communication for the HNB within control, supports the transfer of messages between the HNB 1220 and the positioning server 1240, and other normally performed by the HNB GW. Can perform functions. Processor 1232 can also perform processing for the HNB GW 130 or 330 in the message flows of Figures 2, 5, 6, and 7. Memory 1234 can store program code or data for the HNB GW1230. Communication unit 1236 may allow the HNB GW1230 to communicate with other entities.

Within the positioning server 1240, processor 1242 can perform positioning for the UE, provide assistive data to the UE, support positioning services for the UE and other LCS clients, and so on. Processor 1242 can also perform processing for the H-SLP140 in the message flow of FIG. 2 and for SAS340 in the message flow of FIGS. 5, 6 and 7. Memory 1244 can store program code and data for the positioning server 1240. Communication unit 1246 may allow the positioning server 1240 to communicate with other entities.

Those skilled in the art will appreciate that information and signals can be represented using any of a wide variety of techniques and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be mentioned throughout the above description are by voltage, current, electromagnetic waves, magnetic fields or particles, light fields or particles, or any combination thereof. Can be represented.

Further, those skilled in the art will appreciate that the various exemplary logical blocks, modules, circuits, and algorithmic steps described with respect to the disclosure herein may be implemented as electronic hardware, computer software, or a combination of both. Let's do it. To articulate this compatibility of hardware and software, various exemplary components, blocks, modules, circuits, and steps have been generally described above with respect to their functionality. Whether such functionality is implemented as hardware or software depends on specific application examples and design constraints imposed on the overall system. Those skilled in the art may implement the described functionality in various ways for each specific application, but decisions on such implementation should not be construed as causing a deviation from the scope of this disclosure.

The various exemplary logic blocks, modules, and circuits described with reference to the disclosure herein are general purpose processors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or others. It can be implemented or performed in programmable logic devices, individual gate or transistor logic, individual hardware components, or any combination thereof designed to perform the functions described herein. The general purpose processor can be a microprocessor, but in the alternative, the general purpose processor can be any conventional processor, controller, microcontroller, or state machine. Processors are also implemented as a combination of computing devices, such as a combination of DSP and microprocessor, multiple microprocessors, one or more microprocessors working with a DSP core, or any other such configuration. obtain.

The steps of the methods or algorithms described with respect to the disclosure herein may be performed directly in hardware, in software modules executed by a processor, or in combination of the two. Software modules reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disks, removable disks, CD-ROMs, or any other form of storage medium known in the art. Can be done. An exemplary storage medium is coupled to the processor so that the processor can read information from the storage medium and write the information to the storage medium. Alternatively, the storage medium can be integrated with the processor. Processors and storage media can be in the ASIC. The ASIC can be present in the user terminal. Alternatively, the processor and storage medium may exist as individual components in the user terminal.

In one or more exemplary designs, the features described may be implemented in hardware, software, firmware, or any combination thereof. When implemented in software, features may be stored on a computer-readable medium as one or more instructions or codes. Computer-readable media do not refer to transient propagating signals. The storage medium can be any available medium that can be accessed by a general purpose or dedicated computer. By way of example, but not by limitation, such computer-readable media are RAM, ROM, EEPROM, CD-ROM, or other optical disk storage, magnetic disk storage or other magnetic storage device, or any desired form of instruction or data structure. It can include any other medium that is used to store program code means and can be accessed by a general purpose or dedicated computer or a general purpose or dedicated processor. As used herein, discs and discs are compact discs (CDs), laser discs (registered trademarks), optical discs, digital versatile discs (DVDs), floppy (registered trademarks) discs, and Including Blu-ray discs, discs usually play data magnetically, and discs play data optically with a laser. The above combinations shall also be included within the scope of computer readable media.

The above description of the disclosure is provided to allow one of ordinary skill in the art to create or use the disclosure. Various modifications to this disclosure will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other variants without departing from the spirit and scope of this disclosure. Accordingly, this disclosure is not limited to the examples and designs described herein, but is provided with the maximum scope consistent with the principles and novel features disclosed herein.

100 wireless networks 110 User device 120 HNB 130 HNB gateway 140 H-SLP 150 backbone network 300 wireless network 310 User equipment 320 HNB 322 HNB 324 HMS 330 HNB gateway 340 SAS 350 backbone network 352 MSC / SGSN 354 GMLC 360 LCS client 1210 User device 1220 HNB 1230 HNB gateway 1240 location server