JP2018014077A - Communication device, system, and method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a communication technology for executing an application in a network, and reduce a delay in data transfer to increase the response to a result of execution of the application.SOLUTION: A requester 401 or an edge node thereof determines, in transferring a request message 407, whether to cause one of a relay node A402 and a relay node B403 on a path from a data-a holding node 405 being a destination node to execute an application in terms of proximity to the destination or in terms of proximity to a link, by the fact that which of output data being a result of execution of "application-1" and input data required for the execution is larger, and sets information identifying the determination in the request message 407 as an execution policy bit PL.SELECTED DRAWING: Figure 4

Description

  The present invention relates to a communication apparatus, system, and method for executing an application (hereinafter referred to as “application”) on a network.

  A new network architecture called ICN (Information-Centric Networking) that allows communication and acquisition by designating content by name is drawing attention. Furthermore, a method called NFN (Named Function Networking) is known for executing applications on such a network. In NFN, a node for executing an application is determined in the network, and a request for executing the application is transmitted from the request node to the determined node. The determined node acquires the application and data specified in the request from the network, executes the application, and returns the execution result to the request node.

  A conventional technique for realizing an efficient intelligent distributed environment is known for a message delivery method for delivering messages exchanged between software distributed over a network (for example, Patent Document 1). When delivering a message exchanged between software distributed over the network, a service list defined by the data pairing between the message delivery destination information and the processing information specified by the message is added to the message. Append. The service list part for which processing has been completed is deleted by the software at the delivery destination, and the message with the service list added is delivered from software to software while rewriting the service list as necessary.

  In addition, when distributing a request using a plurality of servers in response to a file transmission request from a client, a conventional technique is known that enables appropriate distribution (for example, Patent Document 2). The processing determining unit compares the required time required for each response obtained by “RTs1, c (FS) <RTs1, c (MSr) + RTc, s2 (MSq) + RTs2, c (FS)”. RTa, b (L) is an expected transfer time required for transmitting a file of size L from the terminal a to the terminal b. FS is the size of the file to be transferred, and MSr is the size of the redirection message. MSq is the file size of the request that the client sends to another server again.

  Further, the following prior art is known in the communication method of the network node for IP routing compatibility (for example, Patent Document 3). Generating a packet including a content name including first information indicating the position of the content and second information identifying the content; and transmitting the generated packet. Accordingly, a gateway for converting the packet format between the IP network and the content-centric network is not required, and the general packet format for IP can be used as it is without being converted.

JP-A-11-175421 JP 2001-243142 A JP-T-2006-502343

  In the above-described NFN, typically, the first NFN node (or near the request node) on the path through which the request message is transmitted on the network executes the application as the application executable node. For this reason, the following problems occur when an app whose input data (image data) is larger than the output data (analysis result) of the app, such as an image analysis app, is executed. Will occur.

  By transferring apps and data from a distant node to an app executable node, the transfer delay of apps and data increases, and the response time (from the time the user throws the app execution request until the response is received) There is a problem that the time is slow.

  Accordingly, an object of one aspect of the present invention is to reduce data transfer delay and speed up response of an application execution result.

  In one example, the communication device includes an execution node determination unit and a request message setting unit. The execution node determination means determines which node of the application executable nodes in the path between the data request destination node and the request node is to execute the application for the output data amount that is the execution result of the application and the execution of the application. Determine based on the amount of input data required. The request message setting means sets the identification information of the determined node in the request message for requesting the execution of the application communicated toward the data request destination node or the application executable node.

  It is possible to reduce the data transfer delay and speed up the response of the application execution result.

It is a figure showing the characteristic of ICN. It is a figure showing the basic model of NFN. It is a figure showing control of application execution in NFN. It is explanatory drawing (description figure showing the 1st operation example of 1st Embodiment) of 1st Embodiment of the communication system which performs application execution. It is explanatory drawing of 2nd Embodiment of the communication system which performs application execution. It is a figure showing the structural example of the communication system which performs application execution which concerns on 1st or 2nd embodiment. It is a figure showing the hardware structural example of the communication apparatus which comprises a node. It is a figure showing the example of a format of the request message and response message communicated with the communication system which performs application execution which concerns on 1st or 2nd embodiment. It is a figure which shows the structural example of PL setting table. It is a flowchart which shows the message transfer process example of the relay node in the communication system which performs application execution which concerns on 1st or 2nd embodiment. It is a figure showing the sequence of the 1st operation example of 1st Embodiment. It is explanatory drawing showing the 2nd operation example of 1st Embodiment. It is a sequence diagram showing the 2nd operation example of 1st Embodiment. It is explanatory drawing showing the 3rd operation example of 1st Embodiment. It is a sequence diagram showing the 3rd operation example of 1st Embodiment. It is explanatory drawing showing the 4th operation example of 1st Embodiment. It is a sequence diagram showing the 4th operation example of 1st Embodiment. It is explanatory drawing showing the 5th operation example of 1st Embodiment. It is a sequence diagram showing the 5th operation example of 1st Embodiment. It is explanatory drawing showing the 6th operation example of 1st Embodiment. It is a sequence diagram showing the 6th operation example of 1st Embodiment. It is explanatory drawing showing the 7th operation example of 1st Embodiment. FIG. 10 is a sequence diagram illustrating a seventh operation example of the first embodiment. It is a sequence diagram showing the operation example of 2nd Embodiment. It is a network diagram for demonstrating application execution of 3rd Embodiment. It is a network diagram for demonstrating the basic policy of 3rd Embodiment. It is a figure showing the message format of 3rd Embodiment. It is the schematic of the system for demonstrating Example 1 of 3rd Embodiment. It is a figure showing the system operation | movement of the Example 1 of 3rd Embodiment. It is a figure showing the sequence of the Example 1 of 3rd Embodiment. It is a figure showing the processing flow of each node of 3rd Embodiment. It is the schematic of the system for demonstrating Example 2 of 3rd Embodiment. It is a figure showing the system operation | movement of the Example 2 of 3rd Embodiment. It is a figure showing the sequence of Example 2 (a) of 3rd Embodiment. It is a figure showing the sequence of Example 2 (b) of 3rd Embodiment.

  Hereinafter, embodiments for carrying out the present invention will be described with reference to the drawings.

  First, FIG. 1 is a diagram showing the characteristics of ICN. ICN has features such that content can be specified by name, and a network node has a cache. In FIG. 1, a request node (hereinafter referred to as “requester”) 102 transmits an Interest 106, which is a content request message, to the ICN 100. In the request message Interest 106, the content is specified in a format such as “/ fj / video1”, for example. When one of the plurality of nodes 103 constituting the ICN 100 receives the request message Interest 106, the node connected to the ICN 100 and holding the content designated by the request (for example, “/ fj / video1”), The content is acquired. Here, the content includes data, an application, or an application execution result. The node processes the acquired content (for example, “/ fj / video1”), and returns a response message Data 108 including the processing result to the requester requester 102.

  In particular, NFN (Named Function Networking) is known as an extension of the ICN 102 so that application execution (In-network processing) in the ICN 100 (inner node) can be specified and implemented. FIG. 2 is a diagram illustrating a basic model of NFN. In the NFN 200, application execution is performed in the following procedure.

  Step S201: Processing request (execution location identification and request transmission). The NFN 200 transfers a request message from a requester (not shown) to the node 201 at the application execution location. The application execution location is selected from a location where an application is present, a location where data is present, and other locations (for example, an empty server). The request message has a format of “Interest (Func (Data_in))”, for example. This format means “execute the application“ Func ”using“ Data_in ”as input data and return the result”.

  Steps S202 and S203: Acquisition of application / data. The CPU (central processing unit) of the identified application execution node 201 transmits another request message “Interest (Func)” to the application holding node 202, whereby the application “Func” is transmitted from the application holding node 202. Is acquired (step S202). Similarly, the CPU of the node 201 obtains data “Data_in” from the data holding node 203 by transmitting yet another request message “Interest (Data_in)” to the data holding node 203 (step S203).

  Step S204: Execution of processing. The CPU of the application execution node 201 receives the data “Data_in” acquired from the data holding node 203, executes the application “Func” acquired from the application holding node 202, and outputs the execution result “Data_out”.

Step S205: sending the result. The CPU of the application execution node 201 returns the execution result “Data_out” as a response message to the request source.
In addition, the following is assumed as a premise in NFN.
・ Apps and data are required to run apps. There can be multiple applications and data. Hereinafter, applications and data are collectively referred to as “element objects”.
Element objects are distributed and distributed at appropriate locations (nodes) in the NFN 200 network and can dynamically move between nodes.
-As a result of application execution, data different from the input data is output and responded.
-The network of NFN 200 is large-scale, and it is difficult to centrally manage the state of all nodes in one place in real time.
Applicable applications include both network applications such as firewalls and filtering, and user applications such as data analysis applications and image analysis applications. These applications are implemented in the form of byte codes (for example, Java (registered trademark)), are platform independent, and can be moved between nodes.

  FIG. 3 is a diagram illustrating application execution control in the NFN 300 based on the above assumption. FIG. 3 shows a case where application-1, data-a, and data-b are required to execute the application. In this case, application execution is performed in the following procedure.

  <Procedure 1>: The requester 301 who is a requester of service execution throws a request message 307 requesting application execution toward data (or an application). In FIG. 3, the request message 307 is specified by, for example, the name “data−a + application−1 + data−b”. In this case, the request message 307 is thrown toward the element object indicated by the name “data-a” at the head of the designated content. The requester 301 specifies the element object to which the request message 307 is to be thrown by the name of the request message 307. In FIG. 3, the transmission path of the request message 307 is indicated by a solid arrow line.

  <Procedure 2>: One of the NFN nodes (nodes that can execute the application) 302, 303, etc. on the route executes the application. Typically, the first NFN node on the route (NFN node-A 302 in FIG. 3) is the application execution location. For example, the NFN node-A 302 separately acquires the necessary application and data specified by the request message 307 from the application holding node 304 and the data holding nodes 305 and 306 via the NFN node-B 303, and The execution is performed, and the result is returned to the requester 301 as a response message 308. The response message 308 includes the name “data−a + application−1 + data−b” specified in the request message 307 and the execution result of the application. In FIG. 3, the transmission path of the response message from the application holding node 304 and the data holding nodes 305 and 306 to the NFN node-A 302 and the response message 308 from the NFN node-A 302 to the requester 301 is indicated by a broken arrow line. Indicated.

  In the application execution method shown in FIG. 3, typically, the first NFN node-A 302 on the route (or near the requester 301) executes the application. For this reason, the following problems occur when an app whose input data (image data) is larger than the output data (analysis result) of the app, such as an image analysis app, is executed. Will occur.

  By transferring apps and data from a distant node to an app executable node, the transfer delay of apps and data increases, and the response time (from the time the user throws the app execution request until the response is received) Time).

  Further, the application execution location (application execution load) cannot always be balanced between the first NFN node on the route (or near the request node) and another NFN node on the route.

  It is also conceivable that the execution location is not limited to the first NFN node on the route, but is determined by other logic according to a certain policy. However, depending on how the policy is determined (for example, when the policy designates the nearest node of the destination), the location of the single node cannot be determined and the execution of the application may not be controlled.

  Each embodiment described below solves the above-mentioned problem. First, the basic policy (approach) for application execution in the first embodiment is as follows.

<Approach 1>
Depending on the relationship between the input data to the application and the size of the output data, that is, the relationship between the input data amount and the output data amount,
If output data <Σ (input data), near the destination (far from the requester)
If output data> Σ (input data), in the vicinity of the requester,
Run each app. Here, “Σ (input data)” means the sum of the sizes of input data that can exist in plural.

<Approach 2>
Further, the resource state of each node is reflected in the determination of the application execution location, and the load is balanced among the nodes with the location specified in Approach 1 as the center. Here, the “resource” means, for example, a processor that can execute a specified application, a hardware resource such as a memory, and / or a software environment that can execute the specified application.

  That is, based on the application characteristics (approach 1) and the resource state (approach 2) of each node, whether or not the application can be executed is determined from information obtained locally by each node, and the application execution location is dynamically determined.

  FIG. 4 is an explanatory diagram of a first embodiment of a communication system that executes an application based on the basic policy. In the communication system 400 of FIG. 4, as in the case of FIG. 3, the case where the application-1, the data-a, and the data-b are necessary to execute the application is shown. In this case, application execution is performed in the following procedure.

<Procedure 1>
In the request message 407 for requesting execution of the transmitted application, the same name “data−a + application−1 + data−b” as in the request message 307 of FIG. This request message 407 is transmitted toward a specific element object (application or data). In the example of FIG. 4, as in the case of FIG. 3, the request message 407 is thrown toward the element object corresponding to the name “data-a” at the head of the name designation “data-a + application-1 + data-b”. It is done.

  Furthermore, in the first embodiment, the execution message bit PL (execution policy identification information), the application holding bit AH (application holding identification information), and the application executable can be added to the request message 407, as indicated by the broken line frame 409 in FIG. Bit AE (application executable identification information) is added. At least the execution policy identification information is set as node identification information.

  Depending on the characteristics of the application, the requester 401 or the edge node (the node at the entrance of the network that accommodates the requester 401) determines whether the execution policy bit PL of the request message 407 is destination neighborhood priority (= 1) or requester neighborhood priority (= 0). ) Or As described in <Approach 1> above, the application characteristics are the relationship between the input data to the application and the size of the output data.

  That is, if “output data <Σ (input data)”, the execution policy bit PL is set to destination neighborhood priority (= 1) so that the application is executed in a node near the destination (far from the requester).

  On the other hand, if “output data> Σ (input data)”, the execution policy bit PL is set to requester neighborhood priority (= 0) so that the application is executed at a node near the requester 401.

  In FIG. 4, the execution policy bit PL is set to a value 1 indicating destination neighborhood priority.

<Procedure 2>
The relay node-A 402 and the relay node-B 403 on the route include the application designated by the request message 407 (hereinafter referred to as “designated app”) including the neighboring nodes not on the route, Depending on whether you have execution resources, perform the following actions: The relay node-A 402 and the relay node-B 403 sequentially set the value 1 to the application holding bit AH and / or the application executable bit AE of the request message 407 received and transferred by the own node.

<Procedure 3>
The destination data-a holding node 405 adds the “data-a” body, which is the requested element object, to the received request message 407, and uses them as a response message 408 to reverse the route of the request message 407. Send back along.

<Procedure 4>
When receiving the response message 408, the relay node-A 402 and the relay node-B 403 perform the following operation. The relay node-A 402 and the relay node-B 403 change the values of the execution policy bit PL, the application holding bit AH, and the application executable bit AE when the request message 407 is transferred and when the response message 408 is received. Compare and autonomously determine the operation of its own node. Based on the operation autonomously determined by each of the relay node-A 402 and the relay node-B 403, the application execution location is the destination node having the maximum size element object, the destination node on the location / route of the requester 401 Alternatively, it is determined in the priority order of a node near the requester and a neighboring node that is not on the route. As will be described later, the application holding bit AH and the application executable bit AE of the request message 407 and the response message 408 indicate the relative position of the own node on the route. Considering the execution policy bit PL indicating whether the application should be executed near the bit and the destination or the application near the requester 401, each node such as the relay node-A 402 and the relay node-B 403 Autonomously decides whether to run the app. In the example of FIG. 4, the relay node-B 403 itself determines to execute the application as a node having a resource for executing the application closest to the destination (data-a holding node 405) on the route. The relay node-B 403 stores “application-1” designated by the request message 407, “data-a”, and “data-b” main bodies, respectively, “application-1” holding node 404, data-a holding. The application is acquired from the node 405 and the data-b holding node 406 and executed. The relay node-B 403 adds the execution result of the application to the response message 408 and returns it as a new response message 409.

  FIG. 5 is an explanatory diagram of a second embodiment of a communication system that executes an application. The communication system 400 of FIG. 5 is an extension of the first embodiment of FIG. 4 and performs the method of the first embodiment after adding a destination element object determination method. In this case, application execution is performed in the following procedure. In FIG. 5, each part given the same reference number as in FIG. 4 indicates the same part as in FIG. 4.

<Procedure 1>
As indicated by 501 in FIG. 5A, the requester 401 is necessary to execute the application for each of the application holding node 404, the data-a holding node 405, and the data-b holding node 406 on the communication system 400. The size of a simple element object (application, data). As a result, the requester 401 specifies the element object having the maximum size (hereinafter referred to as “specific object”). In the example of FIG. 5A, the application holding node 404, the data-a holding node 405, and the data-b holding node 406 are respectively “10 kB (kilobytes)” “1 MB” in response to a size search request from the requester 401. (Megabytes) "" 5kB "size is returned. In response to this, the requester 401 identifies the data-a holding node 405 that has responded “1 MB” as a specific object.

<Procedure 2>
As indicated by 502 in FIG. 5B, the requester 401 throws the destination of the request message as a specific object, and thereafter each node performs the same processing as in the first embodiment of FIG.

<Procedure 3>
As a result, application execution is executed in the following priority order. The node that has decided to execute the application acquires another element object on the spot, executes the application, and returns the result.
Priority 1: A node with a specific object.
Priority 2: A node on the route to a specific object.
Priority 3: A node near the node on the route (not on the route).

  As described above, the application is executed on the destination node or a node near the requester / a node near the requester or a node near the requester on the destination / requester location / route according to the characteristics of the application and the resource state of each node. Next, the application is executed on a node (not limited to a specific node) having resources for executing the application, including on the route and in the vicinity thereof. Here, “neighboring” means, for example, a node existing within k hops excluding a node on a route from a target node.

  FIG. 6 is a diagram illustrating a configuration example of a communication system 400 that performs application execution according to the first or second embodiment. The communication system 400 includes six nodes: a requester 401, a relay node-A 402, a relay node-B 403, an “application-1” holding node 404, a data-a holding node 405, and a data-b holding node 406. And configure the network. As an initial state, the “app-1” main body is deployed in the “app-1” holding node 404, the “data-a” main body is deployed in the data-a holding node 405, and the “data-b” main body is deployed in the data-b holding node 406. In order to execute the application, these element objects are required. The requester 401 issues an execution request for this application.

  FIG. 7 is a diagram illustrating a hardware configuration example of a communication device that configures one of the nodes 401 to 406 in FIG. The node is a general-purpose server in terms of hardware. As shown in FIG. 7, a processor 701, a memory 702, a storage device 703, a transmission / reception interface (for data communication) 704, and a transmission / reception interface (for management) 705 are provided. The buses 706 are connected to each other. The storage device 703 is, for example, a hard disk storage device. The transmission / reception interface (for data communication) 704 is hardware for connecting a node to a LAN (local area network), for example. The transmission / reception interface (for management) 705 is hardware for connecting a node to a maintenance network to which a management server is connected, for example. The node performs an operation defined as a program by the processor 701 executing a program deployed in the memory 702 or the storage device 703.

  FIG. 8 is a diagram illustrating a format example of the request message 407 and the response messages 408 and 409 communicated in the communication system 400 that performs application execution according to the first or second embodiment.

  As shown in FIG. 8A, the request message 407 includes a header part having an execution policy bit PL, an application holding bit AH, and an application executable bit AE, and a Name part. Each definition is as follows.

  Execution policy bit PL (PoLicy): This bit takes a value of 0 or 1. From the viewpoint of delay and transfer amount, it is advantageous that the target application is executed near the requester 401 (PL = 0), or it is more advantageous to execute it near the requester 401 (= near the application or data) ( PL = 1). From the characteristics of the target application, the former is determined when the input data amount is smaller than the output data amount (for example, simple merging of data), and the latter is determined when the opposite is true (for example, image analysis). When the requester 401 sends a request message, or when an edge node relays the request message, the execution policy bit PL is set based on the above determination result.

  Application holding bit AH (Apphold): This bit takes a value of 0 or 1. This indicates whether any node does not have the application specified in the Name part (FIG. 8A) of the request message 407 (AH = 0) or has (AH = 1). The requester 401 itself first sets a value in the application holding bit AH of the request message 407 according to the application holding status, and transmits the request message 407. If the node on the route has the designated application (including the neighborhood), the value 1 is set in the application holding bit AH of the received request message 407. The value is not changed.

  Application executable bit AE (AppExec): This bit takes a value of 0 or 1. This indicates whether any node does not have a resource (CPU or memory) for executing an application specified in the Name part of the request message 407 (AE = 0) or has (AE = 1). The requester 401 itself first sets a value in the application executable bit AE of the request message 407 according to the possession status of the resource for executing the application, and sends the request message 407. If a node on the route has a resource (including a neighborhood), the value 1 is set to the application executable bit AE of the received request message 407, and if the node does not have a resource, the value of that bit is set. Does not change.

  Name part: This is a variable-length field that specifies the application execution to be requested. Name character strings of element objects (applications and data) necessary for executing the application are concatenated with “+” and displayed in the Name part. For example, the Name part is expressed as “data−a + application−1 + data−b”. “Data-a”, “application-1”, and “data-b” written in the Name part are names of the respective element objects. The request message 407 is routed toward the element object corresponding to the first name of the Name part (in this case, “data-a”). In advance, routing information corresponding to each element object is broadcast from the location of each element object in the network, and each node constitutes a routing table for the name of the element object. Upon receiving the request message 407, each node determines an output interface for the top element object of the Name part by using the Longest Prefix Match, and routes the received request message 407 to the output interface.

  Next, as shown in FIG. 8B, the response messages 408 and 409 are composed of a header part having an execution policy bit PL, an application holding bit AH, and an application executable bit AE, a Name part, and a Content part. Consists of. Meanings other than the Content part are the same as those of the request message 407 in FIG. However, the application holding bit AH and the application executable bit AE are not set again by each node, but are copied from the request message at the destination node. The application holding bit AH and the application executable bit AE are reset to 0 and passed to the next node only when the application is executed on the intermediate node. Further, the routing of the response messages 408 and 409 is not performed by the Name part, but each node remembers the transmission source of the request message 407 corresponding to the response message 408 and 409 and sends it to the transmission source. The definition of the Content part is as follows.

  Content part: A variable-length field in which the execution result of the requested application or an element object (application, data) is stored. In the node, before the application is executed, the body of the element object is stored in the Content part. For example, in the response message 408 of FIG. 4, the element object “data-a” stored in the data-a holding node 405 is stored in the Content portion. After the application is executed, the execution result of the application is stored in the Content section. For example, this is the case of the response message 409 in FIG.

  FIG. 9 is a diagram illustrating a configuration example of a PL setting table for setting the execution policy bit PL. As described in <Procedure 1> of the first embodiment of FIG. 4, the request message 407 includes an execution policy bit PL, an application holding bit AH, and an application executable bit, as indicated by a broken line frame 409 in FIG. AE is added. At this time, in the application characteristics, whether the destination neighborhood priority (= 1) or the requester neighborhood priority (= 0) is set according to the above-described procedure. As described above, the execution policy bit PL is set by the requester 401 or the edge node. Here, in many applications, the size relationship between the above-mentioned “Σ (input data)” and “output data” can be estimated in advance, and therefore the value of the execution policy bit PL can also be estimated in advance. Therefore, in this embodiment, for example, the requester 401 or the edge node includes a PL setting table shown in FIG. 9 for determining whether the value of the execution policy bit PL is set to 1 or 0 for each application. The requester 401 or the edge node adds to the request message 407 by referring to, for example, the PL setting table in FIG. 9 stored in the memory 702 or the storage device 703 in FIG. 7 for each application that requests execution. The value of the execution policy bit PL to be determined is determined.

  In the example of FIG. 9, when the application is an image analysis application, the input data is image data, and the output data is an image analysis result, so “output data <Σ (input data)”. In this case, for example, when the application is executed in, for example, the relay node-B 403 in the vicinity (far from the requester 401) of the data-a holding node 405 that holds the “data-a” main body that is image data, for example, The transfer distance of the data-a "body is shortened, and the execution efficiency of the application is good. Therefore, in the PL setting table of FIG. 9, 1 is stored as the value of the execution policy bit PL for the image analysis application.

  When the application is a map search application, the input data is latitude / longitude data or a character string keyword representing a point, and the output data is map data, so “output data> Σ (input data)”. In this case, when the application is executed in the vicinity of the requester 401 that receives the execution result of the application that is output data, for example, in the relay node-A 402, the transfer distance of the output data is shortened, and the execution efficiency of the application is improved. good. Therefore, in the PL setting table of FIG. 9, 0 is stored as the value of the execution policy bit PL for the map search application.

  Furthermore, when the application is a sensor data analysis application, since the input data is sensor data and the output data is an analysis result, generally “output data <Σ (input data)”. In this case, for example, when the application is executed in, for example, the relay node-B 403 in the vicinity (far from the requester 401) of the data-a holding node 405 that holds the “data-a” main body that is sensor data, The transfer distance of the data-a "body is shortened, and the execution efficiency of the application is good. Therefore, in the PL setting table of FIG. 9, 1 is stored as the value of the execution policy bit PL for the sensor data analysis application.

  FIG. 10 is a flowchart illustrating an example of a message transfer process of the relay node-A 402 or the relay node-B 403 in the communication system 400 that performs application execution according to the first or second embodiment described above. In this message transfer processing, for example, the processor 701 in FIG. 7 constituting the relay node-A 402 or the relay node-B 403 executes a message transfer processing program loaded from, for example, the storage device 703 and stored in the memory 702. Is the action.

  First, when receiving a message, the processor 701 determines the message type (step S1001). For example, the message type is separately defined by a header or the like.

  If it is determined in step S1001 that the received message is the request message 407, the processor 701 first determines whether the own node has the application specified in the Name part of the request message 407 (see FIG. 8A). Is checked (step S1002).

  If the determination in step S1002 is YES, the processor 701 sets a value 1 to the application holding bit AH of the request message 407 to be received and transferred. In addition, the processor 701 sets the application holding bit AH, and first sets AH from the value 0 to the value 1 (AH of the received request message 407 is 0, and the own node rewrites AH to 1). Is recorded in the memory 702 (step S1003).

  If the determination in step S1002 is NO, the processor 701 skips the process in step S1003 and does not rewrite the AH bit value in the header portion of the request message 407.

  Next, the processor 701 checks whether or not the own node has a resource for application execution specified in the Name part of the request message 407 (see FIG. 8A) (step S1004). Here, “resource” means, for example, hardware resources such as a processor 701 and a memory 702 that can execute a specified application, and / or a software environment that can execute a specified application.

  If the determination in step S1004 is YES, the processor 701 sets a value 1 to the application executable bit AE of the request message 407 to be received and transferred. In addition, the processor 701 sets the application executable bit AE, and first sets the AE from the value 0 to the value 1 (the AE of the received request message 407 is 0, and the own node rewrites the AE to 1. Or not) is recorded in the memory 702 (step S1005).

  If the determination in step S1004 is NO, the processor 701 skips the process in step S1005 and does not rewrite the AE bit value in the header portion of the request message 407.

  After a series of control processes from steps S1002 to S1005, the processor 701 transfers the received request message 407 to the next node with the first element object of the Name part as the destination (step S1006). Then, the processor 701 ends the message transfer process shown in the flowchart of FIG.

  If it is determined in step S1001 that the received messages are the response messages 408 and 409, the processor 701 first checks the value of each bit in the header part of the response messages 408 and 409, thereby starting from the following step S1007. A series of determination processing up to S1010 is executed.

  First, the processor 701 stores in the memory 702 whether the value of the execution policy bit PL is 1, the value of the application holding bit AH is 1, and the own node sets the application holding bit AH to 1. Is determined (step S1007). In FIG. 10, “and” is indicated by an “&” symbol and represents a logical product.

  If the determination in step S1007 is YES, the processor 701 proceeds to the process in step S1011 and performs an application execution process.

  If the determination in step S1007 is NO, the processor 701 indicates that the value of the execution policy bit PL is 1, the value of the application executable bit AE is 1, and the own node sets the application executable bit AE to 1. Is stored in the memory 702 (step S1008).

  If the determination in step S1008 is YES, the processor 701 proceeds to the process in step S1011 and performs an application execution process.

  As will be described later, the destination, for example, the data-a holding node 405 returns a response message 408 having each bit value of the header part of the request message 407 as it is to the transfer path and the reverse path. Each node such as the relay node-A 402, the relay node-B 403, and the data-a holding node 405 stores the node from which each request message 407 is received. When each node receives the response messages 408 and 409, each node forwards the received response messages 408 and 409 to the source node stored for the corresponding request message 407. As a result, the response messages 408 and 409 are relayed to the reverse path to the transfer path on which the corresponding request message 407 is relayed. In step S1007 or S1008, for example, if the relay node-B 403 first determines that the AH or AE value of the response message 408 is 1, and the record of the AH or AE value in the own node is 1. The own node becomes the application executable node closest to the destination node. Therefore, in this case, if the value of the execution policy bit PL of the response messages 408 and 409 is set to the destination neighborhood priority value 1, the relay node-B 403 that is the own node is the node that should perform the application execution process. It can be determined that there is. As the priority of determination at this time, it is first determined whether or not the own node holds the application (step S1007), and then it is determined whether or not the own node has resources for executing the application (step S1007). S1008).

  If the determination in step S1008 is NO, the processor 701 indicates that the value of the execution policy bit PL is 0, the value of the application holding bit AH is 1, and the own node first sets the application holding bit AH to 1 Is stored in the memory 702 (step S1009).

  If the determination in step S1009 is YES, the processor 701 proceeds to the process in step S1011 and performs an application execution process.

  If the determination in step S1009 is NO, the processor 701 sets the value of the execution policy bit PL to 0, the value of the application executable bit AE to 1, and the node itself first sets the application executable bit AE to 1. It is determined whether or not this is stored in the memory 702 (step S1010).

  If the determination in step S1010 is YES, the processor 701 proceeds to the process in step S1011 and performs an application execution process.

  In step S1009 or S1010, for example, if the relay node-A 402 determines that the AH or AE value of the response message 408 is 1 and that the own node first sets AH or AE, the own node sets the requester 401. The closest app executable node. Therefore, in this case, if the value of the execution policy bit PL of the response messages 408 and 409 is set to the requester neighborhood priority value 0, the relay node-A 402 that is the own node is the node that is to perform the application execution process. It can be determined that there is. As the priority of determination at this time, it is first determined whether or not the own node holds the application (step S1009), and then it is determined whether or not the own node has resources for executing the application (step S1009). S1010).

  If any of the series of determinations in steps S1007 to S1010 is YES, the processor 701 performs an application execution process (step S1011).

  In step S <b> 1011, the processor 701 acquires another element object necessary for application execution that is not held by the self-node by using another request message, and executes the application. That is, the processor 701 holds the own node among the element object groups “application-1”, “data-a”, “data-b” and the like specified in the Name part of the received response messages 408 and 409. The following processing is executed for the element objects that are not. The processor 701 creates a request message in which the element object is specified in the Name part, and transmits it to the network. As a result, the processor 701 acquires the element object from the “application-1” holding node 404, the data-a holding node 405, or the data-b holding node 406 (see FIG. 4) that is destined for the element object. To do.

  In step S1011, when the application execution is completed, the processor 701 generates the following response message 409. In this response message 409, the processor 701 resets both the application holding bit AH and the application executable bit AE in the header part to 0 so that other nodes do not execute the application, and the Content part (FIG. 8 (b) Store the application execution result in ()).

  After the process of step S1011 described above, the processor 701 transfers the generated response message 409 toward the node in the direction in which the request message 407 having the same header part as that of the response message 409 is received (step S1012). ).

  If the determination in step S1010 is NO, the processor 701 receives the request message 407 having the same header part as that of the response message 409 without receiving the received response messages 408 and 409. Transfer to the node (step S1012).

  After that, the processor 701 ends the message transfer process shown in the flowchart of FIG.

  Seven operation examples of the first embodiment based on the configurations of FIGS. 7 to 9 and the message transfer process of FIG. 10 will be described below.

  First, a first operation example in the first embodiment will be described with reference to the explanatory diagram of FIG. 4 and the sequence diagram of FIG. The first operation example shown in FIGS. 4 and 11 is an example in which the execution policy bit PL is set to 1 and only the relay node-B 403 has resources for application execution.

<Operation pattern 1>
The requester 401 sets the value of the execution policy bit PL of the request message 407 to be transmitted to 0 or 1 by referring to the PL setting table of FIG. 9 from the characteristics of the application to be executed. As described above, the execution policy bit PL may be set not by the requester 401 but by the relay node-A 402 (see FIG. 6) corresponding to the edge node. The requester 401 configures the destination (first object, Routeable Prefix) indicated by the Name part of the request message 407 to be one of the element objects (application or data), and transmits the request message 407.

  In the first operation example of FIGS. 4 and 11, the application to be executed is a case where “output data <Σ (input data)”, such as an image analysis application or a sensor data analysis application. As a result, the requester 401 sets the execution policy bit PL of the request message 407 to be transmitted to a value 1 indicating destination neighborhood priority by referring to the PL setting table of FIG. Next, in the first operation example of FIG. 4, the requester 401 sets the name “data−a + application−1 + data−b” as the Name part of the request message 407. As a result, the destination node is the data-a holding node 405 that holds the “data-a” body corresponding to the name “data-a” at the head of the Name part. In this way, the requester 401 sets PL = 1, AH = 0, and AE = 0 in accordance with <Operation pattern 1> described above, and stores “data-a + application-1 + data-b” in the Name portion. 407 is generated (S1101 in FIG. 11). Then, the requester 401 transfers the generated request message 407 to the relay node-A 402 according to the above-described <operation pattern 1> (S1102). In FIG. 11, the request message 407 in which “data−a + application−1 + data−b” is stored in the Name portion is simply expressed as “request (a + 1 + b)”.

  Each of the relay node-A 402 and the relay node-B 403 on the route to the destination node that has received the request message 407 performs the message transfer process described above according to a series of control operations in steps S1001 to S1006 in the flowchart of FIG. Run like this.

<Operation pattern 2>
If the relay node has a designated application in the request message 407 including the neighboring nodes (thick arrows), the determination of steps S1001 → S1002 in FIG. 10 executes the control of YES → S1003 → S1006. As a result, the relay node turns on the application holding bit AH of the request message 407 (sets to value 1), sets AH = 1, and whether or not AH = 1 is initially set in the memory 702. To remember. Thereafter, the relay node forwards the request message 407.

<Operation pattern 3>
As for the relay node, there is no designated application including a neighboring node (thick arrow), but if there is a resource to be executed, the determination of step S1001 → S1002 in FIG. 10 is NO → the determination of S1004 is YES → S1005 → S1006 Execute. As a result, the relay node turns on the application executable bit AE of the request message 407 and stores in the memory 702 whether AE = 1 is set and whether AE = 1 is first set. Thereafter, the relay node forwards the request message 407.

<Operation pattern 4>
If there is no designated application and its execution resource including the neighboring node (thick arrow), the relay node executes the control of step S1001 → S1002 in FIG. 10 NO → S1004 is determined NO → S1006. As a result, the relay node transfers the request message 407 as it is.

  In the above operations 2, 3, or 4, each node searches for within k hops of its own node as “neighboring” of its own node, or has information in advance by examining it.

  In the first operation example shown in FIGS. 4 and 11, the relay node-A 402 has neither “application-1”, which is the designated application, nor resources for executing it. For this reason, the relay node-A 402 keeps both the application holding bit AH and the application executable bit AE of the request message 407 at the value 0 in accordance with the above-described <operation pattern 4>, and sends the request message 407 to the relay node-B. Relay to 403 (S1103 in FIG. 11).

  Next, the relay node-B 403 does not have “application-1”, but has resources to execute it. For this reason, the relay node-B 403 turns on the application executable bit AE in the request message 407 according to the above-described <operation pattern 3> (rewrites the value to 1). Further, the relay node-B 403 stores in the memory 702 that AE = 1 is set and that AE = 1 is first set (S1104 in FIG. 11). Then, the relay node-B 403 transfers the request message 407 to the data-a holding node 405 (S1105 in FIG. 11).

  The destination node (data-a holding node 405 in the example of FIG. 4) operates as follows by determining each bit of the header of the request message 407.

<Operation pattern 5>
If the destination node holds the designated application in the request message 407 or has a resource for its execution, the own node executes the designated application. As a result, the destination node stores the application execution result in the Content part (see FIG. 8B) of the response message 408, and relays the response message 408 to a path opposite to the path of the corresponding request message 407. . At this time, the destination node clears the application holding bit AH and the application executable bit AE in the header part of the response message 408 (to 0).

<Operation pattern 6>
If the destination node has neither the application specified in the request message 407 nor the resource to execute it, and if the application holding bit AH or the application executable bit AE of the request message 407 is on, the following operation is executed. The destination node creates a response message 408, copies the bit values of PL, AH, and AE of the request message 407 in the header portion thereof, and stores the “data-a” body in the Content portion. Then, the destination node returns the response message 408 to the path opposite to the path of the request message 407 corresponding thereto.

<Operation pattern 7>
If the destination node has neither the application specified in the request message 407 nor the resource for its execution, and both the application holding bit AH and the application executable bit AE of the request message 407 are off (value 0), Perform the action. The destination node stores the error (cannot execute the application) in the content part of the response message 408, and returns the response message 408 to the path opposite to the path of the corresponding request message 407.

  The first operation example of FIG. 4 and FIG. 11 is a case where the data-a holding node 405 that is the destination node has neither the application specified in the request message 407 nor the resource for its execution, and the application execution of the request message 407 This is the case when only the possible bit AE is on. Therefore, the data-a holding node 405 executes the following operation in accordance with <Operation pattern 6> described above. The data-a holding node 405 creates a response message 408, copies the bit values of PL, AH, and AE of the request message 407 in the header portion thereof, and stores the “data-a” body in the Content portion ( S1106 in FIG. Then, the data-a holding node 405 transfers the response message 408 to the relay node-B 403 (S1107 in FIG. 11). In FIG. 11, a response message 408 in which the name “data-a + app-1 + data-b” is stored in the Name portion and the “data-a” main body is stored in the Content portion is referred to as “response (a + 1 + b, data -A) ".

  The relay node on the path that has received the response message 408 from the destination node executes the above-described message transfer process according to a series of control operations from steps S1001 to S1007 to S1012 in the flowchart of FIG.

<Operation pattern 8>
The PL bit of the header part of the response message 408 = 1 (destination neighborhood priority), and either the AH or AE bit is on, and the own node including the neighborhood turns on the AH or AE bit. In this case, the relay node performs the following operation. The relay node executes step S1011 when the determination in step S1007 or S1008 in FIG. 10 is YES. This condition applies to the destination node that first received the response message 408 sent from the destination node among the relay nodes having the application specified in the Name part of the response message 408 or the resource for executing the application. It is established at a nearby node. On the other hand, the PL bit of the header part of the response message 408 = 0 (priority in the requester vicinity), and either the AH or AE bit is ON, and the own node including the vicinity sets the AH or AE bit to “first”. When “ON” is selected, the relay node performs the following operation. The relay node executes step S1011 when the determinations of steps S1007 and S1008 in FIG. 10 are NO, and then the determination of either step S1009 or S1010 is YES. This condition is applied to the node of the requester 401 that finally receives the response message 408 sent from the destination node among the relay nodes having the application specified in the Name part of the response message 408 or the resource for executing the application. It is established at the nearest node. When any of the above conditions is satisfied, the relay node acquires another element object necessary for executing the application that is not held by the own node by another request message in step S1011 in FIG. 1, and executes the application. When the application execution is completed, the relay node newly generates a response message 409. In the generated response message 409, the relay node resets both the application holding bit AH and the application executable bit AE in the header part to 0 so that other nodes do not execute the application, and the application execution result in the Content part Is stored. Thereafter, in step S1012 of FIG. 10, the relay node relays the generated response message 409 to the source of the request message 407 having the same header part as the header part (a path opposite to the path of the request message 407).

<Operation pattern 9>
In the determination of the response message 408, in cases other than the above <operation pattern 8>, all the determinations in steps S1007 to S1010 in FIG. 10 are NO. As a result, in step S1012, the relay node relays the response message 408 as it is to the source of the request message 407 having the same header portion as the header portion (the route opposite to the route of the request message 407).

  In the first operation example of FIGS. 4 and 11, when the response message 408 arrives at the relay node-B 403, its PL bit = 1, its AE bit is on, and the relay node-B 403 Stores that AE = 1 is set in the memory 702. Therefore, the relay node-B 403 determines that “application-1” should be executed in accordance with the above-described <operation pattern 8>. First, the relay node-B 403 generates another request message in which the name “data-b” corresponding to one of the element objects that the node itself does not hold is stored in the Name part, and the request message is transmitted to the network. Transmit (S1108 in FIG. 11). In FIG. 11, this separate request message is simply expressed as “request (b)”. In response to this separate request message, the data-b holding node 406 returns a response message in which the “data-b” body is stored in the Content section to the relay node-B 403 (S1109 in FIG. 11). In FIG. 11, this response message is simply expressed as “response (b)”. Similarly, the relay node-B 403 generates another request message in which the name “application-1” corresponding to one of the element objects that the node itself does not hold is stored in the Name part, and the request message is The data is transmitted to the network (S1110 in FIG. 11). In FIG. 11, this separate request message is simply expressed as “request (1)”. In response to this separate request message, the “application-1” holding node 404 returns a response message in which the “application-1” main body is stored in the Content section to the relay node-B 403 (S1111 in FIG. 11). In FIG. 11, this response message is simply expressed as “response (1)”. Thereafter, the relay node-B 403 extracts the “data-a” main body stored in the response message 408, and the program indicated by the “app-1” main body using “data-a” and “data-b” as input data. Is executed (S1112 in FIG. 11). As a result, the relay node-B 403 resets the application executable bit AE to 0 in the header part (the application holding bit AH is originally 0), and generates a new response message 409 in which the execution result is stored in the Content part ( S1113 in FIG. The reason for setting AE = 0 is to prevent other nodes from executing the application. Then, the relay node-B 403 transfers the response message 409 to the relay node-A 402 (S1114 in FIG. 11). In FIG. 11, the response message 409 is simply expressed as “response (a + 1 + b, execution result)”.

  In the relay node-A 402, the application holding bit AH and the application executable bit AE in the header part of the received response message 409 are both off, and the designated application “application-1” and its execution resource are both do not have. Therefore, the relay node-A 402 relays the received response message 409 as it is to the requester 401 in accordance with <Operation pattern 9> described above (S1115 in FIG. 11).

  The requester 401 extracts and receives the execution result of the application from the Content part of the received response message 409.

As described above, in the first embodiment, when the value of the execution policy bit PL is set to 1 (destination neighborhood priority), application execution is performed in the following priority order.
Priority 1: A node with an element object of maximum size.
Priority 2: A node on the path to the element object (a node as close to the destination element object as possible).
Priority 3: A neighboring node of a node on the route (a node that is not on the route but is within a hop from the node on the route).

  Next, a second operation example in the first embodiment will be described with reference to an explanatory diagram of FIG. 12 and a sequence diagram of FIG. The second operation example shown in FIGS. 12 and 13 is an example in which the execution policy bit PL is set to 1 and only the relay node-A 402 has an application execution resource. The simplified notation in FIG. 13 is the same as in the first operation example in FIG.

  First, the requester 401 executes the following control operation in accordance with <Operation pattern 1> described above. In the second operation example of FIG. 12, as in the case of the first operation example of FIG. 4, the application to be executed is “output data <Σ ( Input data) ”. As a result, the requester 401 executes the following control operation in accordance with <Operation pattern 1> described above. The requester 401 refers to the PL setting table of FIG. 9 and sets a value 1 representing destination neighborhood priority to the execution policy bit PL of the request message 407 to be transmitted. Further, the requester 401 sets the name “data−a + application−1 + data−b” as the name part of the request message 407 (S1301 in FIG. 13). Then, the requester 401 transmits the request message 407 generated in this way to the relay node-A 402 (S1302 in FIG. 13).

  The relay node-A 402 and the relay node-B 403 on the route to the destination node respectively follow <operation pattern 2>, <operation pattern 3>, or <operation pattern 4> described above in the description of the first operation example. Execute message transfer processing.

  In the second operation example of FIGS. 12 and 13, the relay node-A 402 does not have “application-1”, but has resources for its execution. Therefore, the relay node-A 402 executes the following control operation in accordance with <Operation pattern 3> described above. The relay node-A 402 turns on the application executable bit AE in the request message 407. Further, the relay node-A 402 stores in the memory 702 (FIG. 7) that AE = 1 is set for the request message 407 and that AE = 1 is set first (FIG. 7). 13 S1303). Then, the relay node-A 402 transfers the request message 407 to the relay node-B 403 (S1304 in FIG. 13).

  Next, the relay node-B 403 has neither “application-1”, which is the designated application, nor the resource for its execution. For this reason, the relay node-B 403 transfers the request message 407 to the data-a holding node 405 without changing the values of AH and AE in accordance with <Operation pattern 4> described above (S1305 in FIG. 13). .

  The data-a holding node 405 that is the destination node has neither “application-1” specified by the request message 407 nor the resource for its execution, and only the application executable bit AE of the request message 407 is on. Accordingly, the data-a holding node 405 executes the following operation in accordance with <Operation pattern 6> described above, similarly to the first operation example of FIG. The data-a holding node 405 creates a response message 408, copies the bit values of PL, AH, and AE of the request message 407 in the header portion thereof, and stores the “data-a” body in the Content portion ( S1306 in FIG. Then, the data-a holding node 405 transfers the response message 408 to the relay node-B 403 (S1307 in FIG. 13).

  The relay node on the path that has received the response messages 408 and 409 from the data-a holding node 405 responds according to <Operation pattern 8> or <Operation pattern 9> described above in the description of the first operation example. The transfer process / application execution process is executed.

  In the relay node-B 403, PL = 1 and AE = 1 in the received response message 409, but “node 1” specified in the Name part of the response message 408 including its neighbors and its execution I don't have any of these resources. Accordingly, the relay node-B 403 relays the received response message 409 as it is to the relay node-A 402 in accordance with <Operation pattern 9> described above (S1308 in FIG. 13).

  In the relay node-A 402, when the response message 408 arrives, the PL bit = 1, the AE bit is on, and the relay node-A 402 sets AE = 1 in the memory 702 Is remembered. Therefore, the relay node-A 402 determines that “application-1” should be executed in accordance with the above-described <operation pattern 8>. As a result, the relay node-A 402 executes a series of control operations from S1309 to S1312 in FIG. 13 in the same manner as the series of control operations from S1108 to S1111 in the first operation example in FIG. As a result, the relay node-A 402 transmits the “application-1” main body and the “data-b” main body, which are not held by the own node, via the relay node-B 403, respectively, according to another request message. Obtained from the 1 ″ holding node 404 and the data-b holding node 406. Thereafter, the relay node-A 402 retrieves the “data-a” main body stored in the response message 408 and uses the “data-a” and “data-b” as input data to indicate the program indicated by the “app-1” main body. Is executed (S1313 in FIG. 13). As a result, the relay node-A 402 resets the application executable bit AE to 0 in the header part (the application holding bit AH is originally 0), and generates a new response message 409 in which the execution result is stored in the Content part ( S1314 in FIG. Then, the relay node-A 402 transfers the response message 409 to the requester 401 (S1315 in FIG. 13).

  Finally, the requester 401 receives the execution result of the application from the Content part of the received response message 409.

  As described above, in the second operation example of FIGS. 12 and 13, the requester 401 designates the execution policy bit PL = 1 (destination priority) when the request message 407 is transmitted. However, none of the relay nodes holds “application-1”, and the relay node having the resource for executing “application-1” is only the relay node-A 402. Therefore, the relay node-A 402 that can only execute “application-1”, although it is a relay node far from the data-a holding node 405 that is the destination node, executes “application-1”.

  Next, a third operation example in the first embodiment will be described with reference to an explanatory diagram of FIG. 14 and a sequence diagram of FIG. The third operation example shown in FIGS. 14 and 15 is an example in which the execution policy bit PL is set to 1 and both the relay node-A 402 and the relay node-B 403 have application execution resources. . The simplified notation in FIG. 15 is the same as in the first operation example in FIG.

  First, the requester 401 executes the following control operation in accordance with <Operation pattern 1> described above. In the third operation example of FIGS. 14 and 15, as in the case of the first operation example of FIGS. 4 and 11, the application to be executed is, for example, an image analysis application or a sensor data analysis application, This is a case where “output data <Σ (input data)”. As a result, the requester 401 sets the execution policy bit PL of the request message 407 to be transmitted to a value 1 indicating destination neighborhood priority by referring to the PL setting table of FIG. Further, the requester 401 sets the name “data−a + application−1 + data−b” as the Name part of the request message 407 (S1501 in FIG. 15). The requester 401 transmits the request message 407 generated in this way to the relay node-A 402 (S1502 in FIG. 15).

  The relay node-A 402 and the relay node-B 403 on the route to the destination node respectively follow <operation pattern 2>, <operation pattern 3>, or <operation pattern 4> described above in the description of the first operation example. Execute message transfer processing.

  In the third operation example of FIG. 14, the relay node-A 402 does not have “application-1” but has resources for executing it. Therefore, the relay node-A 402 turns on the application executable bit AE in the request message 407 in accordance with the above-described <operation pattern 3>. Further, the relay node-A 402 stores in the memory 702 (FIG. 7) that AE = 1 is set for the request message 407 and that AE = 1 is set first. (S1503 in FIG. 15). Then, the relay node-A 402 transfers the request message 407 to the relay node-B 403 (S1504 in FIG. 15).

  Next, similarly to the relay node-A 402, the relay node-B 403 also does not hold “application-1” but has resources for its execution. Perform the operation. First, the relay node-B 403 also overwrites the application executable bit AE in the request message 407. In this case, since the AE bit of the received request message 407 has already become the value 1, the state does not change. Further, the relay node-B 403 stores in the memory 702 (FIG. 7) that AE = 1 is set for the request message 407. Note that since the AE bit of the received request message 407 has already been set to value 1, the relay node-B 403 does not store that AE = 1 was initially set (S1505 in FIG. 15). Then, the relay node-B 403 transfers the request message 407 to the data-a holding node 405 (S1506 in FIG. 15).

  The data-a holding node 405 does not have both “application-1” and its execution resources, and the application executable bit AE of the request message 407 is on, so that it is the same as in the first operation example of FIG. In addition, the following operation is executed in accordance with <Operation Pattern 6> described above. The data-a holding node 405 generates a response message 408 in which the bit values of PL, AH, and AE of the request message 407 are copied in the header portion, and the “data-a” body is stored in the Content portion (FIG. 15 S1507). Then, the data-a holding node 405 returns the generated response message 408 to the relay node-B 403 (S1508 in FIG. 15).

  The relay node on the path that has received the response messages 408 and 409 from the data-a holding node 405 responds according to <Operation pattern 8> or <Operation pattern 9> described above in the description of the first operation example. The transfer process / application execution process is executed.

  In the relay node-B 403, when the response message 408 arrives, the execution policy bit PL = 1, the application executable bit AE is turned on, and the relay node-B 403 stores AE = It remembers that 1 was set. Therefore, the relay node-B 403 determines that “application-1” should be executed according to the above-described <operation pattern 8>, similarly to the case of the first operation example of FIG. As a result, the relay node-B 403 executes a series of operations from S1509 to S1515 in FIG. 15 similar to the series of operations from S1108 to S1114 in the first operation example in FIG. The relay node-B 403 acquires application-1 ”,“ data-a ”,“ data-b ”, executes the application, the AE (and AH) bit is reset to 0, and the application execution result is displayed in the Content section. The stored response message 409 is generated and relayed to the relay node-A 402.

  The relay node-A 402 has a resource for executing “application-1”, but “application-1” has already been executed by the relay node-B 403, and the application holding bit in the header portion of the received response message 409. Both AH and application executable bit AE are off. Accordingly, the relay node-A 402 relays the received response message 409 as it is to the requester 401 in accordance with <Operation pattern 9> described above (S1516 in FIG. 15).

  Finally, the requester 401 receives the execution result of the application from the Content part of the received response message 409.

  As described above, in the third operation example of FIGS. 14 and 15, the requester 401 specifies the execution policy bit PL = 1 (destination neighborhood priority) when the request message 407 is transmitted. Therefore, the relay node-B 403 closer to the data-a holding node 405 that is the destination node among the relay node-A 402 and the relay node-B 403 having resources for executing “application-1” is “ Application-1 "will be executed.

  Next, a fourth operation example in the first embodiment will be described with reference to an explanatory diagram of FIG. 16 and a sequence diagram of FIG. The fourth operation example shown in FIGS. 16 and 17 is an example in which the execution policy bit PL is set to 0 and only the relay node-B 403 has an application execution resource. The simplified notation in FIG. 17 is the same as in the first operation example in FIG.

  First, the requester 401 executes the following control operation in accordance with <Operation pattern 1> described above. In the fourth operation example of FIGS. 16 and 17, the application to be executed is a case where “output data> Σ (input data)”, for example, a map search application. As a result, the requester 401 sets the value 0 representing the vicinity of the requester to the execution policy bit PL of the request message 407 to be transmitted by referring to the PL setting table of FIG. Further, the requester 401 sets the name “data-a + application-1 + data-b” as the Name part of the request message 407 (S1701 in FIG. 17). Then, the requester 401 transmits the request message 407 generated in this way to the relay node-A 402 (S1702 in FIG. 17).

  The relay node-A 402 and the relay node-B 403 on the route to the destination node respectively follow <operation pattern 2>, <operation pattern 3>, or <operation pattern 4> described above in the description of the first operation example. The transfer process of the request message 407 is executed.

  In the fourth operation example of FIGS. 16 and 17, a series of control operations from S1703 to S1707 in FIG. 17 at the relay node-A 402, the relay node-B 403, and the data-a holding node 405 are the same as those in FIG. This is the same as the series of operations from S1103 to S1107 in the first operation example.

  The relay node on the path that has received the response message 408 from the data-a holding node 405 transfers the response messages 408 and 409 in accordance with <Operation pattern 8> or <Operation pattern 9> described above in the description of the first operation example. A process and / or an application execution process is executed.

  In this case, the relay node-B 403 that has received the response message 408 executes a series of operations from S1708 to S1714 in FIG. 17 similar to the series of operations from S1108 to S1114 in the first operation example in FIG. The relay node-B 403 acquires application-1 ”,“ data-a ”,“ data-b ”, executes the application, the AE (and AH) bit is reset to 0, and the application execution result is displayed in the Content section. The stored response message 409 is generated and relayed to the relay node-A 402.

  Since the relay node-A 402 has AH = 0 and AE = 0 in the received response message 409, as in the case of the first operation example shown in FIG. 409 is transferred as it is to the requester 401 (S1715 in FIG. 17).

  Finally, the requester 401 receives the execution result of the application from the Content part of the received response message 409.

  As described above, in the fourth operation example shown in FIGS. 16 and 17, the requester 401 specifies the execution policy bit PL = 0 (requester neighborhood priority) when the request message 407 is transmitted. However, none of the relay nodes holds “application-1”, and only the relay node-B 403 has a resource for executing “application-1”. Therefore, although it is a relay node far from the requester 401, only the relay node-B 403 that can execute “application-1” executes “application-1”.

  Next, a fifth operation example in the first embodiment will be described with reference to an explanatory diagram of FIG. 18 and a sequence diagram of FIG. The fifth operation example shown in FIGS. 18 and 19 is an example in which the execution policy bit PL is set to 0, and only the relay node-A 402 has an application execution resource. The simplified notation in FIG. 19 is the same as in the first operation example in FIG.

  First, the requester 401 executes the following control operation in accordance with <Operation pattern 1> described above. In the fifth operation example of FIG. 18, as in the case of the fourth operation example of FIG. 16, the application to be executed is “output data> Σ (input data)” as in the map search application, for example. It is the case. As a result, the requester 401 sets the value 0 representing the vicinity of the requester to the execution policy bit PL of the request message 407 to be transmitted by referring to the PL setting table of FIG. Further, the requester 401 sets the name “data-a + application-1 + data-b” as the Name part of the request message 407 (S1901 in FIG. 19). Then, the requester 401 transfers the generated request message 407 to the relay node-A 402 according to <Operation pattern 1> described above (S1902 in FIG. 19).

  The relay node-A 402 and the relay node-B 403 on the route to the destination node respectively follow <operation pattern 2>, <operation pattern 3>, or <operation pattern 4> described above in the description of the first operation example. The transfer process of the request message 407 is executed.

  In the fifth operation example shown in FIGS. 18 and 19, the series of control operations from S1903 to S1907 in the relay node-A 402, the relay node-B 403, and the data-a holding node 405 are the same as those in the second operation shown in FIG. This is the same as the series of operations from S1303 to S1307 in the operation example.

  The relay node on the path that has received the response message 408 from the data-a holding node 405 transfers the response messages 408 and 409 in accordance with <Operation pattern 8> or <Operation pattern 9> described above in the description of the first operation example. A process and / or an application execution process is executed.

  In the received response message 409, the relay node-B 403 has PL = 0 and AE = 1, but its own node including the neighborhood includes the application specified in the Name part of the response message 408 and the resource of its execution. I don't have any. Therefore, the relay node-B 403 transfers the response message 408 as it is to the relay node-A 402 according to the above-described <operation pattern 9> (S1908 in FIG. 19).

  The relay node-A 402 executes a series of operations from S1909 to S1915 in FIG. 19 similar to the series of operations from S1309 to S1315 in the second operation example in FIG. The relay node-A 402 acquires application-1 ”,“ data-a ”,“ data-b ”and executes the application, the AE (and AH) bit is reset to 0, and the application execution result is displayed in the Content section. The stored response message 409 is generated and relayed to the requester 401.

  Finally, the requester 401 receives the execution result of the application from the Content part of the received response message 409.

  Next, a sixth operation example according to the first embodiment will be described with reference to an explanatory diagram of FIG. 20 and a sequence diagram of FIG. The sixth operation example shown in FIGS. 20 and 21 is an example in which the execution policy bit PL is set to 0 and both the relay node-A 402 and the relay node-B 403 have application execution resources. . The simplified notation in FIG. 21 is the same as in the first operation example in FIG.

  First, the requester 401 executes the following control operation in accordance with <Operation pattern 1> described above. In the sixth operation example of FIGS. 20 and 21, as in the case of the fourth operation example of FIG. 16, the application to be executed is “output data> Σ (input Data) ”. As a result, the requester 401 sets the value 0 representing the vicinity of the requester to the execution policy bit PL of the request message 407 to be transmitted by referring to the PL setting table of FIG. Further, the requester 401 sets the name “data−a + application−1 + data−b” as the Name portion of the request message 407 (S2101 in FIG. 21). Then, the requester 401 transmits the request message 407 generated in this way to the relay node-A 402 (S2102 in FIG. 21).

  The relay node-A 402 and the relay node-B 403 on the route to the destination node respectively follow <operation pattern 2>, <operation pattern 3>, or <operation pattern 4> described above in the description of the first operation example. The transfer process of the request message 407 is executed.

  In the sixth operation example of FIGS. 20 and 21, a series of control operations from S2103 to S2108 at the relay node-A 402, the relay node-B 403, and the data-a holding node 405 are the same as the third operation of FIG. This is the same as the series of operations from S1503 to S1508 in the operation example.

  The relay node on the path that has received the response message 408 from the data-a holding node 405 transfers the response messages 408 and 409 in accordance with <Operation pattern 8> or <Operation pattern 9> described above in the description of the first operation example. A process and / or an application execution process is executed.

  When the relay node-B 403 receives the response message 408 from the data-a holding node 405, the relay node-B 403 indicates that PL = 0, AE = 1, and the relay node-B 403 sets AE = 1 in the memory 702. I remember it. However, the relay node-B 403 does not store that AE = 1 is initially set in the memory 702. Accordingly, the relay node-B 403 transfers the response message 408 as it is to the relay node-A 402 in accordance with <Operation pattern 9> described above (S2109 in FIG. 21).

  Next, when the relay node-A 402 receives the response message 408 from the relay node-B 403, the relay node-A 402 has its PL = 0, AE = 1, and the relay node-A 402 first sets AE = 1 to the memory 702. I remember setting it. Therefore, the relay node-A 402 determines that “application-1” should be executed according to the above-described <operation pattern 8>. As a result, the relay node-A 402 executes a series of operations from S2110 to S2116 in FIG. 21 similar to the series of operations from S1309 to S1315 in the first operation example in FIG. The relay node-A 402 acquires application-1 ”,“ data-a ”,“ data-b ”and executes the application, the AE (and AH) bit is reset to 0, and the application execution result is displayed in the Content section. The stored response message 409 is generated and relayed to the requester 401.

  Finally, the requester 401 receives the execution result of the application from the Content part of the received response message 409.

  As described above, in the sixth operation example of FIGS. 20 and 1, the requester 401 designates the execution policy bit PL = 0 (requestor neighborhood priority) when the request message 407 is transmitted. Therefore, the relay node-A 402 closer to the requester 401 among the relay node-A 402 and the relay node-B 403 having the resource for executing the “application-1” executes “application-1”. become.

  Next, a seventh operation example according to the first embodiment will be described with reference to an explanatory diagram of FIG. 22 and a sequence diagram of FIG. In the seventh operation example shown in FIGS. 22 and 23, the execution policy bit PL is set to 1, the relay node-A 402 does not hold an application, has no resource for executing the application, and the relay node-B Reference numeral 403 denotes an example in which an application is held. The simplified notation in FIG. 23 is the same as in the first operation example in FIG.

  First, the requester 401 executes the following control operation in accordance with <Operation pattern 1> described above. In the seventh operation example of FIGS. 22 and 23, the application to be executed is a case where “output data <Σ (input data)”, for example, an image analysis application or a sensor data analysis application. As a result, the requester 401 sets a value 1 representing the vicinity of the requester to the execution policy bit PL of the request message 407 to be transmitted by referring to the PL setting table of FIG. Further, the requester 401 sets the name “data−a + application−1 + data−b” as the Name part of the request message 407 (S2301 in FIG. 23). Then, the requester 401 transmits the request message 407 generated in this way to the relay node-A 402 (S2302 in FIG. 23).

  The relay node-A 402 and the relay node-B 403 on the route to the destination node respectively follow <operation pattern 2>, <operation pattern 3>, or <operation pattern 4> described above in the description of the first operation example. The transfer process of the request message 407 is executed.

  In the seventh operation example shown in FIGS. 22 and 23, the relay node-A 402 has neither “application-1”, which is a designated application, nor resources for executing it. For this reason, the relay node-A 402 keeps both the application holding bit AH and the application executable bit AE of the request message 407 at the value 0 in accordance with the above-described <operation pattern 4>, and sends the request message 407 to the relay node-B. Relay to 403 (S2303 in FIG. 23).

  Next, since the relay node-B 403 holds “application-1”, the application holding bit AH in the request message 407 is turned on in accordance with <operation pattern 2> described above. Further, the relay node-B 403 stores in the memory 702 that AH = 1 is set and AH = 1 is set first (S2304 in FIG. 23). Then, the relay node-B 403 transfers the request message 407 to the data-a holding node 405 (S2305 in FIG. 23).

  Since the data-a holding node 405 does not have both “application-1” and its execution resource, and the application holding bit AH of the request message 407 is on, as in the case of the first operation example of FIG. In accordance with <Operation pattern 6> described above, the following operation is executed. The data-a holding node 405 generates a response message 408 in which the bit values of PL, AH, and AE of the request message 407 are copied in the header portion, and the “data-a” body is stored in the Content portion (FIG. 23, S2306). Then, the data-a holding node 405 returns the generated response message 408 to the relay node-B 403 (S2307 in FIG. 23).

  The relay node on the path that has received the response messages 408 and 409 from the data-a holding node 405 responds according to <Operation pattern 8> or <Operation pattern 9> described above in the description of the first operation example. The transfer process / application execution process is executed.

  In the relay node-B 403, when the response message 408 arrives, the execution policy bit PL = 1, the application holding bit AH is turned on, and the relay node-B 403 stores AH = 1 in the memory 702. Remember that you set. Therefore, the relay node-B 403 determines that “application-1” should be executed in accordance with the above-described <operation pattern 8>. As a result, the relay node-B 403 first generates another request message in which the name “data-b” corresponding to one of the element objects that the node itself does not hold is stored in the Name portion. Is transmitted to the network (S2308 in FIG. 23). In response to this separate request message, the data-b holding node 406 returns a response message in which the “data-b” body is stored in the Content section to the relay node-B 403 (S2309 in FIG. 23). Since “application-1” is held by the relay node-B 403 itself, “application-1” is not requested to the application holding node 404. Thereafter, since the relay node-B 403 stores that AH = 1 is set, the “data-a” body stored in the response message 408 is extracted, and “data-a” and “data-b” are extracted. Is input data, and the program indicated by the main body of “application-1” held by the node is executed (S2310 in FIG. 23). As a result, the relay node-B 403 resets the application holding bit AH to 0 in the header part (the application executable bit AE is originally 0), and generates a new response message 409 in which the execution result is stored in the Content part ( S2311 in FIG. 23). AH = 0 is set so that other nodes do not execute the application. Then, the relay node-B 403 transfers the response message 409 to the relay node-A 402 (S2312 in FIG. 23).

  Since the relay node-A 402 has neither “application-1” nor a resource for its execution, the received response message 409 is directly relayed to the requester 401 in accordance with the above-described <operation pattern 9> (S2313 in FIG. 23). ).

  Finally, the requester 401 receives the execution result of the application from the Content part of the received response message 409.

  As described above, in the third operation example of FIGS. 14 and 15, the requester 401 specifies the execution policy bit PL = 1 (destination neighborhood priority) when the request message 407 is transmitted. Therefore, the relay node-B 403 closer to the data-a holding node 405 that is the destination node among the relay node-A 402 and the relay node-B 403 having resources for executing “application-1” is “ Application-1 "will be executed.

  Next, detailed operation of the second embodiment described above with reference to FIG. 5 will be described.

  In the communication system 400 of the second embodiment in FIG. 5, the requester 401 accesses the “application-1” holding node 404, the data-a holding node 405, and the data-b holding node 406 via the network. Although not shown in FIG. 5, also in the second embodiment, the relay node-A 402 and the relay node-B 403 actually operate as shown in FIG.

  As shown in FIG. 5, the communication system 400 according to the second embodiment has an “application-1” main body as an “application-1” holding node 404 and a “data-a” main body as a data-a as an initial state. A holding node 405, a “data-b” body is deployed at the data-b holding node 406. In order to execute the application in the relay node-A 402 or the relay node-B 403 described in the first embodiment, the element objects held in the respective holding nodes are acquired as necessary. An application is executed using these element objects.

  As described above, the hardware configuration of the application holding node 404, the data-a holding node 405, and the data-b holding node 406 has a hardware configuration example shown in FIG.

  Detailed operation of the communication system 400 of the second embodiment will be described with reference to the sequence diagrams of FIGS.

  The requester 401 or the edge node searches the application holding node 404, the data-a holding node 405, and the data-b holding node 406 for the size of the element object necessary for executing the application using a predetermined communication protocol (FIG. 5). 501). As the predetermined communication protocol, HTTP (Hyper Text Transfer Protocol), Telnet, FTP (File Transfer Protocol), or the like can be used.

  Specifically, the requester 401 first transmits a command of a predetermined communication protocol for searching for the size of “application-1” held by the node to the application holding node 304 (S2401 in FIG. 24). In response to this, the application holding node 304 responds to the requester 401 with the size of “application-1”, for example, 10 kB (S2402 in FIG. 24).

  Further, a command of a predetermined communication protocol for performing a size search of “data-a” held by the node is transmitted to the data-a holding node 405 (S2403 in FIG. 24). In response to this, the data-a holding node 405 responds to the requester 401 with the size of “data-a”, for example, 1 MB (S2404 in FIG. 24).

  Similarly, a command of a predetermined communication protocol for performing a size search of “data-b” held by the node is transmitted to the data-b holding node 406 (S2405 in FIG. 24). In response to this, the data-b holding node 406 responds to the requester 401 with the size of “data-b”, for example, 5 kB (S2406 in FIG. 24).

  Thereafter, the requester 401 compares the sizes acquired from the respective response data, and determines the element object having the maximum size (hereinafter referred to as a specific object), for example, “data-a” (S2407 in FIG. 24).

  Alternatively, if the size relationship between the application and the data is known in advance from the characteristics of the application, a maximum object for each application type may be statically defined in addition to the above-described PL setting table of FIG.

  As described above with reference to FIG. 8A, the requester 401 concatenates the name character strings of the element objects (application, data) necessary for executing the application with “+”, and the Name of the request message 407. Set to the section. As described above, for example, the Name part is expressed as “data−a + application−1 + data−b”. “Data-a”, “application-1”, and “data-b” written in the Name part are names of the respective element objects. The request message 407 is a node that holds an element object corresponding to the head name of the Name part (“data-a” in the case of FIG. 5) (data-a holding node 405 indicated by 502 in the case of FIG. 5). Is routed through the network.

  After the request message 407 is transmitted to the network, any one of the above-described first to seventh operation examples in the first embodiment is executed.

  With the communication system according to the first or second embodiment described above, it is possible to reduce the transfer delay / bandwidth of applications and data and speed up the response of the application execution result. In addition, it is possible to achieve load balancing of application execution processing in the network, and to effectively use resources necessary for executing the application.

  Next, a third embodiment of the present invention will be described with reference to the drawings. As described above, the first embodiment is applied when the number of input data that is dominant, that is, relatively large, is 1, and the application is executed at an appropriate position on the path from the requester to the input data. This method

  In the first embodiment, the case where the number of dominant input data is one was discussed, but in the third embodiment, the case where there are a plurality of dominant data is also considered. In the third embodiment described below, application execution locations are distributed among other NFN nodes. As a result, even if output data <Σ (input data), the transfer delay of the application and the input data can be reduced and the response time can be shortened. As described above, the response time means the time from when the user throws the application execution request until the response is received.

  As described above, the third embodiment is applied when the number of dominant input data is plural, and a branch point (branch point) at an appropriate position on the path from the requester to the dominant plural input data. (Also referred to as a point node). When the number of dominant input data is plural, each of the plurality of input data among the input data is relatively larger in size than the other input data and the dominant input data. Each of these refers to a case where the sizes are substantially equal to each other. A branch point refers to a node that receives a single request message but has a plurality of dominant input data and that forwards a plurality of request messages to each of a plurality of nodes as destinations. .

  In general, the network is large and it is difficult to centrally manage the state of all nodes in one place in real time. The target “application” includes both network applications such as firewall and filtering, and user applications such as a data analysis application and an image analysis application. These applications are implemented in a form such as bytecode (for example, Java), are platform-independent, and can be moved between nodes.

  Therefore, in the third embodiment, when there are a plurality of dominant input data, it is an object to shorten response time and realize load distribution between nodes in an application execution call in a network. In order to solve the problem, consider executing an application at a branch point node as illustrated in FIG. In this case, the branch point node is a path toward a holding node that holds data-a and data-b as object elements in an NFN having a tree structure formed by a path from the requester 601 to the node having the request object. Refers to the point where. The NFN is formed as a tree-structured network by selecting in advance on the requester 601 the path to the node where the request object exists, starting from the requester 601 on the actual communication network.

25 and 26 are network diagrams for explaining the basic policy of application execution. As shown in FIG. 26, the request message 607 is previously provided with an execution policy bit (P), an application execution holding bit (AH), and an application executable bit (AE), as in the first and second embodiments. . In addition, for example, 1-bit branch point bit (BR, branch point information) and 2 branch mode bits (BM, branch mode information) are provided. By setting these bits, the network operation is determined as follows according to the relationship of input / output data to / from the application.
[A] When output data> Σ (input data)
-> Run application near request node (PL = 0, BM = Φ (don '
t care))
[B] When Σ (input data)> output data and there is one dominant input data
-> Application execution near the node with input data (far from the requesting node) (PL = 1, BM = 00)
Besides, in this embodiment,
[C] When Σ (input data)> output data and there are multiple dominant input data

-> Application execution near the branch point (a) When the application cannot be executed unless all input data is available ⇒ Application execution near the first branch point (PL = 1, BM = 01)
(B) When an application can be executed even with only a part of input data ⇒ Application execution near each branch point (PL = 1, BM = 10)

  With this network operation, in addition to the destination node “application-1” holding node and requester 601, the branch node 610 can execute the application.

  Further, in the third embodiment, the resource state of each node is reflected in the application execution location determination, and the load can be distributed among the nodes around the specified location including the branch point. That is, it is possible to determine whether or not an application can be executed from information obtained locally by each node based on the application characteristics and the resource state of each node, and dynamically determine the application execution location.

  Although details will be described later, the policy of the third embodiment will be briefly described using the network operation shown in FIG. FIG. 26 shows a case where application-1, data-a, and data-b are necessary to execute the application. The procedure is as follows.

  In the request message 607, a branch point bit (BR) and a branch mode bit (BM) are provided in addition to the execution policy bit (PL) / application holding bit (AH) / application executable bit (AE).

  Depending on the characteristics of the application (the relationship between the amount of input data and the amount of output data), the requester 601 or the edge node (the node at the entrance of the network that accommodates the requester) can execute the execution policy bit PL of the request message 607 and the branch mode bit. Set.

  The execution policy bit is selected from the destination node or branch point node 610 neighborhood priority (PL = 1) and the requester 601 neighborhood priority (PL = 0).

  The branch mode bit is selected and set from no branch point (BM = 00), application execution at the first branch point (BM = 01), and application execution at each branch point (BM = 10).

  In the example shown in FIG. 26, the request message 607 is a destination node of the application / application execution resource holding node, or the application is preferentially executed (PL = 1) near the branch point, and the application at the first branch point. Execution (BM = 01) is shown. A request message configured to indicate a plurality of dominant input data is transmitted to the destination indicated by the Name portion of the request message 607.

  In FIG. 26, data-a and data-b are destinations. A node on the route includes an application holding bit (AH) and / or an app executable bit (or an application executable bit) (depending on whether the node has a designated application or an execution resource, including neighboring nodes not on the route. AE) are set sequentially. In addition, the branch point bit BR is set at a location (branch point) where the request message 607 is relayed to a plurality of network interfaces in the nodes on the route, and the application execution in the subsequent nodes is suppressed.

  Each node determines the operation by determining the state of these bits in the request message and the response message, so that the application execution location is a node on the route, a node nearby in the route, a node in the neighborhood, Determined in order of priority. Here, the node on the route indicates the destination node application / application execution resource holding node, requester or edge node, and branch point node. Also, a nearby node on the route is on the route and is located near any of the destination node application / application execution resource holding node, requester or edge node, or branch point node. It shall refer to a node. When it is determined that an application is executed by a node on the route, any of the application / application execution resource holding node of the destination node, the requester 607 or the edge node, and the branch point node 610 is set as the application execution location. It is determined. The node that executes the application acquires the necessary application and data on the spot, executes the application, and returns the result as a response message. When the application is executed at a branch point and there are a plurality of branch points, the application is executed at one place or every branch point according to the set value of the branch mode bit BR. In this way, each node can know its relative position on the route by the AH, AE, and BR bits of the request message and the response message. Also, each node determines whether or not the application can be executed in consideration of the PL bit and the BM bit.

  FIG. 26 shows a case where the relay node-B 603, which is a branch point node 610 to data-a and data-b, executes an application. As described above, in the third embodiment, a node on a route (an application / application execution resource holding node of a destination node, a requester 601 or an edge node, a branch point node 610) is selected according to the characteristics of the application and the resource state of each node. ), It is possible to execute an application on a nearby node on the route and a nearby node. That is, the application is executed on a node (not limited to a specific node) having an application execution resource including on the route and the vicinity thereof.

  Next, the network operation of FIG. 26 will be described in detail using the message format of FIG. FIG. 27 is a diagram illustrating a message format for a request message and a response message in the following embodiments (part 1 and part 2).

  As shown in FIG. 27A, the request message includes a header part (PL, AH, AE, BR, BM) and a Name part. In the case of the network operation of FIG. 26, (PL, AH, AE, BR) , BM) = (1, 0, 0, 0, 01). Each description is as follows. Note that the additional extension from the request message in the first and second embodiments is BR and BM.

  PL (execution policy bit, Policy): This bit takes a value of 0 or 1. From the viewpoint of delay and transfer amount, it is more advantageous for the target app to be executed near the requester (PL = 0) or far away from the requester (= app, data, or near the branch point) Is advantageous (PL = 1). When the requester sends a request message, or when an edge node (node at the entrance of the network that accommodates the requester) relays the request message, the PL is set according to the characteristics of the application.

  When the input data amount is smaller than the output data amount (ex. Simple merging of data), PL = 0 is set. On the other hand, when the input data amount> the output data amount for the application (ex. Image analysis), PL = 1 is set.

  In the network operation of FIG. 26, since PL = 1, execution of the application far from the requester 601 is selected.

  AH (application holding bit Apphold) is a bit that takes a value of 0 or 1, and is the same as AH in the first and second embodiments described above, and the own node does not have an application specified in the Name part. (AH = 0) or (AH = 1). The requester itself first sets and sends it according to the app's possession status, and if the node on the route has the specified app (including the neighborhood), it is set to 1; Do not change. In the network operation of FIG. 26, since the relay node-A 602 does not hold the application, there is no change from AH = 0, but the relay node-B 603 holds the application. Therefore, the relay node-B 603 changes the request message 607 from (PL, AH, AE, BR, BM) = (1, 0, 0, 0, 01) to (1, 1, 0, 1, 01). Change and transfer to subsequent data holding node.

  Whether AE (application executable bit, AppExec) has a resource (for example, a combination of CPU and memory) for executing the application (AH = 1) as in the AEs of the first and second embodiments described above. No (AH = 0). This is a bit that takes a value of 0 or 1. The requester 601 first sets the value of AE according to the possession status of its own application execution resource, and sends a request message 607. If a node (including the vicinity) on the route has an execution resource, the node sets AE to 1, and if the node does not have an execution resource, the value is not changed.

  BR (branch bit, Branch) has an initial value of 0 when the request message 607 is transmitted by the requester 601. The BR is set to 1 by a node (branch point node 610) that relays the request message 607 to a plurality of network interfaces. This BR = 1 (and BM = 01) suppresses application execution at nodes after the branch point node 610 (nodes that are not branch point nodes).

  In the network operation of FIG. 26, the relay node-B 603 is the branch point node 610. Therefore, the relay node-B 603 updates the request message 607 from (PL, AH, AE, BR, BM) = (1, 0, 0, 0, 01) to (1, 1, 0, 1, 01). And changes to BR = 1.

  BM (branch mode bit, Branch Mode) is assigned 2 bits representing a branch processing mode. Specifically, BM = 00; no branch processing, BM = 01; application execution at one place (first branch point), BM = 10; application execution at any branch point as needed. The BM is set when a requester sends a request message or when an edge node relays a request message because of application characteristics. In the network operation of FIG. 26, since BM = 01, the application is executed at the first branch point, that is, the relay node-B 603.

  Name is a variable-length field that specifies the execution of the application to be requested, as in the first and second embodiments, and is an element object (application, data) required to execute the application. ) Are displayed concatenated. For example, a plurality of data serving as destinations of request messages are combined with “+”, and an application required for executing the application is combined with “:”. As an example, as shown in the network operation request message 607 in FIG. 26, the Name part is expressed as “data−a + data−b: application−1”. Data-a, data-b, and application-1 are names of the respective objects, and the Name part represents that application-1 is executed with data-a and data-b as inputs. The request message 607 is routed toward the data object (in this case, data-a and data-b) indicated by the Name part.

  Here, routing information corresponding to each element object is broadcast in advance from the location where each element object exists, and each node forms a routing table for the name of the object. Upon receiving the request message, each node extracts element objects in the Name part and routes them to output interfaces for these element objects.

  As shown in FIG. 27B, the response messages 608 and 609 include a header part (PL, AH, AE, BR, BM), a Name part, and a Content part. Meanings other than the Data part are the same as those of the request message 607. However, AH, AE, BR, and BM are not newly set, but are copied from the request message 607 at the destination node. AH and AE are reset to 0 when the application is executed at a node in the middle, and passed to the next node. The BR is reset to 0 and passed to the next node when the response message is relayed at the branch point node 610 (the node for which the BR is set for the request message 607). In addition, the response message is not routed by the name part, but the sender of the request message 607 is remembered at each node, and the response message is sent to the sender.

  “Content” is a variable-length field for storing an execution result of the requested application or an element object (application, data). An application execution result is entered after the application is executed on the node, and an element object is entered before the application is executed.

  In the network operation shown in FIG. 26, the data-a holding node 605 does not have an application execution resource, but holds data-a. Therefore, the data-a holding node 605 adds the content of the data-a as a response message in addition to (PL, AH, AE, BR, BM) = (1, 1, 0, 1, 01). Similarly, the data-b holding node 606 does not have an application execution resource, but holds data-b. Therefore, the data-b holding node 606 adds the content of the data-b as a response message in addition to (PL, AH, AE, BR, BM) = (1, 1, 0, 1, 01).

  The relay node-B 603 that is the branch point is the first branch point node 610F that stores the application-1 (AH = 1) and stores that the BR is updated from 0 to 1. Also, since BM = 01, the first branch point node 610F that owns the application-1 uses the data-a and data-b to execute the application, so the relay node-B 603 executes the application. . After executing the application, the relay node-B 603 resets the values of AH and BR from the original values to AH = 0 and BR = 0, and as a response message 609 (PL, AH, AE, BR, BM) = (1, 0, 0, 0, 01) + Execution result is output. This response message 609 is passed to the requester requester 601 via the relay node-A 602.

  The network model used to explain the basic policy of FIG. 26 is composed of five nodes (including requesters) in the case of a network configuration with one branch point. It is. A requester 601 exists in advance on the network, and app-1 is in a branch point node 610 on the network as an initial state. Since data-a and data-b are arranged in the leaf portion of the tree structure of the network as shown in FIG. 28, these element objects are necessary to execute the application. The requester 601 issues an execution request for this application.

  The tree structure of this network is mapped according to the content of the requested content from the actual communication network, but the application execution of the branch point node in the network operation of the third embodiment can be applied to any complex tree structure. It is.

  FIG. 29 is an example of a network having the same network as FIG. 26 and generalized tree structure. In this example, the number of dominant input data is 2 (data-a, data-b), and the application is executed at the branch point. In this case, PL = 1 and BM = 01 in the request message 607. FIG. 29 shows that the relay node-A 602 does not have an application and the relay node-B 603 has an application. The network operation in this case is as follows.

  The requester 601 sets the PL bit and BM bit of the request message 607 from the characteristics of the application to be executed. In the example shown in FIG. 29, PL = 1 (application execution near the destination node or branch point) and BM = 01 (application execution at the first branch point node 610F) are set. Note that the setting of the PL bit and the BM bit here may be performed by the relay node-A 602 corresponding to the edge node in FIG.

  In the first embodiment shown in FIG. 29, the case of PL = 1 will be described. However, the case of PL = 0 (application execution near the requester 601) corresponds to the processing procedure of the first embodiment.

  In FIG. 29, the destination indicated by the Name portion of the request message 607 in the requester 601 is a plurality of dominant input data, which are data-a and data-b in this example. The requester transmits a request message having such a Name part.

  In this example, it is assumed that data-a and data-b, which are destinations in the Name part, are combined with “+” and application-1 is combined with “:”.

  Since the request message 607 has a plurality of destinations, the same message is transmitted to a plurality of network interfaces in the relay node-B 603 that is the branch point node 610. At this time, the nodes (for example, the relay node-A 602 and the relay node-B 603) on the route from the requester 601 to the data-a and data-b have the designated application (application-1) including the neighboring nodes. If so, turn on the AH bit. If there is an execution resource, the AE bit is turned on. Further, if it is a branch point node 610, the BR bit is set, and the application execution in the subsequent nodes is suppressed.

  Each node on the route has information on neighboring nodes by searching for a neighboring node existing within k hops from its own node or by examining in advance.

  In FIG. 29, since the relay node-A 602 has neither a designated application nor an execution resource, AH and AE are not changed in the relay node-A 602 and remain 0. However, since the relay node-B 603 has the designated application, the AH bit is set to 1 and the request message 607 is relayed. And since the relay node-B 603 is the branch point node 610 (transmits a request message to a plurality of network interfaces), the BR bit is set to 1 together.

  The nodes (data-a holding node 605, data-b holding node 606) having data-a and data-b that are element objects as destinations operate as follows with reference to the header bits of the acquired request message 607. To do.

  Since the BR bit is on, the designated data (data-a or data-b) is returned in the Content part of the response message 608 regardless of whether the user has the designated application or there is an execution resource. In this case, the data-a holding node 605 and the data-b holding node 606 copy the header bits (PL, AH, AE, BR, BM) of the request message 607 to the response message 608 as they are.

  The response messages 608 from the data-a holding node 605 and the data-b holding node 606 are transferred through the reverse path of the request message 607 and combined into one message at the branch node 610 (relay node-B). .

  The nodes (for example, relay node-A 602, relay node-B 603) on the route that received the response message 608 operate as follows.

  If the node is not the branch point node 610 and the BR bit of the received response message is ON, the response message 608 is transferred in the reverse direction to the request message 607 in the requester 601 direction.

  For example, when another node exists between a relay node (for example, relay node-A 602, relay node-B 603) and the data-a holding node 605, the relay node operates as follows. When the relay node is the branch point node 610, it waits for arrival of all response messages corresponding to the transmitted request message 607. When all the response messages arrive, all the input data necessary for executing the application is prepared in the relay node. When AE or AH of the response message is on and the relay node (including the vicinity) has a designated application or execution resource, the relay node executes the application. The result is returned in the Content part of the response message. If AH is not turned on in the relay node and AE is turned on, an application is separately acquired with another message and the application is executed. It is assumed that the relay node stores that AH or AE is turned on in response to the request message 607 and can recognize a response message corresponding to the request message 607. The relay node executes the application and clears AE, AH, and BR. In other cases, that is, when application execution is not performed, the content (for example, data-a, data-b) of the received response message is transferred to the requester 601 in one response message. At this time, the relay node clears BR.

  FIG. 29 corresponds to this case, and the relay node-B 603 executes the application.

  When you are not the branch point and the BR bit of the response message is off (= if the response message contains data-a and data-b when transferred without executing the application at the branch point) The relay node operates as follows. When the relay node turns on AE or AH, and the relay node has the designated application or execution resource (including the neighborhood), the relay node executes the application, and the result is the content of the response message. Return it in the department. Further, when AH is not turned on at the relay node and AE is turned on, the application is separately acquired and executed by another message. This relay node is closest to the branch point node 610 and has a designated application or execution resource. At that time, the relay node clears AE, AH, and BR. In other cases, the received response message is transferred to the requester 601 as it is.

  In FIG. 29, the relay node-B 603 sets AH = 1 and stores this. When the response message arrives at the relay node-B 603 from the data-a holding node 605 and the data-b holding node 606, since the node has an application, the application is executed at this node. Then, the relay node-B 603 returns the result in the content part of the response message. At this time, the AH bit and the BR bit are cleared.

By performing the above operations, application execution is performed in the following priority order.
1. Branch point node 610
2. 2. a node near the branch point node 610 on the requester 601 side on the route; A node in the vicinity of a node near the branch point node 610 on the route (not on the route, but a node within k hops from a node on the route)

  Next, a description will be given with reference to a sequence diagram. FIG. 30 is a diagram showing a sequence of the first embodiment of FIG.

  The requester 601 sets PL = 1, BM = 01, AH = 0, AE = 0 (step S3001), and sends a request message 607 with the Name part “data-a + data-b: application-1” to the relay node-A. The data is transferred to 602 (step S3002). Since the relay node-A 602 has neither an application nor an execution resource, the request message 607 is transferred to the relay node-B 603 without changing AH and AE (step S3003). Since the relay node-B 603 has an application, it is rewritten to AH = 1 (step S3004), and the request message 607 is transferred to the data-a holding node 605 and the data-b holding node 606 (steps S3005, S3005). '). At this time, since it is the branch point node 610, the BR bit of the request message 607 is turned on (step S3004). The relay node-B 603 stores that the request message 607 has been rewritten to AH = 1 and that it is the branch point node 610 (step S3004).

  The data-a holding node 605 and the data-b holding node 606 confirm that BR in the request message 607 is 1, and create a response message 608 (steps S3006 and S3006 '). Then, the values of PL, AH, AE, BR, and BM in the request message 607 are copied to each of the response messages 608 (steps S3006 and S3006 '). Further, the data (for example, data-a or data-b) that the user has is put in the Content section and transferred to the relay node-B 603 (steps S3007 and S3007 ').

  The relay node-B 603 waits for the arrival of two response messages 608 because it is a branch node 610. The relay node-B 603 reads that PL = 1 and AH = 1 in the response message 608. And since I turned on AH, it has application-1 and judges that an application should be performed. Since data-a and data-b are included in the received response message 608, the relay node-B 603 uses them to execute the application-1 (step S3008). Then, in the response message 608, AH = 0, BR = 0, and the execution result put in Content (response message 609) (step S3009) is transferred to the relay node-A 602 (step S3010).

  The relay node-A 602 sends the response message 609 to the requester 601 as it is because AH = 0 and AE = 0 in the response message 609 (step S3011).

  The requester 601 receives the application execution result from the response message 609.

  Next, the processing flow of each node will be described. FIG. 31 is a diagram illustrating a processing flow of a node in the first embodiment. When a message is received, the node first determines the message type (separately defines and determines using a header or the like) (step S3101).

(When requesting a message)
It checks whether or not it has an application designated in the Name part (step S3102), and if it has (Yes in step S3102), sets AH of the request message to 1 (step S3103). At this time, it is recorded whether AH is set and whether AH is first set to 0 → 1 (AH of the received request message is 0 and it is rewritten to 1) (step S3103).

  Subsequent to step S3103 or when it is determined No in step S3102, it is checked whether the user has an execution resource (step S3104). If so (Yes in step S3104), the AE of the request message is set to 1 (step S3105). In this case, it is recorded that AE is set and whether AE is first set to 0 → 1 (whether AE of the received request message is 0 and it is rewritten to 1) (step S3105).

  Following step S3105, or if it is determined to be No in step S3104, check whether it is a branch node (determining whether a request message should be transferred to multiple network interfaces based on the destination) (Step S3106). If YES (Yes in step S3106), the request message BR is set to 1 (step S3107). In this case, it is recorded that BR is set (that it is a branch point node) (step S3107). Subsequent to step S3107 or when it is determined as No in step S3106, the request message is transferred to the next node based on the destination (first object of the Name part) (step S3108).

(In response message)
It is determined whether or not the node itself is a branch point node (step S3109).

<When it is a branch point node>
It is determined whether all response messages have been received (step S3110). If NO, the process ends. If YES, the next step is executed.
(PL = 1 and AH = 1 and I set AH) is checked (step S3111). If Yes, an application execution process is performed (step S3112). If No, step S3113 is executed.
(PL = 1 and AE = 1 and whether or not I set AE) is checked (step S3113). If Yes, an application execution process is performed (step S3112). If no, step S3114 is executed.
(PL = 0 and AH = 1 and I set AH first) is checked (step S3114). If Yes, an application execution process is performed (step S3112). If no, step S3115 is executed.
(PL = 0 and AE = 1 and I set AE first) is checked (step S3115). If Yes, an application execution process is performed (step S3112). If all No from step S3111 to step S3115, application execution processing is not performed, BR is reset to 0, and all data is entered in the Content section (step S3116).

  Application execution process: If there is no application, the application is acquired with another request message, and the application is executed (step S3112). Further, in the response message, AH, AE, and BR are reset to 0, and the application execution result is entered in the Content section (step S3112).

  A response message is transferred to the node in the direction that received the corresponding request message (step S3117).

<When it is not a branch point>
(If BR = 1) is checked (step S3118). If Yes, a response message is transferred (step S3117) and the process ends. If No, step S3111 is executed.

  Next, as Example 2 of the third embodiment, a case where the network configuration has two branch points will be described.

  FIG. 32 is a network configuration diagram for explaining the second embodiment. The network includes six nodes (including requesters) and has a network as illustrated in FIG. Data-a, data-b, data-c, and application-f1 are arranged as shown in the figure as an initial state, and these element objects are required to execute the application (with data-a, b, and c as inputs) App-f1). The requester 601 issues an execution request for this application.

  FIG. 33 is a diagram illustrating the network operation of the second embodiment, where (a) represents a case where an application is executed in the vicinity of the first branch point, and (b) is illustrated in the vicinity of individual (plural) branch points. Indicates the case where the application is executed. As a characteristic of the application, the case shown in (a) is a case where the application cannot be executed unless all the input data is prepared, and the case shown in (b) is a case where the application can be executed even with only a part of the input data. Examples of each application include (a): calculating an average value from data of a plurality of temperature sensors, and (b): calculating a maximum value from data of a plurality of temperature sensors. The operation description is as follows.

<(A) When executing an application at the first branch point>
The requester 601 sets the PL bit and BM bit of the request message 607 from the characteristics of the application to be executed. As shown in FIG. 33A, here, PL = 1 (application execution near the destination node or branch point) and BM = 01 (application execution at the first branch point) are set.

  The requester 601 sets the destination indicated by the Name part of the request message 607 as a plurality of dominant input data. Here, as shown in FIG. 33A, data-a, data-b, and data-c are destinations. The requester 601 transmits the generated request message 607 on the route.

  Since the relay node-A 602 has the application -f1 and is the first branch point node 610F, AH = 1 and BR = 1 are set. The relay node-A 602 transfers the request message 607 set in this way to the data-c holding node 611 and the relay node-B 602.

  The relay node-B 603 is the branch point node 610. However, since BR = 1 in the request message 607, it is determined that the first branch point has already been passed. Further, since BM = 01, the BR does not operate and directly transfers the request message 607 to the data-a holding node 605 and the data-b holding node 606.

  The relay node-B 603 is a branch point node 610 but not the first branch point node 610F. Therefore, the relay node-B 603 returns a response message 608 containing these two data to the relay node-A 602 when all of the data returned from the data-a and data-b holding nodes are collected. At this time, the BR operation is not performed (BR = 1 remains).

  The relay node-A 602 executes the application-f1 when all the data (data-c, data-a, data-b) from the data-c holding node 611 and the relay node-B 603 are prepared. A response message 609 containing the result is returned to the requester 601. At this time, AH and BR are reset.

<(B) When an application is executed near each (multiple) branch point>
The requester 601 sets the PL bit and BM bit of the request message 607 from the characteristics of the application to be executed. In FIG. 33B, PL = 1 (near the destination node or branch point) and BM = 10 (individual branch point execution) are set.

  The requester 601 generates the request message 607 with the destination indicated by the Name portion of the request message 607 as a plurality of dominant input data (data-a, data-b, data-c in FIG. 33B), and Send a message.

  The relay node-A 602 has the application -f1 and is a branch point node 610. Therefore, the relay node-A 602 sets AH = 1 and BR = 1 in the received request message 607. The request message 607 set in this way is transferred to the data-c holding node 611 and the relay node-B 602.

  The relay node-B 603 has the application-f1 and is a branch point node 610. Therefore, the relay node-B 603 sets AH = 1 in the received request message 607, and forwards the set request message 607 to the data-b holding node 606 and the data-a holding node 605. At this time, since BR is already 1, it is not operated (BR = 1 is maintained).

  Since the relay node-B 603 is the branch point node 610 and BM = 10, when all the data returned from the data-a and data-b holding nodes are collected, The application -f1 is executed using the data. Then, a response message 609 containing the result is returned to the relay node-A 602. At this time, although AH is reset, since the relay node-B 603 is not the first branch point node 610F, BR is not operated (BR = 1 is maintained).

  The relay node-A 602, when all the data from the data-c holding node 611 and the relay node-B 603 (calculation result of data-c, data-a and data-b) are collected, Perform.

  A response message 609 ′ including the result is returned to the requester 601. In this case, the relay node-A 602 resets AH and BR of the response message 609.

  Next, the sequence of Example 2 will be described. FIG. 34 and FIG. 35 are diagrams showing a sequence of the second embodiment. The explanation is as follows.

  FIG. 34 is a diagram showing a network operation sequence when an application is executed in the first branch point node 610F as in the second embodiment (a). The requester 601 generates a request message 607 in which PL = 1, BM = 01, AH = 0, AE = 0, and the Name part is “data−A + data−b + data−c: application−f1” (step S3201). ). Then, the requester 601 transfers the generated request message 607 to the relay node-A 602 (step S3202).

  Since the relay node-A 602 has an application, it is rewritten to AH = 1 in the received request message 607 (step S3203). The relay node-A 602 transfers the rewritten request message 607 to the data-c holding node 611 and the relay node-B 603 (step 3204, S3204 '). At this time, the relay node-A 602 turns on the BR bit of the request message 607 because it is the first branch point node 610F (step S3203). The relay node-A 602 stores that the request message 607 has been rewritten to AH = 1 and that it is the first branch point node 610F.

  The data-c holding node 611 creates a response message 608 since BR = 1 in the received request message 607 (step S3205). At this time, the data-c holding node 611 copies the values of PL, AH, AE, BR, and BM of the received request message 607 in the response message, and puts the data (data-c) that it has in the Content portion. (Step S3205). Then, the data-c holding node 611 transfers the response message 608 generated in this way to the relay node-A 602 (step S3206).

  The relay node-B 603 that has received the request message 607 from step S3204 'is the branch point node 610. In the request message 607, it is confirmed that BR = 1 and BM = 01. Therefore, the relay node-B 603 transfers the received request message 607 to the data-b holding node 603 and the data-a holding node 602 without changing them (steps S3207 and S3207 '). At this time, although the relay node-B 603 is itself the branch point node 610, since BR is already 1, it determines that it is not the first branch point, and does not perform the BR operation (leave BR = 1). Note that the relay node-B 603 stores that it is not the first branch point node 610.

  The data-b holding node 606 and the data-a holding node 605 each confirm that BR = 1 in the received request message 607, and generate a response message 608 (steps S3208 and S3208 '). At this time, the data-b holding node 606 and the data-a holding node 605 copy the values of PL, AH, AE, BR, and BM of the request message 607 to the response message 608 (steps S3208 and S3208 '). Each of the two nodes puts its own data (data-a or data-b) in the Content section (steps S3208 and S3208 ′) and transfers it to the relay node-B 603 (steps S3209 and S3209). ').

  The relay node-B 603 waits for arrival of two response messages 608 (data-a, data-b). Then, the relay node-B 603 creates a response message 608 containing these two pieces of data when the data-a and the data-b are ready, because it is not the first branch point node 610 ( Step S3210). The relay node-B 603 transfers the response message 608 created to the relay node-A 602 (step S3211).

  Relay node-A 602 waits for the arrival of two response messages 608 (data-c, data-a and data-b). The relay node-A 602 confirms that PL = 1 and AH = 1 in the received response message 608. Then, the relay node-A 602 determines that it has the application-1 and should execute the application because it is the first branch node 610F and has turned on the AH. Since the data-a, data-b, and data-c are all included in the received response message 608, the relay node-A 602 executes the application-1 using these (step S3212). The relay node-A 602 updates the received response message 608 with AH = 0 and BR = 0 as the response message 609, and creates the content with the execution result (step S3213). Then, the relay node-A 602 transfers the created response message 609 to the requester 601 (step S3214).

  The requester 601 receives the application execution result by the response message 609 (step S3214).

  FIG. 35 is a sequence diagram of Example 2 (b). The requester 601 generates a request message 607 in which PL = 1, BM = 10, AH = 0, AE = 0, and the Name part is “data−a + data−b + data−c: application−1” (step S3301). ). Subsequently, the requester 601 transfers the generated request message 607 to the relay node-A 602 (step S3302).

  Since relay node-A 602 has an application, it is rewritten to AH = 1 (step S3303). At this time, the relay node-A 602 turns on the BR bit of the request message 607 because it is the first branch point node 610F (step S3303). The relay node-A 602 transfers the request message 607 rewritten in step S3303 to the data-c holding node 611 and the relay node-B 603 (steps S3304 and S3304 '). The relay node-A 602 stores that the request message 607 has been rewritten to AH = 1, and that it is the first branch point node 610F.

  The data-c holding node 611 confirms that BR = 1 in the received request message 607, and creates a response message 608 (step S3305). At this time, the data-c holding node 611 copies the values of PL, AH, AE, BR, and BM of the received request message 607 to the response message 608. Then, the data-c holding node 611 puts the data (data-c) that the data-c holding node 611 has in the Content part of the response message 608 (step S3305), and transfers this to the relay node-A 602 (step S3306).

  Since the relay node-B 603 that has received the request message 507 in step S3304 'has an application, it is rewritten (overwritten) as AH = 1 in the request message 507 (step S3307). At this time, the relay node-B 603 determines that it is not the first branch point node 610F because it is the branch point node 610 but BR is already 1, and does not perform the BR operation (BR = 1). As it is). Subsequent to step S3307, the relay node-B 603 transfers the rewritten request message 607 to the data-b holding node 606 and the data-a holding node 605 (steps S3308 and S3308 '). The relay node-B 603 remembers that this request message 607 has been rewritten to AH = 1, and that it is not the first branch point node 610F.

  The data-b holding node 603 and the data-a holding node 602 confirm that BR = 1 in the received request message 607, and create a response message 608 (steps S3309 and S3309 '). The data-b holding node 603 and the data-a holding node 602 copy the values of PL, AH, AE, BR, and BM of the request message 507 into the response message 608. The data-b holding node 603 and the data-a holding node 602 put their own data (data-b or data-a) in the content part of the response message 608 (steps S3309 and S3309 '). Next, the data-b holding node 603 and the data-a holding node 602 each transfer the response message 608 created by itself to the relay node-B 603 (steps S3310 and S3310 ').

  The relay node-B 603 waits for arrival of two response messages 608 (data-a, data-b). The relay node-B 603 confirms in the response message 608 that PL = 1, AH = 1, and BM = 10. The relay node-B 603 is a branch point node 610 that is not the first node, but determines that the application should be executed because BM = 10 and the user turns on the AH and has the application-1. To do.

  Since the data-a and the data-b are included in the received response message 608, the relay node-B 603 executes the application-1 using these (step S3311). Then, the relay node-B 603 creates a response message 609 in which the execution result is put in the Content part in the response message 608 (step S3312). Then, the relay node-B 603 transfers the created response message 609 to the relay node-A 602 (step S3313). At this time, since the relay node-B 603 is not the first branch point node 610 and does not set AH from 0 to 1 for the first time, the relay node-B 603 transfers AH = 1 (Step 1). S3313).

  The relay node-A 602 waits for arrival of two response messages (data-c, operation result of data-a and data-b). The relay node-A 602 confirms that PL = 1 and AH = 1 in the response message, and confirms that it has turned on AH. Also, the relay node-A 602 confirms that BM = 10. The relay node-A 602 stores that it is the first branch point node 610F, and since it has the app-1, it determines that the app should be executed. The data-c and the calculation result of the data-a and data-b are included in the received response messages 608 and 609, so that the relay node-A 602 executes the application-1 by using these (Step 1). S3314). The relay node-A 602 updates AH = 0 and BR = 0 to any one of the received response messages 608 and 609, and creates a response message 609 ′ in which the execution result is entered in the Content (step S3315). ). Subsequently, the relay node-A 602 transfers the created response message 609 'to the requester 601 (step S3316).

  The requester 601 receives the application execution result by the response message 609 '(step S3316).

  With the network operation of the third embodiment, the response delay can be shortened by reducing the transfer delay and occupied bandwidth of the application and data. In addition, load distribution of application execution processing in the network can be realized, and effective use of execution resources can be achieved.

Regarding the above embodiment, the following additional notes are disclosed.
(Appendix 1)
Of the application executable nodes in the path between the data request destination node and the request node, which node is to execute the application, the output data amount that is the execution result of the application and the input necessary for the execution of the application Execution node determination means for determining based on the amount of data;
Request message setting means for setting identification information of the determined node in a request message for requesting execution of the application communicated to the data request destination node or the application executable node;
A communication device comprising:
(Appendix 2)
The execution node determination means outputs an execution policy that indicates whether to execute the application on a node close to the data request destination node or to execute the application on a node close to the request node as an execution result of the application Decide which is larger between the amount of data and the amount of input data required to run the app,
The request message setting means sets at least the execution policy identification information as the node identification information in the request message.
The communication apparatus according to attachment 1.
(Appendix 3)
The application executable node and the data request destination node execute the application based on identification information of the node in the request message and / or a response message corresponding to the request message.
The communication apparatus according to appendix 1 or 2.
(Appendix 4)
The request message and the response message corresponding to the request message further include application holding identification information and application executable identification information,
Each node of the application executable node and / or the data request destination node relays the own node according to the holding state of the application and / or the holding state of the resource that can execute the application. Each information of the application holding identification information and / or the application executable identification information in the request message is sequentially set, and the application is determined based on the setting state of the information in the response message and the identification information of the node. Execute, and return the result of the execution to the request node in addition to the response message.
The communication device according to attachment 3.
(Appendix 5)
The request message and the response message corresponding to the request message further include branch point information and branch mode information,
When one or more branch point nodes exist on the route,
Depending on the characteristics of the application and the number of dominant input data, whether to execute the application at a branch node and whether the application execution is performed at the branch node. The execution node determination means determines whether or not to store the determination result as branch mode information in the request message,
The one or more branch point nodes set the branch point information in the received request message,
Each node of the application executable node and / or the data request destination node includes the set branch point information, the branch mode information, the application holding identification information, and / or the application execution in the response message. Executing the application based on the setting state of the possible identification information and the identification information of the node;
The communication device according to attachment 4.
(Appendix 6)
The execution node determination means performs the branch mode information in a case where there is no branch point, a case where the application execution is performed at the first branch point node, and a case where the application execution is shared by a plurality of branch point nodes. Set according to the case
The communication apparatus according to appendix 5.
(Appendix 7)
The communication device according to any one of appendices 1 to 6, wherein each of the application executable node and the data request destination node includes a neighboring node that is located within a predetermined hop from the own node and is not on the route.
(Appendix 8)
The execution node determination unit stores a setting table in which the execution policy is registered for each type of the application, and accesses the setting table by the type of the application that the request message requests to execute when the request message is communicated. The communication device according to any one of appendices 2 to 7, wherein the execution policy is determined by
(Appendix 9)
The request message setting means searches for one or a plurality of element objects having a maximum size among the element objects necessary for execution of the application, and includes the element object or objects having the maximum size as a destination in the request message. The communication device according to any one of appendices 1 to 8, which is set.
(Appendix 10)
Necessary of the application execution node in the path of the data request destination node and the request node or in the vicinity of the path to execute the application is required for the output data amount as the execution result of the application and the execution of the application Execution node determination means for determining based on the input data amount,
Request message setting means for setting identification information of the determined node in a request message for requesting execution of the application communicated to the data request destination node or the application executable node;
With
The application executable node and the data request destination node execute the application based on the identification information of the node in the request message.
Communications system.
(Appendix 11)
Necessary of the application execution node in the path of the data request destination node and the request node or in the vicinity of the path to execute the application is necessary for the output data amount as the execution result of the application and the execution of the application Is determined based on the amount of input data that is
In the request message for requesting execution of the application communicated to the data request destination node or the application executable node, the identification information of the determined node is set,
In the application executable node and the data request destination node, execute the application based on the identification information of the node in the request message.
Communication method.

400 Communication system 401, 601 Requester 402, 602 Relay node-A
403, 603 Relay node-B
404, 604 “App-1” holding node 405, 605 Data-a holding node 406, 606 Data-b holding node 407, 607 Request message 408, 409, 608, 609, 609 ′ Response message 610 Branch point node 610F First Branch point node 611 Data-c holding node 701 Processor 702 Memory 703 Storage device 704 Transmission / reception interface (for data communication)
705 Transmission / reception interface (for management)
706 bus

Claims (11)

Of the application executable nodes in the path between the data request destination node and the request node, which node is to execute the application, the output data amount that is the execution result of the application and the input necessary for the execution of the application Execution node determination means for determining based on the amount of data;
Request message setting means for setting identification information of the determined node in a request message for requesting execution of the application communicated to the data request destination node or the application executable node;
A communication device comprising: The execution node determination means outputs an execution policy that indicates whether to execute the application on a node close to the data request destination node or to execute the application on a node close to the request node as an execution result of the application Decide which is larger between the amount of data and the amount of input data required to run the app,
The request message setting means sets at least the execution policy identification information as the node identification information in the request message.
The communication apparatus according to claim 1. The application executable node and the data request destination node execute the application based on identification information of the node in the request message and / or a response message corresponding to the request message.
The communication device according to claim 1 or 2. The request message and the response message corresponding to the request message further include application holding identification information and application executable identification information,
Each node of the application executable node and / or the data request destination node relays the own node according to the holding state of the application and / or the holding state of the resource that can execute the application. Each information of the application holding identification information and / or the application executable identification information in the request message is sequentially set, and the application is determined based on the setting state of the information in the response message and the identification information of the node. Execute, and return the result of the execution to the request node in addition to the response message.
The communication apparatus according to claim 3. The request message and the response message corresponding to the request message further include branch point information and branch mode information,
When one or more branch point nodes exist on the route,
Depending on the characteristics of the application and the number of dominant input data, whether to execute the application at a branch node and whether the application execution is performed at the branch node. The execution node determination means determines whether or not to store the determination result as branch mode information in the request message,
At least one branch point node among the one or more branch point nodes sets the branch point information in the received request message;
Each node of the application executable node and / or the data request destination node includes the set branch point information, the branch mode information, the application holding identification information, and / or the application execution in the response message. The communication apparatus according to claim 4, wherein the application is executed based on a setting state of possible identification information and identification information of the node.   The execution node determination means performs the branch mode information in a case where there is no branch point, a case where the application execution is performed at the first branch point node, and a case where the application execution is shared by a plurality of branch point nodes. The communication device according to claim 5, wherein the communication device is set in accordance with a case where the communication is performed.   The communication apparatus according to claim 1, wherein each of the application executable node and the data request destination node includes a neighboring node that is located within a predetermined hop from the own node and is not on the route.   The execution node determination unit stores a setting table in which the execution policy is registered for each type of the application, and accesses the setting table by the type of the application that the request message requests to execute when the request message is communicated. The communication apparatus according to claim 2, wherein the execution policy is determined as a result.   The request message setting means searches for one or a plurality of element objects having the maximum size among the element objects necessary for executing the application, and uses the one or more element objects having the maximum size as a destination. The communication device according to any one of claims 1 to 8, wherein Necessary of the application execution node in the path of the data request destination node and the request node or in the vicinity of the path to execute the application is necessary for the output data amount as the execution result of the application and the execution of the application Execution node determination means for determining based on the input data amount,
Request message setting means for setting identification information of the determined node in a request message for requesting execution of the application communicated to the data request destination node or the application executable node;
With
The application executable node and the data request destination node execute the application based on the identification information of the node in the request message.
Communications system. Necessary of the application execution node in the path of the data request destination node and the request node or in the vicinity of the path to execute the application is necessary for the output data amount as the execution result of the application and the execution of the application Is determined based on the amount of input data that is
In the request message for requesting execution of the application communicated to the data request destination node or the application executable node, the identification information of the determined node is set,
In the application executable node and the data request destination node, execute the application based on the identification information of the node in the request message.
Communication method.