JP2005184322A - Multi-hop communication method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a multi-hop communication method by which charging can be easily performed by a communication carrier and the safety in communication is excellent in an ad hoc multi-hop network. <P>SOLUTION: The method comprises: a procedure in which a transmission source terminal S encrypts hop information unique to its own terminal with one (Ks) of an encryption key pair to generate encrypted information; a procedure in which the terminal S broadcasts RREQ containing the encryption key (Ks) and encrypted information, a procedure in which a terminal other than a destination having received the RREQ re-encrypts the encrypted information already registered in the RREQ together with the hop information unique to its own terminal with the encryption key (Ks), a procedure in which the terminal other than the destination broadcasts the RREQ containing the encryption key (Ks) and encrypted information re-encrypted, a procedure in which a destination terminal T having received the RREQ sequentially decrypts the encrypted information with the encryption key pair (KS, Ks); and a procedure in which the destination terminal T creates a hop list on the basis of the decrypted information. <P>COPYRIGHT: (C)2005,JPO&NCIPI

Description

  The present invention relates to a multi-hop communication method, and more particularly to a multi-hop communication method that is easy to be charged by a communication carrier and excellent in communication safety in an ad hoc network.

  In recent years, with the spread of various wireless access methods such as 1xEV-DO and wireless LAN and improvement in communication speed, the communication situation of mobile users has been remarkably improved. Wide area networks are deployed nationwide, covering most areas. In a wireless LAN, although the communication range is narrow, a throughput of several tens of Mbps can be provided.

  With the improvement and widespread use of wireless communication technology like this, the situation where users holding communication terminals are scattered everywhere makes it possible to configure a network ad hoc between communication terminals and communicate without using existing infrastructure. The method to do is widely studied.

In such an ad hoc mode, communication between terminals is performed on a one-to-one basis, but by further expanding this and using an ad hoc routing technology, not only a partner adjacent to itself but also a remote partner. However, multi-hop communication is proposed in which a terminal located between them serves as a relay node, which is disclosed in Patent Document 1, for example. Various methods regarding ad hoc routing are being actively studied. Among them, AODV (RFC-3561) and DSR (draft-ietf-manet-dsr-09.txt) are ad hoc routing protocols that are attracting much attention.
JP 2003-273788 A

  Conventional ad hoc routing has the following technical problems. First, since a communication carrier cannot participate in individual communication, it is difficult to charge or provide unique services. Second, it is difficult to ensure high communication safety.

  More specifically, the second problem is not limited to the presence of a node that operates correctly in a wireless network constructed in an ad hoc manner. In some cases, a malicious third party may exist and perform various attacks. In ad hoc routing technology, data packets sent from a terminal go through multiple relay nodes, but in conventional ad hoc routing technology, even if there is someone who acts fraudulently on the relay node, know that Is difficult.

  Further, in the conventional routing technique, it is necessary for end terminals (a transmission source terminal and a destination terminal) that communicate with each other to register a unique address that can uniquely identify a partner terminal for a transmission packet. For this reason, the end terminal which is performing communication is known to the entire relay node, and communication anonymity is significantly lost.

  The object of the present invention is to solve the above-mentioned problems of the prior art, and in an ad hoc multi-hop network composed of a wireless LAN or the like, multi-hop communication that is easy to be charged by a communication carrier and excellent in communication safety It is to provide a method.

  In order to achieve the above object, the present invention includes a plurality of terminals (S, T... X) and at least one routing control server (RM), and a terminal for transmission and a terminal for destination are relay terminals. The multi-hop communication method for performing communication via the network includes the following procedure.

  (1) The first procedure in which the source terminal (S) transmits a route establishment start request (RST) specifying the destination terminal (T) to the route control server (RM) and the route control server (RM) are asymmetric. A second procedure for generating an encryption key pair (KS, Ks) and a third procedure for the routing control server to notify the source terminal (S) and the destination terminal (T) of the encryption key pair (KS, Ks) And the source terminal (S) encrypts the hop information (from, to, IPs, Ts) unique to the terminal with one (Ks) of the encryption key pair to generate encrypted information. A fifth procedure in which the source terminal (S) broadcasts an RREQ packet including the one encryption key (Ks) and the encryption information;

  The terminal that has received the RREQ, the terminal other than the destination, the encryption information already registered in the RREQ, and the one encryption key (Ks) included in the RREQ together with hop information unique to the terminal. A sixth procedure for re-encrypting in step 7, a seventh procedure for a terminal other than the destination to broadcast an RREQ including the one encryption key (Ks) and the re-encrypted encryption information, and receiving the RREQ And the eighth procedure in which each terminal other than the destination repeats the sixth and seventh procedures, and the destination terminal (T) that has received the RREQ receives the encryption information from the encryption key. A ninth procedure for sequentially decoding in pairs (KS, Ks) and the destination terminal (T) from the source terminal (S) to the destination terminal (T) based on the decoded hop information A tenth procedure for generating a destination hop list, and the destination terminal (T) sends the hop to the routing server (RM) An twelfth procedure for notifying a list and a route control server (RM) establishing a communication route between the source terminal (S) and the destination terminal (T) based on the notified hop list. Procedures.

  (2) A thirteenth procedure in which one of a pair of link-disconnected terminals facing each other across the disconnected link notifies the route control server (RM) of link down when the established route is disconnected, and the route A fourteenth procedure in which the control server (RM) selects one of a first route from the source terminal (S) to the disconnected link and a route from the destination terminal (T) to the disconnected link; and the selected route When the end terminal (source terminal or destination terminal) of the selected terminal tries to establish a path with the other end terminal (destination terminal or source terminal), the RREQ that is transmitted is transmitted to A fifteenth procedure in which the route control server instructs a broken link terminal of the selected route to transmit an RRPR packet equivalent to an RREQ that is predicted to be transmitted when receiving and relaying, and an instruction to transmit the RRPR Broken link A terminal that transmits RRPR at the end, and a terminal that has received the RRPR, and a terminal other than the other end terminal sends encrypted information already registered in the RRPR together with hop information unique to the terminal. A seventeenth procedure for re-encrypting with the one encryption key (Ks) included in the RRPR, and a terminal other than the other end terminal makes the one encryption key (Ks) and the re-encrypted encryption An eighteenth procedure for broadcasting an RRPR including activation information; and a nineteenth procedure in which each terminal other than the other end terminal receives the RRPR and repeats the seventeenth and eighteenth procedures; A twentieth procedure in which the other end terminal that has received the RRPR sequentially decrypts the encrypted information with the encryption key pair (KS, Ks), and the other end terminal receives each of the decrypted terminals. Said one end based on the hop information of A twenty-first procedure for generating a hop list from the end to the other end terminal, a twenty-second procedure for the preceding other end terminal notifying the hop list to the routing control server (RM), and the routing control server (RM) Includes a twenty-third procedure for establishing a communication path between the end terminals based on the notified hop list.

According to the present invention, the following effects are achieved.
(1) Since the route control server can intervene in a procedure for establishing a communication route between end terminals, if the communication carrier manages the route control server, it becomes easy to charge and provide various services.
(2) Since the terminal that relays the RREQ encrypts its own hop information that is additionally registered in the RREQ, even if another terminal refers to the RREQ, it recognizes the route generated by this RREQ and its end terminal. Can not.
(3) The destination terminal (T) confirms the validity of the hop information obtained by decrypting the encrypted information included in the RREQ, and the hop generated based on this hop information only when the validity is confirmed. Since the list is notified to the routing server (RM), the hop list is not generated based on the altered hop information.
(4) The route control server (RM) confirms the validity of the hop list notified from the destination terminal (T), and establishes a communication route based on this hop list only when the validity is confirmed. The communication path is not established based on the altered hop list.
(5) When the correctness of the hop information is denied at the destination terminal (T), or when the validity of the hop list is denied at the routing control server (RM), each terminal that relays or receives the original RREQ Since all the information registered based on the RREQ is deleted and the same processing is executed based on the next received RREQ, it is possible to easily recover from a situation where an illegal act such as tampering is detected.
(6) Even when link down occurs in the established communication path and this is repaired, the hop information registered by each relay terminal in the RRPR (equivalent to RREQ) transmitted and received between end terminals is encrypted. High safety is ensured even during route repair.

  Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the drawings. FIG. 1 is a diagram showing a configuration example of an ad hoc network to which a multi-hop communication method of the present invention is applied, which includes a plurality of mobile terminals (S, A, B,... T) and at least one routing control server (RM). ) Is included. Here, a case where the mobile terminal S behaves as a transmission source terminal and the mobile terminal T behaves as a destination terminal will be described as an example.

  In this embodiment, as listed in FIG. 2, the IP address assigned to each mobile terminal X is expressed as IPx, the time stamp registered in each mobile terminal X is expressed as Tx, and each mobile terminal A MAC address that is unique (more specifically, unique to an interface connecting each mobile terminal to a network: the same applies hereinafter) is expressed as MACx. Further, in the present embodiment, a path is established between the source terminal S and the destination terminal T, and thereafter, given to the source terminal S and the destination terminal T in order to identify a destination of a frame transmitted / received on this path. Unique addresses are expressed as FWs and FWt, respectively.

The path control server (RM) satisfies the following conditions (1) to (3).
(1) A secure session such as SSL (Secure Sockets Layer protocol) can be established with each mobile terminal.
(2) It is possible to generate an asymmetric encryption scheme encryption key pair.
(3) Information on end terminals and relay terminals is held, and appropriate signaling can be performed.

Each mobile terminal satisfies the following conditions (1) to (6).
(1) Holds two wireless communication interfaces.
(2) A secure session such as SSL can be established with the RM.
(3) Asymmetric encryption can be encrypted and decrypted.
(4) Supports advanced wireless channel encryption methods (TKIP: Temporal Key Integrity Protocol, AES: Advanced Encryption Standard, etc.) and enables communication in ad hoc mode. Further, communication is possible by mixing both the encryption mode and the plaintext mode.
(5) Frame 2 can be flooded and transferred at layer 2.
(6) Link disconnection with an adjacent relay terminal can be detected.

  FIG. 3 is a diagram showing a list of main data managed by the route control server (RM) and each mobile terminal X (source terminal S, destination terminal T, relay terminal). The route control server (RM) manages the “route database (DB)”, “hop list”, and “repair information” shown in FIG. All mobile terminals manage the “transfer list” and “connection list” shown in FIG. Further, among the mobile terminals, in particular, the transmission source terminal S and the destination terminal T as end terminals further manage the “route information table” shown as an example in FIG.

  In the “path DB” (FIG. 4) managed by the RM, an ID and an asymmetric encryption key pair (Ks, KS) that are uniquely determined for one connection (a pair of a source terminal S and a destination terminal T) Communication encryption key (KEY) etc. are registered. Each entry has a “valid flag (v)”, “pending flag (p)”, and “repair flag (r)”. The valid flag (v) is set when a path is established between the transmission source terminal S and the destination terminal T and data communication using the unique addresses FWs and FWt described in detail later becomes possible. The pending flag (p) is set in a state where a route is being established using an RREQ packet or an RRPR packet, which will be described later. The “repair flag (r)” is set while the route is being repaired using the RRPR packet.

  The “route information table” (FIG. 6) managed by the source terminal S and the destination terminal T has a unique ID, asymmetric encryption key pair (Ks, KS), communication encryption key ( KEY) is registered. In each entry, the “valid flag (v)”, “pending flag (p)”, and “repair flag (r)” are prepared.

  In the “transfer list” (FIG. 5) managed by all the mobile terminals, a unique ID, one of asymmetric encryption key pairs (Ks), and unique addresses FWs and FWt described later are registered for one connection. Is done. In the “connection list” (FIG. 5), adjacent terminals are listed.

  FIG. 7 is a sequence diagram showing a route establishment procedure in the multi-hop communication method according to the present invention. Here, the procedure when the terminal S establishes a route with the terminal T will be described as an example.

  Procedure (1): The terminal S searches its own route information table and confirms whether or not the route to the destination terminal T has already been established. Here, the description will be continued assuming that a route has not yet been established and it is determined that a new route search is necessary.

  Procedure (2): The terminal S writes the IP address of the terminal T and the time stamp [IPt, Ts] in its own route information table and enters it. In this entry, an “invalid” flag indicating that the entry is still invalid, and a “pending” flag indicating that the entry is pending are set. After that, the terminal S generates a RST (Route Start: route establishment start request) packet: Init (instruction to create route information), encrypts it with SSL, and transmits it to the RM. In this RST: Init, as shown in FIG. 8A, the transmission source (S) and destination (RM), packet type (RST), destination (T) of the route to be established, time stamp ( Ts) and the MAC address (MACs) of terminal S are registered.

  Step (3): Upon receiving the RST, the RM generates an unassigned virtual asymmetric encryption key pair [Ks, KS] and a communication encryption key (KEY), and assigns an identification ID thereto. Further, a new entry is created in the route DB, and the contents of the received RST are recorded.

  Procedure (4): RM generates RST, encrypts it with SSL, and transmits it to destination terminal T. In this RST, as shown in FIG. 8B, the source (RM) and destination (T), packet type (RST), source (S) and destination (T) of the route to be established The key pair (Ks, KS), the communication encryption key (KEY), the time stamp (Ts), and the Mac address (MACs) of the terminal S are registered.

  Step (5): RM generates RST, encrypts it with SSL, and transmits it to terminal S. In this RST, as shown in FIG. 8C, the source (RM) and destination (S), packet type (RST), source (S) and destination (T) of the route to be established An encryption key pair (Ks, KS), a communication encryption key (KEY), a time stamp (Ts), and a source MAC address (MACs) are registered.

  FIG. 9 is a flowchart showing in detail the RST RST reception process including the procedures (3) to (5), and is activated every time the RST: Init is received.

  In step S11, an unassigned virtual encryption key pair [Ks, KS] and KEY are generated, and an ID is assigned to this (procedure 3). In step S12, an entry is created in the route DB, and the contents of the received RST are recorded. In step S13, an RST is generated and transmitted to the destination terminal T (procedure 4). In step S14, it is determined whether or not Ack is returned from the destination terminal T. If Ack is not returned, the entry is deleted from the path DB in step S17, and Nak is transmitted to the transmission source terminal S in step S18.

  On the other hand, if Ack is returned from the destination terminal T in step S14, it is determined in step S15 whether or not this is Ack_d. Since this Ack_d is transmitted when the destination terminal T is adjacent to the transmission source terminal S, if it is Ack_d, the process proceeds to a RR (Received Request) reception process in step S19. If it is not Ack_d, it will progress to step S16 and RST will be transmitted to the transmission origin terminal S (procedure 5).

  Step (6): The source terminal S starts flooding an RREQ (Route Request) packet in response to the reception of the RST. In this RREQ, as shown in FIG. 8D, a dummy address [0.0.0.0] is registered as a source address, and broadcast (b / c) is meant as a destination address [255. .255.255.255] are registered.

  In this RREQ, an electronic signature by a packet type (RREQ), a sequence number Seq, one encryption key (public key) Ks and the other encryption key (secret key) KS of [ID, Seq, Ks] is registered, Furthermore, [from, to, IPx, Tx] as hop information unique to the own terminal is encrypted and registered with the one encryption key Ks. Here, “from” is the MAC address of the terminal immediately before transmitting the RREQ to itself, and “to” is its own MAC address. “IPx” is an identifier for uniquely identifying its own terminal from all the terminals. Here, an IP address is used, but another identifier may be used. Only the terminal S has its own MAC address registered in “from” and “to”. Therefore, the hop information [from, to, IPx, Tx] registered by the source terminal S is [MACa, MACa, IPa, Ta].

  Step (7): Each terminal that receives the RREQ decrypts the electronic signature with one encryption key Ks to read the ID, and based on whether this is already registered as route information, the destination of the RREQ is Determine whether you are yourself.

  Procedure (8): Each terminal that has received RREQ adds hop information specific to the terminal to RREQ if the destination is other than itself. For example, if the terminal A receives the RREQ from the terminal S, the MAC address MACs of the terminal S as “from” of the hop information, the own MAC address MACa as “to”, the own IP address IPa as “IPx”, the time The current time (or a unique random value that does not overlap with others: the same applies below) Ta is added as the stamp Tx. Then, the encryption information registered in the RREQ and the hop information [MACs, MACa, IPa, Ta] are re-encrypted with the encryption key Ks [FIG. 8 (e)].

  Similarly, if the terminal B receives the RREQ from the terminal A, the MAC address MACa of the terminal A as “from” of the hop information, its own MAC address MACb as “to”, its own IP address IPb as IPx, and a time stamp The current time Tb is added as Tx. Then, the encryption information (hop information of the terminal S and the hop information of the terminal A) registered in the RREQ and the own hop information [MACa, MACb, IPb, Tb] are re-encrypted with the encryption key Ks [FIG. 8 (f)]. That is, in this embodiment, every time the number of hops increases, hop information unique to each relay terminal is encrypted in multiple.

  Step (9): When the destination terminal T receives the RREQ addressed to itself, the hop information of each relay terminal encrypted in multiple stages is sequentially transmitted in the encryption key pair [Ks, KS] notified in advance from the RM. Decrypt. Then, the validity of each hop information is determined based on whether or not the MAC address registered as “from” on one of the adjacent terminals and the MAC address registered as “to” on the other side all match. Determine sex.

  More specifically, if the RREQ reaches the terminal T from the terminal S via the terminals A and B, the MAC address registered as “to” by the terminal S unless the tampering is performed on the way. It should match the Mac address that terminal A has registered as “from”. Similarly, the MAC address registered as “to” by terminal A and the MAC address registered as “from” by terminal B should match. In this way, the terminal T determines the validity of each hop information by comparing the hop information of each adjacent terminal. The relay terminals A, B,... Before the destination terminal T are informed of only one [Ks] of the encryption key pair, and therefore cannot decrypt the encryption information. Since the destination terminal T may receive the RREQ on another route, the current RREQ is held in the pending list until the processing related to the current RREQ is completed.

  Procedure (10): The destination terminal T determines the validity of the hop information in this way, and when the validity is confirmed, creates a hop list based on this. The hop list obtained here is [S: Ts, MACs, A: Ta, MACa, B: Tb, MACb, T: Tt, MACt]. However, the MACs obtained by the RST are used, and [T: Tt, MACt] is added by the destination terminal T itself. If tampering is detected at the time of confirmation of validity, the RREQ is discarded without creating a hop list, and another RREQ that arrives next is awaited. When a new RREQ arrives, the validity is confirmed in the same manner as described above, and if the validity is confirmed, a hop list is created.

  Procedure (11): As shown in FIG. 8 (g), the destination terminal T generates an RR packet in which the hop list is registered and transmits it to the RM.

  FIG. 10 is a flowchart showing the operation of each mobile terminal that has received the RREQ, and includes the procedures (6) to (11).

  In step S31, the electronic signature registered in the received RREQ is decrypted with one encryption key Ks. In step S32, Ks and seq registered in RREQ are compared with Ks and seq obtained by the decoding. If they do not match, the RREQ is discarded. If they match, the process proceeds to step S33. In step S33, it is determined whether the ID obtained by decrypting the electronic signature is already registered in the transfer list. If already registered, the sequence numbers seq are compared. If the current sequence number is newer than the already registered sequence number, the process proceeds to step S36. If the ID is not registered, the process proceeds to step S35, and a new entry is added to the transfer list.

  In step S36, it is determined whether or not the current RREQ is addressed to itself based on whether or not the ID obtained by decrypting the electronic signature is already registered in the path information table. Since the ID is not registered if it is other than the destination terminal T, it is determined that the RREQ is addressed to a terminal other than itself, and the process proceeds to step S37. In step S37, hop information [from, to, IPx, Tx] unique to itself is added to RREQ. In step S38, the encrypted information registered in RREQ is re-encrypted together with the hop information [from, to, IPx, Tx]. In step S39, the time stamp Tx and the sequence number seq are registered in the transfer list. In step S40, the RREQ is broadcast (steps 7 and 8 above).

  On the other hand, in step S36, if the destination terminal T, the ID is already registered, so it is determined that the RREQ is addressed to itself, and the process proceeds to step S41. In step S41, the sequence numbers seq are compared. If the current sequence number is newer than the registered sequence number, the process proceeds to step S42. In step S42, the encrypted information registered in the RREQ is sequentially decrypted using the encryption key pair notified in advance from the RM, and the hop information registered by each relay terminal is extracted.

  In step S43, the validity of the hop information is determined based on whether the “from” of the hop information registered by one terminal adjacent to the route matches the “to” of the hop information registered by the other terminal. The sex is determined (procedures 9 and 10 above). If the validity is confirmed, the process proceeds to step S44, and a hop list is created based on the decrypted hop information. In step S45, the hop list is transmitted to the RM (procedure 11).

  If the validity is denied in steps S32 and S43, or if it is determined in steps S34 and S41 that the current sequence number is older than the registered sequence number, the current RREQ is determined in steps S46 and S47. Discarded. In this case, the destination terminal (T) waits for the next RREQ reception and repeats the reception process.

  Step (12): The RM generates a unique unassigned address pair [FWs, FWt]. Here, FWs is a unique address assigned to the source terminal S, and FWt is a unique address assigned to the destination terminal T.

  Step (13): The RM further writes the hop list notified from the terminal T to the route DB, and forwards the FWID (Forwarding Indication: Forward) to all terminals (except the destination terminal T) described in the hop list. Send first packet). As shown in FIG. 8 (h), the FWID packet transmitted to the terminal B includes the time stamp Tb registered in the hop information of the terminal B, and the MAC address of the terminal that the terminal B is supposed to have transmitted RREQ. The unique addresses FWs and FWt are registered together with the MAC address (MACa) of the terminal that is assumed to have transmitted RREQ to the terminal B (MACt).

  Similarly, in the FWID transmitted to the terminal A, as shown in FIG. 8 (i), the time stamp Ta registered in the hop information of the terminal A and the terminal of which the terminal A is said to have transmitted the RREQ are included. The unique addresses FWs and FWt are registered together with the MAC address (MACb) and the MAC address (MACs) of the terminal that is assumed to have transmitted RREQ to the terminal A.

  Similarly, in the FWID transmitted to the terminal S, as shown in FIG. 8 (j), the time stamp Ts registered in the hop information of the terminal S and the terminal of which the terminal S is said to have transmitted RREQ are included. The unique addresses FWs and FWt are registered together with the MAC address (MACa) and the MAC address (dummy address) of the terminal that is assumed to have transmitted RREQ to the terminal A. However, when the terminal S and the terminal T communicate directly, the hop list is only the source terminal S and the destination terminal T, and the FWID is transmitted only to the source terminal S.

  Step (14): Each terminal that has received the FWID checks the time stamp and connection list registered in its forwarding list or routing information table to check the fraud of others (spoofing or replay attack). If no fraud is detected, the unique addresses FWs and FWt are set in the forwarding list, and if fraud is detected, FWID: malicious (notification of falsification etc.) is sent to the RM.

  Note that the RM that has received FWID: malicious identifies a route in which falsification is found by referring to the hop list of the route DB. Then, the information is registered and transmitted to each relay terminal in an FWID: revocation (transfer list deletion instruction) packet, and to the terminal T in an RCMP (Routing Complete: route establishment completion): malicious (tampering discovery notification) packet. Register and send. Each relay terminal discards the corresponding transfer list in response to reception of the FWID: revocation. Terminal T waits for reception of a new RREQ.

  Procedure (15): Each terminal returns Ack to RM when the validity is confirmed. The source terminal S becomes “receivable” at this point.

  Procedure (16): The RM generates an RCMP packet and transmits it to each end terminal S, T. As shown in FIGS. 8 (k) and (l), the RCMP transmitted to each end terminal includes a combination of the source terminal S and the unique address (FWs) assigned thereto, and the destination terminal T and A combination with a unique address (FWt) assigned to this is registered.

  Upon receiving the RCMP, the end terminals S and T register this in the route information table, set the flag to “valid”, and set the pending flag to “off”. The terminal S records IPt → IF_wlan (to the ad hoc interface if the destination address is IPt) in the route information table, IPt = FWt (registers FWt as the IPt mac address), and FWs in the forwarding list. Similarly, terminal T writes IPs → IF_wlan in the route information table, IPs = FWs in the ARP table, and FWt in the transfer list, and turns on a flag indicating whether or not it is addressed to itself. Thereafter, the end terminals S and T return the RCMPack to the RM and delete the pending list regarding the RREQ. When the RM receives the Ack, the flag is “valid”, the pending is turned off, and the path establishment ends here (both terminals S and T are “transmittable / receiveable”).

  FIG. 11 is a flowchart showing the operation of each mobile terminal that has received the FWID, and includes the procedures (14) and (15).

  In step S51, it is determined whether or not the classification of the received FWID is a transfer list deletion instruction (revocation). If it is not revocation, in step S52, it is validated based on the time stamp registered in the FWID. Sex is determined (procedure 14). When the validity is confirmed, in step S53, the unique addresses FWs and FWt registered in the FWID are registered in the transfer list. In step S54, Ack is returned to the RM (procedure 15).

  On the other hand, if the validity cannot be confirmed in step S52, the process proceeds to step S55, and FWID: malicious (notification of falsification discovery) is transmitted to the RM. In step S56, the corresponding transfer list is discarded. If it is determined in step S51 that the received FWID classification is revocation, the transfer list is discarded in step S57. In step S58, Ack is returned to the RM.

  As described above, when a communication path is established between the source terminal S and the destination terminal T, each terminal communicates with one of the unique addresses (FWs) as the source address and the other (FWt) as the destination address. Start. At this time, a frame transmitted / received between the terminals S and T is encrypted with a communication encryption key (KEY) assigned to each connection.

  Next, a link repair procedure for repairing the path established as described above when the path is disconnected will be described with reference to the sequence diagram of FIG. Here, the connectivity between the terminals A and B is lost from the state where the data delivery route is established in the order of the source terminal S, terminal A, terminal B, terminal C, terminal D, and destination terminal T. An example will be described (therefore, terminals A and B are terminals with broken links).

  Procedure (1): Terminal A detects that data has not reached terminal B. This can be detected, for example, based on the fact that Ack for the transmitted data frame is not returned from terminal B.

  Procedure (2): Terminal A that has detected link down sends RERR (Route Error: down) to RM to notify that the topology has changed. In this RERR, the unique address FWt of the destination terminal T of the route on which the packet has stopped reaching is registered together with the IP address IPa of the terminal A and its time stamp Ta.

  Step (3): The RM sets a repairing flag in the route DB. Further, information (IPa, FWt) registered in the notified RERR and information (IPb and FWs) about the terminal S on the opposite side are registered in the route DB. If the repair flag has already been set when the RM receives the RERR, the terminal S is notified to re-establish the route.

  Procedure (4): RM generates an RRPR (Route Repair) packet and transmits it to terminal B. More specifically, the RM calculates the number of hops from the source terminal S to the disconnected link and the number of hops from the destination terminal T to the disconnected link based on the hop list registered in its route DB. Compare. In this embodiment, a route from the destination terminal T to the link-broken terminal B is selected as the route on the side where the number of hops to the disconnected link is far, and the route information is extracted from the hop list. Then, when the terminal T receives the RREQ that will be transmitted when the terminal T tries to establish a route with the terminal S, the terminal B receives it via the terminals D and C, and transmits it when relaying it. The terminal B is instructed to transmit the RRPR substantially the same as the predicted RREQ.

  FIG. 13 is a diagram showing a frame structure of an RRPR packet transmitted from the RM to the broken link terminal B. If the RMPR packet is transmitted from the terminal T and passes through the terminals D, C, and B, it is given to each terminal. Encrypted information of the expected hop information is already attached.

  Step (5): When the link-broken terminal B that has received the RRPR updates Seq in the transfer list, it returns Ack to the RM and floods the RRPR again. FIG. 14 is a diagram showing an RRPR format that terminal B broadcasts in response to an instruction from the RM. The processing at each terminal at the time of flooding is the same as the procedure (8) of the route establishment sequence (FIG. 7).

  Although not shown in FIG. 12, if the RM does not receive an Ack from the terminal B after waiting for a certain time after the transmission of the RRPR packet, the terminal B gives up the terminal B and sends it to another link-disconnected terminal A. Send RRPR. The RRPR transmitted at this time is received when the link-disconnected terminal A receives the RREQ that will be transmitted when the source terminal S tries to establish a route with the terminal T and relays it. It is substantially the same as RREQ that terminal A is expected to transmit. If the RM cannot receive Ack from the terminal A, the RM gives up the path restoration and proceeds to the path reconstruction procedure.

  Procedure (6): Similar to the procedures (9) and (10) of the route establishment sequence (FIG. 7), the terminal S receives the RRPR and uses the encrypted hop information of each relay terminal as the encryption key. Decrypt sequentially with pair [Ks, KS]. Then, the validity of each hop information is determined based on whether or not the MAC address registered as “from” on one of the adjacent terminals and the MAC address registered as “to” on the other side all match. Determine sex. If the validity is confirmed, a hop list is created based on this. Since the destination terminal S may receive the RRPR on another route, the current RRPR is held in the pending list until the processing related to the current RRPR is completed.

  Procedure (7): Similarly to the procedure (11) of the route establishment sequence, the terminal S confirms the presence or absence of falsification, and if the validity is confirmed, the hop list [S: Ts, MACs, N: Tn , MACn, B: Tb, MACb, C: Tc, MACc, D: Td, MACd, T: Tt, MACt] are registered in the RR packet and transmitted to the RM.

  Step (8): The RM transmits FWID: forward to the terminal (terminal N in this example) newly added to the path while overwriting the hop list in the path DB.

  Procedure (9): Before overwriting the hop list, the RM transmits FWID: revocation (transfer list deletion instruction) to the old terminal (terminal A in this example).

  Procedure (10): The RM further transmits FWID: forward to the terminal whose hop destination is changed (in this example, the terminals S and B adjacent to the added terminal N). The FWs and FWt specified here are the same as those used before the link was broken.

  Step (11): Each terminal that has received the FWID checks the validity including the presence / absence of spoofing as in the step (14) of the route establishment sequence. Returns Ack.

  Procedure (12): RM sends RCMP: updated to terminals S and T, turns off the repair flag, and deletes the entry. Terminals S and T update the route information table and Seq in the transfer list, delete the pending list, and wait for the next RRPR reception.

It is the figure which showed an example of the ad hoc network to which the multihop communication method of this invention is applied. It is the figure which displayed the code | symbol as a list. It is the figure which showed the list of the data which a route control server (RM) and each mobile terminal (source terminal S, destination terminal T, relay terminal) manage. It is the figure which showed the list of the data which a route control server (RM) manages. It is the figure which showed the list of the data which all the mobile terminals manage. It is the figure which showed the list of the data which an end terminal (S, T) manages. It is the sequence diagram which showed the route establishment procedure. It is the figure which showed the frame structure of the signaling packet. It is a flowchart of the RST reception process in RM. It is a flowchart of the RREQ reception process in each mobile terminal. It is a flowchart of the FWID reception process in each mobile terminal. It is the sequence diagram which showed the link repair procedure. FIG. 4 is a diagram showing a frame structure of an RRPR packet transmitted from the RM to the broken link terminal B. FIG. 3 is a diagram showing a frame structure of an RRPR packet transmitted by a terminal B with a broken link.

Explanation of symbols

FWx: Unique address assigned to terminal X
FWID ... Forwarding destination instruction packet
IPx: IP address assigned to terminal X
KEY ... Communication encryption key
KS, Ks ... Asymmetric encryption key pair
MACx: Mac address assigned to terminal X
RM: Routing server
RREQ ... Route establishment request packet
RRPR ... Route repair request packet
RST ... Route establishment start request
S ... Source terminal
T: Destination terminal
Tx Time stamp on terminal X

Claims (10)

In a multi-hop communication method including a plurality of terminals (S, T... X) and at least one routing control server (RM), wherein a source terminal and a destination terminal communicate via a relay terminal,
A first procedure in which the transmission source terminal (S) transmits a route establishment start request (RST) specifying the destination terminal (T) to the route control server (RM);
A second procedure in which the routing server (RM) generates an asymmetric encryption key pair (KS, Ks);
A third procedure in which the routing server notifies the source terminal (S) and the destination terminal (T) of the encryption key pair (KS, Ks);
A fourth procedure in which the source terminal (S) encrypts hop information (from, to, IPs, Ts) unique to the terminal with one of the encryption key pairs (Ks) to generate encrypted information;
A fifth procedure in which the source terminal (S) broadcasts an RREQ packet including the one encryption key (Ks) and the encryption information;
The terminal that has received the RREQ, the terminal other than the destination, the encryption information already registered in the RREQ, and the one encryption key (Ks) included in the RREQ together with hop information unique to the terminal. A sixth step of re-encrypting with
A seventh procedure in which a terminal other than the destination broadcasts an RREQ including the one encryption key (Ks) and the re-encrypted encryption information;
An eighth procedure in which each terminal other than the destination, which has received the RREQ, repeats the sixth and seventh procedures;
A ninth procedure in which the destination terminal (T) receiving the RREQ sequentially decrypts the encrypted information with the encryption key pair (KS, Ks);
A tenth procedure for the destination terminal (T) to generate a hop list from the source terminal (S) to the destination terminal (T) based on the decoded hop information;
An eleventh procedure in which the destination terminal (T) notifies the routing control server (RM) of the hop list;
The route control server (RM) includes a twelfth procedure for establishing a communication route between the source terminal (S) and the destination terminal (T) based on the notified hop list. Multi-hop communication method. The multi-hop communication method according to claim 1, wherein each terminal and the route control server (RM) perform encrypted communication. The ninth step further includes a step of confirming the validity of each decrypted hop information,
The destination terminal (T) discards the RREQ when the validity of the hop information is denied, repeats the ninth procedure, and based on the hop information only when the validity of each hop information is confirmed. The multi-hop communication method according to claim 1, wherein a hop list is generated. The twelfth procedure further includes a procedure of confirming validity of the notified hop list,
When the validity of the hop list is denied, the hop list is discarded and the ninth to twelfth procedures are repeated, and only when the validity of the hop list is confirmed, the transmission source terminal is based on the hop list. The multi-hop communication method according to claim 1 or 2, wherein a communication path is established between (S) and a destination terminal (T). The twelfth procedure includes
The routing control server assigns one of the unique unassigned addresses (FWs, FWt) (FWs) to the source terminal (S) and assigns the other (FWt) to the destination terminal (T);
The route control server notifies each terminal on the route of the assignment of the unique address (FWs, FWt),
Each terminal on the route includes a procedure for generating a forwarding list based on the assigned unique address (FWs, FWt),
The source terminal (S) and the destination terminal (T) adopt the unique address (FWs, FWt) as a source address and a destination address when exchanging frames,
5. The multi-hop communication method according to claim 1, wherein each of the terminals transfers a frame destined for one or the other of the unique addresses based on the transfer list. In the second procedure, the routing server (RM) further generates a communication encryption key (KEY) unique to the combination of the source terminal (S) and the destination terminal (T),
In the third procedure, the routing server notifies the communication encryption key (KEY) to the source terminal (S) and the destination terminal (T),
The multi-hop communication method according to claim 5, wherein the source terminal (S) and the destination terminal (T) encrypt a frame to be exchanged with the communication encryption key (KEY). A thirteenth procedure in which, when the established route is disconnected, one of a pair of link-disconnected terminals opposed across the disconnected link notifies the route control server (RM) of a link down;
A fourteenth procedure in which the route control server (RM) selects one of a first route from the source terminal (S) to the disconnected link and a second route from the destination terminal (T) to the disconnected link;
RREQ to be transmitted when an end terminal (source terminal or destination terminal) of the selected path tries to establish a path with the other end terminal (destination terminal or source terminal) is the selected path A fifteenth procedure in which the route control server instructs the link-broken terminal of the selected route to transmit an RRPR packet equivalent to an RREQ that is predicted to be transmitted when the link-broken terminal receives and relays.
A sixteenth procedure in which a broken link terminal instructed to transmit the RRPR transmits the RRPR;
The terminal that has received the RRPR, and a terminal other than the other end terminal uses the one encryption key included in the RRPR together with the encryption information already registered in the RRPR together with hop information unique to the terminal. A 17th step of re-encrypting with (Ks);
An 18th procedure in which a terminal other than the other end terminal broadcasts an RRPR including the one encryption key (Ks) and the re-encrypted encryption information;
A 19th procedure in which each terminal other than the other end terminal receives the RRPR and repeats the 17th and 18th procedures;
A twentieth procedure in which the other end terminal receiving the RRPR sequentially decrypts the encrypted information with the encryption key pair (KS, Ks);
A step 21 in which the other end terminal generates a hop list from the one end terminal to the other end terminal based on the decoded hop information of each terminal;
A twenty-second procedure in which the other end terminal notifies the routing control server (RM) of the hop list;
The multi-hop communication according to claim 1, wherein the route control server (RM) includes a twenty-third procedure for establishing a communication route between the end terminals based on the notified hop list. Method. The multi-hop communication method according to claim 7, wherein, in the fourteenth procedure, the route control server selects a short route by comparing the first route and the second route. Further comprising a procedure for the other end terminal to confirm the validity of each hop information,
The multihop communication method according to claim 7 or 8, wherein the other end terminal generates a hop list based on the hop information only when the validity of the hop information is confirmed. The routing control server (RM) further includes a procedure for confirming the validity of the hop list,
The route control server (RM) establishes a communication route between the end terminals based on the hop list only when the validity of the hop list is confirmed. Multi-hop communication method.

Images