KR20050050457A - A communication method, a communication device and the recording medium thereof in ad-hoc network environment - Google Patents

Abstract

According to the present invention, a communication method under an ad-hoc network environment, a communication apparatus, and a recording medium on which a data structure of a message used for communication under an ad-hoc network environment are recorded. The communication method according to the present invention comprises the steps of: transmitting a routing request in which a query for service availability is inserted to a destination node; and receiving a routing response in which a response to service availability is inserted from the destination node; It includes. According to the configuration of the present invention, it is possible to find a communication node conveniently and quickly in an ad-hoc network environment using a Bluetooth device.

Description

A method, communication device and recording medium in ad-hoc network environment

The present invention relates to a communication method and a communication apparatus, and more particularly, to a communication method under an ad-hoc network environment, a communication device and a data structure of a message used for communication under an ad-hoc network environment. A recorded recording medium.

An ad-hoc network is a temporary network consisting of only mobile hosts without the help of an existing wired network infrastructure or central management system.

Bluetooth is a short-range wireless access technology that wirelessly connects various digital home appliances as well as information and communication devices such as computers, printers, mobile phones, and PDAs in homes and offices without a physical cable connection. Bluetooth is a standard for constructing an ad-hoc network using near field communication. However, since the Bluetooth standard does not consider the routing of ad-hoc networks, it is very difficult to construct an ad-hoc network using Bluetooth. For this reason, Bluetooth is not active in ad-hoc network environment. However, since Bluetooth has many advantages in short-range wireless, the ad hoc network environment using Bluetooth is becoming indispensable in the trend that many Bluetooth devices are attached to mobile terminals such as PDAs and mobile phones. Under these circumstances, it is natural that the demand for ad-hoc networks using Bluetooth will increase. However, as described above, current methods have difficulty in constructing and using an ad-hoc network.

In the Bluetooth 1.1 standard specification, the routing path setting is not defined when configuring a Bluetooth ad-hoc network extended to a scatternet. For this reason, many researches have been conducted, but most of them apply the existing routing protocol to Bluetooth. A communication process in an ad-hoc network using a Bluetooth standard common to existing studies is shown in FIG. 1.

You can see the routing path setup and the SDP (Sevice Discovery Protocol) service discovery query. That is, in order to perform ad hoc network communication using Bluetooth, first, a communication path between a Bluetooth device A as a data source and a Bluetooth device B as a data destination must be set. After that, device A, the source node, queries the device B, the destination node, to find out whether it can provide the desired service. If device B provides the desired service, communication can occur between the two.

Now, referring to FIG. 1, a process for communication between a device A 10 as a source node and a device B 30 as a destination node in an ad-hoc network configured using a Bluetooth device according to the related art will be described in detail. .

First, the source node 10 that wants to send data broadcasts a routing request to all nodes connected to it in order to know the path to the destination node 30 as the destination of the data (S101). When the intermediate node 20 receives the broadcast request thus broadcasted, the intermediate node 20 broadcasts the routing request to the nodes connected to it again when it is not the destination node 30 (S102).

When the routing request arrives to the destination node 30 in this way, the destination node 30 receiving the routing request sends a routing reply in response (S103). The intermediate nodes 20 that have received this routing response relay the routing response back to the source node 10 (S104).

In this way, when the source node 10 receives the routing response, a routing path from the source node 10 to the destination node 30 is established, and information about the routing path is stored in the routing table. However, the setting of the routing table does not mean that communication between the source node 10 and the destination 30 is possible. Bluetooth provides a service-based connection, so there must be a service that can be shared between the two devices. For example, if source node 10 finds the OBEXFileTransfer service class, destination node 30 should specify the OBEXFileTransfer service class in the SDP service database.

Therefore, the source node 10 queries the destination node whether it can provide the OBEXFileTransfer service class using the service query command provided by the SDP. First, the source node 10 sends an SDP request to the intermediate node 20 using the routing information stored in the routing table (S105), and the intermediate node 20 receiving the SDP request is sent to the destination node 30. It relays (S106).

The destination node 30 transmits an SDP response indicating whether the service can be provided to the intermediate node 20 (S107), and the intermediate node 20 receiving the notification informs the source node 10 of the SDP response (see FIG. S108).

If the destination node 30 can provide a service, communication between the two is possible using the OBEXFileTransfer service (S109). Otherwise, the source node 10 must find another device that can communicate. As described above, in the communication process according to the related art, a process of establishing a routing path and a process of querying an SDP service are performed separately.

The problem of the prior art can be explained as follows. Although Bluetooth is a standard created for short-range wireless communication and ad-hoc networks, due to the lack of consideration of routing protocols on ad-hoc networks in the Bluetooth standard, it is necessary to use Bluetooth in an ad-hoc network environment. As described in the prior art operation of FIG. 2, first, a routing path is established at the routing application layer, and then two processes of checking a service available at the service discovery protocol (SDP) layer are required.

In other words, after setting the routing path, SDP service query should be made to provide the desired service again. However, if destination node 30 cannot provide the desired service at source node 10, source node 10 should look for another destination node 30, in which case if source node 10 Failure to find a destination node that provides the desired service will inevitably result in significant time delay.

The present invention is to solve the above problems and to find a communication node conveniently and quickly in the ad-hoc network environment using Bluetooth, the communication device and the message of the message used in the communication under the ad-hoc network environment It is an object to provide a recording medium in which a data structure is recorded.

One feature of the present invention for solving the above problems is in a communication method under an ad-hoc network environment, a) transmitting a routing request inserted with a query whether a service can be provided to a destination node; And b) receiving from the destination node a routing response in which a response as to whether service can be provided is inserted.

Here, preferably, step a) includes the step of transmitting the RREQ message of the AODV protocol inserted with the query information on whether the service can be provided.

Also, preferably, the step b) includes transmitting a RREP message of the AODV protocol in which response information on whether service can be provided is inserted.

In addition, another aspect of the present invention, in a communication device in an ad-hoc network environment, and transmits a routing request inserted with a query for whether a service can be provided to a destination node, and whether or not the service can be provided from the destination node. It includes a routing agent for receiving a routing response inserted with a response to, and a routing table for storing routing information.

Here, preferably, the routing table further stores service information available by the routing agent.

In addition, the communication device may include a communication device operating in a Bluetooth environment.

Another feature of the present invention is a recording medium in which a data structure of a message used for communication in an ad-hoc network environment is recorded, wherein the data structure is a routing in which query information about service availability is inserted. It includes an identifier indicating that it is a request message, address information of the destination device, address information of the source device, and information indicating a query for service availability.

Here, preferably, the identifier is recorded in the PDUID area of the SDP layer format header of the Bluetooth standard.

Also preferably, the message uses the data structure of the RREQ message of the AODV protocol.

Another aspect of the present invention provides a recording medium in which a data structure of a message used for communication in an ad-hoc network environment is recorded, wherein the data structure includes routing in which response information about service availability is inserted. It includes an identifier indicating that it is a response message, address information of the destination device, address information of the source device, and information indicating a response to whether service can be provided.

Here, preferably, the identifier is recorded in the PDUID area of the SDP layer format header of the Bluetooth standard.

Also preferably, the message uses the data structure of the RREP message of the AODV protocol.

Hereinafter, with reference to the accompanying drawings will be described in detail the present invention.

3 is a flowchart illustrating a communication process between two nodes in an ad-hoc network according to the present invention.

According to the present invention, the source node sends a routing request with the SDP request to the destination node, and the destination node sends a routing response with the SDP response to the source node. That is, the source node can find the serviceable node through a single routing request message by integrating the routing path setting and the SDP service query into one so that each node knows the services that can be provided during the routing path establishment.

Referring to FIG. 3, first, a source node 10 that wants to send data makes a routing request in order to know a path to a destination node 30 that is a destination of data. Insert and broadcast to all nodes connected to it (S301).

When the intermediate node 20 receiving the routing request inserted with the broadcasted SDP request is not the destination node 30, the intermediate node 20 broadcasts the routing request inserted with the SDP request back to the nodes connected thereto. (S302).

In this way, when the routing request with the SDP request inserted to the destination node 30 arrives, the destination node 30 receiving the routing request with the SDP request inserted receives a routing response (SDP response inserted) in response thereto. Routing Reply) is sent (S303). The intermediate nodes 20 receiving the routing response relay the routing response in which the SDP response is inserted to the source node 10 again (S304).

If the destination node 30 can provide a service, communication is performed between the source node 10 and the destination node 30 (S305). As such, in the communication process according to the present invention, a process of establishing a routing path and a process of querying an SDP service are integrated so that the source node 10 can obtain the routing path and service availability information through a single request / response process. .

FIG. 4 is a schematic block diagram of a node device for enabling communication through a request / response process between two nodes in an ad-hoc network according to the present invention.

Referring to FIG. 4, the communication node device 410 includes a network application 411, a Bluetooth profile 412, an RF-COMM 413, a service discovery protocol layer (SDP 420), and a logical link. Logical Link Control And Adapatation Protocol (L2CAP (430)), Host Controller Interface (HCI 414), Link Management Protocol (LMP (415)), Baseband 416.

Among the components of the communication device 410, in particular, the SDP layer unit 420 and the L2CAP layer unit 430, which are parts having the configuration according to the present invention, will be described in detail, and other components having a general configuration will be described. Is omitted.

The routing agent 421 included in the SDP layer unit 420 finds a routing path between the two devices A and B through the expansion of the SDP command in the SDP layer, and reveals the types of services available between the two. The routing information and available service information for each node are recorded in the routing table 431 of the L2CAP layer unit 430.

According to an example of the present invention, the routing agent 421 generally follows the operation form of an AODV (Ad hoc On Demand Distance Vector) among on-demand routing protocols used in an ad-hoc network environment. The concept of RREQ and RREP is used to establish and maintain the routing path. On-demand AODV routing protocol broadcasts RREQ (Routing REQuest) when routing path is needed, and the node receiving RREQ sends RREP (Routing REPly) to find routing path when RREQ arrives at the desired destination. I use it. The same concept is used in an example of the present invention.

On-demand RREP and RREQ messages are implemented by extending the SDP commands of the SDP layer. This is so that the source node device can know whether all nodes on the piconet and all nodes on the scatternet are provided through one RREQ message. That is, the SDP command is extended to integrate routing path establishment and SDP service query in one step. Here, the piconet (piconet), according to the Bluetooth standard, the basic structure for communication in the Bluetooth network refers to a star-shaped single hop network, the scatternet (scatternet) refers to a network made by connecting a plurality of piconets.

However, unlike the AODV, the present invention does not send a HELLO message. That is, in the AODV routing protocol, every node periodically sends a HELLO message to check the routing path stored in its routing table to update the routing path. However, Bluetooth basically has a list of active devices connected to the master on the piconet, so when the RREQ message is delivered to the master on the piconet, the master broadcasts to the rest of the slaves. none. Therefore, in the present invention using the characteristics of Bluetooth, a HELLO message is not necessary for updating routing information.

Since the routing agent 421 uses the concept of RREQ and RREP to set and maintain the routing path used in AODV, the routing agent 421 also uses various fields used in RREQ and RREP of AODV.

For reference, the RREQ and RREP messages of the conventional AODV will be briefly described with reference to FIG. 2.

Referring to FIG. 2, the format 200 of the SDP layer of Bluetooth includes a header having a Protocol Data Unit (PDU) ID 210, a Transaction ID 220, and a Parameter Length 230, and the payload 240 has a header. It is the size of the parameter length defined in, consisting of each parameter.

Here, the PDU ID field 210 is defined and used in the standard from ID values 0x01 to 0x07, but is not used from 0x08 to 0xff. An example of the present invention defines the RREQ and RREP commands required for the routing protocol by extending such unused parts. For example, RREQ may assign an ID value of 0x20 and RREP may assign an ID value of 0x21.

Now, the structure of the RREQ message and the RREP message according to the present invention will be described.

5 is a block diagram of an SDP extension command packet for performing a routing request together with an SDP request according to the present invention.

Referring to FIG. 5, the RREQ message 500 includes a PDU ID 501, a Transaction ID 502, a Parameter Length 503, a Hop Count 504, a RREQ ID 505, a Destination BD Address 506, and a Destination. Sequence Number 507, Source BD Address 508, Source Sequence Number 509. Service UUID 510 is included.

The PDU ID field 501 may be selected and used from values 0x08 to 0xff not used in the standard, and 0x20 may be used according to an example of the present invention.

Transaction ID 502 and Parameter Length 503 are the same as before.

Hop Count 504 indicates the number of hops from the source node to the node that received the RREQ.The source node sets this area to 0 when transmitting an RREQ and transmits it, and the node receiving the RREQ re-enters the RREQ. When we broadcast to neighboring nodes, we increase the Hop Count value by 1.

The RREQ ID 505 refers to a serial number that issued the RREQ, and the source node sequentially increases the RREQ ID 505 whenever the RREQ is issued. Using this, the node receiving the RREQ compares the source node's Bluetooth address with the Broadcast ID to determine whether to receive duplicates. Each node maintains only one RREQ ID.

Destination BD Address 506 indicates the Bluetooth device address of the destination node to which the RREQ should arrive.

The destination sequence number 507 is a serial number which generated the RREP in the destination node and solves the infinite count problem by using the destination sequence number 507. The destination sequence number is used to determine whether the node holds the path from the destination node to the source node.

The Source BD Address 508 is the Bluetooth device address of the source node that originally created the RREQ.

The source sequence number 509 indicates the serial number that generated the RREP in the source node, and solves the infinite count problem using the source sequence number. The source sequence number indicates whether the mobile terminal from the source node to the destination node is valid for the path held by the source node. It is used to determine.

The service UUID 510 is a universally unique ID (UUID) indicating the type of service defined by the Bluetooth standard.

6 is a block diagram of an SDP extension command packet for performing a routing response together with an SDP response according to the present invention.

The RREP message is a message sent by the receiving node in response to the RREQ to the corresponding source node when the receiving node looks at the service UUID field of the RREQ message and is a service that can be provided.

Referring to FIG. 5, the RREP message 600 includes a PDU ID 601, a Transaction ID 602, a Parameter Length 603, a Hop Count 604, a Destination Sequence Number 605, a Source BD Address 606, Life Time 607 and Destination BD Address 608.

The PDU ID field 601 may be selected from among values 0x08 to 0xff not used in the standard, and 0x21 may be used according to an example of the present invention.

Hop Count (604) is a field that stores the number of hops between the source node and the destination node obtained during the transmission of the RREQ, Destination Destination Number (605) is the serial number that issued the RREP in the destination node that generated the RREP, Source BD Address 606 is the Bluetooth device address of the source node that generated the RREQ, and Lifetime 607 indicates the valid time of the generated routing path. Destination BD Address 608 is the Bluetooth device address of the node that created the RREP.

7 is a system configuration diagram of a Bluetooth ad-hoc network using a routing protocol according to the present invention.

Several Bluetooth nodes form a piconet A and piconet B together with neighboring nodes, and a slave 30 node included in two or more piconets serves as a gateway connecting two different piconets A and piconet B. . If the slave 20 wants to communicate with the slave 40 or there is no device on its piconet that provides the desired service, it sends an RREQ. The RREP is then received and forwarded in response to the routing path and available services to communicate with the slave 20 and the slave 40. Hereinafter, the operation will be described in detail.

Referring to FIG. 7, master 10 and slaves 10, 20, and 30 form piconet A, and master 20 and slaves 30 and 40 form piconet B.

The slave node 20, which is the source node, sends an RREQ message to the master 10 on the piconet A to which it belongs when it wants to communicate with the device providing the desired service. The master 10 receiving the RREQ message broadcasts the RREQ message received to the slave devices 10 and 30, which are the active devices connected thereto. Slave 30, which is a device serving as a gateway of the scatternet among the devices receiving the RREQ message from the master, that is, slave 30, which is a device belonging to another piconet B, transfers the RREQ message to master 20 of another piconet B. . Piconet B's Master 20 delivers the RREQ to slave 40, the active device, except for Slave 30, which just sent it to itself.

RREQ is delivered as described above, and all devices that receive an RREQ can see the service UUID field of the mesh to see if it is a service they can provide. If the service can be provided in comparison with its SDP database, RREP is sent to the slave node 20 as the source node. The process of sending an RREP message to the source node is the same as the process of sending RREQ. In this manner, the slave node 20, which is the source node, receives the RREP message from the master 10 and checks whether the routing path and the service can be provided through the received RREP message.

8 is a configuration diagram of an ad-hoc network system for solving a network disconnection problem occurring in an ad-hoc network according to the present invention.

In the Bluetooth standard, nodes on a piconet operate in synchronization with their master nodes. Therefore, if slave 10 of piconet A or slave 30 of piconet B do not take any action, as shown in the left figure of FIG. Although the slaves 30 are in communication range, no routing path can be established because neither of them finds each other and forms a new piconet.

In order to solve this problem, in the present invention, when a slave becomes a slave in one piconet, the neighboring nodes are inqury at a predetermined time interval, and a new connection is made with a node connected to another piconet among the nodes that are not currently connected to themselves. To form a new piconet.

That is, the newly formed piconet C is shown on the right side of FIG. 8. If you repeat this operation, all nodes on all networks will be connected when they are physically located.

Routing protocols through command extensions of the SDP layer can be described in two categories. One relates to the operation of a routing protocol that occurs on one piconet, ie, physically in one hop routing, and the other is routing between nodes that are over one hop away.

Now, the communication process through the extended SDP command according to the present invention will be described in detail with reference to FIG.

Referring to FIG. 9, when one source node wants to receive a specific service from a destination node, a routing request message including an RREQ, that is, a service provision query, which is an extension command of the SDP layer is sent (step 910).

Intermediate nodes (including the master node) that have received the RREQ will relay the RREQ until the RREQ arrives at the destination node (step 920).

AODV, the existing wireless routing protocol, periodically sends a HELLO message to check entries in the routing table. However, according to the Bluetooth specification, communication between slaves on a piconet is all passed through a master, and in the present invention, since the master has a list of active devices that can communicate on the piconet, that is, in the present invention, Do not use. Therefore, when a device looking for a desired service on the piconet sends an RREQ to the master, the master can broadcast the RREQ to all active devices on its list, so the master can update the routing table with a HELLO message. No action is required. The master may update the active devices through periodic inquiry instead of the HELLO message.

  The destination node receiving the RREQ 500 compares the service UUID 510 field of the RREQ packet with the service class list of its SDP database (step 930).

Thus, if the service UUID 510 matches its service class list, the service UUID 510 sends a RREP 600, which is a routing response message containing a response to the provision of service, to the source node in response (step 940).

The source node receiving the RREP communicates with the destination node using the established path and available services (step 950). If multiple destination nodes send RREP to the source node, this means that many devices are serviceable to the source node. At this time, the source node may select and communicate with the device in consideration of the distance or other conditions from the list of all destination node devices that have sent the RREP. The reason for sending the desired service UUID to RREQ is because Bluetooth is a connection-oriented technology, even if there is a routing path, communication between two nodes cannot be made if the destination node does not provide the service that the source node wants. . As such, by sending the service UUID 510 to the RREQ 500 together, the routing protocol is efficiently configured to send the RREP only when the destination node can provide the service indicated by the UUID.

According to the configuration of the present invention as described above, as the routing of the ad-hoc network through the command extension of the SDP layer, it is possible to set up the routing path and query the available services with only one RREQ message delivery. Allows you to configure an ad hoc network environment. In addition, unlike the existing method, the routing protocol is configured at the SDP layer rather than the application layer to maintain routing information at this layer, so that many applications can easily use it without considering the routing protocol. That is, according to the present invention, the ad-hoc network may be configured and used more easily, faster, and more efficiently using Bluetooth technology, and in the reality that the ubiquitous environment is gradually coming to reality, the instruction extension of the SDP layer of Bluetooth may be implemented. Through Bluetooth terminals, it is possible to configure ad hoc network environment more quickly and easily.

1 is a flowchart illustrating a process of communication between two nodes in an ad-hoc network according to the prior art;

2 illustrates the structure of a message according to the prior art;

3 is a flowchart illustrating a process in which communication is performed between two nodes in an ad-hoc network according to the present invention;

4 is a schematic block diagram of a node device for communication between two nodes in an ad-hoc network according to the present invention;

5 is a configuration diagram of an SDP confirmation command packet according to the present invention;

6 is a block diagram of an SDP extension command packet according to the present invention;

7 is a system configuration diagram of an ad-hoc network according to the present invention;

8 is a configuration diagram of an ad-hoc network system for solving a network disconnection problem occurring in an ad-hoc network according to the present invention;

9 is a flowchart illustrating a process of communicating between two nodes in an ad-hoc network in detail according to the present invention.

Claims (12)

In a communication method in an ad-hoc network environment, a) sending to the destination node a routing request with a query for service availability; b) receiving from the destination node a routing response inserted with a response as to whether service can be provided. The method of claim 1, Step a) is And transmitting a Routing REQuest (RREQ) message of the AODV protocol into which query information about service availability is inserted. The method of claim 1, B), And transmitting a Routing REPly (RREP) message of the AODV protocol with response information on whether service can be provided. A communication device in an ad-hoc network environment, A routing agent for transmitting a routing request inserted with a query for service availability to a destination node, and receiving a routing response with a response for service availability from the destination node; And a routing table for storing routing information. The method of claim 4, wherein The routing table further stores service information available by the routing agent. The method of claim 4, wherein And the communication device comprises a communication device operating in a Bluetooth environment. A recording medium on which a data structure of a message used for communication in an ad-hoc network environment is recorded, wherein the data structure is: An identifier indicating that the query information about the service availability is an inserted routing request message; Address information of the destination device, Address information of the source device, And a record indicating information on whether a service can be provided. The method of claim 7, wherein And the identifier is recorded in a Protocol Data Unit ID (PDUID) area of the SDP layer format header of the Bluetooth standard. The method of claim 7, wherein And the message uses the data structure of the RREQ message of the AODV protocol. A recording medium on which a data structure of a message used for communication in an ad-hoc network environment is recorded, wherein the data structure is: An identifier indicating that the response information about the service availability is an embedded routing response message; Address information of the destination device, Address information of the source device, A recording medium comprising information indicating a response to whether the service can be provided. The method of claim 10, And the identifier is recorded in the PDUID area of the SDP layer format header of the Bluetooth standard. The method of claim 10, And the message uses the data structure of the RREP message of the AODV protocol.