WO2007019689A1

WO2007019689A1 - Coordination of client and geo-location oriented services in a mobile network

Info

Publication number: WO2007019689A1
Application number: PCT/CA2006/001337
Authority: WO
Inventors: André Claude BAYOMOCK LINWA; Samuel Pierre
Original assignee: Corporation De L'ecole Polytechnique De Montreal
Priority date: 2005-08-16
Filing date: 2006-08-16
Publication date: 2007-02-22

Abstract

There is provided a method of coordinating client-oriented services provided to mobile clients in a network. The method comprises the steps of discovering the mobile clients in the network, getting profile information on the discovered mobile clients, using the profile information to determine services that apply to the discovered mobile clients, establishing linking data facilitating a connection of the discovered mobile clients to the services determined to be applicable, and giving access of the services determined to be applicable to the discovered mobile clients. There is also provided a method of locating mobile clients in a network and a system for coordinating client-oriented services provided to mobile clients in a network.

Description

COORDINATION OF CLIENT AND GEO-LOCATION ORIENTED SERVICES IN A MOBILE NETWORK

FIELD OF THE INVENTION The present invention relates to a mobile network and more specifically to the coordination of client and geo-location oriented services provided to mobile clients in a mobile network.

BACKGROUND OF THE INVENTION A geo-located web service is a web service that is offered in a particular geographical region or area. In the execution phase, a geo-located web service uses the mobile position to deliver a service. For example, a geo- located web service could be an emergency application which informs the police or firefighter administration of a particular region about the location of a car accident, using the driver's mobile phone position. In next generation (superior or equals to the third generation) of mobile networks, to obtain the mobile position, a geo-located web service will interact with the position or Location Server (LCS) of a mobile network operator [3GPP, "Functional stage 2 description of location services in UMTS", Technical Specifications TS 23.171 V3.9.0, Reference http://www.arib.or.jp/IMT- 2000/ARIB-spec/ARIB/23171_300.PDF, September 2002].

Referring to their specifications [3GPP, "Functional stage 2 description of location services in UMTS", Technical Specifications TS 23.171 V3.9.0, Reference http://www.arib.or.jp/IMT-2000/ARIB- spec/ARIB/23171_300.PDF, September 2002.], the geo-located web services can be deployed on the next generation mobile networks. Then, it will be possible to a Supplier Application Server (SAS) to get the location or geographical position of a mobile client. In this point of view, an SAS is considered as a set of web services that require the client position to deliver the service. A geo-located web service generates a maintainability problem of a service execution when a mobile client moves to a location area where the service is no longer offered by the SAS in execution.

The major challenge for a mobile client, as geo-located web services will be increasingly deployed in organizations [Ericsson, "Mapping user selected QoS to RSVP and DiffServ Attributes", http://ing.ctit.utwente.nl/WU5/D5.16/pa5.pdf, July 30, 2001], [C. Schmandt and N. Marmasse, "User-centered location awareness", Computer Volume 37, Issue 10, pp. 110 -111 , Oct. 2004], will be to discover a specific service corresponding to their requirements such as proximity, cost, network bandwidth or server utilization rate and to maintain a service in execution.

Traditional protocols for discovering services (SLP, Jini, UDDI, Globe) are not adapted to the geo-located web services as the client position is not an entry parameter to find a service. The deployment of such services thus requires the definition of a service discovery protocol allowing, among others, to select an SAS based on the location context of the mobile client (the location context refers to the current geographical area or position of a mobile client), to migrate services in execution to the nearest or closest SAS (it is an SAS that offers the service in execution at the current location context of a mobile client) and to factorize common location methods based on thematic aspect (for example, locate all taxi drivers of ABC company within two miles of my current position, where 'taxi drivers of ABC is a theme or subject). The selection of common locations based on thematic aspect is called a thematic factorization.

Related work in this field do not challenge the problem of discovering geo- located web service and maintain the service execution in the location context of a mobile client. Current architectures are either adapted to discover services where fixed clients are involved [E. Guttman, "Service Location Protocol : Automatic Discovery of IP Network Services", IEEE Internet Computing, pp. 71-80, July-August 1999] and those which consider the mobility put the emphasis on code and agent mobility [N. Harashima, T. Okoshi, J. Nakazawa, Y. Tobe, and H. Tokuda, "AMRB: Toward Location Migration Transparency of Services", IEEE International Conference on Parallel and Distributed Systems, pp. 305-314, ICPADS 2001], [F. Michahelles, M. Samulowitz and B. Schiele, "Detecting Context in Distributed Sensor Networks by Using Smart Context-Aware Packets", International Conference on Architecture of Computing Systems, Reference http://www.vision.ethz.ch/publ/arcs02.html, ARCS 2002] rather than data or task mobility to the closest SAS (as the web services are service oriented and use a client/server model) based on the location context of the mobile client and maintainability of service execution. Moreover, none of the architectures suggested in the literature offer a thematic factorization of common location methods to a set of application suppliers.

SUMMARY OF THE INVENTION Geo-located web services are web services offered in a particular geographical region. In mobile application design, a geo-located web service can be mapped to a set of mobile network location areas. As a mobile client roams in a mobile network, if he has a geo-located web service in execution progress at a supplier application server (SAS), he will lose its session in case when its current location is not covered by this SAS. With the next generation (third and up) of mobile networks, the geographical position of a mobile client will be sent back by a Location Server (LCS) to an application which requests it. As many geo-located web services will be deployed in the future, the great challenge for a mobile client will be to discover and maintain a geo-located web service when he is roaming. We propose a new system named Geo-Located Web Service - A -

Architecture (GLWSA) that aims to discover and maintain a geo-located web service with or without QoS at the nearest SAS of a mobile client current location. The GLWSA is a set of discover servers named GLWSMs (Geo-Located Web Service Manager) which are distributed in the topology. The GLWSA extends the UDDI and MLP protocols to add the GLWSM topology management and the thematic location of a mobile clients group, respectively. A thematic location consists of sending to a LCS, a chain of characters that represents a theme or a subject linking a group of mobile clients. In this paper, we present the GLWSA concepts and its mathematical formalism. Tests executed to evaluate the system performance prove that the GLWSA concepts are adequate to discover geo-located web services.

An example of thematic location is to determine the position of all railroad trains of Via Rail Canada which are in Montreal area. In this request, the "railroad trains of Via Rail Canada" is the subject or theme.

To discover a service with QoS (cost of service, network bandwidth and SAS utilization rate) and maintain a service execution with QoS, we defined a new mechanism that collects the network bandwidth of a particular geo- located web service and the SAS utilization rate at a specific GLWSM. For a specific service, the network bandwidth and SAS utilization rate are collected periodically in a particular GLWSM domain by sending a collect traffic message to all SAS that offer the concerned service in this domain. Each concerned SAS collects and sends back to the requestor GLWSM₁ the bandwidth and the SAS processor rate. Collected QoS parameters are used in the SAS selection and migration process.

As a first aspect of the invention, there is provided a method of coordinating client oriented services provided to mobile clients in a network, the method comprising: -discovering the mobile clients in the network;

-getting profile information on the discovered mobile clients;

-using the profile information to determine services that apply to the discovered mobile clients;

-establishing linking data facilitating a connection of the discovered mobile clients to the services determined to be applicable;

-giving access of the services determined to be applicable to the discovered mobile clients.

The step of establishing linking data preferably comprises binding software components selected for each of the mobile clients as a function of the profile information with a service application program operable to interact with and serve all of the mobile clients.

The profile information preferably includes quality of service parameters, the steps are preferably coordinated using at least one middleware server, wherein the step of getting profile information on the mobile clients preferably comprises sending the profile information from the mobile clients to the middleware server.

The profile information can also be predetermined, then the step of getting profile information on the mobile clients preferably comprises looking in a client database server, and the steps are preferably coordinated using at least one middleware server, wherein the linking data is communicated from the middleware server to at least one server providing the services without involving the mobile clients. The step of discovering the mobile clients in the network preferably comprises identifying the mobile clients while the mobile clients contacting their respective home middleware servers. The step of discovering the mobile clients in the network preferably includes determining a location of the mobile clients, the step of determining services that apply to the mobile clients preferably comprises determining a most appropriate application server providing a set of the services, and the step of giving access of the services to the mobile clients is preferably carried out using the most appropriate application server.

The method preferably further comprises, if required, coordinating migration of the determined services provided by an application server to the most appropriate application server.

The most appropriate application server is preferably a nearest application server to the mobile clients' location. The most appropriate application server can also be an application server that provides the set of the services and that allows access of the set of the services to some of the mobile clients in according to quality of service requirements.

The services preferably consist of a same application service executed by different application servers according to different quality of service parameters.

As a another aspect of the invention, there is provided a method of locating mobile clients in a network, the method comprising:

-defining a location criterion and a theme in association with a group of mobile clients; -sending a request containing the location criterion and the theme from a client;

-determining a first list of mobile clients from the theme contained in the request at a server location;

-obtaining mobile network location for the first list of mobile clients;

-processing the first list of mobile clients according to the location criterion to produce a second list of located mobile clients;

-sending the second list of located mobile clients to the client.

As a further aspect of the invention, there is provided a system for coordinating client oriented services provided to mobile clients in a network, the system comprising (see Fig. 6):

-a location server for locating the mobile clients within the network;

-at least one application server for providing application services to the mobile clients;

-at least one middleware server in communication with the location server for receiving locations of the mobile clients within the network, the middleware server further receiving profile information on the mobile clients, determining services that apply to the mobile clients as a function of the profile information, determining a most appropriate application server among the at least one application server to provide each of the services determined to be applicable, and for transmitting to at least one of the most appropriate application server and the mobile clients linking data for facilitating a connection of the mobile clients to the most appropriate server.

The system preferably further comprises at least one client database server connected to the at least one middleware server for receiving the profile information on the mobile clients. The profile information can also be sent by the mobile clients.

The at least one application server preferably comprises a large number of application servers.

The system preferably further comprises at least one UDDIM server in communication with the at least one middleware server for transmitting network topology and characteristics.

The at least one middleware server preferably comprises a large number of middleware servers, and the system preferably further comprises a root server connected to each of the large number of middleware servers for facilitating communication therebetween.

BRIEF DESCRIPTION OF THE DRAWINGS

Fig. 1 is a view showing a GLWSA architecture;

Fig. 2 is a view showing a GLWSA topology;

Fig. 3 a) is a view showing the impact of the micromobility in GLWSA in case of HMIPv6;

Fig. 3 b) is a view showing the impact of the macromobility in GLWSA in case of HMIPv6;

Fig. 4 is a UML class diagram showing UDDIM data structures;

Fig. 5 is a UML class diagram showing MLPe data structures; Fig. 6 is a block diagram of a system for coordinating client-oriented services provided to mobile clients in a network; Fig. 7 is a view showing a functional architecture of GLWSA.

Fig. 8 is a view showing the process of nearest service lookup with or without QoS;

Fig. 9 is a view showing the process of service publication; Fig. 10 is a view showing the process of coordination of the service migration with or without QoS;

Fig. 11 is a view showing the generated network topology and trajectory of a target mobile client;

Fig. 12 is a view showing Round Trip Time of a nearest service lookup in case of one client;

Fig. 13 is a view showing nearest service lookup time comparison;

Fig. 14 is a view showing Round Trip Time of a nearest service lookup in the case where the number of clients varies between 1 and 50;

Fig. 15 is a view showing coordination time of a service migration without QoS;

Fig. 16 is a view showing geo-located web service publication time in two

GLWSM leaf nodes;

Fig. 17 is a view showing geo-located web service publication time in two

GLWSM leaf nodes; Fig. 18 is a view showing geo-located web service publication time in ten

GLWSM leaf nodes;

Fig. 19 is a view showing geo-located web service publication time in twenty GLWSM leaf nodes;

Fig. 20 is a view showing comparison of the sending location time of a group of mobiles (locateMsids) versus a thematic location (locateSubject).

DETAILED DESCRIPTION

I. Overview of UDDI and MLP Protocols

In order to better understand our contribution, we first describe UDDI and MLP protocols which constitute the basis of the proposed architecture. A- The UDDI protocol

The UDDI is a directory or a register of companies in order to publish Web services and describe the manner of reaching each Web service in a WSDL (Web Service Description Language) document. The UDDI fulfills the functions of white, yellow and green pages. A detailed description of the UDDI protocol is described in [UDDI, http://www.uddi.org/specification.html]. The UDDI is made up mainly of four entities: businessEntity, businessServices, bindingTemplates and tModels. The businessEntity describes a company or an organization. It contains basic information about an organization (name, description, category, person contacts, etc.), the businessServices that it offers and the URL addresses where its Web services can be discovered. In a XML representation, the businessEntity envelopes all other entities. The businessServices is a collection of businessService entity offered by an organization. Each businessService has one or more technical Web Service Descriptions captured in an XML element called a bindingTemplate. The bindingTemplate contains the information that is relevant for application programs that need to invoke or to bind to a specific Web Service. This information includes the Web Service' URL address, and other information describing hosted services, routing and load balancing facilities contains the data required to invoke a service. Before invoking a Web Service, it is useful to determine whether the specific service being invoked complies with a particular behavior or programming interface. Each bindingTemplate element, therefore, contains an element called a tModel that has information which enables a client to determine whether a specific Web Service is a compliant implementation. The protocol UDDI offers two sets of API: inquiry and publish API. The inquiry API lookup or search for a businessEntity, businessService, bindingTemplate and tModel in the registry. The publish API verify credentials of a publisher, save or delete a businessEntity, businessService, bindingTemplate and tMode\ in the registry.

B- The MLP protocol The Mobile Location Protocol (MLP) is an application-level protocol that uses XML messages for querying the position of mobile stations independent of underlying network technology (UMTS, CDMA-2000, or WGS-136). The MLP serves as the interface between a Location Server and an application server [Location Inter-operability Forum (LIF)₁ "Mobile Location Protocol", LIF TS 101 Specification, Version 3.0.0 6, Reference http://dan.greening.name/profession/manuscripts/LIF%20TS%20101%20v 3.0.0.pdf, June 2002]. The MLP protocol has three main layers: service, element and transport. On the lowest level, the transport protocol defines how XML content is transported. Possible MLP transport protocols include HTTP, SOAP and others. The element layer (second layer) defines all common elements used by the services in the service layer. The service layer (top layer) defines the services offered by the MLP. The services are classified into five categories: standard location immediate service, emergency location immediate service, standard location reporting service, emergency location reporting service and triggered location reporting service. The standard location immediate service is a standard query service with support for a large set of parameters. This service is used when a single location response is required immediately (within a set time). The emergency location immediate service is a service used especially for querying the location of a mobile client that has initiated an emergency call. The response to this service is required immediately (within a set time). The standard location reporting service is a service that is used when a mobile client wants an application server to receive its location. The position is sent to the application server from the location server. The concerned application and its address are defined in the location server or specified by the mobile client. The emergency location reporting service is a service that is used when the wireless network automatically initiates the positioning at an emergency call. The position and related data are then sent to the emergency application from the location server. (5

The triggered location reporting service is a service used when the mobile client's location should be reported at a specific time interval or on the occurrence of a specific event.

II. The Global Architecture Proposed 0 The approach used to design the GLWSA is to analyze the web services discovering in mobility context. For these purposes, all entities that interact with the system must be found. We suppose that UDDI is a base registry of web services and extend it for client mobility. We consider MLP as the interoperability location protocol and extend it to add factorized common 5 location methods. In this section, the proposed system GLWSA (Fig. 1) is described before the GLWSA topology. Then, the impact of mobility will be illustrated. Finally, the UDDIM (UDDI for Mobiles) registry and the MLPe (Mobile Location Protocol extension) will be described.

0 A- Investigated System GLWSA

The GLWSA, illustrated in Fig. 1 , is composed of three main entities: the server Geo-Located Web Services Manager (GLWSM), the UDDIM and ClientlnfosDB (Client personal Information DataBase) databases.

5 The UDDIM database is an extension of UDDI to store the GLWSA topology. This extension is related to the geographical position of GLWSM nodes, the service agreement to a specific GLWSM node and the desired QoS limit values of a specific service. The database ClientlnfosDB stores user personal data such as identification (name, address, username, 0 password, etc.), equipment (mobile station identifier, phone number), subscription and quality of service data.

The GLWSM interacts with external entities such as: mobile clients, LCS, and SAS. SOAP (Simple Object Accces Protocol) is used between: Client and GLWSM, GLWSM GLWSM, GLWSM and SAS; MLPe protocol is used between GLWSM and LCS. To connect GLWSM to the databases UDDIM and ClientlnfosDB, a data connector such as ODBC (Open Data Base Connectivity) is used. The messages exchanged are carried out through the mobile network and Internet. B- GLWSA Topology

As shown in Fig. 2, the GLWSA topology proposed is a bi-level hierarchical model. A bi-level tree was chosen to reduce the number of exchanged messages among the GLWSM nodes when a publication service is initiated and to limit the lookup service to a single node. The lower level corresponds to the level of the tree leaves and the higher level represents the tree root. The leaf level includes or contains several GLWSM nodes. A leaf node contains a set of published services from the suppliers. The service publication is coordinated by the root node which stores all GLWSM nodes of the GLWSA topology.

Each mobile access network is associated with one GLWSM node. A GLWSM covers a region that represents the location areas of the mobile access network with which it is associated. Two different GLWSM nodes cannot cover the same location areas. A SAS can be associated with many GLWSMs. A supplier's particular web service can be distributed over many SAS. The main characteristic of the leaf nodes is that they are dependent on the location areas of the network operator to ensure the mobility tracking, to maintain service execution in a SAS, and to coordinate the service migration when a mobile client moves to location areas controlled by another GLWSM node where the service in execution exists. Otherwise, the service execution will continue to be provided by the SAS in progress. We impose a migration delay constraint of 2 seconds to migrate a service.

All leaf nodes offer functionalities for authentication and authorization, subscription, tracking mobile position, coordination of the migration, lookup and publication service. These are the relation properties of GWLSA:

Covered Areas: In the topology suggested, the location areas covered by two different GLWSM leaf nodes are disjoined.

Visibility Relation. Every GLWSM node that offers a service S,- knows all GLWSM nodes which offer the same service.

Home Node is the GLWSM leaf node where the mobile client is registered.

Every mobile client is associated with a single home node. The mobile client used the home node to authenticate himself and to lookup for a service. Visited Node is a GLWSM leaf node other than the home node of a mobile client.

Nearest Node is a GLWSM leaf node where the mobile client is located.

Nearest SAS is the SAS attached to the nearest GLWSM node and where the service requested by a mobile client is in execution phase.

C- Impact of the Mobility

Two mobility scenarios are possible when a mobile client interacts with a GLWSM node: micromobility and macromobility (Fig. 3a) and 3b)). We suppose that in the mobile network, an IP micromobility protocol (such as HMIPvθ, Cellular IPv6 or Hawaii IPv6) is used to know the location address of a mobile client in the network layer.

In case of micromobility with HMIPv6 for example, let us suppose that a mobile client who is attached to access router AR,i sends a lookup message to GLWSM_h and changes point of attachment to AR,₂ before receiving the result. During this local handoff, the mobile client will receive two care-of-addresses: new local care-of-address LCoA,₂ and a regional care-of-address RCoA₁. He will send a binding update containing RCoA₁ and LCoA,2 to a gateway router GR, acting as MAP (Mobile Anchor Point). The GR₁ extracts the LCoA,₂ and RCoA₁, then update its routing table to forward all received packets sent by GLWSMh with RCoA₁ to LCoA,₂. Thus, the mobile client will received the server SAS₁ address and will interact with it.

If the handoff occurs in macromobility for GR, to GR_j when the lookup message is sent to GLWSM_h, the mobile client will receive a new local care-of-address LCoA_ji and a new regional care-of-address RCoA_j. He will send three binding updates.: the first one to GRj acting as MAP that contains the LCoA_ji and RCoA_j, the second to the home agent that contains the RCoA, and the third to the correspondent GLWSM_h that contains the RCoA_j too. All packets addressed to the mobile client will be routed to its new RCoA,. Thus, the GR_j will forward them to the new LCOAJ-_I .

D- UDDIM Registry: UDDI Extension for Mobiles

The current UDDI version does not define data structures and API to find and publish a geo-located web service. In our work, we extend the UDDI protocol to add the GLWSA topology and the agreement service in order to find and publish a geo-located web service. We called this UDDI extension a UDDIM (UDDI for Mobiles). We select the UDDI as the basis protocol to extend because it is considered as the standard in the web service discovering process.

Practically, we add four XML data structures to the UDDI: Node, Agreement, AgreementNode and PolygonLineSegment. The UML representation of these elements is given in Fig. 4.

The data structure of a Node element describes information about a GLWSM node. The parameters that identify a GLWSM node are node key, the node URL, the type of the node ("root" or "leaf), the geographical position of the node (xPos, yPos, zPos), the maximum distance distanceMaxNodeSetvice allowed between an SAS and the node nodeld, the MAP address of the MAP associated with the node and the number of line segments numberOfPolygonLineSegment that delimit the node covered area (we consider that a node covered area has a polygon shape).

The Agreement element represents service agreement of a particular service. It is composed of the agreement key, service key, service administrator identifier and coordinate system reference. The AgreementNode element represents the detailed description of an agreement service in a particular GLWSM node. It is composed of the static QoS parameters (costService, BW_min, BWjnax, PPD_min, PPDjnax, SDU_smax). The BW min and BW_max represent the minimum and maximum bandwidth a service serviceld can offer at the node nodeld. The PPD_min and PPD_max represent the minimum and maximum propagation path delay a service serviceld can offer at the node nodeld. The SDU_smax is the maximum size of the service data unit. We chose the provided QoS parameters in conformity with the 3GPP recommendation of interactive applications [Ericsson, "Mapping user selected QoS to RSVP and DiffServ Attributes", http://ing.ctit.utwente.nl/WU5/D5.16/pa5.pdf, July 30, 2001]. The parameters (xPos, yPos, and zPos) of an AgreementNode element materialize the geographical position of a SAS that offers the service serviceld at the node nodeld. The PolygonLineSegment allows determining one line segment of a node-covered area which has a polygon shape. The (X1, Y1) and (X2, Y2) parameters represent the X and Y cartesian coordinate values of two points "1" and "2" belonging at one line segment, respectively. The attribute sign (can take one of the values '<=' or '>=') of a PolygonLineSegment is one of the line segment inequation of a node. The UDDIM API are methods that manage the data structures that we described above. The following API have been added to the UDDIM: addNode(paramefers are all parameters of element 'Node¹) adds a node in the topology; removeNode(nodeld: String) removes a node; findNode(nodeld: String) finds a specific node; getRootNode(nodeld: String) finds and returns the root node of GLWSA topology. The described API of this paragraph and those presented below are implemented in the topology manager object TopologyManager and the agreement manager AgreementManager described in Section V₁ respectively. createAgreement(paramefers are all parameters of element 'Agreement) creates a new Agreement for a specific service; removeAgreement(agreementld: String) removes a specific agreement; findAgreement(agreementld: String) finds a specific agreement; createAgreementNode(parameters are all parameters of element ΑgreementNode) creates a new agreement for a specific service in a particular node; removeAgreementNode(agreementld: String, nodeKey: String) removes a specific agreement for particular node; findAgreementNode(agreementld: String, nodeld: String) finds a specific agreement for a particular node; createPolygonLineSegment(parameters are all parameters of element 'PolygonLineSegmenf) creates a new line segment for a specific node; removePolygonLineSegment(lineSegmentld: String) removes a specific line segment; findPolygonl_ineSegment(lineSegmentld: String) finds a specific line segment.

E- MLPe: MLP Extension

The usability of mobile client location to offer services is a common characteristic of geo-located applications. With the current MLP version 3.0, when an application requests the positions of a group of mobiles, it sends a list of mobile identifiers to the LCS (Table 1). We analyzed these applications and found that in the location request of a group of mobiles, the mobiles are generally linked by a thematic subject. Thus, we factorized the common location methods related to a group of mobiles on the basis of a thematic subject to interact with the LCS. Thematic factorization of the common location methods appeared important to us, as it allows code re- utilization and decreases the message size of the location request of the group of mobiles loaded on the network. Indeed, thematic factorization would allow requesting the positions of a group of mobiles bound by a subject and thus avoid loading on the network a list of the mobiles which would increase the transmission time of the requests to the GLWSM. For these purposes, the current MLP was extended.

TABLE 1 GROUP OF MSIDS CONSTRUCTION IN CURRENT MLP VERSION

<msids>

</msids>

The data structures of elements added to the MLP protocol are represented in the UML diagram (Fig. 5).

The MLPe was also provided with the API to manage elements Theme and ThemeMsid: addTheme(parameters are all parameters of element Theme) adds a theme to an LCS, removeTheme(themeld: String) removes a specific theme; findTheme(themeld: String) finds a specific theme; addThemeMsid (themeld: String, msld: String) relates or adds a specific mobile identifier msld to the particular theme themeld; findAIIMsidOfTheme(themeld: String) finds all mobile client identifiers related to the theme themeld; removeThemeMsid (themeld: String, msid: String ) removes a specific mobile identifier msld from the particular theme themeld. In order to factorize the common geolocated services, we established a typology of the geolocated applications documented in the literature. We distinguish among four categories of applications: informational services, mobile client tracking, resource management services and navigation services [M.A Dm and S. Saada, "Location based mobile services: the essentials", Alcatel Telecommunications review, pp. 71-76, 1^st quarter 2001].

These are the factorized location methods: - locateSubject(subject): allows to locate the position of all the mobiles bound on the queried subject;

- locateSubjectNearOf(subject, position, precision): allows to locate the position of all the mobiles of the queried subject whose distance compared to the value "position" is less than or equal to "precision"; - locateSubjectlnZone(subject, idzone): allows locating the position of all the mobiles of the subject queried which are in the area "idzone";

- ifEntry(subject, idzone): allows to find the mobiles of the subject queried entering the location area "idzone" and to notify the entry to the SAS server; notifyEntry(msid): notifies the SAS that the mobile identifier is entering into the covered location areas;

- ifExit(subject, idzone): allows to find the mobiles of the subject queried leaving the location area "idzone" and to notify the exit to the SAS server; notifyExit(msid): notifies the SAS that the mobile identifier "msid" is leaving; - collocate(msid, subject): allows finding the mobiles of the queried subject which are in the same location area as the mobile "msid".

To implement the MLPe protocol, we modified the MPS 6.0 tool of Ericsson that simulates mobile location. This tool is originally implemented using Java language. We created a new package

"com.ericsson.mps.jml.mlp.Theme" where we added the data structure of Theme, ThemeMsid and PolygonLineSegment. For simulation purposes, we mapped this structure to a database ClientlnfosDB by creating associated tables. An extract of the detailed implementation of thematic methods added is described in Table 2. Due to the basic function getLocation (of LocationProtocol class) called to locate a mobile in the LCS server, we were constraint to add to every thematic location method (except notify Entry and notifyExit), a new parameter that represents a request context RequestContext object in order to initialize the location parameters in MPS tool. We modified the MPS "com.ericsson.mps.jml.DefaultConnection" class to implement all thematic location methods and APIs that manage data structure Theme and ThemeMsid. We also add in this class a private method getSpatialData that converts longitude/latitude/altitude coordinates to Cartesian coordinates and a private method islnsideCoveredArea which verifies a mobile is inside a node covered area.

In Table 2, parameters myUser and myPassword are attributes of the DefaultConnection class. The LocationData object contains the position result status (success or failure) of a specific mobile. The zone is the node covered area (specifically, it is a collection of PolygonLineSegment elements). The detailed information of a mobile position is contained in the LocatedMobileStation object. The parameter urlList contains two URL addresses listened by the Ericsson MPS Emulator. The method pushAnnounceEntry called by notifyEntry just adds a found mobile identifier in the list of found mobiles in the SAS.

The thematic location generates a security problem to know if a location requester that is authorized to use a thematic location has the right to obtain the position of a particular client. Then, for security reasons, the authorization process to get a mobile location verifies first if a particular user has the right to use the requested thematic location and if he has the right to see the position of a client before getting a mobile client location. We propose a scheme <authorized subject to track the members of a thematic location> <authorized operations> <target object> <object conditions> to perform this kind of access control. For example, authorized user to track the members of the subject ABC Taxi><collocate> <the mobile client identifier msid ><if the mobile client identifier msid is a member of the subject ABC Taxi>.

The global process of locating thematically a group of mobile clients comprises the following steps:

1 - A client (mobile or fix) defines a location criterion and a thematic subject associated with a group of mobile clients and sends it to a middleware server. 2 - The middleware server sends the received client request to a location server in order to determine the location of mobile clients in according to the request criterions;

- The MLPe protocol process the request and interacts with a client database to determine a first list of mobile clients from the theme contained in the request;

- The MLPe sends the first list of mobile clients determined to the Location Server (LCS) in order to localize them within the network.

3 - The Location Sever localize the mobile clients contained in the first list and determine those among them who respect the location criterion specified by the client in his request and includes these mobile clients in a second list;

- The Location Server sends the second list of mobile clients to the middleware server.

4 - The middleware server sends the second list of located mobile clients to the client. TABLE 2

EXTRACT OF THEMATIC LOCATION METHODS public synchronized void ifEntry(String subject, Array List zone.String urlApp.LocationRequestContext requestContext)

{

LocationResult result=null, ArrayList mobιleFound=null, boolean flag=false, try{ result=locateSubjecl(subject, requestContext), ArrayList locatιons=(Arrayϋst) result getLocatιons(), for (int ι=0, ι<locatιons sιze(), ι++){ ιf(((LocatιonData)locatιons get(ι)) getLocationStatusO == Lc cationData SUCCESSFU L_LOCATION){

LocatedMobileStation lms =(LocatedMobιleStatιon)locatιons get(ι), Spatial spatial = getSpatιalData(lms), flag=ιslnsιdeCoveredArea(zone, spatial), if(Hag==true){ notιfyEntry(((LocatιonData)locatιons get(ι)) getMobιleStatιonld(),urlApp),

} } }

}catch(Exceptιon e){ e printStackTraceO, }

} public synchronized void notifyEntry(String msid, String urlApp) { try {

Service service = new Servιce(),

Call call = (Call) service createCall(), call setTargetEndpoιntAddress( new java net URL(urlApp) ), call setOperatιonName(new QNamefhttp //soapinterop org/", "pushAnnounceEntry")),

String rep= (String) call ιnvoke( new ObjectQ {msid} ), } catch (Exception e) {

System err prιntln(e toStπngO), } public synchronized LocationResult locateSubject(String subject, LocationRequestContext requestContext) {

Theme theme=null, ThemeMsid themeMsid =null, com ericsson snf mps Connection conn=null, LocationResult result=null,

CommunicationException communicationexception = null, LocationProtocol locationprotocol = null, java net URL urlListQ = factory getURLs(), java net URL urlLCS=null, try{ themeMsid = new ThemeMsιd(), theme = new Theme(),

ArrayList msιdLιst=(ArrayLιst) themeMsid findAIIMsιd(theme fιndThemeBySubject(subject) getThemeld()), if (msidLιst sιze()'=0){

LocationTargetfJ target=new LocatιonTarget[msιdLιst sιze()], for (int i=0, ι<msιdLιst sιze(), ι++){ target[ι]=new MobιleStatιon(msιdLιst get(ι) toStπngO),

} if (UrILiSt[O] '=null) urlLCS=urlϋst[O], if (urlList[1] ι=null) urlLCS=urlLιst[1],

HttpURLConnection httpurlconnection = locationprotocol openConnection(urlLCS), result = locationprotocol getLocation(httpurlconnection, myUser, myPwd, target, requestContext), httpurlconnection dιsconnect(),

}

}catch(Exceptιon e) { e printStackTraceO, } fιnally{ try{ conn closeO, }catch(LocatιonExceptιon lex){

System out pπntlπflex getMessage()), } I

III. The Functional Architecture

To determine the functional architecture, we used a top-down approach based on the use cases analysis of the different types of applications that can be deployed in a GLWSA to discover objects and API functions. The functional architecture of a GLWSA is illustrated in Fig. 7. In this section, we describe the manager objects where API functions are implemented.

The functional architecture has three main layers: published services and asynchronous message, service managers and basic classes.

A- Published services and asynchronous message listeners layer

The published services and asynchronous message listeners expose some synchronous methods of the service managers layer that will be accessible to an external client and listen for asynchronous messages sent by another entity. The terms synchronous and asynchronous mean that in a service execution, a client will wait or will not wait for the server response, respectively. A published service is a web service. To publish services (Table 3), we used Axis Apache container that parses developed classes to SOAP (and SOAP to classes), deploys the methods selected in a service manager to a web service.

TABLE 3 PUBLISHED SERVICES OR WEB SERVICES SUB-LAYER DESCRIPTION

The asynchronous message listeners consist of listening to the message sent to the broker destination addresses of a specific GLWSM node. To implement asynchronous messages, we used Sun Message Queue 3.5 toolkit. Each message has a producer who writes and sends the message and one or many subscribers that consum the message.

TABLE 4 ASYNCHRONOUS MESSAGES LISTENERS SUB-LAYER

B- The Service Managers Layer The service managers layer is composed of eight software modules: AA "Authentication and Authorization", DSM "Discovery Services Manager", SM "Subscription Manager", LM "Location Manager", TM "Topology Manager", AM "Agreement Manager", NQoSM "Network QoS Manager", and MM "Migration Manager".

1) Authentication and Authorization Manager Authentication and authorization operations are conducted in GLWSM home. Mobile clients first connect with GLWSM home giving their credentials (username, password). After successful authentication, access control takes place. The access control operation is based on the user's role and capabilities. There are three types of roles: administrator, supplier and client. 2) Subscription Manager

Suppliers use a subscription manager to register new clients who want to use one of their applications. This operation will assign a GLWSM home to a client according to his home address. Personal data such as name, username, password, address, subscribed services, mobile equipment identifier will be recorded in the ClientlnfosDB database attached to the GLWSM home node.

3) Discovery Services Manager Nearest service lookup: When an authorized mobile client looks up for a geo-located web service (Fig. 8), the following steps are executed:

1- The mobile client sends first a nearest service lookup request containing the service name and the mobile identifier to his home

GLWSM node. 2- The home GLWSM node sends a client position request to the

LCS. The LCS returns the client's geographical position to the

GLWSM home. 3- The home GLWSM node finds and selects in his UDDIM database the GLWSM leaf node that covers the current location area of the mobile client (the covered areas property described in the section

IV-B is used in this step). If the mobile position does not belong in the covered areas of any of the GLWSM leaf nodes, then the requested service is not offered in the location area where the mobile client currently resides and no SAS will be selected. 4- If a GLWSM leaf node is found, it is considered to be the nearest

GLWSM node. 5- Then, the home GLWSM node finds and selects the requested service in his UDDIM (the visibility relation described in the section

IV-B is used in this step). 6- The URL of the requested service associated with the nearest

GLWSM will be returned to the mobile client. 7- The SAS that offers the returned service will be considered to be the nearest SAS offering this service.

Nearest Service lookup with QoS: The detailed description of this feature consists of finding a service with the associated network QoS. This aspect is beyond the scope of this paper.

Service Publication: After a successful authentication of an SAS administrator to the GLWSM root, the administrator sends the service entity to be published and its agreement identifier to the root node (Fig. 9). The system verifies the agreement conformity and saves the service in the UDDIM root. This service is forwarded to all GLWSM leaf nodes that are included in the agreement service. The forwarding message is done by sending an asynchronous message destined to all nodes that subscribed to this service publication topic (all GLWSM leaf nodes included in the agreement service contract except the producer of the message). Each concerned leaf node receives the message, stores the data and sends back a receipt to the GLWSM root. The GLWSM root keeps a list of received messages and compares it to the list of selected leaf nodes in order to confirm whether publication was well done in all nodes.

4) Migration Manager

The migration manager of a current nearest GLWSM node tracks the position of any mobile client in communication with a current SAS attached to it. It also coordinates the service migration by informing the current nearest SAS in execution of the next SAS address. At the beginning of the process, a mobile client MC is attached to a current nearest SAS in execution. This SAS is considered as the current SAS where the requested service is in execution. The detailed description of the coordination of the service migration with QoS is beyond the scope of this paper. The steps below described the coordination of a migration process without QoS (Fig. 10):

1- The current nearest GLWSM where the mobile MC is attached sends to an LCS a location request that consists of tracking if the mobile MC is presently in its covered location areas.

2- The geographical position obtained is processed by the current nearest GLWSM to find the next nearest GLWSM node that covers the current location area of the mobile client.

3- Then, the current nearest GLWSM verifies if the next nearest GLWSM found is a member of the service agreement nodes. In other terms, the current nearest GLWSM verifies if the requested service is offered in the next nearest GLWSM.

4- If not, the service does not exist in the location area where the mobile is moving. Otherwise, the next nearest GLWSM is either attached to the same current nearest SAS or a next nearest SAS.

5- If the next nearest GLWSM is attached to the current nearest SAS, the service execution will continue to this current nearest SAS and the next nearest GLWSM will be notified by the current nearest GLWSM to track the position of the mobile client who has just entered into his covered location areas.

6- If the next nearest GLSWM is attached to a next nearest SAS that offers this service, the current nearest GLWSM informs the current nearest SAS in execution progress of the URL address of the next nearest SAS where the service must be migrated so that the service remains closer of the client's current position. Once the service has migrated, the current nearest GLWSM associated with the current nearest SAS closes the client session and instructs the next nearest GLWSM to continue tracking the target client position.

The maintainability of services in execution provides the continuity of a service and eventually reduces the communication costs. Indeed, when a client moves over a mobile network topology, the number of used hops between him and the SAS taking part in the communication will generally increase if the client moves farther away. Consequently, the total delay of exchanged messages between these two entities may considerably increase due principally to the queuing delay in the hops. The service migration will reduce this latency by selecting the nearest SAS that offers the service in the mobile client location context and decrease communication costs in cases where time billing model is used [www.3G.co.uk., "SFR launch 3G" , http://www.3g.co.uk/PR/June2004/7922.htm, June 17, 2004].

The process migration between two SAS is not in the scope of the GLWSA. Meanwhile, the SAS process migration can be done using thread migration without transferring the application code (in fact that each SAS has a persistent application code) or using session migration. An interesting work in thread migration realized by [S. Bouchenak, D. Hagimont, S. Krakowiak, N. De Palma and F. Boyer. "Experiences Implementing Efficient Java Thread Serialization, Mobility and Persistence", INRIA Technical Report No. RR-4662, December 2002], conducted to build a thread migration tool that does not generate the message overhead. This tool is certified and protected by Sun Microsystems. The performance of thread or session migration depends on the size of frames and the size of serialized objects to migrate. The session or thread median migration latency is in order of three milliseconds to few hundred of milliseconds.

5) Topology Manager

The topology manager object maintains the topology of the GLWSA. It adds, removes and modifies GLWSM node information. Those operations can only be performed by a GLWSM administrator. 6) Location Manager

The location manager interacts with the LCS to obtain the position of mobile clients. It contains location API and thematic location API to get position of a mobile or a group of mobile clients.

7) Agreement Manager

The agreement manager defines the agreement contract of a geo-located web service. It binds a geo-located web service of a SAS to a list of GLWSM nodes, defines the service cost at each GLWSM node, the minimum and maximum QoS requirements that the supplier wishes to be controlled.

8) Network QoS Manager

The network QoS will be used to collect the QoS parameters (network path bandwidth, SAS utilization rate) in a particular domain controlled by a

GLWSM node. Thus, when the mobile client sends a lookup message with

QoS₁ the GLWSM home will verify if the desired QoS can be obtained.

Then, the found service URL will be returned to the mobile client. The proposed network manager does not provided the negotiation or re- negotiation QoS mechanisms. The detailed operations of the network QoS manager fall beyond the scope of this paper.

IV. Implementation Details and Evaluation

In order to evaluate the proposed GLWSA architecture, we built a prototype using the Java programming language (Jbuider 7 and Sun Mesasge Queue

3.5). This prototype implements the functionalities of the GLWSM and communicates with the LCS and the SAS servers. Communication with the

LCS was carried out through Ericsson MPS 6.0 emulator. The emulator uses an MLP V3.0 protocol to determine the position of a client (or a group of clients) moving over the network topology. We generate a network topology with the network density set to urban, the distance between two base stations is set to 5000 meters and created a mobile trajectory with a constant speed value (Fig. 11). In Fig. 11 , the GLWSMh is the home GLWSM domain of the target mobile client and its geographical covered areas, the GLWSM1 and GLWSM2 are the visited GLWSM domains of the target mobile client with their associated geographical covered areas. In our tests, we used three constant speeds 50 km/h, 100 km/h and 200 km/h. By using the configuration settings described above, a static route file that contains the current cell identifier where the mobile resides, the relative distance between the mobile and the current base station and the mobile position data calculated each 10 seconds and given in geographical system coordinate (latitude/longitude/altitude) is created. The tool calculates the client position between two consecutive offset times of the route file (for example between 0 and 10 seconds) by using the interpolation operations. But the formula used to do the interpolation operations is not given by the MPS tool specifications. At the beginning of the simulation, the emulator starts a clock and reads the mobile position in function clock time in the static route file created. We used the database management system Oracle 9i to store data in UDDIM registry and ClientlnfosDB. We used JUDDI [jUDDI, http://ws.apache.org/juddi/] and appended UDDIM API to interact with the registry UDDIM. The machines used to materialize the GLWSM, the SAS and the LCS are similar (1.2 GHz Pentium III with 512 Mo RAM). The machines are connected in a wireless LAN. The WLAN has a transmission rate of 11 Mbits/s and is compliant IEEE 802.11 b. The relevant metrics selected to evaluate the performances of the GLWSM are: the nearest service lookup time, the lookup mobile time, the migration service time and the publication service time.

The round trip time (RTT) is the time difference between the reception time of the request response at a client machine and the time when the client sent a request to a server. In Fig. 12, we measured the RTT of a nearest service lookup when a mobile client sends a request each 2 seconds to his home GLWSM. We found a minimal RTT value of 20 milliseconds, an average RTT of 28 milliseconds and a maximum RTT of 52 milliseconds. Then, we compared in Fig. 13, the average RTT obtained with the lookup service time (RTT) in Jini and SLP [J. Govia and M. Barbeau, "Results of Comparing Bandwidth Usage and Latency: Service Location Protocol and Jini", Workshop on Ad hoc Communications, held in conjunction with the Seventh European Conference on Computer Supported Cooperative Work (ECSCW 2001), Bonn, Germany, Reference http://www.scs.carleton.ca/~barbeau/Publications/2001/WAHC/govea.pdf, September 16-20, 2001] to which we added the average calculation time of the position to the LCS which is 23 milliseconds, a total lookup service time of 46 and 51 milliseconds are obtained for SLP and Jini respectively. Note that the substantial gain of the GLWSM over Jini and SLP in the nearest service lookup of geo-located web service is related to the fact that the two traditional protocols Jini and SLP do not integrate the UDDI structure in their architecture and thus require additional data transformation operations to be compatible with a UDDI data structure.

In Fig. 14, we measured the RTT of the nearest service lookup when the number of clients varies from 1 to 50. We found an average RTT value of 52 milliseconds and a maximal RTT of 620 milliseconds. We also found that the RTT increases considerably when the number of clients is greater than or equal to 28. We think that the increasing of RTT and the observed peak values are due to the GLWSM buffer overflow.

The coordination time of a service migration shown in Fig. 15 represents the RTT to send the URL of the next SAS (that implement the service in execution of a mobile client) and the mobile identifier parameter of a mobile client (who just changed the SAS domain) to the current SAS in execution. At the receiving of the message, the current SAS just sends back an acknowledgement to the GLWSM sender. Then, the GLWSM sender notifies the next GLWSM to track the target mobile. The coordination time of a service migration has an average RTT of 11 milliseconds, a minimal value of 7 milliseconds and a peak value of 40 milliseconds. We varied the speed of the target mobile and we remarked that the speed does not have a direct impact in the coordination of the service migration. Meanwhile, as we imposed that the delay migration constraint must be less than or equals to 2 seconds, if a mobile client has a speed of 300 Km/h when the migration is relevated, the target mobile will be at 166.67 meters of the precedent GLWSM domain when the service migration will be terminated. As the service migration for SAS to SAS has a maximum average rate of 300 milliseconds [S. Bouchenak, D. Hagimont, S. Krakowiak, N. De Palma and F. Boyer. "Experiences Implementing Efficient Java Thread Serialization, Mobility and Persistence", INRIA Technical Report No. RR- 4662, December 2002], we will have a maximum total service migration time (SAS service migration time and coordination migration time) of 355 milliseconds which is less than the delay migration service constraint. Thus, the system has a margin time 1645 milliseconds for huge applications.

Fig. 16 shows a geo-located web service publication time in two GLWSM leaf nodes. To measure the service publication, we suppose that an authorized supplier sent a size of 1116 bytes parameter data (service, agreement service, agreement node entities) to publish to the root GLWSM machine. Then, the root GLWSM stores the data in his UDDIM and forwards them to the publication queue listened by the two GLWSM leaf nodes. After storing the forwarded data in their UDDIM, each GLWSM leaf node sends back a recept to the root GLWSM. We found an average RTT of 105 milliseconds with a minimal and maximal RTT of 88 and 300 milliseconds during 10 minutes observation. We also analyzed the publication time in function of the number GLWSM leaf nodes (which increases the size of parameters sent in a publication process) where they are published. We found that the publication time increases when the number of GLWSM leaf nodes increases too. We found an average RTT of 110, 147 and 247 milliseconds for 5 (Fig. 17), 10 (Fig 18) and 20 GLWSM leaf nodes (Fig. 19), respectively. This variation is due in fact that the size of message sent to a root GLWSM increases when the number of selected GLWSM leaf nodes increases too.

The sending location time of a group of mobiles in a LCS was measured to evaluate the relevance of thematic factorization of the common location functionalities. Tests were designed to compare a sending location request of a group or list of mobiles versus a thematic location. For this purpose, we built two methods: locateSubject that has one parameter representing a subject or a theme and locateMsids that takes as parameter the list of mobile identifiers that we want to locate. We calculated the sending time by building a SOAP client request that loads these two methods. The sending time of locateSubject is calculated by adding the time difference between the received time and sent time of the request and the lookup time to retrieve all mobiles identifiers in the database ClientlnfosDB on the server side. The sending time of locateMsids is calculated by adding the reading time of all mobile identifiers in the database ClientlnfosDB of client machine and the time difference between the received time and sent time of the request. Fig. 20 shows the comparison between the two curves with the maximum subject size implemented (250 characters) and the size of mobile identifiers implemented (20 characters). Note that the thematic location is more efficient. We also remarked that the thematic location gain increases when the number of mobiles to locate increases too.

Claims

1. A method of coordinating client oriented services provided to mobile clients in a network, the method comprising :

discovering said mobile clients in the network;

getting profile information on said discovered mobile clients;

using said profile information to determine services that apply to said discovered mobile clients;

establishing linking data facilitating a connection of said discovered mobile clients to said services determined to be applicable;

giving access of said services determined to be applicable to said discovered mobile clients.

2. The method as claimed in claim 1 , wherein said step of establishing linking data comprises binding software components selected for each of said mobile clients as a function of said profile information with a service application program operable to interact with and serve all of said mobile clients.

3. The method as claimed in claim 1 or 2, wherein said profile information includes quality of service parameters, said steps are coordinated using at least one middleware server, wherein said step of getting profile information on said mobile clients comprises sending said profile information from said mobile clients to said middleware server.

4. The method as claimed in any one of claims 1 to 3, wherein said profile information is predetermined, said step of getting profile information on said mobile clients comprises looking in a client database server, and said steps are coordinated using at least one middleware server, wherein said linking data is communicated from said middleware server to at least one server providing said services without involving said mobile clients.

5. The method as claimed in any one of claims 1 to 4, wherein said step of discovering said mobile clients in the network comprises identifying said mobile clients while said mobile clients contacting their respective home middleware servers.

6. The method as claimed in any one of claims 1 to 5, wherein said step of discovering said mobile clients in the network includes determining a location of said mobile clients, said step of determining services that apply to said mobile clients comprises determining a most appropriate application server providing a set of said services, and said step of giving access of said services to said mobile clients is carried out using said most appropriate application server.

7. The method as claimed in claim 6, further comprising, if required, coordinating migration of said determined services provided by an application server to said most appropriate application server.

8. The method as claimed in claim 6 or 7, wherein said most appropriate application server is a nearest application server to said mobile clients' location.

9. The method as claimed in claim 8, further comprising, if required, coordinating migration of said determined services provided by an application server to said most appropriate application server.

10. The method as claimed in any one of claims 6 to 9, wherein said most appropriate application server is an application server that provides said set of said services and that allows access of said set of said services to some of said mobile clients in according to quality of service requirements.

11. The method as claimed in claim 10, further comprising, if required, coordinating migration of said determined services provided by an application server to said most appropriate application server.

12. The method as claimed in any one of claims 1 to 11 , wherein said services consist of a same application service executed by different application servers according to different quality of service parameters.

13. A method of locating mobile clients in a network, the method comprising:

defining a location criterion and a theme in association with a group of mobile clients;

sending a request containing said location criterion and said theme from a client;

determining a first list of mobile clients from said theme contained in said request at a server location;

obtaining mobile network location for said first list of mobile clients;

processing said first list of mobile clients according to said location criterion to produce a second list of located mobile clients;

sending said second list of located mobile clients to said client.

14. A system for coordinating client oriented services provided to mobile clients in a network, the system comprising:

a location server for locating said mobile clients within the network;

at least one application server for providing application services to said mobile clients;

at least one middleware server in communication with said location server for receiving locations of said mobile clients within the network, said middleware server further receiving profile information on said mobile clients, determining services that apply to said mobile clients as a function of said profile information, determining a most appropriate application server among said at least one application server to provide each of said services determined to be applicable, and for transmitting to at least one of said most appropriate application server and said mobile clients linking data for facilitating a connection of said mobile clients to said most appropriate server.

15. A system as claimed in claim 14 further comprising at least one client database server connected to said at least one middleware server for receiving said profile information on said mobile clients.

16. A system as claimed in claim 14 wherein said profile information is sent by said mobile clients.

17. A system as claimed in any one of claims 14 to 16 wherein said at least one application server comprises a large number of application servers.

18. A system as claimed in any one of claims 14 to 17 further comprising at least one UDDIM server in communication with said at least one middleware server for transmitting network topology and characteristics.

19. A system as claimed in any one of claims 14 to 18 wherein said at least one middleware server comprises a large number of middleware servers, and said system further comprises a root server connected to each of said large number of middleware servers for facilitating communication therebetween.