KR100712047B1 - Device detection and service discovery system and method for a mobile ad hoc communications network - Google Patents

Abstract

A computer system, method and computer program product are provided for performing device detection and service discovery in a mobile ad hoc communication network. The method includes performing a query of the mobile ad hoc communication network to find nearby devices. If the query indicates that the nearby device includes a middleware layer, the method further includes identifying whether each of the nearby devices includes the middleware layer. For each of the nearby devices that include the middleware layer, the method further includes executing the middleware layer to perform application and service discovery and to initiate applications and services.

Description

Device detection and service discovery system and method for a mobile ad hoc communication network

Cross-Reference to the Related Application

This application for a patent is a US patent application, filed October 31, 2002, with the US Patent and Trademark Office, entitled "Device Detection and Service Discovery System and Method for Mobile Ad Hoc Communication Networks". Claims priority to No. 10 / 284,135 and includes the application by reference. This application for a patent is also part of the United States, filed September 16, 2003 with the US Patent and Trademark Office, entitled "Device Detection and Service Discovery System and Method for Mobile Ad-hoc Communication Networks." (continuation-in-part) Claims priority to patent application No. SS / XXX, YYY and includes this application by reference. This application for a patent is also filed with the U.S. Patent and Trademark Office on September 16, 2003, entitled US "Mechanism for Improving Access Control in Equal-to-Equal Ad Hoc Communication Networks." It is associated with patent application number SS / XXX, YYY and is incorporated by reference. This application for a patent is also filed with US Patent and Trademark Office on September 16, 2003, US Patent Application No. SS, entitled “Application Control in Equal-to-Equal Ad Hoc Communication Network”. / XXX, YYY and the above application is incorporated by reference. The assignee is the same as the assignee of the parent patent application, the partial patent application and the related patent applications.

The disclosed invention generally relates to communication between devices connected to a wireless communication network. In particular, the disclosed invention is a system and method for performing device detection and service discovery in a mobile ad hoc communication network.

Short-range wireless systems have a range of less than one hundred meters, but can connect to the Internet to provide communication over longer distances. Short-range wireless systems include, but are not limited to, wireless personal area networks (PANs) and local area networks (LANs). Wireless PANs use low cost, low power wireless devices with a typical range of 10 meters. An example of wireless PAN technology is the Bluetooth standard. The Bluetooth standard operates in the 2.4 GHz industrial, scientific and medical (ISM) band, provides a peak radio-link speed of 1 Mbps and is low enough for use in personal, portable electronic devices such as personal digital assistants or mobile phones. Provide power consumption. A description of the Bluetooth communication protocol and device operation principles is given in December 1999, Bluetooth Specific Interest Group, Bluetooth Standard Specification , Version 1.0B, Volumes 1 and 2. WLANs are more expensive than wireless PANs, but have a longer range. Examples of wireless LAN technology are the IEEE 802.11 wireless LAN standard and the HIPERLAN standard. The HyperLAN standard operates in the 5 GHz Unlicensed-National Information Base (U-NII) band and provides a peak radio-link speed of 10 to 100 Mbps.

An ad hoc network is a short-range wireless system that includes any collection of wireless devices that are physically close enough to exchange information. An ad hoc network is quickly configured with wireless devices joining and leaving the network as wireless devices enter or leave the vicinity of the remaining wireless devices. The ad hoc network may also include stationary wireless devices that operate as one or more access points, ie gateway connections to other networks or as a standalone server.

In the future, the Bluetooth standard is likely to support the interconnection of multiple piconets to form a multi-hop ad hoc network or scatternet. In a scatternet, the connecting device transmits traffic between different piconets. The connecting device may serve as a master device in one piconet, but may act as a slave device or master device in another piconet. Thus, the connecting devices join the piconets, including the scatternet, by adapting the timing and hop sequence to each piconet and perhaps changing their roles from master device to slave device.

Bluetooth devices include, but are not limited to, mobile electronic devices such as mobile phones, personal or laptop computers, radio-frequency identification tags and personal digital assistants (PDAs), pagers, or portable-computing devices. Each Bluetooth device includes applications and operating system programs designed to discover other Bluetooth devices as they enter and leave the communication range of the network. The requesting Bluetooth device in the client role and the responding Bluetooth device in the server role establish a link between the two devices. The requesting and responding Bluetooth device discovers the services provided by the other Bluetooth device and how to access the services using the link and service discovery protocol.

Prior art systems follow a similar pattern of behavior for service discovery protocols. The service description, generated using the description language and appropriate vocabulary, is advertised or made available for query matching. Some prior art systems advertise the service description by pushing the description to a directory and asking advertisers to find the directory. Other prior art systems advertise the service description by making the descriptions available for equal-to-equality discovery. A client device that needs to find the service description composes a query using a query language and matching vocabulary and forwards the query using a query protocol or a decentralized query-processing server.

Service discovery protocols in prior art systems require sending inquiry messages and responding to the inquiry messages. If no other device is present, the inquiry messages are sent in vain. To avoid excessive power consumption, prior art systems typically require a human user to manually initiate device detection when there is another device of interest. For example, a human user manually initiates device detection when connecting a cellular telephone to a laptop computer to handle data communication or when connecting a wireless headset to a laptop computer to deliver digital audio. The prior art systems rely on three assumptions. First, an application can be started freely because the existence of its services is guaranteed. Second, the application performs service discovery if it first requires a service. Third, the configuration of the network does not change during the life of the application.

Thus, in the device detection and service discovery protocol, which avoids excessive power consumption and allows an application present on one device to automatically discover any other resource or corresponding application present on any of the remaining devices in the ad hoc communication network. There is a need. The protocol does not require a human user to manually initiate device detection to discover the counterpart application or other resource. Moreover, the protocol will not guarantee the presence of a particular service, and the configuration of the network will accommodate a dynamic network environment since devices frequently enter and leave the network. The presently disclosed invention addresses this need.

A computer system, method and computer program product are provided for performing device detection and service discovery in a mobile ad hoc communication network. The method includes performing a query of the mobile ad hoc communication network to find nearby devices. If the inquiry indicates that the devices in the vicinity may include a middleware layer, the method may include creating a connection to each of the devices in the vicinity and verifying that each of the devices in the vicinity includes the middleware layer. It further comprises a step. For each of the nearby devices including the middleware layer, the method further includes executing the middleware layer to perform application and service discovery and to initiate applications and services.

In one embodiment, the mobile ad hoc communication network is a Bluetooth network. Performing the inquiry includes sending a Bluetooth inquiry command and receiving a Bluetooth inquiry result command including an indication that the device may include the middleware layer. Creating a connection to a device that may include the middleware layer includes sending a Bluetooth paging request message to the device and receiving a Bluetooth paging accept message. Confirming that the device includes the middleware layer includes sending a recognition request message to the device and receiving a recognition response message. Running the middleware layer to perform application and service discovery may include receiving a notification message from a device having a copy of a local application directory, and updating the combined application directory based on a comparison of the local and combined application directories. Storing and sending an update to the combined application directory to each device in the Bluetooth network. Moreover, executing the middleware layer includes launching a local application based on a reference in the combined application directory and connecting the local application to a counterpart application running on the device.

The accompanying drawings best illustrate details of device detection and service discovery systems for mobile ad hoc communication networks, both in structure and operation. Like reference numbers and designations in the drawings indicate like elements.

1 is a network diagram illustrating interaction of devices including a mobile ad hoc communication network, in accordance with an embodiment of the present invention.

FIG. 2A is a block diagram illustrating hardware and software components including server 110 shown in FIG. 1, in accordance with an embodiment of the invention.

FIG. 2B is a block diagram illustrating hardware and software components including the terminal 120 shown in FIG. 1, according to one embodiment of the invention.

3A is a flow diagram of one embodiment of a server 110 that performs device detection and service discovery for a mobile ad hoc communication network.

3B is a flowchart of one embodiment of a terminal 120 performing device detection and service discovery for a mobile ad hoc communication network.

4A is an exemplary block diagram of a data flow before a terminal enters a mobile ad hoc communication network.

4B shows an exemplary block diagram of FIG. 4A after a terminal enters a mobile ad hoc communication network.

5 is a flow diagram of one embodiment of a process illustrating a message flow during the establishment of a communication session between terminal X and terminal Y in a mobile ad hoc communication network.

1 is a network diagram illustrating interaction of devices including a mobile ad hoc communication network, in accordance with an embodiment of the present invention. In one embodiment, the mobile ad hoc communication network is a Bluetooth piconet including one master device and up to seven active slave devices. As shown in FIG. 1, the piconet 100 includes a server 110 and five terminal 120 instances. Server 110 maintains a network clock and is a communications manager for each instance of terminal 120. Server 110 typically initiates data exchange with an instance of terminal 120. Two instances of terminal 120 typically communicate through the server 110, but if two instances of terminal 120 communicate directly, one instance will assume the role of server or master and the other instance It will assume the role of client or slave.

Each device in the mobile ad hoc communication network will act as a terminal device or server device. The terminal device is a consumer of services for which a single user operates. Terminal devices include devices such as mobile phones or PDAs. The server is typically a stationary device and only creates services. The server device creates hotspots around them to use their services. "Hotspot" refers to a wireless coverage area provided by the server device for detecting devices and discovering services provided by applications hosted on the server. If the server device is not stationary, one of the terminal devices in the network will assume the role of an application directory server and perform device detection and service discovery functions for the other terminal devices in the network. The presently disclosed invention introduces two roles between such terminal devices, application directory servers and terminals, which act as terminals in device detection and service discovery. If there are still servers with hotspots, the servers typically operate as application directory servers, but device detection and service discovery are possible without such a stop server because one of the terminals will assume the application directory server obligation. .

The presently disclosed invention categorizes applications as server-based applications, terminal-to-terminal applications, foreground applications, background applications or generic application elements. Server-based applications require a server to create a service. Terminal-to-terminal applications require at least two terminal devices to implement a service without the presence of a server device. A foreground application is an application that resides in a terminal device that a user accesses through the user interface of the terminal device. Background applications are applications that reside on a terminal device that can be started without any intervention by the user. Generic application elements can be used as elements in standalone applications or other applications.

Applications can be further categorized as active, passive, new or rejected. An active application is a foreground or background application that resides on the terminal (ie, stored in memory). Passive applications reside on the terminal, but have not yet started. In another embodiment, the passive application is started but does not actively find other instances of the same application. The new application does not yet reside on the terminal, but may exist in the future. Rejected applications are marked as applications that do not reside on the terminal and must never reside on the terminal by the user. In another embodiment, the rejected application resided once on the terminal but was subsequently deleted and marked as rejected. In another embodiment, the rejected application never resides on the terminal, but is a type of application that the user has marked as rejected.

Service discovery in a mobile ad hoc communication network distinguishes between resident and unloaded applications. The resident application is stored in the terminal memory and loaded as a foreground application or a background application. An unloaded application has not yet been stored or loaded on the terminal but has been accepted by the user. Typically, if an application was previously used but overwritten to use space, the application is considered not loaded. Thus, starting an unloaded application may require first downloading the application.

Service discovery from the terminal device's perspective requires categorizing the state of the application as an active resident application, an active unloaded application, a passive resident application, a passively unloaded application, a rejected application or a new application. An active resident application is loaded on the terminal and finds peers, servers or clients. Applications that are not active loaded are still looking for these counterpart applications that are not loaded on the terminal but can be automatically downloaded if found to be of interest. Passive resident applications are loaded into the terminal but do not find counterpart applications. Applications that are not manually loaded are not loaded into the terminal but have been accepted once by the user. The rejected application is the application that the user has requested to exclude from the terminal device. The new application is not loaded on the terminal device, but the user may have seen the application on the previous server, for example.

FIG. 2A is a block diagram illustrating hardware and software components including server 110 shown in FIG. 1, in accordance with an embodiment of the invention. Server 110 is a general purpose wireless device. Bus 200 is a communication medium connecting keypad 201, display 202, central processing unit (CPU) 203, and radio frequency (RF) adapter 204 to memory 210. The RF adapter 204 is a mechanism that connects to the terminal 120 via a wireless link and facilitates network traffic between the server 110 and the terminal 120.

The CPU 203 performs the methods of the present invention by executing sequences of operational instructions, including each computer program residing in or operating on the memory 210. The memory 210 includes operating system software 211, application programs 212 and middleware software 220. Operating system software 211 controls keypad 201, display 202, RF adapter 204 and controls management of memory 210. The application programs 212 control the interactions between the user and the server 110. The middleware software 220 includes an application program interface (API) 221 that helps an application program running on the server 110 find a counterpart application running on the terminal 120 and communicate with the counterpart application. To quickly find each application, middleware software 220 also includes an application directory 230 for tracking the roles assigned by each application residing on each device within piconet 100.

FIG. 2B is a block diagram illustrating hardware and software components including the terminal 120 shown in FIG. 1, according to one embodiment of the invention. Terminal 120 is a general purpose wireless device. Bus 250 is a communication medium that connects keypad 251, display 252, central processing unit (CPU) 253, and radio frequency (RF) adapter 254 to memory 260. The RF adapter 254 is a mechanism that connects to the server 110 or other terminal 120 via a wireless link and facilitates network traffic between the server 110 and the terminal 120.

The CPU 253 performs the methods of the present invention by executing sequences of operational instructions, including each computer program residing in or operating on the memory 260. Memory 260 includes operating system software 261, application programs 262 and middleware software 270. Operating system software 261 controls keypad 251, display 252, RF adapter 254 and controls management of memory 260. The application programs 262 control the interactions between the user and the terminal 120. Middleware software 270 is an application program interface (API) 271 that helps an application program running on terminal 120 to find and communicate with a counterpart application running on server 110 or other terminal 120. ). To quickly find each application, middleware software 270 also includes an application directory 280 for tracking the roles assigned by each application residing on each device within piconet 100.

In one embodiment, the configurations of memory 210 and memory 260 are the same. In other embodiments, the configuration of memory 210 and memory 260 includes only the software needed to perform the essential tasks of server 110 and terminal 120, respectively. For example, if terminal 120 needs to receive a generic inquiry access code but does not need to send a generic inquiry access code message, only software that receives the message will be present in memory 260.

The application running on the terminal always finds the other application, that is, another instance of the same application that can communicate with the application. Each instance of the application assumes a specific role. Communication between the application and the counterpart application is meaningful only if the roles are complementary. For example, an application acting as a "client" can communicate with a counterpart application acting as a "server". Middleware software is a software layer with an API that negotiates communication between two applications to help the application find the counterpart application with the correct role. Thus, an application installed and activated on the terminal will query the API for a continuous stream of new counterpart applications of interest.

The new application is installed by "installer" applications that use middleware to find the counterparts and install the new application to the terminal's local storage device. The actual discovery and selection of new applications takes place at the application level. Initially, the installer application accesses counterpart applications in the servers, browses their available databases, allows the user to select the applications to install, and downloads and installs the new applications. Ie, client-server). Later, the corresponding function may be added to Radio Access Protocol (WAP) and Hypertext Markup Language (HTML) browsers.

Service discovery is considered a three-step process. First, new potential applications will be discovered and installation will be considered. Second, active installed applications begin to search for counterpart applications. Third, active installed applications begin to search for common resources such as printers (ie resource discovery). The presently disclosed invention relies on applications to perform resource discovery. Typically, a terminal application communicates with its counterpart application and uses local (ie server) resources. If an application uses private resources, the associated service discovery is implemented by the application in a standard (eg Bluetooth or Bluetooth / Java) manner that is not supported by the terminal middleware software.

3A is a flowchart of an embodiment of a server 110 that performs device detection and service discovery for a mobile ad hoc communication network. The process begins when server 110 sends a generic inquiry access code message to terminal 120 (step 300). Terminal 120 receives the message and transmits an acknowledgment message to server 110 (step 302). Server 110 accesses middleware software 220 to request a socket connection with terminal 120 (step 304). In response to the socket connection establishment, server 110 receives a message from terminal 120 that includes a local application directory listing all the applications residing locally on terminal 120. The server 110 compares the list of applications residing on the terminal 120 with the combined application directory residing on the server 110. Server 110 updates the combined application directory by adding each entry in the local application directory that does not appear in the combined application directory to the combined application directory (step 308). Server 110 transmits the portion of the updated combined application directory to each terminal 120 in piconet 100 (step 310). The portion may be changed for each terminal 120 and includes each entry in the combined application directory, which is a counterpart application for an application residing on terminal 120. In another embodiment, server 110 relies on terminal 120 to send the entire combined application directory to each terminal 120 in piconet 100 and to maintain associated entries. Instances of middleware software in terminal 120 and server 110 begin scheduling newly discovered counterpart application pairs for execution (step 312). In one embodiment, the scheduled applications use some other Bluetooth profile and protocol. In another embodiment, an application that is an installer application may suggest other applications that the user should download. Once server 110 downloads and starts a new application, the matching counterpart repeats and the new application becomes part of the middleware scheduling.

3B is a flowchart of an embodiment of a terminal 120 that performs device detection and service discovery for a mobile ad hoc communication network. The process begins when terminal 120 receives a general inquiry access code message from server 110 (step 320). Terminal 120 generates an acknowledgment message and transmits to server 110 (step 322). Terminal 120 transmits a message to server 110 that includes a local application directory including all applications residing locally on terminal 120 (step 324). The server 110 compares the list of applications residing on the terminal 120 with the combined application directory residing on the server 110. Server 110 updates the combined application directory by adding each entry in the local application directory that does not appear in the combined application directory to the combined application directory. Terminal 120 receives a portion of the updated combined application directory from server 110 (step 326). The server 110 customizes the portion for the terminal 120 to include each entry in the combined application directory, which is the counterpart application for the application residing on the terminal 120. In another embodiment, server 110 relies on terminal 120 to send the entire combined application directory to terminal 120 and to maintain associated entries. Instances of middleware software in terminal 120 and server 110 begin scheduling the newly found counterpart application pair for execution (step 328).

4A and 4B are exemplary block diagrams showing the contents of the application directory before and after the terminal X and terminal Y enter the mobile ad hoc communication network served by the server S; 4A shows the configuration of the application directory 404, the application directory 415, and the application directory 425 before the terminal X and the terminal Y enter the communication network managed by the server S. FIG. Application C 401 resides in server S memory 400 and accesses middleware software 403 through API 402. Middleware software 403 registers application C 401 in application directory 404 by adding a table entry indicating that application C resides on the local device (ie, server S) and assumes the role of server. Application A 411 and application B 412 reside in terminal X memory 410 and access middleware software 414 via API 413. Middleware software 414 is responsible for the fact that application A resides on the local device (i.e., terminal X) and assumes the role of a client, and that application B resides on the local device (i.e., terminal X) and plays an equivalent role. Application A 411 and application B 412 are registered in application directory 415 by adding a table entry for presentation. Application B 421 and application C 422 reside in terminal Y memory 420 and access middleware software 424 via API 423. Middleware software 424 is responsible for the fact that application B resides on the local device (i.e., terminal Y) and assumes an equivalent role, and that application C resides on the local device (i.e., terminal Y) and plays the role of a client. Application B 421 and application C 422 are registered in the application directory 425 by adding a table entry for presentation.

4B shows the configuration of the application directory 404, the application directory 415, and the application directory 425 after the terminal X and the terminal Y enter the communication network managed by the server S, the master device. Server S acts as an application directory server (ADS) and coordinates the registration of the applications present in each device within piconet 100. Server S adds a table entry to application directory 404 for each application present in the device on piconet 100. Thus, server S is responsible for application A of client role present in terminal X, application B of equal role present in terminal X, application B of equal role present in terminal Y and application C of client role present in terminal Y. Add an entry. Server S also updates the application directory 415 in terminal X and the application directory 425 in terminal Y with application registrations that may be of interest to terminal devices. As shown in FIG. 4B, both terminal X and terminal Y host an equivalent role Application B. FIG. Because there is likely to be an equal-to-equivalent communication session between application B on terminal X and application B on terminal Y, server S may make an entry in application directory 415 for an equivalent role application B present on terminal Y. Add an entry to the application directory 425 for an equivalent role Application B present in terminal X. Also, since there is likely to be a client-server communication session between application C on terminal Y and application C on server S, server S adds an entry to the application directory 425 for application C of the server role present at server S. do. Finally, there is no counterpart in piconet 100 for application A on terminal X.

As shown in Figures 4A and 4B, the disclosed data items for each entry in the middleware software application directory server may include a device identifier (e.g., "local", an address or other unique identifier), an application identifier (e.g. , Application name or other unique identifier) and the role of the application (eg, "client", "server", "equivalent", etc.). In another embodiment, the data items may be extended to include fields for the local applications (ie, device = "local") and fields for remote applications in other terminals or servers. Fields for the local applications include:

Name—Identifier of the application (eg provider name and data for comparing different versions and hardware variants);

My_Role-the role the application assumes on the local device;

Partner_Role—the role that the application assumes from interested parties (eg, equivalence, client and server are the most common roles);

Residency-Resident (installed and currently in memory), not loaded (once installed, not in memory but can be automatically redownloaded), rejected (new that it should ignore the application) Appear in the application installer) or new (the application is not installed or rejected);

● Status-running (communicating, now operating with its remote parties, but there can be only one or more applications that can use the communication at the same time), waiting (running but not doing any communication) ), Startable (active, if an equivalence matching the correct partner_role is found, the middleware software launches the application, and if necessary downloads the software first), complete (all counterpart applications are recognized) Or passive (the user must do something to launch the application);

Type-foreground (if the application terminates, the state will be passive) or background (if the application terminates, the state will be startable);

No loading-automatic (middleware can remove the code if the application terminates) or uninstall (the user must confirm the removal);

Icon-creates a visual image for the application for the user; And

Timeout-Set a timeout that the middleware software uses to detect when the application is in an unproductive software loop, for example.

Fields for the remote applications include:

Device-an address for establishing communication with the terminal or server storing the application instances;

Name-an identifier for the application; And

My_Role-The role the application plays on the remote device.

The client-server roles of the applications are independent of the roles of the device as a terminal device and an application directory server. Typically, a device acting as an application directory server hosts applications acting in the server role and the terminal devices act in the client role for the same application. In another embodiment, the two terminal devices each transmit a generic inquiry access code message and listen for a response. The terminal device receiving the response will first assume the role of server and proceed according to the procedure of FIG. 3A. The other terminal device receiving the inquiry message will assume the role of terminal and proceed according to FIG. 3b. Thus, the presently disclosed invention supports terminal-to-terminal scenarios (eg, one of the same handheld devices becomes ADS) and does not require any application directory servers.

5 is a flow diagram of an embodiment of a process illustrating a message flow during the establishment of a communication session between terminal X and terminal Y in a mobile ad hoc communication network. In one embodiment, terminal X and terminal Y are mobile devices such as terminal 120 shown in FIGS. 1 and 2B. In another embodiment, terminal X is a mobile device such as terminal 120 shown in FIGS. 1 and 2B and terminal Y is a mobile device such as server 110 shown in FIGS. 1 and 2A.

As shown in Fig. 5, the terminal X initiates communication by sending an inquiry request message to the mobile ad hoc communication network. Since terminal Y is a nearby device, terminal Y receives the inquiry request message and sends an inquiry response message to terminal X. In one embodiment, the inquiry request message is a Bluetooth inquiry command and the inquiry response message is a Bluetooth inquiry result command. In another embodiment, the inquiry request message is a Bluetooth inquiry command and the inquiry response message is a Bluetooth inquiry result command modified to indicate that the terminal sending the Bluetooth inquiry result command includes a middleware layer. In one embodiment, the middleware layer includes dedicated middleware software that provides advanced application and service discovery and execution. In one embodiment, the change to the Bluetooth inquiry result command is for class of device (CoD) parameters. For example, if the terminal sending the Bluetooth inquiry result command includes the middleware layer, the terminal will set at least the "ad hoc networking awareness bit" bit (bit 16) to on (1). Alternatively, if the terminal sending the Bluetooth inquiry result command includes the middleware layer, the terminal will set the "ad hoc networking awareness" bit (bit 16) to on (1) and "location information". Bit (bit 17) will be set to off (0). Alternatively, if the terminal sending the Bluetooth inquiry result command includes the middleware layer, the terminal will set the "ad hoc networking awareness" bit (bit 16) to on (1) and "telephony enabled". Will set bit (bit 22) to on (1). Alternatively, when the terminal sending the Bluetooth inquiry result command includes the middleware layer, the terminal sets the "ad hoc networking awareness" bit (bit 16) to on (1) and the "location information". Bit (bit 17) to off (0) and the "telephony enabled" bit (bit 22) to on (1). In another embodiment, if a dedicated display parameter indicating the presence of the middleware software is introduced into the Bluetooth inquiry result command specification, no change to the Bluetooth inquiry result command is necessary.

After the inquiry, as shown in FIG. 5, the terminal X transmits a paging request message to establish a connection to each nearby device indicating the possible possession of the middleware layer by the inquiry response message, such as the terminal Y. Can be generated. If terminal Y does not indicate a possible possession of the middleware layer (eg by setting the "ad hoc networking aware" bit (bit 16) to off (0)), no paging request message is sent and the communication The session is disconnected. After performing an inquiry that includes an indication that terminal Y probably includes a middleware layer, terminal X sends the paging request, as discussed above. Terminal Y receives the paging request message and optionally transmits a paging accept message to accept the connection request. In one embodiment, the paging request message is a Bluetooth connection creation command and the paging accept message is a Bluetooth connection request accept command.

Following connection to each nearby device, as shown in FIG. 5, terminal X sends a recognition request message to confirm that the nearby device such as terminal Y clearly includes the middleware layer. Terminal Y receives the recognition request message and sends a recognition response message to terminal X. In one embodiment, receipt of the recognition response message is confirmation that terminal Y includes the middleware layer. In another embodiment, the content of the recognition response message will indicate whether terminal Y includes the middleware layer. In one embodiment, the recognition request message and the recognition response message use the Bluetooth Service Discovery Protocol (SDP). If terminal Y does not include the middleware layer, the communication session may be disconnected.

Following confirmation that a nearby device, such as terminal Y, includes the middleware layer, as shown in FIG. 5, terminal X and terminal Y use the middleware layer to discover and initiate applications and services. In one embodiment, terminal X and terminal Y discover and initiate applications and services using the methods disclosed in the flowcharts shown in FIGS. 3A and 3B.

Although the disclosed embodiments describe a fully functional device detection and service discovery system and method for a mobile ad hoc communication network, the reader should understand that other equivalent embodiments exist. Since numerous changes and modifications will occur to those reviewing the disclosure, the device detection and service discovery system and method for the mobile ad hoc communication network is not limited to the precise configuration and operation described and disclosed. Accordingly, this disclosure intends that all suitable modifications and equivalents fall within the scope of the claims.

Claims (60)

A system for performing device detection and service discovery in a mobile ad hoc communication network, Memory devices; And A processor arranged to communicate with the memory device, The processor is configured to perform an inquiry of the mobile ad hoc communication network to find at least one nearby device, the inquiry including an indication that the at least one nearby device may include a middleware layer; , If the query includes an indication that the at least one nearby device may include the middleware layer: The processor, Generate a connection to the at least one nearby device, Determine whether the at least one nearby device includes the middleware layer, If the at least one nearby device includes the middleware layer: The processor is configured to execute the middleware layer to perform application and service discovery. 2. The method of claim 1, wherein the middleware layer comprises a service discovery protocol and at least one computer program, each computer program comprising at least one sequence of operational instructions for causing a network server or mobile terminal to execute the service discovery protocol. System comprising a. The system of claim 1, wherein if the at least one nearby device includes the middleware layer, the processor is further configured to execute the middleware layer to initiate applications and services. The processor of claim 1, wherein the processor is further configured to perform the inquiry. Further transmit a query request message to a communicable area within the mobile ad hoc communication network, And receive an inquiry response message from the at least one nearby device, wherein the inquiry response message includes the indication. The system of claim 4, wherein the inquiry request message is a Bluetooth inquiry command, and the inquiry response message is a Bluetooth inquiry result command. delete delete delete delete delete delete delete delete delete delete The system of claim 2, wherein the service discovery protocol provides a recognition request message which is a Bluetooth service discovery protocol request and a recognition response message which is a Bluetooth service discovery protocol response. The method of claim 1, wherein the middleware layer is executed to perform application and service discovery. The processor is further configured to receive a notification message from the at least one nearby device, the notification message comprising a local application directory stored at the at least one nearby device, The processor is further configured to store an update to the combined application directory, wherein the update is based on a comparison of the local application directory and the combined application directory, The processor is further configured to send an update message to the at least one nearby device, wherein the update message is an update portion of the combined application directory for updating the local application directory stored at the at least one nearby device. System comprising a. 18. The system of claim 17, wherein the processor is further configured to launch a local application based on a reference in the combined application directory, And connect the local application to a counterpart application running on the at least one nearby device. A method for performing device detection and service discovery in a mobile ad hoc communication network by a network server or a mobile terminal, the method comprising: Performing an inquiry of the mobile ad hoc communication network to find at least one nearby device, the query comprising an indication that the at least one nearby device may include a middleware layer; If the query includes an indication that the at least one nearby device may include the middleware layer: Creating a connection to the at least one nearby device; Confirming that the at least one nearby device includes the middleware layer; And If the at least one nearby device includes the middleware layer: Executing the middleware layer to perform application and service discovery. 20. The system of claim 19, wherein the middleware layer comprises a service discovery protocol and at least one computer program, each computer program comprising at least one sequence of operational instructions for causing a network server or mobile terminal to execute the service discovery protocol. Method comprising a. 20. The method of claim 19, wherein if the at least one nearby device includes the middleware layer, the method further comprises executing the middleware layer to launch applications and services. The method of claim 19, wherein performing the inquiry comprises: Sending an inquiry request message to a coverage area within the mobile ad hoc communication network; And Receiving an inquiry response message from the at least one nearby device, wherein the inquiry response message further comprises the indication. The method of claim 22, wherein the inquiry request message is a Bluetooth inquiry command, and the inquiry response message is a Bluetooth inquiry result command. 24. The method of claim 23, wherein setting at least one bit in the Bluetooth inquiry result command to at least one predetermined value is the indication. delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete A method of performing device detection and service discovery in a mobile ad hoc communication network, each device comprising at least one network node storing a local application directory, the method comprising: Selecting a directory server node from the at least one network node, the directory server node having a communicable zone and storing a combined application directory; Sending an inquiry message to a listening node entering the coverage area; Receiving a notification message from the listening node, the notification message including the local application directory stored at the listening node; Storing an update to the combined application directory in the directory server node based on a comparison of the local application directory and the combined application directory included in the notification message; And Sending an update message to each network node in communication with the mobile ad hoc communication network, wherein the update message is an update of the combined application directory for updating the local application directories of each node in the mobile ad hoc communication network. And including the portion. 54. The method of claim 53 wherein the combined application directory stores a reference to each application program stored at the at least one network node, and wherein the local application directory is stored in each application program stored at the network node associated with the local application directory. Storing a reference. 55. The method of claim 54, wherein the reference stored in the combined application directory and the reference stored in the local application directory include an application identifier, a network node identifier, and an application role. A method of performing device detection and service discovery in a mobile ad hoc communication network, each device comprising at least one network node storing a local application directory, the method comprising: Selecting a directory server node from the at least one network node, the directory server node having a communicable zone and storing a combined application directory; Receiving an inquiry message at a listening node entering the coverage area; Sending a notification message to the directory server node, the notification message including the local application directory stored at the listening node; And Receiving an update message from the directory server node, the update message including an update portion of the combined application directory for updating the local application directories of each node in the mobile ad hoc communication network; , And the directory server node stores an update to the combined application directory based on a comparison of the local application directory and the combined application directory included in the notification message. 57. The method of claim 56, wherein the combined application directory stores a reference to each application program stored at the at least one network node, and wherein the local application directory is stored in each application program stored at the network node associated with the local application directory. Storing a reference. 59. The method of claim 57, wherein the reference stored in the combined application directory and the reference stored in the local application directory include an application identifier, a network node identifier, and an application role. A computer-executable medium for performing device detection and service discovery in a mobile ad hoc communication network including at least one network node, each network node configured to communicate within a coverage area and to store a local application directory. A computer executable medium configured for Program code for storing in the storage means a combined application directory comprising local application directory information of each network node in communication with the mobile ad hoc communication network; Program code for sending, via a wireless transmitter, an inquiry message to a listening node entering the communicable area; Program code for receiving a notification message from the listening node at a wireless receiver, the notification message comprising the local application directory stored at the listening node; Program code for storing, in the storage means, an update to the combined application directory based on a comparison of the local application directory included in the notification message with the combined application directory; And Program code for sending, via the wireless transmitter, an update message to each network node communicating with the mobile ad hoc communication network, the update message updating the local application directories of each node in the mobile ad hoc communication network. And program code for including an update portion of the combined application directory for a computer. A computer executable medium for performing device detection and service discovery in a mobile ad hoc communication network comprising at least one network node, each network node configured to store a local application directory and from the at least one network node. A medium executable on a computer, configured to select a directory server node, the directory server node having a communicable zone and storing a combined application directory. Program code for storing the local application directory in storage means; Program code for receiving an inquiry message from the directory server node at a wireless receiver when entering a communicable area of the directory server node; Program code for transmitting a notification message to the directory server node at a wireless transmitter, the notification message comprising the local application directory stored in the storage means; And Program code for receiving an update message at the wireless receiver from the directory server node, the update message including program code including an update portion for updating the stored local application directory, The received update message is based on a comparison of the local application directory and the combined application directory included in the sent notification message.

Images