WO2010100325A1 - Building and maintaining wireless node constellations - Google Patents

Abstract

In accordance with an example embodiment of the present invention, there is a method comprising: detecting neighbor access nodes; requesting location information from at least some of the detected neighbor access nodes and receiving from the respective neighbor access nodes the requested location information; and storing in a local memory a constellation database comprising identifiers for the detected neighbor access nodes and location information for at least some of the detected neighbor access nodes.

Description

BUILDING AND MAINTAINING WIRELESS NODE CONSTELLATIONS

TECHNICAL FIELD:

[0001] The exemplary and non-limiting embodiments of this invention relate generally to wireless communication systems, methods, devices and computer programs and, more specifically, relate to location information of network nodes or gadgets such as for example access points of a wireless local area network (WLAN) or wireless interoperability for microwave access (WiMAX) network.

BACKGROUND:

[0002] This section is intended to provide a background or context to the invention that is recited in the claims. The description herein may include concepts that could be pursued, but are not necessarily ones that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, what is described in this section is not prior art to the description and claims in this application and is not admitted to be prior art by inclusion in this section.

[0003] Wireless systems such as WLAN/WiFi use access points APs which are the nodes which the non-AP stations STAs use to connect to and communicate across the network. The APs themselves may also be end nodes of a communication. Different WLANs may be stand-alone islands or may be interconnected via one or more of the APs to another network (e.g., the Internet). APs can be set up and taken down from their AP role within an existing WLAN much more easily than a base station of a traditional cellular network, and so the organization and arrangement of WLAN APs is much more dynamic.

[0004] This dynamism leads to the need for location information for the different WLAN APs, so that areas of weak coverage may be identified before a problem arises. Currently, obtaining the location information of APs within an indoor environment is a particular problem if one or more of those APs are not already configured with its respective location. [0005] Specifically, in one technique a person physically walks around and scans for beacons. If a beacon with a yet unknown MAC address is spotted, then that beacon/MAC address is recorded and associated with the location of the AP (if that can be found out) or simply with the location where the beacon was spotted (this is less accurate). In another technique, user communities may report such MAC addresses, and the locations where those were seen. An information technology person associated with the building may then need to confirm the correctness of the information before that new location information can be made accessible to other users.

[0006] What is needed in the art is a way to automatically detect the appearance of a new AP or a new WLAN device in a location of interest (e.g., in a public building such as a mall, shopping center, entertainment center, or a downtown area), and preferably to also determine a relatively accurate location for that AP for the case where the AP is not already configured with its own location and/or for the case where it is not configured to share its configured location.

SUMMARY: [0007] In a first aspect thereof the exemplary embodiments of the invention provide a method comprising: detecting neighbor access nodes; requesting location information from at least some of the detected neighbor access nodes and receiving from the respective neighbor access nodes the requested location information; and storing in a local memory a constellation database comprising identifiers for the detected neighbor access nodes and location information for at least some of the detected neighbor access nodes.

[0008] In a second aspect thereof the exemplary embodiments of the invention provide an apparatus comprising at least one processor and at least one memory storing computer program code. The at least one memory storing the computer program code is configured with the at least one processor to cause the apparatus at least to perform: detecting neighbor access nodes; requesting location information from at least some of the detected neighbor access nodes and receiving from the respective neighbor access nodes the requested location information; and storing in a local memory a constellation database comprising identifiers for the detected neighbor access nodes and location information for at least some of the detected neighbor access nodes.

[0009] In a third aspect thereof the exemplary embodiments of the invention provide a memory storing computer program code that when executed by at least one processor result in operations comprising: detecting neighbor access nodes; requesting location information from at least some of the detected neighbor access nodes and receiving from the respective neighbor access nodes the requested location information; and storing in a local memory a constellation database comprising identifiers for the detected neighbor access nodes and location information for at least some of the detected neighbor access nodes.

[0010] In a fourth aspect thereof the exemplary embodiments of the invention provide a method comprising: receiving from individual ones of a plurality of access nodes a local constellation database comprising identifiers of neighbor access nodes; and for at least one identifier, calculating location information for the node associated with the at least one identifier and storing in a memory the calculated location information in association with the at least one identifier.

[ooi 1] In a fifth aspect thereof the exemplary embodiments of the invention provide an apparatus comprising at least one processor and at least one memory storing computer program code. The at least one memory storing the computer program code is configured with the at least one processor to cause the apparatus at least to perform: receiving from individual ones of a plurality of access nodes a local constellation database comprising identifiers of neighbor access nodes; and for at least one identifier, calculating location information for the node associated with the at least one identifier and storing in a memory the calculated location information in association with the at least one identifier. [0012] In a sixth aspect thereof the exemplary embodiments of the invention provide a memory storing computer program code that when executed by at least one processor result in operations comprising: receiving from individual ones of a plurality of access nodes a local constellation database comprising identifiers of neighbor access nodes; and for at least one identifier, calculating location information for the node associated with the at least one identifier and storing in a memory the calculated location information in association with the at least one identifier.

[0013] These and other aspects are detailed below with greater particularity.

BRIEF DESCRIPTION OF THE DRAWINGS:

[0014] Figure 1A is a schematic diagram of a WLAN constellation having access points APs and non-AP stations STAs in which a new AP, shown by dotted lines, takes on the AP function in the WLAN but its location is not known.

[0015] Figure 1 B is a schematic diagram illustrating context for the MLME as reproduced from Figure 5-1 Oa of draft P801.11 u D5.0 (February 2009).

[0016] Figure 2A is a simplified block diagram of various electronic devices, including an AP and a STA shown in Figure 1A, that are suitable for use in practicing the exemplary embodiments of this invention.

[0017] Figure 2B is a more particularized schematic block diagram of an AP or STA of Figure 1A embodied as a user equipment/mobile phone.

[0018] Figures 3A-B are logic flow diagrams that each illustrate in varying detail the operation of a method, and a result of execution of computer program instructions embodied on a computer readable memory, in accordance with exemplary embodiments of this invention. [0019] Figure 4 is a logic flow diagram that illustrates the operation of a method, and a result of execution of computer program instructions embodied on a computer readable memory, in accordance with another exemplary embodiment of this invention.

[0020] Figure 5 is a signaling diagram between a non-AP STA, an AP, and a database external to the AP for exchanging AP location information according to an exemplary embodiment of the invention.

DETAILED DESCRIPTION:

[0021] There are two ways at least for which position information can be used for WLAN APs. First, the STA or other AP with a WLAN interface, when it sees a WLAN beacon, asks the location of the beaconing AP. Typically with a new AP, the case sometimes arises wherein the AP does not have its location configured, so even if both the beacon-receiving STA and the beacon-sending AP support location retrieval and assuming that the STA can associate to the WLAN, the AP has no location information to give. In many cases WLAN networks are secured and access to them, including their location, requires a passcode. A new amendment to the WLAN standards has defined the GAS (generic advertising service) mechanism which can be used to communicate with the APs without the need to associate/authenticate to them.

[0022] Second, there may be a database external to the APs themselves which store location information which is then provided to inquiring parties. Such a database has the medium access control MAC addresses of the known APs and either the location where the beacon was seen or the true location of the AP. When a device such as a

STA or another AP sees a beacon, the beacon-receiving device reads the MAC address in that beacon and queries that external database to find out the approximate location of the AP. If the database has location information for that MAC address, then the device retrieves from the database the location associated with that MAC address. Because of limited range in WLAN (e.g., approximately 50 m between STA and AP), the beacon location is also the approximate location of the inquiring device.

[0023] For this second use of location information, there are challenges with building such a database. It is clear that adding one AP to the database requires that the presence of the AP is detected, the MAC address of it is recorded and associated with the location of the AP, which is either the location where the beacon was seen or the true location of the AP. Current methods of populating such a database are seen to be inefficient. The MAC address is used because that uniquely identifies the network device. Any other unique identifier of the network device can be used for this purpose.

[0024] Recall that in background above it was stated what was needed in the art is an automated way to detect the appearance of a new AP or a new WLAN device in a location of interest. Such detected information can then be used for several different purposes, such as to fetch or calculate the location of the new AP, build a WLAN constellation, upload the information to a database, etc. If WLAN APs are to be used for positioning, then the MAC addresses of the APs have to be associated with their location somehow. It would more efficient to avoid manually scanning these new APs and manually finding or confirming their location information. Embodiments of the invention detailed herein instead describe automated ways to add the location which maps to AP MAC address information within a database, and such a database may be stored/maintained within the WLAN (e.g., within a local storage medium of each of the individual APs) or it may be uploaded to some external location (e.g., an Internet server) for access by devices within the WLAN on an as needed basis. This is particularly helpful for APs that do not have their location information configured.

[0025] In a particular embodiment so as to better prevent fraud, not all APs will have access to one, or to the same external database. If only certain APs have access to such database, it is desirable that there is a way which allows those APs to learn about the presence of APs which are not their direct neighbor, but their presence is learned through a chain of neighbors. When such a local database is built, termed herein a constellation database, it is uploaded to the external server. Thus, even if only one AP has access to the external database from one WLAN island, it can upload the full WLAN constellation of the island to the external database.

[0026] In one embodiment, APs scan and record the MAC addresses from the beacons they see, thus building their local database of neighboring AP MAC addresses. Then in one embodiment, this local database is uploaded to an external database. In another embodiment, the local databases of APs supporting this capability is exchanged, building a local constellation database. Then, in yet another embodiment, this constellation is uploaded to an external database. Note that in the above procedures location of APs may be part of databases' information.

[0027] Then in a separate embodiment, the external database calculates or allocates location to the MAC addresses present in the uploaded constellation (by e.g., manually configuring the location of at least one AP, or multiple APs, or all APs. Or, manually configuring the location of some of the APs, then based on those locations, estimating the location of the rest).

[0028] Figure 1A illustrates an exemplary WLAN network of APs designated 101 , 102 and 103 and non-AP STAs designated 111 , 112, 113, 114 and 121 in which embodiments of the invention may be advantageously deployed. STAs join the WLAN network by connecting to the respective AP to which they have a bidirectional link 150 as shown at Figure 1A. The particular WLAN of Figure 1 A has the APs 101 , 102 and 103 further interconnected through bidirectional Ethernet links 160 to the Internet 130 (shown as a node of an Internet service provider ISP), though some embodiments of the invention in which the database is maintained wholly within the WLAN may or may not have any node of the WLAN in communication with any other network(s) [e.g., WLAN islands]. A WLAN island is a collection of APs which see each other's beacon directly, or indirectly (their neighbor sees it). [0029] Also shown at Figure 1A are dotted lines indicating the range of the various APs 101 , 102, 103. Thus AP 101 can receive/see the beacons of AP 102 and 120, but not of AP 103; AP 102 can receive/see the beacons of AP 101 and AP 120 but not of AP 103; and AP 103 can receive/see the beacon of AP 120 but not of AP 101 or AP 102. Range is not indicated for AP 120 but it encompasses all of the APs illustrated at Figure 1 A: AP 101 , AP 102 and AP 103.

[0030] Whether or not there is connection with an external network, one may refer to the WLAN itself as a WLAN island. A WLAN island is a collection of APs which see each other's beacon directly, or indirectly (their neighbor sees it). For example, at Figure 1A, if AP 120 was not there, AP101 and 102 would form an island, as none of them see AP 103 which falls outside of their coverage area. As a consequence, AP 103 would be an island of its own, as it does not see AP 101 or 102. Once AP 120 is running as an AP, then all four APs 101 , 102, 103 and 120 form a WLAN island since AP 120 links APs 101 and 102 with AP 103.

[0031] Generally, according to an exemplary embodiment of the invention, the APs 101 , 102, 103 scan routinely for the appearance of any new APs. In the Figure 1A environment, these APs 101 , 102, 103 which are already established in the WLAN see new AP 120 by reading its beacon. These pre-existing APs 101 , 102, 103 record the MAC address from the beacon of the new AP 120 and request its location information. This also continues with the other pre-existing APs 101 , 102 and 103, so that each AP builds up a database of its adjacent/neighboring AP's MAC address and WGS84 based geographic or symbolic (symbolic location is e.g., a store name within a mall or a room number or name within a building; WGS84 is the standard used by GPS) location information. Term each of these the AP's local database.

[0032] It is herein proposed to define a mechanism by which these APs can exchange these local databases so that each can build up a WLAN constellation of the entire neighborhood. Additionally or alternatively, these APs may communicate their local databases to an external entity which then aggregates these multiple local databases from the same WLAN island or from multiple WLAN islands into an aggregated (external) database, which can be used for updating the various local databases at the APs and/or for providing AP location information to non-AP STAs according to the teachings detailed below.

[0033] While building the constellation of the neighborhood by exchanging the local databases with each other, in an exemplary embodiment the APs will retain the information about which AP reported which other APs that reporting AP has seen. This information may be uploaded, in whole or in part, to an external database having a map application which will allow the external database to estimate/calculate the location of the APs whose location is not known. In an alternative embodiment the APs can do this estimation/calculation of the unknown location information themselves, such as when they exchange their local databases with one another.

[0034] For the case wherein the APs exchange their local databases with one another, then each local database being updated with the exchanged local databases of others will then encompass a constellation of all APs in the WLAN island. Recall from the AP ranges shown at Figure 1 A that AP 101 is too far removed from AP 103 to receive its beacon. When AP 120 is part of the network, the local database for AP 120 will include the MAC address and possibly the location information for AP 103. This local database for AP 120 is then exchanged with AP

101 , who then adds the MAC address and location information for AP 103 to its own local database with a note that this information was reported by AP120. In this manner the MAC address and location information for all APs in the WLAN propagate throughout the entire WLAN island so that each AP aggregates the exchanged local databases of other APs with its own to achieve aggregated constellation database for the WLAN island.

[0035] To improve efficiency, each version of an individual AP's local database may include a version number, which changes only after that local database is updated. In this manner, prior to exchanging the entire local databases, the various APs query for the version number of the others' database and only if the version number is different from the version number returned as a result of the previous query, will the AP fetch the other APs database. Consider an example. AP 101 previously received from AP 102 version number 102-1292009B, which is by example the AP identifier followed by Julian date and year followed by a letter designator. AP 102 sends a message to AP 101 that its current version number is 102-1312009B. AP 101 compares the two version numbers it has for AP 102 (the previous version number for which it has AP 102's local database - i.e., 102-1312009A - and the version number just reported), sees there is a difference, and then requests AP 102 send its updated local database. If instead AP 102 reports that version number 102- 1292009A is current, then there is no need for AP 101 to request from AP 102 that it send its actual local database since it has not been updates since last being sent to AP 101.

[0036] Now consider the case where the location information of a particular AP is not known, for example, if the new AP 120 does not have its location information configured and so it cannot provide its location information to the requesting neighbor APs 101 , 102 and 103. Then the AP information of the new AP's neighbors (AP 101 , 102 and 103) can be exploited to estimate the new AP's location information, such as for example by triangulation or trilateralization. In an embodiment, reports on the new location-unaware AP 120 from one or more non-AP STAs 121 can also be used to estimate the location information for the new AP 120, assuming those non-AP STAs 121 are themselves location-aware e.g.: via GPS or by reporting of all AP beacons it sees) and can provide their own location information in such a report. Exemplary implementation details that are specific to WLAN and to messages which currently exist in the WLAN standards (IEEE 802.11 series) are detailed below so that the information exchange may be employed without drastic change to existing WLAN protocols.

[0037] Before describing those more particularized implementations, reference is made to Figure 2A for illustrating a simplified block diagram of various electronic devices and apparatus that are suitable for use in practicing the exemplary embodiments of this invention. The devices of Figure 2A may in particular em bod i merits include a protocol stack such as that shown at Figure 1 B, which is reproduced from IEEE P802.11 u/D5.0: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications (Draft STANDARD, February 2009). Figure 1 B shows a data link layer/MAC layer which includes a MAC sublayer management entity MLME and which lays hierarchically above the physical layer for the IEEE 802.1 x series of standards. The MLME-GAS messages detailed below are created and processed in that MLME and communicated to other entities (other APs or non- AP STAs) via the physical layer.

[0038] In Figure 2A an access point AP 12 of a wireless network such as a WLAN is adapted for communication over a wireless link 11 with an apparatus, such as a mobile communication device which may be referred to as a station STA or user equipment UE 10. The AP 12 may include a gateway functionality and a bidirectional link 15 (wired or wireless) to another data communications network such as the Internet shown in Figure 1A. The STA 10 includes a controller, such as a computer or a data processor (DP) 10A, a computer-readable memory medium embodied as a memory (MEM) 10B that stores a program of computer instructions (PROG) 10C, and a suitable radio frequency (RF) transceiver 10D for bidirectional wireless communications with the AP 12 via one or more antennas. The AP 12 also includes a controller, such as a computer or a data processor (DP) 12A, a computer-readable memory medium embodied as a memory (MEM) 12B that stores a program of computer instructions (PROG) 12C, and a suitable RF transceiver 12D for communication with the STA 10 via one or more antennas. The logical layers MAC and PHY shown at Figure 1 B are kept separate by the controller 12A, and similar for the controller 10A of the STA.

[0039] At least one of the PROGs 10C and 12C is assumed to include program instructions that, when executed by the associated DP, enable the device to operate in accordance with the exemplary embodiments of this invention, as summarized above and as detailed in more particularized exemplary embodiments below. [0040] That is, the exemplary embodiments of this invention may be implemented at least in part by computer software executable by the DP 10A of the STA 10 and/or by the DP 12A of the AP 12, or by hardware such as for example a semiconductor chip or chipset or general purpose processor with or without associated transmitter and/or receiver and/or antenna(s), or by a combination of software and hardware (and firmware).

[0041] For the purposes of describing the exemplary embodiments of this invention the STA 10 may be assumed to also include a medium access control MAC sublayer management entity MLME 10E for invoking the MAC layer signaling MLME-GAS procedure detailed below, and the AP 12 may similarly include its own MLME 12E for invoking its own MAC layer signaling MLME-GAS procedure. As will be detailed below, the MLME (the entity of the management layer in which the physical layer MAC state machines reside) GAS (generic advertisement service) procedure is modified according to the WLAN-specific implementations of these teachings so as to enable the MLME 10E, 12E to exchange an AP's MAC address and location information so that the databases noted above may be built and accessed.

[0042] In general, the various embodiments of the STA 10 or the AP 12 can include, but are not limited to, cellular telephones, personal digital assistants (PDAs) having wireless communication capabilities, portable computers (e.g., laptops/notebooks) having wireless communication capabilities, image capture devices such as digital cameras having wireless communication capabilities, gaming devices having wireless communication capabilities, music storage and playback appliances having wireless communication capabilities, Internet appliances permitting wireless Internet access and browsing, as well as portable units or terminals that incorporate combinations of such functions.

[0043] The computer readable MEMs 10B and 12B may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor based memory devices, flash memory, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory. The DPs 1 OA and 12A may be of any type suitable to the local technical environment, and may include one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on a multicore processor architecture, as non-limiting examples.

[0044] Figure 2B illustrates further detail of an exemplary STA 1 or AP 12 in both plan view (left) and sectional view (right), and the invention may be embodied in one or some combination of those more function-specific components. At Figure 2B the STA 10 or AP 12 has a graphical display interface 20 and a user interface 22 illustrated as a keypad but understood as also encompassing touch-screen technology at the graphical display interface 20 and voice-recognition technology received at the microphone 24. A power actuator 26 controls the device being turned on and off by the user. The exemplary STA 10 or AP 12 may have a camera 28 which is shown as being forward facing (e.g., for video calls) but may alternatively or additionally be rearward facing (e.g., for capturing images and video for local storage). The camera 28 is controlled by a shutter actuator 30 and optionally by a zoom actuator 32 which may alternatively function as a volume adjustment for the speaker(s) 34 when the camera 28 is not in an active mode.

[0045] Within the sectional view of Figure 2B are seen multiple transmit/receive antennas 36 that are typically used for cellular communication. The antennas 36 may be multi-band for use with other radios in the STA 10 or AP 12. The operable ground plane for the antennas 36 is shown by shading as spanning the entire space enclosed by the STA 10 or AP 12 housing though in some embodiments the ground plane may be limited to a smaller area, such as disposed on a printed wiring board on which the power chip 38 is formed. The power chip 38 controls power amplification on the channels being transmitted and/or across the antennas that transmit simultaneously where spatial diversity is used, and amplifies the received signals. The power chip 38 outputs the amplified received signal to the radio- frequency (RF) chip 40 which demodulates and downconverts the signal for baseband processing. The baseband (BB) chip 42 detects the signal which is then converted to a bit-stream and finally decoded. Similar processing occurs in reverse for signals generated in the apparatus 10 and transmitted from it.

[0046] Signals to and from the camera 28 pass through an image/video processor 44 which encodes and decodes the various image frames. A separate audio processor 46 may also be present controlling signals to and from the speakers 34 and the microphone 24. The graphical display interface 20 is refreshed from a frame memory 48 as controlled by a user interface chip 50 which may process signals to and from the display interface 20 and/or additionally process user inputs from the keypad 22 and elsewhere.

[0047] Certain embodiments of the STA 10 or AP 12 may also include one or more secondary radios such as a wireless local area network radio WLAN 37 and a

Bluetooth® radio 39, which may incorporate an antenna on-chip or be coupled to an off-chip antenna. Throughout the apparatus are various memories such as random access memory RAM 43, read only memory ROM 45, and in some embodiments removable memory such as the illustrated memory card 47 on which the various programs 10C/12C are stored. All of these components within the STA 10 or AP 12 are normally powered by a portable power supply such as a battery 49.

[0048] The aforesaid processors 38, 40, 42, 44, 46, 50, if embodied as separate entities in a STA 10 or AP 12, may operate in a slave relationship to the main processor 10A, 12A, which may then be in a master relationship to them. Embodiments of this invention are most relevant to the baseband processor 42 since it is within the signals decoded at baseband are where the device 10, 12 learns the MAC address and location information of the neighbor AP, though it is noted that other embodiments need not be disposed there but may be disposed across various chips and memories as shown or disposed within another processor that combines some of the functions described above for Figure 2B. Any or all of these various processors of Figure 2B access one or more of the various memories, which may be on-chip with the processor or separate therefrom.

[0049] Note that the various chips (e.g., 38, 40, 42, etc.) that were described above may be combined into a fewer number than described and, in a most compact case, may all be embodied physically within a single chip.

[0050] Now are detailed more specific exemplary embodiments of the invention, in the particular environment of a WLAN as set forth at Figure 1 A.

[0051] Consider from the perspective of one particular AP 101. This AP 101 scans around to spot the appearance of any new APs, shown by example as AP 120. The scanning AP 101 records the MAC addresses of all the APs it finds, which in this example includes AP 102 and new AP 120. For purposes of local database exchange with other APs, this local database may also include the AP's own MAC address and location information. As noted above, assume for this example that AP 103 is beyond the normal range of the subject AP 101. Normal range as used herein means a typical or average WLAN range which may be obtained via an omnidirectional antenna, typically about 50 meters in clear space; directed/dish antennas are capable of longer range but for this example consider an omni-directional antenna range as being normal. The subject AP 101 exchanges location information with the other APs 102, 120 whose beacon it can read, and requests location information from those APs 102, 120. This was noted above as the local database exchange. Based on this information exchange, each AP 101 , 102, 120 can build up a local database about all of the APs in the WLAN 'island' shown as the entirety of Figure 1A, including AP MAC addresses and locations. The 802.1 I u GAS protocol is proposed for this exchange, as that mechanism allows exchanging management frames in a pre-associated state. The AP-local databases are exchanged between neighboring APs, allowing them each to build a WLAN constellation of the entire WLAN neighborhood. As can be appreciated from the above, the MAC address and location of distant APs such as AP 103 are collected at the subject AP 101 through reporting from the adjacent APs 102, 120, enabling the subject AP 101 (and every AP in the WLAN) to build a constellation of all APs in the WLAN.

[0052] In another embodiment, regardless of whether there is also an exchange of local databases between the APs themselves, the local database built up by each of the APs in their local memory is sent by some of the various APs to a centralized database, which may be external to the WLAN (e.g., on an Internet server).

[0053] For the case where the location information is not configured in an AP such as for example new AP 120, but the reporting AP 120 is known from its beacon, then there can be applications connected to the local or external database, which can approximate the location of the AP by using e.g. calculations based on trilateration/triangulation (knowledge of its adjacent neighbors and their locations). For example, assume the physical arrangement shown at Figure 1 A, where AP 120 does not have its location information to report to the other APs 101 , 102, 103. Each of those adjacent APs 101 , 102, 103 reports the MAC address of the location- unaware AP 120, along with their own MAC address and location information. From the locations of the reporting APs 101 , 102, 103 which can read the location-unaware AP 120, the location of the location unaware AP 120 can be estimated as lying somewhere within the bounds defined by the locations of those reporting APs 101 , 102, 103, regardless of whether the reporting APs 101 , 102, 103 also report relative signal strength of the beacon they each received from the location-unaware AP 120. This location estimation may be done at the external database, and/or for the case where the APs exchange among themselves their local databases it can be done by the APs themselves. The estimated location information can then be provided to a location-unaware STA, such as a STA that is attached to an AP which is location- unaware, and it can also be provided to the location-unaware AP itself)

[0054] Location information of AP120 could be further refined using (e.g. geometrical) models to estimate the center of the coverage area of AP120. Additionally or alternatively, location information can be further refined by including the non-AP

STAs in the reporting and triangulating process, even where the non-AP STA does not have (cannot report) its own location information since triangulating the location of that non-AP STA can give another data point from which to triangulate the estimated location of the location-unaware AP. Since the normal WLAN range is relatively small, this location estimate will necessarily be accurate to within a reasonable precision.

[0055] The end result is an automated process by which there is a database which associates MAC addresses with physical location information of APs, regardless of whether the APs have their locations configured or whether GPS (global positioning system) information is available. Such a database may be external, in which case it can provide to any non-AP STA 121 in the WLAN an indication of the location of that non-AP STA (assuming the non-AP STA is itself location-unaware), and/or the external database can also provide to all the APs in the WLAN location information which it has calculated/estimated for the location-unaware (new) AP 120. Providing the location estimate to the location-unaware AP 120 itself renders the AP 120 location-aware, though when reporting its own location obtained in this manner there might be included some digital flag to indicate to others that this location is an estimate and not a verified location.

[0056] Figure 3A is a process flow diagram illustrating an exemplary method, actions performed by a computer program stored on a computer readable memory, and operations performed by an apparatus according to the above example from the perspective of an AP 101. At block 302, the AP scans neighboring APs. At block 304, the subject AP requests location information from detected neighboring APs. At block 306, from this received information the AP builds and locally stores a database that includes the identifier (e.g., MAC ID) and location information of APs that are within its "WLAN constellation" or neighborhood.

[0057] At block 308, the subject AP sends at least some of the information of the local database to an external database. At block 310, for one or more of the scanned APs for which location information is not known, the subject AP estimates a location for the location-unaware AP based on the locations of other APs which report that location-unaware AP as being in their neighborhood (adjacent to them). At block 312, the local database stored at the subject AP also contains connectivity information about the subject AP, i.e. which APs it scanned directly. Note that the overall arrangement for this exemplary embodiment lies within blocks 302, 304 and 306; blocks 308, 310 and 312 are optional implementation details depending on how extensive the database is to be and whether it will also be aggregated at some external database with information reported by other APs in the same WLAN.

[0058] Figure 3B is another process flow diagram illustrating an exemplary method, actions performed by a computer program stored on a computer readable memory, and operations performed by an apparatus according to the above example. Figure

3B is also from the perspective of an AP 101 , referred to in Figure 3B as the first AP, but showing further detail as compared to Figure 3A. At block 320 the first AP performs a scan (active or passive) to detect neighboring APs. At block 322 the first AP records the MAC addresses of the other APs which it has 'seen' over a period of time. At block 324 the first AP engages in dialog with the APs indicating support for

Interworking to find out whether those other APs support geographic and/or civic location information. For those which do support geographic/civic location information, at block 326 the first AP downloads from them their geographic and/or civic location.

[0059] From the information obtained at blocks 322 and 326 the first AP then builds its local database of a WLAN constellation. For the case that the information at block 326 is only the location information for the reporting AP, then at this juncture the local database of the first AP includes only those APs with which the first AP is in direct contact (whose beacons it can read).

[0060] There may be APs for which location information is not known. For those APs, their MAC address is added at block 330 to the local database of the first AP. This local database is then uploaded at block 332 to the external database, and/or shared at block 334 with the other APs in the WLAN. [0061] Figure 4 is a process flow diagram illustrating an exemplary method, actions performed by a computer program, and operations performed by an apparatus according to the above example from the perspective of an entity which may be located in an upper level network (e.g., a server on the Internet) at which is stored a database of MAC identifiers and associated AP locations which are aggregated from reports by multiple APs in the same WLAN. At block 402 the apparatus receives from various APs in a WLAN the local databases of those various APs and aggregates them into an external database. These local databases are uploaded from the APs at block 332 of Figure 3B and have the MAC addresses of APs in the respective reporting AP's neighborhoods. Optionally, these local databases also have the location information (where available) of the APs associates with the MAC addresses, or the upper level entity may obtain the related location information from another source. At block 402 the external database apparatus calculates the location of APs for whom there is not yet associated location information (e.g., those APs whose location information is not present in any of the local databases received from the various APs, or whose location information may not have yet been configured and so is not available from the other source which provided the existing location information to this upper level entity/server), and associates the calculated location with the MAC address of the location-unaware AP. In an embodiment such as the triangulation estimation noted above, at block 406 at least some of the obtained information is used to perform the calculation at block 404. This location information is then provided at block 408 to the various APs of block 402 which sent the information from which the database was aggregated. Additionally or alternatively, the external database is made available at block 410 to non-AP STAs in the WLAN, so that they may find from the location the MAC address of a nearest AP. For example, a store name (civic location) is displayed which indicates to the non- AP STA in a mall the store in which the nearest AP is located, and the non-AP STA can then search for the MAC address associated with that civic location. As detailed below, instead of store name a relative direction can be indicated to the user of the non-AP STA. [0062] Note also that an AP may provide this same information to the non-AP STA, indicating where the next nearest AP is located, regardless of whether the APs exchange their local databases or not. This is particularly useful if there is an external database which provides the location information it computes to the location- unaware AP 120. The other APs in the WLAN can then get the calculated location information from the external database also, or from local database exchanges with other APs since the location of the new AP that it received for itself from the external database would then propagate through the whole WLAN island to all APs.

[0063] Now are detailed some exemplary implementations as to how the location information might be exchanged. One draft standard of 802.11 v (section 7.3.2.22.12 of draft 802.11V D4.01 , attached as Exhibit A to the priority document US Provisional Patent Application no. 61/209,161 filed on March 4, 2009) provides for a Location Civic Report. Such a report is typically used indoors. According to an exemplary embodiment of the invention, that Location Civic Report is changed to include azimuth information of the AP being reported. The addition of the azimuth information, particularly when attached to an AP's civic location information, enables one to determine whether the relative position of the location-unaware AP is to the north, to the south, to the east or to the west. The azimuth information that is determined can be configured (e.g., the relative azimuth of neighboring APs 102, 120 can be configured in an individual AP 101 just like its own location information can be), or can be measured with a magnetic compass, which works both indoors and outdoors with the same precision, or can be provided by the external database based on the relative locations and its mapping function which maps the various APs in a WLAN.

[0064] Also in the 802.11 u draft standard, there is a procedure with which the inquiring AP 101 can ask the beacon-sending AP 102, 102, 120 for its location. Specifically, such procedure is described in the current Draft_P802.11 u_D5.0 at draft Table 7-43bz (attached as Exhibit B to the priority document), and the information element names "Info names" listed there are "AP Geospatial Location" and "AP Civic Location". As one particular implementation of this invention, these inquiring procedures are made bi-directional (e.g., the GAS request can be generated and received by the APs, and also in an embodiment by the non-AP STAs), so that both the AP 101 and a non-AP STA 111 , 112 will be enabled to receive and transmit such a message, both in the basic service set BSS and in the independent basic service set IBSS cases.

[0065] Further according to a specific exemplary implementation of the invention, there is defined a new protocol element, which can be referred to for example as "Constellation Exchange info", which would advantageously also be listed in table 7- 43bz. In an embodiment this would also be a bidirectional procedure, so that both the AP 101 and a non-AP STA 111 , 113 would be enabled to receive and to transmit such a message, both in the BSS and the IBSS cases. In this particular implementation, this message exchange would exchange the MAC addresses and associated locations known to the APs. In this implementation there is a prerequisite that APs collect the information around them by regularly scanning for other APs' beacons. The APs would then build their local database using several different methods, for example: scan at regular intervals and record the observed MAC addresses; delete the MAC addresses which are only seen for a short period of time and retain the rest.

[0066] Once the individual APs build up their own local database with the APs they see directly (whose beacons they receive and whose location information they receive upon request), they could exchange that information with each other, thus resulting in a database at each of the APs of the WLAN constellation (see Figure 1A). The information can propagate all the way within the WLAN 'island', and stop at the edge of the WLAN coverage. In such a WLAN constellation database, the MAC addresses and location information of the neighbor APs, and the reporting AP's MAC address and location would also be stored. Once such a constellation is built, there is no need to continually re-construct it. Any particular AP, which has access to the external WLAN database, could then simply upload the constellation, or any updates to the already uploaded constellation, into its own locally stored database in order to keep each AP's local database current for any newly added APs 120.

[0067] In a particular exemplary embodiment, these local databases can be built using the GAS Native mechanism described in Draft_P802.11 u_D5.0, section 7.3.4.1 (Exhibit B of the priority document as noted above). Specifically, when an AP senses a beacon from another AP, it looks for the support of Interworking Service in the Extended Capabilities information element. If that support is there, then the AP uses the MLME-GAS. request primitive to invoke Native GAS to request the Capabilities List from all the neighboring APs which were detected. If the Capabilities List indicates support for either or both the Geo Location / Civic Location, the non-AP STA again invokes the MLME-GAS. request primitive to retrieve the respective location of those APs.

[0068] Further with this same exemplary implementation, if support for Interworking Service in the Extended Capabilities information element is not indicated, then the requesting AP will not be able to download the configured location of the detected AP. In that case, it will only record the MAC address of the detected AP.

[0069] In a specific exemplary embodiment, the APs would repeat the above procedures periodically in order to keep their local databases up-to-date. Uploading their individual local databases to an external (aggregated) database can be done once the AP collecting the information in its local database deems that its local database is accurate and correct at the time of reporting. This assumes that the APs periodically query their neighbors supporting the 'constellation exchange info' capability about the version number of their local database. If that changed, the updated version of the database is fetched from the neighbor.

[0070] In an embodiment, the mere detection of new APs' beacons does not in itself result in that new AP being added to the beacon-receiving AP's local database. Newly detected APs should be found to be present over some period of time before they are added to the neighbor AP's local database, which is ultimately distributed to the neighboring APs and uploaded to the external database. For example, there may be a threshold number of times / periodic scans that a new AP's beacon is received before the beacon-receiving AP adds that new AP's MAC address to its database, or there may be an elapsed period of time (e.g., a 24 hour period) in which that new AP's beacon is received before its MAC address is added. This filters out nodes that take on the AP role only sporadically and leaves only those nodes in the database that are more reliably taking on the AP role.

[0071] Once the local databases of APs are deemed ready for distribution, these APs can exchange information from their local databases with each other, using as a non- limiting example the bidirectional Constellation Exchange information element noted above for the BSS and IBSS cases. Such an exchange mechanism for these databases is now detailed by way of a non-limiting example, with reference to the WLAN layout of Figure 1A.

[0072] First, when an AP 101 wants to download the local WLAN constellation database of another AP 102 (or all the APs from the neighborhood), it looks for the support of Interworking Service in the Extended Capabilities information element of that neighbor AP's 102 beacon. If that support is there, then the AP 101 uses the MLME-GAS. request primitive to invoke Native GAS to request the Capabilities List from all the neighboring APs 102, 120 which were detected (AP 103 is out of direct range from AP 101 and so its beacon is not detected by AP 101 ). If the Capabilities List indicates support for the newly to be defined 'constellation exchange' element, then the first AP 101 again invokes the MLME-GAS. request primitive to retrieve the respective local WLAN constellation database of those APs 102, 120. The second AP 102 and all the other APs 120 can do the same thing with the first AP 101.

[0073] As a specific example, and using the Device Configuration of Appendix V.1.5 of Draft_P802.11 u_D5.0 (Exhibit B of the priority document as noted above), assume an AP 101 acts as a non-AP STA and performs an active scan by transmitting a probe request frame. In response, the AP 101 acting as STA receives probe response frames from the various APs 102, 120, indicating support for Interworking Service in the Extended Capabilities element. The AP acting as STA uses the MLME. GAS. request primitive to invoke Native GAS to request the capabilities list

(section 7.3.3.1 of Draft_P802.11 u_D5.0) from any of those other APs 102, 120, and by these teachings that capabilities list includes a Constellation Exchange information element. If the capabilities list indicated support for the Constellation Exchange, the AP 101 acting as STA again invokes the M LM E-GAS. request primitive to retrieve the valid location information from the requested AP 102, 120, which in an embodiment is that AP's whole local database built up as above and at Figures 3A-B.

The Device Configuration of Appendix V.1.5 noted above is termed a message exchange in state 1 since the requesting party (non-AP STA in the appendix, or AP acting as non-AP STA in this example) does not have to be associated with the AP to which the inquiry is sent. Adjusting this state 1 message exchange to enable the constellation exchange is advantageous in that it can be used in all three WLAN states and does not require the AP acting as non-AP STA to associate with each AP for which it requests constellation information.

[0074] In a related vein, the AP can act as STA by associating to one or more neighbor APs and use the Radio Management Request and Radio Management Report frames to exchange location information. Specifically, the geo-location information can be exchanged using these frames as described at IEEE 802.11 k for the case where an AP acts as STA and associates with a neighbor AP, and the civic location information can be exchanged using these frames as described at IEEE 802.11 v for the case where an AP acts as STA and associates with a neighbor AP. This can be implemented in WLAN networks which are not secure (open access) and/or when the AP acting as STA knows the passcode required to associate with its neighbor AP as a STA.

[0075] The external database has more tools to decide when a new AP 120 should be kept in a database. For example, the external database may elect to retain a new AP 120 when that new AP 120 is reported as being seen by multiple other APs (102 and 103 as well as 101 ; a threshold number of reporting APs can be used), or when the new AP 120 is reported by multiple APs 101 , 102, 103 to have appeared around the same time. These are non-limiting examples and either or both may be used alone or in combination with other criteria.

[0076] The individual APs can upload their local database to the external database via the Subscription Service Provider Network SSPN interface defined in IEEE 802.11 for WLAN. In other embodiments the uploading is preconfigured, and in another embodiment the AP uses its WAN interface to contact the external database and send its local WLAN constellation database to the external database.

[0077] Note that the database with the WLAN constellation information is useful even in case the location of the new AP 120 is not known, since the MAC addresses of any new APs 120 can still be associated with the location of the reporting APs 101 , 102, 103 which report on the new AP 120. Knowing the location of the new AP 120 with a higher precision would add further value for many applications, and so below are a few exemplary embodiments as to how the location of a new location-unaware AP 120 may be determined.

[0078] In a first location determining approach, which can be used for example with a bi-directional AP Geospatial and/or AP Civic location message exchange noted above, the reporting AP 101 inquires as to the location of the newly found AP as detailed above. If the new AP 120 has its location configured, then that information is fetched by the reporting AP 101 , stored in its local database, then ultimately uploaded to the external database.

[0079] In a second location determining approach, then the exchange between the various APs 101 , 102 of their local database constellation information can be used to find the new AP's 120 location. Each of these exchanged local databases indicate whether the reporting AP 101 , 102 which compiled and reported its own locally stored database received the new AP's 120 beacon . From the exchange of the local databases then, each AP can see which other APs apart from itself received the new AP's beacon. Of course, the external database can use this same information from all of the APs in the WLAN to fix the position of the new location-unaware AP 120 with a reasonably high degree of precision. The WLAN constellation database (which indicates the APs 101 , 102, 103 that see the beacon of the new AP 120) will contain information which can be used by the external database to calculate a more precise location of the newly seen AP (e.g., using trilateration and a map database, for example)

[0080] It is noted that the above approach would be enhanced if the reporting APs also measure and report the received signal strength of the new AP's 120 beacon.

Uploading this information into the external database enables the external database to perform triangulation for a more precise location determination for the new AP 120.

[0081] Having this WLAN constellation database in the first instance enables the external database to detect that an AP has moved from one location to another, even for the case where the location of that moving AP is not configured. It is not uncommon to move APs around, such as for example for conference organizers who must place the AP's differently to meet more specific needs of different conferences in a same facility, or conference organizers which carry the same set of APs to the different locations where conferences are held. In these instances, the APs may stay in their new location for a few days or weeks. Even for such a short period of time, adding these 'mobile' APs to the constellation, then removing them may provide a reasonably valuable benefit so as to more effectively enable people attending such conferences with reliable WLAN connections across the convention floor and other levels of the building (e.g., to provide to them maps of meeting rooms and schedules and the like).

[0082] For further explanation, below is an exemplary local database in which there are six APs in the WLAN designated by the MAC addresses MAC11 , MAC12, MAC2, MAC3, MAC13, and MAC4. Of those, MAC3 is both new and not configured for its location, and MAC 4 is new but is location-configured. The MAC address and location information for the other APs is known from previous scans (though no other AP sees the beacon for MAC13). Reporting AP MAC address: MAC11

Reporting AP Location: LOCG11 , LOCC11 (geo location, civic location) Seen beacons:

MAC12, LOCG12, LOCC12 (already known, no change) MAC2, LOCC2 (already known, no change)

MAC3, unknown location (new, seen since date/month/year)

Reporting AP MAC address: MAC12

Reporting AP Location: LOCG12, LOCC12 (geo location, civic location) Seen beacons:

MAC11 , LOCG11 , LOCC11 (already known, no change)

MAC2, LOCC2 (already known, no change)

MAC3, unknown location (new, seen since date/month/year) Reporting AP MAC address: MAC13

Reporting AP Location: LOCG13, LOCC13 (geo location, civic location)

Seen beacons:

MAC2, LOCC2 (already known, no change)

MAC3, unknown location (new, seen since date/month/year) MAC4, LOCG4 (new, seen since date/month/year)

Reporting AP MAC address: MAC2 Reporting AP Location: LOC2 Seen beacons: MAC3, unknown location (new, seen since date/month/year)

MAC4, LOCG4 (new, seen since date/month/year)

[0083] In the above database, those APs which are 'new' and 'seen since' have not yet crossed the threshold of number of times seen/duration over which it then becomes an already known AP to be reported to the external database, as noted above in an exemplary embodiment.

[0084] Indoors, where there is no GPS signal and so the geographic coordinates seen in the database above may not be known, usage of symbolic/civic/virtual addresses can be used to indicate the AP's location information. Even where geographic (GPS) coordinates are known for an AP, APs located indoors can be associated with symbolic location information so that users can better understand where these APs are located. Some indoor locations, such as for example large anchor stores within a shopping mall, are too expansive to be fully covered by one AP, and such stores often have multiple APs to provide reliable WLAN coverage. Those multiple APs, even if they have their symbolic addresses configured, will typically all be configured with the same symbolic address (being in the same store).

Since the beacon of at least some of those same-store and same-MAC address APs may leak out to the neighboring shops in the mall proper itself, it would be useful to know how those APs within the same shop are positioned to each other, which one is most north, which most south, etc. This is one particular instance where the azimuth information noted above proves helpful.

[0085] Different from the azimuth information, a similar advantage can be obtained by segmenting the different shops or stores of the mall example into different 'zones' and assigning each AP within a shop to the zone in which the shop is located. In this implementation the 'zone' information would then be a part of the civic location. All

APs of a particularly large shop or anchor store might be a single zone in themselves. Smaller shops in the section of the mall proper that is adjacent to the anchor store/zone can then indicate to users that there are other APs in the WLAN in the adjacent zone, which is the anchor store itself and can be named as such for simplicity for the roaming WLAN user.

[0086] It is anticipated that there may also be instances in which APs do not see one another, such as AP 101 and AP 103 in Figure 1A. In an embodiment, the WLAN constellation may be more robustly built by using a mobile device such as the non-

AP STA 112, which does see both those APs 101 , 103, to act as a 'bridge' between the APs 101 , 103 by downloading the constellation from one AP 101 and sharing it with the other AP 103, and vice-versa. In the specific illustration of Figure 1 A the AP 102 takes on this function, but if the WLAN has a gap such as if AP 102 and 120 were not present the non-AP STA 112 could be employed to facilitate local database exchange using the MLME-GAS. request primitive noted above.

[0087] While the above description detailed advantages for an environment in which the APs are located indoors, the described WLAN constellation build-up would also be useful in outdoor environments such as downtown areas where a GPS signal may not be available because of urban canyons where buildings shield GPS signal propagation. Further, while the exemplary embodiments are in the context of a WLAN system, these teachings apply to various different systems, for example to WLAN infrastructure mode (when one device is designated to act as an AP), WLAN ad-hoc mode (when no devices are dedicated to act as APs, but any of them can act as a 'soft-AP'), 802.16 based infrastructures (e.g., WIMAX, wireless broadband WIBRO, etc), any 802.16 based ad-hoc networks, 802.15 based WPAN (wireless Personal Area Network WPAN), and also to hierarchical networks that use relay stations in addition to fixed base stations/nodeB's. As such, the WLAN examples as well as the names of messages and information elements used above are exemplary but non-limiting embodiments of these teachings.

[0088] Figure 5 illustrates an exemplary signaling diagram using the exemplary WLAN embodiment and message names. Note that this is meant to encompass various of the embodiments and not all elements shown at Figure 5 need to be present to constitute an embodiment of the invention. There are three APs 101 , 102, 120; a non-AP STA 112; and an external database 501 which may be embodied as a gateway AP or an Internet server or a database accessible by the APs via the Internet. Figure 5 illustrates from the perspective of AP 101 where AP 102 has its location configured and AP 120 does not. Figure 5 begins with no pre-existing database for this WLAN, either local or external.

[0089] First, AP 101 receives beacon frames 510 from AP 102 and AP 120. Then the AP 101 sends a request 512 to each of AP 102 and 120 for their capabilities list to see if they are capable and configured to report their location information. AP 102 replies with its capabilities list 514, from which AP 101 determines that it can get the location information for AP 102 from AP 102. The AP 101 sends to AP 102 a MLME GAS request message asking for its geographic and/or civic location, to which the AP 102 responds 518 with the requested location information.

[0090] There is either no capabilities list sent from AP 120, or the sent list indicates to AP 101 that AP 120 will be unable to provide its location information, and so the MLME-GAS exchange 516/518 is not undertaken. Instead, the AP 101 might try to ascertain from a non-AP STA 112 whether it might provide location information on AP 120. To this end AP 101 sends to the non-AP STA 112 a constellation exchange request 520. If the non-AP STA 112 can act as a bridge between AP 120 and AP 101 , the local database of AP 120 is sent to the non-AP STA 112 who sends it in a constellation exchange response message 522 to the AP 101.

[0091] If the AP 101 still does not have the location information for AP 120, it can request it from the external database 501 in a query location message 524. In this example the external database does have that location information for AP 120, and provides it to AP 101 in a query response message 526. At some periodic time or on request, the AP 101 uploads at 528 its local database to the external database, where other local databases from other APs are also collected. Over time there may be an update needed for the local database of AP 101 , in which case the external database provides it in the update message 530.

[0092] The exchange of local databases between APs is shown in Figure 5 using the non-AP STA 112 as a bridge. As noted above, this constellation exchange may also take place between the APs directly, without the non-AP STA 112 between them.

[0093] The various blocks shown in Figures 3A-B, 4 and the signaling shown at Figure 5 may be viewed as method steps, and/or as operations that result from operation of computer program code, and/or as a plurality of coupled logic circuit elements constructed to carry out the associated function(s).

[0094] According to the above detailed examples then it will be appreciated that in an exemplary embodiment of the invention from the perspective of an access node within the network there is a method, and an apparatus, and a memory storing a computer program which when executed by a processor result in actions comprising detecting neighbor access nodes and storing in a local memory a constellation database comprising identifiers for the detected neighbor access nodes; and thereafter at least one of: a) sending at least a portion of the constellation database to a database outside the network in which the access nodes lie; and b) exchanging the constellation database stored in the local memory with at least one of the neighbor access node's constellation database and adding information from the neighbor access node's constellation database to the stored constellation database.

[0095] In an exemplary embodiment, the method, apparatus and program of paragraph [0094] above, further comprises requesting location information from at least some of the detected neighbor access nodes; receiving from the respective neighbor access nodes the requested location information; and storing in the constellation database each of the received location information in association with the respective identifier for the neighbor access node.

[0096] In an exemplary embodiment, the method, apparatus and program of paragraph [0085] above, in which there remains at least one identifier in the constellation database which is not associated with location information.

[0097] In an exemplary embodiment, the method, apparatus and program of paragraph [0096] above, further comprises receiving, from the database outside the network, location information for the at least one identifier which is not associated with location information, and updating the constellation database with the location information which is received from the database outside the network.

[0098] In an exemplary embodiment, the method, apparatus and program of any one or combination of paragraphs [0094] through [0096] above, wherein detecting the neighbor access nodes comprises receiving from each of the neighbor access nodes a beacon or probe response which carries the identifier for the respective access node; and wherein exchanging the constellation database comprises requesting the location information by sending to the detected neighbor access nodes a request for a capabilities list, and thereafter sending to the at least one neighbor access node a request for geographic or civic location information only if the capabilities list received from the at least one neighbor access node indicates support for location information. [0099] !n an exemplary embodiment, the method, apparatus and program of any one or combination of paragraphs [0094] through [0098] above, wherein exchanging the constellation database comprises receiving from the at least one neighbor access node at least a portion of the neighbor access node's constellation database in response to sending to the at least one neighbor access node a request for constellation exchange, and wherein sending the request for constellation exchange is contingent on a version number for the neighbor access node's constellation database not matching a version number stored in the local memory.

[00100] In an exemplary embodiment, the method, apparatus and program of paragraph [0099] above, wherein sending to the at least one of the neighbor access nodes at least a portion of the constellation database and receiving from at least one of the neighbor access nodes at least the portion of that neighbor access node's constellation database are conducted under a bi-directional generic advertising service message exchange which comprises a constellation exchange information element.

[00101] In an exemplary embodiment, the method, apparatus and program of paragraph [0100] above, wherein the generic advertising service message exchange further comprises a bi-directional GAS Native query message exchange in which the apparatus and the at least one of the neighbor access nodes exchange location capabilities prior to exchanging constellation databases. In another exemplary embodiment, the generic advertising service message exchange comprises a bidirectional GAS Native query message exchange in which the apparatus downloads location information of the at least one neighbor access node. In this latter embodiment the location information might be used for any purpose, even apart from building a local constellation database, and the apparatus may not necessarily send its own location information to the neighbor access node in that bi-directional message exchange.

[00102] In an exemplary embodiment, the method, apparatus and program of any one or combination of paragraphs [0094] through [0101 ] above, in which the apparatus is an access node operating within one of a wireless local area network WLAN or a worldwide interoperability for microwave access WiMAX network or the method is executed by such an apparatus, in which the access node operates as a non-access station for the generic advertising service message exchange.

[00103] In an exemplary embodiment, the method, apparatus and program of anyone or combination of paragraphs [0094] through [0102] above, wherein the information added to the stored constellation database from the neighbor access node's constellation database comprises identifiers for each access node detected by the neighbor access node and alternatively also location information associated with at least some of the identifiers.

[00104] In an exemplary embodiment, the method, apparatus and program of any one or combination of paragraphs [0094] through [0103] above, wherein the constellation database comprises azimuth information associated with at least one of the identifiers for one of the detected neighbor access nodes. In this embodiment, the azimuth information is attached to civic location information and provided to the database outside the network, and/or the azimuth information attached to the civic location information may be sent to and/or received from the at least one neighbor access node during the constellation database exchange.

[00105] According to the above detailed examples then it will be appreciated that in an exemplary embodiment of the invention from the perspective of an external database such as a server there is a method, and an apparatus, and a memory storing a computer program which when executed by a processor result in actions comprising receiving from individual ones of a plurality of access nodes a local constellation database comprising identifiers of neighbor access nodes; and for at least one identifier calculating location information for the node associated with the at least one identifier and storing in a memory the calculated location information in association with the at least one identifier.

[00106] In an exemplary embodiment according to paragraph [0105] above, the received constellation database also comprises location information associated with identifiers for at least some of the neighbor nodes, and the location information is calculated for at least one of the nodes associates with an identifier for which there is no received location information.

[00107] In an exemplary embodiment, the method, apparatus and program of any one or combination of paragraphs [0105] through [0106] above, wherein the calculating uses information from at least some of the received local constellation databases.

[00108] In an exemplary embodiment, the method, apparatus and program of any one or combination of paragraphs [0105] through [0107] above, wherein calculating comprising estimating one of a civic or geographic location by triangulating or trilateralizing from location information received in the said some of the local constellation databases.

[00109] In an exemplary embodiment, the method, apparatus and program of any one or combination of paragraphs [0105] through [0108] above, further comprising providing the estimated location information to a non-access point station which is associated with one of the plurality of access nodes.

[00110] In an exemplary embodiment, the method, apparatus and program of any one or combination of paragraphs [0105] through [0109] above, further comprising providing the estimated location information to the access node for which it was calculated.

[00111] In an exemplary embodiment, the method, apparatus and program of any one or combination of paragraphs [0105] through [01 10] above, further comprising providing the estimated location information to each of the plurality of access nodes.

[00112] In general, the various exemplary embodiments may be implemented in hardware or special purpose circuits such as for example a semiconductor chip or chipset or general purpose processor with or without associated transmitter and/or receiver and/or antenna(s), software, logic or any combination thereof. For example, some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device, although the invention is not limited thereto. While various aspects of the exemplary embodiments of this invention may be illustrated and described as block diagrams, flow charts, signaling diagram or some other pictorial representation, it is well understood that these blocks, apparatus, systems, techniques or methods described herein may be implemented in, as nonlimiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

[00113] It should thus be appreciated that at least some aspects of the exemplary embodiments of the inventions may be practiced in various components such as integrated circuit chips and modules, and that the exemplary embodiments of this invention may be realized in an apparatus that is embodied as an integrated circuit. The integrated circuit, or circuits, may comprise circuitry (as well as possibly firmware) for embodying at least one or more of a data processor or data processors, a digital signal processor or processors, baseband circuitry and radio frequency circuitry that are configurable so as to operate in accordance with the exemplary embodiments of this invention.

[00114] Various modifications and adaptations to the foregoing exemplary embodiments of this invention may become apparent to those skilled in the relevant arts in view of the foregoing description, when read in conjunction with the accompanying drawings. However, any and all modifications will still fall within the scope of the non-limiting and exemplary embodiments of this invention.

[00115] It should be noted that the terms "connected," "coupled," or any variant thereof, mean any connection or coupling, either direct or indirect, between two or more elements, and may encompass the presence of one or more intermediate elements between two elements that are "connected" or "coupled" together. The coupling or connection between the elements can be physical, logical, or a combination thereof. As employed herein two elements may be considered to be "connected" or "coupled" together by the use of one or more wires, cables and/or printed electrical connections, as well as by the use of electromagnetic energy, such as electromagnetic energy having wavelengths in the radio frequency region, the microwave region and the optical (both visible and invisible) region, as several non- limiting and non-exhaustive examples.

Furthermore, some of the features of the various non-limiting and exemplary embodiments of this invention may be used to advantage without the corresponding use of other features. As such, the foregoing description should be considered as merely illustrative of the principles, teachings and exemplary embodiments of this invention, and not in limitation thereof.

Claims

Claims:

1. A method comprising: detecting neighbor access nodes; requesting location information from at least some of the detected neighbor access nodes and receiving from the respective neighbor access nodes the requested location information; and storing in a local memory a constellation database comprising identifiers for the detected neighbor access nodes and location information for at least some of the detected neighbor access nodes.

2. The method according to claim 1 , further comprising at least one of: sending at least a portion of the constellation database to a database outside the network in which the access nodes lie; and exchanging the constellation database stored in the local memory with at least one of the neighbor access node's constellation database and adding information from the neighbor access node's constellation database to the stored constellation database.

3. The method according to any one of claims 1 or 2, in which there remains in the constellation database at least one identifier which is not associated with location information.

4. The method according to any one of claims 1 or 2, wherein the constellation database stored in the local memory comprises a capabilities list received from at least one of the detected neighbor nodes and associated with the identifier for the said at least one detected neighbor node.

5. A memory storing a computer program which when executed by a processor result in actions comprising: detecting neighbor access nodes; requesting location information from at least some of the detected neighbor access nodes and receiving from the respective neighbor access nodes the requested location information; and storing in a local memory a constellation database comprising identifiers for the detected neighbor access nodes and location information for at least some of the detected neighbor access nodes.

6. The memory according to claim 5, the actions further comprising at least one of: sending at least a portion of the constellation database to a database outside the network in which the access nodes lie; and exchanging the constellation database stored in the local memory with at least one of the neighbor access node's constellation database and adding information from the neighbor access node's constellation database to the stored constellation database.

7. An apparatus comprising: at least one processor; and at least one memory storing computer program code configured to, with the at least one processor, cause the apparatus at least to perform: detecting neighbor access nodes; requesting location information from at least some of the detected neighbor access nodes and receiving from the respective neighbor access nodes the requested location information; and storing in a local memory a constellation database comprising identifiers for the detected neighbor access nodes and location information for at least some of the detected neighbor access nodes.

8. The apparatus according to claim 7, in which the memory storing computer program code is configured with the at least one processor to cause the apparatus at least to further perform at least one of: sending at least a portion of the constellation database to a database outside the network in which the access nodes lie; and exchanging the constellation database stored in the local memory with at least one of the neighbor access node's constellation database and adding information from the neighbor access node's constellation database to the stored constellation database.

9. The apparatus according to any one of claims 7 or 8, in which there remains in the constellation database at least one identifier which is not associated with location information.

10. The apparatus according to any one of claims 7 or 8, wherein the constellation database stored in the memory comprises a capabilities list received from at least one of the detected neighbor nodes and associated with the identifier for the said at least one detected neighbor node.

11. A method comprising: receiving from individual ones of a plurality of access nodes a local constellation database comprising identifiers of neighbor access nodes; and for at least one of the identifiers, calculating location information for the node associated with the at least one identifier and storing in a computer readable memory the calculated location information in association with the at least one identifier.

12. The method according to claim 11 , wherein the calculating uses information from at least some of the received local constellation databases.

13. The method according to claim 12, wherein the calculating comprises estimating one of a civic or geographic location by at least one of triangulating and trilateral izing from location information received in the said some of the local constellation databases.

14. The method according to any one of claims 11 through 13, wherein the received constellation database comprises location information associated with identifiers for at least some of the neighbor nodes, and the location information is calculated for each of the nodes that are associated with an identifier for which there is no received location information.

15. A memory storing a computer program which when executed by a processor result in actions comprising: receiving from individual ones of a plurality of access nodes a local constellation database comprising identifiers of neighbor access nodes; and for at least one identifier, calculating location information for the node associated with the at least one identifier and storing in a memory the calculated location information in association with the at least one identifier.

16. The memory according to claim 15, wherein the calculating uses information from at least some of the received local constellation databases.

17. An apparatus comprising: at least one processor; and at least one memory storing computer program code configured to, with the at least one processor, cause the apparatus at least to perform: receiving from individual ones of a plurality of access nodes a local constellation database comprising identifiers of neighbor access nodes; and for at least one identifier, calculating location information for the node associated with the at least one identifier and storing in a memory the calculated location information in association with the at least one identifier.

18. The apparatus according to claim 17, wherein the calculating uses information from at least some of the received local constellation databases.

19. The apparatus according to claim 18, wherein the calculating comprises estimating one of a civic or geographic location by at least one of triangulating and trilateral izing from location information received in the said some of the local constellation databases.

20. The apparatus according to any one of claims 17 through 19, wherein the received constellation database comprises location information associated with identifiers for at least some of the neighbor nodes, and the location information is calculated for each of the nodes that are associated with an identifier for which there is no received location information.