DIRECTIONAL MESSAGING

Field of the Invention

The present invention relates to a system and method for directional broadcasting of messages in a wireless network, in particular a system and method for broadcasting messages in a specific direction in a wireless network to a particular set of receiving clients.

Background to the Invention

The IEEE 802.11 standard, more commonly referred to as Wi-Fi, for Wireless Local Area Networks (WLANs) has been rapidly adopted by many users seeking to implement wireless telecommunications networks. Wi-Fi networks are starting to provide wireless networking for an ever increasing number of users, with some urban and suburban areas having a significant density of wireless access points (APs) per geographical area. It is likely that in the future, we will see even more wireless APs in residential, enterprise and public places, supporting increasing user density and traffic loads. The density of APs in many areas may even reach a state when each AP will be able to communicate wirelessly with a neighbouring AP, with the relative distance between APs decreasing.

Indeed, in some countries, there are APs installed along highways and roads, providing users with network access whilst in their cars. Whilst such networks are designed to effectively provide data access to road users, they have yet to be fully utilised. One area they are lacking in is support efficient distribution of messages between users along a highway, and furthermore a system that is able to take into account the directional movements of users in both sending and receiving vehicles.

Summary of the Invention

It is the aim of embodiments of the present invention to address at least some of the above stated problems and also to generally provide an improved method of broadcasting messages in a wireless network.

According to one aspect of the present invention, there is provided a method of transmitting a message in a wireless network from a sending mobile client to a receiving mobile client, said method comprising the steps of: providing by a user an input to the sending mobile client, said input corresponding to the occurrence of an event; determining by the sending mobile client the position and direction of movement of the sending mobile client with reference to at least one of a plurality of access points in the wireless network; determining by the sending mobile client a required direction of movement and a required position for a receiving mobile client, wherein the required direction of movement is with reference to the plurality of access points, and the required position is relative to the position of the sending mobile client; and generating a request message by the sending mobile client for transmitting to the receiving mobile client, wherein the request message comprises an indication of the event, the required direction of movement of the receiving mobile client and the required position of the receiving mobile client.

Preferably, the method further comprises: transmitting the request message from the sending mobile client to a server, and wherein the server generates and transmits a target message onto at least one of the plurality of access points in dependence on the required position of the receiving mobile client obtained from the target message.

The target message may comprise the indication of the event taken from the request message and the required direction of movement of the receiving mobile client taken from the request message.

The at least one of the plurality of access points preferably forwards the target message onto a receiving mobile client connected to the at least one of the plurality of access points, and the receiving mobile client determines if the

target message is intended for receiving mobile client based on the required direction of movement in the target message.

The receiving mobile client preferably determines if the target message is intended for receiving mobile client by comparing the required direction of movement in the target message with the actual direction of movement of the receiving client, and if the required direction of movement and the actual direction of movement match, then the receiving mobile client outputs the indication of the event from the target message.

The received mobile client may determine the actual direction of movement by examining a log of previously connected access points.

Preferably, the sending mobile client determines the direction of movement of the sending mobile client by using a log of previously connected access points.

According to a second aspect of the present invention, there is provided a client module for a mobile client comprising a processor adapted to: receive user inputs corresponding to the occurrence of an event; determine the position and direction of movement of the mobile client with reference to at least one of a plurality of access points in the wireless network; determine a required direction of movement and a required position for a receiving mobile client, wherein the required direction of movement is with reference to the plurality of access points, and the required position is relative to the position of the mobile client; and generate a request message for transmitting to a receiving mobile client, wherein the request message comprises an indication of the event, the required direction of movement of the receiving mobile client and the required position of the receiving mobile client.

In embodiments of the present invention, messages can be targeted to quite specific receiving clients by the server only sending a target message to specific access points limited by their required position. Hence not all potential receivers in the network are flooded with messages.

In general, embodiments of the invention provide improved directional messaging, which takes into consideration the direction of travel of the target client and not just for the position of the target clients, thus distinguishing between bidirectional traffic and unidirectional traffic.

The method can for example be employed for emergency event messaging, such as for accidents occurring on the road, which automatically alerts the relevant emergency response parties as well as other clients or vehicles.

The method provides directional messaging without any need to modify any existing WLAN standards as the message data is in application level data.

Brief Description of the Drawings

For a better understanding of the present invention reference will now be made by way of example only to the accompanying drawings, in which:

Figure 1 is network arrangement in an embodiment of the present invention; Figure 2 illustrates a client module in an embodiment of the present invention;

Figure 3 illustrates a messaging server in an embodiment of the present invention;

Figure 4 illustrates a table detailing a scheme for representing target direction in an embodiment of the present invention;

Figure 5 is a message layout for a request message in an embodiment of the present invention;

Figure 6a and 6b are message flow diagrams illustrating the operation of an embodiment of the present invention; Figure 7 is a message layout for a target message in an embodiment of the present invention.

Description of the Preferred Embodiments

The present invention is described herein with reference to particular examples. The invention is not, however, limited to such examples.

Embodiments of the present invention describe a messaging system for clients in vehicles moving along a road with WLAN access. The system can generate messages, determine the direction of travel of the sending client along the road, decide which other clients on the road should receive the messages and send a suitable message accordingly.

Figure 1 illustrates a network arrangement 100 in an embodiment of the present invention. The network 100 at least partially covers a road 102. The network coverage for the road is provided by a series of wireless access points (APs) 114, 116, 118 and 120. These wireless APs operate in accordance with the IEEE 802.11 standard for wireless local area networks (WLAN). Each of the APs has an associated coverage area wherein any client within that area is provided with wireless LAN access. In the network 100, AP 114 has a coverage area 122, AP 116 has a coverage area 124, AP 118 has a coverage area 126, AP 120 has a coverage area 128. The total coverage area provided by all the APs provides complete coverage for the road 102 along which the APs are regularly positioned. Thus, any vehicles travelling along the road 102 is provided with wireless LAN access by at least one of the APs 114, 116, 118 or 120.

Each of the APs is connected to a fixed network 132, such as the Internet or some private fixed network, via a network connection 130. Network connection 130 may be wired or wireless. A messaging server 13 is connected to the fixed network 132, providing messaging services to the connected APs. Whilst the fixed network 130 and network connection 132 are shown as being separate, but interconnected networks, a skilled person will appreciate that the two networks may be replaced by a single network or network connection that could be either wired or wireless.

The road 102 in Figure 1 is divided into 2 segments, and upper segment 140 and a lower segment 150. The upper segment 140 represents the half or lanes that are used by vehicles travelling from left to right in the figure, whilst the lower segment 150 represents the half of the road used by vehicles travelling from right to left in the figure. There are 5 vehicles shown in this illustration. Vehicles 104, 106 and 108 are shown travelling in segment 150 from right to left, whereas vehicles 120 and 112 are in segment 140 and travelling from left to right.

Each of the vehicles is configured with a suitable wireless client enabling wireless network access via the APs using the IEEE 802.11 standard. Examples of such clients include suitably configured laptops, PDAs or smartphones, as well as dedicated in-car wireless systems. For the purposes of the present application, the terms "client" and "vehicle" are used interchangeably. The precise AP with which a given client will connect and ^" communicate with is dependent on the position of the client with respect to the AP, and more specifically coverage area associated with the AP. For example, client 108 can connect with AP 120 only as it is located only in coverage area 128 which is associated with AP 120. In contrast, client 112 can connect with both AP 118 and 120, because it is located in both coverage areas 126 and 128, which are associated with APs 118 and 120 respectively.

Now, there are various situations that might arise on the road 102, which a driver of one of the vehicles may wish alert other drivers/vehicles to so that the other drivers can react according e.g. take evasive action. For example, there may be an accident on the road that the driver has seen, where it would be useful to inform drivers behind on the same side of the road to avoid by taking an alternative route. Or, a vehicle may have broken down, and it might be useful to broadcast an alert to request a breakdown service. Emergency vehicles such as ambulances or police cars could alert vehicles ahead heading in the same direction to clear the road or move over into the nearside lanes.

However, one of the factors that have to be taken into consideration before any message is broadcast is to which vehicles on the road 102 the message should be directed to. For example, on a normal highway or road, there are two directions of travel, and also two relative positions of vehicles in front of and vehicles behind the vehicle in question. This effectively results in four groups covering all basic combinations of vehicle position/vehicle direction relative to the broadcasting vehicle: vehicles in front and travelling in same direction, vehicles behind travelling in same direction, vehicles in front travelling in opposite direction and vehicles behind travelling in opposite direction. Of course, these groups can also be combined to cover other combinations, such as all vehicles travelling in the same direction (including those in front and behind), and all vehicles on the road irrespective of direction or position.

For example, if vehicle 106 has just driven past an accident on his side of the road 150, he may wish to notify all vehicles driving in the same direction behind him, which in Figure 1 would be vehicle 108. Alternatively, if vehicle 108 was an ambulance, and wanted to clear the road ahead, he would broadcast a message to that effect directed at all vehicles on the same side of the road in front of it, which would include vehicles 104 and 106.

Embodiments of the present invention utilise an adapted wireless client module for generating and transmitting messages. These messages are received by a neighbouring AP to which the client is connected, and then forwarded to the messaging server 134 over the fixed network 132. The messaging server 134 then determines which APs to forward the message onto for broadcasting based on the direction/coverage specified in the message. Receiving clients are adapted to filter and display the messages according to the intended destination. The mode of operation will be described below after the client module and messaging server arrangement have been described.

Figure 2 illustrates a client module 200, which may be included in any of the vehicles shown in Figure 1 and used for generating and transmitting messages, as well for receiving and displaying messages. The client module 200

comprises a processing unit 202 and a radio interface 212. The radio interface 212 would typically be a wireless network interface card capable of transmitting and receiving data wirelessly in accordance with the IEEE 802.11 standard. The processing unit 202 also has access to a rules/filter store 208 as well AP tables 210. The processing unit 202 receives message inputs from a suitable input means 204, for example a keypad or a module preloaded with message templates/types, and uses the input data to generate an outgoing message for transmission by the radio interface 212. The processing unit 202 also receives incoming messages received from the radio interface 212 and outputs the messages received to a message display 206 following suitable processing based on information stored within the received message as well as any processing parameters stored in the rules/filter store 208. The rules/filter store 208 also contains information used by the processing unit for generating outgoing messages. Thus, the client module 200 is used for processing both outgoing and incoming messages.

The AP tables 210 store details of the access points that the client has previously been connected. This may be with reference to a suitable identifier such as the AP SSID or IP address. In a preferred embodiment of the invention, the APs are identified by a custom identifier. The custom identifier can be used as well as or instead of the standard SSID. In this example, the SSID is replaced by this identifier. The customised SSID uniquely identifies an AP, and can include a reference to the road along which the AP is located as well as the position along that road, thereby accurately reflecting the position of the associated AP. For example, if the road is the M4 motorway in the UK, then the SSID is M004000100. The first 4 characters (or subfield) in the SSID field reflects the road name, here the M4, and the second 6 characters (or subfield) reflect the position along the road, here 100 metres from the start of the motorway.

To illustrate, let us assume that the road 102 in Figure 1 is a road in the UK called the A14. The road 102 increases in direction from left to right (i.e. the road "starts" somewhere off to the left). Thus, the APs 114, 116, 118 and 120

are labelled with SSIDs of "A014000100", "A014000200", "AQ14000300" and "A014000400" respectively. AP 114 is nearest the start of the road 102, the "A14", and thus has a value of "A014" in the road name subfield of the SSID reflecting the road name, and "000100" in the position subfield in its SSID, reflecting the fact that the AP is 100m away from the start of the road. In contrast, AP 120 is 400m away from the start of the road 102, the "A14", and thus has a value of "000400" instead of "000100" in the position subfield of its SSID.

Whilst the customised SSID above has been described above as being 10 bytes long, a skilled person will appreciate that other lengths could be used instead. For example, in the IEEE 802.11 , the standard SSID field is usually 32 bytes long, which the present invention could be adapted to use instead.

Returning now to the client module 200 in Figure 2, the AP tables 210 can also store other details other than just a list of previous APs with which the client has been connected. Other information includes the start and end connection times of each of the previous APs for example. Furthermore, the AP tables 210 also store details of the current AP with which the client is connected as well as any neighbouring APs that can also be detected. These details include not only the SSID, but may also include the IP address and an indication of the signal strength such as the received signal strength indicator (RSSI). The data in these tables 210 are used to calculate the exact position of the vehicle as well as the direction of travel.

Figure 3 shows a messaging module 300 located within the messaging server 134. The messaging module 300 includes an input/output interface 302 with which the module is able to communicate with the connected fixed network 132, and onwards to the connected APs. The messaging module 300 also includes a message processor 304 which processes messages received from connected APs, and determines which APs to forward those messages onto. The message processor 304 also has access to various lookup tables 306,

which provides network routing for the APs such as mapping between the AP SSID and the APs IP address.

Figure 4 is a table detailing a scheme for representing the target client direction i.e. the intended recipient of a message. The scheme is used to efficiently represent different groups of clients or vehicles in dependence on their direction of travel and their position relative to the client sending the message.

A 2 byte field is used, wherein the first byte is used to describe the side (i.e. sector 140 or 150) of the road the target client is travelling on (or direction of travel), and the second byte describes the target client's position along the road relative to the sending client. Thus, the first byte can take a value of "+", "-" or " ^* ". "+" represents the side of the road where vehicles are travelling with increasing mileage which is sector 140 in Figure 1 (note that vehicles move from left to right in sector 140 and the road "starts" on the left, thus "increasing" or "+" mileage is from left to right along sector 140). Similarly, "-" represents sector 150, where vehicles are travelling from right to left, and "decreasing" in mileage towards the start of the road. " ^* " is used to denote all vehicles travelling in both directions.

The second byte denotes the target direction or position measured relative to the sending client, where "+" is for a target client having a higher mileage (or position to the right in Figure 1 ) of the sender, and "-" is for a target client having a lower mileage (or position to the left in Figure 1 ). " ^* " is for all target clients, whatever their position.

For example, a target client travelling in sector 140 of Figure 1 , a second byte of "+" would indicate a target client ahead i.e. having a higher mileage compared to the sending client. For the same client in sector 140 of Figure 1 , a second byte of "-" would indicate a target client behind that of the sending client i.e. having a lower mileage.

To illustrate, if we take client 106 as the sending client, then a target direction of "++" would be used to refer to clients on the increasing mileage side of the road (the first byte) i.e. sector 140 travelling left to right, and for those clients to have a higher mileage (the second byte) i.e. those positioned to the right of client 106, which results in a target client of client 112. Alternatively, if the target direction of "-+" were used, then the target client would be client 108 (travelling right to left and positioned to the right). In yet another example, if the target direction of "+ ^* " were used, then the target clients would be clients 110 and 112.

Figure 5 shows the format of a message 500 as generated by the client module 200, following input from the user or can be generated automatically, and sent via the radio interface 212 from the sending client to a connected AP for onward transmission to target clients (via the messaging server as will be described later). The message 500 contains a header field 502 and an application data field 504.

The header field 502 includes various subfields for information such as the sender's IP address as well as the destination IP address. The application data field 504 is subdivided various subfields including an origin AP subfield 506, a direction subfield 508, a message content subfield 510 and an options subfield 512. The origin AP subfield 506 is filled with the customised SSID of the AP to which the client is connected at the time of message generation. The direction subfield 508 contains the 2 byte target direction as described above in relation to Figure 4. The message content subfield 510 contains the message text input by the user such as "Accident on A14. All lanes blocked towards city". The options subfield 512 contains options or rules relating to the broadcast of the message, such as periodic rebroadcasting to the target clients.

Other examples of possible events and associated messages include: alerting all clients along a road, making a request for emergency response, "car breakdown, red Toyota, KDA 36YY, repair service on M4 5km from London"; ambulance or other emergency vehicle alerting all users in front to clear the

road "emergency vehicle approaching, please move out of left/outside lane"; informing clients on other side of road of possible danger such as a landslide that has just occurred "landslide near junction 14 of M4 eastbound"; and a simple announcement service such as for a bus or shuttle service and the location "bus to Ipswich city centre on A14 near junction of A12".

The operation of the system shown in the aforementioned figures will now be described with reference to the message flow diagram of Figure 6a and 6b (note that the steps shown in Figure 6b follow on from those shown in Figure 6a). The combination of Figures 6a and 6b will be collectively referred to as Figure 6 for ease of reference. References in Figure 6 to elements found in earlier Figures will be made using like reference numerals.

Figure 6 outlines the steps executed by the system 100 as whole when the sending client 106 encounters an incident on the road 102 and the client module 200 installed in the sending client 106 is used to send message for receipt by other clients such as client 108.

In step 610, the sending client 106 receives a message input from the user, in this case the driver of the vehicle in which the client module 200 is installed. In this example, the message is to alert other road users driving behind the sending client 106 and in the same direction (or same side of the road) that there has been a landslide blocking off the sending client 106 side of the road. The message can be input by the user manually or by selecting one a number of predefined messages and adding the requisite details. Likewise, the target direction for the receiving clients or vehicles is also defined using the system set out in Figure 4 either manually or using some automated process. For example, the client module 200 may present the user of client 106 with a list of possible message types, one of which is a "landslide" message. The client module 200 then asks the user if the blockage affects only the user's side of the road, the opposite side of the road, or both. Thus the message content subfield 510 can be automatically populated by the client module 200 following these guided user inputs, and the target direction for the direction subfield 508

determined using the following method without the user needing to explicitly provide the details.

In order to determine the target direction for the direction subfield 508, the processing unit 202 examines the AP tables 210 stored in the client module. As discussed earlier, the AP tables include a list of the SSIDs of previously connected APs. In this example, the AP table known as "AP LOG", Table 1 below, details the customised SSIDs of the current and previously connected APs.

AP LOG

AP014000200

AP014000300

AP014000400

Table 1

The AP LOG shows a list, with most recent or current AP SSID at the top, of SSIDs of previously connected APs. Using this table, the processing unit 202 not only knows which AP it is currently connected to, AP014000200 or AP i 16, but also which earlier ones it has been connected to. Thus, using this data, the processor can determine that the client is travelling in a decreasing mileage direction along sector 150 of the road 102 by the fact the SSIDs are decreasing. It therefore uses the historical SSID data without the need for any external direction data such as from a GPS.

The processing unit 202Jhen takes the input event of a "landslide", the input from the user on which side of the road the blockage is on, the direction of travel of the client 106 as extrapolated using the AP table, Table 1 , together with any rules associated with a particular event and uses all this information to determine the target direction for the message 500. In this example of a landslide event, which is blocking the client 106 side of the road, the target direction of "-+" is generated by the processing unit 202 for use in the message

500. A target direction of "-+" means that the resulting message 500 will be directed at all other clients on the same side of the road as the client 106 or travelling in the same direction as the client 106 (i.e. target clients having a decreasing mileage denoted by the first byte "-"), but having a higher mileage or positioned to the right of the client 106 (denoted by the second byte "+").

The processing unit 202 then generates the message 500 in step 612 by populating the header field 502 with the IP address of client 106 as well as the IP address of the messaging server 134 and the application field 504 with other data. Specifically, the origin AP subfield field 506 is populated with the AP SSID of the AP with which the client 106 is currently connected. In this example, the client is connected to AP 116, which has an SSID of A014000200. The direction subfield 508 is filled with the string "-+". The message content subfield is filled with the text "Landslide on the A14. West bound lane blocked".

The message 500 is passed onto the radio interface 212 from the processing unit, and transmitted to AP 116 in step 614, which already has a network connection with the client. AP 116 forwards the message onto the messaging server 134 in step 616 over the fixed network 132 based on the destination IP address located in the IP header field 502. Note that reference to the message 500 that is sent by the client 106 to the AP 116 and onto the messaging server has been made using the term "request message" in order to differentiate it from the message that is sent from the messaging server 134 to the target APs later.

When the request message arrives at the messaging server 134, the messaging server 134 extracts the content from the message in step 618, which includes the target direction for the message taken from the direction subfield 508. The messaging server also determines the SSID of the AP to which the client 106 was connected and the message originated from by examining the origin AP subfield 506 in step 620.

The messaging server 134 then uses a lookup table 306 to determine the IP address of AP 116 from which the request message has been sent, based on the SSID in the origin AP subfield 506. The lookup table, Table 2, is shown below. In practice, the lookup table will contain many more entries corresponding to the many numbers of APs.

Table 2

The extracted target direction information is used in conjunction with the originating AP details to determine which APs, or target APs, to forward the message onto. This is shown in step 622. In this example, the target direction is "-+", which indicates a target client moving right to left in direction (or in sector 150) and positioned to the right of (or having a higher mileage than) the sending client 106. As the sending client 106 was connected to a specific AP, the originating AP 116, and the target clients will also each be connected to their own particular AP, the messaging server 134 determines that the message needs to be sent to the APs positioned to the right of (or having a higher mileage than) the originating AP, AP116. As such, the second byte of the target direction is used to determine the target APs in conjunction with the originating AP. In effect, the second Thus, the target APs are AP 118 and AP 120. The lookup table, Table 2, is then used again to determine the IP addresses of target AP 118 and 120 for addressing the message.

Now the target APs have been identified, the request message originally received is forwarded onto the target APs in step 626. The message forwarded is referred to as the target message, and is similar to the request message, except that the header field 502 now contains the IP address of the messaging server 134 as the source IP address and the target AP IP address as the

destination IP address. Furthermore, as we have two target APs, AP 118 and AP 120, two messages are sent: one identified with the destination IP address of AP 118 and the other with the destination IP address of AP 120. For simplicity, only one target message is shown, which is sent to AP 120 in step 626. A person skilled will appreciate that the processing of the message by AP 118 and any subsequent processing will be consistent with that described now with reference to AP 120.

In an alternative embodiment of the invention, the target message can be further simplified in comparison to the request message. It will become apparent later that as well as the message content, only the first byte of the target direction subfield is required by the target clients for filtering the target messages (contrast with the messaging server processing which only requires the second byte). Thus, the messaging server 134 can generate and send a modified target message of the type shown in Figure 7. The modified target message 700 comprises a header field 702, which contains routing data much like header field 502, a one byte target direction field 704 filled with the first byte of the two byte target direction field 508, and the message content field

706, which contains the same message as in message content field 510.

Upon receipt of the target message, AP 120 rebroadcasts the message to all clients within range 128 and connected to AP 120, which are clients 108 and 112.

In step 628a, the target message is transmitted to client 108 by AP 120. The target message is received and processed by a client module 200 in the client 108. The client module 200 extracts the information in the message in step 630a. Using the target direction information in the target direction subfield 508, the client module in the receiving client 108 can filter the message and determine if it is an intended recipient in step 632a. In this case, the target direction is "-+". Now, the client module 200 knows that the messaging server 134 will only have sent the target message to the correctly positioned APs for forwarding, and thus already satisfied the position criteria (second byte of the

target direction 508). Therefore, the client module only needs to determine if the direction of travel as required by the first byte of the target direction 508. In this example, the byte representing the required direction of travel is the first byte, which is a "-" meaning travel in a decreasing mileage or left to right. The client module 200 then examines the AP tables 210 to determine the client 108 direction of travel, which is of a decreasing mileage.

Thus, the client module 200 has determined that the target message is intended for the present client 108, and proceeds to display the message "Landslide on the A14. West bound lane blocked" to the user in step 634a on the message display screen 206.

In contrast, step 628b shows the target message being sent by AP 120 to the other client it is connected to, client 112. Client 112 also has a client module 200 installed, and the client module receives the target message and extracts the data from it in step 630b. The client module then goes onto filter the message in step 632b to determine if the client 112 is an intended recipient of the message. It does this by determining the target direction of travel, which is "-" from the target direction field 508, and the direction of travel of the client 112 as "+" from the AP tables. Thus, the conclusion is that the client 112 is moving in an increasing mileage direction, i.e. left to right, whereas the target message is intended for clients having a decreasing mileage, i.e. travelling right to left. The client module therefore discards the message in step 634b.

The same processing described above by the target clients 108 and 112 would apply if the messaging server 134 sent a modified target message 700 instead. It is clear that the only field required by the target client for deciding whether it is an intended recipient is the one byte denoting the required direction of travel, as it is assumed that the messaging server only sends the message onto correctly positioned APs.

The receiving client module is not limited to a module in a vehicle such as a car. The receiving client could alternatively be a pedestrian user walking along

the roadside with a suitably configured device such as a smartphone including a client module 200. In such circumstances, the client module 200 can be used to filter certain messages leaving only those relevant. For example, a subscription service can be established so that a user can select the type of messages the device will receive and display. In the case of a car user, all traffic messages would likely be subscribed to, but for a pedestrian user, traffic messages would be less relevant, but a message service announcing bus schedules and positions might be more useful.

The present system would be implemented by a network operator, and users could subscribe to the service they require, thereby allowing both the sending and receipt of information with other users on the road. Any misuse of the system can be identified by other users by pointing out spurious messages to the network operator, who can in turn track and if necessary revoke the subscription of the abusive user. This monitoring may be handled by the messaging server, which can keep a log of all message requests by clients and monitor any misuse.

Whilst the system has been described in relation to a IEEE 802.11 network operating with IP based messaging, a person skilled in the art will recognise that the same methods can be applied to other types of wireless network. With such variations, features such as the SSID may be replaced with equivalent features such as basestation ID.

It is noted herein that while the above describes examples of the invention, there are several variations and modifications which may be made to the described examples without departing from the scope of the present invention as defined in the appended claims. One skilled in the art will recognise modifications to the described examples.