WO2009016376A1 - Messagerie directionnelle - Google Patents

Messagerie directionnelle Download PDF

Info

Publication number
WO2009016376A1
WO2009016376A1 PCT/GB2008/002603 GB2008002603W WO2009016376A1 WO 2009016376 A1 WO2009016376 A1 WO 2009016376A1 GB 2008002603 W GB2008002603 W GB 2008002603W WO 2009016376 A1 WO2009016376 A1 WO 2009016376A1
Authority
WO
WIPO (PCT)
Prior art keywords
mobile client
client
message
movement
target
Prior art date
Application number
PCT/GB2008/002603
Other languages
English (en)
Inventor
Heng Tze Chieng
Kee Ngoh Ting
Rafeeza Binti Rahim
Original Assignee
British Telecommunications Public Limited Company
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by British Telecommunications Public Limited Company filed Critical British Telecommunications Public Limited Company
Publication of WO2009016376A1 publication Critical patent/WO2009016376A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W64/00—Locating users or terminals or network equipment for network management purposes, e.g. mobility management
    • H04W64/006—Locating users or terminals or network equipment for network management purposes, e.g. mobility management with additional information processing, e.g. for direction or speed determination
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/12—Messaging; Mailboxes; Announcements

Definitions

  • 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.
  • Wi-Fi Wireless Local Area Networks
  • WLANs Wireless Local Area 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.
  • APs wireless access points
  • a method of transmitting a message in a wireless network from a sending mobile client to a receiving mobile client 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.
  • 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.
  • the sending mobile client determines the direction of movement of the sending mobile client by using a log of previously connected access points.
  • 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.
  • 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.
  • 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.
  • 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
  • FIG. 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
  • 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.
  • FIG. 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.
  • APs wireless access points
  • These wireless APs operate in accordance with the IEEE 802.11 standard for wireless local area networks (WLAN).
  • WLAN wireless local area networks
  • Each of the APs has an associated coverage area wherein any client within that area is provided with wireless LAN access.
  • 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.
  • 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.
  • clients include suitably configured laptops, PDAs or smartphones, as well as dedicated in-car wireless systems.
  • 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.
  • client 108 can connect with AP 120 only as it is located only in coverage area 128 which is associated with AP 120.
  • 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.
  • 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.
  • 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.
  • FIG 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.
  • 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.
  • the APs are identified by a custom identifier.
  • the custom identifier can be used as well as or instead of the standard SSID.
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • the standard SSID field is usually 32 bytes long, which the present invention could be adapted to use instead.
  • 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.
  • RSSI received signal strength indicator
  • FIG. 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.
  • 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).
  • "-" 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.
  • 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.
  • a second byte of "-" would indicate a target client behind that of the sending client i.e. having a lower mileage.
  • 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.
  • target client those positioned to the right of client 106, which results in a target client of client 112.
  • target direction of "-+” were used, then the target client would be client 108 (travelling right to left and positioned to the right).
  • 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.
  • 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".
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the processing unit 202 examines the AP tables 210 stored in the client module.
  • the AP tables include a list of the SSIDs of previously connected APs.
  • the AP LOG shows a list, with most recent or current AP SSID at the top, of SSIDs of previously connected APs.
  • the processing unit 202 uses this table to 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.
  • 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.
  • 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.
  • the origin AP subfield field 506 is populated with the AP SSID of the AP with which the client 106 is currently connected.
  • 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.
  • the messaging server 134 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.
  • 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.
  • 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.
  • 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.
  • the second byte of the target direction is used to determine the target APs in conjunction with the originating AP.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • 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
  • AP 120 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.
  • 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.
  • the client module in the receiving client 108 can filter the message and determine if it is an intended recipient in step 632a.
  • the target direction is "-+".
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention porte sur un procédé de transmission d'un message dans un réseau sans fil d'un client mobile expéditeur à un client mobile de réception, ledit procédé comprenant les étapes consistant à : fournir par un utilisateur une entrée au client mobile expéditeur, ladite entrée correspondant à l'occurrence d'un événement ; déterminer par le client mobile expéditeur la position et la direction d'un mouvement du client mobile expéditeur par rapport à au moins l'un d'une pluralité de points d'accès dans le réseau sans fil ; déterminer par le client mobile expéditeur une direction requise de mouvement et une position requise pour un client mobile de réception, la direction requise de mouvement étant par rapport à la pluralité de points d'accès, et la position requise étant relative à la position du client mobile expéditeur ; et générer un message de requête par le client mobile expéditeur pour transmettre au client mobile de réception, le message de requête comprenant une indication de l'événement, la direction de mouvement requise du client mobile de réception et la position requise du client mobile de réception.
PCT/GB2008/002603 2007-07-31 2008-07-30 Messagerie directionnelle WO2009016376A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
MYPL20071258 2007-07-31
MYPI20071258 2007-07-31

Publications (1)

Publication Number Publication Date
WO2009016376A1 true WO2009016376A1 (fr) 2009-02-05

Family

ID=39864912

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB2008/002603 WO2009016376A1 (fr) 2007-07-31 2008-07-30 Messagerie directionnelle

Country Status (1)

Country Link
WO (1) WO2009016376A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020086659A1 (en) * 1999-08-30 2002-07-04 Eric Lauper Emergency call system within a telecommunication network
US20050259606A1 (en) * 2003-09-23 2005-11-24 Shutter Jon D Method and system for developing traffic messages

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020086659A1 (en) * 1999-08-30 2002-07-04 Eric Lauper Emergency call system within a telecommunication network
US20050259606A1 (en) * 2003-09-23 2005-11-24 Shutter Jon D Method and system for developing traffic messages

Similar Documents

Publication Publication Date Title
CA2953974C (fr) Surveillance de l'etat d'un vehicule au moyen de diffusions cellulaires
US20080186206A1 (en) Communication Device and Communication System as Well as Method of Communication Between and Among Mobile Nodes Such as Vehicles
JP6344239B2 (ja) 交通情報配信システム、セルラ通信システム、及び通信端末
US11810407B2 (en) Selecting V2X communications interface
US8831604B2 (en) Localized information service for cellular networks using multicast channels
US20120003921A1 (en) Solution for the scalability of broadcast forwarding in vehicular networks by map-referenced information on node position
KR101800767B1 (ko) 드론을 이용한 이동통신 기지국 기반의 실시간 도로 교통 정보 분석 시스템
US20120270558A1 (en) System and Method for Providing Geographically-Relevant Informantin to Mobile Users
CN102484781B (zh) 用于提供过滤的本地化信息服务的系统、方法和设备
WO2016206458A1 (fr) Procédé et appareil de traitement d'informations d'alarme dans l'internet des véhicules
US20200327806A1 (en) Connected vehicle platform assisted v2x communications
WO2015001795A1 (fr) Dispositif de distribution, terminal de communication, procédé de distribution, procédé de réception et support lisible par ordinateur non transitoire contenant un programme
CN107369319B (zh) 一种路况信息的获取方法及装置
JP6292222B2 (ja) 通信システム及び配信情報決定装置
US20080275628A1 (en) Method and apparatus for communicating traffic information
US11626022B2 (en) Method, device, and system for detecting a dangerous road event and/or condition
KR20120064938A (ko) 애니캐스트?멀티캐스트 통신 기반 긴급 정보의 수집 및 전달을 위한 방법 및 장치
US20180132083A1 (en) Method, motor vehicle, and system for determining a transmission path
CN107730884B (zh) 交通应用实例处理方法及交通控制单元
CN103971528B (zh) 与被监控车辆互联的智能交通监控系统的实现方法
WO2009016376A1 (fr) Messagerie directionnelle
JP2019067088A (ja) 通信装置、及び報告制御方法
JP2017195556A (ja) 基地局装置および端末装置
CN115440051B (zh) 一种面向大型社区的交通智能管理方法
JP2020102822A (ja) サーバ、通信システム、通信装置、通信方法及びプログラム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08776098

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08776098

Country of ref document: EP

Kind code of ref document: A1