WO2018069181A1

WO2018069181A1 - Network entities, a wireless communication system and a method for refining a relationship between multiple presence cells

Info

Publication number: WO2018069181A1
Application number: PCT/EP2017/075494
Authority: WO
Inventors: James Harrow
Original assignee: Ip.Access Limited
Priority date: 2016-10-14
Filing date: 2017-10-06
Publication date: 2018-04-19
Also published as: GB2555102A; GB201617441D0

Abstract

A method for refining a relationship between multiple Presence Cells in a wireless communication system is described. The method comprises, at a controller: maintaining a Presence Cell list of relationships between multiple Presence cells in the wireless communication system; sending each of a plurality of Presence Cells a frequency of another Presence Cell from the Presence Cell list; causing an access attempt of a wireless communication unit to be re-directed from a first Presence cell to a selected second Presence cell from the multiple Presence Cells based on the frequency sent to the first Presence cell; obtaining information from the selected second Presence cell related to the respective access attempt; forming a relationship value between the first Presence cell and the selected second Presence cell based on the obtained information; and refining the relationship value in the Presence Cell list upon repeating the operation of causing further access attempts and obtaining information following the further access attempts.

Description

NETWORK ENTITIES, A WIRELESS COMMUNICATION SYSTEM AND A METHOD FOR REFINING A RELATIONSHIP BETWEEN MULTIPLE PRESENCE CELLS

Field of the invention

The field of this invention relates to network entities, a wireless communication system and methods therefor and particularly to a method for refining a relationship between multiple Presence Cells in a wireless communication system.

Background of the Invention

Wireless communication systems, such as the 3^rd Generation (3G) of mobile telephone standards and technology, are well known. An example of such 3G standards and technology is the Universal Mobile Telecommunications System (UMTS™), developed by the 3^rd Generation Partnership Project (3GPP™) (www.3gpp.orq). The 3^rd generation of wireless communications has generally been developed to support macro-cell mobile phone communications. Such macro cells utilise high power base stations (NodeBs in 3GPP™ parlance) to communicate with wireless communication units within a relatively large geographical coverage area. Typically, mobile wireless communication units, or User Equipment (UEs) as they are often referred to in 3G parlance, communicate with a Core Network (CN) of the 3G wireless communication system via a Radio Network Subsystem (RNS). A wireless communication system typically comprises a plurality of radio network subsystems, each radio network subsystem comprising one or more cells to which UEs may attach, and thereby connect to other communication units within, or through, the wireless communication system. 3GPP™ also has developed a 4G Long Term Evolution (LTE) solution, namely, an Evolved Universal Mobile Telecommunication System Territorial Radio Access Network, (E-UTRAN), for a mobile access network, and a System Architecture Evolution (SAE) solution, namely, an Evolved Packet Core (EPC), for a mobile core network.

User Equipment (UE) can access a core network through a 2G,3G or 4G RAN such as the (Enhanced Data Rate for GSM Evolution, EDGE) Radio Access Network (Radio Access Network, GERAN) or a Universal Mobile Telecommunication System Terrestrial Radio Access Network (Universal Mobile Telecommunication System Terrestrial Radio Access Network, UTRAN), and access the EPC through the E-UTRAN. Generally, the Core Network is responsible for switching and routing voice calls and data to and from wired telephone networks or the Internet. A RAN is located between the Core Network and the UE.

Operators are seeking to exploit their radio spectrum by providing micro-location based tracking of anonymised UEs in their networks. The operators already provide large-scale macro location insights using probes to monitor which UEs are using which macro cells and then combine this with other data sources (such as their Customer Relationship Management (CRM) information, billing data and the web sites that the users visit). By combining these data sets in an anonymised form they can provide valuable data insights into what type of consumer visits which areas and what their typical journeys are. These can be provided to governments and transportation providers in order to assist with planning future capacity requirements or to aid in optimising of traffic routes.

Lower power (and therefore smaller coverage area) cells are a recent development within the field of wireless cellular communication systems. Such small cells are effectively communication coverage areas supported by low power base stations. The terms 'picocell' and 'femtocell' are often used to mean a cell with a small coverage area, with the term femtocell being more commonly used with reference to residential small cells. Herein, the term 'small cell' means any cell having a relatively small coverage area (a coverage area less than a typical macro cell) and includes picocells and femtocells. The low power base stations that support small cells are referred to as Access Points (APs), with the term Home Node B (HNBs) or Home evolved Node B (HeNB) identifying femtocell access points. These small cells are intended to augment the wide area macrocell network and support communications to User Equipment in a restricted, for example, indoor environment. An additional benefit of small cells is that they can offload traffic from the macrocell network, thereby freeing up valuable macrocell network resources.

With the increasing use of small cell HNB type devices instead of macro cells the Operators can now provide location data at a much finer granularity. Recently, it is noted that retailers also want to know where a mobile wireless communication unit, such as a UE/smartphone, is located within an indoor environment, say within their specific shop. This has numerous retail applications, such as allowing a retailer to have insight into the type of people who frequent their stores (based on anonymous aggregated sightings). The use of HNB-type devices being configured to provide location information is often referred to the HNB functioning as a 'Presence Cell', which works much like a HNB operating in a closed access mode. In this manner, the HNB appears like any other cell in the Operator's network in terms of UE reselection behaviour. The standard operation of a UE is to attempt to use the strongest (i.e. nearest) small cell to initiate its RRC Connection Request to, irrespective of whether or not this small cell has functionality to be re-configured as a Presence Cell. As such, the Presence Cell would first ask UEs trying to access it for their unique identity and would then reject the UE back to the normal macro network. In this manner, the UE's unique identity, together with a timestamp and location (based on the fact that the coverage area of the Presence Cell is relatively small), may be obtained and provided to a presence collector to be passed to the retailer.

However, this information is presently obtained in an ad hoc manner, i.e. based on the UE's selection of the small cell to attempt to access to the network. Furthermore, although vastly superior to a macro cell, the location accuracy provided by a single Presence Cell may not be as accurate as desired due to 'signal leakage' and the, somewhat, unpredictable nature of radio propagation.

Thus, a need exists for an improved method, wireless communication system and apparatus to obtain improved and more structured location information through a presence cell, which mitigates the aforementioned disadvantages. Summary of the invention

Aspects of the invention provide a method for refining a relationship between multiple Presence Cells in a wireless communication system as described in the appended claims.

In a first aspect of the invention, a method for refining a relationship between multiple

Presence Cells in a wireless communication system is described. The method comprises, at a controller: maintaining a Presence Cell list of relationships between multiple Presence cells in the wireless communication system; sending each of a plurality of Presence Cells a frequency of another Presence Cell from the Presence Cell list; causing an access attempt of a wireless communication unit to be re-directed from a first Presence cell to a selected second Presence cell from the multiple Presence Cells based on the frequency sent to the first Presence cell; obtaining information from the selected second Presence cell related to the respective access attempt; forming a relationship value between the first Presence cell and the selected second Presence cell based on the obtained information; and refining the relationship value in the Presence Cell list upon repeating the operation of causing further access attempts and obtaining information following the further access attempts.

In this manner, a mechanism is provided that allows relationships to be developed between Presence Cells, so that they can gain an appreciation of neighbouring Presence Cells and thereby refine a Presence Cell list.

In an optional example, causing an access attempt and obtaining information from selected Presence cells may be repeated multiple times, for multiple presence cells and multiple wireless communication units in order to refine relationships between multiple presence cells. In an optional example, the controller may be a cluster controller coupled to a plurality of presence cells configured in a cluster, and refining a relationship value between cells may comprise automatically learning those cells that are closely located to one another. In an optional example, refining a relationship value between cells may comprise automatically learning those cells that are closely located to one another to provide an improved chance of obtaining presence sighting information following a redirection instruction to a wireless communication unit.

In an optional example, refining a relationship value between cells may comprise creating a list of a set of re-direction rules between cells, and instructing one or more wireless communication units to attempt access to presence cells according to each set of re-direction rules in a random manner in order to measure a likelihood of success. In an optional example, the obtaining of information from the selected first presence cell may comprise obtaining a quality metric relayed from the wireless communication unit and using the quality metric to bias a location estimation relationship value between cells when refining the relationship value. In an optional example, the quality metric may comprise a received signal code power, RSCP, value. In an optional example, the method may further comprise updating the set of redirection rules based on real measurements performed by one or more wireless communication units.

In an optional example, refining a relationship value between cells comprises re-organising a presence list by lowering a priority status or swapping Presence cells that are less useful based on wireless communication unit measurements. In an optional example, the method may further comprise halting a re-organising of the presence list upon determining that the presence list has evolved to a steady state position.

In an optional example, causing an access attempt of a wireless communication unit to be re- directed from a first Presence cell to a selected second Presence cell from the multiple Presence Cells may comprise sending a radio resource control, RRC, reject with re-direction message to at least one wireless communication unit. In some examples, the method may further comprise monitoring and interpreting access attempts by one or more wireless communication units based on an identifier of the wireless communication unit and using the wireless communication unit information to determine an order to adapt the Presence list. In an optional example, the method may further comprise monitoring and interpreting access attempts by one or more wireless communication units based on historical information on a success or failure of wireless communication unit attempts for particular cells.

In an optional example, the method may further comprise applying at least one threshold to at least one of: a time limit to the causing and obtaining operations; a number of Cells to obtain information from; a low received signal value threshold.

In an optional example, the method may further comprise adapting the Presence Cell list related to relationships between multiple cells in response to at least one of the multiple cells failing to record a sighting of the wireless communication unit. In an optional example, the method may further comprise autonomously adapting the Presence Cell list in response to installation, deactivation or relocation of Presence Cells.

According to a second aspect of the invention, a controller for refining a relationship between multiple Presence Cells in a wireless communication system is described. The controller comprises a transceiver and a signal processor, operably coupled to the transceiver and configured to: maintain a Presence Cell list of relationships between multiple Presence cells in the wireless communication system; send each of a plurality of Presence Cells a frequency of another Presence Cell from the Presence Cell list; cause an access attempt of a wireless communication unit to be re-directed from a first Presence cell to a selected second Presence cell from the multiple Presence Cells based on the frequency sent to the first Presence cell; obtain information from the selected second Presence cell related to the respective access attempt; form a relationship value between the first Presence cell and the selected second Presence cell based on the obtained information; and refine the relationship value in the Presence Cell list upon repeating the operation of causing further access attempts and obtaining information following the further access attempts.

According to a third aspect of the invention, a wireless communication system is described. The wireless communication system comprises a plurality of presence cells operably coupled to a controller, the controller comprising a transceiver and a signal processor, operably coupled to the transceiver and configured to: maintain a Presence Cell list of relationships between multiple Presence cells in the wireless communication system; send each of a plurality of Presence Cells a frequency of another Presence Cell from the Presence Cell list; cause an access attempt of a wireless communication unit to be re-directed from a first Presence cell to a selected second Presence cell from the multiple Presence Cells based on the frequency sent to the first Presence cell; obtain information from the selected second Presence cell related to the respective access attempt; form a relationship value between the first Presence cell and the selected second Presence cell based on the obtained information; and refine the relationship value in the Presence Cell list upon repeating the operation of causing further access attempts and obtaining information following the further access attempts.

These and other aspects, features and advantages of the invention will be apparent from, and elucidated with reference to, the embodiments described hereinafter.

Brief Description of the Drawings

Further details, aspects and embodiments of the invention will be described, by way of example only, with reference to the drawings. Elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. Like reference numerals have been included in the respective drawings to ease understanding.

FIG. 1 illustrates a part of an example wireless communication system comprising a macro core network and small cells, with at least a plurality of small cells being configured to operate as presence cells and, as such, coupled to a presence collector and presence controller, in accordance with an example embodiment of the invention.

FIG. 2 illustrates an example block diagram of a base station (for example a HNB functioning as a presence cell) configured to operate in accordance with an example embodiment of the invention.

FIG. 3 illustrates an example flowchart of a method of forced re-direction of mobile handset access requests to assist a location determination in accordance with an example embodiment of the invention.

FIG. 4 illustrates a frequency-based diagram of a carrier usage in an example wireless communication system in accordance with an example embodiment of the invention.

FIG. 5 illustrates an example cell-based diagram of a position estimation scheme with a single Cell, in accordance with an example embodiment of the invention

FIG. 6 illustrates an example cell-based diagram of a position estimation scheme with two Cells, in accordance with an example embodiment of the invention.

FIG. 7 illustrates an example cell-based diagram of a position estimation scheme with three Cells, in accordance with an example embodiment of the invention.

FIG 8 illustrates an example cell-based diagram of a cluster controller of multiple Cells, in accordance with an example embodiment of the invention.

FIG 9 illustrates an example flowchart of how a Cluster Controller can automatically learn which cells are closely located and have the maximum chance of getting sightings after a redirection attempt, in accordance with an example embodiment of the invention. Detailed Description

Examples of the invention describe a method for refining a relationship between multiple presence Cells in a wireless communication system. The method comprises, at a controller: maintaining a Presence Cell list of relationships between multiple Presence cells in the wireless communication system; sending each of a plurality of Presence Cells a frequency of another Presence Cell from the Presence Cell list; causing an access attempt of a wireless communication unit to be redirected from a first Presence cell to a selected second Presence cell from the multiple Presence Cells based on the frequency sent to the first Presence cell; obtaining information from the selected second Presence cell related to the respective access attempt; forming a relationship value between the first Presence cell and the selected second Presence cell based on the obtained information; and refining the relationship value in the Presence Cell list upon repeating the operation of causing further access attempts and obtaining information following the further access attempts.

In this manner, by causing repeated access attempts of a wireless communication unit via multiple presence cells, the repeated presence cell attempts and the information obtained therefrom allow location relationships to be developed between Presence Cells, so that they can each gain an appreciation of neighbouring Presence Cells. Thereafter, for example a Presence Cell list of neighbouring presence cells may be refined.

Although examples of the invention are described with reference to a use by small cells re- configured as Presence cells, it is envisaged that some examples may be employed by small cells or other cells, for other applications. One such envisaged example application is in the context of an enterprise environment, where for example an employer may want to identify where employees are and then uses the example embodiments described herein for location relationships of neighbouring presence cells to assist coverage/capacity (e.g. voice /data calls) support.

Currently, it is noted that only one Presence Cell is typically deployed by itself, due to the random interactions that would be caused if multiple Presence Cell were deployed in a similar location. However, the inventor of the present invention has recognised that if presence cells were arranged in a cluster (e.g. in a grid-type structure, as described with reference to FIG. 8) then, as part of the process of performing a location update request, the UE would report the CPICH RSCP at RACH, which is included in the RRC Connection Request message to the Node B.

In examples of the invention, a first cell, such as a small cell that may be re-configured as a Presence Cell, is arranged to accept a UE Connection Request message and send a RRC Connection Setup message to the UE. Thereafter, in some examples, the UE will send an RRC Connection Setup Complete message back to the first cell, e.g. the Presence Cell. The UE will typically wish to perform a Location Update Request due to the Presence Cell having a different Location Area Code (LAC) from the macro cell that it was previously camped onto. The first cell, e.g. Presence Cell, will send an Identity Request to ask the UE for its IMSI and may optionally also ask the UE for its IMEI. Once the UE responds with its IMSI, and optionally IMEI, the Presence Cell will send the UE a Location Update Reject message. Thereafter, if the first Presence Cell knew about nearby, neighbouring cells (NCells) that were configurable as, or functioning as, other Presence Cells, then the first Presence Cell may send an RRC Connection Release that includes Redirection Information, in order to direct the UE to one of the other Presence Cells in the vicinity.

In examples of the invention, if the UE detected the second Presence Cell, it will send an RRC

Connection Setup message and will include its TMSI and CPICH RSCP measurement of the second Presence Cell. Instead of accepting the UE (by means of sending it an RRC Connection Setup message), in accordance with examples of the invention, the second Presence Cell is configured to send the UE an RRC Reject with Re-direction message towards a third Presence Cell. Similarly if the UE detects the third Presence Cell then it may also attempt to access the third Presence cell and would send its TMSI and CPICH RSCP measurement. Again the third Presence Cell may decide to send RRC Connection Reject with Redirection Info message to either another nearby fourth Presence Cell or it may redirect the UE back towards the macro network, in order to ensure that the UE is not disconnected from the macro network for too long in case there are incoming calls for that UE which may be missed. In other examples, the re-direction messages may comprise (multiple) RRC Connection Reject messages.

In examples of the present invention, the term 'co-located' is used to encompass the pCells being in close physical proximity to one another, typically within a distance between pCells measured in meters or a few tens of meters.

Examples of the invention propose a mechanism for a first presence cell to cause a second presence cell to perform a redirection of a wireless communication unit, the wireless communication unit will only measure the RSCP of the second presence cell and not of all the pcells in the close proximity. When the wireless communication unit moves out from the macro coverage and reselects the first presence cell it runs an extended reselection criteria and with the access attempt can send the RSCPs of all the surrounding Pcells with reasonable signal strength (for example those RSCPs that meet the reselection S criteria when a SIB 1 1 is broadcasted by the presence cell to report intra and inter frequency neighbours).

Further examples of the invention propose a mechanism to avoid the relative apriori known positioning of Presence Cells by describing a mechanism for the system to self-learn from system installation and autonomously adapt to locations of Presence Cells as they are installed, deactivated or re-located.

Some examples of the inventive concept find applicability in a wireless communication system comprising a presence collector.

Those skilled in the art will recognise and appreciate that the specifics of the specific examples described are merely illustrative of some embodiments and that the teachings set forth herein are applicable in a variety of alternative settings. For example, implementations within cellular communication systems conforming to different standards are contemplated and are within the scope of the various teachings described. Location information of a UE obtained through a targeted re-direction of multiple access attempts for the UE.

Referring now to FIG. 1 , an example of part of a 3G wireless communication system comprising a macro core network and a number of small cells, with at least a plurality of small cells being configured to operate as, is illustrated in accordance with an example embodiment of the invention. The wireless communication system is illustrated and indicated generally at 100, referred to as a 'core network connected mode' and comprises a Node B 102 that supports wireless communications in a macro cell. The Node B 102 is connected with a radio network controller (RNC) 104, which in turn is linked with a Core Network 106 that includes a Mobile Switching Centre and other conventional network elements or subsystems (not shown). The MSC of the Core Network 106 routes services for both the small cell and macro cell networks of FIG.1 .

A plurality of small cells is supported in the wireless communication system, with communication within the small cell being provided by HNBs. An example of a typical HNB for use within a 3GPP 3G system may comprise Node-B functionality and some aspects of RNC functionality, as specified in 3GPP TS 25.467. The HNBs provide a radio access network (RAN) connectivity to the UE 108 using the so-called luh interface to a network Access Controller, also known as a Home NodeB Gateway (HNB-GW) (not shown), which in turn is connected to the MSC of the Core Network 106. The HNBs, as represented in FIG. 1 , are configurable to function as Presence Cells 1 10, 120, 130, with only three being shown for the sake of clarity and simplicity. The Presence Cells 1 10, 120, 130 are coupled to a presence collector 160 via a local presence controller 150.

A User Equipment (UE) 108 may roam in and out of the coverage areas of the Node B 102 or the pCells 1 10, 120, or 130 and may attempt to perform a Location Update Request to any one of these pCells. The pCells upon receipt of a RRC Connection Request and Location Updated Request will request the UE identity (IMSI) and will then send a Location Update Reject and in doing so redirect the UE back to the Node B. The local presence Controller 150 is configured to generate a location presence notification message and send this to a presence collector 160 each time it receives a registration request from a UE 108 via any one of the Presence cells 1 10, 120, 130 to which it is linked. A location presence notification message contains information relating to the identity of the UE 108 (e.g. it's IMSI) and the identity of the Presence Cell that received the initial request for registration.

In accordance with examples of the invention, a first RRC set-up request message 170 is sent from UE 108 to first presence cell (pCell) 1 10. In response, the first presence cell accepts the connection and expects to receive a Location Update Request message. The first presence cell in receiving a Location Update Request, asks the UE for its IMSI and optionally IMEI by sending an Identity Request. The first presence cell then may send a Location Update Reject message to the UE and release the RRC connection using, a RRC Connection Release with redirection message 172 is returned from first pCell 1 10 to UE 108, re-directing the UE 108 to request access to a further pCell from an identified pCell redirection list. In response to the first RRC Connection Release with redirection message 172, the UE 108 detects pCell 120 and sends a second RRC Request message 174 to second pCell 120. This time, in response, a RRC Connection Reject with redirection message 176 is returned from second pCell 120 to UE 108, re-directing the UE 108 to request access to a further pCell 130 from the identified pCell redirection list. In response to the second RRC Connection Reject with redirection message 176, the UE 108 sends a third RRC Connection Request message 178 to third pCell 130. Again, in response, a third RRC reject with redirection message 180 is returned from third pCell 130 to UE 108, re-directing the UE 108 to request access, say, via NodeB 102. In this manner, the third pCell has realised, or is informed, that a sufficient number of pCell access attempts has been performed by the UE 108, such an accurate location determination, say through triangulation, can be performed from the previous pCell attempts. Hence, in this example, and from the identified pCell redirection list, the final redirection message may be to return to an appropriate macro cell NodeB, such as NodeB 102.

In some examples, the local presence cluster controller 150 may be a local server device or a Presence Cell dedicated as a master Presence Cell to co-ordinate other Presence Cells located around it. In some examples, the local presence (cluster) controller 150 may be configured to control a cluster of Presence Cells, such as Presence Cells 110, 120, 130. In this regard, the local presence cluster controller 150 is configured to inform the associated Presence Cell of which of its neighbours to redirect to, for example with a RRC Connection Release with Re-direction message or multiple RRC Connection Reject with Re-direction messages. In this manner, a more controlled and intelligent redirection technique is provided.

In some examples, local presence cluster controller 150 may comprise a processor or controller 152 arranged to control and update one or more Presence Cell RRC re-direction lists stored in memory 158 for sending to the Presence cells 1 10, 120, 130. In some examples, the processor or controller 152 may comprise, or be coupled to a timer or counter 154, and be configured to apply time limits to the RRC redirection process. In some examples, the processor or controller 152 may be used to limit how many Presence cells are used as part of the mini cluster, thereby avoiding relatively long periods where the UE 108 is off the macro network.

In some examples, the processor or controller 152 of the local presence cluster controller 150 may use the timer or counter 154 to coordinate a cluster wide view of the system. First, for example, the timer or counter 154 may be used to prevent UEs being handed around the cluster indefinitely. Secondly, the timer or counter 154 may be used to avoid processing a UE a second time (within a certain time period) should it appear on a different pCell.

In some examples, the processor or controller 152 may be coupled to a timer or counter 154 and a threshold detection circuit 156. In one example, the timer or counter 154 is configured to track a number of RRC Connection Reject with redirection messages that are sent to UE 108, so that a number of access attempts and rejections can be controlled if the threshold detection circuit 156 detects that the number has exceeded a value, e.g. three cells. In some examples, the processor or controller 152 of the local presence cluster controller 150 may be configured to adapt a number of RRC Connection Reject with redirection messages that it proposes for a specific UE 108 based on, say, the UE's estimated position. For example, if the initial CPICH RSCP reading from a first Presence Cell (pCell 1 ) was weak and below a power threshold determined by threshold detection circuit 156, and it was known or suspected that pCell 1 was on the edge of a cluster, the processor or controller 152 of the local presence cluster controller 150 may decide that it is too risky (or of too little potential value) to RRC Redirect the UE 108 to another Presence Cell in the cluster. In this instance, for example, the processor or controller 152 of the local presence cluster controller 150 may deem that it is safer and more efficient with regard to use of the available communication resource to redirect the UE 108 back to the macro cell network and for it to access NodeB 102.

Alternatively, in another example, the local presence cluster controller may also decide that after two sightings of the UE 108, say based on CPICH RSCP signal measurements from two respective Presence Cells, the position of the UE 108 is now further disambiguated. In this instance, processor or controller 152 of the local presence cluster controller 150 may decide that there is no other Presence Cell in the cluster that the local presence cluster controller 150 should try to obtain more presence-related data from and abandon the location validation or accuracy improvement process. In this case, the processor or controller 152 of the local presence cluster controller 150 may also decide to redirect the UE 108 back to the macro cell network instead of attempt a third presence cell (pCell) access. Thus, in this instance, only the two Presence Cell sightings of the UE 108, for example based on CPICH RSCP signal measurements, will be used in validating or more accurately determining a location of the UE 108. Referring now to FIG. 2, a block diagram of a wireless communication unit, adapted in accordance with some example embodiments of the invention, is shown. In practice, purely for the purposes of explaining embodiments of the invention, the wireless communication unit is described in terms of a wireless base station 200, such as a HNB configured to operate as a Presence Cell, such as pCell 130 in FIG. 1 . The base station 200 contains an antenna 202, antenna array, or plurality of antennas for receiving and transmitting signals 221 coupled to an antenna switch or duplexer 204 that provides isolation between receive and transmit chains within the base station 200. One or more receiver chains, as known in the art, include receiver front-end circuitry 206 (effectively providing reception, filtering and intermediate or base-band frequency conversion). The receiver front-end circuitry 206 is coupled to a signal processor 228 (generally realized by a digital signal processor (DSP)). A skilled artisan will appreciate that the level of integration of receiver circuits or components may be, in some instances, implementation-dependent.

The controller 214 maintains overall operational control of the base station 200. The controller 214 is also coupled to the receiver front-end circuitry 206 and the signal processor 228. In some examples, the controller 214 is also coupled to a buffer module 217 and a memory circuit 216 that selectively stores operating regimes, such as decoding/encoding functions, synchronization patterns, code sequences, and the like, as well as information related to UEs that it is communicating with. A timer 218 is operably coupled to the controller 214 to control the timing of operations (e.g. transmission or reception of time-dependent signals) within the base station 200. As regards the transmit chain, this essentially includes an input module 240, coupled in series through transmitter/modulation circuitry 222 and a power amplifier 224 to the antenna 202, antenna array, or plurality of antennas. The transmitter/ modulation circuitry 222 and the power amplifier 224 are operationally responsive to the controller 214.

In accordance with examples of the invention, base station 200 is configured such that the transmitter and receiver circuits (often referred to as a transceiver) are configured to communicate with a plurality of mobile handsets, e.g. users of UEs 108 from FIG. 1 . In some examples, the signal processor 228 or controller 214 is able to re-configure the base station 200 as a presence cell. The signal processor 228 (in operation with the receiver front-end circuitry 206 and associated radio frequency circuits) receives a connection request message, say in a form of a RRC Connection Req. message, from a wireless communication unit, such as UE 108 from FIG. 1 . In some examples, the RRC connection request message transmitted on the random access channel (RACH) may include a common pilot channel (CPICH) received signal code power (RSCP) level that the UE measured from a transmission by the base station 200, as well as the UE's temporary mobile subscriber identity (TMSI). Here, the base station 200 is in a RRC Connected mode in order to receive the Location Update Request and attempt to get the IMSI/IMEI. The signal processor 228 (in operation with the receiver front-end circuitry 206 and associated radio frequency circuits) then, in some examples, is configured to determine whether (or not) a UE that sends a RRC Connection Request message should be accepted in a normal manner, or whether the UE should be redirected in accordance with the examples herein described.

In some examples, this determination by the signal processor 228 involves the signal processor 228 using the known TMSI from the local presence controller and a count of how many recent sightings of this same TMSI that the local presence controller has seen, say in the last 5 seconds. In this manner, the base station 200 may avoid an occurrence of continuous redirection amongst other base stations/pCells. In some examples, the signal processor 228 includes, or is operably coupled to, a counter circuit 240 that is configured to count a number of recent sightings of this same TMSI that the local presence controller has seen. In this manner, base station 200 configured as a pCell is able to limit the number of access attempts it responds to, and the interactions it triggers with the Presence Controller, say Presence Controller 150 of FIG. 1 .

In response to a RRC Connection Request message, the signal processor 228 (in operation with the transmitter/ modulation circuitry 222 and the power amplifier 224) sends an RRC Connection Setup message to the UE. In response to the RRC Connection Setup the UE sends a RRC Connection Setup Complete message, and may then send a Location Update Request to the pCell. In response thereto, the signal processor 228 (in operation with the transmitter/ modulation circuitry 222 and the power amplifier 224) sends an Identity Request (IMSI) message to the wireless communication unit. In response, the signal processor 228 (in operation with the receiver front-end circuitry 206 and associated radio frequency circuits) receives an Identity Response (IMSI) message. The signal processor 228 (in operation with the transmitter/ modulation circuitry 222 and the power amplifier 224) then sends an Identity Request (IMEI) to the wireless communication unit and receives, in response, the wireless communication unit's Identity Response (IMEI). At this point, and in accordance with examples of the invention and as directed by the Local Presence controller, the signal processor 228 sends a Location Update Reject message and includes an RRC Connection Release with Redirect Info to a new UTRA absolute radio frequency channel number (UARFCN) of a second Presence Cell (such as pCell 120 of FIG. 1 ) for the wireless communication unit to attempt access to. In some examples, the signal processor 228 may implement this re-direction after performing a location update (LU) reject operation, as part of a RRC Connection Release (e.g. redirect) operation.

In accordance with examples of the invention, memory circuit 216, operably coupled to the signal processor 228, may be configured to store details of the redirection to the next base station/presence cell, in accordance with a re-direction list (such as a RRC redirection list) controlled by the presence controller.

The signal processor 228 in the transmit chain may be implemented as distinct from the signal processor in the receive chain. Alternatively, a single processor may be used to implement a processing of both transmit and receive signals, as shown in FIG. 2. Clearly, the various components within the base station 200 can be realized in discrete or integrated component form, with an ultimate structure therefore being an application-specific or design selection.

FIG. 3 illustrates a simplified flowchart 300 of a method of forced re-direction of mobile handset access requests to assist a location determination of a UE in accordance with an example embodiment of the invention. In some examples, if the UE is a Release-6 or later UE, then the pCell may implement this re-direction after performing a location update (LU) reject operation, as part of a RRC Connection Release (e.g. redirect) operation.

At 302, a UE, such as UE 108 of FIG. 1 , is already registered on macro cell NodeB 102 and detects a first small cell, such as an HNB, configured to operate as a Presence cell (e.g. first pCell 1 10 from FIG. 1 ). At 304, the UE 108 attempts to send a connection request message on a random access channel (RACH), say in a form of a RRC Connection Req. message, to first pCell 1 10 and includes a common pilot channel (CPICH) received signal code power (RSCP) level that the UE measured of the transmission of the first pCell 1 10 and the UE's temporary mobile subscriber identity (TMSI).

At 305, the first pCell 1 10, admits the UE by sending an RRC Connection Setup message to the UE 108. The UE 108 then completes the RRC Connection and sends a Location Update Request.

At 306, the first pCell 1 10 sends an Identity Request (IMSI) message to UE 108. In response, at 308, the UE 108 sends an Identity Response (IMSI) message to first pCell 1 10. At 310, first pCell 1 10 sends an Identity Request (IMEI) to UE 108 and at 312 the UE 108 sends its Identity Response (IMEI) to first pCell 1 10. Thus, in some examples, the local presence cluster controller may use the UE's IMEI, say in order to derive manufacture and handset type or classmark, in order to advantageously determine which UEs can safely be introduced into the location determination process and be redirected, since there are sometimes known issues with specific handsets that do not behave well. At 314, the first pCell 1 10 sends a Location Update Reject message and includes an RRC Connection Release with Redirect Info to a new UARFCN of a second Presence Cell (pCell 120). The selection of the second Presence Cell (pCell 120) to re-direct the UE 108 to has, in some examples, been decided by the local presence cluster controller and duly informed to the first pCell 1 10. The second pCell 1 10 has also been duly informed to redirect UEs to a third pCell, such as third pCell 130 in FIG. 1 .

At 316, in response to the rejection, the UE 108 attempts to connect to the second Presence Cell (pCell 120) and then sends RRC Connection Request to the second pCell 120, which again includes TMSI and 'CPICH RSCP on RACH' information. At 318, the second pCell 120 is configured to send a RRC Connection Reject message and includes an RRC Redirect Info to a new UARFCN of third Presence Cell (pCell 130).

At 320, the UE 108 attempts to connect to the third pCell 130 and sends a RRC Connection Request to third Presence Cell (pCell 130), which includes TMSI and "CPICH RSCP on RACH". In some examples, third Presence Cell (pCell 130) may continue this process to pCell #4, etc. However, in this example, with three sets of data being collected by the first, second and third pCells 1 10, 120 & 130, and three sets of presence data being deemed sufficient to perform location validation, the third pCell 130 redirects the UE 108 back to the macro cell network. Thus, at 322, the pCell 130 also sends a RRC Connection Reject and, in this example, includes an RRC Redirect Info to redirect the UE to the macro cell UARFCN of NodeB 102.

In this example, and at 324, first, second and third pCells 1 10, 120 & 130 forward their respective presence sighting data (based on CPICH RSCP signal measurements), including the UE's TMSI, to a Local presence controller, such as Local presence controller 150 of FIG. 1 . At 326, the Local presence controller 150 calculates an estimated location of the UE, from the information obtained from the three pCells, or forwards the respective sightings data and/or a location estimate to Presence collector 160. In this example, and at 328, the Presence collector 160 determines a UE location based on the received sightings data. In one example, the Presence collector 160 may determine a UE location based on the received sightings data by using, say, known triangulation techniques to improve the location accuracy of the UE 108.

In one example, the known triangulation technique may be based on a pathloss estimate. In this example, the location of the pCells themselves would need to be apriori known, e.g. by performing an approximate survey to know their relative positions.

At 330, the UE 108 attempts to connect to macro NodeB 102 and performs Location update back to Macro network.

In some examples, it is noted that two sightings from two Presence cells based on CPICH RSCP signal measurements will be able to provide sufficient information to provide an indication of a UE's location. However, in this example, it is noted that three sightings from three Presence cells provides better accuracy than two sightings from two Presence cells, thereby helping remove any ambiguity of location.

In some examples, if the CPICH RSCP power reading on a first Presence Cell (pCell 1 ) was weak and below a power threshold, and it was known or suspected that pCell 1 was on the edge of a cluster, the processor or controller of the local presence cluster controller may decide that it is too risky (or of too little potential value) to RRC Redirect the UE to another Presence Cell in the cluster.

In some examples, if the UE 108 cannot detect the redirected pCell, on the specified UARFCN, then the UE 108 will give up and search back for the macro network anyway. Thus, a few seconds later, the UE 108 may either result in being connected to the macro network (where it is Location Update Accepted) or the UE 108 will attempt a connection to another pCell, which may be the same one it was redirected from or a new pCell.

In the current 3GPP™ standard, it is not possible to inform the UE of the scrambling code to redirect the UE. As such, the UE typically selects the newest strongest cell by itself (from the system information broadcast (SIB) SIB1 1 message), and is told what frequency to use on that cell. Thereafter, the UE chooses any available scrambling code (e.g. from ScrCodes 1 -512) on the channel. In contrast, in some examples, the technique herein described to deploy each of the pCells on a different UARFCNs and to use a RRC re-direct message to allow control of the UE access attempts to a specific pCell that is co-located.

Hence, in accordance with some example embodiments, it is proposed to use an orthogonal carrier technique (i.e. offset by +200kHz, 0 and -200kHz from the normal pCell layer). This technique may be used to force the UE temporarily to re-measure a new specific frequency, related to a different pCell, as illustrated in FIG. 4. Advantageously, the use of such an offset frequency arrangement, as supported in 3GPP™, allows the cell to perform a RRC Connection reject operation and re-direct the wireless communication unit to another cell in accordance with a predetermined redirection list, for example stored in memory 158 of local presence controller 150 of FIG. 1 .

FIG. 4 illustrates an example frequency-based diagram 400 of a carrier usage in an example wireless communication system in accordance with an example embodiment of the invention. In this example, multiple orthogonal UARFCN carriers are used. In UMTS a UARFCN defines the centre frequency of a UMTS carrier that is typically 5MHz wide. The UARFCN maps onto an absolute frequency in MHz with a channel raster typically at 200kHz offsets, for example UARFCN 10700 maps to 2140MHz and UARFCN 10701 maps to 2140.2MHz. Therefore, it is possible for two different UARFCNs to overlap significantly, though normally an operator will deploy their spectrum so that their carriers do not overlap. As far as the UE is concerned, they are treated as different or orthogonal carriers and the UE obeys the instructions sent by the network in its use of frequencies. In UMTS, many individual cells will transmit on the same UARFCN. In UMTS™, when a UE is redirected, only the UARFCN is specified in the Redirect-lnfo (there is no ability to redirect to a specific cell Scrambling Code for example) and so then the UE is free to choose whichever detected cell it discovers on that UARFCN, meaning that there would be no real control over which specific cell the UE is redirected to. As such, examples of the invention propose using a couple of additional such offset UARFCNs that result in there being an ability to redirect towards a specific cell in order to take advantage of known RRC Reject with Redirect messages. In some examples, such an approach may be employed in a normal cellular re-use pattern within the cluster. In one example, a cluster of cells may be configured to operate on a (mostly) separate UARFCN to the macro cell (NodeB). In this cluster example, it is envisaged that this separate UARFCN may be used to turn a single block of spectrum (of say 5.4MHz wide) into three usable 5MHz channels. In this manner, a largish cluster of cells may be deployed by using a standard re-use pattern, which advantageously results in a minimal impact on the macro cell due to limited frequency overlap.

Thus, in some examples of the invention, such offsets may be used to provide control to each presence cell to forcefully redirect a user/UE to a known carrier frequency (UARFCN) on which other pCells in a cluster are configured.

In examples of the invention, the use of multiple orthogonal UARFCN carriers allows RRC Reject with Re-direction messages to alternative channels, which may be co-channel with other macro NodeBs use but allows UEs to treat them as separate in RRC Redirection Info messages. Hence, as a UE is RRC Redirected to a UARFCN when it is rejected, such orthogonal UARFCNs for use in a presence cell arrangement as described herein may be employed.

The example frequency-based diagram 400 is divided into three contiguous 5MHz channel bandwidths 402, 404, 406. In this example, it is assumed that a single network operator owns at least two contiguous 5MHz channel bandwidths 402, 404. The first frequency channel band (F1 ) 412 is identified by its UTRA absolute radio frequency channel number (UARFCNJ 10637 and the second frequency channel band (F2) 414 is identified by UARFCN 10661 . It is known within 3GPP that carrier frequencies may be offset by 200 kHz 420. In this scenario, a first offset channel band (F2') 432 is allocated a UARFCN number 10660 and relates to second frequency channel band (F2) with a 200KHz offset. A second offset channel band (F2") 434 is allocated a UARFCN number 10659 and relates to second frequency channel band (F2) with a 400 kHz offset.

In one example of the invention, such offsets may be used by different pCells in order to facilitate orthogonality, e.g. first presence cell (pCell 1 ) is used on F2, ScrCode 1 , second presence cell (pCell 2) is used on F2-200kHz, ScrCode 2, third presence cell (pCell 3) is used on F2 - 400kHz, ScrCode 3, etc. Here, the macro cell may only broadcast one UARFCN/ScrCode in its neighbour cell (NCell) list to first presence cell (pCell 1 ). Assuming pCelM is detected by the UE then pCelM is configured to redirect the UE to pCell2 (e.g. based on its UARFCN). Thereafter, in accordance with example embodiments, pCell2 is configured to redirect to pCell 3. Thereafter, in accordance with example embodiments, pCell3 is configured to redirect the UE back to the macro cell network.

Advantageously, this example may also provide the presence Layer a 'sub-layer' (for the carriers F2' and F2" that are not normally used by the operator's normal macro NodeBs, and as such the presence deployment is free to choose its own allocated ScrCodes, rather than needing these to be specifically allocated by the operator's cell planning team.

In other examples, it is envisaged that if sufficient spectrum was available, the concepts herein described could be implemented using discrete carriers rather than offset carriers.

Thus, in some examples, an intelligent and focused instruction to specifically obtain information from a selected cell from an identified list, performed following aspects of a standard, mechanism that may obtain a location of a cell may assist a presence service. Furthermore, in some examples, multiple structure access attempts may be configured, rather than randomly obtaining pCell measurement and data.

System set-up, Self-learning & adaptation to system changes

Aspects of the invention describe a mechanism to have an adaptive, self-learning system for location determination of a wireless communication unit in a wireless communication system that includes multiple small cells that can be re-configured as presence cells. In some examples of this second aspect, a local presence controller is configured to develop relationships between multiple presence cells. For example, in the first aspect of the invention with a targeted re-direction (for example through an access rejection) of a wireless communication unit to attempt to access cells, the relationships between multiple presence cells may be used to facilitate the location validation or location accuracy improvement of the wireless communication unit's location. In some examples, the RRC Redirect list (per pCell), either during installation or during normal operation may be created and self-optimised in an adaptive fashion.

When the relative locations and proximity relationships of the multiple presence cells are difficult for the installer to manually enter into the local presence cluster controller 150, the system can be made to self-learn these relationships so as to reduce the probability of RRC Redirection failures. In other examples, the relationships that are developed between multiple cells may be used to improve a neighbour cell list. In other examples, the relationships that are developed between multiple cells may be used to improve handover options. One such example is when multiple small cells that are used for coverage and capacity purposes, for example in a training mode, are deployed into a building then the system can be made to use the UE RRC redirects successes and failures to automatically detect relative proximity between the small cells and outdoor macro cells, so as to build handover relationships and idle mode cell reselection neighbour relationships as part of a self- organising system. Once the system is trained then it can operate in a 'stable' mode.

In a location validation example, when the system is first deployed, each pCell in the cluster is provided with a unique UTRA absolute radio frequency channel number (UARFCNJ and a scrambling code to use as its transmission operating parameters. Each pCell is also provided with a randomly generated pCell list of UARFCNs of other nearby pCells (which should not include the UARFCN of itself) which it will use to redirect a wireless communication unit to another pCell in the cluster. The randomly generated pCell list is created and updated, for example, by local presence cluster controller 150. In this example, the results from multiple cells obtaining information from a wireless communication unit's multiple attempts to access a wireless communication system are received and collated by the local presence cluster controller 150. The local presence cluster controller 150 then revises the pCell list according to each new result, to fine-tune relationship information between multiple cells to identify those presence cells that are in the vicinity of others, and may then be more suited than others for a location validation algorithm, or to improve a neighbour cell list for handover purposes. This approach to initially use a randomly generated pCell list of UARFCN and Scrambling codes significantly eases the deployment of multiple small cells into a macro cell coverage area, for example within a retailer's shop. For example, no site surveys or system planning are required, and small cells that are re-configurable as presence cells may be, to some degree, dropped into operation.

In some examples, the local presence cluster controller 150 may be a local server device or a Presence Cell dedicated as a master Presence Cell to co-ordinate other Presence Cells located around it. In some examples, the local presence (cluster) controller 150 may be configured to adaptively control relationships between a cluster of Presence Cells, such as Presence Cells 1 10, 120, 130. In one example, the local presence cluster controller 150 is configured to adaptively build a relationship between multiple cells, for example adaptively inform the associated Presence Cells of which of its neighbours to instruct a UE attempting to access the cell as to which other cell the UE should redirect to. In this manner, a more controlled and intelligent re-direction technique is provided.

In some examples, local presence cluster controller 150 may comprise a processor or controller 152 that is arranged to control and update one or more Presence Cell RRC re-direction lists stored in memory 158 for sending to the Presence cells 1 10, 120, 130.

As will be appreciated, in some cases, if the RRC Redirection list on each Presence Cell was not correct (for example a redirection from one cell to another cell in the cluster that was too far away for the UE to detect) as stipulated by the local presence controller, such as local presence controller 150 of FIG. 1 , or if one of the neighbouring Presence Cells was switched off, then the RRC Redirect mechanism may fail. When this occurs the UE must perform a scan to try to get back onto the network which may take several tens of seconds which would cause unacceptable service disruption to UEs if it was to happen all of the time. In response to any such failures, the local presence controller 150 is configured to adapt the RRC Redirect list stored in memory 158. In some examples, if the UE 108 cannot detect the redirected pCell, on the specified UARFCN, then the UE 108 will give up and search back for the macro network anyway. Thus, a few seconds later, the UE 108 may either result in being connected to the macro network (where it is Location Update Accepted) or the UE 108 will attempt a connection to another pCell, which may be the same one it was redirected from or a new pCell.

In some examples, the processor or controller 152 may be coupled to timer or counter 154 and a threshold detection circuit 156. In one example, timer or counter 154 is configured to track the success or failure rate of the RRC redirection messages that are sent to UEs. In this manner, a rating between the successful re-direction from a first pCell to other pCells can be calculated and adapted according to the number of successes or failures. If the number of failures increases beyond a threshold, for example as determined by the threshold detection circuit 156, then the relationship between the first pCell and the failing pCell can be disregarded (or allocated a low priority option).

In some examples, the processor or controller 152 of the local presence cluster controller 150 may be configured to adapt a number of RRC reject with redirection messages that it proposes for a specific UE 108 based on, say, the UE's estimated position. For example, if the initial power reading on a first Presence Cell (pCell 1 ) was weak and below a power threshold determined by threshold detection circuit 156, and it was known or suspected that pCell 1 was on the edge of a cluster, the processor or controller 152 of the local presence cluster controller 150 may decide that it is too risky (or of too little potential value) to redirect the UE 108 to another Presence Cell in the cluster. In this instance, for example, the processor or controller 152 of the local presence cluster controller 150 may deem that it is safer and more efficient, with regard to use of the available communication resource, to redirect the UE 108 back to the macro cell network and for it to access NodeB 102. Accordingly, in this example, the processor or controller 152 of the local presence cluster controller 150 may also adapt the Presence Cell RRC re-direction lists stored in memory 158.

Alternatively, in another example, the local presence cluster controller may also decide that after two sightings of the UE 108, say based on CPICH RSCP signal measurements from two respective Presence Cells, the position of the UE 108 is now sufficiently further disambiguated. In this instance, processor or controller 152 of the local presence cluster controller 150 may decide that there is no other Presence Cell in the cluster that the local presence cluster controller 150 should try to obtain more presence-related data from and abandon the location validation or accuracy improvement process. In this case, the processor or controller 152 of the local presence cluster controller 150 may also decide to redirect the UE 108 back to the macro cell network instead of attempt a third presence cell (pCell) access. Thus, in this instance, only the two Presence Cell sightings of the UE 108, for example based on CPICH RSCP signal measurements, will be used in validating or more accurately determining a location of the UE 108. Accordingly, in this example, the processor or controller 152 of the local presence cluster controller 150 may also adapt the Presence Cell RRC re-direction lists stored in memory 158.

In one example, the algorithm applied by the local presence cluster controller 150 may be configured to swap out (or lower a priority status of) pCells, such as pCells 1 10, 120, 130 that are less useful and effectively re-organise the list so that the closest pCells to other pCells are discovered over a period of time. Once the system has evolved to a steady state position, then the relationships between the pCells can be assumed to be stable (e.g. the probability of redirecting to a distant, non- useful, pCell becomes smaller or indeed negligible.

Furthermore, and advantageously in some examples, since the system self-adapts, any pCell outage would be self-healing by the system. Both of these features allow for a reduced operational cost and reduced installation complexity.

In some examples, the local presence cluster controller (i.e. local with the pCells) may monitor and interpret the 2^nd / 3^rd RRC requests that come through (based on the UE TMSI) and then use this information to determine which order to adapt the RRC Redirect list, which in some examples may be additionally based on historical information on the success/failure of RRC re-direction requests for particular pCells. Some examples of the invention propose to use the TMSI, as this is always sent with the CPICH Power level on the RRC Connection Request.

In this manner, the local presence cluster controller 150 aims to make deployment simpler through a self-learning/optimisation technique for generating and maintaining an RRC Redirect list without needing to perform multiple site surveys. Referring now to FIG. 5, an example cell-based diagram 500 is illustrated showing a first example of a position estimation scheme with a single Cell, in accordance with an example embodiment of the invention. Here, a first (single) small cell 510, configurable to support presence services, is located in, say a building. Based on the measurement provided by UE 540, of the Cell#1 510 received signal code power (RSCP) power level, and with the knowledge of the position of the Cell #1 510 within the building, it is possible to estimate a circular location zone based on an assumed 'radius' 520. An additional circular area 530, indicated by an extended uncertainty radius 535 provides a margin of error for location estimates of the UE 540. Thus, with a single cell arrangement, the position of the UE 540 may be, in essence, anywhere within the estimated location zone 530, and therefore there is a large margin for location error.

Referring now to FIG. 6, an example cell-based diagram 600 is illustrated showing a position estimation scheme with two Cells, in accordance with an example embodiment of the invention. In this diagram, and based on UE measurement of the Cell#1 510 RSCP power level and with the knowledge of the position of the Cell #1 510 it is possible to estimate a circular location zone based 530 on an assumed 'radius' and a margin of error, as shown in FIG. 5. However, with a second measurement from the UE 540 of Cell #2 612 RSCP power level and with the knowledge of the position of Cell #2 612, it is possible to produce a similar circular location zone of UE around Cell #2 612 with a radius of 621 , with an additional uncertainty area 632 with an additional uncertainty radius 637. Using an overlap of the two circular coverage zones 630, 632, it is possible to then produce 2 candidate locations 650, 652 for the true position of the UE (thereby to a better accuracy). However, as clearly shown with two cells, there still remains an ambiguity in the true location of the cell between these two possible location zones 650, 652. Referring now to FIG. 7, an example cell-based diagram 700 is illustrated showing a position estimation scheme with three Cells, in accordance with an example embodiment of the invention. As in FIG. 5 and FIG. 6, based on UE measurement of the Cell#1 510 RSCP power level and with the knowledge of the position of the Cell #1 510, it is possible to estimate a circular location zone based 530 on an assumed 'radius' and a margin of error.

With a second measurement from the UE 540 of Cell #2 612 RSCP power level and with the knowledge of the position of Cell #2 612, it is possible to produce a similar circular location zone of UE 540 around Cell #2 with an uncertainty 632.

With a third measurement from the UE 540, via Cell #3 714 and providing a RSCP power level and with the knowledge of the position of Cell #3 714, it is possible to produce a similar circular location zone of UE 540 around Cell #3 714 with a radius 724 and an uncertainty area 734 of radius 739.

However, using the overlap of the three circular coverage zones 530, 632, 734, it is possible to then produce a single candidate location estimate 750 for the true position of the UE 540 to provide a better accuracy in this case there is no ambiguity of the true location of the cell. Referring now to FIG 8, an example cell-based diagram 800 of a cluster controller 810 of multiple Cells is illustrated, in accordance with an example embodiment of the invention. FIG 8 illustrates a cluster controller 810 that coordinates the cells#1 -#9 510, 612, 714, 816-826, which are located in a grid arrangement. In other examples, it is envisaged that other physical location arrangements and grid structures may be employed. In this example, the UE#1 540 is located closest to Cell#1 510 and cell#2 612, as well as cell#4 816 and cell#5 818. Whilst it may be advantageous to attempt to redirect the UE to Cell#9 826 due to its physical distance, it may be less likely to be detectable by the UE 540. As such, there is no value in redirecting UE 540 towards this cell if it was first detected on Cell #1 510.

Referring now to FIG 9 an example flowchart 900 is illustrated detailing how a cluster controller, for example cluster controller 810 of FIG. 8, can automatically learn which cells are closely located and have the maximum chance of getting sightings after a redirection attempt, in accordance with an example embodiment of the invention. Such a process may be based on having a 'learning' phase, where a set of re-direction rules between cells is created as a list, and each is tried at random in order to measure a likelihood of success.

Additionally, in some examples, a quality metric for each re-direction may be based on the UE signal strength measurements, which can be used to further bias which redirection is likely to yield a signal for good location estimation purposes. Once sufficient 'statistically significant' data has been obtained, then the learning phase may be deemed complete and the cluster controller is able to change into an 'active' mode. In this example, instead of making decisions at random, they are based on the learnt data.

In some examples, it is understood that the system performance may change over time - e.g. a retail store refit may mean that a position of the sales till may move, or the position of the cells or internal walls / obstructions may change and, as such, people may congregate in different hotspot areas of a store. This may mean that the redirection rules need to evolve automatically. The self- learning nature of the algorithm described below allows it to adapt to changes and/or outages in cells, for example by updating the redirection rules based on real measurements.

The example flowchart 900 starts at 905, where the cluster controller, for example cluster controller 810 of FIG. 8, is configured with X, Y co-ordinates of all cells allocated in a cluster, in order to allow sighting location estimation to be performed. At 910, the cluster controller may initialise a self- learning algorithm of state information for all relationships. At 915, the cluster controller may begin to create relationship mapping rules (e.g. Cell#1 to Cell#2, Cell#1 to Cell#9, etc.). At 920, during this 'Learning' phase, the cluster controller may attempt (at random) different redirection rules and determines a success or failure of the re-direction attempt, for example 'was the UE sighted on the requested cell'? At 925, the cluster controller updates, say, a probability of success of each possible redirection rule. At 930, the cluster controller may optionally add a quality score of each redirection rule, say based on the reported UE measurement of RSCP / RSSI / RSRP of the redirected Cell. For example, if the RSCP / RSSI / RSRP is too weak (i.e. barely detectable), then the quality score is degraded. At 935 the cluster controller may determine when the 'Learning' phase has sufficient data, in order to change to an 'Active' mode. This is based on a having statistically significant amounts of learnt data. At 940, in an 'Active' mode, the cluster controller ranks the redirection rules based on the probability of successful redirection and quality. At 945, in response to a first sighting received for a UE, the cluster controller may determine which rule is the most likely successful redirect rule to use, given the historical data and quality metric. Thereafter, for example, the cluster controller may determine which cell to redirect to and instructs the first Cell to redirect to next cell.

At 950, if a sighting is received for the second cell (for the same UE) then the cluster controller may update, say, its success metric for this redirection rule. If the second cell sighting is not seen, then the success metric for this redirection rule is degraded. In some examples, a controller, such as controller 810, may be configured to change or update the UARFCN in response to a non-sighting. In this way the system may adapt to natural changes in the radio environment or cell outages. At 955, if the cluster controller detects a link failure to one of the cells in the redirection chain, it can update the associated redirection rules in order to prevent failed redirection attempts. In some examples, the cluster may also raise an alert to the operator that a cell is failed, or if the performance of a redirection rule has degraded for environmental reasons (e.g. the cell has been moved). For example, if a new cell is added to the cluster then the system may automatically transition into a learning mode. At 960, the redirection process may continue for several other attempts, which may be configured by the limit of redirection attempts.

The signal processing functionality of the embodiments of the invention, particularly the function of the signal processor 228, may be achieved using computing systems or architectures known to those who are skilled in the relevant art. Computing systems such as, a desktop, laptop or notebook computer, hand-held computing device (PDA, cell phone, palmtop, etc.), mainframe, server, client, or any other type of special or general purpose computing device as may be desirable or appropriate for a given application or environment can be used. The computing system can include one or more processors which can be implemented using a general or special-purpose processing engine such as, for example, a microprocessor, microcontroller or other control module.

The computing system can also include a main memory, such as random access memory (RAM) or other dynamic memory, for storing information and instructions to be executed by a processor. Such a main memory also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by the processor. The computing system may likewise include a read only memory (ROM) or other static storage device for storing static information and instructions for a processor.

The computing system may also include an information storage system which may include, for example, a media drive and a removable storage interface. The media drive may include a drive or other mechanism to support fixed or removable storage media, such as a hard disk drive, a floppy disk drive, a magnetic tape drive, an optical disk drive, a compact disc (CD) or digital video drive (DVD) read or write drive (R or RW), or other removable or fixed media drive. Storage media may include, for example, a hard disk, floppy disk, magnetic tape, optical disk, CD or DVD, or other fixed or removable medium that is read by and written to by media drive. The storage media may include a computer-readable storage medium having particular computer software or data stored therein.

In alternative embodiments, an information storage system may include other similar components for allowing computer programs or other instructions or data to be loaded into the computing system. Such components may include, for example, a removable storage unit and an interface, such as a program cartridge and cartridge interface, a removable memory (for example, a flash memory or other removable memory module) and memory slot, and other removable storage units and interfaces that allow software and data to be transferred from the removable storage unit to computing system.

The computing system can also include a communications interface. Such a communications interface can be used to allow software and data to be transferred between a computing system and external devices. Examples of communications interfaces can include a modem, a network interface (such as an Ethernet or other NIC card), a communications port (such as for example, a universal serial bus (USB) port), a PCMCIA slot and card, etc. Software and data transferred via a communications interface are in the form of signals which can be electronic, electromagnetic, and optical or other signals capable of being received by a communications interface medium.

In this document, the terms 'computer program product', 'computer-readable medium' and the like may be used generally to refer to tangible media such as, for example, a memory, storage device, or storage unit. These and other forms of computer-readable media may store one or more instructions for use by the processor comprising the computer system to cause the processor to perform specified operations. Such instructions, generally referred to as 'computer program code' (which may be grouped in the form of computer programs or other groupings), when executed, enable the computing system to perform functions of embodiments of the present invention. Note that the code may directly cause a processor to perform specified operations, be compiled to do so, and/or be combined with other software, hardware, and/or firmware elements (e.g., libraries for performing standard functions) to do so.

In an embodiment where the elements are implemented using software, the software may be stored in a computer-readable medium and loaded into computing system using, for example, removable storage drive. A control module (in this example, software instructions or executable computer program code), when executed by the processor in the computer system, causes a processor to perform the functions of the invention as described herein.

Furthermore, the inventive concept can be applied to any circuit for performing signal processing functionality within a network element. It is further envisaged that, for example, a semiconductor manufacturer may employ the inventive concept in a design of a stand-alone device, such as a microcontroller of a digital signal processor (DSP), or application-specific integrated circuit (ASIC) and/or any other sub-system element.

It will be appreciated that, for clarity purposes, the above description has described embodiments of the invention with reference to a single processing logic. However, the inventive concept may equally be implemented by way of a plurality of different functional units and processors to provide the signal processing functionality. Thus, references to specific functional units are only to be seen as references to suitable means for providing the described functionality, rather than indicative of a strict logical or physical structure or organisation.

Aspects of the invention may be implemented in any suitable form including hardware, software, firmware or any combination of these. The invention may optionally be implemented, at least partly, as computer software running on one or more data processors and/or digital signal processors or configurable module components such as field programmable gate array (FPGA) devices. Thus, the elements and components of an embodiment of the invention may be physically, functionally and logically implemented in any suitable way. Indeed, the functionality may be implemented in a single unit, in a plurality of units or as part of other functional units.

Although the present invention has been described in connection with some embodiments, it is not intended to be limited to the specific form set forth herein. Rather, the scope of the present invention is limited only by the accompanying claims. Additionally, although a feature may appear to be described in connection with particular embodiments, one skilled in the art would recognize that various features of the described embodiments may be combined in accordance with the invention. In the claims, the term 'comprising' does not exclude the presence of other elements or steps.

Furthermore, although individually listed, a plurality of means, elements or method steps may be implemented by, for example, a single unit or processor. Additionally, although individual features may be included in different claims, these may possibly be advantageously combined, and the inclusion in different claims does not imply that a combination of features is not feasible and/or advantageous. Also, the inclusion of a feature in one category of claims does not imply a limitation to this category, but rather indicates that the feature is equally applicable to other claim categories, as appropriate.

Furthermore, the order of features in the claims does not imply any specific order in which the features must be performed and in particular the order of individual steps in a method claim does not imply that the steps must be performed in this order. Rather, the steps may be performed in any suitable order. In addition, singular references do not exclude a plurality. Thus, references to 'a', 'an', 'first', 'second', etc. do not preclude a plurality.

Claims

1 . A method for refining a relationship between multiple Presence Cells in a wireless communication system, the method comprising, at a controller:

maintaining a Presence Cell list of relationships between multiple Presence cells in the wireless communication system;

sending each of a plurality of Presence Cells a frequency of another Presence Cell from the Presence Cell list;

causing an access attempt of a wireless communication unit to be re-directed from a first Presence cell to a selected second Presence cell from the multiple Presence Cells based on the frequency sent to the first Presence cell;

obtaining information from the selected second Presence cell related to the respective access attempt;

forming a relationship value between the first Presence cell and the selected second Presence cell based on the obtained information; and

refining the relationship value in the Presence Cell list upon repeating the operation of causing further access attempts and obtaining information following the further access attempts.

2. The method of Claim 1 wherein causing an access attempt and obtaining information from selected presence cells is repeated multiple times, for multiple presence cells and multiple wireless communication units to refine relationships between multiple presence cells.

3. The method of Claim 1 or Claim 2 wherein the controller is a cluster controller coupled to a plurality of presence cells configured in a cluster, and refining a relationship value between cells comprises automatically learning those cells that are closely located to one another.

4. The method of Claim 3 wherein refining a relationship value between cells comprises automatically learning those cells that are closely located to one another to provide an improved chance of obtaining presence sighting information following a redirection instruction to a wireless communication unit.

5. The method of any preceding Claim wherein refining a relationship value between cells comprises creating a list of a set of re-direction rules between cells, and instructing one or more wireless communication units to attempt access to presence cells according to each set of redirection rules in a random manner in order to measure a likelihood of success.

6. The method of Claim 5 wherein obtaining information from the selected first presence cell comprises obtaining a quality metric relayed from the wireless communication unit and using the quality metric to bias a location estimation relationship value between cells when refining the relationship value.

7. The method of Claim 6 wherein the quality metric comprises a received signal code power, RSCP, value.

8. The method of any of preceding Claims 5 to 7 further comprising updating the set of redirection rules based on real measurements performed by one or more wireless communication units.

9. The method of any preceding Claim wherein refining a relationship value between cells comprises re-organising a presence list by lowering a priority status or swapping Presence cells that are less useful based on wireless communication unit measurements.

10. The method of Claim 9 further comprising halting a re-organising of the presence list upon determining that the presence list has evolved to a steady state position

1 1 . The method of any preceding Claim wherein causing an access attempt of a wireless communication unit to be re-directed from a first Presence cell to a selected second Presence cell from the multiple Presence Cells comprises sending a radio resource control, RRC, reject with redirection message to at least one wireless communication unit.

12. The method of any preceding Claim further comprising monitoring and interpreting access attempts by one or more wireless communication units based on an identifier of the wireless communication unit and using the wireless communication unit information to determine an order to adapt the Presence list.

13. The method of Claim 12 further comprising monitoring and interpreting access attempts by one or more wireless communication units based on historical information on a success or failure of wireless communication unit attempts for particular cells.

14. The method of Claim 13 further comprising changing or updating a redirection rule, for example UTRA absolute radio frequency channel number, ARFCN, in response to a non-sighting or failure of the wireless communication unit access attempt for a cell.

15. The method of any preceding Claim further comprising applying at least one threshold to at least one of:

a time limit to the causing and obtaining operations;

a number of Cells to obtain information from; a low received signal value threshold.

16. The method of any preceding Claim further comprising adapting the Presence Cell list related to relationships between multiple cells in response to at least one of the multiple cells failing to record a sighting of the wireless communication unit.

17. The method of any preceding Claim further comprising autonomously adapting the Presence Cell list in response to installation, deactivation or re-location of Presence Cells.

18. A controller for refining a relationship between multiple Presence Cells in a wireless communication system, the controller comprising a transceiver and a signal processor, operably coupled to the transceiver and configured to:

maintain a Presence Cell list of relationships between multiple Presence cells in the wireless communication system;

send each of a plurality of Presence Cells a frequency of another Presence Cell from the Presence Cell list;

cause an access attempt of a wireless communication unit to be re-directed from a first Presence cell to a selected second Presence cell from the multiple Presence Cells based on the frequency sent to the first Presence cell;

obtain information from the selected second Presence cell related to the respective access attempt;

form a relationship value between the first Presence cell and the selected second Presence cell based on the obtained information; and

refine the relationship value in the Presence Cell list upon repeating the operation of causing further access attempts and obtaining information following the further access attempts.

19. A wireless communication system, comprising a plurality of presence cells operably coupled to a controller, the controller comprising a transceiver and a signal processor, operably coupled to the transceiver and configured to:

obtain information from the selected second Presence cell related to the respective access attempt; form a relationship value between the first Presence cell and the selected second Presence cell based on the obtained information; and