Method of mobile ad-hoc networking
Field of the Invention
The present invention relates to a method of mobile ad-hoc networking. 5.
Background
A mobile ad-hoc network (MANET) is an autonomous system of mobile routers connected by wireless links. The routers are free to move and organise themselves so as to provide a flexible network topology. The network can operate 0 independently or be connected to another network. Further information regarding ad-hoc networks may be obtained at the Internet Engineering Task Force (IETF) web-site at http://www.ietf.org/html.charters/manet-charter.html.
Usually, mobile routers operate as mobile terminals providing users with voice and 5 data services. Examples of mobile terminals which, when adapted, can be used in a mobile ad-hoc network include mobile telephone handsets, hand-held communicators, lap-top computers, game consoles, printers, televisions sets, music players and digital cameras.
0 Mobile ad-hoc networks have different uses. For example, a mobile ad-hoc network can be used to establish a so-called "personal" local network for devices held or used by the same user. For instance, the personal network can be used to route video data received by a mobile telephone handset via a lap-top computer to a television set. 5
In another example, a mobile ad-hoc network can be employed as a so-called "face- to-face" local network. If two or more mobile terminal users meet to form a group, then a mobile ad-hoc network is formed through which the users can communicate and/or exchange data. This can be used in meetings and presentations. This type 0 of network can also be used in gaming applications.
A mixed mobile ad-hoc network, which uses a fixed network to connect two or more mobile-ad hoc segments or zones, can operate as a remote area network. This can be used for rescue and emergency service operations.
Mobile ad-hoc networks are versatile not only because their network topologies can dynamically change, but also because they can be used to deliver different services.
The present invention seeks to establish what services may be provided to users within a group connected by a mobile ad-hoc network and to provide those services.
Summary of the Invention
According to a first aspect of the present invention there is provided a method of mobile ad-hoc networking comprising defining an addressable group of mobile terminals in dependence upon one or more attributes common to users of said mobile terminals.
This has the advantage that users are provided with service which is customised to them.
The method may comprise a service organiser transmitting an advertisement for a service and/ or a mobile terminal transmitting a request to a service organiser to be provided with a service.
The method may comprise a service organiser transmitting a request to a mobile terminal to send profile information and/or a mobile terminal transmitting profile information to a service organiser. The method may comprise the service organiser determining a service for providing to said and other mobile terminals in dependence upon one or more attributes included in profile information of said and said other mobile terminals. The method may comprise registering said mobile terminal as a member of a service group. The method may comprise the service organiser transmitting a certificate including service information to said mobile
terminal. The service information may include a service group address. The service organiser may be a terminal for providing said service.
Transmitting a certificate has the advantage that the user can use the service at later _ \ time or different place.
The method may comprise a mobile terminal which is provided with service information transmitting a request to a terminal for providing a service to become a member a service group, said terminal registering said mobile terminal as a member 10 of said service group and may further comprise said terminal transmitting to said mobile terminal information regarding said group, which may include a group address, such as an Internet Protocol address. The Internet Protocol address may be for multicasting data to mobile terminals including said mobile terminal.
15 The method may further comprise said mobile terminal searching for said terminal prior to transmitting said request to become a member said service group.
The method may comprise a terminal transmitting service data to said addressable group of mobile terminals and one or more of said mobile terminals transmitting 20 data to said terminal providing service data. This has the advantage that service is provided to those participating mobile terminals. The transmitting of the data between a mobile terminal and said terminal may comprise routing said data via other mobile terminal.
25 The method may further comprise defining an addressable sub-group of mobile terminals in dependence upon one or more further attributes common to users of said mobile terminals. This has the advantage that users are provided with a service which is further customised to match their needs.
30 The method may comprise a terminal which is providing a service to said addressable group of mobile terminals transmitting to one or more mobile terminals within said addressable group information relating to a sub-group. This allows users to promote or provide new services. The information relating to said sub-
. . . . _
- 4 -
group may include a sub-group address and may include an Internet Protocol address.
The method may comprise transmitting to said one or more mobile terminals in said sub-group information regarding a further service.
The method may comprise a mobile terminal within said addressable group of mobile terminals transmitting to said other mobile terminals an invitation to form a sub-group, one or more of said other mobile terminals transmitting an acceptance to said mobile terminal and said mobile terminal transmitting to a terminal providing service to said group a request for a sub-group address. The sub-group may comprise an Internet Protocol address. The method may comprise said terminal providing service to said group transmitting a sub-group address to said mobile terminal.
The method may comprise transmitting to said one or more mobile terminals information relating to said sub-group. The information relating to said sub-group may comprise a sub-group address and may include an Internet Protocol address.
The method may comprise transmitting to said one or more mobile terminals in said sub-group information regarding a further service.
The method may comprise a terminal which is providing a service to said addressable group of mobile terminals transmitting a request for a mobile terminal to report its state, said mobile terminal transmitting a response to said request to said terminal. The transmitting of said request for a mobile terminal to report its state may comprise unicasting said request or multicasting said request to said mobile terminals including said mobile terminal.
The method may comprise a terminal which is providing a service to said addressable group of mobile terminals detecting a moving mobile terminal. The method may comprise terminal transmitting a request to said addressable group of mobile terminals to search for said moving mobile terminal and may further
comprise said terminal transmitting said request to other mobile terminals which route information for said addressable group of mobile terminals. The method may comprise one of said mobile terminals transmitting a reply to said terminal regarding said moving mobile terminal. The method may comprise said terminal ttaj^mitting a request to said replying mobile terminal for said moving mobile terminal to report its state, said replying terminal transmitting said request to said moving mobile terminal and said moving mobile terminal reporting its state to said terminal.
According to a second aspect of the present invention there is provided a computer program for performing the method.
According to a third aspect of the present invention there is provided a terminal configured to define an addressable group of mobile terminals in an ad-hoc network in dependence upon one or more attributes common to users of said mobile terminals.
According to a fourth aspect of the present invention there is provided a mobile terminal for use in an ad-hoc network, said mobile terminal configured to provide profile information comprising attributes and to be provided with an address for defining a group of mobile terminals whose users have one or more attributes in common.
Brief Description of the Drawings Embodiments of the present invention will now be described, by way of example, with reference to the accompanying drawings in which:-
Figure is a schematic diagram of a mobile ad-hoc network;
Figure lb is a schematic diagram of a service group;
Figure 2a is a schematic diagram of another mobile ad-hoc network; Figure 2b is a schematic diagram of a service group;
Figure 3 is a process flow diagram showing formation and use of a service group and subgroups;
Figure 4a illustrates a process by which a service group is defined "on-the-spot";
Figure 4b illustrates a process by which a service group is predefined; Figure 5 illustrates a process by which a service subgroup is formed and used; Figure 6 illustrates a profile table;
Figure 7 is a schematic block diagram of a mobile terminal; _5_ Figure 8 is a functional layer diagram of the mobile terminal shown in Figure 7;
Figure 9 shows routing of service data through a mediator;
Figure 10 illustrates a process by which a service group is predefined;
Figure 11 shows apparatus for remote registration of a mobile terminal;
Figure 12 illustrates a process by which a mobile terminal remotely registers for a 10 service;
Figure 13 illustrates a process by which a service group is created;
Figure 14 shows a process by which a predefined service group is created;
Figure 15 illustrates a process by which information is distributed throughout a service group; 15 Figure 16 shows a process by which a subgroup is created by a hub terminal;
Figure 17 illustrates a process by which a subgroup is created by a mobile terminal;
Figures 18a and 18b illustrates processes by which members of a service group are tracked;
Figures 19a and 19b show a first instance of a mobile ad-hoc network before and 20 after a mobile terminal has moved;
Figure 20a and 20b show a second instance of a mobile ad-hoc network before and after a mobile terminal has moved;
Figure 21 illustrates a process by which an errant mobile terminal is located;
Figure 22 is a process flow showing operation of a hub terminal while seeking an 25 errant mobile terminal;
Figure 23 is a process flow showing operation of a mobile terminal while seeking an errant mobile terminal;
Figure 24a show a mobile terminal wishing to join a service group;
Figure 24b illustrates a process by which a mobile terminal joins a service group; 30 Figure 25a show a mobile terminal wishing to leave a service group;
Figure 25b illustrates a process by which a mobile terminal leaves a service group;
Figure 26 shows a plurality of mobile terminals used in a tour guide system;
Figure 27 is a schematic diagram of hub terminal memory used for service control;
Figure 28 is a schematic diagram of mobile terminal memory used for service control;
Figure 29 shows overlapping coverage of mobile terminals; Figure 30 is a schematic diagram of a member database; JFigure 31 is a schematic diagram of a material database;
Figure 32 is a schematic diagram of a tour database; ~
Figure 33 shows a mobile terminal applying and registering for a tour on-site;
Figure 34 shows a mobile terminal applying and registering for a tour on-site via a registration desk; Figure 35a shows a participant applying for a tour off-site;
Figure 35b shows the participant of Figure 35a registering for the tour;
Figure 36a is a schematic diagram of a tour ad-hoc mobile network;
Figure 36b is a schematic diagram of a tour group;
Figure 37a and 37b show a process by which a tour schedule is distributed; Figure 38a and 38b show a process by which a mobile terminal tracks its neighbours;
Figures 39a to 39d show local network configurations;
Figure 40 shows a process by which a tour conductor performs a roll call;
Figure 41 shows a process by which a tour conductor can delegate responsibiUty to a participant;
Figure 42a and 42b show a process by which data is distributed by a tour conductor;
Figure 43a and Figure 43b show a process by which data is distributed by a tour conductor on demand;
Figure 44a and 44b show a process by which data is distributed by an autonomous source;
Figure 45a and 45b show a process by which data is distributed by an autonomous source on-demand; and
Figure 46a and 46b show a process by which a further subgroup is created by a third party.
Detailed Description of the Invention
General System Mobile ad-hoc network 1
Referring to Figure la, a mobile ad-hoc network 1 according to the present invention comprises a pluraUty of mobile terminals MT1, MT2, MT3, MT4, MT5, MT6, such as hand-held communicators, connected by a pluraUty of wireless Unks 2. Mobile terminal MT6, herein referred to a hub terminal 3, provides'aYefvice fcTthe ~ other mobile terminals MT1, MT2, MT3, MT3, MT4 using mobile terminal MT5, herein referred to as a mediator 4, to route data to mobile terminal MT3. The hub terminal 3 supplies mobile terminals MT1, MT2, MT3, MT4 with service data 5. Thus, although mobile terminal MT5 routes service data 5 from the hub terminal 3 to mobile terminal MT3, mobile terminal MT5 is not itself provided with service.-
Referring to Figure lb, mobile terminals MT1, MT2, MT3, MT4 form a service group 6 which is assigned a service group identity, Service_ID. The service group 6 is defined by a profile which is common to the mobile terminals MT1, MT2, MT3, MT4. Briefly stated, a profile comprises one or more attributes associated with the user of a mobile terminal and may include personal details, preferences and tastes. At a logical level, the mobile terminals MT1, MT2, MT3, MT4 are Unked to one another by connections 7 independent of the physical arrangement of the network 1. Thus, although the mobile terminal MT5 is part of the physical network 1, it is not part of the service group 6.
Within the service group 6, mobile terminals MT1, MT4 form a service subgroup 8 defined by another profile which is common to mobile terminals MT , MT4, but not mobile terminals MT2, MT3. The profiles and the manner in which groups and subgroups are defined will be explained in more detail later.
Referring to Figures 2a and 2b, the mobile terminals MT1, MT2, MT3, MT4, MT5, MT6 can form another mobile ad-hoc network 9 connected by wireless Unks 2 and an existing network 10, such as a wired network. This is an example of a mixed mobile ad-hoc network. Although the other network 9 is configured differently physicaUy from the network 1 , the service group 6 is the same.
Group 6 and subgroup S formation
Referring to Figure 3, a general process by which the service group 6 and subgroups
8 are formed and used is shown.
Mobile terminals MTl, MT2, MT3, MT4, MT5 provide the hub terminal 3 (Figure la) with profiles which are used to determine the service group 6 (step Al). Generally, there are two ways in which this can be achieved. Firstly, referring to Figure 4a, potential members of the service group 6 (Figure la) assemble (step Al.1.1) and the based upon profiles provided there and then, the service group 6 is defined (step Al.1.2). This is known as "on-the-spot" service group definition.
Secondly, referring to Figure 4b, potential members supply their profiles before they rendezvous (step Al.2.1). The members thereafter assemble (step Al.2.2). This is known as "predefined" service group definition. The service group may be defined using a combination of the on-the-spot and predefined methods. Both methods of service group definition will be described in more detail later.
Once the service group 6 has been defined, it is created and information about the service group 6 is shared throughout the service group 6 (steps A2 & A3). If a service subgroup 8 is defined, then this is created and managed accordingly (step A4). The service group 6 is provided with service (step A5). Once the service has been deUvered or if the service group 6 disbands, then the service group 6 is terminated (step A6).
Referring to Figure 5, the service subgroup 8 is handled in a similar way to the service group 6. The service subgroup 8 is created and information about it distributed throughout the service subgroup 8 (step A4.1 & A4.2). The subgroup 8 is provided with another service individual to the subgroup 8 (step A4.3).
Referring to Figure 6, a profile table 11 for users a, b, c, d, m of the mobile terminals MTl, MT2, MT3, MT4, MT5 is shown. The profile table 11 includes the names 12 of the users a, b, c, d, m and their attributes 13. Attributes 13 can include personal details, tastes and preferences and can be divided into broad two categories, namely those which are predefined 14 and those that are defined on-the-
spot 15. For example, the predefined attributes 14 include nationaUty 16 and sex 17 of the user. The on-the-spot attributes 15 include a preference 18 for a type of food and another preference 19 for a tour location.
_ __ _ he profile table 11 shows that users a, b, c, d wish to go on a tour of Tokyo. This common attribute defines the service group 6 (Figure la). The service to be ~ provided is a guided tour and can include distribution of information to the members of the group 6 and a channel for allowing members of the group 6 to ask a tour guide questions. Within this service group 6, users a, d are Japanese. This
10 attribute defines the subgroup 8 (Figure la). Accordingly, the tour information is given in Japanese.
Each mobile terminal MTl, MT2, MT3, MT4, MT5 holds or provides attributes 13 for a respective user a, b, c, d, m. For example, a mobile terminal stores the
15 predefined attributes 14 and prompts a user to supply on-the-spot attributes 15 on demand. Thus, the profile table 11 is usually distributed between the mobile terminals MTl, MT2, MT3, MT4, MT5 and not held in any one place. However, the profile table 11 may be compiled by the hub terminal 3 when members of the group assemble. The process by which this occurs will be described in more detail later.
20
Mobile Terminals MT1 , MTl, MT3, MT4, MTS, MT6
The mobile terminals MTl, MT2, MT3, MT4, MT5, MT6 wiU now be described.
Referring to Figure 7, the mobile terminals MTl, MT2, MT3, MT4, MT5, MT6 each 25 include a radio frequency (r.f.) unit 20 for receiving and generating radio signals to and from an antenna 21 and for performing coding and decoding of the received and transmitted data. The radio frequency unit 20 may be a Bluetooth™ transceiver. The radio frequency unit 20 may comprise two transceivers, for example, one Bluetooth and another GSM. The mobile terminals MTl, MT2, MT3, 30 MT4, MT5 also include a central processing unit 22, a user input 23, such as a keypad, and a display 24. The mobile terminals MTl, MT2, MT3, MT4, MT5 further include memory 25. The memory 25 is divided and apportioned to different
tasks including communication control 26, group control 27 and service control 28, and also includes a database 29. The database 29 is used to store a user's profile.
Referring to Figure 8, a functional layer structure 30 for the mobile terminals MTl, MT2, MT3, MT4, MT5 is shown. The layer structure 30 comprises a physical layer
31, a data link layer 32, an IP routing layer 33, a session layer 34 and an appUcatϊoh- layer 35. The radio frequency unit 20 is responsible for estabUshment and management of the physical layer 31. Communication control 26 is responsible for the link and IP layers 32 and 33. Group control 27 is responsible for the session layer 34. FinaUy, service control 28 is responsible for the appUcation layer 35.
The establishment of the wireless Unks 2 (Figure la) between the mobile terminals MTl, MT2, MT3, MT4, MT5, MT6 is controlled by the radio frequency unit 20 in the physical layer 31. Once a wireless Unk 2 has been estabhshed, the routing of data packets which comprise service data 5 is managed by communication control 26. As described earlier, the mobile terminals MTl, MT2, MT3, MT4 forming the service group 6 are assigned the service group identity, Service_ID. The service group identity includes an IP address. This aUows the mediator 4 to route service data 5 on behalf of the service group 6.
Referring to Figure 9, the flow of service data 5 from the hub terminal 3 to the mobile terminal MT4 via the mediator 4 is shown. The service data 5 is used in the appUcation layer 35. Thus, the service data 5 received by the mediator 4 is not sent up to the appUcation layer 35 but handled by the IP layer 33 which routes it to the mobile terminal MT4.
Each step in the general process shown in Figure 3 will now be described in more detail:
Service Group Definition (Step A 1)
As explained earUer, there are two ways in which the service group 6 can be defined, namely on-the-spot when the members assemble and predefined.
Referring to Figure. 10, a process by which the service group 6 is defined on-the- spot is shown. The mobile terminals MTl, MT2, MT3, MT4, MT5 assemble at some location, such as hotel lobby (step Bl). A service provider, such as a tour company, is also present with a mobile terminal MT6. The mobile terminal MT 6, acting as the hub terminal 3, transmits an advertisement for its service, inviting users to join (step B2). In this case, the advertisement is for a tour f Tokyo*/ The advertisement may be displayed or announced at each mobile terminal MTl, MT2, MT3, MT4, MT5. In response to the advertisement, mobile terminal MTl sends a request to subscribe to the service (step B3). The hub terminal 3 checks the status of the service, for example by ensuring that the mobile terminal MTl can be accommodated. The hub terminal 3 thereafter asks the mobile terminal MTl to send a profile (step B5). The profile is retrieved from the database 29 (Figure 7) and sent to the hub terminal 3 (step B6). At the hub terminal 3, the mobile terminal MTl is registered and its profile added to the profile table 11 held in memory 29 (Figure 7) (step B7). A certificate including service information is transmitted to the mobile terminal MTl (step B8) where it is stored (step B9).
The service information includes the service group identity, service_ID. In this example the service group identity is a tour_ID. The service information for this example may also include a schedule, an IP address for a tour conductor, a ticket number and other information relating to the tour.
Thus, it is the preference to tour Tokyo that is used to define the service group 6. In this scenario, this attribute is defined by responding to the advertisement, in other words the attribute is defined on-the-spot. In this case, the service group 6 is defined on-the-spot at the point of service with other members of the group 6. The service group 6 is ready to be created and the service deUvered and this will be described in more detail later.
Referring to Figures 11 and 12, a process by which the service group 6 is predefined is shown. The user of mobile terminal MT 1 wishes to procure a service. In this case, the user wishes to go on a tour of Tokyo. The user sends a request to the service organiser, such as a travel agent or tour guide operator, to be suppUed with a
service (step CI). The user employs mobile terminal MTl to contact a device 36, such as a personal computer, operated by the service provider over a network 37, such as a mobile ad-hoc network or an existing mobile or fixed network. The service organiser checks the status of the service, for example by ensuring that the _ mobile terminal MTl can be accommodated (step C2). The service organiser thereafter asks the mobile terminal MTl to send a profile (step C3). The profiler is retrieved from the database 29 (Figure 7) and sent to the service organiser (step C4). At the service organiser, the mobile terminal MTl is registered and its profile added to the profile table 11 held in a database (not shown) (step C5). A certificate including service information is transmitted to the mobile terminal MTl (step C6) where it is stored (step C7). Also at step C5, the profile is forwarded to the hub terminal 3 via a network 38.
As in the on-the-spot definition, the service information includes the service group identity, service_ID.
Thus, the preference to go on a Tokyo tour is defined before the members of the group 6 have assembled. In this case, when the group is being defined, members of the group are located elsewhere from the point of service. However, when the group 6 assembles, the hub terminal 3 possesses profiles of the members, particularly the Tokyo tour attribute, and so is able to create the service group 6 and deUver the service.
Creation of Group (Step A2) The method in which the service group 6 is created depends on whether it is defined on-the-spot or is predefined.
Referring to Figure 13, a process by which the service group is created following on-the-spot definition is shown. Mobile terminal MTl sends a request to the hub terminal 3 to become a member of the group (step Dl). The request can be sent immediately once mobile terminal MTl has received the certificate (step B8) or at some predefined time later. The hub terminal 3 registers the mobile terminal MTl with the group (step D2). Registration involves confirming that the mobile terminal
MT1 has appears on the service spot and includes storing information comprised in the certificate, such as a member_ID, an IP address of the mobile terminal MTl, its profile and the Uke. The hub terminal 3 thereafter sends the mobile terminal MTl group information (step D3). The group information includes a group_ID. The group_ID is an IP address which aUows service data 6 to be routed to mobile terminals MTl, MT2, MT3, MT4 within the service group 6. The mobile terminal MTl stores this information in memory 25 related to group control 27 (step D4) and confirms receipt (step D5). Step Dl to D5 are repeated for each mobile terminal MTl, MT2, MT3, MT4. Once completed, the hub terminal 3 multicasts a final confirmation to the mobile terminal MTl, MT2, MT3, MT4 in the group 6 that the members have joined (step D6). The mobile terminal MTl, MT2, MT3, MT4 within the service group 6 reply with an acknowledgement (step D7).
Referring to Figure 14, a process by which a predefined service group 6 is created is shown. Mobile terminal MTl arrives at a predefined location. The mobile terminal MTl thereafter searches for the hub terminal 3 (step El). It will be appreciated that the mobile terminal MTl may perform different search strategies. It can search from the moment it receives the service certificate (step C7; Figure 12). It can search periodically. It can search whenever it or a new member joins an ad hoc network. The mobile terminal MTl can search when instructed by the user.
Once the mobile terminal MT 1 has located the hub terminal 3, it sends a request to the hub terminal 3 to become a member of the group (step E2). The hub terminal 3 registers the mobile terminal MTl with the group (step E3). The hub terminal 3 thereafter sends the mobile terminal MTl group information (step E4). Similar to group defined on-the-spot, the group information includes a group_ID. The mobile terminal MTl stores this information in memory 25 related to group control 27 (step E5) and confirms receipt (step E6). Step El to E6 are repeated for each mobile terminal MTl, MT2, MT3, MT4. Once completed, the hub terminal 3 multicasts a final confirmation to the mobile terminal MTl, MT2, MT3, MT4 in the group 6 that the members have joined (step E7). The mobile terminal MTl, MT2, MT3, MT4 within the service group 6 reply with an acknowledgement (step E8).
S baring Group Information (Step Λ3)
The service group 6 is now created. Each mobile terminal MTl, MT2, MT3, MT4 within the group 6 possesses an group IP address. This aUows information to be distributed throughout the group 6 using multicasting. Different multicasting protocols may be used such as multicast ad-hoc on-demand distance vector
(MAODV) routing, differential destination multicasting (DDM) and/o£~on-delhand multicast routing (ODMR). Further information regarding multicasting may be found at the IETF web-site supra and in our EP appUcation 00306578.6 filed on 2 August 2000.
Referring to Figure 15, a process by which group information can be shared throughout the service group 6 is shown. The hub terminal 3 multicasts information in readiness for the service to mobile terminals MTl, MT2, MT3, MT4 (step FI). The information may include membership information and software related to the service. In the case of a tour, the information may include a tour schedule, discount tickets for shops and restaurants. The mobile terminals MTl, MT2, MT3, MT4 acknowledge receipt of the information (step F2).
Subgroups (Step 4) Once a group 6 has been estabUshed, the hub terminal 3 or any mobile terminal
MTl, MT2, MT3, MT4 is able to determine or seek to determine whether subgroups exist within the service group 6 and provide an additional service accordingly.
Referring to Figure 16, a process by which a subgroup is created and subgroup information is shared is shown. The hub terminal 3 determines that a subgroup exists within the group 6. In this case, mobile terminals MTl, MT4 defined as members of the subgroup 8 (Figure la). The subgroup 8 relates to users who are Japanese. The hub terminal 3 unicasts information relating to the subgroup to the mobile terminals MTl, MT4 (step Gl). Different unicasting protocols may be used such as ad-hoc on-demand distance vector (AODV) routing and/or optimised Unk state routing protocol. The information includes a subgroup_ID, subgroup service details and optionaUy other information relating to the subgroup. The subgroup_ D is an IP address. The mobile terminals MTl, MT4 return an
acknowledgement (step G2). The hub terminal 3 thereafter multicasts information for setting up a further service (step G3). For example, the information may include a Japanese font. The mobile terminals MTl, MT4 acknowledge receipt (step G4).
Referring to Figure 17, a process by which another subgroup is created and subgroup information is shared is shown. In this case, however, the other subgroup creation is initiated by the mobile terminal MTl . The other subgroup relates to food preferences 18 (Figure 6). The mobile terminal MTl multicasts an advertisement to mobile terminals MT2, MT3, MT4 (step HI). Each mobile terminal MT2, MT3, MT4 sends a reply accepting or decUning (step H2). In this case, mobile terminals MT2, MT4 wish to join the other subgroup, while mobile terminal MT3 does not. Mobile terminal MTl sends a request to the hub terminal 3 for a subgroup identity (step H3). The hub terminal 3 allocates a subgroup identity, subgroup _ID2 (step H4). Mobile terminal MTl unicasts the subgroup identity to mobile terminals MT2, MT3 (step H5) which in turn acknowledge receipt (step H6). Mobile terminal MTl multicasts information for setting up the subgroup usirig"fhe subgroup identity, subgroup_ID2 (step H6). The other members of the subgroup send an acknowledgement (step H7).
It will be appreciated that there can be a pluraUty of subgroups within a group, which may or may not overlap. Moreover, subgroups may be formed within subgroups. In each case, subgroups are addressable by a subgroup identity which allows data to sent to members a particular subgroup.
Group Management (Step A5)
Once the service group 6 has been created, then service can be delivered to mobile terminals MTl, MT2, MT3, MT4. To aUow the service to be deUvered, the service group 6 is managed. Management of the service group includes tracking group members, maintaining the membership of the group following a change in network topology and overseeing joining of new members and leaving of existing members.
-Tracking service group members-
Referring to Figure 18a, a first process by which members of the group 6 are tracked is shown. The terminal hub 3 requests that mobile terminal MTl reports its state (step II). Mobile terminal MTl sends a response (step 12). State information may include the identity of the mobile terminal, the location of the mobile terminal and the identity of any neighbouring mobile terminals. The hub terminal 3 waits a predetermined period, Tm, before sending a request to mobile terminalTMT2 (step 13). In reply, mobile terminal MT2 sends a response (step 14). The request- response process is repeated for mobile terminals MT3, MT4 (step 15, 16, 17 18).
Referring to Figure 18b, a second process by which members of the group 6 can be tracked is shown. The terminal hub 3 multicasts a request that mobile terminals MTl, MT2, MT3, MT4 reports their respective states (step 19). Each that mobile terminals MTl, MT2, MT3, MT4 sends a response (step 110). The hub terminal 3 waits a predetermined period, Tn, before multicasting another request (step 19').
-Maintaining service group membership- Referring to Figure 19a, the mobile ad-hoc network 1 includes further mobile terminals MT7, MT8. Mobile terminals MT7, MT8 are mediators 39, 40 and are not included in the service group 6. Mobile terminals MTl, MT2, MT3, MT4 receive service data 5 through Unk connections 2. Mobile terminal MT4 receives service data by a route 41 via mobile terminal MT2.
Referring to Figure 19b, mobile terminal MT4 moves from a first position 42 to a second position 43. The Unk connection 2 between mobile terminals MT2, MT4 is broken and so service data can no longer be sent via route 41. Instead a new route 44 is found so that service data is sent via mobile terminals MT2, MT7, MT8.
Thus, although the network topology has changed, the service group 6 remains intact.
In the case described, the new route 44 is found using at least one mobile terminal as a mediator. However, an existing network may be used alternatively or additionaUy.
Referring to Figure 20a, the mobile ad-hoc network 1 includes mobile terminal MT7 and an existing network 45. The existing network 45 can be a fixed or mobile network. As in the previous case mobile terminal MT7 is a mediators 39 and thus, is not included in the service group 6. Mobile terminals MTl, MT2, MT3, MT4 receive service data 5 through Unk connections 2. Mobile terminal MT4 receives service data by a route 41 via mobile terminal MT2.
Referring to Figure 20b, mobile terminal MT4 moves from the first position 42 to a third position 46. The Unk connection 2 between mobile terminals MT2, MT4 is broken and so service data 5 can no longer be sent via route 41. Instead a new route 47 is found so that service data is sent via mobile terminal MTl and the existing network 46.
A process by which mobile terminal MT4 is kept within the service group 6 will now be described with reference to Figures 19a and 19b.
The hub terminal 3 tracks the mobile terminals MTl, MT2, MT3, MT4 according to the process shown in Figure 18. The mobile terminal MT4 moves as shown in Figure 19b. Because the Unk connection 2 between mobile terminals MT2, MT4 is broken, no response is received from mobile terminal MT4. As a result, the hub terminal 3 sets about searching for mobile terminal MT4.
Referring to Figure 21, a search process is shown. The hub terminal 3 broadcasts a request to aU mobile terminals MTl, MT2, MT3, MT5, MT6, MT7, MT8 to search for mobile terminal MT4 (step Jl). Mobile terminal MT8 estabUshes contact with mobile terminal MT4. Thus, mobile terminal MT8 reports to the hub terminal 3 that mobile terminal MT8 is nearby (step J2). The hub terminal 3 transmits a request for mobile terminal MT4 to report this state via mobile terminal MT8 (steps J3 & J4). The mobile terminal MT4 responds by identifying its location (steps J5 & J6).
In this way, the hub terminal 3 keeps track of the location of mobile terminal MT4. This aUows service data to be directed to mobile terminal MT4.
Referring to Figure 22, operation of the hub terminal 3 during this process is shown. The hub terminal 3 detects that mobile terminal MT4 has moved (step Kl) and broadcasts a search (step K2). This is performed using IP routing protocol. "If the hub terminal 3 finds the errant mobile terminal MT4 (step K3), then other mobile terminals MT help establish a route to mobile terminal MT4. This is performed using IP routing protocol. The terminal hub 3 requests that mobile terminal MT4 report its state (step K4). Provided this is successful, service is resumed (step K5). If no response is received, then the hub terminal 3 checks the number of times it has transmitted the search request (step K6). If the number of the tries exceeds a threshold number, say ten times, then the service provider is notified at the appUcation layer (step K7). If the threshold is not exceeded then another search request is broadcast (step K2).
Referring to Figure 23, operation of moving mobile terminal MT4 is shown. Mobile terminal MT4 moves and in so doing becomes detached from the network 1 (step LI). Detachment is detected in the IP layer 38. Mobile terminal MT4 searches for the nearest mobile terminal. If it finds a mobile terminal (step L2), in this case mobile terminal MT 8, the mobile terminal MT4 determines whether the hub terminal 3 is accessible (step L4). If it can access the hub terminal 3, it does so (step L5). It then transmits information regarding its state including service group identity, group information and profile (step L6). If the hub terminal 3 is authenticated (step L7), then service is restarted (step L8), otherwise the mobile terminal MT4 leaves the service group (step L9). If no mobile terminal is detected at step L2, mobile terminal MT4 checks how many attempts it has made to find a mobile terminal (step L9). If a threshold is exceeded, then it notifies the user (step L10), otherwise it tries again. In a similar way, if the mobile terminal MT4 unsuccessfuUy accesses the hub terminal 3, it checks how many attempts it has made (step LI 2) and, if a threshold number of attempts is exceeded, then it notifies the user (step L12), otherwise it tries again.
-Joining the service group- Referring to Figure 24a, a mobile terminal MT9 wishes to join the service group 6.
Referring to Figure 24b, a process by which the mobile terminal MT9 joins the service group 6 is shown. Mobile terminal MT9 sends a request to the hub terminal
3 to join a service group it controls (step Ml).. In this case, mobile terminal MT9 specifies the service group 6 it wishes to join. The hub terminal 3 sends a query whether the mobile terminal MT9 possesses a certificate of service (step M2). Mobile terminal MT9 checks whether it has such a certificate (step M3). If it does not, it forwards its profile to the hub terminal 3 (step M4). The hub terminal 3 registers the profile (step M5) and issues a service certificate (step M6). Mobile terminal MT9 stores the certificate (step M7). Once in possession of a service certificate, the mobile terminal MT9 sends the hub terminal 3 the certificate with a request to be registered with the service group 6 (step M8). The hub terminal 3 vaUdates the certificate (step M9) and if successful registers mobile terminal MT9 with the group (step M10). The hub terminal 3 thereafter sends mobile terminal MT9 information relating to the service group 6 (step Mil). Mobile terminal MT9 stores the group information (step M12) and confirms receipt (step M13).
Mobile terminal MT9 is now a member of the service group 6 and can receive service data 5 (Figure la) in the same way as mobile terminals MTl, MT2, MT3, MT4.
-Leaving the service group- Referring to Figure 25a, mobile terminal MT9 now wishes to leave the service group 6.
Referring to Figure 25b, a process by which the mobile terminal MT9 joins the service group 6 is shown. Mobile terminal MT9 sends a request to the hub terminal 3 to leave the service group 6 (step Nl). The hub terminal 3 sends a query whether the mobile terminal MT9 intends to leave temporarily (step N2). If mobile terminal MT9 does not intend to leave temporarily (step N3) it informs the hub terminal 3 that it wishes service to be discontinued (step N4). The hub terminal 3 removes
mobile terminal MT9 from the register of group members and removes the profile from its database (step N5). The hub terminal 3 sends a message to mobile terminal MT 9 that it accepts it request to leave the group (step N6).
If, aj: step N3, mobile terminal MT9 intends only to leave the group temporarily, then it notifies the hub terminal of this fact (step N7). The hub terminal 3 removes mobile terminal MT9 from the register of group members (step N8). The hub terminal 3 sends a message to mobile terminal MT 9 that it accepts it request to temporarily leave the group (step N9).
Tour Guide System
The general system described earUer can be used to deUver a tour guide service, as will now be described in more detail:
Mobile terminals MT1 , MT2, MT3, MT4, MT5, MT6
Referring to Figure 26, mobile terminals MTl, MT2, MT3, MT4, MT5, MT6 are personal communicators. The user input 23 (Figure 7) includes a keypad 231 and a microphone 232. The user output 24 includes a display 24a and a speaker 242.
The hub terminal 3 is held by a tour conductor. The other mobile terminals MTl, MT2, MT3, MT4 are held by participants.
Referring to Figure 27, memory 25 included in the hub terminal 3 is aUocated to service control 28. Service control 28 includes a master tour guide program 48, a member database 49, a material database 50 and a schedule database 51. The master tour guide program 48 is used by the tour conductor to monitor and organise participants and send tour information.
Referring to Figure 28, memory 25 included in mobile terminals MTl, MT2, MT3, MT4 is allocated to service control 28. Service control 28 includes a slave tour guide program 52 and a tour ticket 53 which includes a tour identity 54, user identity 55 and a user profile 56. The slave tour guide program 52 is used by the participant to access tour information.
Referring to Figure 29, mobile terminal MT5 is used as a mediator to forward service data 5 from mobile terminal MT6 (the hub terminal 3) to mobile terminal MT4. To achieve this, mobile terminals MT4, MT5, MT6 are within wireless communication range. Each mobile terminal MTl, MT2, MT3, MT4, MT5, MT6 provides wireless coverage in a cell of radius 57. TypicaUy, cell radius 57 is 10 to 100m.
-Hub terminal 3- Referring to Figure 30, the member database 49 is shown in more detail. The member database 49 holds entries for each group member. Each group member is assigned a user identity 58 and each entry includes a member name 59, language 60, sex 61 and sub-group 62.
Referring to Figure 31, the material database 50 is shown in more detail. The material database 50 holds information relating several tours. Each tour is assigned a tour identity 63 and each entry includes "the tour name 64 and corresponding tour material 65. The tour material 65 may include images 66, text 67 and audio files 68. For example, the images 66 may be stiU or video chps of a location and can be stored as JPEG, or MPEG files. The text 67 may be provided in a language such as EngUsh, French or Japanese and store in a TXT or DOC format. The audio material 68 can include voice commentary and can be stored as a AVI or WAV file. It wiU be appreciated that other file formats can be used.
The tour material 65 can be Unks to material available on the world-wide web
(WWW). For example, a sample of tour material 65j for Lake Leman comprises metadata:
<?xml version="1.0" encloding="UTF-8"?> <material id="l"iπdex="Lake anan">
<picture> tt : //server . com/pic/ leman. jpg</picture> <English> ttp .• //server . cran/voice/leman-eng . avi</Englis > < Japanese>htt : //server . ccπyVoice/leman-eng . avi</ apanese > <Erench http://server.ccm/voice/lernan-eng.avi</ French >
</material>
Referring to Figure 32, the schedule database 51 is shown in more detail. The schedule database 51 holds itinerary information comprising several events. Each event is assigned an event identity 69 and each entry includes a start time 70, a finish time 71 and a description 72".""" - - - - - .__
Signing up for a tour
A user wishes to tour Tokyo which starts in a hotel lobby. GeneraUy, there are two ways in which they can apply and register for the tour. Firstly, the user can apply and register on-site. Secondly, the user can apply off-site and register later when they come for the tour.
-On-site appUcation and registration- Referring to Figures 10 and 33, the user possesses mobile terminal MTl . In response to an advertisement either displayed in the hotel lobby or broadcast electronically and received by mobile terminal MTl, the user sends a request directly to the tour conductor MT6 to participate in the tour (step B3). If the user can be accommodated and provided any necessary payment is made, the user is registered (steps B4 to B7). Once registration is completed, the user is issued with a certificate with tour information (step B8 & B9). The user is registered with the terminal hub and so immediately becomes a member of the service group.
Referring to Figures 10 and 34, the process described above can be modified so that the user appUes and registers at a registration desk 36 rather than a hub terminal 3. The registration desk 36 includes a personal computer 73, a member database 74 and a transceiver 75 for communicating with mobile terminal MTl. The result the appUcation and registration process is that the user is issued with a certificate, which is sometimes referred to as an "e-ticket". At this stage, however, the tour conductor (hub terminal 3) has not registered mobile terminal MTl, even though it may also be located in the lobby. Thus, to register with the tour conductor and participate in the tour, mobile terminal MTl requests to join the service group 6 as
described with reference to Figures 24a and 24b. Thus, the modified process described above combines aspects of "predefined" and "on-the-spot" definition.
It will be appreciated that in the modified process, the user need not possess mobile terminal MTl prior to making the appUcation. The mobile terminal MT 1 may be loaned to the user.
-Off-site appUcation and on-site registration- Referring to Figures 11, 12 and 35a, off-site, the user employing a mobile terminal MTl or a personal computer 76 contacts the registration desk 36 and appUes to be taken on a tour (step CI). If the user can be accommodated and provided any necessary payment is made, they are registered (steps C2 to C5). The registration desk 36 passes details of the registration to hub terminal 3 (step C5). If the user possesses mobile terminal MTl, then a certificate, referred to hereafter as an "e- ticket", can be issued (step C6 & C7).
Referring to Figure 35b, if the user does "possess mobile terminal MTl, then the"e- ticket is issued and instaUed on mobile terminal MT lwhen the user arrives on-site. The mobile terminal MT 1 may be loaned to the user.
Although this process is used mainly for off-site appUcations, it can be also be used on-site.
The tour group Referring to Figure 36a, hub terminal and mobile terminals MTl, MT2, MT3, MT4 assemble ready for a tour together with mobile terminals MT10, MT11, MTl 2, MTl 3, MTl 4, MTl 5 whose users wish to tour Tokyo. The mobile terminals MTl, MT2, MT3, MT4, MT10, MTU, MTl 2, MTl 3, MTl 4, MTl 5 connect together using wireless Unks 2 to construct a tour mobile ad-hoc network 76.
Referring to Figure 36b, a tour group 77 is created according to the process described with reference to Figures 13 and 14. Each mobile terminal MTl, MT2, MT3, MT4, MT10, MTll, MT12, MT13, MT14, MT15 requests to be registered as a
member of the group (step Dl or E2) and receives and stores group information (steps D2 to D5 or E3 to E6). Once the mobile terminal MTl, MT2, MT3, MT4, MT10, MT11, MT12, MTl 3, MT14, MT15 have been registered, the hub terminal 3 multicasts a final confirmation to the members of the enlarged group 76 (steps D7 & D8 or E7 & E8). Only some of the logical connections 7 are shown in Figure 36b for reasons of clarity.
The hub terminal 3 also creates Japanese, English and French subgroups 78, 79, 80 according to the process described with reference to Figure 16. Each of these subgroups 78, 79, 80 is assigned a tour identifier, namely Tour_ID = 1, 2 and 3 respectively.
Once the tour group 77 has been created, the hub terminal 3 shares information with members of the group 77 according to the process described with reference to Figure 15. The information may include data held in the material database 50 and the schedule database 51.
Other features of the tour group 77, wiU now be described:
-Distributing a schedule- Referring to Figures 37a and 37b, the tour conductor wishes to change the tour schedule bring forward rendezvous from 17:00 to 16:00.
The tour conductor edits the schedule held in the schedule database 51 (step PI) and multicasts the schedule to the tour group 77 (step P2). Mobile terminal MTl 5 receives the schedule and then multicasts it so as to be received by mobile terminal MTU (step P3). In turn, mobile terminal MTU multicasts the schedule. Mobile terminal MTl 5 checks tour_ID so as to verify that the schedule is intended for members of its group 77 or subgroup 79 (step P4). If not, the mobile terminal MTl 5 simply ignores the schedule. Otherwise, the mobile terminal MT5 shows the schedule on its display 2 t (step P5) and sets an alarm (step P6). Each of the mobile terminals MTl, MT2, MT3, MT4, MT10, MTU, MT12, MT13, MT14 foUows this procedure.
-Tracking neighbours-
If participants are aUowed time to do as they please, then there is danger that they might wander away from the tour group. Therefore, it is helpful to monitor the number of neighbouring participants and sound an alarm if this number becomes low.
Referring to Figures 38a and 38b, each mobile terminal MTl, MT2, MT3, MT4, MT10, MTU, MTl 2, MTl 3, MTl 4, MTl 5 searches for others around it within the radius of coverage 57 (step Ql), counts the number of neighbours (step Q2) and displays the number for the user (step Q3).
Referring to also to Figures 39a to 39d, mobile terminals found in locations 81, 82, 83, 84 have zero, one, two and three neighbours respectively. Alarms are sounded if there is only one neighbour.
-RoU caU-
Once a free period has ended or if the tour conductor wants to ask the participants a question, they can conduct a roU call or poU.
Referring to Figure 40, the tour conductor selects a caU or message (step Rl) and multicasts the call to the tour group 77 (step R2) . Mobile terminal MTl 5 receives the call and in turn multicasts it so as to be received by mobile terminal MTl 1 (step R3). In turn, mobile terminal MT11 multicasts the caU. Mobile terminal MTl 5 checks tour_ID so as to verify that the caU is intended for members of its group 77 or subgroup 79 (step R4). If not, the mobile terminal MTl 5 simply ignores the caU. Otherwise, the mobile terminal MTl 5 prompts the user to enter a response (step R5) and which it sends to the hub terminal (step R6). Mobile terminal MT11 also foUows this procedure (step R7 to R9) as do other mobile terminals MTl, MT2, MT3, MT4, MT10, MTl 2, MTl 3, MTl 4. The hub terminal 3 collects the caU responses (step RIO) and counts the number of the responses (step Rll).
-Delegation-
In an emergency situation, the tour conductor may need to delegate responsibiUty for the tour to one of the participants. The foUowing procedure permits this to happen:
Ref erring to Figure 41, the hub terminal 3 sends a request to a participant, in this mobile terminal MTl 5, to take responsibiUty for the tour (step SI). The request can include information for authenticating the hub terminal 3. If mobile terminal MTl 5 accepts (step S2), then the hub terminal 3 delegates responsibiUty and transfers data (step S3). The data includes service control data 28 (Figure 27) such as the master tour guide program 48, the member database 49, the material database 50 and the schedule database 51.
The tour subgroups
-Distribution of information by a tour conductor (Push)- During the tour, the tour conductor distributes information to the participants.
This may include for example tour commentary. The information may be relevant to all the members of the tour group. However, the information may only be relevant to a subgroup. This occurs when, for example the tour commentary is in EngUsh.
Referring to Figure 42a and 42b, the tour conductor searches the material database 50 (Figure 27) held at the hub terminal 3 and selects content that he wishes to distribute (steps Tl & T2). The content, in the form of metadata, is multicast to the EngUsh speaking subgroup 79 (Figure 36b). The content is received at mobile terminal MTl 5 (step T3). Mobile terminal MTl 5, in turn, forwards the content to mobile terminal MTU (step T4) and so on. Mobile terminal MTl 5 checks whether the content is intended for it by checking the subgroup identity, Tour_ID=2 (step T5). If so, the content is output (step T6). For example, this may include outputting content on the display 24j and/or outputting voice content on the speaker 242 or a set of headphones (not shown).
Thus, the content permeates through the group. If an EngUsh-speaking member of the group receives the content, then the content is deUvered. If a non-EngUsh-
speaking member receives the content, then the content is simply forwarded to neighbours. For example, mobile terminal MTl 1 passes on the content without deUvering it.
-Distribution of information by a tour conductor (Pull)-
It is common for participants to ask questions during the tour. For example, if a participant sees a statue, then they may want to know more about the sculptor and their other works.
Referring to Figures 43a and 43b, mobile terminal MTl 5 sends a request for information to the hub terminal 3 (step Ul). The request includes the participant's profile. The tour conductor accesses a remote database 85 via a network 86 using base station 87. For example, the base station 87 can be fixed Bluetooth transceiver. The base station 87 may be comprised in mobile telecommunications network, such as a GSM network.
The tour conductor searches the database 85 (step U2). The participant's profile is used to filter the content (steps U3 & U4). For example, the content may be filtered according to language. The content is then unicast to the participant (step U5). Alternatively, the content may be multicast to members of the same subgroup. The content is output using the mobile terminal MTl 5 (step U6) and, optionally, saved to a database in memory 29 (Figure 7), such as a hard disk (not shown).
-Distribution of information by an autonomous source (Push)- The tour conductor is not the only source of information available. For example, the tour group may visit an art gaUery housing a coUection of works. The gallery may provide information about each work, such as a history of the work, a critical analysis and a biography of the artist. This information may be provided by autonomous sources.
Referring to Figure 44a and 44b, mobile terminals MTl 5, MT11 are found in front of a work of art 87. A base unit 88 transmits information related to the work of art 87 held on a database 89. In this example, the information comprises metadata and
is multicast to mobile terminal MTl 5 together with a subgroup identity, Tour_ID=2 (step VI). Mobile terminal MTl 5 forwards the content to mobile terminal MT11 (step V2). Mobile terminal MTl 5 examines whether the content is meant for it (step V3) and if so outputs the content (step V4). In this case the content comprises commentary on the work of art 87 in EngUsh.
Thus, similar to the process described earlier with reference to Figures 42a and 42b by which information is distributed by a tour conductor, this process aUows subgroups and/or individual participants to be targeted.
Of course, this process can be used in other environments such as notice boards in railway stations.
-Distribution of information by an autonomous source (Pull) A participant may not wish to be inundated with information from autonomous source wishing instead to be selective as to what information it receives. Furthermore, the participant n ay have questions of their own. Thus, it would be helpful if the participant could request information as-and-when needed.
Referring to Figures 45a and 45b, mobile terminal MTl 5 is located in front of the work of art 87. Its user wishes to obtain information regarding the work. Mobile terminal MTl 5 sends a request for information to the base unit 88 (step WI). The request includes the participant's profile. The base unit 88 searches the database 89 (step W2) using the participant's profile to filter the content (steps W3 & W4). The content is then unicast to the participant (step W5). The content is output using the mobile terminal MTl 5 (step W6) and, optionally, saved to a database in memory 29 (Figure 7), such as a hard disk (not shown) (step W7).
-New subgroup formation- Third parties, such as a museum restaurant, may be interested in offering services to group or subgroup members.
Referring to Figures 46a and 46b, mobile terminals MT2, MTU, MT12, MTl 5 are found near a restaurant. A terminal 90 which is associated with the restaurant broadcasts a caU 91 which comprises an advertisement, together with a subgroup address (step XI). The advertisement offers sushi at a reduced price and invites participants to the restaurant. The caU is received by mobile terminal MTl 2, which forwards the call to mobile terminal MT2 (step X2). The call is also* forwarded "to mobile terminal MTl 5. Mobile terminals MT2, MTl 5, in turn, forward the call to other mobile terminals.
At mobile terminal MTl 2, a decision is taken whether the user is in the offer (step X3). This is done by comparing the food type specified in the offer, namely sushi, with a preference entered by the user there-and-then or with a predefined preference. If the user is interested, then mobile terminal MTl 2 stored the subgroup address (step X4) and sends a response 92 (Step X5). Responses are collected and a restaurant subgroup is defined (step X6). Content 93, such as an electronic voucher for reduced-price sushi, is multicast to mobile terminal MTl 2 (step X7) and is output (step X8).
-Spontaneous aUocation of free time by tour conductor- During a tour, the tour conductor may suggest that participants are free to wander by themselves or continue to foUow the tour route. In effect, a further subgroup is defined similar to the process described with reference to Figure 16.
For example, if the tour visits a site which some members of the group are already familiar with, such as works by EngUsh artists, the tour conductor suggests that members of the EngUsh-speaking subgroup 79 (Figure 36b) are free to do as they please while he guides the remaining members of the group.
-Spontaneous requests for free time by tour participants- During a tour, a participant may suggest going shopping. In effect, a further subgroup is defined similar to the process described with reference to Figure 17.
For example, if the tour passes a shopping maU, one of the members of the group, transmits an invitation to the rest of the subgroup or group asking if anyone would Uke to join them.
It will be appreciated that many modifications may be made to the embodiments described above.