WO2012001366A2

WO2012001366A2 - Wlan location services

Info

Publication number: WO2012001366A2
Application number: PCT/GB2011/000993
Authority: WO
Inventors: Peter Paul Smyth; Andrew Robert John Cook
Original assignee: British Telecommunications Public Limited Company
Priority date: 2010-06-30
Filing date: 2011-06-30
Publication date: 2012-01-05
Also published as: WO2012001364A2; WO2012001364A3; WO2012001366A3

Abstract

A device tracking and proximity service system are described which determine respectively location and proximity information for communications devices located in one or more WLANs. The system comprises a monitoring system arranged to receive signalling data to enable a device presence to be senses within a WLAN which includes means for updating a data record for said device with location information for the device by accessing a series of data stores associated with network and service management. The monitoring system processes each data record when updated it to check if it includes one or more other device identifiers and if so, determines for each of said one or more other device identifiers a corresponding data record containing location information and processes the location information of each data record to determine proximity information between said sensed device and said one or more other devices.

Description

WLAN LOCATION SERVICES

The present invention relates to a method and system for providing wireless local area network (WLAN) location services and to related aspects. In particular, but not exclusively, the invention relates to a communications system providing a wireless network broadband access service in which a range of IP addresses is unique to each wireless network access point for assignment to roaming wireless communications devices. The invention further relates to a method and system for providing a location service to locate a device which has associated with a WLAN provided by a wireless access point whose location is known, examples of location services including device tracking and device proximity services to the device themselves and/or to third parties.

Many location-based services are known in the art, some of which rely on cellular communications technology providing location data, some of which use Global Positioning System (GPS) technology. Most services rely on a device being used at the time its location is to be fixed, for example, by a user explicitly activating an application on the device, so that GPS information is retrievable from the device for use by the service.

Many web-services are already known to provide information for particular localities which a user might seek to access. The parties providing such services can often provide locality- specific information or general information of interest to a user of a roaming device, i.e. the services can depend on or be modified by location information for the device requesting the service if the device location is determinable. Some services desire to broadcast or multicast information to devices known to be "roaming" devices as opposed to devices which are not "roaming" which are considered to be in their "home" or "native" WLAN. The term "roaming device" as used herein refers to a device which associates with a WLAN using credentials which are not associated with the broadband access line subscription connected to the wireless access point (AP) providing the WLAN. A "guest" or "visitor" device is also a "roaming" device. All such "roaming devices" roam into at least one WLAN whose credentials are not used to authorise the device for connection to the broadband service.

A stronger level of trust is increasingly in demand for web-based service transactions for roaming devices and the invention seeks to provide an alternative way of determining the location of a device.

The ability to monitor a plurality of devices to determine how many device are roaming in a number of privately-owned/operated WLANs, such as those provided by a digital subscriber line (DSL) based wireless network router and broadband AP (for example, apparatus such as British Telecommunications Home Hub™), presents additional challenges compared to the situation where a public-access point is owned directly by a service provider. For example, there is a greater statistical likelihood that access points may be moved as subscribers move the location of their service subscription (for example, due to moving house etc). It is known in the art for traffic from roaming (or equivalently, guest or visitor) devices which is directed to the core network via such APs to travel along a secure tunnel to a captive portal which blocks the traffic to prevent its further propagation into the network before a user login process to authenticate the use of the roaming service is completed. WO 2007/121331 entitled "Mobile computing device geographic location determination" describes a system in which after a mobile device has registered successfully with a network controller, geographic location information on the device is retrieved from a database by a service mobile location centre and provided to the network controller. The database stores information such as last known position, IP address, MAC address, a mobile or subscriber identifier, etc. The geographic information is then communicated back to the network controller which is configured to forward the position information onwards for processing (e.g. via a switch for emergency calls).

WO2009/006940 entitled "Unlicensed mobile access (UMA) terminal location in a communications network" describes a method of managing location information for an UMA terminal in a GSM (Global System for Mobile Communications) network in which an IP address for the UAM terminal is received at a generic access network controller. The generic network controller queries a connectivity session location and repository function associated with the IP network or IP sub-network via which the UMA terminal has gained IP connectivity for location information which can then be forwarded to a mobile switching centre or serving general packet radio system service node.

The embodiments of the invention seek to provide a location service which exploits the IP address assignment process implemented in the DSL environment of the WLANs and broadband subscriber data to provide location information. Known techniques in the art associate the MAC address of a wireless access point with its physical location and use this to provide a fix on its location. However, the data which is used to indicate the location of the wireless AP is collected in a very basic manner. For example, one technique uses WLAN detectors in vehicles which roam geographic areas to detect what WLANs are provided in which location. This is time-consuming and cumbersome and a limited number of access points in practice are detectable this way, as such street surveys only detect WLAN offered by access points within the range of the detecting device, which may be limited to areas in close proximity to public rights of way. Moreover, should an access point be moved, the information becomes inaccurate, without any ability to determine that the information already stored is no-longer accurate. Services which use location inaccurate or out of date information unknowingly result in problems ranging from being irritating to being unusable, and where emergency VoIP calls are being made using a roaming access WLAN, the results may be fatal if the emergency service response is sent to the wrong location.

SUMMARY STATEMENTS OF INVENTION

The aspects and preferred embodiments of the invention are as set out below and in the accompanying claims, and may be suitably combined in any appropriate manner apparent to one of ordinary skill in the art.

One aspect of the invention comprises a method of tracking a wireless communications-enabled device across a plurality of wireless communication networks, the method comprising:

sensing said device on one of said wireless communication networks;

determining a device identifier and assigning IP address for said sensed device from information provided by said sensing of said device;

updating a data record in a remote data store associated with said device identifier with a current location information instance for the sensed device;

processing the location information for said data record to determine device tracking information from a current location information instance for said sensed device and at least one previous location information instance for said sensed device;

wherein each of said current and previous location information instances for said device is derivable by mapping an IP address assigned to said device to a range of IP addresses for assignment to communications-enabled devices by an access point, said assignable IP address range being uniquely associated with an access point which sensed the device on a said wireless communications network provided by said access point, wherein said access point is configured to provide broadband connectivity over an access network to sensed devices, wherein location information is derivable from an address for service for a broad band service providing each said access point with said broadband connectivity over said access network.

One aspect of the invention relates to a method of tracking a wireless communications-enabled device across a plurality of WLANs, the method comprising:

sensing a device on a WLAN;

determining a device identifier for said WLAN;

updating a data record associated with said device identifier with location information for the device;

processing the location information of each data record to determine from said current location history information for said sensed device and previous location information for said sensed device, tracking information;

wherein said current and previous location information is derived by mapping a private IP address to a range of IP addresses uniquely associated with each access point providing one of said plurality of wireless WLANs , said unique association enabling the address for service for said wireless broadband access point enabling the location of a device attached to said WLAN to be determined and tracked from WLAN to WLAN.

The tracking information may comprise directional information for the movement of said device. The tracking information comprises a movement speed for said device, which with the directional information can provide velocity and acceleration information.

The tracking method may further provide a method of determining proximity information for communications devices located in one or more WLANs comprising: sensing a device on a WLAN; updating a data record for said device with location information for the device; determining said data record includes one or more other device identifiers; determining for each one or more other device identifiers a corresponding data record containing location information; processing the location information of each data record to determine proximity information between said sensed device and said one or more other devices.

Another aspect of the invention comprises a communications system arranged to enable the location of a mobile communications-enabled device in each of a plurality of open-access short-range wireless communications local area networks to be tracked in real-time, the system comprising:

means to verify the location of each said wireless access point providing a said open-access wireless local communications area network used by said device;

means to allocate an IP address to said device when it associates with each said wireless access point; and

means to determine from each allocated address, in real-time the wireless access point the device has most recently associated with, and

means to associate the device with the verified locations of each of said plurality of wireless access points.

The plurality of verified locations may be stored sequentially in a time-order associated with the time at which the most recent address is allocated. The plurality of verified locations may be stored in association with time-stamp information recording when said location is determined.

The plurality of verified locations may be stored in association with a time-stamp indicating when a said IP address location was allocated.

The plurality of verified locations may be stored in association with a time-stamp indicating when a said IP address location was last verified. The system may further comprise:

means to determine from the allocated address, if said allocated address is within the range of addresses which are allocated to said access point, and if so, to determine from a device identifier for the access point (14), the location of the access point.

The location of the access point may be verified each time the access point renegotiates its connectivity over an access network with an access server.

The location may be verified by determining if the DSLAM port used by the connection over which said connectivity request is sent to the access server is associated with the same service identifier stored in a data store accessible by said access server in association with said device identifier for said access point.

The access point 14 may include or have access to digital subscriber line modem functionality.

The access point may include or have access to functionality enabling it to transmit data over an optical network.

Another aspect of the invention comprises a method of tracking the location of a mobile communications-enabled device (16) in each of a plurality of open-access short-range wireless communications local area networks (12) in real-time, the method comprising: allocating an IP address to said device when it associates with each said wireless access point; and

determining from each allocated address, in real-time the wireless access point the device has most recently associated with, and associating with the device with the verified locations of each of said the wireless access points.

Another aspect of the invention seeks to provide a method of determining proximity information for communications devices located in one or more WLANs comprising: sensing a device on a WLAN; updating a data record for said device with location information for the device; determining said data record includes one or more other device identifiers; determining for each one or more other device identifiers a corresponding data record containing location information; processing the location information of each data record to determine proximity information between said sensed device and said one or more other devices.

The sensed device may comprise a roaming device. The proximity information may be sensed prior to the roaming device being authenticated to use a roaming service offered by said WLAN to access the internet.

The data record for said sensed device may include in association with each other device identifier provided an associated proximity alert condition and where an alert condition is provided, if said proximity information meets said proximity alert condition, the method may further comprise an alert being generated by said monitoring system.

The alert may be sent to one or more or all of said devices identified in said sensed data record.

Another aspect of the invention seeks to provide a method of providing proximity location information according to one embodiment of the invention which comprises: storing device presence information indicating the presence of a plurality of devices in a plurality of wireless local area networks, each device having a data record indicating for said respective device a device presence in one or more of said wireless local area networks, each data record being associated with a device identifier; storing in each said data record as device location information an address for service of an access network connection service used by an access point providing each wireless local area network the device has a presence in; using proximity search identifiers extracted from a received service request sent by an authenticated device to determine one or more other device identifiers; determining a data record for said authenticated device; using said one or more other device identifiers to find respective data records for each corresponding device; processing the location information of said authenticated device and the location of one or more other device locations to determine proximity distance information between said authenticated device and said one or more other devices; sending said proximity distance information for each said corresponding device to said authenticated device, wherein each said device's presence information is generated prior to said device being authenticated to use a communications link provided by said access network connection service, and wherein said proximity search identifier used to search for said data record comprises one or more of the following: a public IP source address for said authenticated device included in said service request, and/or a device identifier for said authenticated device included in said service request.

One aspect of the invention seeks to provide a system for determining proximity information for communications devices located in one or more WLANs, the system comprising: means for sensing a device on a WLAN; means for updating a data record for said device with location information for the device; means for determining said data record includes one or more other device identifiers; means for determining for each one or more other device identifiers a corresponding data record containing location information; and means for processing the location information of each data record to determine proximity information between said sensed device and said one or more other devices. The location of each said device stored in a said data record may be determined from the location of the wireless network access point providing the wireless local area network.

The device may be sensed before said wireless local area network is used to provide said device with wireless internet connectivity.

Embodiments of the drawings will now be described with reference to the accompanying drawings in which Figure 1 shows schematically an exemplary street environment comprising a plurality of WLAN communications systems for which WLAN location services are provided according to embodiments of the invention;

Figure 2 shows schematically elements in a WLAN system as shown in Figure 1 and elements in an access network architecture providing broadband connectivity for the WLAN communication;

Figure 3 shows schematically how data flows between elements of an access network communications system when an AP seeks to establish a connection request over the access network;

Figures 4A and 4B comprise flow diagrams showing some of the data flows which are generated when an AP seeks to establish a connection request over an access network; Figure 5 shows the network architecture of a communications system in which a WLAN device location information service is provided according to an embodiment of the invention;

Figures 6A, 6B, and 6C show alternative address assignment schemes which an AP can implement to assign an IP address to a roaming device;

Figures 7A, 7B, and 7C are flow diagrams showing how information is initially collected for providing WLAN location services according to three embodiments of the invention; Figure 8 shows how post-authentication traffic is made available for providing WLAN location services according to an embodiment of the invention;

Figures 9A, 9B, and 9C show schematically the different types of traffic initially and subsequently used for providing WLAN location services in three different embodiments of the invention which use the address assignment schemes shown in Figures 6A,B,C respectively;

Figures 10A, 10B, and 10C show steps in a method of generating WLAN location information using data collected by a monitoring system to provide WLAN location services according to the corresponding embodiments of the invention shown in Figures 9A,B,C;

Figures 11 A and 11 B show schematically a central monitoring system according to embodiments of the invention;

Figure 12 shows a hierarchical monitoring system for a large geographic area;

Figure 13 shows a device WLAN location services system according to an embodiment of the invention;

Figure 14A shows a device communicating with a location service requesting platform according to an embodiment of the invention;

Figure 14B shows how NAT affects the provision of a device location service to the service requesting platform of Figure 14A; Figures 15A and 15B shows steps respectively performed by a service requesting platform and a location services system in an embodiment of a device WLAN location information service according to the invention; Figures 16A.B, and C show exemplary proximity scenarios between devices in WLAN networks for which proximity information can be generating using a method of determining proximity information according to an embodiment of the invention; and Figures 17A and B show steps in two methods of determining proximity information according to embodiments of the invention.

The best mode of the invention will now be described with reference to the accompanying drawings. In the following description of the preferred embodiments of the invention, those of ordinary skill in the art will be aware of modifications and functional equivalents to those features of the invention which are described herein below. Certain features of the invention may be omitted from the description for the sake of brevity and clarity where their inclusion and function as part of the invention would be apparent and known to those of ordinary skill in the art.

Figure 1 of the accompanying drawings shows schematically a communications system 10 comprising a plurality of short-range wireless local area networks (WLANs), for which five are shown in this exemplary embodiment. Each WLAN 12a,..12e is provided by a respective wireless access points APs 14. Each AP 14 is located within a subscriber's residence, and a plurality of residential premises are schematically shown in Figure 1. Each of the APs 14a, ...,e is configured to provide an open-access wireless communications network service to roaming communications-enabled devices, one of which, roaming device 16 is shown at a plurality of locations A, B, and C in communications system 10. The WLANs 12 may cover separate or overlapping areas of network coverage. Each AP 14 is also configure to provide a secure WLAN (also referred to herein as a "home" WLAN) to devices which are authenticated to use the home WLAN. Each WLAN thus provides two different networks which use two different SSIDs for identification purposes, and whilst each home or roaming device will normally be able to detect both types of SSID when within range, it will only be able to associated with one network SSID, either as a home or roaming user.

As the wireless APs 14 shown in Figure 1 are configured to provide WLANs 12 which support both home WLAN services and roaming WLANs, the APs provides a network roaming service which supports usage of the roaming network by roaming devices. The term "roaming" device refers here to any device using a roaming service, which includes devices which can maintain a connection when moving between WLANs as well as to devices which connect only within any given single WLAN as a "guest" or roaming user. As such, the term "roaming device" refers to a device using a different set of WLAN connection credentials from that of the "home" user's devices (which, for example, can use a set of credentials to utilise a private WLAN connection). However, a "roaming device" can be physically located within its "home" LAN but this will be treated as a "roaming device" if it has associated instead with the "roaming" service public WLAN and not the private WLAN that the AP is also configured to provide.

Each access point 14a, ...,e is configured to use a Digital Subscriber Line DSL-type of communications link 18a e, for example by integrating or being connected to an appropriate

DSL modem type. The identifier for each AP 14 is associated physically with the modem component of the AP 14, i.e., the identifier may comprise or be derivable from the modem MAC address as an example. In Figure 1 , DSL-type communications links 18 from each AP 14 share a common access line over public access network 20 to the Digital Subscriber Line Access Multiplexer (typically this is located at the nearest line aggregation point such as the local exchange). If an optical line or another suitable form of communications infrastructure is available for use by the AP 14, the AP 14 is provided with alternative modem type functionality to use an appropriate communication protocol to enable access to the nearest digital exchange using the access link 18. The access points (AP) 14 shown in Figure 1 are moveable in the sense that the subscriber access line 18 they are connected to can be changed if a service subscriber re-locates AP 14 to different premises and migrates their broadband access service accordingly. The environment shown in Figure 1 uses a communications system 10 which is configured to collate and provide information on the location of communications-enabled devices 16 using one or more of the plurality of short-range WLAN networks 12a,b,c,d,e,f in a guest context for accessing access network 20 via which web-services such as the internet (or any other accessible network supporting any other suitable network service). Each device 16 performs "roaming" when it is within the service domain of a WLAN requiring different authentication from the WLAN whose authentication is configured as its "home" WLAN. The "roaming" service in some embodiments supports a formal "handover" between the roamed in networks, but it is possible that in other embodiments session continuity between WLANs may not be supported in which case the location service itself is not persistent. The residential environment WLANs 12 shown in Figure 1 are unlikely to exceed an area of 100 m² but the system can be scaled to provide location services on a national or even international scale. Figure 1 shall be described in more detail later herein below.

The network infrastructure of the invention enables the collation of information from a plurality of data stores associated with telecommunications services. The data stores are associated with different control domains and/or services and access is constrained by the inherent data collection techniques used to populate each data store, which results in differing data record structures being searchable using a plurality of different search indices. This enables the physical location of an AP using a broadband connection (for example, such as that provided by a digital subscriber line (DSL) modem) to be determined with close to real-time levels of responsiveness to location queries received by a location services platform (see Figure 11 B) remotely located within the network. The invention enables a suitably rapid response to location queries supporting the provision of such service to mobile devices.

The network infrastructure shown in the accompanying drawings supports mobile devices 16 using any one of the WLANs 12 to gain connectivity over a DSL access line 18 to the internet and have dynamically assigned IP addresses. The selection process for determining which one of a plurality of WLANs available to a device is the WLAN the device attaches comprises any suitable process known to a person of ordinary skill in the art, e.g. the WLAN with the strongest or most stable signal is often the WLAN selected.

Each AP 14 providing a roaming access (or equivalently guest access) WLAN 12 is capable of supporting a predetermined number of devices 16 and assigns each device an IP address allocated from within a range of IP addresses. The range of IP addresses for assignment to devices 16 which roam into each such WLAN 12 is pre-determined for each WLAN AP 14. Each IP address is dynamically assigned to a roaming device 16, however, the dynamic address assigned to a device 16 is one which is allocated in dependence on the static and unique IP address assigned to each AP 14.

Traffic generated by the device initially indicates the private DSL IP address in the DSL addressing domain, however, if the destination address lies outside the private addressing domain, as the traffic traverses one or more Network Address Translation servers (not shown) it is translated into a public IP address. Thus, when a roaming device requests a web-service from a server located outside the private IP address domain, any location services must initially use a public IP address for a device which will have undergone NAT translation, and possibly Port Address Translation as well.

The invention seeks to a location service in which location information can be provided either directly to the device or indirect to the device via a web-service from which the device has requested information. Web-services may include mobile advertising, travel and tourist information services and the like, and any location and presence-based or modifiable services. For example, a web-service which use information indicating the number of devices within a WLAN are provided in one embodiment of the invention. Such web-services may be used to provide crowd control as the density of users within a predetermined number of WLAN areas of network coverage can be derived from this information. Another embodiment of a web-service benefiting from the invention comprises one which indicates the number of devices headed in a particular direction. This type of information and facilitates crowd-control and allows public services to ease congestion after mass-participation events. Another web-service locates devices (for example, people via their known use and association with a device). Such web- services may be provided, for example, to persons who have eatable devices and yet who are not capable of determining or who are unable to determine their own whereabouts.

Thus in a communications system according to an embodiment of the invention, a device location is determined based on the physical location of the network access point (14) which assigned the device (16) a service address, for example, an Internet Protocol service address. As the device 16 moves from the WLAN service area supported by one network access point 4 to the WLAN service area supported by another network access point 14, the IP service address assigned in each WLAN area is taken from a unique predetermined range of IP addresses assignable to devices in that WLAN. By determining which IP address range an IP address falls within, it is possible to determine the AP 4 associated with the IP address range. Once the AP 14 is known (usually by means of a particular access point identifier for the AP being retrieved), the address for service for that AP can be determined. The address for service for that AP is determined by performing a look-up operation for the address for service associated with that access point identifier, which enables the device location to be determined, although any other suitable process for retrieving the address for service could be used. The information on the address for service and the public IP address is then collated using a monitoring system to generate a suitable data record for subsequent use in providing location services in the communications network 10.

The location monitoring provides location information indicating a particular device's location and/or movement to a location-service requesting platform or directly to the requesting device. An example of a location-service requesting platform is a web-server to which the device 16 whose location is to be determined has sent a connection-request.

In packet-based communications networks such as those which carry internet protocol (IP) traffic, to enable more devices to make efficient use of the IP addressing scheme network address translation (NAT) is applied within the communications networks. NAT partitions the addressing domains, so that whilst an IP address will always resolve uniquely within any one addressing domain, reuse of the same IP address is possible in different domains. This creates an inherent problem when trying to resolve a packets IP address to a particular source, as the source IP address is not directly determinable if any NAT has occurred. Port Address Translation (PAT) may also need to be addressed when a device establishes a data flow with a remote data server. PAT involves a single or small block of IP addresses being shared across lots of clients and is used by some networks in overload conditions and by others on a permanent basis. PAT presents similar problems to NAT where used.

Within the access network 18 of communications system 10, each AP 14 is allocated a unique IP address range which enables each AP to be identifiable as the AP which has assigned a particular IP address to a roaming device by mapping a given IP address to a particular IP address range.

Telecommunications networks collate data on a massive scale to enable appropriate authentication, authorisation, and accounting functionalities to be performed directly for their own clients and for other service providers who use the telecommunications network infrastructure. Whilst wireless communications networks collate data differently due to the mobility of the devices using the network and services provided over the wireless communications network infrastructure from fixed line networks. Both types of network are often configured to perform a monitoring service which enables data collection and/or data interception to occur when communications take using that network's infrastructure. Communications network monitoring systems are often configured to either monitor the content of a communication (i.e., the information exchanged in a communications call) and/or monitor the quality of service provided when the communication takes place.

As mentioned above and described in more detail below, the invention provides a location service using the location of the current network access point 14 (which assigned a location service requesting device 16 its address for service) as a proxy location for the service requesting device 16 when it is located within a WLAN 12 provided by the network access point 14. Typically such a WLAN 2 is one which is capable of providing connectivity over an access network 18 to a plurality of devices (i.e., to both roaming and home devices). The location is determined to within the range of such a WLAN - typically such WLANs use short range communications protocols such as 802.11 (WiFi) or 802.16 (WiMax). Thus each network access point 14 provides a limited number of guest access (or roaming) devices with network connectivity within a surrounding area of up to approximately 100 sq m.

The location provided is reliable to the extent that whilst APs can be mobile (for example, a service subscriber may reuse an access point when they move to different premises), each time an access point renegotiates a connection over the access network the ServicelD of the AP is verified as consistent with the address for service stored in the network in association with that ServicelD and an identifier for the AP (e.g. the AP's media access control (MAC) address).

As mentioned briefly before, traffic from a "roaming" device is distinguished from the traffic generated by a "home network" device. Firstly, the credentials of the service subscriber of the access network connection used by a particular AP are different if the network is a "home network". Secondly, all traffic generated by roaming devices is sent over a secure connection separately from the connection used by traffic generated by devices which use the credentials of the service subscriber to authenticate their access. A secure connection may be provided by using a secure tunnel for example, an IPSEC tunnel, from the AP 12 to a suitable platform 25 (see Figure 5) arranged to terminate what is effectively a virtual private network (e.g. a VPN node) between the AP 14 and the platform 25 within the communications system 10. All traffic originating from any roaming device 16 passes through the secure tunnel, including (and as mentioned above) signalling traffic which is generated prior to the device 16 seeking to use the WLAN 12 for accessing the internet and/or prior to any user authentication. If more than one device 16 is roaming in the same WLAN 12 the secure tunnel is shared to provide access to both devices 16. If the traffic is authentication traffic it is forwarded to an appropriate authentication platform 42 using the secure communications link and, until use of the connection service by the roaming device 16 has been authorised, non-authentication traffic is blocked at this point so that it does not propagate further in the network.

Accordingly, a location service system according to the invention is arranged, even prior to any authentication and/or authorisation for use of a roaming service by a device, to propagate any traffic generated by the device to a monitoring system which enables the device location information to be retrieved/generated and stored by the monitoring system in form suitable for providing to third parties. The type of traffic generated prior to authentication is mostly signalling associated with the AP 14 seeking to allocated/reserve an IP address for the device 16 in its network. The type of traffic will still use the secure tunnel and so will still be intercepted at the termination point of the VPN. The monitoring system which receives this traffic processes it to extract information extracted about the device and the wireless access point being used, although it may need to wait until authentication is requested to capture user credentials for the device. From this information, it is possible to determine the geographic location of a particular wireless access point, from this the location of the device, and hence the presumed location of a user of the device. The details of the device and/or user identifiers which are collected via the monitoring system may be encrypted for data protection before being appropriately stored. The stored data can include in addition information enabling the identification of relevant third parties, such as internet service providers, which is collected as ServicelDs along with any traffic.

Even if a WLAN is provided by an AP which has relocated to use a different access network connection, as the AP establishes its connection over the new access link the new address for service is updated to associate this with the ServicelD the AP is using. The ServicelD associated with a DSL connection, for example, is determined by the DSLAM ports via which the AP has established an initial layer 2 point to point connection with an access server for communicating its authentication credentials to the network. In this way, the network operator can be made aware of such a move when the AP powers up or for some other reason negotiates a DSL session over the access network and can store this information in an appropriate data store which associates an appropriate identifier for the AP and/or the ServicelD for the access network connection service an AP uses with an address for service (AoS) providing location information. This provides a means of more accurately tracking devices through their association with such APs in real time within such communications systems.

Residential scale wireless LANs are often provided by wireless access points which use either integrated or separate access network connectivity devices, such as cable, optical or copper- network modem type devices. Broadband connectivity bandwidth is provided by the latter type of device establishing some sort of DSL type of connection to the local exchange. The term "wireless access points" or "access points"(APs) is used herein to refer to both the WLAN AP device and to the network connectivity component alike, regardless of whether both functionalities are implemented by the same platform or by different devices suitably connected.

The BT Home Hub™ is an example of an access point providing a WLAN offering guest or roaming access to roaming devices which have WLAN connectivity capabilities. The Home Hub™ is an example of a type of open WLAN access point which provides a separate network SSID for usage of WLAN by devices which are not associated with the service credentials of the service subscriber whose access point is providing the guest access. The BT FON™ service is an example of a WLAN service which enables device roaming in WLANs provided that the roaming device is associated with a service subscriber account which has configured its own WLAN to provide such a service other subscriber's devices and/or for payment if not. The traffic streams from subscriber devices using the "private" subscriber SSID network and traffic streams from guest devices which use a different SSID are separated into two paths which enable usage by devices which are associated with the subscriber's credentials to be separated from devices which are not.

Returning now again to the accompanying drawings, more details of the remaining figures will be provided to illustrate the various embodiments of the invention.

Figure 2 shows schematically the network coverage provided by WLANS 12at each of the locations A, B, and C shown in Figure 1. In Figure 2, when a roaming device 16 is at location A, it receives a plurality of network beacons from WLANs 12a,b,c. As shown in Figure 2, WLANs 12a,b,c all use the same service set identifier SSID#1 as they each provide the same roaming service. Each WLAN 12a, b,c, is provided by a respective access point 14a, b,c. At location B, the device receives beacons from the wireless network 12d (as shown also using service set identifier #1 as this WLAN also provides the same roaming service as WLAN 12a,b,c provide). At location C the roaming device 16 receives beacons from another wireless network 12e with service set identifier #1 as this is again a roaming service. The Service Set Identifier ("SSID#1") identifies a wireless network as one providing open-access to appropriately configured wireless communications-enabled devices on a "roaming" or guest user basis. Figure 2 does not show any private home networks from which device 16 may also be able to receive beacons from which would also have different SSIDs. Also, in alternative embodiments of the invention, it is possible for one or more roaming networks to have different SSIDs. As shown in Figure 2, each of the open-access networks 12a,...,e provides connectivity to one or more remote networks for roaming device 16 using a digital subscriber line (DSL) communications link 18 over the public access network 20. The DSL communications links 18 are aggregated at a suitable link-access device providing an aggregation point for multiple subscriber lines, for example, at the DSLAM 22 at the local exchange. DSLAM 22 aggregates data traffic from a plurality of subscribers for forwarding to a switch or router over a suitable multiplexed connection using a communications protocol such as, for example, Frame Relay, ATM, or Ethernet to a remote access server (RAS) 24.

AP Connectivity Configuration

Referring now to Figure 3 of the accompanying drawings, RAS 24 is configured to act as the logical network termination point when an access point 14 seeks to establish or re-establish its connectivity over the access network 20. To achieve connectivity, AP 14 is configured to establish a layer 2 connection via DSLAM 22 with RAS 24. Each DSL broadband connection to DSLAM 22 over the access network 20 (as shown in Figure 3, the DSL line into DSLAM port 26a) is associated with a ServicelD. The AP is connected via DSLAM port 26b to RAS 24. Each service subscriber's service identifier (ServicelD) functions as a broadband calling line identifier for the access link 18 which connects that subscriber's AP 14 (as this provides the functionality which supports both the WLAN and DSL modem broadband connection). The ServicelD for the broadband connection that AP 14 uses is the same ServicelD for the broadband connection if just the DSL modem used when no WLAN is being provided indicates which particular internet service providers communications service the AP 14 is configured to use, i.e., it indicates the service provider of the broadband service used by the AP 14.

The RAS 24 is arranged to verify that the correct DSLAM port is being used by a connection to AP 14 by verifying if the ServicelD associated with the port has a termination location which matches the address for service associated with the identity (the APID) of the AP 14 which is trying to re-establish its connectivity, for example, the MAC address of the AP. This requires RAS 24 to access an address for service (AoS) data store 30 using the provided ServicelD to determine if its AoS matches the AoS of the connection at the DSLAM 22. The AoS database 30 maps the Service ID for the service provided over each physical line connected to the DSLAM 22 to the physical address of the network termination point of that physical line (i.e., the ServicelD indicates the service subscriber's address from which the access link 18 is provisioned to the DSLAM 22). In this way, the RAS is able to associate the ServicelD used by an AP 14 with geographic address information, such as a street and premises number. The data stored in AoS database 30 is accessible to monitoring system 40 shown in Figure 5 (and also in Figure 13) using a suitably configured interface mechanism which enables a look-up to be performed based on a ServicelD sent in a look-up request, which enables the monitoring system to retrieve location information.

In order for AP 14 to form a connection via which communications with remote networks can be established, the AP 14 must be authenticated for use of its communication service provider's communications network services. To achieve this, RAS 24 functions as a client to an authentication system 28 for service providers, such as one which is implemented using what is known in the art as an AAA server system which implements Authentication, Authorisation, and Accounting functionality. An exemplary AAA server system known in the art comprises uses the Remote Authentication Dial-In User Service (RADIUS) communications server protocol. Such a server system is shown in Figure 3 as AAA server 28 (also shown in Figure 4 as RADIUS server 28). RADIUS is a networking protocol which provides centralised authentication, authorisation, and accounting management functionality to enable remote clients, e.g., computers or mobile communications devices and computers, such as communications device 16, to connect to and use a communications network service.. The RAS 24 is also be referred to in the art as a Network Access Device (NAD), a Network Access Server (NAS), or a Broadband RAS (B-RAS, BRAS, or BBRAS). In the context of this invention a RADIUS server may also function as a virtual private network (VPN) termination point for communications traffic generated by roaming devices using a open guest access wireless LAN AP 14 provides in addition to the private subscriber WLAN it supports.

As shown in Figure 3, AAA (or equivalently RADIUS) server 28 is configured to authenticate connection requests forwarded by RAS 24 received from AP 14 over a suitable layer 2 connection, for example, PPPoE. As shown later in the embodiment of the invention described later herein with reference to Figure 5, the RADIUS server 28 is configured to query a central DHCP server to assign an IP address to the AP 14. The IP address assigned is then stored in a local or remote AP IP & ServicelD data store 32 with the ServicelD which the RAS server 24 has forwarded with the AP's access request.

Any suitable data structure may be used by the invention to associate the unique IP address range allocated for use by devices using the AP 14. Depending on how it is configured, the data structure may form part of a record in a new data store (e.g. a data base or look-up table). Alternatively, this information may be stored in a modified version of a data structure in an existing data store, such as by modifying a data record in a data store such as 32 (or even 30) to enable this information to be stored here in association with the AP ID. As such, data can be stored in dedicated data storage platforms arranged in a monolithic or distributed system (and may include duplicate sites (mirror sites) to facilitate data retrieval). Data may be stored in any suitable data record form known to those of ordinary skill in the art, especial forms which are optimised for high-speed data retrieval operations from large data sets.

As shown in Figure 3, the data records which store the AP ID and ServicelD information are stored in data store 32 and are thus separate from the data records held in the data store 30 which holds address for service records enabling the ServicelD to be authenticated using the credentials the AP has provided. These credentials are forwarded by the RAS 24 and include, for example, a username and /or password for the subscription broadband service the AP is using. However, it is possible for a larger database to be generated with data records which include data extracted from these data stores, and the data stores even if different logical structures, can be supported by the same platform. In each case, however, a ServicelD searchable record is generated which is updated by the RADIUS server to show the most recently verified DSL IP address assigned to the AP 14. The DSL IP address is assigned directly by the RADIUS server to the AP 14. If, however, the IP address has already been assigned by the RAS 24 and included in the connection request forwarded, then the RADIUS server updates AP IP & ServicelD data store 32 with this IP address. The RADIUS is then configured to forward this information to the DHCP server 38 (shown in Figure 4).

Figures 4a and 4b show schematically the signalling and message flows which enable AP 14 to establish a connection over the network over which communications can be established with remote networks using the communications service provided by the AP 14's service provider.

In Figure 4a, the AP 14 is configured to send a connection request to the RAS 24 via DSLAM 22 after a suitable triggering event has occurred (for example, such as on power-up of the AP or whenever AP 14 needs to re-establish its DSL connection over access network link 18).

At this point the AP 14 is allocated an IP address for use in the DSL network by the RAS 24 querying a DHCP server as described hereinabove. At this point, location information is generated comprising the physical line location associated with the address for service of the subscriber ID provided by the AP 14 which is stored in association with the DSL IP address allocated to the AP 14.

Whenever an AP 14 is authenticated by AAA server 28 for establishing connections over a particular broadband access line, RAS 24 is configured to automatically update the location information for AP 14. In this way, should a customer move their AP 14 to another broadband access line in a different location, when the AP powers-up and seeks to re-establish a connection over the new broadband access line, the RAS will receive the most recent and verified address for service associated with the service ID that the AP provides for authentication purposes to use the new broadband service. Accordingly, the location service system provided by the embodiments of the invention is able to locate changes of address for APs 14 in a timely manner. If an AP 14 moves location, the AP 14 has to re-establish its connection to the DSLAM at the new location before it can be used, accordingly, the address associated with the AP 14 for location services purpose is a current address which has been "verified" using the service ID address for service over the broadband access line the AP 13 is currently using.

AP Address Verification Returning now to Figures 4A and 4B of the accompanying drawings the address verification process for the AP 14 will now be described in more detail.

As shown in Figure 4a, on power-up, or following disconnection, AP 14 establishes (or reestablishes) a suitable layer 2 point-to-point connection with the RAS 24. After re-connecting to RAS 24, AP 14 negotiates access and establishes connection information and service credentials. These processes provide information, such as, for example, the DSLAM port number the request was received from, a service subscriber "username" and "password" for the service connection used, and a Service Identifier (ServicelD) for the service connection the AP 14 has been configured to use. The ServicelD the AP 14 uses should correspond to the ServicelD associated with DSLAM port used if the AP 14 has not changed its location since it was provisioned for providing DSL connectivity at a particular address. If there is any difference, the AP 14 will not be authenticated as if the ServicelD from the DSLAM port 26b is forwarded by RAS 24, it will not be accompanied by the correct service credentials which the AP 14 provides. The RAS 24 forwards information such as relevant connection information and service credentials including the ServicelD in an authentication request which is sent to the RADIUS server 28 so that a suitable IP address can be allocated to the AP 14.

The RADIUS server 28 performs a lookup operation using the ServicelD information on a local or remote RADIUS authentication database 32. The RADIUS server 28 verifies using the service credentials provided by the AP 14 via RAS 24 that the subscriber's username and password are valid, and may perform other security functions on the authentication request. If the RADIUS server 28 locates the servicelD in datastore 32 and the credentials provided in the RADIUS request provided show the AP 14 is authenticated to use that ServicelD. Turning at this point to Figure 4B, the RADIUS server 28 returns an access acceptance message and the DSL IP address it has allocated to the AP 14 with the return path being via the RAS 24. The IP address may be assigned using any suitable assignment process. The AP 14 is pre-configured with a unique range of roaming device allocable IP addresses and incorporates a local DHCP type functionality. However, it is possible that when the IP address is assigned to the IP, a unique IP address range is assigned by the DHCP server. The unique IP address range with which the AP 14 is associated is stored in communications system 10 in range data store 36 in association with the APID used by the AP 14. If, the AP is configured to use remote DHCP for device IP address assignment, then the AP generates a DHCP query whenever it needs to allocate an IP address to a device 16 which is sent to the remote DHCP server 38, which then allocates an IP address from the unique IP address range associated with that AP 14.

After an AP 14 has been successfully authenticated, RADIUS server 28 updates the AP IP address & ServicelD data store 32 record for that AP ID with the assigned IP address for the AP and the ServicelD for that AP 14 and the RADIUS server 28 returns the assigned IP address to the AP 14. If, however, a servicelD is not authorised for use by a given AP 14 by the RADIUS server 28, i.e., if the authentication or authorisation process fails, the RADIUS server 28 rejects the request and returns an access rejection message and the RAS 24 then closes or refuses the connection request from AP 14 based on the response from the RADIUS server. The RADIUS server 28 may also return other list information from the same AP data record associated with that service identifier, such as for example, the subscriber's authorization and/or connection parameters to the RAS if this is also requested. A RAS 24 may also generate usage and accounting data which may be forwarded by the RAS 24 to the RADIUS server 28, which in turn may store or forward the data it receives to AoS data store 30 support billing for the services provided to the subscriber in some embodiments of the invention.

Referring now briefly to Figure 5, this shows how the communications system 10 arranged to provide location services incorporates a monitoring system (MS) 40. MS 40 is arranged to receive data as soon as a device 16 responds to the beacon generated by an AP 14 which indicates the device 16 is located within the WLAN 12 that AP 14 provides. This means that MS 40 intercepts signalling associated with device attaching to the WLAN 14 including signalling which assigns an IP address to the device 16. In addition, the MS 40 receives traffic generated by devices 16 running applications which generate traffic to actively use the WLAN 12 provided by AP 14 for internet access and the like.

The data received by the MS 40 is stored in monitoring data store (MSDS) 44. The MS 40 is able to access supplementary data from one or more service or network management type of data stores, such as data stores 30, 32, 34, 36, NAT data store 27, DHCP system 38, and authentication system 42 described later herein below. MS 40 may use the supplementary information in MSDS 44 or dynamically perform look-up operations on these other management data stores to retrieve information which enables location services to be provided. For example, the AP IP & Service ID data store 32 is accessible by the MS 40 shown in Figure 5 using a suitable query interface which enables the monitoring system to perform a look-up type operation using an IP address to retrieve the ServicelD allocated to an AP 14. When a plurality of APs 14 in communications system 10 are authenticated and a connection established between each AP 14 and the RAS 24, a plurality of the ports 26a, 26b of the DSLA are occupied depending on the number of different secure tunnels (to each respective AP) which are established to distinguish traffic from each AP's subscriber's device(s) from roaming device traffic. Each tunnel terminates using different virtual private networks (VPNs) or alternatively MPLS labels at a VPN node 25 which is located more centrally within the access network than RAS 24, for example, between the RAS 24 and the service selection gateway (SSG) 48 located in the core network. At the VPN node 25 traffic emerges from the tunnel associated with a VPN configured specifically for roaming device traffic (whereas traffic generated by devices associated with the home WLAN provided by the same AP). The traffic from the roaming devices is forwarded by the VPN along two paths - one is to the destination address indicated for the traffic and the other path is to MS 40 (the traffic flow being effectively duplicated (or copied)). Typically, the VPN node 25 is also configured to forward traffic onto the monitoring system 40 when directing traffic for forwarding back to a roaming device over the tunnel. Both device generated and device addressed traffic is thus received by monitoring system 40 in one embodiment of the invention.

Those of ordinary skill in the art will be aware that the VPN node 25 providing the VPN termination functionality for the secure tunnel used for traffic generated by devices 16 that associate with an AP 14 may be hosted on the same physical platform as the RAS 24, and/or on the same physical platform that hosts a NAT functionality (shown in Figure 5 as a NAT server 27). In one embodiment of the invention, once the AP 14 has been authenticated by the RADIUS server 28 to enable it to use a particular ServicelD to access an ISP communications service, the AP 14 is configured to send an XML message or similar type of signalling message to a special "AP information" data store 34 which contains the AP's APID and provides details of the private IP address the Radius server has allocated to the AP 14, the AP's DSL IP address. If this message is sent over the access network to the service selection gateway SSG 48 (shown in Figure 5) the source address (of the AP 14 from which the message originates) in the header of the message will undergo network address translation (NAT) at NAT server 27. Accordingly, to overcome the problem of identifying which AP 14 has sent the message when only a translated IP address is received, the data records which hold the range of allocatable IP addresses for a device using a particular AP are associated with a unique identifier for the AP, similar to a Media Access Control (MAC) address, which is referred to herein as the "APID".

The APID data stored in data base 34 is available for access through a suitable interface mechanism by the monitoring system 40 shown in Figure 5. The interface mechanism enables the monitoring system 40 to perform a look-up request based on the APID to return the AP's DSL IP address, which is provided within the body of the message the AP 14 sends to update data store 36 and so does not undergo IP address translation. In one embodiment, the unique IP address range from which the IP address is allocated to a device is preconfigured on each AP 14, so that the AP is already aware of this information. In this embodiment, each WLAN provides a separate addressing domain for the devices within it. This range information is made network accessible by being stored in the AP information data store 34. It is provided within the body of the same XML message or similar signalling message that updates this store to indicate the APID has been allocated a DSL IP address.

As shown in Figure 5, the AP 14 is configured to send the range of IP addresses which can be allocated to a device using that AP's network 12 (for example, using one of the mechanisms described later herein below with reference to Figures 6A to 6C), to another special "Range" data store 36 which stores the range of IP addresses that a given AP ID can assign to devices within its networks. The IP addresses which are stored in the data store 36 resolve in the access domain to the AP and the devices using its network, i.e., the private IP addresses which can be resolved to devices using the DSL access link 18. This enables the range of IP addresses which an AP 14 can allocate to roaming devices 16 to be associated with that AP's ServicelD, and enables a device to be associated with an AP if the device is determined to have a private DSL resolvable IP address which falls within the range of IP addresses associated with a particular AP. The data stored in data bases 34 and 36 is similarly accessible using a suitably configured interface mechanism by the monitoring system 40 shown in Figure 5 and may be processed by the MS 40 and stored in records associated with device or AP IDs in MSDS 44. Those of ordinary skill in the art will be aware that the service and/or network management data stores 30, 32, 34, and 36 have been indicated separately, and it is possible for the corresponding data records of a plurality or all of these data stores to be subsumed into a single data record and hosted with the monitoring system's data store 44, in any suitable manner capable of supporting the amount of data involved.

Each access point is allocated an address range for devices which is unique from the address range other access points use for allocation purposes. Different ranges of IP address are allocated for use by home network attached devices than for roaming devices. In one embodiment, the range of IP addresses are served from a local DHCP server on the AP 14 whose unique range is set at configuration time when the AP 14 is activated, i.e., the range is allocated and associated during configuration of the AP 14 for participating in the roaming service (e.g., when an access point such as the BT Home Hub™ is made live to participate in the BT FON™ service). Alternatively, this can be done by a central DHCP server. An AP initially configured to perform local DHCP may later be reconfigured to allow remote DHCP to be performed, for example, if dormant code on the AP 14 is activated at some point. If roaming devices are assigned IP addresses allocated from a central DHCP server (as opposed to a local DHCP server hosted by the AP 14), the IP address assigned to a roaming device is dynamically allocated (although each AP 14 still assigns IP addresses from the same unique IP address range to roaming devices).

Thus the IP address range allocated for roaming devices is unique to each AP 14 in communications system 10. Where the AP uses a preconfigured IP address range, the IP address allocation is different from private DSL IP address which is dynamically allocated.

As each IP address range allocatable to roaming devices is uniquely associable with an AP 14, the IP address range for roaming devices is also unique to each AP Service ID, and the IP address range will be unique associable with the AP ID (and also at any given time with an AP IP address).

Returning again to Figure 5, this shows schematically how the monitoring system 40 accesses several service and/or network management data stores to retrieve data and populate its own data store 44. Network address translation (NAT) of IP addresses and/or port address translation (PAT) is managed by the MS 40 having access to the data records of the NAT node 27 from which data store both NAT and PAT private/public IP address mappings can be determined.

In Figure 5, several data flows are shown which are described below: Fine dashed line: AP connection configuration traffic (authenticates AP);

Heavy dotted line: Roaming device authentication traffic;

Dot-Dash line: traffic from the AP comprising data which associates a device's private DSL IP address (which is the IP address which is resolvable over the DSL access link 18) with its own APID and data which enables the AP's own private DSL address to be associated with its APID. Dot-dot-dash line: traffic comprising data enabling the AP to update the DHCP server to indicate the address it has allocated to a device in a WLAN the AP provides. By enabling the DHCP server to know this information, it facilitates sharing this information with the monitoring system and enables the device to potentially be tracked over a larger geographic range (i.e. over several WLANs) by the monitoring system 40.

Light short-dot line: Various traffic flows comprising data which is pushed to or pulled by MS 40 from/to various data stores into/from MSDS 44.

Heavy dashed: Monitored traffic from roaming device emerging from VPN.

Referring more generally to Figure 5, the communications system 10 includes a monitoring system (MS) 40 arranged to collate data which is either pushed to the monitoring system or which is collated by MS 40 interrogate various data stores. As shown in Figure 5, a successful AP 14 connection request generates traffic shown by the fine dashed line which results in a ServicelD being associated with the AP's IP address in data store 32. The AP 14 is then able to populate data store 34 to associate its AP ID with its IP address (which may change each type the AP establishes a connection over the access network), and data store 36 which associates the AP IP address with the range of IP addresses that AP may allocate to devices.

As shown in the system of Figure 5, when a device 16 associates with an AP 14, it generates traffic which enables an IP address to be assigned to the device. If the device has been suitably configured, the allocation of an IP address results from this association, and does not require the device to have been authenticated to access the roaming service as shown in Figure 5 by back-end authentication server system 42. The traffic which is received by the AP 14 over the open-access roaming or guest WLAN the AP 14 provides is forwarded via the RAS 24 over a separate secure tunnel providing a virtual private network to separate this traffic from the traffic which is generated by devices configured to associate with the private WLAN 12 the AP 14 provides. The AP 14 is configured to automatically forward all traffic received using its roaming service to the VPN node 25, which is configured to route the VPN traffic from roaming devices through to the monitoring system 40, either on a divert or by duplicating the traffic flow it has received over the VPN from the roaming device 16. This may comprise call signalling traffic, signalling traffic when the device seeks to access a web-page, or traffic generated by the device launching an application prior to authentication.

Post-authentication, in one embodiment, all roaming traffic (from and/or to a roaming device) is duplicated at the network end of the termination point of the secure communications link (in otherwords, the monitoring system can collate data bi-directionally or uni-directionally. Figure 5 shows some of the monitored data such as the traffic flows which are duplicated by VPN node 25 when it receives signalling traffic flows generated when device 16 associates with an AP 14 and is allocated an IP address.

Also shown in Figure 5 is an additional traffic flow which the AP generates in some embodiments of the invention in which it updates the DHCP server 28 with the IP address it has allocated to a device 16. Not shown is the data flow which may occur if the AP needs to request an IP address from the central DHCP server 38 to allocate to a device, and the resultant communications between the DHCP server 38 and the AP 14.

Both local and remote DHCP IP address allocation could result in the DHCP server 38 updating its records to store a device identifier ("DevicelD") for device 16, for example, a MAC address associated with the device which is stored in association with the IP address allocated to the device 16. In one embodiment, therefore, it is possible to search for a device using its MAC address which will not only enable the associated IP addresses (private and if actively being used public) but also the device location to be determined by accessing location information derived from the AoS data store 30. The MAC address and location data stored may be pulled by the monitoring system from the DHCP server 38 in some embodiments and stored directly in a data structure along with the (private) DSL IP address of the device 16. In the best mode currently contemplated by the inventors, the device IP and MAC address are suitably pushed by the DCHP server 38 to MS 40 in real-time. This enables MS 40 to update MS DS 44 with the new IP address for a device with a given MAC address in the record for that device MAC with a time- stamp. Alternatively, the AP 14 may directly update the monitoring system 40 using XML or a similar communications protocol.

Figures 6A, 7A, and 9A show schematically how if DHCP service address allocation occurs at the network edge and NAT is used within the core network, a user is only identifiable after they log in to the roaming service. In Figures 6B, 7B and 9B, DHCP relay is used which means that user can be identifiable before they log in to the roaming service, depending on where NAT occurs in the communication system. In Figures 6C, 7C and 9C, DHCP occurs at the network edge but as the WLAN AP provides additional data to the core by sending an additional message it is still possible to identify a user even if NAT has occurred, and this is also possible before the user has logged in to the roaming service. Figures 6A, 6B and 6C show various ways of distributing addresses to a roaming device 16 or use in a communications system 10 according to various embodiments of the invention and the elements shown retain the numbering scheme of Figure 5 where appropriate.

In Figure 6 A, after a roaming device 16 has associated with a WLAN AP 14, for example, by responding to a beacon from the WLAN AP 14, the roaming device 16 automatically requests an IP address from the WLAN AP 14. The IP address request can be implemented, for example, by sending a DHCP IP address request to the WLAN AP 14. The WLAN AP 14 responds by locally allocating an IP address to the roaming device 16 from a range of local IP addresses it is configured to distribute to roaming devices. The IP address allocated may be a public address in that it can be uniquely resolved outside the WLAN associated with that WLAN AP 14 to a unique device, but usually one or more layers of network address traversal (NAT) will be used to enable reuse of the IP address space.

Accordingly, after an IP address has undergone NAT translation, the monitoring system 40 must interrogate the NAT data store to determine what NAT translations have been implemented. Thus whilst any roaming traffic originating from the access network received at monitoring system 40 can be resolved directly if it is diverted to the monitoring system with its original IP address, if it has undergone NAT traversal at any point prior to its reception by the monitoring server, MS 40 needs to verify the translation at the relevant NAT servers along the path the packets have taken. As shown in 6A, therefore, after AP 14 has assigned an IP address to a roaming device, the AP 14 pushes the device MAC address and the IP address assigned to the monitoring system 40 using a suitable messaging format. The IP address assigned in this way is the IP address which will resolve over the WiFi access network domain (i.e., within the WLAN provided by the AP 14 - effectively, however, as roaming device traffic is tunnelled out to VPN node 25, this domain extends along the DSL broadband line over the access network up to VPN node 25) up to the point where NAT occurs. This device IP address is also referred to herein as the private IP address for the device (and is also the DSL IP address for the device).

In Figure 6B, the roaming device 16 generates a local DHCP request. In this embodiment, the WLAN AP 14 relays the DHCP request over the secure communications tunnel over access link 18 to the VPN terminating node 25. VPN node 25 sends a duplicate of all traffic received on the port associated with roaming device traffic including the DHCP request traffic to MS 40. VPN node 25 also forwards the DHCP request towards an appropriate service selection gateway (SSG node 48 shown in Figure 5) which forwards it on via the control plane to the central DHCP server system 38 which allocates an IP address responsive to the address assuming one is still available to allocate to devices using the WLAN 12 provided by the AP. VPN node 25 is automatically configured to copy traffic received from and sent using a secure communications tunnel over one of access links 18 to WLAN access points 14 to the MS 40. MS 40 is configured to extract from received traffic data flow characteristics such as the source IP address used. Where the data has not undergone any NAT, the monitoring system 40 is able to determine the IP address of the roaming device 16 directly, alternatively, it may need to perform a look-up operation to determine from the NAT data store what private IP address is associated with what public IP address. In addition, the MS 40 receives data directly from AP 14 and/or from DHCP server 40 which enables a DevicelD for the roaming device 16 to be determined such as its MAC address. Finally, by accessing the service/network management data stores shown in Figure 5, the MS can determine the device location, and/or other information such as the user(s) of a device. For example, as is shown in Figure 6B, the relayed DHCP request typically contains information such as a roaming device identifier, for example, a MAC source address for a roaming device 16, a WLAN AP identifier, for example, the IP source address of the WLAN AP 14. The monitoring server system 40 can associate such device and WLAN AP identifiers with the location of the WLAN AP 14 by determining to which broadband access service provider the WLAN AP with that MAC address is associated with and/or the fixed or wireless communication line identifier that particular WLAN AP 14 is registered to use. If the device identifier (DevicelD) resolves to a type of device for which a user has account information credentials, it is possible to associate a particular user (as identified by the use of the account credentials) with a location and to monitor movements of the user as the device roams between networks.

This is possible even if the device does not attempt to use the networks for roaming services. WLAN AP 14 generates and/or forwards address request traffic for a roaming device 16 as soon as it associates with the WLAN. This traffic uses the secure communications tunnel over access link 18 to a termination point provided by the VPN node 25. VPN node 25 automatically forwards the traffic it receives on the ports associated with WLANS for roaming devices to a monitoring point 40. As shown in Figure 6B, in one embodiment of the invention the DHCP system 38 is configured to push the device MAC address (derived from the DHCP IP allocation request it has received) and the IP address centrally assigned to the device 16 to the monitoring system 40. Alternatively, or in addition, the AP 14 may push this information into the monitoring system 40. The IP address assigned in these ways is the IP address which will resolve over the DSL access network domain before any NAT has occurred. This device IP address is also referred to herein as the private IP address for the device. In such systems, subsequent internet-bound traffic which contains the centrally allocated DHCP IP address is resolved through the VPN node 25 to a unique device. The device identity is determined by the MS 40 either receiving information pushed by the DHCP server 38 or by the MS 40 querying the DHCP server 38 to determine the identifying MAC address of a roaming device associated with a particular IP address in use.

As mentioned above, VPN node 25 is configurable in one embodiment to copy in-bound traffic to roaming devices 16 (which would also use the secure link) and to forward a duplicated version of such in-bound traffic to monitoring server 40, i.e., both in-bound and out-bound traffic which uses a particular port on the VPN node associated with a roaming WLAN is forwarded to MS 40.

MS 40 processes each DHCP IP address request it receives forwarded by the AP 14 to extract the MAC address of a roaming device 16 and the particular WLAN AP 14. As mentioned herein above this can then directly be used to query service and/or network management data stores to extract location information for the AP 14 which serves as a proxy for the location of the roaming device 16. This information is then suitably stored in a retrievable form by MS 40 in MS DS 44.

The DHCP IP response from the central DHCP server 38 to the roaming device 16 is then also intercepted, which enables the MS DS record to be supplemented with the centrally allocated IP address assigned responsive to the DHCP address request being processed by the DHCP server 38.

If the roaming device 16 subsequently requires authentication by a user, the WLAN AP 14 will forward an authentication request to the authentication server 42. In some embodiments, the user information detected is then separately associable with a previously stored MAC address for the roaming device 16 and from this, the location of the user of the device can be determined. This also enables the user providing the authentication details to be associated with the traffic generated by a particular roaming device 16 and for this traffic to be monitored based on the device's current IP address as that inbound traffic is being sent to a particular device using that current IP address at the monitoring server 40.

In this way, the traffic sent and received by a particular device whilst roaming in a WLAN, including an open-access WLAN, can be monitored and the geographic location of the device determined remotely in the network from the signalling traffic.

Figure 6C shows an alternative mechanism for associating authentication information for a user of a roaming device 16 with a private IP address assigned locally to the roaming device 16 by the WLAN AP 14. In Figure 7C, the WLAN AP 14 allocates a private IP address to a roaming device 16 from a range of possible addresses allocated to the WLAN AP. A roaming device 16 is not assigned the IP address until after the device 16 has been authenticated by authentication server 42. The authentication traffic which is forwarded from the device via the WLAN AP includes as its IP source address the IP source address of the WLAN AP 14. If the traffic forwarded undergoes NAT translation at some point prior to reaching authentication server 44, the authentication server 42 will not know the IP address has been assigned to the device as this will not be apparent from the authentication traffic it receives.

In order for the authentication server 42 to know which NAT translated IP address has been authenticated, so that only IP traffic from an authenticated device is allowed to access a remote network 46 such as the Internet, in one embodiment the WLAN AP 14 is configured to generate a separate authentication message, for example an extensible Meta-Language (XML) message. The authentication message comprises sufficient meta-data and information on the roaming device 16 (such as user account credentials etc., original IP address) to enable the authentication server 42 to make the necessary association of the NAT translated IP address of the authentication traffic originating from the roaming device 16 with the NAT translated private IP address allocated by the WLAN AP to that particular roaming device 16. As an example, such meta-data may include the roaming device Media Access Control (MAC) address, the WLAN AP MAC and/or IP addresses, and/or any other relevant information. As this traffic is intercepted by the monitoring station 40, it is also available to track the location and internet usage of a particular roaming device 16 and/or determine an authenticated user of a particular roaming device 16 whose traffic is being monitored.

Thus in Figure 6C AP 14 is configured to push out the MAC address and assigned private IP address to the monitoring system 40. As mentioned hereinabove, this enables a device ID to be used as a means to find the location of the device. Also as mentioned already hereinabove, the IP address assigned in this way is the IP address which will resolve over the DSL access network domain before any NAT has occurred. Figures 7A to 7C show the data flows which occur for the monitoring system to determine that a device is located within the range of an AP 14. Figures 7A to 7C, 8 and 9A to 9B all show how the monitoring system 40 collates information from the device traffic it receives from the VPN node 25. As shown in Figures 7A to C, 8, and 9A to C the exemplary data flows comprise messages (but additionally/alternatively datagrams or flows of streamed data packets could be intercepted and processed by MS 40). In these Figures, the message flows shown may omit some messages which are known in the art as essential to persons of ordinary skill where such messages would be apparent and are not relevant in the context of the embodiments of the invention described herein. Figure 7A and 9A show a roaming device 16 detects a beacon from WLAN AP 14 and associates with WLAN AP 14. The device is locally authenticated automatically using any suitable automatic authentication procedure known in the art to enable cross WLAN authentication, i.e., processes which provide a roaming service across several wireless LAN access points post association are known in the art.. The authenticated device is then allocated an IP address by the WLAN AP 14 and can utilize the WLAN provided by AP 14. At this point, as Figure 7A shows, the AP pushes out the device IP address and the device MAC address to monitoring system 40.

Continuing now from the dash dot dot line shown in Figure 9A, at some subsequent point in time whilst the device 16 is still associated with the same WLAN AP 14, device 16 generates internet bound traffic. Such traffic may, for example, comprise a service request generated using a web-browser or by the device launching an application which requires internet connectivity. AP 14 receives traffic from the device over the wireless WLAN and determines from the destination IP address that the traffic is internet bound. The AP 14 then either establishes a secure communications link, for example, in the form of an IPSEC tunnel to VPN node 25 or reuses an already established link. VPN node 25 is configured to duplicate all traffic which it receives on a particular port associated with the secure link, i.e., with IPSEC tunnel and forwards this traffic to monitoring system 40. The VPN node 25 also forwards the received traffic on to SSG 48 which determines if the traffic from that device requires authentication before accessing the AP's service provider's roaming network so it can communicated with a remote network 46 such as the Internet or if it can automatically be routed over the AP's service provider's network towards remote network 46. If authentication/authorization is required, the VPN node 25 intercepts the authentication traffic generated by the authentication server 42 which is returned over the same secure communications link associated with that AP (i.e., traffic which flows in the direction of the roaming device is also intercepted and diverted to the monitoring system 40). In this way, the monitoring system 40 is provided with information which includes the device identifier and other information enabling the location of the device to be determined. The MS thus receives information even if a user of the device does not successfully complete their authorization or does not require authorization for a particular internet-bound service request to be delivered. The monitoring service will have updated its data stores when it was notified that a new IP address had been allocated to a device, which occurs prior to the device being authorised for access to the roaming service offered by WLAN AP 14 over the access network.

As the monitoring server 40 does not need to access the authorization server, there is no need to identify to the authorization server 42 the identity of any particular user or device 16 which is being monitored in this way. However, where service authentication is required, as all authentication traffic flows through the same VPN node 25, it is also possible to monitor and track this information when appropriate. In some embodiments of the invention, post- authentication all traffic from a roaming device 16 using the roaming network SSID #2 is forwarded by AP 14 and when received by VPN node 25 from the secure tunnel with AP 14, the VPN node forwards a duplicate traffic stream to monitoring system 40, as shown in Figure 8.

Figure 7B shows exemplary messages flows in an alternative embodiment of the invention. In Figure 7B, roaming device 16 detects a beacon from WLAN AP 14 and associates with AP 14. If the roaming device 16 has previously been authenticated by a user to use the roaming service, the roaming device 16 will then be configured to automatically perform local authentication. Local authentication occurs when a network is used in which no device authentication is required at this stage but sometimes username, service provider in the form of a network domain and password are requested. The roaming device then generates a DCHP request for an IP address which is detected by the WLAN AP 14. In this embodiment, WLAN AP 14 is configured to relay the DHCP request to a central address server 46. Accordingly, when WLAN AP 14 receives the DHCP request, it uses an existing or establishes a new secure communications link, for example, an IPSEC tunnel, to a termination point at the VPN node 25. As shown in Figure 7B, WLAN AP establishes an IPSEC tunnel to VPN 25 and relays the DHCP request over this tunnel to the VPN 25 which copies the DHCP request (and any other traffic sent over the tunnel). One version of the copied DHCP request is sent to the monitoring server system 40. The other version is end to a central DHCP server 42 in the control plane which processes the request and responds over the same IPSEC tunnel via the WLAN AP 14 to assign an IP address to the roaming device 16. At this point, in the embodiment shown in Figure 7B shows, the AP either pushes out a copy of the DHCP response which includes the device IP address and the device MAC address to monitoring system 40, or alternatively, as was shown in Figure 6B (although not shown in Figure 7B), the DHCP server is configured to push out this information to the monitoring system 40. Continuing now from the dash dot dot line shown in Figure 9B, after having an IP address remotely assigned in this way, when the WLAN AP 12 detects internet bound traffic from the device 16, the roaming device traffic is forwarded using the same (or a new) secure link to VPN node 25. If authentication is required for this traffic, this proceeds at this point in a similar manner to that shown and described before with reference to Figure 7A with all traffic sent over the secure link being received at VPN node 25 and a duplicate traffic stream is forwarded to the monitoring station 40.

As shown in Figures 7B and 9B, however, it is possible for the monitoring station to intercept traffic prior to a device generating internet-bound service requests or authentication information as well as the traffic associated with such requests and network activity. The address request (in this example, a DHCP IP address request), and any other signalling the device generates for which the WLAN AP 14 is configured to establish a secure communications link to the communications system 10 for and to forward over that link is capable of being monitored by the monitoring system 40.

Figure 7C shows another alternative embodiment in which a roaming device authenticates using the IEEE 802.1 x communications protocol for port-based network access control (PNAC) It provides an authentication mechanism for a device to attach to a WLAN to provide a point-to- point connection only if authentication is successful. IEEE 802.1 x uses the Extensible Authentication Protocol (EAP) over LANs (EAPOL) for IEEE 802 LAN technologies such as the 802. 1 wireless communications suite. A port in the 802.1x communications protocol refers to a single point of attachment to the WLAN infrastructure such as a particular roaming device 16. The WLAN AP 14 authenticates the roaming device 16 using the remote authentication server 42 (which in one embodiment of the invention comprises a host platform arranged to support EAP and RADIUS (Roaming Authentication Dial In User Service) server functionalities to provide a centralized authentication, authorization, and accounting management platform. Both EAP and RADIUS authentication techniques are well known in the art and are not described further herein. In the embodiment of the invention shown schematically in Figure 7C, the use of the 802.1 x protocol for roaming device authentication enables monitoring point 40 to determine additional information from the unencrypted outer layers of the EAP over RADIUS authentication traffic sent over the IPSEC tunnel established by the WLAN AP 14 with VPN node 25 as well as from the XML message the WLAN AP 14 generates when the roaming device 16 requests an IP address.

As shown in Figure 7C, roaming device 16 detects a beacon from WLAN AP 14 and having associated with the WLAN the roaming device generates an EAP authentication request and sends this to the WLAN AP 14. The EAP authentication request is automatically triggered on association. In this embodiment, when the WLAN AP 14 detects it has received an EAP request, it establishes an IPSEC tunnel to VPN node 25 via which the EAP request is relayed to a suitable authentication server system 42. The EAP request is duplicated at the VPN node 25 and forwarded to monitoring server system 40. As the EAP request is relayed from the WLAN AP 14 to the remote authentication server 42 its source address undergoes NAT translation. This means that the authentication system cannot authenticate IP traffic based on just the source IP address as the authentication system (and similarly the monitoring system) has only a NAT translated WLAN AP IP SA address. The monitoring server system 40 can be optionally configured to be triggered by the detection of an EAP request to monitor traffic generated by authentication server system 42 responsive to that EAP request. If the EAP request is successful, the roaming device 14 is authorized to use the WLAN AP 14 to send a local DHCP request to the WLAN AP 14.

The WLAN AP 14 then allocates an IP address for the roaming device 16 and generates a meta-data message in which its own address is replaced as the source address with the IP address it has allocated for the roaming device 16. This message is forwarded by the VPN node 25 to the MS 40. MS 40 is configured to recognise this type of message and extract from it the IP address of the device and the device MAC address.

Continuing now from the dash dot dot line shown in Figure 9C, the forwarded XML message contains other device identifying information and enables the authorization server 42 to associate the NAT translated address of the message it receives from the WLAN AP 14 with the authentication information. This enables the communications system 10 to be configured to allow internet traffic from roaming device 16 to access a service provider's network to communicate with the remote network 46 based on the NAT translated source IP address of the roaming device 16. It also accordingly enables the monitoring station 40 to track traffic generated by the roaming device 16 and traffic sent to the roaming device 16 using the NAT translated source IP address of the device 16. The device identity information is received by and stored by the MS 40 and in one embodiment the device identity information comprises both a Media Access Control (MAC) address for the device 16 and the associated 802.1 x credentials included in the metadata (e.g.XML) message which is pushed to the MS post authentication by the AP 14. MS 40 is configured to process pushed information such as the received metadata message to extract information such as source address, IP addresses, and any credential type data. The MS 40 stores the 802.1 x credential in a suitable data record format in association with the current MAC address and private IP of the device 16 so that all three are combined and separately searchable if a look-up query is performed using a suitable monitoring system application programming interface on any of the monitoring system data stores 210, 44 etc, such as may be performed to provide a location service such as is described later herein below with reference to Figure 13 of the accompanying drawings.

Once the authentication server 42 has linked the NAT traversed IP address allocated by the WLAN AP 14 to the roaming device 16, it indicates to the WLAN AP 14 that the roaming device 16 using that IP is authenticated to use the communications system 10 to access the service provider's roaming network service. WLAN AP 14 then releases the allocated IP address to the roaming device 16. Whilst additional authentication may be performed at this point, in one embodiment however, the roaming device 16 is automatically enabled to access a remote network 46 without any prompts being generated for user input.

If the roaming device 16 is automatically authorised and authenticated for internet access using this type of EAP and XML based authentication, a user does not need to enter any additional account or authentication information when an application launched on the device 16 generates a service request requiring internet connectivity. This means that the data generated at this point does not need to be redirected to a so-called "captive portal" as is known in the art, as there is no requirement to halt access to the internet whilst authentication information is provided.

Applications provided on a device configured to automatically access web-services or otherwise request information can be configured to "pull" data to the device 16 from remote servers even when the device 16 is roaming as a guest in a WLAN 12a,b,c,d,e offering roaming access. The traffic generated by the roaming device 16 (and traffic addressed to the roaming device 16 is distinguished from the traffic generated by the subscriber (or equivalently private or "home" WLAN user) by the use of two WLANs being provided by each AP 14. A private (or restricted access) WLAN is provided by the same AP 14a,b,c,d,e, has a different SSID from the WLAN SSID used by roaming traffic. By ensuring different WLANs having different SSIDs are used by home and roaming devices, roaming traffic can be received using a different tunnel from home traffic (comprising traffic generated by a device which has associated with the home network). As such, the device activity and related information for roaming devices 16 is capable of being remotely monitored within the communications system 10 by monitoring server system 40, and is automatically distinguished from traffic generated by home devices. It is also possible for monitoring system 40 to receive a diverted traffic flow from VPN node 25 (as opposed to a duplicated traffic flow).

The above description indicates various ways of obtaining information by monitoring signalling traffic in a communications network which is generated by a roaming device using a WLAN as a guest or roaming user (and staying within the boundaries of that particular WLAN) and also when a device roams from one wireless LAN to another wireless LAN as the device associates with each of the roaming networks. As mentioned above, the roaming traffic which is monitored includes signalling traffic and only devices attached to the roaming network SSID use the secure tunnel between the VPN node 25 and the AP 14 providing that particular roaming network. Each secure tunnel reserved for roaming device traffic may be shared by more than one devices which are roaming at any given time within range of the particular wireless network that an AP is providing. Traffic received by MS 40 from each secure tunnel is generated by one or a plurality of devices in each of a large number of WLANs as within a given WLAN a plurality of devices can be operated by one or a plurality of different users (as an example, a user may have a laptop computer and a smart phone with WLAN connectivity, and an electronic book- reader all configured to associated with WLANs) and as many guest users may be roaming at any time in a given WLAN. According to the various embodiments described herein, at the point where the roaming traffic separation imposed by the secure tunnel terminates, at VPN node 25, the traffic on each port associated with a secure tunnel is duplicated and forwarded to MS 40. The VPN node 25 is configured to duplicate only certain types of traffic in one embodiment. Selective duplication may target the type of traffic, for example, duplication of signalling traffic, such as signalling traffic generated by the association of a device with an AP 14. Alternatively, just traffic to certain websites is duplicated. It is also possible, in some embodiments of the invention, to duplicate any traffic arriving at the VPN 25 which is to be sent via an AP 14 to a roaming device 16 over a secure communications tunnel over an access link 18, i.e., to monitor device bound traffic. It is possible to selectively duplicate and/or monitor just signalling traffic or the contents of selected packets. Unwanted traffic is discarded by MS 40.

The duplication is performed at VPN node 25 using any suitable mechanism and/or selection criteria and one version is forwarded to an appropriately configured monitoring system and the other version forwarded onwards as appropriate for its purpose. The monitoring system 40 processes the received traffic to determine appropriate information to populate the data records of MS DS 44. For example, information which enables the identification of the device and/or the location of the wireless network access point and/or other information such as a user identifier and/or related user account information and/or traffic which is sent to or generated by the device and/or meta-data about the roaming device and/or wireless access point used and/or user of the device can be extracted from the data forwarded to the monitoring system. Typically such information may comprise a MAC address and IP address or IP address and port number used, and the AoS information together with a timestamp generated when the MS DS record was updated.

The signalling traffic which is monitored is generated by a roaming device includes signalling from devices which have previously associated with one or more of said wireless local area networks. In some embodiments of the invention, the signalling traffic is collected from devices have already been configured to be locally authorised to use the roaming service. In other embodiments, however, the monitored signalling traffic includes traffic generated before the device or its user has been authenticated and may include traffic generated during the assignment of an IP address.

As mentioned above, a roaming device 16 does not have to generate a request to use the roaming service to trigger monitoring of its signalling traffic as the wireless access point is configured to establish a secure link for certain types of traffic prior to the user authentication process being complete. Roaming device generated traffic which is generated after authentication is capable of being monitored by MS 40 but results in a larger amount of data being collated than is required to implement a device location or tracking scheme and such data may be discarded or stored in a separate data storage facility due to its volume. It should be noted that DHCP signalling will only be stored by MS 40 in embodiments where the AP 14 is using DHCP relay mode or if the DHCP server pushes information to MS 40 (or if the AP 14 pushes this information to the MS 40). Referring now to Figures 10a, 10b, and 10c of the accompanying drawings, these show how the monitoring system 40 shown in Figure 5 uses its notification of when a device 16 is allocated a device DSL IP address for use in the WLAN 12 provided by AP 14 as a trigger event for determining the location for that device based on the address associated with the ServicelD of the AP 14 it is using.

In Figure 10a, when a device 16 roams into an area in which an open-access WLAN is provided by AP 14, it responds to the beacons generated by the AP 14 and associates with the AP 14, a process which provides a device identifier (DevicelD) to AP 14. This triggers the assignment of an IP address to the device 16 by the AP 1 from its pre-configured address range for allocating to roaming devices 16 using its WLAN connectivity (step 50). Successful roaming device IP address assignment causes the AP 14 to push the roaming device ID (e.g. its MAC address or a similar preferably globally unique device identifier) to MS 40 (step 51)

The MS 40 updates MS data store 44 to record the new DSL IP address allocated by AP 14 (step 52). The monitoring system 40 uses the device IP address to retrieve the APID of the AP 14 the device is using (step 54) from Range data store 36. This comprises checking (using any appropriate range checking process known in the art) if the IP address of the device is one within the range of IP addresses which are allocatable to roaming devices 16 using a particular AP 14.

Once an AP 14 has been located whose allocatable IP address range includes the IP address of the device 16, MS 40 uses that AP's APID to perform a look-up operation on the AP Information data store 34 to map the APID to an AP IP address (step 56). The retrieved AP IP address is used to perform a look-up operation on the AP IP &ServicelD data store 32 (step 58). If the AP IP address is found to match to a particular ServicelD, the monitoring system 40 can use the ServicelD to retrieve selected information from the service subscriber records from the AoS data store, including the address for service associated with a particular ServicelD, which provides an indication of the location of the device as being with the range of that AP's WLAN (step 60). If an AP's has a sufficiently low-range, this information may be sufficient to provide a useful fix on the device IP location. If a device is shown as having associated with a plurality of APs whose WLANs have overlapping areas of network coverage, any suitable location resolution technique known in the art, for example, a triangulation technique known in the art, is used to provide enhanced accuracy as to the device's location.

Figure 10B shows an alternative embodiment in which, as the AP 14 requests a central DHCP server 38 to allocate an address to the Device 16 (step 61a). Here the DHCP server 38 responses to the AP (step 61 b) and also pushes to the MS 40 the DevicelD (e.g. the MAC address) it has received from the AP 14 together with the DSL IP address it has allocate to that device (step 61c). The steps then continue as for Figure 10A

Figure 10C shown an alternative embodiment in which, the AP reserves an IP address and generates an XML message which includes a device identifier such as the device MAC address and which includes as a SA for the message the device IP address instead of the AP's IP address as the SA (step 62a). The MS 40 receives a copy of the XML message (step 62b), and processes the message to extract the data it needs to update the MS DS 44 data record associated with the device MAC address to indicate the IP address allocated to that device (step 62c). The steps then continue as for Figure 10A. Figures 1 1 A AND 11B show how local information gathered at locations A and B can be fed into a hierarchy of monitoring system data stores such as Figure 12 shows. This enables location information for devices collected locally by MS 40 associated with each DSLAM (or group of DSLAMs) to be centrally collaged in a central monitoring data store 210 for use on a regional basis to provide a wider scale of geographic coverage (the scale increasing as the hierarchical level increases).

In Figure 11 A, at location A, a device 16 with an exemplary DevicelD (MAC Address) of 00:16:cb:84:ab:e7 is allocated IP Address: 10.50.22.3: by AP "A" from its allocable IP Address Range: 10.50.22.1 - 10.50.22.7. The local area access network applies NAT at the first possible point after termination of the secure tunnel established for roaming or guest device traffic, i.e., just after VPN node 25 located after RAS 24.

At VPN node 25, all traffic received on a port which terminates a secure tunnel over an access communications link is duplicated and forwarded onwards towards its destination and to the monitoring system 40. In order for the monitoring system to determine the identity of the device 16 if it is provided with a pubic IP address or public IP address and port pairing, a suitable mechanism for the MS 40 to interrogate the NAT data store 27 is provided. This enables MS 40 to associate the locally assigned (private) DSL IP address which is used as the IP source address (SA) for packets over the access network, and the NAT translation of the device's private IP address, i.e., the public IP address, which known outside the access network connection domain (i.e., known outside the DSL service domain).

The NAT data store "A" maps addresses to the NAT IP Address Range: 72.20.1.1. - 172.32.255.255 and stores association of the private IP address 10.50.22.3 of device 16 with the NAT translated IP address 172.20.5.5, and this will be pushed down to the monitoring system "A" for storage in data store 44a. The IP address 10.50.22.3 is the IP address allocated by the AP 14 to device 16. The traffic generated in the course of assigning this IP address to the device in the VPN tunnel has the IP source address of the AP 14, which is the DSL IP address allocated by the central DHCP server. The private WLAN IP address is translated by NAT node 27 to a Public IP address valid outside the private network domain associated with the broadband connection over the access network 18. The connection between the AP and the end service is sourced from a unique IP port number, and thus the private IP address is translated to a public IP address which is associated with this port number to distinguish flows between devices whose public IP addresses are the same, i.e., the public IP address and associated port number of, for example, 217.30.90.100:32194 enables devices to be unique resolved using just their public IP address and the IP port used. Accordingly, a MS 40 is first updated with a AP IP address and Device MAC address and then via a message generated by the Central DHCP server 38 the associated public IP address of the device 16 with that MAC address.

In Figure 11 A, two DHCP server functionalities are shown. One server 38 deals with the IP address allocation for the DSL network. The other server is implemented within the AP "B" and deals with IP address allocation on the public WLAN interface. At location B the same device has IP address 10.90.25.3, which was allocated by AP "B". Similarly NAT at B maps traffic flowing from WLAN B with the IP address 10.90.25.3 to 172.20.5.9. Monitoring system B however captures this NAT information, and also stores it locally in its data store "B" 44b. There is a further level of NAT between the core network and the Internet before traffic is routed to the Internet where the non-routable private 172.20.5.9 address is NATed to a routable public IP address.

In the embodiment of the invention shown, each of the MSDSs 44a, b store for the monitored traffic flows they receive a DevicelD, the device private IP address, and NAT translation information pairing the device private IP address with its public IP address. Port information associated with the public/private IP addresses may also be stored. Location information may be stored and/or the AP IP, APID, ServicelD and AP Location information obtained by querying the various service and/or network management data stores 30, 32, 34, 36 described herein above.

If tracking is to be provided in real-time a TimeStamp is also stored. This is associated with the time at which the MS updated the record. Alternatively the time stamp may be the time at which the Device is allocated an IP address, in which case the time-stamp is not generated by the MS but is provided to the MS with the latest IP address information as each time a device moves its access point, it will be assigned a new IP address. In one embodiment, the device ID such as its MAC address is provided instead of/in addition to the IP address (or IP address/port number if PAT is used). Thus it is possible to track in real time the device movement using the device ID and the associated IP address addresses. In some embodiments, not all of data is permanently stored as for location and tracking purposes the devicelD and/or latest IP address, and AoS location information can be sufficient to provide a location service.

Figure 1 1 B shows a central monitoring server system (CMS) 200 with its central monitoring system data store (CMS DS) 210, which collates the information it receives from a plurality of local data monitoring systems 40a,b, and location server 300 which uses a suitable application programming interface or other suitable interface to securely query CMS 200. By centrally storing records in which a DevicelD and location history is provided, either by previous entries or by previous entries associated with a time-stamp, it is possible to track a device by proxy by determining the location of the plurality of APs 14 that the device 16 associates with from location A to B even if these locations are geographically beyond the range of one local exchange.

For tracking purposes, a Device ID is required as each WLAN A and B will allocate the device a different IP address and being able to associate a device's IP address with a location at any given time provides no continuity as the device moves between locations A, B, and C and from WLANs 12a to 12d to 12e, as the monitoring system will only be aware of the location of a device IP address for the duration the device is within the range of one of these WLANs. Examples of suitable DevicelDs for indexing such records include, for example, the Media Access Control (MAC) address and/or any other hardware-embedded or securely embedded device identifier of the device. For example, the DevicelD may be provided by a subscriber- associated hardware module such as a SIM card or the like of a type well-known in the art for enabling a mobile communications device to use one or more mobile communications service(s). In the best mode currently contemplated by the inventors, DHCP server 38 uses a MAC address as a Device ID to store in association with its allocated DSL IP address. Even when remote DHCP IP address allocation is used to assign an IP address to a roaming device, the IP address assigned will be from within a unique range of IP addresses associated with that particular AP 14. Thus the address stored for a device is the private IP address for the device, which is the IP address which resolves to the device 16 within the WLAN network and also over the DSL access link 18. Similarly, if the AP allocates a device IP address, it will be unique within that AP's WLAN 12 (but will not be beyond this when NAT has occurred).

Whenever NAT on a monitored traffic flow's IP address occurs, the monitoring system 40 must update a DevicelD record for the device which has generated the traffic flow to track the pre- NAT translated and post-NAT translated addresses to continue enable the device to be mapped to a valid location. As mentioned hereinabove, in Figure 10, local NAT server A updates local monitoring system 40a whenever it performs NAT, and local NAT server B updates local monitoring system 40B whenever it performs NAT. . As those of ordinary skill in the art will be aware, although only one level of NAT is shown in the drawings of Figure 11 A, additional levels of NAT may be required before the public address domain is reached which are generally omitted from the description and drawings for the sake of clarity (an additional level is shown in being implemented by a NAT server 27c in Figure 11 B by way of example). Generally, no matter how many levels of NAT are traversed, all levels of NAT will have associated data stores to which the MS 40 has access to. In Figure 11a, 11b, both monitoring servers 40a, 40b push their data records to a centralised monitoring server 200 which stores data records derived from each monitoring server 40a, b. Each data record includes the APID which has allocated a particular IP address to each devicelD, and the devicelD. As the APID is also unique, this ensures that even when two devices in different IP addressing domains are using the same IP address (as a result of the address domain separation imposed by the NAT process), the central monitoring system 200 can still resolve each device 16 using its DevicelD (and/or by checking the APID of the AP 14 providing the WLAN 12 the device 16 is using), and hence determine the correct location of the device 16. Similarly, if PAT has been occured, the IP address and port ID pairing is also be stored by MS 40. In embodiments where a DHCP server 38 stores the private IP address, this is stored with the roaming device MAC address, and internal IP address 10.50.22.3 allocated by the AP 14.

Referring again to Figure 11 A, in this embodiment of the invention roaming device 16 is first allocated a Private IP address from an IP address range supplied to an AP 14 via the RADIUS server's ServicelD&IPAddress database 32 (not shown in Figure 11 a). The AP 14 has built in DHCP server functionality which allocates a device IP address from the unique range of IP addresses allocated to the AP 14 for use by roaming devices. The IP source address (SA) allocated to the device 16 is then forwarded by the AP 14 to the DCHP server 38 along with the device MAC address. Both the Device MAC address and Private IP address are forwarded by the DHCP server 38 to MS 40 and stored with the MS DS 44. Not shown in great detail in Figure 1 1 A is the equivalent system for location B where the IP address may be allocated using the same addressing scheme (such as is shown in Figure 6b) or a different addressing scheme, for example, on such as one shown in Figures 6a, 6c.

Figure 11 B shows similar elements to those shown in Figure 11 A and retains the same numbering scheme. In Figure 1 B, location services system 300 is configured to query the central monitoring system (CMS) 200 using interface 240. CMS 200 is configured to query a central monitoring system data store (CMSDS) 210. Local MS DSs 44a,b provide data which may be replicated in CMSDS 210, or may alternatively or in addition CMS 200 is configured to collectively provide data retrievable using an indexing scheme which propagates down from CMSDS 210, such as is described in more detail later herein below with reference to Figure 12. Thus the data in local MS DSs 44a, may be directly accessible to CMS 200 or indirectly retrievable via local MSs 40 a,b. Figure 11 B also shows the private DSL domains and an additional level of NAT being required before the public address domain is reached (shown as NAT node 27c in Figure 11 B). The NAT node 27c performing NAT here either pushes data indicating the IP address mappings performed (and any relevant port numbers assigned for data flows established between a device 16 and a remote server) through to the relevant local MS 40a,b or directly to the CMS 200. The web-servers which respond to location requests by devices 16 will generally provide public IP addresses for such devices 16 to location service system 300, as these will have similarly undergone NAT.

Figure 12 shows schematically a way of providing a hierarchical database structure which facilitates a large-scale location service system according to the invention. In one embodiment of the invention, the processing complexity of any location service is made manageable by authenticating devices only when required. A distributed database structure such as is shown in Figure 12 enables a location to be resolved in response to a location query being received in real-time if required. In Figure 12, each local RAS monitoring database 44a,b,c,d effectively represents a physical region of the country since each RAS 24 is dimensioned to support typically between 50K to 100K customers associated with a number of connected DSLAMs.

As shown in Figure 12, each RAS associated data base 44 functions as a "macrocell" collecting information from a plurality of DSLAMs and each DSLAM functions as a smaller scale microcell. Each of these can be mapped to an area of geographical coverage to provide a means of mapping movement both locally and nationally, by using a hierarchy of monitoring systems. Accordingly, in one embodiment an efficient database structure is provided collectively with each monitoring system data base 44a,b,c,d associated with a RAS 24 being regarded as a macrocell element on a location database hierarchical structure where each DSLAM 22 represents a lower element. As each WLAN 14 has a relatively small range in the embodiments of the invention, incremental movement of a device will normally be localised and this approach to the database structure provides an efficient organisation as the associated movement data is local in its logical structure. This provides geographical scalability with queries directed to the CMS 200 by location server 300 propagating down to the local MS DS 44a, b as appropriate.

In Figure 12 the data storage architecture is structured for providing geographic coverage of the UK. The root DB (UK) data store 210 contains a list of all current MAC addresses and user ID, a marker to show if the device requires tracking with a vector point to the next DB 220a,b,c,d below. Here DB 220a represents broadly speaking "England", and a marker in DB 210 would indicate that this database is relevant by a suitable tag (e.g., "E" for England). For example, an enquiry at root CMSDS node 210 determines if a particular MAC is on line at that time. If it is then the entry against it will have E for England. In the national DS 220a there is a tag for the regional datastore, 230a, and in the regional data store a tag indicates a particular RAS level DB 44, for example, a tag for IP for Ipswich. Once an entry is determined down to the RAS level data store 44 the data record can be retrieved from which location information can be determined.

Returning now to Figures 11A.B the following method is used in one embodiment of the invention to retrieve stored location information for device 16a. Firstly, responsive to a location request from location services server 300 which includes an IP Address and/or a device ID, the monitoring system 40a queries either using the public IP address and/or the devicelD the monitoring database 44a. In this embodiment, the MS DS data records are populated with information which associates the public IP address with a private IP address. In alternative embodiments, MS 40 may query NAT store 27 responsive to receiving a location request for a public IP address to determine the private IP address.

The current Private IP address of the device is then used by MS 40 to query the range data store 36, which returns the APID if this information has not been previously captured and stored in its MS DS 44. MS 40 uses the APID returned to query the AP Information data store 34 to determine the current DSL IP address allocated to the AP 14, and then queries the data store 32 used by the RADIUS server 28 which enables the AP's ServicelD to be determined. Finally MS 40 queries (using the ServicelD) the subscriber record data store 30 which enables the location of the address for service associated with that ServicelD to be verified.

MS 40 is able to track devices within the range of WLANs providing roaming access which are provided by APs 14 connected to any DSLAM 22 to which MS 40 is able to receive data from. In practice, this would be normally implemented only if the devices have registered for a tracking service. As an example, in one embodiment, a monitoring record stored in monitoring data store 44 comprises a device MAC address, a time stamp recording when traffic was intercepted from the device (and/or alternative the time the IP address of the device was allocated by the AP), the AP's IP address and a reference number for the relevant DSLAM data base.

As such the local data stores 44a, b provide local movement changes at a fine level of granularity (the level comprising the level of detail of the address for service for each AP 14). This location data is retrievable at this fine-level of detail over the entire monitoring system data store hierarchy shown in Figure 12. The hierarchical structure organises local changes at the local level in its logical structure to provide a scalable and rapid search strategy. It provides a means to track identified devices over a large scale, despite the very small scale of each WLAN and in a way which minimises the amount of data to be stored. The processing is conserved to minimum and only used to track devices when required. In a preferred embodiment of the invention, all APs 14 are configured to provide roaming WLANs 12 with the same consistent SSID. In this embodiment, a device 16 which has successfully attached whilst roaming to one network SSID automatically generates signalling traffic when it roams further and attaches to another WLAN sharing the same SSID. As this signalling includes IP address information and is generated without a user necessarily actively using the device 16 in the new WLAN (e.g. there is no need for the user to generate a request for service (such as, for example, generating a request for content which would require the device to connect to the internet) which would require the user to authenticate their use of the wireless access point roaming service) and location information is still remotely determinable by MS 40 for that device.

DEVICE LOCATION SERVICE

Figure 13 of the accompanying drawings shows an embodiment of a system arranged to provide device location services to a service requesting platform (SRP) 302. SRP 302 comprises any suitable device, such as a web-server platform, which may itself be mobile although in practice any commercial scale web-server is more probably provided at a fixed location, including the roaming device 16 itself. A location services portal (LSP) 300 is addressable by SRP 302 using any suitable communications protocol query structure, for example, a suitable url type query interface may be provided. LSP 300 is hosted on a suitable platform which is arranged to enable interrogation by the LSP 300 of CMS 200 through an appropriate application programming interface (API) 240. A CMS query comprises at least a public IP address provided by the SRP 302 for which a location is requested. The CMS query is processed by CMS 200 to extract the public IP address which is then used to query the CMSDS 210.

One or more NAT servers 27 may be queried at this point to determine a private IP address or the query may use the public IP address to propagate the query to the appropriate local RAS MS 40 and its local NAT datastore data held in its local MS DS 44.

Once a query to a NAT server/data store 27 has resolved the public IP address to a private IP address, the private IP address is record held in the local MS DS 44 may either be directly associated with an AoS held in that record, or used to perform a look-up to enables a AP ID to be determined using range data store 36 which maps the private IP address of a roaming device 16 to a range of IP addresses uniquely associated with a particular AP 14.

The data records used at this point involve data which is related to the connection service used by the roaming device 16. Once the AP ID has been determined, however, this may resolve to a particular data-store subsystem 44 such as are shown in Figures 11 a,b, and Figure 12. From the AP ID the DSL IP address used by the AP 14 can be determined by querying data store 34, which enables the ServicelD used by the AP 14 to be determined by querying data store 32, which in turn allows the Address for Service for that particular servicelD to be determined from AoS data store 30.

As mentioned herein above, the data held in the records for one or more or all these service and/or network management data stores may be extracted and held in a single data store 210 used by the monitoring system and/or may be directly stored in records associated with each roaming device's local monitoring system records. In practice, the scale of information held and the constraints which data protection can impose, means that querying several sources of information held in existing data bases may be more practical.

Figure 14A shows device 16 seeking to access a service provided by a remote web-server, which will then in turn function as a service requesting platform 302 by querying the location services portal 300.

In Figure 14a, however, the service requested by the device is one which is dependent on or enhanced by location information for the requesting device. If PAT is used within the access network to enable reuse of the IPv4 address space the port number will be assigned to the client device (here roaming device 16) when it establishes a flow to the remote server. In this case, the IP address and port number allocated to the data flow between device 16 and webserver 302 will be used by the location services system 300 to locate the device 16 within the correct WLAN 12.

Accordingly, responsive to the access request, the webserver uses the public IP address information and port number it extracts from the connection request to generate a location query which is sent to location server system 300. As shown in Figure 14A, the remote web-server is functioning as a location service requesting platform (SRP) 302. The other elements shown in Figures 14A.B retain the numbering scheme for elements shown in the earlier accompanying drawings.

Figure 14B shows how the request received from the device 16 by the web-server platform 302 comprises a public IP address as the source address. When the web-server acts as a service requesting platform 302 it generates a location query message for this public IP address (which it derives from the associated with a connection request generated by the device). This location query comprising the public IP address for the device is then provided to location services portal 300 and used by the location services portal 300 to query monitoring system 200 thus comprises the public, NAT translated address.

Figures 15A and 15B show how a method of providing a device location service to a web-server is implemented by a web-server (shown as A SRP 302) and by a location services portal (300) respectively according to an embodiment of the invention. In Figure 15A, web-server 302 receives a request for a web-service from a device 16 (step 400), the public IP source address of the device is extracted from the request (step 402) and used to generate a location query (step 404). As shown in Figure 15A, the location query comprises the public IP address determined from the connection request, but in alternative embodiments of the invention, the location query includes additional information such as the MAC address of the device and/or the port used by the device. The MAC address may be encrypted suitably for added security.

The location query is sent to a location services portal 300 (step 406). Any suitable communications protocol capable of providing a suitable query format can be used, for example an XML message or message supporting a SQL query addressed using a suitable addressing scheme. In one embodiment, the service could be accessed via a url which provides an API for inputting a public IP address and the LSP 300 then returns the location information which can be displayed by the service.

Assuming the query generated is successfully processed by the location services server 300, web-server 302 receives a response which includes the location address of device as indicated by the address for service which was verified for the AP when the AP last established a connection with RAS 24 (step 408). The format of the returned address may imitate the address structure of the address for service records for the AP, or be converted into a GPS coordinate reference as appropriate. Where a web-server 302 has queried the location services server 300, the response is associated with the connection request received from the roaming device 16 (for example, by matching the IP address provided in the response with the IP address extracted from the connection-request received by the device 16). This accordingly enables web-server 302 to determine the location of the device 16 which generated the web- service connection request the web-server 302 received, and to provide in response to the device's request content which is modified by the location information retrieved.

As mentioned above, it is also possible for the roaming device 16 itself to comprise the location service requesting platform 302 and to generate a location request which is directly sent to the location services portal 300 in embodiments of the invention where device 16 is running an application which enables this. Where this is the case, the information the device displays is dependent in part on the location information provided by LSP 300. Figure 15B shows steps performed by the location services server 300 and monitoring system 200 responsive to the receipt of a location services request being received by the location services server 300 (step 410). The query is processed to extract the public IP address and a query is then sent to monitoring system server 200 (step 412) which triggers a look-up operation being performed on NAT data store 27 to determine the private IP address (step 414). The private IP address range associated with the private IP address is used to determine the AP ID used by the device (step 416), and from this the service identifier for the connection the AP is currently using can be found (418), which enables the latest address for service associated with that service identifier to be retrieved (step 420). As described herein above, this retreived address for service comprises a verified address for the AP 14 in that each time the AP 14 connects to RAS 24 via DSLAM 22 and the service address is verified by matching the service ID for the AP 14 with the service ID associated with the ports 26a, b the AP 14 has connected to on the DSLAM 22). This location (the verified address for service) is then returned by the monitoring system 200, via the location server 300, to the location services requesting platform 302. As mentioned above, as shown in Figures 14A and B, SRP 302 comprises a web-server 302, but the SRP 302 could instead comprise the roaming device 16 itself in other embodiments of the invention.

Accordingly, in one embodiment of the invention, a web services based location service is provided by a location server 300 which presents an internet API which allows third parties to make an enquiry of the location of device using the real time public IP address/ port number and device MAC address. In this embodiment, to maintain security of the location of users, the third parties must be subscribers to a third party location service and use https secured communications over the internet between the location service system 300 and their own service requesting platforms 302. Communications between the devices and the third party web-sites also use a secure communications protocol such as https which enables communications from the user to the web site and from the web site to the location service portal 300 to be relatively secure.

In one embodiment, a device MAC address is encrypted using a public key system and the device MAC address is decrypted by the location service server system 300 using the private key. This allows a third party web site to know the public IP address/port number at a given time but not the actual device MAC address. The location service server system 300 then returns the device location as its physical address only if there is a match between the real time Public IP address/port number and the Mac address of the device with the location records accessed via the monitoring system at a given time, in either encrypted or un-encrypted form.

The location services portal 300/monitoring system 200 may be combined in some embodiments of the invention. Real time location of a device is providable if the Public IP address is known in real-time with the device MAC address (or encrypted MAC address). In some embodiments, the MSDS 44 records host both the MAC address, the public IP address and/or a public IP address and local DSLAM (to the AP 14) allocated port number for the traffic flow associated with the roaming device's use of the AP's connection over the access network and makes this information available to the database hierarchy shown in Figure 12 through a suitable mechanism. This enables monitoring system 200 to resolve queries which contains a public IP address to determine the location of a device in real time. Similarly, within the communications system 10 a network operator can track a device as it moves between APs 14a,b,c,d,e,f on the network in real time.

In one embodiment of a location services system according to the invention, the location services system 300 first translates the public IP address/ port number to the private DSL (internal) address and checks that the device is still associated with that particular AP 14 at that given time. In some embodiment, where the MAC address is encrypted using a service provider public key, the MAC address within the service provider domain is de-encrypted first, and a check performed against the stored records. Once the MAC address for the device generating the location service query is found to e match a stored MAC address, then the physical address is determined and returned via https to the third party service which is hosting the web-service the device has requested. In one embodiment, the web services application allows pre-registration of the user and device address such as MAC address, or SIM card or Transport Layer Security (TLS) certificate as found in 802.1x. In this embodiment, it is necessary to only know its real time public IP address/port number of a device and the association of the device ID, such as MAC address or 802.1x, to return the device location. A web services entity 302 presents the device ID and the real-time IP address/port number to the location services portal 300. It is not necessary in all embodiments for the location service server 300 to know a user's identity (for example, to know a user identifier or any associated user credentials), it can verified this as well using its verification system for the device ID. Accordingly, user identity information may be requested instead or in addition to a location in a service request generated by SRP 302 in some embodiments.

An application on the device which is part of the location service associated with the third party comprises in one embodiment a third party developed application (e.g. an IPhone or Android™ type of application) but alternatively may be implemented in web-browser software. Where a web-browser is used, additional functionality associated with the service can be carried out by the installation of browser plug-ins using software technologies such as Java.

For non-tracking applications where a third party requires knowing the fixed location of the user no time stamp is required. Normally, location services and location-related service information can be retrieved on a time-scale which is fast enough for a user to not have moved significantly during the location query processing time (or if the device did move out of a WLAN it would be not more than to a neighbouring WLAN i.e., over a very short distance, given the broadband connectivity speeds which the WLAN AP 14 provides access to). This also assumes that the device has moved but the internal databases have not yet updated to show any new WLAN the device has relocated. Location information stored in any of the databases may time out and return a "location not known" type of response or provide "last known location" if the device location has not been known for some time.

In one embodiment of the invention, to reduce the processing complexity of any location service the physical location associated with the authentication is only carried out when required. For example, a static service can be used by the web services company where it is envisaged that the device would not move during the session. An example would be using a roaming device to buy tickets at the nearest cinema to the location of the device when it generates a request to buy the tickets with a ticket selling web-service. It is possible to also use the LSP 300 of the invention to alternatively purchase the tickets using a device located in its own home WLAN. In this case, part of the transaction verifies the home address provided by the user to the ticket selling web-service against the address for service stored against the customers' records adding additional confidence to the financial transaction.

If a web server presents the Public IP address/port number and device ID such as MAC address, the public IP address/port number isused to locate the device's physical location and the device ID is used as a security check so that knowing the MAC address alone could not be used to find the user. The current public IP address/port number is known in real-time as this is dynamically assignedeach time the AP negotiates a DSL session and each time NAT is carried out. In some embodiments of the invention in which device movements are tracked centrally by the Monitoring System 200, central tracking is performed using just the MAC of the roaming device as a look-up, and the monitoring databases 210, 44 etc. of the monitoring system 200 are configured in such a way that IP address, IP address and port number (assigned by the DSLAM) and the MAC address of a roaming device 16 can be used as a search index.

In this way, three different types of WLAN location services can be provided to locate a roaming device. One mode of WLAN location service uses the public IP address alone, the other uses the Public IP address and uses a MAC address as an additional verification element, and finally, it is possible to use a device ID when known alone (e.g. the MAC address of the device) to locate a lost or missing device or in any situation where the location needs to be determined but the device has not yet been allocated an IP address or may not be using its IP address or the IP address is not known. The above description of the embodiments of the invention indicate how traffic originating from a device roaming in an open-access wireless local area network can be monitored from within a core communications network system by collecting information forwarding at the VPN node 25 which functions as the termination point of the secure tunnel with the AP 14 which is established for traffic only from the open-access roaming/guest devices 16 . The term core communication system as used herein refers to the communications network locate at or beyond the first line aggregation point or node. One example of a line aggregation point or node is a kerb-side cabinet but more generally the monitoring system will be located on the far side of the nearest local exchange via which traffic from the roaming device 16 originates. The information collected from the tunnel forwarded data is used to populate a roaming device location record for the roaming device 16 in a suitable device location data store. A roaming device location record is generated for each device ID and contains a series of data fields which index against an IP address assigned to the roaming device, a time and/or date stamp and the current location of the device. The series of data fields may be configured so that they are separately searchable, so, for example, a specific IP address can be searched for which was used in a time-window in order to retrieve the device ID of the roaming device to which it was assigned at that time. An example of a record entry which the monitoring station can generate and maintain for a roaming device 16 comprises a plurality of data fields such as a plurality of the following a Device ID, a Device MAC address, a device public IP address, a device private IP address, an AP ID, an AP MAC address, an AP public IP address, an AP private IP address, the Date/Time the device associated with an AP (and optionally at what point the device first generated a request to a specific destination address), and the geographic location of the AP, which may be provided in mapping co-ordinates such as GPS or using a street address from a customer record. In some embodiments, records for each AP are provided which include the range of IP addresses which may be locally or centrally allocated to devices using a particular AP's WLAN. As a specific example, a record may for a roaming device 16 comprises the following fields shown in the table below:

The record shown above indicates that a device with the MAC address 00:16:cb:84:ab:e7 had a public device IP address 193.113.10.2, which corresponded to the private device IP address 10.50.22.3 and used an AP having IP address 0.50.22.1 at 12:00:01 at a geographic location corresponding to the street address of the AP given in the customer record when the broadband service the AP uses was provisioned. The same device MAC address 00:16:cb:84:ab:e7 had a public device IP address 193.113.10.6, which corresponded to the private device IP address 10.90.25.3 when it later used an AP having IP address 10.90.25.1 at 12:05:01 at a different location corresponding to the street address of the AP given in the customer record when the broadband service the AP uses was provisioned

The location is stored in a suitable format, for example, as shown in the above record, a street address for service is translated into in latitude and longitude coordinates but it may be alternatively provided as the street address data from the customer record from which it was imported.

In the above embodiment of a roaming device data record both the private IP address and the public IP address (or the NAT translated IP address) are associated in each roaming device ^' record. The ability to associate a public IP address with a location enables the network operator controlling the network monitoring server to provide location services to third parties. Such third parties have access to a public IP address and/or an encrypted MAC address which serves to verify the correct location has been resolved in one embodiment of the invention, i.e., the MAC address enables the monitoring system to determine a verified location of a device which is using that public IP address and to confirm this is the correct address by determining if the decrypted MAC address provided in the location query matches the MAC address for that device also stored in the device record. This enables security measures to be implemented which rely on verifying the location of a roaming device 16. By providing a mechanism which enables a public IP address to be associated with a device MAC address, third parties are provided with a greater degree of security.

The monitoring service may track devices, particularly if the devices have registered for a tracking service. For example, in one embodiment, a monitoring record stored in monitoring data store 44 contains the device Mac address, a time stamp recording when traffic was intercepted from the device and/or alternative the time the IP address of the device was allocated by the AP, the AP's IP address and a reference number for the relevant DSLAM data base.

As the local data stores 44a, b provide local movement changes at a fine level of granularity, location data is retrievable at a fine-level of detail over the entire monitoring system data store hierarchy shown in Figure 12. The hierarchical structure organises local changes at the local level in its logical structure to provide a scalable and rapid search strategy. It provides a means to track identified devices over a large scale, despite the very small scale of each WLAN and in a way which minimises the amount of data to be stored. The processing is conserved to minimum and only used to track devices when required.

In some scenarios, all roaming WLANs are assigned a consistent SSID, which means a device which has successfully attached whilst roaming to one network SSID may automatically generate signalling traffic when it roams in other WLANs sharing that SSID. This signalling can include IP address information which is generated without a user necessarily actively using the device to generate a request for service (such as, for example, generating a request for content which would require the device to connect to the internet) which would require the user to authenticate their use of the wireless access point roaming service. DEVICE PROXIMITY SERVICE

An embodiment of the invention will now be described in which location services server 300 is arranged to provide device proximity services to a service requesting device or platform 302. The service requesting device 302 comprises any suitable web-server platform, which may itself be mobile although in practice any commercial scale web-server is more probably provided at a fixed location.

In this embodiment, in Figure 13, the location services portal (LSP) comprises a proximity service system (PSS) 300 which is addressable by a service requesting platform 302 which requires proximity information for one or more other devices (not shown in Figure 13, see Figures 16a,b,c). The SRP 302 may comprise a security server, or a web-server from which a device or other server system can request service information or alternatively, SRP 302 comprises one of the devices for which the proximity to other devices is requested.

The requesting device and/or one of the other devices for which proximity information is requested may be roaming or not roaming in a WLAN for which a device has generated presence information detected by a monitoring system 40. PSS 300 is addressed by the SRP 302 using any suitable communications protocol query structure, for example, a suitable url type query interface may be provided. PSS 300 is hosted on a suitable platform which is arranged to interrogate either the CMS 200 through an appropriate application programming interface (API) 220 or a local MS 40, although CMS 200 is shown in the embodiment of Figure 13.

As shown schematically in Figure 13, API 220 provides access to the central monitoring system 200. A proximity query sent over API 220 comprises a proximity search identifier to identify if a data record holds current location information for each device for which proximity information is requested.

In one embodiment of the invention, a proximity request is generated by a proximity server for monitoring purposes when the presence of a device on a WLAN triggers a search for one or more other devices to determine if they also have a presence on a WLAN. If so, if this is the same WLAN or if the devices are located on WLANs within a predetermined distance of each other a proximity alert is sent via the monitoring station to a security system. In this way, it is possible for a security system (not shown) to be informed by the PSS 300 if a group of known devices are together.

In another embodiment, a device requests the proximity of other devices. The request identifies the requesting device and at least one other device using a proximity search identifier. A proximity search identifier for a device comprises at least one or more of:

a username, e.g. "Joe" or "Mary";

an embedded component device identifier, for example, a MAC address, which in one embodiment is encrypted in the search index using a public key and the proximity location server holds the private key to decrypt on receipt);

a mobile communications device identifier, for example, a subscriber identifier module (SIM) identifier, a IMSI (International Mobile Subscriber Identity) and/or a MSISDN (which can be referred to as the Mobile Subscriber Integrated Services Digital Network Number), It is also possible to use as a proximity search identifier a public IP address for a device which has been authenticated to use a WLAN roaming service in one embodiment of the invention, when this device requests its proximity to other devices. Whilst the other devices are identified using an appropriate proximity search identifier as indicated above, alternatively all devices may use search identifiers comprising their public IP address. This enables devices which are interacting on-line to determine their proximity to each other. The proximity service system performs a translation from each given proximity search identifier to a suitable device identifier such as MAC address using available data accessed directly within the monitoring system or from external sources to enable the relevant data records for each device having a WLAN presence to be located using the CMS 200 or an MS 40.

The proximity server system 300 thus generates or forwards each query containing proximity search identifiers received via MS API 220 to the CMS 200. The query is processed by the CMS 200 to locate data records which contain presence information for the identifiable devices using WLAN(s) in communications system 10 in order to determine, from the location of the AoS of the APs providing the WLANs in which the devices are present, proximity information between each pair of devices. The information may be presented as line of sight distance information, for example, "Joe and Mary are within 100 meters", or, as the AoS are determinable as street address information, it is possible to provide information broken down to regional, area, or street level. For example, the proximity information may be provided as "Joe and Mary are in the same WLAN" or "Joe and Mary are also in one or more of "Country Name" or "County Name" "TownName" or "StreetName" or "StreetAddress" or "Zip/Post code".

The query is processed by CMS 200 to use the search identifiers to locate the device identifiers such as MAC address are stored in the data records accessible by the CMSDS 210 .

If one of the proximity search identifiers comprises a public IP address for one of the devices, a NAT look up is performed by querying NAT data store 27 to determine the private IP address. Once a query to the NAT data store 27 has resolved the public IP address to a private IP address, the private IP address is record held in the local MS DS 44 is either directly associated with an AoS held in that record for the AP of the WLAN it has a presence in, or it is used to perform a look-up to enables a AP ID to be determined using range data store 36. The data records used at this point involve data which is related to the connection service used by the roaming device 16. Once the AP ID has been determined, however, this may resolve to a particular data-store subsystem 44 such as are shown in Figures 11 a,b, and Figure 12. From the AP ID the DSL IP address used by the AP 14 can be determined by querying data store 34, which enables the ServicelD used by the AP 14 to be determined by querying data store 32, which in turn allows the Address for Service for that particular servicelD to be determined from AoS data store 30.

The search identifiers which comprise mobile communications device identifiers are used to query the relevant mobile communications service registry information to retrieve a MAC address. If a username or other proxy device identifier is used, this is also translated into a suitable MAC address. If an encrypted MAC address is received this is decrypted. This enables a look-up operation to be performed on the data records held in the monitoring system based on the MAC address of a device. If a MAC address is found to have a presence pre-authenticated or post-authenticated on a WLAN in communications system 10, the location of the AP providing that WLAN can be determined.

As mentioned herein above, the data held in the records for one or more or all these service and/or network management data stores may be extracted and held in a single data store 210 used by the monitoring system and/or may be directly stored in records associated with each roaming device's record. In practice, the scale of information held and the constraints which data protection can impose, means that querying several sources of information held in existing data bases may be more practical.

Figure 4A shows device 16 seeking to access a proximity service provided by a remote web- server 302. If PAT is used within the access network to enable reuse of the IPv4 address space the port number will be assigned to the client device (here roaming device 16) when it establishes a flow to the remote server. In this case, the IP address and port number allocated to the data flow between device 16 and webserver 302 will be used by the location services system 300 to locate the requesting device 16 within the correct WLAN 12. The device 16 sends to the web-server 302 a request which includes a search identifier for at least one other device. Accordingly, responsive to the service access request, web-server uses the public IP address information and port number it extracts from the service connection request by the device to generate a proximity query which is sent to proximity server system 300. As shown in Figure 14A, the remote web-server is functioning as a proximity service requesting platform (S P) 302. The other elements shown in Figures 14A.B retain the numbering scheme for elements shown in the earlier accompanying drawings.

Figure 14B shows how the request received by the web-server platform 302 uses a public IP address as its source address. When the service requesting platform 302 generates a location query message for an address associated with a connection request (or otherwise associated with a device 16), the address provided to location services portal 300 and used by the location services portal 300 to query monitoring system 200 comprises a public, NAT translated address. According, in one embodiment of the invention, a web-services based proximity service is provided by a proximity service server 300 which presents an internet API to allow third parties to enquire about the proximity of a plurality of devices to each other using real time public IP address/ port number and/or device MAC address. In this embodiment, to maintain security of the location of users, the third parties must be subscribers to a third party device proximity service and use https secured communications over the internet between the proximity service system 300 and their own service requesting platforms 302. Similarly, communications between the devices and the third party web-sites also use a secure communications protocol such as https. This way communications from the user to the web site and from the web site to the proximity service system 300 are relatively secure.

In one embodiment, the web services application allows pre-registration of each user and device address such as MAC address, or SIM card or Transport Layer Security (TLS) certificate as found in 802.1x in the proximity service. In this embodiment, a real time public IP address or IP address and port number of a device and/or and the device _ID, such as MAC address or 802.1 x, is used to locate each device's location which is then used to determine if proximity criteria are met.

As mentioned herein above, traffic originating from a device roaming in an open-access wireless local area network is monitored from within the core communications network system by collecting information forwarding at the termination point of the secure tunnel established for traffic from the open-access roaming/guest devices. This allows the monitoring system to determine the presence of a device in a WLAN even before authentication. The term core communication system as used herein refers to the communications network located at or beyond the first line aggregation point or node. One example of a line aggregation point or node is a kerb-side cabinet but more generally the monitoring system will be located on the far side of the nearest local exchange via which traffic from the roaming device 16 originates.

This information is used to populate a device location record for the device in a suitable data store 44 of each monitoring system 40. A roaming device location record is generated for each device ID and contains a series of data fields which index against an IP address assigned to the roaming device, a time and/or date stamp and the current location of the device. The series of data fields may be configured so that they are separately searchable, so, for example, a specific IP address can be searched for which was used in a time-window in order to retrieve the device ID of the roaming device to which it was assigned.

An example of a record entry which the monitoring station can generate and maintain for a roaming device 16 comprises a plurality of data fields such as a plurality of the following a Device ID, a Device MAC address, a device public IP address, a device private IP address, an AP ID, an AP MAC address, an AP public IP address, an AP private IP address, the Date/Time the device associated with an AP (and optionally at what point the device first generated a request to a specific destination address), and the geographic location of the AP, which may be provided in mapping co-ordinates such as GPS or using a street address from a customer record. In some embodiments, records for each AP are provided which include the range of IP addresses which may be locally or centrally allocated to devices using a particular AP's WLAN.

As a specific example, a record may for a roaming device 16 post-authentication comprises the following fields:

The record shown above indicates that a device with the MAC address 00:16:cb:84:ab:e7 had a public device IP address 193.113.10.2, which corresponded to the private device IP address 10.50.22.3 and used an AP having IP address 10.50.22.1 at 12:00:01 at a location corresponding to the street address of the AP given in the customer record when the broadband service the AP uses was provisioned. The same device MAC address 00:16:cb:84:ab:e7 had a public device IP address 193.113.10.6, which corresponded to the private device IP address 10.90.25.3 when it later used an AP having IP address 10.90.25.1 at 12:05:01 at a different location corresponding to the street address of the AP given in the customer record when the broadband service the AP uses was provisioned The location is stored in a suitable format, as shown above this is translated into in latitude and longitude coordinates but it may be alternatively provided as the street address data from the customer record from which it was imported.

In the above embodiment of a roaming device data record both the private IP address and the public IP address (or the NAT translated IP address) are associated in each roaming device record. The ability to associate a public IP address with a location enables the network operator controlling the network monitoring server to provide location services to third parties. Such third parties have access to a public IP address and/or an encrypted MAC address which serves to verify the correct location has been resolved in one embodiment of the invention, i.e., the MAC address enables the monitoring system to determine a verified location of a device which is using that public IP address and to confirm this is the correct address by determining if the decrypted MAC address matches the MAC address stored in its records. This enables security measures based on verifying if the location of the device is in accordance with a predetermined security criteria. By providing a mechanism which enables a public IP address to be associated with a device MAC address, third parties are provided with a greater degree of security.

The data record for the same device pre-authentication contains the following information in one embodiment:

As shown above, as a device IP address has been allocation prior to the device seeking authentication to use the roaming service, the monitoring system is still able to perform a search for a device based on its device ID, here the device MAC address, and or any of the other searchable fields, such as the private IP address.

Figures 16A,B,C of the accompanying drawings show exemplary scenarios for which proximity information may be determined between two or more devices according to an embodiment of the invention. Figure 16A shows an exemplary scenario where just two devices X and Y are located within the same WLAN network #1 at time A. If either or both devices generate proximity queries, as the result of any location query based on the MAC address for X and Y would return the same AP identifier for the AP providing WLAN#1 , which would be indicated in the response to the proximity query.

In one embodiment, proximity server 300 alert preferences are configured which generate a proximity alert when one or more proximity conditions are met. When a device with an alert preference is detected by MS 40 as present in any WLAN, its data record includes identifiers for other devices in accordance with the proximity criteria. If any of the other device identifiers indicate a data record for which a contemporaneous presence is determinable, then the proximity to that device is calculated using any known suitable technique and the results compared with the proximity alert criteria stored for the device having the proximity alert criteria. Accordingly, as shown in Figure 15A, if device X has a proximity alert set for device Y being within 1 mile or the same WLAN or in the same postal region, say, a proximity alert would be triggered both if device Y is already located within a WLAN meeting the alert criteria but also, by setting a suitable alert condition for all data records which have an AP located within the search criteria, if device Y subsequently has a presence on a WLAN meeting the alert criteria. The proximity server in this embodiment uses the private IP address information of the appropriate data record to address an alert message to device X or to both devices X and Y which are configured to generate and appropriate display/sound to indicate the proximity of the other device.

Figure 16B shows a similar exemplary scenario to that of Figure 15A but for three devices. In Figure 15B, all three devices X, Y, and Z may be configured to receive proximity alerts. Alternatively, one device say X may generate an open proximity query which does not indicate any other devices by an identifier but does indicate a proximity distance. Proximity server 300 is configured to treat all enquiries where no alternative devices are shown as requests for the number of devices within a WLAN and responds accordingly with any publically releasable information indicating what devices are present.

In Figure 16B, the scenario shown indicates that at a later point three devices X, Y and Z are located within the same WLAN #1. The two already present devices X and Y receive an alert shortly after time A+B to indicate device Z is located within the same WLAN, and device Z can be alerted to the presence of devices X and Y.

Figure 16C shows how proximity based on the AoS of APs providing WLANs #1 , #2 and #3 is in fact provided as the proximity distance. As shown in Figure 15C, device Z is in fact further from devices X and Y (see the dashed lines) but would still trigger a proximity alert based on the distance between the APs (solid line) meeting proximity alert criteria. Figure 17A shows steps in a method of determining proximity information and in a method of generating a proximty alert according to embodiments of the invention in which the monitoring system contains data records which have associated with them devices identified in association with proximity alerts, for example, a data record of the following exemplary type:

A method of determining proximity information is triggered when a device first sensed in a WLAN by monitoring system 40 is found to have related deviceJD fields in its data record with associated proximity alert information. The device is first sensed prior to authentication (step 400), and a look-up operation is performed to determine a data record for that device in which the location of the WLAN in which the device is present is stored (step 402). This happens before the device is authenticated to use the access communications network via which traffic from the WLAN flows to the internet. The presence of the other device identifiers triggers a search for data records for other devices using the device identifiers (step 404). If a data record is found with location for the device which was last updated within a predetermined period of time, the location is extracted from the data record (step 510) and used to determine proximity information (512) for each device indicated in the sensed device's data record (of which two such devices are shown in the exemplary data record above). An example of proximity information comprises the distance between the APs providing each WLAN within which the devices are currently located. If this proximity information complies with a given proximity condition/criteria, a proximity alert is generated which is flagged to the CMS 200 and via proximity service system 300 to any proximity service requesting device/system. Figure 17B shows another embodiment of a method of generating proximity information according to the invention. Before a proximity information request is generated, the presence of a device in a WLAN is sensed by MS 40 (step 500) and presence information is stored (step 502). The stored information indicates the presence of each device which has been sensed via its association with access points providing wireless local area networks, and may be supplemented with post-authentication information such as a public IP address if the device subsequently attempts to use the roaming access communications service the WLAN provides. Each sensed device thus has a data record indicating for said respective device a device presence in one or more of said wireless local area networks with each data record for a device being associated with at least one device identifier for that device and possibly also containing proximity alert criteria listing one or more other device identifiers and associated optional proximity criteria. The proximity criterion is optional if a default proximity criteria is set, for example, the same WLAN within the proximity service system. The data record for each device stores as the location information an address for service of the access network connection service used by the access point providing the wireless local area network the device has been sensed to be present in.

At a subsequent point in time, the device is authenticated for using the access network connection service (step 504). The device generates a proximity services request which is sent to the proximity service system 300 which forwards the request to CMS 200. CMS 200 processes the received proximity search request (step 506) to extract proximity search identifiers for locating the requesting device and one or more other devices (step 508) to determine their proximity to the requesting device. Thus in this embodiment, the device identifiers are provided in the request. The MS then processes the proximity search identifiers to determine corresponding device identifiers used to locate each device data record (step 510). The location of the authenticated device is determined (step 512) and then the location is retrieved from the respective data records for each other device identifiable by the proximity search identifiers provided in the proximity service request (step 514). The retrieved locations are processed to determine proximity information indicating the proximity of the devices from each other (step 516). The proximity information are either sent to the requesting device and/or to each device identified in the service request at this point (518). Alternatively, the proximity information determined for the devices are further processed to determine if they meet one or more proximity criteria specified in the proximity search request or as a default criteria which are determined to be located in the same WLAN (step 520). Accordingly, a method of providing proximity location information according to one embodiment of the invention comprises: storing device presence information indicating the presence of a plurality of devices in a plurality of wireless local area networks, each device having a data record indicating for said respective device a device presence in one or more of said wireless local area networks, each data record being associated with a device identifier; storing in each said data record as device location information an address for service of an access network connection service used by an access point providing each wireless local area network the device has a presence in; using proximity search identifiers extracted from a received service request sent by an authenticated device to determine one or more other device identifiers; determining a data record for said authenticated device; using said one or more other device identifiers to find respective data records for each corresponding device; processing the location information of said authenticated device and the location of one or more other device locations to determine proximity distance information between said authenticated device and said one or more other devices; sending said proximity distance information for each said corresponding device to said authenticated device, wherein each said device's presence information is generated prior to said device being authenticated to use a communications link provided by said access network connection service, and wherein said proximity search identifier used to search for said data record comprises one or more of the following: a public IP source address for said authenticated device included in said service request, and/or a device identifier for said authenticated device included in said service request.

Another embodiment of the invention provides a proximity service system which determines proximity information for communications devices located in one or more WLANs. The system comprises a monitoring system arranged to receive signalling data to enable a device presence to be sensed within a WLAN which includes means for updating a data record for said device with location information for the device by accessing a series of data stores associated with network and service management. The monitoring system processes each data record when updated it to check if it includes one or more other device identifiers and if so, determines for each of said one or more other device identifiers a corresponding data record containing location information and processes the location information of each data record to determine proximity information between said sensed device and said one or more other devices.

Exemplary embodiments of the invention are described in detail herein above and pictorially in the accompanying drawings, however, the invention is not intended to be limited to such exemplary embodiments and includes various obvious modifications and equivalent arrangements which fall within the scope of the appended claims. Features referred to explicitly herein and in the claims may be replaced with alternative features providing functional equivalents where such functional equivalents would be known to those of ordinary skill in the art.

In the above description, references to "one embodiment," "an embodiment," "example embodiment," "various embodiments," etc., indicate that the embodiment(s) of the invention so described include a particular feature, structure, or characteristic. However, it is not necessary for every embodiment to comprise that particular feature, structure, or characteristic. Where the phrase "in one embodiment," or "in an exemplary embodiment," is referred to herein above it may or may not refer to the same embodiment as previously mentioned depending on the relevant context as apparent to one of ordinary skill in the art. Terms referring to features such as, for example, "processing," "computing," "calculating," "determining," or the like refer to an action and/or process(es) undertaken by a computer or computing system, or similar electronic computing device, that manipulates and/or transforms data represented as physical, such as electronic, quantities within the computing system's registers and/or memories into other data similarly represented as physical quantities within the computing system's memories, registers or other such information storage, transmission or display devices.

The term "computing platform" comprises one or more data processors, where a data "processor" refers to any device or portion of a device that processes electronic data from registers and/or memory to transform that electronic data into other electronic data that is capable of being stored in registers and/or memory.

One or more embodiments of the invention include apparatuses for performing the operations herein. An apparatus may be specially constructed for the desired purposes, or it may comprise a general purpose device selectively activated or reconfigured by a program stored in the device.

Where appropriate, a feature described herein in an embodiment of the invention may be implemented in one or a combination of hardware, firmware, and software. Where a feature is implemented as instructions stored on a machine-readable medium, such instructions may be read and executed by a computing platform to perform one or more or all of the operations and/or method steps described herein.

The term "machine-readable medium" comprises any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer). Examples of machine-readable mediums include, but are not limited to: read only memory (ROM), random access memory (RAM), magnetic disk storage media, optical storage media, flash memory devices, and propagated electrical, optical, acoustical or other suitable digital and/or analogue signals (for example, carrier waves, infrared signals, digital signals, etc). Any references to the term "software", "application", "computer program" (which are used as equivalent terms herein) and/or "computer control logic" include as appropriate references to machine code and/or executable code and/or source code which when compiled results in execution on a computing platform of a set of instructions in accordance with the code. A computer program may be provided in an electronically downloadable format or in a format which is stored in the main memory and/or secondary memory of a computing platform and/or data storage means capable of being attached and removed from a computing platform. Where a computer program is stored in one or more data storage means it comprises a computer program product. Such computer programs, when executed, are arranged to enable the computer platform or system to perform the features of the present invention as discussed herein. In particular, the computer programs, when executed, are arranged to enable a processor to implement one or more steps in a method according to an embodiment of the invention. Accordingly, such computer programs may represent data controllers of the computer system.

A computer program product comprising a computer readable medium having control logic (computer software) stored therein may be provided to distribute the invention or cause, when the product is loaded and running on one or more computer platforms, a method according to an embodiment of the invention to be performed. Control logic, when executed by one or more processors, can cause the one or more processors to perform one or more of the functions of a method according to an embodiment of the invention as described herein. The computer program product software may be loaded into a computer system using any appropriate means, including appropriate data storage reading means and/or via a network communications interface card. Software implementing control logic executed by a data processor causes the processor to perform the functions of an embodiment of the invention as described herein. The computer program product software may run as a standalone software application program running in an operating system. Alternatively, it may be integrated into an operating system of the computing platform.

Features implemented primarily in hardware may comprise, but are not limited to, hardware components such as application specific integrated circuits (ASICs), field programmable gateways (FPGAs) or one or more state machines, etc. Any appropriate implementation of the hardware state machine so as to perform the functions described herein may be used as is apparent to a person or persons skilled in the relevant art(s).

The embodiments and examples discussed herein are non-limiting. The embodiments of the invention described in detail herein above form exemplary embodiments only and it will be apparent to those skilled in the art that changes and modifications may be made without departing from the spirit and scope of the invention, for example, in its broader aspects. The embodiments of the invention as defined in the claims are intended to cover all such changes and modifications as fall within the true spirit of the invention.

Claims

1. A method of tracking a wireless communications-enabled device (16) across a plurality of wireless communication networks (12), the method comprising:

sensing said device (16) on one of said wireless communication networks (12);

determining a device identifier and assigning IP address for said sensed device from information provided by said sensing of said device (16);

updating a data record in a remote data store associated with said device identifier with a current location information instance for the sensed device (16);

processing the location information for said data record to determine device tracking information from a current location information instance for said sensed device and at least one previous location information instance for said sensed device (16);

wherein each of said current and previous location information instances for said device (16) is derivable by mapping an IP address assigned to said device (16) to a range of IP addresses for assignment to communications-enabled devices (16) by an access point (14), said assignable IP address range being uniquely associated with an access point (14) which sensed the device (16) on a said wireless communications network (12) provided by said access point, wherein said access point (14) is configured to provide broadband connectivity over an access network (18) to sensed devices (16), wherein location information is derivable from an address for service for a broad band service providing each said access point (14) with said broadband connectivity over said access network (18).

2. A method as claimed in claim 1 , wherein said tracking information comprises directional information for the movement of said device.

3. A method as claimed in claim 1 or 2, wherein said tracking information comprises a movement speed for said device.

4. A method as claimed in any previous claim, wherein said tracking information is used to determine proximity information between a plurality of communications devices located in one or more wireless communications networks, wherein said proximity information is derived by: sensing a device on a wireless communications network;

updating a data record for said device with location information for the device;

determining said data record includes one or more other device identifiers;

determining for each one or more other device identifiers a corresponding data record containing location information;

processing the location information of each data record to determine proximity information between said sensed device and said one or more other devices.

5. A method as claimed in claim 1 , wherein said sensed device is a roaming device and said proximity information is sensed prior to the roaming device being authenticated to use a roaming service offered by said WLAN to access the internet.

6. A method as claimed in claim 5, wherein said data record for said sensed device includes in association with each other device an associated proximity alert condition, and if said proximity information meets a proximity alert condition, an alert is generated by said monitoring system.

7. A method as claimed in claim 6, wherein the alert is sent to one or more or all of said devices identified in said sensed data record.

8. A method of providing proximity location information comprising:

storing device presence information indicating the presence of a plurality of devices in a plurality of wireless local area networks, each device having a data record indicating for said respective device a device presence in one or more of said wireless local area networks, each data record being associated with a device identifier;

storing in each said data record as device location information an address for service of an access network connection service used by an access point providing each wireless local area network the device has a presence in; using proximity search identifiers extracted from a received service request sent by an authenticated device to determine one or more other device identifiers;

determining a data record for said authenticated device; using said one or more other device identifiers to find respective data records for each corresponding device;

processing the location information of said authenticated device and the location of one or more other device locations to determine proximity distance information between said authenticated device and said one or more other devices;

sending said proximity distance information for each said corresponding device to said authenticated device,

wherein each said device's presence information is generated prior to said device being authenticated to use a communications link provided by said access network connection service, and

wherein said proximity search identifier used to search for said data record comprises one or more of the following:

a public IP source address for said authenticated device included in said service request, and/or

a device identifier for said authenticated device included in said service request.

9. A system for determining proximity information for communications devices (16) located in one or more wireless communications networks (12), the system comprising:

means for sensing a communications device (16) on a wireless communications network;

means for updating a data record for said sensed device with location information for the device;

means for determining if said data record includes one or more device identifiers for one or more other devices;

means for determining for each one or more other device identifiers included in said data record a corresponding data record containing location information; and

means for processing the location information of each data record to determine proximity information between said sensed device and said one or more other devices.

10. A system as claimed in claim 9, wherein the location information comprises tracking information generated using a method as claimed in any one of claims 1 to 7.

11. A system as claimed in claim 9 or 10, wherein the device is sensed before said wireless local area network is used to provide said device with wireless internet connectivity over said broadband access network.