User plane location based service using message tunneling to support roaming

(54) Title: SERVICE BASED ON USER PLAN LOCATION USING MESSAGE ENCAPSULATION TO SUPPORT ROAMING (30) Unionist Priority: 12/02/2003 us 10 / 724,773 (71) Depositor (s): Telecommunication Systems, Inc. (US) (72) Inventor (s): YinjunZhu (74) Attorney: Dannemann, Siemsen, Bigler & Ipanema Moreira (86) International request: pct US2004 / 040115 of 12/02/2004 (87) International publication: wo 2005/057884 de 23/06/2005 (57) Summary: SERVICE BASED ON USER PLAN LOCATION USING MESSAGE ENCAPSULATION TO SUPPORT ROAMING. An improved architecture based on User Plan location and message flow, which allows total User Plan location based services even when a mobile or wireless device is roaming between different carrier networks. The present invention overcomes the restrictions inherent in the current protocol for roaming support defined by the Secure User Plan Location Service report. A location system is allowed to go back to a message encapsulation mechanism to ensure the security of a communication path between the location service system and the target wireless device, ensuring that the communication path is not interrupted as far as The wireless device moves.

<img file="BRPI0417246A_D0001.tif" />

PJ. oMMW

Invention Patent Description Report for SERVICE BASED ON USER PLAN LOCATION USING MESSAGE ENCAPSULATION TO SUPPORT ROAMING.

BACKGROUND OF THE INVENTION

FIELD OF THE INVENTION

The present invention generally relates to wireless and long distance carriers, Internet Service Providers (ISPs), and information content service and providers and long distance carriers. More specifically, this refers to location services for the wireless industry.

BACKGROUND OF RELATED TECHNIQUE

It is desired to precisely locate the physical position of a wireless device (for example, a cordless phone) within a wireless network. There are currently two different types of architecture developed to run a location based service (LSB): the Control Plan location based services, and more recently the User Plan location based services.

Older location-based services use what is now called Control Plan location-based services. A Control Plan location-based service uses a management system to automate and build processes and perform inventory management. A Control Piano location-based service uses control or signaling messages to determine the location of a specific wireless device.

A key difference between these two technologies is that a Control Plan solution uses a control channel to communicate with the wireless device, while a User Plan solution uses the subscriber's own traffic channel (for example, support of IP or SMS) to communicate with the wireless device. A Control Plan solution requires software updates for almost all existing wireless network components and devices', while a User Plan solution is recognized as a more doable solution for carriers to provide location-based services.

The concept known as a User Plan location-based service makes use of the user's own support channel, for example, IP or SMS support, to establish the communication required to initiate a positioning procedure. User Plan location-based services were introduced as an alternative location service architecture as defined in standard organizations, for example, 3GPP.

Thus, User Plan location-based services use the content of the communication itself to locate the wireless device. User Plan location-based services focus on the TCP / IP capability of a wireless device, such as a mobile phone, to generally bypass the carrier infrastructure and instead use, for example, the Internet. There are significant advantages to the development of User Plan location-based services, including an easier and more streamlined architecture than that of a Control Plan location-based service. In this way, costly upgrades are avoided, and rapid and relatively economical development is possible using otherwise conventional system components.

In User Plan location-based services, the inventors noted that there is a problem with the location service procedure when the mobile object is roaming and IP support is used (IP support is the standard support for solutions User Plan location service provider). Roaming refers to the physical movement of a wireless device between the territories covered by different wireless carriers.

Specifically, based on the conventional User Plan location service architecture, the target or mobile wireless device to be located must communicate with the Positioning Server (known as GMLC in 3GPP, MPC in 3GPP2) that is serving the cell where the wireless device is camping. In this procedure, a Context of

PDP is established between the wireless device and GGSN on the Domestic Public Land Mobile Network (H-PLMN). The PDP Context is a communication channel established for the target wireless device to access IP networks, including an H-LCS Manager (known as H-GMLC on 3GPP, or H-MPC on 3GPP2) and an LCS Manager Visited (known as GMLC Visited in 3GPP, or MPC Visited in 3GPP2), and / or a Positioning Server (known as SMLC in 3GPP, or PDE in 3GPP2).

However, the inventors here realize that for security reasons, IP networks of different PLMNs are separated with protective IP firewalls. Furthermore, within a PLMN, the IP network is usually configured as a private network that uses private IP addresses. IP connectivity to the Internet passes through a port router that provides a NAT function. However, in the currently defined User Plan location-based services, a wireless target device must communicate with the positioning server on the Visited PLMN through the GGSN on Domestic PLMN, using the private IP positioning address of the provided server by the Visited LCS Manager. However, in a roaming scenario, it is realized that a wireless device is currently not allowed to communicate directly with an appropriate positioning server due to the various firewalls.

Although User Plan location-based solutions have been developed and deployed across a number of networks, support is not complete, especially when GPRS IP support is used as the support. This invention introduces a methodology to solve a key problem related to a roaming scenario for User Plan location-based service solutions.

In conventional 3GPP network architectures, when a mobile starts a packet data service section, called a PDP Context, the location SGNS will establish a connection with the GGSN indicated by an Access Point Name (APN) provided by the mobile. The GGSN identified by the APN usually resides on the Mobile Public Terrestrial Home Network (H-PLMN). Thus, in the roaming scenario, IP support is established between the MS and GGSN in Domestic PLMN. Therefore, all IP traffic to / from the mobile is funneled to the Domestic PLMN.

With a Version 6 architecture of the 3GPP standard, a Mobile Door Location Center (GMLC) is able to communicate with other GMLCs that reside in different PLMNs, using an Lr interface. Thus, the Lr interface is allowed to pass through the firewalls of PLMNs, trying to provide adequate services in a roaming scenario.

In a Mobile Termination (MT) location service in a roaming scenario, the mobile or wireless device must communicate with the local positioning server for a User Plan location-based service (sometimes referred to as SMLC using 3GPP standard terminology), to exchange location information and request assistance and a positioning calculation depending on the specific positioning method being used.

However, during the MT location service procedure of a conventional User Plan location based service, a wireless device will be provided with the IP address of the local positioning server. As the inventors appreciated, this IP address is usually a private IP address. So, although in theory full roaming support seems to be allowed, the inventors here have appreciated that in reality the wireless device is not always able to reach its IP host over a private network (H-PLMN) because it is protected by firewalls.

There is a need to provide roaming support for a real-world subscriber using a User Plan location based service on an existing GPRS network architecture.

SUMMARY OF THE INVENTION

In accordance with the principles of the present invention, a message bottleneck mechanism allows a User Plan location service to continuously support a location based service even when the target subscriber is roaming on different networks.

In one aspect of the invention, a method of providing a User Plan location-based service for a wireless roaming device comprises establishing a roaming interface between the home LCS manager of a home wireless carrier network and an LCS manager visited from a currently visited wireless carrier network. IP connectivity is directed over the Internet with the ability to be transmitted through a firewall on the home wireless carrier network and through a firewall on the visited wireless carrier network. A message bottleneck mechanism is provided to provide an uninterrupted communication path between a location-based service system and a wireless device being located.

BRIEF DESCRIPTION OF THE DRAWINGS

The features and advantages of the present invention will be apparent to those skilled in the art of the following description with reference to the drawings, in which:

Figure 1 shows an exemplary user plan location service architecture according to an embodiment of the present invention.

Figure 2 shows an exemplary user plan location service signaling based on the user plan location service according to Figure 1.

Figure 3 shows an improved user plan location service signaling using a message bottleneck mechanism, based on the user plan location service according to Figure 1.

Figure 4 shows an exemplary message flow for message bottlenecks to support roaming in a User Plan location-based service, in accordance with the principles of the present invention.

Figure 5 shows an exemplary message flow for message bottlenecks to support roaming in a User Plan location based service, where a Visited LCS Manager and a Visited Positioning Server are integrated into a device, according to principles of the present invention.

DETAILED DESCRIPTION OF THE ILLUSTRATIVE MODALITIES

The present invention relates to the provision of an architecture and service message flow based on User Plan location (LBS), allowing uninterrupted User Plan location based services even when a mobile or wireless device roams between different carrier networks.

The present invention overcomes the restrictions inherent in the current protocol for support and roaming defined by the Secure User Plan Location Service specification.

The solution of the invention allows a location system to automatically fall back into a message bottleneck mechanism to ensure the security of a communication path between the location service system and the target wireless device, ensuring that the communication path be uninterrupted as the wireless device moves.

Figure 1 shows an exemplary user plan location service architecture of the present invention.

Specifically, as shown in Figure 1, a roaming interface (Lr) is established between LCS Managers (known as GMLCs in 3GPP, or MPCs in 3GPP2), which can direct IP connectivity through firewalls over the Internet. The solution of the invention implements a message bottleneck mechanism to provide end-to-end protocol connectivity through a Home LCS manager and / or a visited LCS manager.

An important concept introduced by the present invention is the use of a message level bottleneck through GMLCs using the Lr interface. With this method, a wireless device can communicate with the local positioning server, traversing the

PLMNs, to complete the requested User Plan positioning procedure.

Figure 2 shows a user plan location service signaling as shown in Figure 1.

Specifically, as shown in Figure 2, the roaming UE needs to communicate with the Positioning Server V that resides in the Visited PLMN, based on the procedure defined in the User Plan LCS, it cannot even establish a TCP connection with Positioning Server V, even though they are physically on the same network. Therefore, the current User Plan architecture cannot support roaming scenarios for mobile networks using private IP address assignments (which is very common in the industry due to the limited resource of IP addresses).

Figure 3 shows an improved user plan location service signaling using a message bottleneck mechanism, based on the user plan location service according to Figure 1.

Specifically, Figure 3 illustrates the concept of message bottlenecks for the User Plan LCS service in roaming scenarios. In this case, the UE sends a User Plan message, which should be sent to Positioning Server V, to the Home LCS Manager instead. The Home LCS Manager encapsulates the received message in a generic message and sends it to the LCS Manager V. With the existing 3GPP Version 6 architecture, an LCS Manager (known as GMLC in 3GPP) is able to communicate with other LCS Managers (or GMLCs) residing in different PLMNs, using the Lr interface, ie the interface Lr is allowed to pass through the firewalls of PLMNs. The LCS Manager V also uses a message bottleneck mechanism to pass the message from the UE to the V Positioning Server, through local IP network connectivity.

Figure 4 shows an exemplary message flow for message bottlenecks to support roaming in a User Plan location-based service, in accordance with the principles of the present invention.

STEP A

As shown in Step A of Figure 4, when receiving a location request from an enabled location service application, the LCS Agent 302 can authenticate the application. If authentication is successful, LCS Agent 302 issues an MLP Location request to Requesting LCS Manager 304, with which the LCS Agent is associated, for immediate location fixing.

STEP B

LCS Requesting Manager 304 authenticates LCS Agent 302, and verifies that LCS Agent 302 is authorized for the service it requests, based on the Ics-client-id received.

By examining the msid received from the target subscriber, the LCS Manager R 304 can identify the relevant Home LCS Manager 306 based, for example, on roaming agreements, or using a Domain Name Service (DNS) lookup mechanism similar to IETF RFC 2916. The mechanisms used to identify the relevant 306 Home LCS Manager are known to those skilled in the art.

LCS Manager R 304 then transfers the location request to the target subscriber's Home LCS Manager 306 using an Lr interface.

STEP C

Upon receipt of a location request, Home LCS Manager 306 applies Subscriber Privacy against Ics-client-id, requestor-id, qos, etc. that are received in the request. This use case assumes a successful privacy check. If LCS Manager 304 does not authorize the application, Step N will be returned with the applicable MLP return code.

The LCS Manager H 306 then initiates location processing with user equipment (UE) 312 using a suitable LCS INIT message, for example a wireless application protocol (WAP) PUSH, or a short message system trigger (SMS), and starts a T1 timer.

The LCS Manager H 306 can optionally provide the raw position information from UE to the UE at this time if the LCS Manager H 306 is aware of the gross position.

If the result of the privacy check in Step B indicates that a notification or verification from the target subscriber is required, the LCS Manager H 306 may also include a notification element in the LCS INIT message.

STEP D

If Notification / Verification is required, an instant UE text can be used to notify the subscriber requesting their location information, for example, Ics-client-id, requestor-id, requesttype, etc. Optionally, the subscriber can be allowed to either grant the location request or deny the location request.

If the target subscriber grants the location request, the UE 312 starts the positioning procedure by retrieving the cell information it is serving current, TA, NMR, and capacity from the mobile device. The UE 312 then initiates a location section with the LCS Manager H 306 using Start Location Request (SLREQ), with optional cell and AD, TA and NMR information if the UE needs to obtain assistance data, and / or TA and NMR are available. Optionally, UE 312 also indicates whether the target subscriber has granted access when verification is required in the LCS INIT message.

If the target subscriber denies the location request, the UE 312 initiates a location response to the LCS Manager H 306 that includes the denial indication.

When LCS Manager H 306 receives the SLREQ message from the target subscriber for the pending transaction, it stops timer T1.

STEP E

If the target subscriber denied the location request in Step D, Step L will resume with the applicable MLP return code. In this case, Steps E through K are skipped. Otherwise, with cell information from target UE 312 (or through another mechanism), LCS Manager H 306 can determine that target UE 312 is roaming. Based on a relevant roaming agreement, or using a DNS query mechanism similar to IETF RFC 2916, LCS Manager H 306 can identify the Visited LCS Manager 308, and initiate an Lr request to the Visited LCS Manager 308, with an indicator that the message bottleneck mechanism will be used for this transition.

STEP F

When receiving the Lr request the visited LCS Manager 308 initiates a Position Request (PREQ), with cellinfo, NMR, device cap, etc., optional for Positioning Server 310 that serves the area where the target UE 312 is currently located.

STEP G

Positioning Server 310 sends a Positioning Response (PRESP) back to LCS Manager V 308, and confirms that Positioning Server 310 is ready to process the location request identified by sessionid.

STEP H

Upon receipt of the Position Response message, LCS Manager V 308 sends an Lr Response message to LCS Manager H 306. The Lr response message may include, for example, the IP address (URL) of Positioning Server 310. STEP I

When receiving the confirmation of the PRESP message from the Positioning Server 310 that it is serving, the LCS Manager H 306 sends a Start Location Response (SLRESP) message with the address of the LCS Manager H 306 instead of the Po11 Server V positioning for a non-roaming scenario, if direct communication between the Positioning Server 310 it is serving and the target UE 312 is required, and an optional posmode for the target UE 312.

Note, importantly, that the address provided by the Positioning Server 310 that you are serving can be a private IP address in the roaming scenario.

STEP J

Upon roaming detection for the relevant UE 312, target UE 312 initiates position determination, for example Position Determination Initiation (PDINIT), and sessionid, for LCS Manager H 306. The PDINIT message optionally contains additional information, for example, cell id, ad, and / or IS-801 PDU.

STEP K

When receiving the message, LCS Manager H 306 forwards the PDINIT message within a Position Data message that corresponds to the sessionid to LCS Manager V 308 via the relevant Lr connection.

STEP L

LCS Manager V 308 forwards the received Position Data message to the Positioning Server 310 it is serving.

STEP M

Positioning Server 310 and target UE 312 initiate an accurate positioning procedure by exchanging encapsulated Position Determination Message (PDMESS) messages with Position Data as illustrated in Steps J, K and L, through LCS Manager H 306 and LCS Manager V 308.

Importantly, the positioning procedure itself can be, for example, a transaction based on RRLP, IS-801, or RRC. However, the positioning procedure protocol (for example, RRLP, IS-801 or RRC) is funneled into PDMESS messages, which are funneled by generic Position Data messages that are carried between the LCS Manager H and the LCS V Manager.

STEP N

Positioning Server 310 can send a Position Report (PRPT) to LCS Managers R / H / V 304, 306, 308 with the location information of the target UE 312.

STEPS O, P

When receiving the position estimates required from the Position Report (PRPT) the Visited LCS Manager 308 forwards the location estimate to the Home LCS Manager 306 using an Lr response message.

STEP Q

Home LCS Manager 306 forwards the location estimate to the Requesting LCS Manager 304 if the location estimate is permitted by the target subscriber's privacy settings. STEP R

Finally, Requesting LCS Manager 304 sends an MLP SLIA message with location estimates back to LCS Agent 302.

Figure 5 shows an exemplary message flow for message bottlenecks to support roaming in a User Plan location-based service, where the Visited LCS Manager and the Visited Positioning Server are integrated into a device according to the principles of the present invention.

STEP A

As shown in Step A of Figure 4 when receiving a location request from an enabled location service application, the LCS Agent 302 can authenticate the application. If authentication is successful, LCS Agent 302 issues an MLP Location request to Requesting LCS Manager 304, with which the LCS Agent is associated, for immediate location fixing.

STEP B

Requesting LCS Manager 304 authenticates the

LCS 302, and verifies that the LCS Agent 302 is authorized for the service it requests, based on the Ics-client-id received.

By examining the msid received from the target subscriber, the LCS Manager R 304 can identify the relevant Home LCS Manager 306 based, for example, on roaming agreements, or using a Domain Name Service (DNS) lookup mechanism similar to IETF RFC 2916. The mechanisms used to identify the relevant 306 Home LCS Manager are known to those skilled in the art.

LCS Manager R 304 then transfers the location request to the target subscriber's Home LCS Manager 306 using an Lr interface.

STEP C

Upon receipt of a location request, Home LCS Manager 306 applies Subscriber Privacy against Ics-client-id, requestor-id, qos, etc. that are received in the request. This use case assumes a successful privacy check. If LCS Manager 304 does not authorize the application, Step N will be returned with the applicable MLP return code.

LCS Manager H 306 then initiates location processing with user equipment (UE) 302 using a suitable LCS INIT message, for example a wireless application protocol (WAP) PUSH, or a short message system trigger (SMS), and starts a T1 timer.

The LCS Manager H 306 can optionally provide the raw position information from UE to the UE at this time if the LCS Manager H 306 is aware of the gross position.

If the result of the privacy check in Step B indicates that a notification or verification from the target subscriber is required, the LCS Manager H 306 may also include a notification element in the LCS INIT message.

STEP D

If Notification / Verification is required, an instant UE text can be used to notify the subscriber requesting their location information, for example, Ics-client-id, requestor-id, requesttype, etc. Optionally, the subscriber can be allowed to either grant the location request or deny the location request.

If the target subscriber grants the location request, the UE 312 starts the positioning procedure by retrieving the cell information it is serving current, TA, NMR, and capacity from the mobile device. The UE 312 then initiates a location section with the LCS Manager H 306 using Start Location Request (SLREQ), with optional cell and AD, TA and NMR information if the UE needs to obtain assistance data, and / or TA and NMR are available. Optionally, UE 312 also indicates whether the target subscriber has granted access when verification is required in the LCS INIT message.

If the target subscriber denies the location request, the UE 312 initiates a location response to the LCS Manager H 306 that includes the denial indication.

When the LCS Manager H 306 receives the SLREQ message from the target subscriber for the pending transaction, it stops the IT timer.

STEP E

If the target subscriber denied the location request in Step D, Step L will be returned with the applicable MLP return code. In this case, Steps E through K are skipped. Otherwise, with cell information from target UE 312 (or through another mechanism), LCS Manager H 306 can determine that target UE 312 is roaming. Based on a relevant roaming agreement, or using a DNS query mechanism similar to IETF RFC 2916, LCS Manager H 306 can identify the Visited LCS Manager 308, and initiate an Lr request to the Visited LCS Manager 308, with an indicator that the message bottleneck mechanism will be used for this transition.

STEP F

Positioning Server 310 and target UE 312 initiate an accurate positioning procedure by exchanging encapsulated Position Determination Message (PDMESS) messages with Position Data messages, via LCS Manager H 306 and LCS Manager V308.

Importantly, the positioning procedure itself can be, for example, a transaction based on RRLP, IS-801, or RRC. However, the positioning procedure protocol (for example, RRLP, IS-801 or RRC) is funneled into PDMESS messages, which are funneled by generic Position Data messages that are carried between the LCS Manager H and the LCS Manager V. STEP G

When receiving the position estimates required in Step F, Visited LCS Manager 308 forwards the location estimate to Home LCS Manager 306 using an Lr response message.

STEP H

Home LCS Manager 306 forwards the location estimate to the Requesting LCS Manager 304 if the location estimate is permitted by the target subscriber's privacy settings. STEP I

Finally, Requesting LCS Manager 304 sends an MLP SLIA message with location estimates back to LCS Agent 302.

Although the invention has been described with reference to its exemplary modalities, those skilled in the art will be able to make several modifications to the described modalities of the invention without departing from the true spirit and scope of the invention.