JP2006510124A - Device detection and service discovery system and method for mobile ad hoc communication networks - Google Patents

Abstract

A computer system, method and computer program product for performing device discovery and service discovery in a mobile ad hoc communication network. The method includes interrogating a mobile ad hoc communication network to discover nearby devices. If the query indicates that neighboring devices may include a middleware layer, this method further creates a connection to each neighboring device, and whether each neighboring device includes a middleware layer. Including the step of confirming whether or not. If each neighboring device includes a middleware layer, the method further includes executing the middleware layer to perform application and service discovery and initiating applications and services.

Description

The present invention generally relates to communication between devices connected to a wireless communication network. More particularly, the present invention relates to a system and method for performing device discovery and service discovery in a mobile ad hoc communication network.
This application refers to US patent application Ser. No. 10 / 284,135, filed Oct. 31, 2002, entitled “DEVICEDETECTION AND SERVICE DISCOVERY SYSTEM AND METHOD FOR A MOBILE AD HOC COMMUNICATIONS NETWORK”. Incorporate and claim its priority. In addition, this application is a US partial continuation patent application SS / XXX, entitled “DEVICEDETECTION AND SERVICE DISCOVERY SYSTEM AND METHOD FOR A MOBILE AD HOC COMMUNICATIONS NETWORK” filed with the US Patent and Trademark Office on September 16, 2003. YYY is also used as a reference and claims its priority. Further, this application is a US patent application No. SS / XXX, YYY entitled “MECHANISM FOR IMPROVING CONNECTION CONTROL IN PEER-TO-PEER AD-HOC NETWORKS” filed with the United States Patent and Trademark Office on September 16, 2003. It is related to and is used as a reference. This application is also filed in US Patent Application No. SS / XXX, YYY entitled "APPLICATION CONTROL IN PEER-TO-PEER AD-HOC COMMUNICATION NETWORKS" filed with the US Patent and Trademark Office on September 16, 2003. Related and incorporated by reference. The assignee is the same in the patent application, partially continuation patent application, and related patent application.

  The short range wireless system has a range of less than 100 meters, but can be connected to the Internet for long distance communication. Short range wireless systems include, but are not limited to, wireless personal area networks (PAN) and wireless local area networks (LAN). Wireless PANs use low cost, low power wireless devices with a typical range of 10 meters. An example of a wireless PAN technology is the Bluetooth standard. The Bluetooth standard operates in the 2.4 GHz Industrial, Scientific and Medical (ISM) band and is sufficient for use with 1 Mbps peak air link speeds and personal and portable electronic devices such as personal digital assistance and mobile phones. Gives low power consumption. A description of the Bluetooth communication protocol and device operation principle is published in “Bluetooth Special Interest Group, Specification of the Bluetooth Standard”, Version 1.0B, Volumes 1 and 2, December 1999. A wireless LAN costs more than a wireless PAN, but is long distance. An example of a wireless LAN technology is the IEEE 802.11 wireless LAN standard and the HIPERLAN standard. The HIPERLAN standard operates in the unlicensed National Information Infrastructure (U-NII) band of 5 GHz and provides peak air link speeds of 10 to 100 Mbps.

  An ad hoc network is a short range wireless system comprised of an arbitrary collection of wireless devices that are physically close enough to exchange information. Ad hoc networks are quickly configured by wireless devices entering and leaving the network as they enter and exit other wireless devices. An ad hoc network may also include one or more access points, i.e., a fixed wireless device that operates as a standalone server or as a gateway connection to another network.

  In the future, the Bluetooth standard will probably support multiple piconet interconnections to form multi-hop ad hoc networks or scatter nets. In the scatter net, the connection device transfers traffic between different piconets. The connection device acts as a master device in one piconet, but acts as a slave device or master device in another piconet. Thus, the connecting device joins the piconet, including the scatternet, by adapting the timing and hop sequence to each piconet and possibly switching the service role from the master device to the slave device.

  Bluetooth devices include, but are not limited to, mobile phones, personal or laptop computers, radio frequency identification tags, and personal electronic devices such as personal digital assistants (PDAs), pagers or portable computer devices. Each Bluetooth device has an application and operating program designed to discover other Bluetooth devices when entering or leaving the network coverage. 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 devices use their links and service discovery protocols to discover services offered by other Bluetooth devices and how to connect to those services.

  Conventional systems follow a similar behavior pattern for service discovery protocols. A service description generated using the description language and the appropriate vocabulary is advertised or used for query matching. One conventional system advertises a service description by pushing the description into the directory and requesting the advertiser to find the directory. Other conventional systems advertise service descriptions by making the descriptions available for peer-to-peer discovery. A client device that needs to find a service description constructs a query using the query language and the matching vocabulary, and delivers the query using either a query protocol or a distributed query processing server.

  The service discovery protocol in conventional systems requires sending and responding to inquiry messages. If no other device exists, an inquiry message is sent unnecessarily. In order to avoid excessive power consumption, conventional systems typically require a human user to manually initiate device detection when another such device is present. For example, a human user manually detects the device when connecting a cellular phone to a laptop computer to handle data communication or when connecting a wireless handset to a laptop computer to deliver digital audio. Start. These conventional systems rely on three assumptions. First, the application can start freely as its existence is guaranteed. Second, the application performs service discovery when it first needs service. Third, the composition of the network does not change during the lifetime of the application.

  Thus, device detection that avoids excessive power consumption and allows an application residing on one device to automatically find a corresponding application or other resource residing on any other device in the ad hoc communication network. And a service discovery protocol is desired. This protocol does not require a human user to manually initiate device discovery to find a compatible application or other resource. Furthermore, this protocol accepts network environments where the presence of a particular device is not guaranteed and the composition of the network is dynamic due to the frequent entry and exit of the device. The present invention is directed to such a need.

  A computer system, method, and computer program product for performing device discovery and service discovery in a mobile ad hoc communication network are provided. The method includes interrogating a mobile ad hoc communication network to discover nearby devices. If the query indicates that neighboring devices may include a middleware layer, the method further includes forming a connection to each neighboring device, and each neighboring device has a middleware layer. And a step of confirming whether or not For each neighboring device that includes a middleware layer, the method further includes executing the middleware layer to perform application and service discovery and initiating the application and service.

  In one embodiment, the mobile ad hoc communication network is a Bluetooth network. The step of querying includes transmitting a Bluetooth query command and receiving a Bluetooth query result command including an indication that the device includes a middleware layer. Forming a connection to a device that includes the middleware layer includes sending a blue-to-spacing request message to the device and receiving a blue-to-spacing acceptance message. Confirming that the device includes the middleware layer includes sending a confirmation request message to the device and receiving an acknowledgment message. The step of executing the middleware layer to perform application and service discovery receives notification messages from the device along with a copy of the local application directory, stores updates to the combined application directory based on a comparison of the local and combined application directories, And sending updates to the combined application directory to each device in the Bluetooth network. Further, the step of executing the middleware layer includes initiating a local application based on the reference in the combined application directory and connecting the local application to a corresponding application executed on the device.

  The accompanying drawings best illustrate the details of the device detection and service discovery system and method for both mobile ad hoc communication networks, both in its structure and operation. In these drawings, similar elements are indicated with the same reference numerals.

  FIG. 1 is a network diagram showing the interaction of devices constituting a mobile ad hoc communication network according to an embodiment of the present invention. In one embodiment, the mobile ad hoc communication network is a blue-to-piconet with one master device and up to seven active slave devices. As shown in FIG. 1, the piconet 100 includes a server 110 and five instances of a terminal 120. Server 110 maintains a network clock and is a communication 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 via server 110, but if two instances of terminal 120 communicate directly, one instance acts as a server or master and the other instance is a client. That is, it plays the role of a slave.

  Each device in the mobile ad hoc communication network serves as either a terminal device or a server device. A terminal device is a consumer of services operated by a single user. Terminal devices include devices such as mobile phones or PDAs. A server is usually a fixed device that only generates services. Server devices form hot spots around them to use their services. A “hot spot” refers to a wireless coverage area provided by a server device to detect the device and discover services offered by an application hosted on the server. If the server device is not fixed, one of the terminal devices in the network acts as an application directory server and performs device discovery and service discovery functions for the remaining terminal devices in the network. The present invention introduces two roles between such terminal devices, an application directory server and a terminal, which serves the terminal in device discovery and service discovery. Where there is a fixed server with a hotspot, the server usually acts as an application directory server, but since one of the terminals fulfills the obligation of the application directory server, device discovery and service discovery is such a fixed server. It is possible even without.

  The present invention classifies applications as server-based applications, terminal-to-terminal applications, foreground applications, background applications, or general application components. Server-based applications require a server to generate a service. A terminal-to-terminal application requires that at least two terminal devices perform a service in the absence of a server device. The foreground application is an application that is resident in the terminal device, and is an application that the user accesses through the user interface of the terminal device. The background application is an application that is resident in the terminal device and can be started without user intervention. A general application component can be used as a stand-alone application or as a component of another application.

  Applications may be further classified as active, passive, new or rejected. An active application is a foreground or background application that resides in a terminal (ie, stored in memory). Passive applications reside in the terminal but have not yet been started. In another embodiment, a passive application is started but does not actively look for other instances of the same application. New applications do not yet reside in the terminal, but may reside in the future. The reject application is not resident in the terminal and is marked by the user as an application that should never reside in the terminal. In another embodiment, the rejection application was once resident at the terminal but has since been deleted and marked as rejected. In yet another embodiment, the rejection application is a form of application that never resides in the terminal and that the user has marked as rejection.

  Service discovery in mobile ad hoc communication networks distinguishes between resident and unloaded applications. The resident application is stored in the terminal's memory and loaded as either a foreground application or a background application. The unload application is not stored or loaded into the terminal, but is accepted by the user. Typically, an application is considered unloaded when it has been used before but has been overwritten to take advantage of space. Therefore, to start an unload application, it is necessary to download the application first.

  To discover services from the terminal device perspective, classify the application state as either an active resident application, an active unload application, a passive resident application, a passive unload application, a rejection application, or a new application It is necessary to. The active resident application is loaded into the terminal and searches for peers, servers or clients. An active unload application searches for a corresponding application that is not loaded into the terminal but can be automatically downloaded if it is found to be of interest. Passive resident applications are loaded into the terminal but do not search for compatible applications. Passive unload applications are not loaded into the terminal but are accepted by the user. The rejection application is an application requested by the user to be excluded from the terminal device. The new application is not loaded on the terminal device, but the user may be watching the application at an initial service, for example.

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

  The CPU 203 performs the method of the present invention by executing a series of operating instructions that make up each computer program that resides in or operates in the memory 210. The memory 210 includes operating system software 211, application programs 212, and middleware software 220. The operating system software 211 controls management of the keypad 201, display 202, RF adapter 204, and memory 210. Application program 212 controls the interaction between the user and server 110. The middleware software 220 includes an application program interface (API) 221 that helps an application program running on the server 110 to find and communicate with a corresponding application running on the terminal 120. In order to quickly search for each application, the middleware software 220 also includes an application directory 230 for tracking the role played by each application residing on each device of the piconet 100.

  2B is a block diagram illustrating the hardware and software components that make up the terminal 120 shown in FIG. 1 according to one embodiment of the invention. Terminal 120 is a general purpose wireless device. The bus 250 is a communication medium that connects the keypad 251, the display 252, the CPU 253, and the RF adapter 254 to the memory 260. The RF adapter 254 is a mechanism that is connected to the server 110 or another terminal 120 via a wireless link to facilitate network traffic between the server 110 and the terminal 120.

  The CPU 253 performs the method of the present invention by executing a series of operating instructions that make up each computer program that resides in or works in the memory 260. The memory 260 includes operating system software 261, application programs 262, and middleware software 270. The operating system software 261 controls the management of the keypad 251, the display 252, the RF adapter 254, and the memory 260. Application program 262 controls the interaction between the user and terminal 120. The middleware software 270 includes an API 271 that helps an application program running on the terminal 120 find and communicate with a corresponding application running on the server 110 or another terminal 120. To quickly search for each application, the middleware software 270 also includes an application directory 280 for tracking the role played by each application residing on each device of the piconet 100.

  In one embodiment, the configurations of the memory 210 and the memory 260 are the same. In another embodiment, the configuration of memory 210 and memory 260 includes only the software necessary to perform the essential tasks of server 110 and terminal 120, respectively. For example, if terminal 120 needs to receive a general query access code but does not need to send a general query access code message, only the software that receives this message resides in memory 260. .

  An application running on the terminal always searches for its corresponding application, ie another instance of the same application that can communicate with the application. Each instance of the application plays a specific role. Communication between an application and its corresponding application is only meaningful if their roles are complementary. For example, an application acting as a “client” can communicate with a corresponding application acting as a “server”. Middleware software is a software layer with an API that negotiates communication between two applications to help find a corresponding application with the correct role. Thus, an application installed and activated in the terminal queries the API for a continuous stream of new corresponding applications of interest.

  The new application is installed by an “installer” application that uses middleware to find its counterpart and install the new application in the terminal's local storage. Actually finding and selecting a new application is done at the application level. Initially, the installer application accesses the corresponding application in the server, browses their available application database, allows the user to pick up the application to be installed, and downloads and installs the new application A dedicated “browser-supplier” (ie, client-server) application. Later, corresponding functions may be added to Wireless Access Protocol (WAP) and Hypertext Markup Language (HTML) browsers.

  Service discovery is considered a three step process. First, new potential applications are found and considered for installation. Secondly, the installed active application initiates a search for its corresponding application. Third, the installed active application initiates a search for common resources such as printers (ie resource discovery). The present invention relies on an application to perform resource discovery. Typically, a terminal application communicates with its corresponding application and uses local (ie server) resources. If the application uses private resources, the associated service discovery is performed by the application in a standard way that is not supported by the terminal middleware software (eg, Bluetooth or Bluetooth / Java). .

  FIG. 3A is a flowchart illustrating an embodiment of a server 110 that performs device discovery and service discovery for a mobile ad hoc communication network. This process begins when server 110 sends a general query access code message to terminal 120 (step 300). Terminal 120 receives the message and sends an acknowledgment message to server 110 (step 302). The server 110 accesses the middleware software 220 and requests a socket connection with the terminal 120 (step 304). In response to establishing the socket connection, server 110 receives a message from terminal 120 that includes a local application directory that lists all applications that reside locally at terminal 110 (step 306). Server 110 compares the list of applications residing on terminal 120 with the combined application directory residing on server 110. Server 110 updates the combined application directory by adding each entry of the local application directory that does not appear in the combined application directory to the combined application directory (step 308). Server 110 sends a portion of the updated combined application directory to each terminal 120 of piconet 100 (step 310). This portion may be different for each terminal 120 and includes each entry in the combined application directory that is a corresponding application for an application resident at terminal 120. In another embodiment, the server 110 sends the full combined application directory to each terminal 120 of the piconet 100 and maintains the entry based on the terminal 120. The middleware software instances at the terminal 120 and the server 110 begin to schedule execution of newly found corresponding application pairs (step 312). In one embodiment, the scheduled application uses other Bluetooth profiles and protocols. In another embodiment, an application that is an installer application may suggest to the user other applications that the user must download. When server 110 downloads and starts a new application, the matching of its counterparts is repeated, and the new application becomes part of the middleware schedule.

  FIG. 3B is a flowchart illustrating an embodiment of a terminal 120 that performs device discovery and service discovery for a mobile ad hoc communication network. This process begins when terminal 120 receives a general query access code message from server 110 (step 320). The terminal 120 generates an acknowledgment message and sends it to the server 110 (step 322). Terminal 120 sends a message to server 110 that includes a local application directory that includes all applications that reside locally at this terminal (step 324). Server 110 compares the list of applications residing on terminal 120 with the combined application directory residing on 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). Server 110 customizes a portion of terminal 120 to include each entry in the combined application directory that is a corresponding application for an application that resides at terminal 120. In another embodiment, server 110 sends the entire combined application directory to terminal 120 and maintains the entry based on terminal 120. The middleware software instances at the terminal 120 and the server 110 begin to schedule execution of newly found corresponding application pairs (step 328).

  4A and 4B are block diagrams illustrating the contents of the application directory before and after terminal X and terminal Y enter the mobile ad hoc communication network served by server S. FIG. FIG. 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 as the master device. Application C 401 resides in memory 400 of server S and accesses middleware software 403 via API 402. Middleware software 403 registers application C 401 in application directory 404 by adding a table entry to indicate that application C resides on the local device (ie, server S) and acts as a server. Application A 411 and application B 412 are resident in the memory 410 of the terminal X and access the middleware software 414 via the API 413. Middleware software 414 indicates that application A resides on the local device (ie, terminal X) and acts as a client, and application B resides on the local device (ie, terminal X) and acts as a peer. The application A411 and the application B412 are registered in the application directory 415 by adding a table entry. Application B 421 and application C 422 reside in terminal Y memory 420 and access middleware software 424 via API 423. Middleware software 424 indicates that application B resides on the local device (ie, terminal Y) and acts as a peer, and application C resides on the local device (ie, terminal Y) and acts as a client. The application B421 and the application C422 are registered in the application directory 425 by adding a table entry.

  FIG. 4B shows a configuration of the application directory 404, the application directory 415, and the application directory 425 after the terminal X and the terminal Y have entered the communication network managed by the server S that is the master device. Server S acts as an application directory server (ADS) and mediates registration of applications that reside on each device in piconet 100. The server S adds a table entry to the application directory 404 for each application that resides on the piconet 100 device. Accordingly, the server S is connected to application A residing in terminal X in the client role, application B residing in terminal X in the peer role, application B residing in terminal Y in the peer role, and terminal Y in the client role. Add an entry for resident application C. The server S also updates the application directory 415 at terminal X and the application directory 425 at terminal Y with application registrations that are of interest to these terminal devices. As shown in FIG. 4B, both terminal X and terminal Y host application B in the role of peer. Since there is probably a peer-to-peer communication session between application B at terminal X and application B at terminal Y, server S adds an entry to application directory 415 for application B residing at terminal Y in the peer role. At the same time, an entry is added to the application directory 425 for the application B residing in the terminal X of the peer role. Also, since there is likely a client-to-server communication session between application C at terminal Y and application C at server S, server S enters an application directory 425 for application C that resides on server S in the server role. Add Finally, there is no corresponding part in the piconet 100 for the application A of the terminal X.

  As shown in FIGS. 4A and 4B, the data items disclosed herein as each entry in the middleware software application directory server include a device identifier (eg, “local”, address, or other unique identifier) and an application identifier ( Application name or other unique identifier) and the role of the application (eg, “client”, “server”, “peer”, etc.). In another embodiment, the data item can be expanded to include fields for local applications (ie, device = “local”), and fields for other terminal or server remote applications. The fields for the local application include:

-Name: identifier for the application (eg, the name of the supplier, and data comparing different versions and hardware variants);
-My_role (your role): the role that the application plays on the local device;
-Partner_role (partner role): the role that the application plays from the counterpart of interest (eg, peer, client and server are the most common roles);
Residency: RESIDENT (installed and currently in memory), UNLOADED (once installed but not currently in memory and can be automatically re-downloaded), REJECTED (application should be ignored) Instruct the new application installer to be), or NEW (the application will not be installed or rejected);
-State: RUNNING (has communication and is currently working with its remote counterpart, but there is only one or more applications that can use communication at a time), WAITING (running, but what No communication), STARTABLE (middleware software starts this application if it finds a peer that is active and matches the correct Partner_role, downloads the software first if necessary), COMPLETE ( All known applications are known) or PASSIVE (the user has to do something to start the application);

-Type (form): FOREGROUND (the state is PASSIVE when the application is terminated), or BACKGROUND (the state is STARTABLE when the application is terminated);
-Unload: AUTOMATIC (middleware can remove code when application exits), or UNINSTALL (user must confirm removal);
-Icon: generates a visual image of the application for the user; and-Timeout: sets the time limit used by the middleware software to detect when the application is in a non-productive software loop, for example. To do.

The fields for the remote application include:
Device: an address for establishing communication with a terminal or server storing application instances;
-Name (name): identifier for the application; and-My_role (your role): the role that the application plays in the remote device.

  The client-server role of the application is independent of the role of the device as a terminal device and application directory server. Typically, a device that acts as an application directory server hosts an application that works in a server role, and a terminal device works in a client role for the same application. In another embodiment, each of the two terminal devices sends a general inquiry access code message and listens for a response. The terminal device that receives the response initially acts as a server and proceeds based on the procedure of FIG. 3A. Another terminal device that receives the inquiry message acts as a terminal and proceeds according to FIG. 3B. Thus, the present invention supports terminal-to-terminal scenarios (eg, one of the same handheld devices automatically becomes ADS) and does not require a given application directory server.

  FIG. 5 is a flowchart of an embodiment of a process illustrating message flow during establishing 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 starts communication by transmitting 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 query request message is a Bluetooth query command and the query response message is a Bluetooth query result command. In another embodiment, the query request message is a Bluetooth query command, and the query response message is a Bluetooth query result command modified to indicate that the terminal sending the Bluetooth query 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 query result command is to a device class (CoD) parameter. For example, if the terminal sending the Bluetooth query result command includes a middleware layer, the terminal sets at least the “ad hoc networking aware” bit (bit 16) to on (1). Alternatively, if the terminal sending the Bluetooth query result command includes a middleware layer, the terminal turns on the “ad hoc network notice” bit (bit 16) and the “location information” bit (bit 17). Is set to off (0). Alternatively, if the terminal sending the Bluetooth query result command includes a middleware layer, the terminal turns on the “ad hoc network notice” bit (bit 16) and sets the “telephony” bit ( Bit 22) is set on (1). Alternatively, if the terminal sending the Bluetooth query result command includes a middleware layer, the terminal turns on the “ad hoc network notice” bit (bit 16) and turns on the “location information” bit (bit 17). Is set to off (0) and the “telephone ready” bit (bit 22) is set to on (1). In yet another embodiment, if a dedicated instruction parameter for indicating the presence of middleware software is introduced in the Bluetooth query result command specification, no change to the Bluetooth query result command is required.

  Following the query, as shown in FIG. 5, terminal X connects to each neighboring device, eg, terminal Y, by sending a paging request message to indicate the possible ownership of the middleware layer in the query response message. Can be formed. If terminal Y does not indicate a possible ownership of the middleware layer (eg, by setting the “ad hoc network aware” bit (bit 16) to off (0)), the paging request message is not sent, The communication session is disconnected. After making a query that includes an indication that terminal Y probably includes a middleware layer, terminal X sends a paging message request as described above. Terminal Y receives the paging request message and optionally sends a paging acceptance message to accept the connection request. In one embodiment, the paging request message is a Bluetooth connection establishment command and the paging acceptance message is a Bluetooth connection acceptance request command.

  Subsequent to the connection to each neighboring device, as shown in FIG. 5, terminal X transmits a confirmation request message for confirming whether the neighboring device such as terminal Y clearly includes the middleware layer. Terminal Y receives the confirmation request message and sends an acknowledgment message to terminal X. In one embodiment, receipt of the acknowledgment message is an acknowledgment that terminal Y includes a middleware layer. In another embodiment, the content of the acknowledgment message indicates that terminal Y includes a middleware layer. In one embodiment, the confirmation request message and the acknowledgment message use Bluetooth Service Discovery Protocol (SDP). If terminal Y does not include the middleware layer, the communication session can be disconnected.

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

  Although the above embodiments have described a fully functional device detection and service discovery system and method for mobile ad hoc communication networks, it will be appreciated that other equivalent embodiments exist. Since many changes and modifications will be apparent to those skilled in the art, the device detection and service discovery system and method for mobile ad hoc communication networks is illustrated in the exact structure and operation disclosed and disclosed herein. It is not limited to. Accordingly, this disclosure also contemplates all suitable modifications and equivalents included within the scope of the claims.

FIG. 2 is a network diagram showing the interaction of devices constituting a mobile ad hoc communication network according to an embodiment of the present invention. FIG. 2 is a block diagram showing hardware and software components constituting the server 110 shown in FIG. 1 according to an embodiment of the present invention. FIG. 2 is a block diagram illustrating hardware and software components constituting the terminal 120 shown in FIG. 1 according to an embodiment of the present invention. FIG. 6 is a flowchart illustrating an embodiment of a server 110 that performs device discovery and service discovery for a mobile ad hoc communication network. FIG. 4 is a flow chart illustrating an embodiment of a terminal 120 that performs device discovery and service discovery for a mobile ad hoc communication network. FIG. 2 is a block diagram illustrating a data flow before a terminal enters a mobile ad hoc communication network. FIG. 4B is a block diagram of FIG. 4A after the terminal has entered the mobile ad hoc communication network. FIG. 3 is a flowchart of an embodiment of a process showing message flow during establishing a communication session between terminal X and terminal Y in a mobile ad hoc communication network.

Claims (13)

In a system for performing device detection and service discovery in a mobile ad hoc communication network,
A memory device;
A processor arranged to communicate with the memory device;
The processor comprises:
Querying the mobile ad hoc communication network to discover at least one neighboring device, the query comprising an indication that the at least one neighboring device may include a middleware layer;
When the query includes an indication that the at least one neighboring device may include a middleware layer, the connection forms a connection to the at least one neighboring device, and the at least one neighboring device includes a middleware layer. And if the at least one neighboring device includes a middleware layer, execute the middleware layer to perform application and service discovery;
A system configured like this.   The system of claim 1, wherein the middleware layer includes a service discovery protocol and at least one computer program, each computer program including at least one sequence of operating instructions.   The system of claim 1, wherein when the at least one neighboring device includes a middleware layer, the processor is further configured to execute the middleware layer to initiate applications and services. In order to make the query, the processor further comprises:
Sending an inquiry request message to a coverage area in the mobile ad hoc communication network, and receiving an inquiry response message including the indication from the at least one neighboring device;
The system according to claim 1 configured as described above.   The system according to claim 4, wherein the inquiry request message is a Bluetooth inquiry command, and the inquiry response message is a Bluetooth inquiry result command. In order to execute the middleware layer and perform application and service discovery, the processor further comprises:
Receiving a notification message from the at least one neighboring device, the notification message comprising a local application directory stored in the at least one neighboring device;
Storing an update to the combined application directory, the update being based on a comparison of the local application directory and the combined application directory, and sending an update message to the at least one neighboring device, the update message being The system of claim 1, comprising an update portion of the combined application directory to update a local application directory stored on at least one nearby device. The processor further includes:
Initiating a local application based on a reference in the combined application directory, and connecting the local application to a corresponding application running on the at least one nearby device;
The system according to claim 6 configured as described above. In a method for performing device discovery and service discovery in a mobile ad hoc communication network,
Querying the mobile ad hoc communication network to discover at least one neighboring device, the query including an indication that the at least one neighboring device may include a middleware layer Steps,
When the query includes an indication that the at least one neighboring device may include a middleware layer, the connection forms a connection to the at least one neighboring device, and the at least one neighboring device includes a middleware layer. Steps to check if it contains,
When the at least one neighboring device includes a middleware layer, executing the middleware layer to perform application and service discovery;
With a method.   9. The method of claim 8, wherein the middleware layer includes a service discovery protocol and at least one computer program, each computer program including at least one series of operational instructions.   9. The method of claim 8, further comprising executing the middleware layer to initiate applications and services when the at least one neighboring device includes a middleware layer. The step of making the inquiry further comprises:
Sending an inquiry request message to a coverage area in the mobile ad hoc communication network;
Receiving an inquiry response message including the indication from the at least one neighboring device;
The method of claim 8 comprising:   The method of claim 11, wherein the query request message is a Bluetooth query command and the query response message is a Bluetooth query result command.   The method of claim 12, further comprising setting at least one bit in the Bluetooth query result command to at least one predetermined value in the indication.

Images