WO2014010102A1

WO2014010102A1 - Technique for distributing a message to mobile terminals that are located in a destination area

Info

Publication number: WO2014010102A1
Application number: PCT/JP2012/068537
Authority: WO
Inventors: Takeshi Matsumura; Shingo Murakami; Toshikane Oda; Shinta Sugimoto
Original assignee: Telefonaktiebolaget L M Ericsson (Publ)
Priority date: 2012-07-13
Filing date: 2012-07-13
Publication date: 2014-01-16

Abstract

There is provided a message distribution server for distributing a message to mobile terminals that are located in a destination area of a predetermined geographical area. The message distribution server can access a tile database storing a plurality of tiles obtained by dividing the predetermined geographical area. Each tile is assigned a multicast address. The message distribution server comprises a message receiving unit configured to receive the message and the destination area, an identifying unit configured to identify, in the tile database, destination tiles for the message, the destination tiles at least partly overlapping the destination area, an obtaining unit configured to obtain multicast addresses assigned to the destination tiles, and a multicasting unit configured to multicast the message to each of the obtained multicast addresses.

Description

DESCRIPTION

TECHNIQUE FOR DISTRIBUTING A MESSAGE TO MOBILE TERMINALS THAT ARE LOCATED IN A DESTINATION AREA

TECHNICAL FIELD

[0001] The present invention generally relates to a technique for distributing a message to mobile

terminals that are located in a destination area.

BACKGROUND

[0002] GeoMessaging is a service to distribute a message to mobile terminals that are located in a certain destination area. An example of GeoMessaging may be known from ETSI TR 102 962 VI.1.1, which is available from

http: //www.etsi. org/deliver/etsi_tr/102900_102999/10296 2/01.01.01_60/trJL02962v010101p.pdf.

[0003] The International Publication No. WO

2012/055433 discloses the grid-based GeoMessaging as a way to realize the GeoMessaging service in an optimal way. According to the grid-based GeoMessaging, a geographical area (GeoMessaging service area) covered by the GeoMessaging service is divided into small grids, and each user or mobile terminal is localized in a certain grid.

[0004] Compared to time-based and distance-based user localization, the grid-based user localization enables faster lookup of users who are located in the destination area of a message. It also enables

horizontal scale out of the system by assigning the grids to different GeoMessaging servers.

[0005] According to the currently known grid-based

GeoMessaging, it is required that a GeoMessaging server maintains two databases, that is a grid database and a user location database.

[0006] The grid database is a database for grid spacing. Specifically, the GeoMessaging service area is divided into small grids, and each grid may further be divided into smaller grids in order to take a balance between the amount of uplink messages for localization of users and the amount of downlink messages the users outside the destination area receive but just ignore. The grid database maintains

information representing how the GeoMessaging service area is divided into grids.

[0007] The user location database is a database for keeping track of users in each grid. Specifically, the user location database maintains information about the geographical location of mobile terminals (i.e., information representing which user is located in which grid) .

SUMMARY

[0008] The present invention has been made in view of the above circumstances, and it is an object thereof to eliminate the necessity of a database for

maintaining information about the geographical location of mobile terminals.

[0009] According to the first aspect of the

present invention, there is provided a message

distribution server for distributing a message to mobile terminals that are located in a destination area of a predetermined geographical area. The message distribution server can access a tile database storing a plurality of tiles obtained by dividing the

predetermined geographical area. Each tile is assigned a multicast address. The message distribution server comprises: a message receiving unit configured to receive the message and the destination area; an

identifying unit configured to identify, in the tile database, destination tiles for the message, the

destination tiles at least partly overlapping the destination area; an obtaining unit configured to obtain multicast addresses assigned to the destination tiles; and a multicasting unit configured to multicast the message to each of the obtained multicast addresses.

[0010] According to the second aspect of the present invention, there is provided a mobile terminal for use in a predetermined geographical area divided into a plurality of tiles each of which is assigned a multicast address. The mobile terminal comprises: an obtaining unit configured to obtain a multicast address assigned to a current-location tile which is a tile covering a geographical location of the mobile

terminal; a joining unit configured to join a multicast group corresponding to the multicast address assigned to the current-location tile; and a multicast receiving unit configured to receive a multicast message directed to the multicast group which the joining unit has joined.

[0011] According to the third aspect of the present invention, there is provided a method for controlling a message distribution server for

distributing a message to mobile terminals that are located in a destination area of a predetermined geographical area. The message distribution server can access a tile database storing a plurality of tiles obtained by dividing the predetermined geographical area. Each tile is assigned a multicast address. The method comprises: a message receiving step of receiving the message and the destination area; an identifying step of identifying, in the tile database, destination tiles for the message, the destination tiles at least partly overlapping the destination area; an obtaining step of obtaining multicast addresses assigned to the destination tiles; and a multicasting step of

multicasting the message to each of the obtained multicast addresses. [0012] According to the fourth aspect of the present invention, there is provided a method for controlling a mobile terminal for use in a

predetermined geographical area divided into a

plurality of tiles each of which is assigned a

multicast address. The method comprises: an obtaining step of obtaining a multicast address assigned to a current-location tile which is a tile covering a

geographical location of the mobile terminal; a joining step of joining a multicast group corresponding to the multicast address assigned to the current-location tile; and a multicast receiving step of receiving a multicast message directed to the multicast group which has been joined in the joining step.

[0013] By virtue of the above features, it is possible to distribute a message to mobile terminals that are located in a destination area, without the necessity of a database for maintaining information about the geographical location of mobile terminals.

[0014] Further features and advantages of the present invention will be apparent from the following description with reference to the accompanying drawings, in which like reference characters designate the same or similar parts throughout the figures thereof.

BRIEF DESCRIPTION OF DRAWINGS

[0015] Fig. 1 illustrates an overview of a GeoMessaging system 100 according to the first

embodiment of the present invention;

[0016] Fig. 2 is a sequence diagram illustrating a location-registration procedure and a message- distribution procedure according to the first

embodiment of the present invention;

[0017] Fig. 3 is a sequence diagram illustrating a location-update procedure according to the first embodiment of the present invention;

[0018] Fig. 4 schematically illustrates a scenario in which two or more tiles are assigned the same multicast address and distinguished from each other by means of the multicast source address;

[0019] Fig. 5 is a functional block diagram of the

GeoMessaging server 101 according to the first

embodiment of the present invention;

[0020] Fig. 6 is a functional block diagram of the mobile terminal 104 according to the first embodiment of the present invention;

[0021] Fig. 7 is a sequence diagram illustrating a location-registration procedure according to the second embodiment of the present invention;

[0022] Fig. 8 is a sequence diagram illustrating a location-registration procedure and a location-update procedure according to the third embodiment of the present invention; and

[0023] Fig. 9 illustrates an overview of a GeoMessaging system 900 according to the fourth

embodiment of the present invention.

DETAILED DESCRIPTION

(First Embodiment)

System Overview

[0024] Fig. 1 illustrates an overview of a

GeoMessaging system 100 according to the first

embodiment of the present invention.

[0025] In Fig. 1, a GeoMessaging server 101, which is also referred to as a message distribution server, is responsible for a GeoMessaging service for a

predetermined geographical area (e.g., the entirety of Japan) , which is also referred to as a GeoMessaging service area. The GeoMessaging server 101 divides the GeoMessaging service area into a plurality of tiles to generate a tile set, and stores the tile set in a tile database (DB) 102. Each tile is assigned an IP

multicast address, which is simply referred to as a multicast address hereinafter, and a GeoMessaging message is distributed through a multicast network 103.

[0026] The multicast network 103 is a network that is capable of maintaining IP multicast clients (such as mobile terminals 104 shown in Fig. 1) and distributing IP multicast messages to the clients. Specifically, the multicast network 103 includes a plurality of multicast routers 105, and supports IGMP (Internet Group Management Protocol) and/or MLD (Multicast

Listener Discovery) in order to let the clients join a multicast group corresponding to a certain IP multicast address .

[0027] The mobile terminal 104 informs its

geographical location to the GeoMessaging server 101, and receives therefrom a multicast address which is assigned to a tile (current-location tile) covering the geographical location. The mobile terminal 104 then registers itself with a tile by joining the multicast group corresponding to the received multicast address (see an arrow 106 shown in Fig. 1) .

[0028] A message source 107 is a network node which wishes to distribute a GeoMessaging message to mobile terminals located in a certain destination area. The message source 107 requests for the distribution of the GeoMessaging message by sending it together with the destination area to the GeoMessaging server 101. It should be noted that the mobile terminals 104 may act as the message source 107.

[0029] When the GeoMessaging server 101 receives a

GeoMessaging message together with a destination area from the message source 107, the GeoMessaging server 101 identifies the tiles corresponding to the

destination area and multicasts the GeoMessaging message to the multicast addresses corresponding to the identified tiles. Location-registration Procedure and Message- distribution Procedure

[0030] Fig. 2 is a sequence diagram illustrating a location-registration procedure and a message- distribution procedure according to the first

embodiment of the present invention. Although Fig. 2, as well as Figs. 3, 7, and 8 which are described later, show only one mobile terminal 104 for the sake of simplicity, the GeoMessaging system 100 of the present invention may include two or more mobile terminals 104 as shown in Fig. 1, and every mobile terminal included in the GeoMessaging system 100 may operate in the same way .

[0031] When the GeoMessaging server 101 starts up, in step S201, the GeoMessaging server 101 generates a plurality of tiles by dividing a predetermined

GeoMessaging service area, and stores them in the tile DB 102. Hereinafter, the tiles stored in the tile DB 102 are also referred to as a "tile set". The tile set may specify each tile based on the tile ID and the geographical information. In step S202, the

GeoMessaging server 101 assigns a multicast address to each tile. Details of the generation of the tile set and the assignment of the multicast address will be described later.

[0032] When the mobile terminal 104 starts up or its GeoMessaging functionality is activated, in step S203, the mobile terminal 104 identifies its

geographical location by using GPS or some other mechanism. In step S204a, the mobile terminal 104 sends its geographical location to the GeoMessaging server 101.

[0033] In-some alternative embodiments, in step

S204b, the GeoMessaging server 101 may receive the geographical location of the mobile terminal 104 from a location server (not shown) in a mobile network. The location server identifies the geographical location of a mobile terminal operating in the mobile network based on the positional relationship between the mobile terminal and base stations around the mobile terminal. In this case, steps S203 and S204a may be omitted.

[0034] In step S205, the GeoMessaging server 101 identifies, with reference to the tile DB 102, a tile (current-location tile of the mobile terminal 104) which covers the geographical location received in step S204a or S204b. In step S206, the GeoMessaging server 101 obtains, with reference to the tile DB 102, the multicast address which is assigned to the current- location tile. In step S207, the GeoMessaging server 101 sends the multicast address, as well as information (tile information) representing the current-location tile, to the mobile terminal 104.

[0035] In step S208,. the mobile terminal 104 joins a multicast group corresponding to the received

multicast address by sending an IGMP or MLD join message to the multicast network 103 (to be more exact, to the closest multicast router) . Then, the closest multicast router and the intermediate multicast routers leading to the GeoMessaging server 101 send the join message to the upper multicast router in the multicast tree as needed. It should be noted that it is not necessary for the GeoMessaging server 101 to maintain which mobile terminal joined the multicast group. It is only the first hop multicast router which knows that the mobile terminal 104 joined the multicast group.

[0036] At this point in time, the location

registration of the mobile terminal 104 has been completed. In other words, according to the present embodiment, the mobile terminal 104 can register itself with the current-location tile by joining the multicast group corresponding to the current-location tile.

[0037] When some event such as a traffic accident occurs, the message source 107 (not shown in Fig. 2) decides to send a GeoMessaging message to the users who are likely interested in this event. The message source 107 determines the destination area of the

GeoMessaging message, and sends the GeoMessaging message together with the destination area to the

GeoMessaging server 101. In step S209, the

GeoMessaging server 101 receives them from the message source 107.

[0038] In step S210, The GeoMessaging server 101 identifies, with reference to the tile DB 102, the tiles (destination tiles) which at least partly overlap the destination area. In step S211, the GeoMessaging server 101 obtains, with reference to the tile DB 102, the multicast addresses assigned to the destination tiles .

[0039] In step S212, the GeoMessaging server 101 multicasts the GeoMessaging message through the

multicast network 103 by sending it to the multicast addresses obtained in step S211. Assuming that the mobile terminal 104 has joined the multicast group corresponding to one of the multicast addresses

obtained in step S211, in step S213, the multicast network distributes the GeoMessaging message to the mobile terminal 104. Moreover, as schematically illustrated by dashed arrows following step S213, the GeoMessaging message is distributed to every mobile terminal which has joined^' the multicast group

corresponding to one of the multicast addresses

obtained in step S211.

[0040] When the mobile terminal 104 is terminated or its GeoMessaging functionality is de-activated, the mobile terminal 104 leaves the multicast group which it has joined in step S208.

[0041] Next, with reference to Fig. 3, the location-update procedure for allowing the mobile terminal 104 to move to another tile is described.

[ 0042 ] In step S301, the mobile terminal 104 periodically identifies its geographical location, and detects that the latest geographical location is outside the current-location tile. The mobile terminal 104 is capable of this detection because it has received the tile information of the current-location tile in step S207.

[0043] In step S302, in accordance with the processing of steps S204a-S208 of Fig. 2, the mobile terminal 104 joins a new multicast group corresponding to a new current-location tile which covers the latest geographical location.

[0044 ] In step S303, the mobile terminal 104 waits until a predetermined period of time passes.

[0045] In step S304, the mobile terminal 104 leaves the previously joined multicast group (i.e., the multicast group corresponding to the old current- location tile) . Because this step is executed after the predetermined period of time passes from the joining to the new multicast group, it is possible to avoid the situation in which the mobile terminal 104 repeats the joining to and leaving from the multicast groups in a short period of time when the mobile terminal 104 repeatedly crosses the border of the tile in a short period of time. [ 0046] At this point in time, the location update

(i.e., registration with the new current-location tile and de-registration with the old current-location tile) of the mobile terminal 104 has been completed.

Generation of Tile Set and Assignment of Multicast Address

[ 0047 ] Next, an example of details of the

generation of the tile set and the assignment of the multicast address in steps S201-S202 are described.

[ 0048] When the GeoMessaging server 101 generates the tile set, it assigns a tile ID to each tile.

Specifically, the GeoMessaging server 101 utilizes the quaternary spatial partitioning to generate the tile set and assign a tile ID to each tile. Moreover, the GeoMessaging server 101 comprises a multicast address calculator, which is a function to map a tile ID to a multicast address.

[0049] The quaternary spatial partitioning is a way to split a space into four smaller spaces of the same size and apply the same operation to smaller spaces recursively. In the tile-based GeoMessaging service, it is advantageous to generate various sizes of tiles in view of the load balancing. For example, assuming the case that GeoMessaging messages are frequently directed to various small parts of a certain region of the GeoMessaging service area, the signaling load may be reduced if smaller tiles cover this region. The quaternary spatial partitioning can be used for generating various sizes of tiles by adjusting how many times each tile is recursively split. In this case, the tile DB 102 is structured in a quadtree or a linear quadtree (see http://en.wikipedia.org/wiki/Quadtree).

[0050] In this case, an identity (tile ID) needs to be assigned to each tile and also needs to be mapped to a multicast address. In the tile-based GeoMessaging service, a tile may be split into smaller tiles

dynamically. If the quaternary spatial partitioning is employed, each tile can be identified with the Morton order. The Morton order does not change even if a tile is split dynamically (see

http://en.wikipedia.org/wiki/Z-order_curve). A tile ID generated according to the Morton order contains the identities of the parent and ancestor tiles as part of the tile ID. This means that a longer tile ID is assigned to a tile with smaller size, and the maximum length of the tile ID depends on how many times a tile is split recursively.

[0051] For example, the land of Japan can be covered by a square having a single side length of 2271km. Assuming that the minimum tile size for the GeoMessaging service is 10000m² (100m * 100m), the square can be split 15 times at most (i.e.,

log₂ (2271000 / 100) < 15). This means that at most 15 bits are needed to identify a tile in one direction (i.e., either latitude or longitude), and thus 30 bits are needed at most to identify a tile in the entirety of the land of Japan. Moreover, an extra 4 bits are needed to specify the length of the tile ID, because not all tiles are split for 15 times. Thus, the length of the tile IDs assigned according to the Morton order will be 34 bits to cover the land of Japan with minimum tile size of 10000m².

[0052] Next, how to map tile IDs to multicast addresses is described. A tile ID assigned according to the Morton order can directly be mapped to an IPv6 multicast address, because the multicast group id field has 112 bits. This length is sufficient for the land of Japan because only 34 bits are required for the land of Japan as described above, and it is expected that this length of 112 bits is sufficient for any

GeoMessaging service area.

[0053] In cases that the length of multicast group id field is shorter (for example, in cases that IPv4 multicast addresses are used) , only the lower bits may be taken from the tile ID and mapped to the multicast group id field so that the tile ID is shortened to fit into the shorter multicast group id field. For example, in the above case where 30 bits are needed at most to identify a tile, the lower 14 bits may be taken from the 30 bits. This can be achieved by limiting the largest tile size to 100 km² (10km * 10km) (i.e., log₂(2271000 / 100) - log₂(2271000 / 10000) < 7, 7 * 2 = 14). In this case, an extra 3 bits are needed to specify the length of the shortened tile ID, and the total 17 bits are mapped to the multicast group id field. When the tile ID is shortened in this way, a plurality of tiles corresponding to different areas may be assigned the same multicast group id (i.e., the same multicast address) . In this case, they must be

distinguished from each other by using different IP multicast source addresses. In other words, each tile can be identified by a pair of a multicast address and a multicast source address (Fig. 4).

[0054] In Fig. 4, tiles in the area 401 are served by the GeoMessaging server #1, which has the multicast source address #1. Similarly, tiles in the area 402 are served by the GeoMessaging server #2, which has the multicast source address #2, and tiles in the area 403 are served by the GeoMessaging server #3, which has the multicast source address #3. The tiles 411, 412, and 413 are assigned the same multicast address, but they can be distinguished from each other by means of the multicast source address. For example, the tile 411 can be identified by the pair of its multicast address and the multicast source address #1.

[0055] In a case that the tiles are identified by a pair of the multicast address and the multicast source address, in step S202 of Fig. 2, the GeoMessaging server 101 further assigns a multicast source address to each tile. Then, in step S206, the GeoMessaging server 101 further obtains the multicast source address assigned to the current-location tile. In step S207, the GeoMessaging server 101 further sends the multicast source address to the mobile terminal 104. In step S208, the mobile terminal 104 joins a multicast group corresponding to the pair of the multicast

address and the multicast source address. In step S211, the GeoMessaging server 101 further obtains the

multicast source addresses assigned to the current- location tile. In step S212, the GeoMessaging server 101 performs the multicast of the GeoMessaging message based on the pairs of the multicast message and the multicast source address obtained in step S211.

Dynamic Division/Merging of Tile

[0056] The GeoMessaging server 101 can dynamically divide a tile into smaller tiles, and merge a plurality of adjacent tiles to generate a larger tile. The division of a tile can be performed in accordance with the quaternary spatial partitioning as described above. The merging of tiles can be performed by identifying the parent tile for the tiles to be merged.

[0057] When the GeoMessaging server 101 divides a tile into smaller tiles, it adds the new tiles to the tile set stored in the tile DB 102, and marks the tile (parent tile) which was divided into smaller tiles as "disabled for registration". Moreover, the

GeoMessaging server 101 assigns a multicast address to each new tile.

[0058] When the GeoMessaging server 101 merges adjacent tiles to generate a larger tile, it adds the new tile to the tile set stored in the tile DB 102, and marks the tiles which were merged as "disabled for registration". Moreover, the GeoMessaging server 101 assigns a multicast address to the new tile.

[0059] The GeoMessaging server 101 does not accept new location registration to the tiles which are marked as "disabled for registration". For this purpose, if a new tile or tiles are added to the tile DB 102 and two or more tiles cover the geographical location of the mobile terminal 104, in step S207 of Fig. 2, the

GeoMessaging server 101 sends a multicast address assigned to one of these tiles which was most recently added to the tile DB 102. Alternatively, the^'

GeoMessaging server 101 sends a multicast address assigned to the tile which is not marked as "disabled for registration".

[0060] However, the mobile terminals 104 currently registered with those tiles (i.e., the mobile terminals 104 which have joined the multicast groups

corresponding to those tiles) can stay in "disabled for registration" tiles until they run the next location- registration or location-update procedure. In step S210 of Fig. 2, the GeoMessaging server 101 can

identify the destination tiles even if they are marked as "disabled for registration". Accordingly, the mobile terminal can receive a GeoMessaging message in step S213 even if the current-location tile has been divided or merged, and marked as "disabled for

registration" .

[0061] In order to facilitate de-registration from the "disabled for registration" tile, the mobile terminal 104 periodically (e.g., once in 24 hours) sends its geographical location in step S204a (Fig. 2), even if the geographical location does not change. In this case, if the current-location tile has been divided or merged, the mobile terminal 104 receives a different multicast address in step S207. Accordingly, the mobile terminal 104 joins a different multicast group in step S208, and leaves the previously joined multicast group in step S304 (Fig. 3) .

[0062] Alternatively, when the GeoMessaging server

101 divides a tile or merges tiles, the GeoMessaging server 101 may multicast a GeoMessaging message to the multicast group (s) corresponding to the divided tile or the merged tiles. Upon reception of this GeoMessaging message, the mobile terminal 104 sends its geographical location in step S204a (Fig. 2) , and receives a different multicast address in step S207. Accordingly, the mobile terminal 104 can promptly join a different multicast group and leave the previously joined

multicast group corresponding to the divided tile or one of the merged tiles.

[0063] Finally, every mobile terminal which has joined the multicast group of the "disabled for

registration" tile leaves this multicast group and joins a new multicast group. After that, the

GeoMessaging server 101 can safely remove the "disabled for registration" tile from the tile set stored in the tile DB 102, if needed.

[0064] In order for the GeoMessaging server 101 to determine whether or not the "disabled for

registration" tile can be removed from the tile set, when the GeoMessaging server 101 divides a tile or merges tiles, it starts a timer to count a

predetermined period of time corresponding to the frequency of the location update in step S301. The GeoMessaging server 101 removes the divided tile or merged tiles from the tile set when the timer expires.

[0065] Alternatively, the GeoMessaging server 101 may query the closest multicast routers about the list of multicast addresses corresponding to the multicast groups which at least one mobile terminal 104 joins. Such a list is always maintained by the closest

multicast routers by using a multicast protocol, because the list is needed to determine to which multicast routers multicast messages should be

forwarded. The GeoMessaging server 101 can identify, among the tiles marked as "disabled for registration", the tiles which do not have a mobile terminal anymore by comparing the list with the multicast addresses assigned to the tiles marked as "disabled for

registration". Then, the GeoMessaging server 101 may remove the identified tiles from the tile set stored in the tile DB 102.

Functional Blocks of the GeoMessaging Server 101 and the Mobile Terminal 104

[0066] Fig. 5 is a functional block diagram of the

GeoMessaging server 101 according to the first

embodiment of the present invention. The GeoMessaging server 101 comprises a message receiving unit 501, an identifying unit 502, an obtaining unit 503, and a multicasting unit 504. The GeoMessaging server 101 also comprises a location receiving unit 505, a sending unit 506, a generating unit 507, and an assigning unit 508. The GeoMessaging server 101 may further comprise a providing unit 509, which will be described later in the third embodiment of the present invention.

[0067] The message receiving unit 501 is

configured to receive the message and the destination area. The identifying unit 502 is configured to identify, in the tile DB 102, destination tiles for the message, the destination tiles at least partly

overlapping the destination area. The obtaining unit 503 is configured to obtain multicast addresses

assigned to the destination tiles. The multicasting unit 504 is configured to multicast the message to each of the obtained multicast addresses.

[0068] The location receiving unit 505 is

configured to receive a geographical location of a mobile terminal 104. The sending unit 506 is

configured to send, to the mobile terminal 104, the multicast address assigned to the current-location tile. The generating unit 507 is configured to generate the plurality of tiles by dividing the predetermined

geographical area. The assigning unit 508 is

configured to assign a multicast address to each of the plurality of tiles.

[0069] The GeoMessaging server 101 further

comprises a central processing unit (CPU) 510, a read only memory (ROM) 511, and a random access memory (RAM) 512. The functionality of the units 501-509 of the GeoMessaging server 101 may be implemented by the CPU 510 which executes software stored in the ROM 511 with using the RAM 512 as a work area. Alternatively, the functionality of some or all of the units 501-509 may be implemented using dedicated hardware, or by the combination of software and hardware. [0070] Fig. 6 is a functional block diagram of the mobile terminal 104 according to the first embodiment of the present invention. The mobile terminal 104 comprises an obtaining unit 601, a joining unit 602, and a multicast receiving unit 603. The mobile

terminal 104 also comprises an identifying unit 604. The mobile terminal 104 may further comprise an

information receiving unit 605, which will be described later in the third embodiment of the present invention.

[0071] The obtaining unit 601 is configured to obtain a multicast address assigned to a current- location tile which is a tile covering a geographical location of the mobile terminal. The joining unit 602 is configured to join a multicast group corresponding to the multicast address assigned to the current- location tile. The multicast receiving unit 603 is configured to receive a multicast message directed to the multicast group which the joining unit has joined. The identifying unit 604 is configured to identify the geographical location of the mobile terminal 104.

[0072] The mobile terminal 104 further comprises a central processing unit (CPU) 606, a read only memory (ROM) 607, and a random access memory (RAM) 608. The functionality of the units 601-605 of the mobile terminal 104 may be implemented by the CPU 606 which executes software stored in the ROM 607 with using the RAM 608 as a work area. Alternatively, the functionality of some or all of the units 601-605 may be implemented using dedicated hardware, or by the combination of software and hardware.

[0073] According to the above-described message distribution procedure, as long as the mobile terminal 104 joins the multicast group corresponding to the multicast address assigned to the current-location tile, the mobile terminal 104 can receive a GeoMessaging message directed to the destination area which at least partly includes the current-location tile. Because the distribution of the GeoMessaging message can be

performed by means of the standardized multicast

delivery mechanism (e.g., see RFC 791, and RFC 1112), it is not necessary for the GeoMessaging server 101 to know the tile in which the mobile terminal 104 is currently located.

[0074] Consequently, according to the present embodiment, it is possible to distribute a GeoMessaging message to mobile terminals that are located in a destination area, without the necessity of a database for maintaining information representing where mobile terminals are located. This makes it easier for the GeoMessaging server 101 to horizontally scale out.

Moreover, efficiency of IP packet usage is improved, thanks to the nature of IP multicast.

(Second Embodiment) [0075] In the second embodiment, the GeoMessaging server 101 may generate a tile set in a manner that two or more tiles may cover a certain geographical location. The differences from the first embodiment will be described with reference to Fig. 7.

[0076] Fig. 7 is a sequence diagram illustrating a location-registration procedure according to the second embodiment of the present invention.

[0077 ] When the GeoMessaging server 101 starts up, in step S701, the GeoMessaging server 101 generates a plurality of tiles by dividing a predetermined

GeoMessaging service area, and^' stores them in the tile DB 102. The generation of the plurality of tiles may be performed based on the quaternary spatial

partitioning, as described in the first embodiment.

Although the tile set of the first embodiment does not include a parent tile which has been divided into smaller tiles, according to the second embodiment, the tile set may include such a parent tile as a valid tile. Accordingly, some geographical locations may be covered by a plurality of tiles with various sizes.

[0078 ] In step S702, the GeoMessaging server 101 identifies, with reference to the tile DB 102, one or more tiles (current-location tiles) which cover the geographical location received in step S204a or S204b. Because the tile set may include some parent tiles, two or more tiles may be identified as covering the geographical location. In step S703, the GeoMessaging server 101 obtains, with reference to the tile DB 102, one or more multicast addresses which are assigned to the one or more current-location tiles identified in step S702. In step S704, the GeoMessaging server 101 sends the one or more multicast addresses, as well as information (tile information) which represents the one or more current-location tiles, to the mobile terminal 104.

[0079] If the mobile terminal 104 receives two or more multicast addresses in step S704, in step S705, the mobile terminal selects one of the received

multicast addresses. In step S706, the mobile terminal 104 joins a multicast group corresponding to the selected multicast address by sending an IGMP or MLD join message to the multicast network 103 (to be more exact, to the closest multicast router) .

[0080] As with the first embodiment, the

GeoMessaging server 101 can dynamically divide a tile into smaller tiles, and merge a plurality of tiles to generate a larger tile. In the second embodiment, the GeoMessaging server 101 may keep the divided tile or the merged tiles valid. In other words, it is not mandatory for the GeoMessaging server 101 to mark the divided tile or the merged tiles as "disabled for registration". If the divided tile or the merged tiles are kept valid, two or more tiles may be identified in step S702 as covering the geographical location of the mobile terminal 104, and every multicast address assigned to the identified tiles which are not marked as "disabled for registration" is sent to the mobile terminal 104.

[0081] The location-registration procedure of the present embodiment can enhance the protection of user privacy. Specifically, if the user controls the mobile terminal 104 to select a multicast address

corresponding to a larger tile in step S705, the details of his/her movement in the GeoMessaging service area can be hidden from the multicast network 103 and/or GeoMessaging server 101. On the other hand, if the user controls the mobile terminal 104 to select a multicast address corresponding to a smaller tile in step S705, the possibility of receiving a GeoMessaging message which is not directed to his/her current geographical location can be reduced.

(Third Embodiment)

[0082] In the third embodiment, techniques for reducing the signaling load between the GeoMessaging server 101 and the mobile terminal 104 are described.

[0083] As a first technique, the GeoMessaging server 101 provides neighbor tile information when it sends the multicast address for the current-location tile. Specifically, with reference to Fig. 2, in step S205, the GeoMessaging server 101 further identifies the neighboring tiles of the current-location tile. In step S206, the GeoMessaging server 101 further obtains the multicast addresses assigned to the neighboring tiles. In step S207, the GeoMessaging server 101 further sends multicast addresses assigned to the neighboring tiles to the mobile terminal 104.

[0084] In this case, even if the mobile terminal

104 detects that the latest geographical location is outside the current-location tile in step S301 (Fig. 3), if the new current-location tile is one of the

neighboring tiles, the mobile terminal 104 can join a multicast group for the new current-location tile in step S208, without the signaling in steps S204-S207.

[0085] As a second technique, the GeoMessaging server 101 provides the mobile terminal 104 with the multicast address calculator in place of the multicast address for the current-location tile. Specifically, with reference to Fig. 8, upon the reception of the geographical location of the mobile terminal 104 in step S204a or S204b, in step S801, the GeoMessaging server 101 obtains the tile set from the tile DB 102. In step S802, the GeoMessaging server 101 sends the tile set together with the multicast address calculator to the mobile terminal 104. Consequently, the mobile terminal 104 has the same multicast address calculator as the GeoMessaging server 101. Therefore, in step S803, the mobile terminal can identify the current- location tile based on the tile set and calculate the multicast address for the current-location tile.

[0086] More generally, the providing unit 509 (Fig.

5) of the GeoMessaging server 101 provides the mobile terminal 104 with information representing the tiles stored in the tile DB 102 and information representing corresponding multicast addresses, and the information receiving unit 605 (Fig. 6) of the mobile terminal 104 receives information representing the plurality of tiles and information representing corresponding multicast addresses from the GeoMessaging server 101. The combination of the tile ID and the multicast address calculator is an example of the information representing the corresponding multicast addresses.

[0087] Once the mobile terminal 104 is provided with the multicast address calculator and the tile set, when the mobile terminal 104 detects that the latest geographical location is outside the current-location tile in step S301, in step S804, the mobile terminal 104 can identify the new current-location tile and calculate the multicast address for the new current- location tile without querying the GeoMessaging server 101. Accordingly, the signaling load between the

GeoMessaging server 101 and the mobile terminal 104 is reduced. Then, in step S805, the mobile terminal 104 joins a multicast group for the new current-location tile .

[0088] When the GeoMessaging server 101 divides a tile or merges tiles and the tile set is updated, the GeoMessaging server 101 sends the updated tile set to the mobile terminal 104. Although this increases the signaling load between the GeoMessaging server 101 and the mobile terminal 104, because the frequency of the update of the tile set is usually smaller than the frequency of the location update of the mobile terminal 104, it is expected that the entire signaling load between the GeoMessaging server 101 and the mobile terminal 104 can be reduced.

(Fourth Embodiment)

[0089] In the fourth embodiment, the Multimedia

Broadcast Multicast Service (MBMS) network is used as a multicast network for distributing a message. The MBMS is a way to multicast data to users in a cell or in multiple cells over the radio access, available in W- CDMA/GPRS and LTE/EPS networks (see 3GPP TS 23.246).

[0090] Fig. 9 illustrates an overview of a

GeoMessaging system 900 according to the fourth

embodiment of the present invention. In Fig. 9, the multicast network 103 (Fig. 1) is replaced by the multicast network 901, which implements the MBMS.

[0091] The BM-SC provides functions for MBMS user service provisioning and delivery to the content provider. It can also serve as an entry point for IP MBMS data traffic from the MBMS User Service source. The BM-SC has the function to announce MBMS services to the clients. It maintains the IP multicast addresses and includes one in a service announcement to MBMS clients. The GGSN (for GPRS) or MBMS-G (for EPS) serves as an entry point for IP multicast traffic as MBMS data from the BM-SC.

[0092] A client who wants to receive data over the

MBMS joins an IP multicast address by using IGMP (IPv4) or MLD (IPv6). This means that the GeoMessaging server 101 and the mobile terminal 104 can operate in a similar way to the first, second, and third embodiments even when the MBMS is used. The GeoMessaging server 101 assigns a multicast address to each tile and provision the address to the BM-SC.

[0093] When the tile set in the tile DB 102 is initially configured or updated, the GeoMessaging server 101 registers or de-registers an MBMS service including the multicast address with the BM-SC. The GeoMessaging server 101 configures the BM-SC to disable service announcement of the registered MBMS services for these IP multicast addresses, because the BM-SC does not consider a geographical location of the mobile terminal 104 when the BM-SC announce services. The multicast address for a tile is given to the mobile terminal 104 when the mobile terminal 104 informs its geographical location to the GeoMessaging server 101.

[0094] The cellular networks can choose to use multicast or unicast in the radio access, for instance by counting the number of mobile terminals joining an IP multicast group.

[0095] The present invention is not limited to the above-described embodiment, and various changes and modifications can be made within the spirit and scope of the present invention. Therefore, to apprise the public of the scope of the present invention, the following claims are made.

Claims

1. A message distribution server (101) for

distributing a message to mobile terminals (104) that are located in a destination area of a predetermined geographical area, wherein the message distribution server can access a tile database (102) storing a plurality of tiles obtained by dividing the

predetermined geographical area and each tile is

assigned a multicast address, the message distribution server comprising:

a message receiving unit (501) configured to receive the message and the destination area;

an identifying unit (502) configured to identify, in the tile database, destination tiles for the message, the destination tiles at least partly overlapping the destination area;

an obtaining unit (503) configured to obtain multicast addresses assigned to the destination tiles; and

a multicasting unit (504) configured to multicast the message to each of the obtained multicast addresses.

2. The message distribution server according to

Claim 1, further comprising a location receiving unit (505) configured to receive a geographical location of a mobile terminal,

wherein : the identifying unit identifies, in the tile database, a current-location tile of the mobile terminal by identifying a tile covering the

geographical location;

the obtaining unit obtains a multicast address assigned to the current-location tile; and

the message distribution server further comprises a sending unit (506) configured to send, to the mobile terminal, the multicast address assigned to the

current-location tile.

3. The message distribution server according to Claim 2, wherein:

the identifying unit further identifies, in the tile database, neighboring tiles of the current- location tile;

the obtaining unit further obtains multicast addresses assigned to the neighboring tiles; and

the sending unit further sends, to the mobile terminal, the multicast addresses assigned to the neighboring tiles.

4. The message distribution server according to Claim 2 or 3, further comprising:

a generating unit (507) configured to generate the plurality of tiles by dividing the predetermined geographical area; and an assigning unit (508) configured to assign a multicast address to each of the plurality of tiles;

5. The message distribution server according to Claim 4, wherein:

the generating unit adds, to the tile database, one or more new tiles obtained by dividing one of the existing tiles or merging a part of the existing tiles; and

the assigning unit assigns a multicast address to each new tile.

6. The message distribution server according to Claim 5, wherein if two or more tiles stored in the tile database cover the geographical location, the sending unit sends, as the multicast address assigned to the current-location tile, a multicast address assigned to one of said two or more tiles which was most recently added to the tile database.

7. The message distribution server according to Claim 5 or 6, wherein the generating unit removes, from the tile database, said one of the existing tiles or said part of the existing tiles when a predetermined period of time has passed from the addition of the plurality of new tiles or when it is determined that there is no mobile terminal joining a multicast group corresponding to the multicast address assigned to said one of the existing tiles or said part of the existing tiles .

8. The message distribution server according to

Claim 5, wherein:

the generating unit marks one of the existing tiles as being disabled; and

if two or more tiles stored in the tile database cover the geographical location, the sending unit sends, as the multicast address assigned to the current- location tile, every multicast address assigned to the tiles which are not marked as being disabled.

9. The message distribution server according to

Claim 8, wherein the generating unit removes, from the tile database, the tiles which are marked as being disabled when a predetermined period of time has passed from the marking or when it is determined that there is no mobile terminal joining a multicast group

corresponding to the multicast address assigned to the tiles which are marked as being disabled.

10. The message distribution server according to

Claim 1, further comprising a providing unit (509) configured to provide a mobile terminal with

information representing the tiles stored in the tile database and information representing corresponding multicast addresses.

11. The message distribution server according to any one of Claims 1-10, wherein:

each tile stored in the tile database is also assigned a multicast source address;

the obtaining unit further obtains multicast source addresses assigned to the destination tiles; and for each of the multicast addresses assigned to the destination tiles, the multicasting unit performs the multicast of the message using the multicast source address assigned to the corresponding destination tile.

12. A mobile terminal (104) for use in a

predetermined geographical area divided into a

plurality of tiles each of which is assigned a

multicast address, comprising:

an obtaining unit (601) configured to obtain a multicast address assigned to a current-location tile which is a tile covering a geographical location of the mobile terminal;

a joining unit (602) configured to join a

multicast group corresponding to the multicast address assigned to the current-location tile; and

a multicast receiving unit (603) configured to receive a multicast message directed to the multicast group which the joining unit has joined.

13. The mobile terminal according to Claim 12, further comprising an identifying unit (604) configured to identify the geographical location of the mobile terminal .

14. The mobile terminal according to Claim 13, wherein the obtaining unit obtains the multicast address assigned to the current-location tile from a message distribution server (101) by sending the geographical location to the message distribution server .

15. The mobile terminal according to Claim 14, wherein :

the obtaining unit further obtains information representing the current-location tile from the message distribution server;

the identifying unit periodically identifies the geographical location of the mobile terminal; and

if the latest geographical location is outside the current-location tile, the obtaining unit obtains a multicast address assigned to a new current-location tile and information representing the new current- location by sending the latest geographical location to the message distribution server.

16. The mobile terminal according to Claim 15, wherein the joining unit leaves the multicast group corresponding to the multicast address assigned to the previous current-location tile when a predetermined period of time has passed from the joining to the multicast group corresponding to the multicast address assigned to the new current-location tile.

17. The mobile terminal according to Claim 15 or 16, wherein :

the obtaining unit further obtains, from the message distribution server, multicast addresses assigned to neighboring tiles of the current-location tile and information representing the neighboring tiles; and

even if the latest geographical location is outside the current-location tile, if the new current- location tile corresponding to the latest geographical location is one of the neighboring tiles, the obtainin unit does not send the latest geographical location to the message distribution server.

18. The mobile terminal according to any one of Claims 14-17, wherein:

the obtaining unit periodically obtains the multicast address assigned to the current-location til by periodically sending the geographical location to the message distribution server; and

if the newly obtained multicast address differs from the previously obtained multicast address, the joining unit joins a multicast group corresponding to the newly obtained multicast address.

19. The mobile terminal according to Claim 12, further comprising an information receiving unit (605) configured to receive information representing the plurality of tiles and information representing corresponding multicast addresses from the message distribution server,

wherein the obtaining unit obtains the multicast address assigned to the current-location tile based on said information representing the plurality of tiles and said information representing corresponding multicast addresses.

20. The mobile terminal according to any one of Claims 12-19, wherein:

if the obtaining unit obtains two or more multicast addresses assigned to the current-location tile, the joining unit joins one of a multicast group corresponding to one of said two or more multicast addresses .

21. The mobile terminal according to any one of

Claims 12-20, wherein:

each of the plurality of tiles is further

assigned a multicast source address;

the obtaining unit further obtains a multicast source address assigned to the current-location tile; and

the joining unit joins a multicast group

corresponding to a pair of the obtained multicast address and the obtained multicast source address.

22. A method for controlling a message distribution server (101) for distributing a message to mobile terminals (104) that are located in a destination area of a predetermined geographical area, wherein the message distribution server can access a tile database (102) storing a plurality of tiles obtained by dividing the predetermined geographical area and each tile is assigned a multicast address, the method comprising: a message receiving step (S209) of receiving the message and the destination area;

an identifying step (S210) of identifying, in the tile database, destination tiles for the message, the destination tiles at least partly overlapping the destination area;

an obtaining step (S211) of obtaining multicast addresses assigned to the destination tiles; and a multicasting step (S212) of multicasting the message to each of the obtained multicast addresses.

23. A method for controlling a mobile terminal (104) for use in a predetermined geographical area divided into a plurality of tiles each of which is assigned a multicast address, comprising:

an obtaining step (S207, S803) of obtaining a multicast address assigned to a current-location tile which is a tile covering a geographical location of the mobile terminal;

a joining step (S208, S706) of joining a

a multicast receiving step (S213) of receiving a multicast message directed to the multicast group which has been joined in the joining step.