GB2558246A

GB2558246A - Method and system for implementing efficient cellular data roaming

Info

Publication number: GB2558246A
Application number: GB1622067.5A
Authority: GB
Inventors: Ward Colm; Portley Nigel; Kelly Kieran; Mullin David; Mulqueen Kay
Original assignee: Tango Telecom Ltd
Current assignee: Tango Telecom Ltd
Priority date: 2016-12-22
Filing date: 2016-12-22
Publication date: 2018-07-11
Anticipated expiration: 2036-12-22
Also published as: GB2558246B; GB201622067D0

Abstract

A proxy device is positioned in a GPRS Tunnelling Protocol (GTP) data pathway in a mobile telephone network. The proxy device has an analysis engine which is employed for data usage monitoring, routing or charging purposes. The analysis engine may redirect data packets intended for the GGSN of another network to a local node for connection to the internet The proxy device may alter the address of data packets from a home mobile phone network APN of a roaming device on the network to a local APN of the mobile phone network. The proxy device may have charging engine for data charging on users of the mobile telephone network based on monitoring data usage performed by the analysis engine. The charging engine may be configured to interact with an internal OCS or third party system. The proxy device may alter the QoS being received by a device. The GTP proxy may be situated in a visited mobile network and may redirect traffic intended for the home network elsewhere, for instance by routing the data traffic locally through the visited network. This feature may be referred to as Local Breakout (LBO) or Regional Breakout.

Description

(71) Applicant(s):

Tango Telecom Limited Walton House, Lonsdale Road,

National Technology Park, Limerick, Ireland, Ireland (72) Inventor(s):

Colm Ward Nigel Portley Kieran Kelly David Mullin Kay Mulqueen (74) Agent and/or Address for Service:

Hanna Moore + Curley

Garryard House, 25/26 Earlsfort Terrace, Dublin 2, DO2 PX51, Ireland (51) INT CL:

H04W 76/22 (2018.01) H04W 8/08 (2009.01)

H04W 76/12 (2018.01) H04W 88/18 (2009.01) (56) Documents Cited:

EP 2522165 B1

3GPP Draft; S2-100492; SAWG2; 2010-01-12; 3rd Generation Partnership Project (3GPP), Mobile Competence Centre, 650, route des Lucioles, F-06921 Sophia-Antipolis Cedex, France; Selected IP Traffic Offload for UMTS at LuPS; XP050433032 (58) Field of Search:

INT CLH04W

Other: EPODOC, WPI, Patent Fulltext, XP3GPP (54) Title of the Invention: Method and system for implementing efficient cellular data roaming Abstract Title: Functions and services provided by a GTP based proxy in a cellular network (57) A proxy device is positioned in a GPRS Tunnelling Protocol (GTP) data pathway in a mobile telephone network.

The proxy device has an analysis engine which is employed for data usage monitoring, routing or charging purposes.

The analysis engine may redirect data packets intended for the GGSN of another network to a local node for connection to the internet

The proxy device may alter the address of data packets from a home mobile phone network APN of a roaming device on the network to a local APN of the mobile phone network.

The proxy device may have charging engine for data charging on users of the mobile telephone network based on monitoring data usage performed by the analysis engine. The charging engine may be configured to interact with an internal OCS or third party system. The proxy device may alter the QoS being received by a device.

The GTP proxy may be situated in a visited mobile network and may redirect traffic intended for the home network elsewhere, for instance by routing the data traffic locally through the visited network. This feature may be referred to as Local Breakout (LBO) or Regional Breakout.

1/5 ο

CM

CM w

Optional charging relationship

2/5 ο

CM

3/5

03 18

δ ω

c ω

Ε ο

X

Fig. 3

4/5

5/5

METHOD AND SYSTEM FOR IMPLEMENTING EFFICIENT CELLULAR DATA ROAMING

Field of the Application

The present application relates to the routing of data in a mobile phone network.

Background

High quality cost effective mobile data access has become an important aspect of modern life and a key driver for economic development globally. Smartphones, tablets & other mobile data devices are used more and more for data transfer or to access data services such as Facebook, Twitter, Whatsapp, Netflix, for essential navigation and access to information services in addition to pure web browsing. The fast developing Internet of Things (IoT) also requires high quality cost effective mobile data access.

Increasingly, users of mobile data services expect the quality and cost effectiveness of their service to be maintained when they are travelling outside of the home network; i.e. when roaming in visited networks.

Traditionally, the approach to providing mobile data services when a user is roaming in a visited cellular network is arranged by having the visited network route the actual data traffic back from the user to the home network, where it is handled in a similar manner to when the subscriber or device is located in the home network.

There are a number of reasons for this approach, not least because the home network needs to be in a position to monitor and charge for the services used.

There are several problems associated with this method of providing cellular data roaming services.

The first category of problems arise because of the need to route increasingly high and more critically rapidly growing bandwidths of data traffic over international roaming networks which were not necessarily designed for the traffic.

The approach is often also very inefficient, because in many cases the endpoint for the user’s traffic is closer to the visited network than the home network.

The second category of problems is related to the ensuring that monitoring and charging functionality continues to work adequately, both for prepaid and for postpaid traffic, without creation of any fraud windows etc.

The third category of problem is related to the commercial arrangements between the home network, the visited network and the intermediate carriers.

Because of the complexity of these arrangements, and the feeling that roaming data users are a special case to which relatively high tariffs can be applied, the outcome has been that the majority of cellular roaming customers globally do not use cellular data when roaming.

There represents a significant loss of potential revenue for Mobile Network Operators (MNOs).

This present invention concerns a method and system for implementing efficient cellular data roaming which avoids the above problems.

Summary

In a first aspect, the present application provides a proxy device for positioning in a GTP data pathway of a mobile telephone network. The proxy device comprises a receiving interface for receiving data packets, an analysis engine for analysing the data packets and a transmission interface for onward transmission of the received data packets, wherein the analysis engine is employed for data usage monitoring, routing or charging purposes.

The analysis engine may be configured to redirect data packets intended for the GGSN of another network to a local node for connection to the Internet. In this case, the proxy device may be configured to alter the address of data packets from a home mobile phone network APN of a roaming device on the network to a local APN of the mobile phone network. Similarly, the proxy device may be configured to map an IMSI and or MSISDN for a device roaming on the mobile telephone network to appear as an authorised device for a APN of the mobile telephone network.

The proxy device may further comprise a charging engine for implementing a data charging function on users of the mobile telephone network based on monitoring of data usage performed by the analysis engine. This charging engine may be configured to interact with an internal OCS or to a third party payment system. The charging engine may use locally stored micro balances for individual users. This is so as to reduce the number of interactions required with the OCS or third party payment service.

The proxy device is configured, through the analysis engine or other aspect to disconnect a user’s data session when a predetermined condition is detected. This disconnection can simply involve the proxy not forwarding packets for/from the user. Various predetermined condition may be employed including for example but not limited to conditions associated with an individual user, including for example but not limited to when an account balance is zero, a data throughput quota has been reached, an access duration timer has expired or other condition identifying where an account is required to be replenished/renewed.

Disconnecting a user’s session may comprise redirecting user’s data to a server configured to respond with a message with one or both of informing the user that the predetermined condition has been reached and allowing the user to replenish their account.

The proxy may be configured to alter the QoS being received by a device. In this option, the proxy alters the QoS for a user by at least redirecting some of the traffic for the user through an alternative node. The proxy may be configured to charge for the QoS delivered to the end user. The proxy device is configured to manipulate charging parameters in the GTP flow to suppress the generation of chargeable TAP records, suitably in a visited, transit or home network. The analysis engine may be configured to detect the absence of a data session from an identified roaming data subscriber within a given time and in response to making such a detection being configured to message the identified user with an offer or promotion to encourage roaming data usage.

Description of Drawings

The present application will now be explained in the context of the accompanying drawings in which:

Figure 1 is a representation of a conventional data roaming scenario;

Figure 2 is a representation of an arrangement of the GTP proxy for roaming according to a first aspect of the application

Figure 3 is a representation of an arrangement of the GTP proxy provided in the home network for data monitoring and/or specialised routing;

Figure 4 is an arrangement of the GTP proxy for handling of the GTP protocol for a GPRS cellular network; and

Figure 5 is a representation of an example of the business logic associated with the GTP proxy for the case of silent roamer detection and the promotion of appropriate data packages for such roamers.

Detailed Description

The present application relates to when a mobile subscriber is roaming outside their mobile telephone network and wishes to use data roaming via an alternative means to the data roaming mechanism charged by their home network.

Currently, when an international roaming mobile subscriber attempts to access data via mobile data roaming, the data path is routed from the international visited network back to the home country network of the subscriber from where it is further routed out of the mobile network onto the internet. This arrangement is shown generally in Figure 1.

In this conventional setup, the roaming data traffic arrives from the user roaming on the foreign (visited) network at the SGSN (Serving GPRS support node) of the visiting network. The SGSN may provide initial access to a Domain Name Service access to subscribers and visiting roamers to determine the end destination for the data.

Thereafter traffic is routed by the SGSN through the GTP (GPRS Tunnelling Protocol) network layer.

In the case of local subscribers of the roaming network, the traffic is routed to the GGSN (Gateway GPRS Support Node) of the roaming network from where a decision is made whether to pass the data more generally to the Internet.

More particularly, the GGSN acts as a gateway onto the external internet and monitors and controls and optionally charges for the data access. In the diagram this charging is shown for a prepaid subscriber, to be performed via the subscribers account in the home OCS (Online Charging System).

As explained above, the data is carried between the SGSN and the GGSN using a protocol known as GTP (GPRS Tunnelling Protocol). In larger networks, intermediate routers (not shown) may additionally be employed.

A similar arrangement happens for visiting roamers except their traffic is routed through the GTP layer to the GGSN (Gateway GPRS Support Node) in the home network. Once at the GGSN (Gateway GPRS Support Node), the data is passed more generally to the Internet.

Similar to the local subscribers on the roaming network, the home GGSN acts as a gateway onto the external internet and monitors and controls and optionally charges for the data access. In the diagram this charging is shown for a prepaid subscriber, to be performed via the subscribers account in the home OCS (Online Charging System). The data is carried between the SGSN and the GGSN using a protocol known as GTP (GPRS Tunnelling Protocol) and in larger networks may use intermediate routers (not shown).

The same approach will be followed irrespective of the technology employed for the wireless telephone network. However, the names of the various elements may change based on the type of network. Thus for example, in a LTE (4G) network, the SGSN and GGSN may be referred to by their equivalent names S-GW (serving gateway) and P-GW (packet gateway) respectively, which are assumed in the remainder of this document to be included in the terms SGSN and GGSN. Similarly, in a Wi-Fi network, the equivalent functional elements are named differently but assumed to be referred to in this document by the generic SGSN & GGSN terms.

The present application is directed at avoiding the problems identified above with these approaches.

In a first aspect of the application, as shown in Figure 2, the present application provides a GTP (GPRS Tunnelling Protocol) proxy device.

The GTP proxy is installed in the network of a mobile provider and receives user data transmitted from the SGSN and intended for the GGSN of the local (roaming) network or the home network of a visiting roamer. Equally, the GTP proxy may be installed in an intermediate connection point between the visited network and the home network.

In simple terms, the GTP proxy comprises a network interface for receiving and transmitting packets onto a GTP network of the mobile phone network. The network interface functionally has a receiving interface for receiving data packets and a transmission interface for onward transmission of the received data packets.

The GTP proxy has an analysis engine that analyses the packets as they arrive at the proxy. The analysis engine may analyse packets in both directions, i.e. coming from and going to mobile phones. The analysis engine may also alter the contents of packets, including their header information to change the source or destination of the packet or other characteristic as will be understood in the context of the description which follows in which it will be appreciated that functionality described may be implemented in the analysis engine or an associated component with which it interacts.

The GTP proxy acts to redirect data traffic intended for the home network elsewhere. This redirection is able to cause the visiting subscribers data traffic to be routed to the internet via the visited network GGSN or intermediate network GGSN rather than conventionally via the home network. This feature may be referred to as Local

Breakout or Regional Breakout depending on the level in the roaming or intermediate network at which the breakout occurs.

The redirection happens under carefully controlled conditions to ensure that the approach is not susceptible to fraud or other issues.

The GTP proxy enable this effect and selectively monitors and controls the roamer’s data roaming services while they are in the visited network.

All of this may be achieved transparently to the user of the service, i.e. without the need for the user of the service to alter the configurations settings of their handset when roaming, or to alter them back again when home.

It will be appreciated by those skilled in the art that proxies are generally well known and used to achieve various desired effects in data networks.

It will be appreciated by those skilled in the art that the fundamental mechanism by which proxies function, is that of emulating other network functions so that each element “appears” to be connected to its normal counterpart. The means by which traffic is routed to the proxy rather than to the intended network element function, are both well understood in the art.

Indeed, it is known to employ a GTP protocol based proxy inside a General Packet Radio Service (GPRS mobile data) network, between an SGSN and a GGSN. A specific example of such a proxy is Zhimei, Jiang; Li Fung, Chang; Kim, B.J.J.; Leung, K.K., Incorporating proxy services into wide area cellular IP networks, IEEE Wireless Communications and Networking Conference in 23-28 September 2000 in Chicago, published by IEEE, the entire contents of which are herein incorporated by reference. The benefits, amongst others that have been listed for such a proxy are identified as a) enhanced security, b) lower latency, c) easier access to network and user specific data within the network. Further use of specific GTP proxies for QoS (Quality of Service) management, including image compression for example, during congestion are also known in the art, for example Zhimei, Jiang; Leung, K.K., Link condition based proxies for QoS management in Wireless Networks, IEEE 2001, 07803-7244-0/01, the entire contents of which are herein incorporated by reference. Thus it will be understood that the present application is not the invention of a GTP proxy as such but rather the functions performed on data intercepted by the GTP proxy and the subsequent processing therof by such a proxy.

In the arrangement of the present application shown in Fig 2, the GTP proxy controls the detailed packet flow between the nodes, in particular the flow of control packets, in such a way that selected traffic is routed to the visited or other GGSN rather than the home GGSN. The proxy, in this arrangement of the application, also causes the data packet flow to be selectively routed via itself, so that the data access for selected cases can be monitored and measured, and charged if required.

The GTP protocol for both the control plane and the data plane, contains source and destination IP addresses for each leg of the protocol. The GTP proxy on receiving a setup message can reply with its own address as the destination, for either the control and date planes or for both. This causes the SGSN to route the packets appropriately.

The proxy additionally remembers the original destination address and can restore this address on the downstream leg.

In a further mode of operation, the proxy can manipulate parameters of the control stream setup messages and subsequently cause the control stream messages to be routed normally, thereby “backing out” of the subsequent dialog.

The advantage of this approach is that the proxy is not employed for all traffic.

In the arrangement shown in Fig 2, as an additional application, one of several techniques may be employed to discover when roamers are detected in the visited network.

This may, in one method, for example, be implemented by receiving a data feed from the home or transit networks indicating the roamers presence in the visited network.

This information is available from the home network as part of the normal mobility management function.

In one example, it may be obtained by monitoring the location update messages sent to the HLR (Home Location Register) from the visited network. The monitoring may be done in the home network or at a transit point between the home network and the visited network.

In another example, it can be obtained by monitoring the CDRs/EDRs (Call Detail Records/Event Detail Records) produced by the HLR.

In this latter case, the method may be used to detect that although a subscriber is roaming, they have not used roaming data services within a given time period.

This detection may be performed by a simple test, since no data context would have been established via the GTP proxy and so there would be no record of data having passed through the GTP proxy. It will be appreciated that the GTP proxy may store the data requests passing through it.

The detection that a subscriber is roaming and not using data may be used to selectively make offers and promotions to the subscriber to encourage them to avail of data roaming services, including for example free data roaming for initial periods, or sponsored data roaming where the data access is at least in-part paid by a third party. Such offers may be sent by SMS text message or other mechanism to the user.

A problem that may arise with the GTP proxy is that of charging records since the redirection of data has the potential to interfere with the existing charging processes implemented by the network operators.

The method of the present application provides a mechanism to facilitate existing mobile operator international data traffic reconciliation & billing processes.

The mechanism manipulates the ChargingID field in the GTP control signalling plane in the GTP proxy.

The manipulation acts to ensure that any data diverted to a Local Breakout data session does not generate charged TAP (Transferred Account Procedure) records and to allow the easy filtering of Visited GGSN or alternative GGSN CDRs or EDRs (Call Detail Records or Event Detail Records).

The GTP proxy performs the manipulation by reading in a particular Charging ID field in the data stream from the SGSN.

The read-in charging ID field is then altered to provide an altered Charging ID field which is present in the data stream sent to the GGSN. In this manner the corresponding records produced by the GGSN for subsequent charging and billing analysis can be separated out for specific treatment (for example treated as free because the access has already been charged by the proxy or marked as already prepaid).

The converse manipulation is done in the reverse direction.

Alternatively, the CDRs produced by the visited SGSN are not sent to the home network since they are identifiable (by the destination GGSN IP address) as belonging to sessions which have been routed elsewhere.

This characteristic is used, for example, to avoid potential multiple charging for the data access by the various parties involved (home, visited or alternative service provider).

The GTP proxy also has the facility to map other parameters in the GTP control stream to achieve several useful features.

For example, it is a standard feature of many GGSNs that several attributes of the traffic being routed to the internet are checked and validated before access is allowed.

As an example, it is common that only certain ranges of IMSl/MSISDN are allowed access, and that only particular APNs are allowed access.

It is a feature of the current invention that these fields may be mapped in both directions through the proxy to enable the local breakout access through the GGSN and for example also so that the roaming subscriber does not have to change the APN in the handset to avail of local breakout when roaming and also does not have to restore the original APN when back in the home network. In this way, whilst a phone employed by a user believes it is connecting through the home network APN, the proxy substitutes a local one. Similarly, the proxy can change the IMSI/MSISDN to ensure that a roaming user can get access through a local APN.

It is also a feature of the GTP protocol that the Quality of Service (QoS) obtained by a user of the network may be controlled by various fields which are set by the GGSN. It is a characteristic of the invention that the QoS fields can also be mapped by the proxy so as to achieve higher or lower QoS, depending on the nature of the access for which the subscriber has subscribed. In a typical example, this could be used to implement a “turbo boost” feature where the QoS would be increased for given time or a given quantum of access or where a higher QoS than normal would be guaranteed even in the event of congestion conditions.

The SGSN and GGSN negotiate the level of QoS to be applied to a session using GTP control plane signalling (GTP-C). The QoS level for a session is negotiated at the start of a session and may be changed by either party (SGSN or GGSN) during a session. At all times the GTP Proxy has visibility of the active QoS level for an open session and is consequently able to moderate session charging to reflect session QoS. The GTP Proxy can control the QoS level applied from the start of a session by overriding the QoS requested by the SGSN in the session setup signalling.

The GTP Proxy can change the QoS level at any point mid-session by injecting an appropriate GTP-C update request into the control path. Therefore, in addition to charging based on session QoS the GTP Proxy can also actively set session QoS to match subscription and/or service parameters.

An alternative arrangement of the application is shown in Figure 3, in which a GTP proxy is employed in a home network.

In this arrangement, the GTP proxy may be used within the home network to solve a variety of problems.

For example, to supplement the charging or data monitoring capabilities of the home network, where incompatibilities between the various equipment vendors implementation of the standards may result in inadequate real time data monetisation functionality.

A second example of this type of use, is where the GTP proxy is used to selectively route mobile data from enterprise customers, for example, to an alternative GGSN with particular characteristics more suited for this type of traffic.

The GTP proxy provides a mechanism to choose different routing paths for the control plane and the data plane of the GTP traffic, i.e. the GTP-c (control) & GTP-u (data) planes. This mechanism is the strategic changing of the source IP GSN addresses from the SGSN and GGSN IP addresses to the GTP proxy IP address.

The GTP proxy provides a mechanism to choose to route data sessions so that the GTP proxy remains in the traffic chain for a subset of the GTP control signalling (GTP-c) but remains outside of the traffic chain of the actual data packets (GTP-u). In order to remain in the control plane signalling path and step out of the data plane signalling path, the GTP proxy sets the source address for the control plane messages towards the SGSN/SGW to the GTP proxy IP address, and sets the source address for the data plane messages towards the SGSN to the GGSN address.

The method allows for the provision of data services to the subscriber via a set of data packages that may be offered to visiting roamers.

The GTP proxy provides a mechanism to issue the roamer with a free data package to allow the roamer the data access to subscribe to the data package.

The GTP proxy provides the ability to allow the subscriber to view available data packages, select a preferred data package and confirm purchase of the preferred data package.

This is achieved via a HTTP-REST API and also via the traditional telecommunications interaction methods of SMS & USSD.

The GTP proxy uses a subscriber database which contains a record of all roamers that have landed on the visited network, subscribed to a data roaming package, or interacted with the local breakout solution in any way in order to achieve the necessary business logic to achieve the data roaming service.

The GTP proxy optionally uses counters in the subscriber record on the subscriber database to count the data usage consumed by the subscriber per data package.

The GTP proxy can notify the subscriber when the subscriber reaches configurable usage thresholds, through counting the usage for different data types and by configuring thresholds on that usage. Examples of configurable notification settings include but are not limited to: 90% of data usage, 100% of data usage, etc.

The GTP proxy supports business logic governing the interaction with the subscriber and the actions taken once every subscriber related event occurs. This business logic is achieved through the combination of a subscriber database and a configurable set of subscriber states. See Figure 5 for an example of a set of business logic corresponding to this GTP proxy in the example of silent roamer detection.

The GTP proxy supports interaction with the subscriber through a range of subscriber touchpoints including but not limited to a restful API, SMS & USSD.

The notification options include but are not limited to an SMS via SMPP, a USSD dialogue, app notifications & push notifications. This timely ‘silent roamer’ notification is triggered through recognition of the location update event when the subscriber registers on the visited network, upon which the notification message or offer is selected for the subscriber based on a combination of inputs including but not limited to subscriber history, subscriber class, subscriber type, subscriber spend, data usage and subscriber location.

The GTP proxy integrates or forwards to one or more payment systems, including but not limited to Voucher Management Systems, PayPal, Stripe, Credit Card, OCS, BSS & In-App purchases to facilitate subscriber buy-in.

The GTP proxy has the ability to direct the subscriber through the subscription & payment process, via one of the following methods, including but not limited to instructional notifications, a smartphone app, website instructions & others.

A typical arrangement of the GTP proxy is shown in Fig.3, for the case of a GPRS cellular data network. The system consists of a receiving interface for receiving data packets and a transmission interface for onward transmission of the received data packets. It will be appreciated that these may integrated together. Low level software reads and writes UDP data from the GTP-U and GTP-C streams for data protocol and control protocol respectively (31,32 33 and 34) received at the receiving and transmitted from the transmission interface.

The data protocol packets are copied to the output stream, and also to a protocol analysis (or protocol stack) module 35, where the higher level protocols are analysed and decoded and the packet volumes classified according to the protocol class. This includes, for example, HTTP, WAP, SIP, RTSP and various other protocols whose use need to be monitored and optionally to be charged.

The GTP-C control protocol packets are handled by an GTP-C Control State Machine module 36, which implements the required protocol handling.

The GTP protocol supports the use of many distinct tunnels between any given endpoints. For example, there may be a separate tunnel for each active PDP context established by a user. The individual tunnels are identified in the control stream by a 32-bit number called a Tunnel Endpoint IDentifier (TEID_C)

This state machine suitably has an instance for each pair of control plane TElDc and handles the tunnels for both ends of the control connection (SGSN and GGSN end). A data array is stored for the TEID_C of each side, which contains details of the associated TEID_C on the other side and also of the remote TEID_C, the remote GSN address and the (IMSI) and other data associated with the connection (PDP address and APN for example).

This control structure allows a single state machine to handle the interworking of the control signals efficiently and is a characteristic of the GTP proxy.

An GTP-U control state machine handles the data tunnels, with a single instance of the state machine for a pair of data plane Tunnel Endpoint IDentifiers TEID_ds. A data array is stored which contains the TEID_d of each side and the TEID_C instance handling them, the remote TEID_d: the remote GSN address, the status of the data tunnel, the packet count and the octet count, etc. The GTP-U control state machine sends and receives UDP messages on the data port. It updates fields such as the packet count and the octet count and rewrites some fields in the message itself, forwarding the message to the destination.

The charge monitor 38 is a state machine which examines several rows in the TEID data array held in the shared data structure 30 on a regular basis and generates traffic reports based in the information in the table.

Traffic reports are communicated using a generic interface from the charge monitor to a Charge Handler interface 41. This implements the optional charging functions towards the home or visited networks, as appropriate, and uses input from a Rating function 42 which is configured with the data required to implement the operators desired rating scheme for data access.

It is also a characteristic that the GTP proxy can be used to implement charging for specialised data access protocols in any type of network, for example HTTP, WAP, RTSP, SIP, etc. This is achieved by incorporating a traffic classification function into the packet handling, so that the data volumes are reported by class.

In the context of charging, the proxy device may comprise a charging engine for implementing a data charging function on users of the mobile telephone network.

The charging engine is configured to interface with and co-operate with the analysis engine. The charging function may be based on monitoring of data usage performed by the analysis engine. In one mode of operation, a user attempting to establish a network data connection through a web browser on their mobile device may be directed to a specific website allowing them to create an account for using the data services enabled by the proxy or to continue with their existing arrangement with their own network operator.

Equally, the user may be provided with an option to “sign-in” where they have previously established an account.

As part of the set-up process, the user may establish their account with a third party payment system or a charging system (OCS) of the local mobile phone network. Once an account is set-up, the user is authorised to use the data services by the proxy device. To ensure payment is obtained, the proxy may interrogate the OCS or third party payment service as the user sends and receives data to ensure the usage can be paid for.

To reduce the volume of such requests, the proxy device may employ locally stored micro balances for individual users. Thus users are allowed to use the service provided as long as their local balance on the proxy is sufficiently high (i.e. the proxy reduces the balance as data is sent/received). If the balance falls below a threshold, for example 0, the proxy device may interrogate the OCS or third party payment service for approval. Where such approval is received, the micro-balance for a user may be reset. Where such an approval is not received, the proxy device is suitably configured to disconnect a user’s data session. Alternative conditions may also be employed to determine when to disconnect or permit a user’s data session. For example by reference to a data throughput reaching a quota (which may be an aggregate or window based value or both, or an access duration timer has expired.

An exemplary method of operation for a user engaging through the proxy device will now be explained with reference to Figure 5. The method commences with the user not being a user of the data service provided by the proxy, i.e. there is no entry for them in a database of subscribers associated with the proxy.

The method begins with a user establishing a connection to a roaming network for voice calls. As part of this a location update is fed back to the home network which is used as a trigger for the process on the proxy. A timer is started for the user. If the user does not send data within a pre-defined period of time, e.g. X may be 10 minutes, an offer is sent from the proxy or device associated with the proxy to the user informing them of the data service provided through the proxy. The system monitors for a response. If no response is received within a predefined second period, e.g. X may be 2 days in this instance, the offer may be resent.

If the user accepts the offer, they are allowed to either set-up an account or if available to authorise for the service to be billed to their network account. It will be appreciated that this may be implemented by sending the user a link in a message which when clicked on takes the user through the browser on their mobile device through the proxy to an associated website where the user can register and purchase a subscription in the form of a data package or plan as required. This may be a fixed amount of data, e.g. 1GB or may be for a fixed duration e.g. 24 hours, 1 week, 1 month a year etc. or may be a re-occurring charge.

Once the user has completed the process, the service on the proxy allows the user access to data services by routing their data to and from a local or regional breakout node. The analysis engine suitably continuously monitors the activities of users and may send the users notices regarding their data usage or sending a further offer to a user when their subscription has ended. It will be appreciated that this is merely one exemplary manner of operation and that several others will be facilitated by the proxy device of the present application.

Claims

Claims

1. A proxy device for positioning in a GTP data pathway in a mobile telephone network, the proxy device comprising:

a receiving interface for receiving data packets;

an analysis engine for analysing the data packets;

a transmission interface for onward transmission of the received data packets, wherein the analysis engine is employed for data usage monitoring, routing or charging purposes.
2. A proxy device according to claim 1, wherein the analysis engine is configured to redirect data packets intended for the GGSN of another network to a local node for connection to the Internet.
3. A proxy device according to claim 2, wherein the proxy device is configured to alter the address of data packets from a home mobile phone network APN of a roaming device on the network to a local APN of the mobile phone network.
4. A proxy device according to claim 2 or claim 3, wherein the proxy device is configured to map an IMSI and or MSISDN for a device roaming on the mobile telephone network to appear as an authorised device for a APN of the mobile telephone network.
5. A proxy device according to any preceding claim, wherein the proxy device further comprises a charging engine for implementing a data charging function on users of the mobile telephone network based on monitoring of data usage performed by the analysis engine.
6. A proxy device according to claim 5, wherein the charging engine is configured to interact with an internal OCS or to a third party payment system.
7. A proxy device according to claim 6, wherein the proxy device locally stores a micro balance for individual users.
8. A proxy device according to any one of claims 5 to 7, wherein the proxy device is configured to disconnect a user’s data session when a predetermined condition associated with the user is detected.
9. A proxy device according to claim 8, wherein the predetermined condition is one of the following:

a) an account balance of a user is zero;

b) a data throughput quota of a user has been reached;

c) an access duration timer has expired; or

d) other condition wherein the user’s account is required to be replenished/renewed.
11. A proxy device according to claim 8 or 9, wherein disconnecting a user’s session comprises redirecting it to a server configured to respond with a message with one or both of informing the user that the predetermined condition has been reached and allowing the user to replenish their account.
12. A proxy device according to any preceding claim, wherein the proxy is configured to alter the QoS being received by a device.
13. A proxy device according to claim 12, wherein the proxy alters the QoS for a user by at least redirecting some of the traffic for the user through an alternative node.
14. A proxy device according to claim 13, wherein the proxy is configured to charge for the QoS delivered to the end user
15. A proxy device according to any preceding claim, wherein the proxy device is configured to manipulate charging parameters in the GTP flow to suppress the generation of chargeable TAP records, suitably in a visited, transit or home network.
16. A proxy device according to any preceding claim, wherein the analysis engine is configured to detect the absence of a data session from an identified roaming data subscriber within a given time and in response to making such a detection being configured to message the identified user with an offer or promotion to encourage roaming data usage.

Intellectual

Property

Office

Application No: GB1622067.5 Examiner: Mr Daniel Davies