Information processing method and information processing equipment

Abstract

An information processing method according to the present disclosure is a method for an information processing apparatus that executes an M2M application for performing M2M communication with a physical node. The information processing method includes performing, by an information processing apparatus, communication with at least one of a virtual node and a virtual location. The virtual node will be implemented as a software module as at least one of a function of a physical node of the M2M communication peer and a function for augmenting the physical node. The virtual location implements, as a software module, a function of a physical sink that performs wireless communication with the physical node, a function for enhancing the physical sink, and an installation location of the physical sink.

Description

Technical Field

[0001] The present disclosure relates to an information processing method and an information processing device. Background Art

[0002] In recent years, research and development on M2M (Machine To Machine) communication is actively carried out. In M2M communication, since various devices such as sensor devices are connected to a network and perform communication, realization of efficient wireless communication is an important technical subject.

[0003] As a technology for further improving the efficiency of wireless communication, for example, it is known that network functions such as P-GW, S-GW, and MME in LTE are arranged as software modules in an MEC (Mobile Edge Computing, Multi-Access Edge Computing) server. In this technology, efficient wireless communication is achieved by performing communication between an MEC server having network functions and a terminal.

[0004] Citation List

[0005] Patent Literature

[0006] Patent Document 1: WO 2017 / 43204A Summary of the invention

[0007] Technical issues

[0008] As described above, when various devices are connected to a network, security measures for the devices are an important issue. In particular, devices that perform M2M communication tend to have high functionality. With the high functionality of the device, the possibility of being attacked by unauthorized access and the like increases.

[0009] Therefore, the present disclosure provides a mechanism that can achieve more secure communication in M2M communication.

[0010] Note that the above-mentioned problem or purpose is only one of multiple problems or purposes that can be solved or achieved by multiple embodiments disclosed in this specification.

[0011] Solution to the problem

[0012] The information processing method of the present disclosure is a method in which an information processing device executes an M2M application for performing M2M communication with a physical node. The information processing method includes communicating with at least one of a virtual node and a virtual location by the information processing device. A virtual node is a node in which at least one of a function of a physical node as a communication partner for M2M communication and a function of reinforcing the physical node is implemented as a software module. A virtual location is a location in which a function of a physical sink that performs wireless communication with a physical node, a function of reinforcing the physical sink, and an installation location of the physical sink are implemented as software modules. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Figure 1 is a diagram illustrating an example of an M2M system according to an embodiment of the present disclosure.

[0014] Figure 2 is a diagram for explaining an example of processing of an M2M application according to an embodiment of the present disclosure.

[0015] Figure 3 is a flowchart illustrating an example of a data parsing process of an M2M application according to an embodiment of the present disclosure.

[0016] Figure 4 is a flowchart illustrating another example of a data parsing process of an M2M application according to an embodiment of the present disclosure.

[0017] Figure 5 is a diagram illustrating an example of a configuration of an M2M system according to an embodiment of the present disclosure.

[0018] Figure 6 is a block diagram illustrating an example of a configuration of an information processing device according to an embodiment of the present disclosure.

[0019] Figure 7 is a block diagram illustrating an example of a configuration of a communication device according to an embodiment of the present disclosure.

[0020] Figure 8 is a block diagram illustrating an example of a configuration of a wireless communication device according to an embodiment of the present disclosure.

[0021] Fig. 9 is a diagram for explaining an example of node-specified type sensor data parsing for specifying a fixed node according to an embodiment of the present disclosure.

[0022] Fig.10 is a diagram for explaining an example of node-specified type sensor data parsing of a specified mobile node according to an embodiment of the present disclosure.

[0023] Fig.11 is a diagram for explaining an example of location-specifying type sensor data parsing according to an embodiment of the present disclosure.

[0024] Fig.12 is a diagram illustrating a relationship between categories in an M2M system according to an embodiment of the present disclosure.

[0025] Fig.13 is a diagram illustrating a relationship between instances in an M2M system according to an embodiment of the present disclosure.

[0026] Fig.14 is a diagram illustrating an example of the architecture of an M2M system according to an embodiment of the present disclosure.

[0027] Fig.15 is a sequence diagram illustrating an example of a fixed node installation procedure according to an embodiment of the present disclosure.

[0028] Fig.16 is a sequence diagram illustrating an example of a mobile node connection procedure according to an embodiment of the present disclosure.

[0029] Fig.17 is a sequence diagram illustrating an example of a mobile node disconnection procedure according to an embodiment of the present disclosure.

[0030] Fig.18 is a sequence diagram illustrating another example of a mobile node disconnection procedure according to an embodiment of the present disclosure.

[0031] Fig.19 is a sequence diagram illustrating an example of a data registration process for registering sensor data from a fixed node according to an embodiment of the present disclosure.

[0032] Fig. 20 is a sequence diagram illustrating an example of a data registration process for registering sensor data from a mobile node according to an embodiment of the present disclosure.

[0033] Fig.21 is a sequence diagram illustrating an example of a global graph DB update process according to an embodiment of the present disclosure.

[0034] Fig. 22 is a sequence diagram illustrating an example of a global sensing DB update procedure according to an embodiment of the present disclosure.

[0035] Fig.23 is a sequence diagram illustrating an example of an M2M application start procedure according to an embodiment of the present disclosure.

[0036] Fig.24 is a sequence diagram illustrating another example of an M2M application start procedure according to an embodiment of the present disclosure.

[0037] Fig.25 is a sequence diagram illustrating an example of a place resolution process according to an embodiment of the present disclosure.

[0038] Fig.26 is a sequence diagram illustrating an example of a node resolution process according to an embodiment of the present disclosure.

[0039] Fig. 27 is a sequence diagram illustrating an example of a node designation type past data parsing process according to an embodiment of the present disclosure.

[0040] Fig.28 is a sequence diagram illustrating another example of a node designation type past data parsing process according to an embodiment of the present disclosure.

[0041] Fig.29 is a sequence diagram illustrating an example of a node-specified type current data parsing process according to an embodiment of the present disclosure.

[0042] Fig.30 is a sequence diagram illustrating another example of a node-specified type current data parsing process according to an embodiment of the present disclosure.

[0043] Fig.31 is a sequence diagram illustrating an example of a node-specified type condition-satisfying data parsing process according to an embodiment of the present disclosure.

[0044] Fig.32 is a sequence diagram illustrating another example of a node-specified type condition-satisfying data parsing process according to an embodiment of the present disclosure.

[0045] Fig.33 is a sequence diagram illustrating an example of a place designation type past data parsing process according to an embodiment of the present disclosure.

[0046] Fig.34 is a sequence diagram illustrating an example of a place-specified type current data parsing process according to an embodiment of the present disclosure.

[0047] Fig.35 is a sequence diagram illustrating an example of a place designation type condition satisfaction data parsing process according to an embodiment of the present disclosure.

[0048] Fig.36 is a sequence diagram illustrating an example of an operation instruction process according to an embodiment of the present disclosure.

[0049] Fig.37 is a sequence diagram illustrating another example of an operation instruction process according to an embodiment of the present disclosure. DETAILED DESCRIPTION

[0050] Embodiments of the present disclosure will be described in detail below with reference to the accompanying drawings. Note that in this specification and the drawings, components having substantially the same functional configuration are denoted by the same reference numerals and symbols, thereby omitting repeated descriptions of these components.

[0051] In the present specification and the drawings, similar components in the embodiments are sometimes distinguished by adding different letters or numbers after the same reference numerals. However, when there is no need to particularly distinguish each similar component, only the same reference numeral is added.

[0052] In this specification and the drawings, specific values ​​are sometimes indicated for the purpose of explanation. However, the values ​​are examples, and other values ​​may be applied.

[0053] One or more embodiments (including examples and variations) described below can be implemented independently. On the other hand, at least a portion of the multiple embodiments described below can be appropriately combined with at least a portion of other embodiments to achieve. These multiple embodiments may include new features that are different from each other. Therefore, these multiple embodiments can contribute to solving purposes or problems that are different from each other, and can achieve effects that are different from each other.

[0054] <<1. Introduction>>

[0055] M2M applications are applications that communicate with terminal devices such as sensors or actuators to perform processing without human intervention. Examples of M2M applications include crop growth management in agriculture (collaboration between temperature and humidity sensors and temperature regulation equipment or watering equipment), building environment management (collaboration between human sensors or temperature and humidity sensors and lighting equipment or air conditioners), and automotive autonomous driving.

[0056] Figure 1 3 is a diagram illustrating an example of an M2M system according to an embodiment of the present disclosure. In the present embodiment, terminal devices (such as sensors and actuators) that perform M2M communication are collectively referred to as nodes 30. The nodes 30 can be connected to a network, such as a core network of a mobile phone or the Internet, through wireless communication. Alternatively, the nodes 30 can be directly connected to the network through a wired connection. When the node 30 is connected to the network through wireless communication, equipment (e.g., a base station or an access point) that serves as a gateway between the wireless communication and the wired network is referred to as a sink 20.

[0057] Notice, Figure 1 The case where three sinks 20 are connected to the network is illustrated. However, the number of sinks 20 connected to the network is not limited to three. The number of sinks 20 connected to the network may be two or less, or may be four or more.

[0058] Figure 1The case where three nodes 30 are connected to the sink 20 is illustrated. However, the number of nodes 30 connected to the sink 20 is not limited to three. The number of nodes 30 connected to the sink 20 may be two or less, or may be four or more. For each sink 20, the number of nodes 30 connected to the sink 20 may be different.

[0059] In general, the M2M application 10 repeats the following process: acquiring sensor data from the node 30 via the network, and instructing the node 30 to perform an operation based on the content of the sensor data.

[0060] Figure 2 1 is a diagram for explaining an example of the process of the M2M application 10 according to an embodiment of the present disclosure. As described above, the two types of processes performed by the M2M application 10 include acquiring sensor data from the node 30 and an operation instruction to the node 30.

[0061] like Figure 2 As shown in , if the operation can be indicated by specifying the node 30 by an identifier or the like, it is considered that the operation indication from the M2M application 10 to the node 30 is sufficient (node ​​specification type).

[0062] On the other hand, as a scheme for the M2M application 10 to acquire sensor data from the node 30 (hereinafter also referred to as a data acquisition scheme), two types of schemes can be roughly conceived. For example, as a data acquisition scheme, a method is considered in which the M2M application 10 specifies the node 30 using an identifier or the like to acquire sensor data (node ​​specification type). As another data acquisition scheme, a method is considered in which the M2M application 10 specifies a geographical location and acquires sensor data of the node 30 existing near the location (location specification type). If these two types can be implemented as data acquisition schemes, it is considered sufficient.

[0063] When acquiring sensor data, the M2M application 10 specifies the type of sensor data, for example, temperature data. As sensor data, there are two types of sensor data: sensor data measured in the past (past data) and sensor data measured currently (current data).

[0064] In addition, in the case of current data, it is convenient if the sensor data (condition satisfaction data) can be acquired when the sensor data satisfies a condition specified by the M2M application 10. The operation of the M2M application 10 acquiring sensor data is called data parsing.

[0065] In summary, as an operation instruction and data analysis solution for node 30, if Figure 2 The seven types shown in the table are considered sufficient.

[0066] Figure 3 is a flowchart illustrating an example of a data parsing process of the M2M application 10 according to an embodiment of the present disclosure. Figure 3 The diagram illustrates the data parsing process for a location-specific type.

[0067] like Figure 3 As shown in FIG. 1 , first, the M2M application 10 specifies a geographical area to be searched (step S101). For example, the M2M application 10 specifies Figure 1 The area surrounded by the dotted line.

[0068] like Figure 3 As shown in FIG. 1 , then, the M2M application 10 searches for a sink installation location in a specified area (step S102). Thus, the M2M application 10 indicates a set of discovered sinks 20 ( Figure 1 1 and 20_2 in the example shown in FIG. 10 to acquire data (step S103 ).

[0069] As described above, the M2M application 10 can designate a place (area) and acquire sensor data.

[0070] Note that the functions of steps S101 and S102 explained above, ie, the function of specifying an area and searching for a set of places in which the sink 20 is installed, is referred to as place resolution.

[0071] Figure 4 is a flowchart illustrating another example of a data parsing process of the M2M application 10 according to an embodiment of the present disclosure. Figure 4 The diagram shows the node-specified data parsing process. Figure 3 The same processes as in the process are denoted by the same reference numerals and their descriptions are omitted.

[0072] The M2M application 10 connects to (a set of) the sinks 20 discovered as a result of step S102 , and searches for a node 30 having a desired function (eg, a temperature measurement function) (step S201 ).

[0073] The M2M application 10 acquires data from the set of nodes 30 found as a result of the search (step S202). For example, the M2M application 10 indicates Figure 1 Nodes 30_22 and 30_23 shown in FIG. 1 are connected to the sink 20_2 to obtain data.

[0074] As described above, the M2M application 10 may specify the node 30 and obtain sensor data.

[0075] Note that the function of step S201 explained above, that is, the function of specifying the set of sinks 20 and the functions that the node 30 can have and searching for the set of nodes 30, is called node resolution.

[0076] The nodes 30 can be roughly classified into two types, fixed nodes and mobile nodes. A fixed node is a node 30 that is physically fixed and installed like a surveillance camera used as a sensor or a lighting equipment used as an actuator. A mobile node is a node 30 that has the functions of a sensor and an actuator and physically moves, like a car or a smart phone.

[0077] Therefore, it is desirable to efficiently implement a location management method for both fixed nodes and mobile nodes for location resolution and node resolution. In addition, it is desirable to efficiently implement the seven types of data resolution and operation instructions described above for both fixed nodes and mobile nodes (see Figure 2 ) data management methods.

[0078] <<2.Overview>>

[0079] In order to realize the M2M system described above, there are four main issues to be solved.

[0080] <2.1. First question>

[0081] The first problem is the increase in communication delay between the M2M application 10 and the node 30 (sensor or actuator) and the communication volume of the network. The M2M system of the related art has a configuration in which the node 30 is connected to the network and communicates with a cloud server installed in a data center. In such a configuration, the communication delay between the node and the cloud server increases. In addition, when many M2M applications 10 communicate with many nodes 30, the traffic of the network increases.

[0082] To solve this problem, the M2M system according to the present embodiment uses a geographically distributed and arranged MEC server group. The M2M system selects an MEC server or a cloud server and arranges the M2M application 10 in consideration of the communication delay of the node 30 communicating with the M2M application 10 and the computing load of the M2M application 10. For example, the M2M system selects the optimal MEC server or cloud server and arranges the M2M application 10 using the MANO (Management ANdOrchestration) function.

[0083] <2.2. Second question>

[0084] The second challenge is node security. Nodes 30 used as sensors or actuators tend to have high functionality. That is, the computing power of the node 30 is improved, and advanced programs can be executed or programs can be dynamically updated. Such high functionality of the node 30 is inseparable from the increase in the attack surface (the part to be attacked) in terms of security.

[0085] To solve this problem, the M2M system of this embodiment reduces the functions of the node 30 to the minimum required and eliminates as many security vulnerabilities of the node 30 itself as possible. For example, in the M2M system, dynamic program updates are not allowed. Instead of reducing the hardware functions to the minimum required, the M2M system according to this embodiment virtualizes the physical node 30 into software and executes the software on the MEC server or cloud server.

[0086] In the following description, the physical node 30 is referred to as a physical node (PNode) 30P. A software module obtained by virtualizing the PNode 30P is referred to as a virtual node (VNode) 30V. The virtual node 30V implements, for example, the functions of the physical node 30P and the functions that enhance the physical node 30P as a software module.

[0087] The latest security technology is applied to the VNode 30V. Thus, the VNode 30V prevents unauthorized access, etc. Since security technology is advancing every day, it is assumed that the VNode 30V performs maintenance such as software update. By virtualizing the PNode 30P, the M2M system can more easily perform maintenance of the node 30. The M2M application 10 can achieve more secure communication with the node 30.

[0088] Here, the M2M system can reduce the number of VNodes 30V as maintenance targets by, for example, reducing the number of VNodes 30V relative to the number of PNodes 30P by associating PNodes 30P with VNodes 30V in a many-to-one relationship. For example, even if a large number of PNodes 30P serving as one product are installed, only one VNode 30V corresponding to the PNode 30P needs to be implemented.

[0089] <2.3. The third question>

[0090] The third problem is the diversity of specifications and capabilities of the nodes 30. There are various nodes 30, and their specifications and capabilities are also different. Therefore, when designing the M2M application 10, the characteristics of the nodes 30 need to be considered, and the design is complicated.

[0091] To solve this problem, the M2M system according to the present embodiment enables the M2M application 10 to operate in a virtual space in which software modules having a unified specification operate.

[0092] The related art M2M application operates in a physical space targeting a physical node (PNode 30P). On the other hand, the M2M application 10 in the present embodiment operates in a virtual space targeting a VNode 30V virtualized as a software module.

[0093] Therefore, as described above, in addition to virtualizing the PNode 30P into the VNode 30V, the location where the physical sink (PSink) 20P is installed is virtualized by a software module called a virtual location (VPoint) 20V. The virtual location 20V is obtained by, for example, realizing the functions of the physical sink 20P (hereinafter also referred to as the physical sink 20P), strengthening the functions of the physical sink 20P, and the installation place of the physical sink 20P as a software module.

[0094] In the physical space, the PNode 30P is connected to the PSink 20P. The PNode 30P transmits sensor data to the M2M application 10 via the PSink 20P and receives an operation instruction from the M2M application 10.

[0095] In the virtual space, the VNode 30V is connected to the VSink 20V. The VNode 30V transmits sensor data to the M2M application 10 via the VPoint 20V and receives an operation instruction from the M2M application 10.

[0096] That is, the M2M application 10 communicates with at least one of the VNode 30P and the VPoint 20V to perform M2M communication with the PNode 30P. Note that the M2M application 10 may be executed by an information processing device (not shown) as described below.

[0097] Here, by virtualizing the PSink 20P, the M2M application 10 can achieve secure communication similar to the VNode 30V. As described above, the M2M system can achieve more secure M2M communication by virtualizing at least one of the node 30 and the sink 20.

[0098] For example, the M2M system may associate the PSink 20P and the VPoint 20V in a many-to-one relationship. As described above, the M2M system may reduce the number of VPoints 20V as maintenance targets by reducing the number of VPoints 20V relative to the number of PSinks 20P. For example, even if a large number of PSinks 20P used as one product are installed, only one VPoint 20V corresponding to the PSink 20P needs to be implemented.

[0099] The M2M system can virtualize the PSink 20P and the PNode 30P connected thereto together into a VPoint 20V. Thus, the VPoint 20V can be regarded as a virtual location for transmitting sensor data or instructing an actuator to perform an operation.

[0100] In addition, by enhancing the function of the VNode 30V or by combining multiple types of PNodes 30P to define one VNode 30V, a node 30 that does not physically exist can be virtually defined. For example, a VNode 30 used as a license plate recognition sensor can be defined by adding a car license plate recognition function to a VNode 30V corresponding to a surveillance camera that captures a static image. As described above, multiple PNodes 30P are virtualized through one VNode 30V, so that a node 30 that does not physically exist can be virtually defined.

[0101] In the present embodiment, three layers of API (Application Programming Interface) may be defined for the M2M application 10 operating in the virtual space.

[0102] As the top layer API, an M2M API may be defined. The M2M API is, for example, a function group of high-level functions provided to the M2M application 10. Specifically, the functions of the M2M API may include, for example, the location resolution and node resolution described above and seven types of classified functions (see Figure 2 ).

[0103] As a lower layer of the M2M API, for example, a primitive API (Prim API) may be defined. The functions of the Prim API are obtained by decomposing the functions defined by the M2M API into basic functions. For example, access to a VNode 30V or a VPoint 20V is defined as a function of the Prim API.

[0104] The lowest level API is a device-specific API (Dev API). Here, different types of PNode 30P have their own APIs. The API unique to the PNode 30P is defined as the Dev API.

[0105] In other words, the access function to the VNode 30V used as the function of the Prim API is converted into an access function unique to the PNode 30P (function of the Dev API) actually accessed in the VNode 30V and executed. Therefore, the difference in the specification of the PNode 30P is hidden from the Prim API.

[0106] <2.4. Fourth question>

[0107] The fourth problem is a management method for efficiently implementing location resolution and node resolution for both fixed nodes and mobile nodes. For example, a mobile node may be a smart phone or a car. Mobile nodes such as cars or smart phones have the functions of sensors or actuators, and at the same time, have the computing power of a computer. To this end, these mobile nodes can execute M2M applications 10. That is, mobile nodes can be treated equally with MEC servers.

[0108] To solve this problem, in the present invention, VNode 30V corresponding to a mobile node is defined separately from VNode 30V corresponding to a fixed node. A physical mobile node is referred to as a physical mobile node (PMNode) 30PM. A VNode 30V corresponding to a PMNode 30PM is referred to as a virtual mobile node (VMNode) 30VM.

[0109] VMNode 30VM always knows the physical location of PMNode 30PM. Regardless of the physical location of PMNode 30PM, VMNode 30VM is fixedly arranged in a predetermined MEC server. Such a MEC server is called a home MEC server related to PMNode 30PM.

[0110] The VMNode 30VM always operates on the same MEC server (home MEC server). To this end, the M2M application can perform node-specific type data parsing on the PMNode 30PM by accessing the VMNode 30VM, regardless of the physical location of the PMNode 30PM.

[0111] On the other hand, when PMNode 30PM exists within the communication range of PSink 20P, M2M application can receive sensor data from PMNode 30PM, but when PMNode 30PM exists outside the communication range of PSink 20P, M2M application cannot receive sensor data. PSink 20P to which PMNode 30PM is connected changes all the time.

[0112] Therefore, in the M2M system according to the present embodiment, the VPoint 20V obtained by virtualizing the installation site of the PSink 20P has a function of managing the PMNode 30PM temporarily entering the communication range of the PSink 20P. Thus, the M2M application 10 can also acquire sensor data from the PMNode 30PM through location designation type data parsing.

[0113] In addition, PNode 30P, VNode 30V, PSink 20P, VPoint 20V, PMNode 30PM, VMNode 30VM, etc. are associated with position information and expressed in ontology.

[0114] In the ontology, in the physical space, the Area class is defined as a class representing a geographical area, and the PNode class, PMNode class, and PSink class are defined as classes representing physical equipment. On the other hand, in the virtual space, the VNode class, VMNode class, and VPoint class are defined as classes obtained by virtualizing physical equipment.

[0115] In addition, the system (System) class, the server (Server) class, the application (App) class and the API class are defined as classes representing computing resources and software modules. The system (System) class is a class representing the M2M system according to the embodiment. The application (App) class is a class representing the M2M application 10. The API class is a class representing a software module that provides the M2M API. The server (Server) class is a class representing a cloud server or an MEC server.

[0116] Since the M2M application 10 or API operates on a cloud server or MEC server, the server class, application (App) class, and API class are associated with each other. The PMNode class is associated with the PNode class from the perspective of the node 30, and at the same time, is associated with the server class from the perspective of the computer. In addition, the class of the physical space is associated with the class of the virtual space.

[0117] <<3. System Configuration Example>>>

[0118] The physical modules and virtual modules of the M2M system described above are described. Figure 5 is a diagram illustrating an example of a configuration of an M2M system according to an embodiment of the present disclosure. Note that Figure 5 (a) is a diagram illustrating a configuration example of an M2M system in a physical space, and Figure 5 (b) is a diagram illustrating a configuration example of an M2M system in a virtual space.

[0119] <3.1. Example of system configuration in physical space>

[0120] like Figure 5As shown in (a), in the physical space, the M2M system includes a cloud server 100_1, MEC servers 100_21 and 100_22, PSinks 20P_11 and 20P_21, PNodes 30P_11 and 30P_21, and PMNodes 30PM_11 and 30PM_21.

[0121] In the physical space, cloud server 100_1, MEC server 100_21 and MEC server 100_22 are connected to the 5G core network / Internet. PSink 20P_11 and the like as physical sinks are connected to MEC server 100_21. PNode 30P_11 and the like as physical nodes are connected to PSink 20P_11.

[0122] In addition, PMNode30PM_11, which is a physical mobile node that sets the MEC server 100_21 as the MEC server to which it belongs, also temporarily exists within the communication range of PSink 20P_11.

[0123] Similarly, PSink 20P_21 and the like as physical sinks are connected to MEC server 100_22. PNode 30P_21 and the like as physical nodes are connected to PSink 20P_21.

[0124] exist Figure 5 In the example shown in (a), PMNode 30PM_21, which is a physical mobile node that sets MEC server 100_22 as a home MEC server, temporarily exists in the communication range of PSink 20P_11. It is assumed that the communication range of PMNode 30PM_21 changes from PSink 20P_21 to PSink 20P_11 due to movement. As described above, PSink 20P connected to PMNode 30PM as a mobile node changes due to movement.

[0125] Here, a configuration example of devices in a physical space is described.

[0126] (Information Processing Device 100)

[0127] Figure 6 is a block diagram illustrating an example of the configuration of the information processing apparatus 100 according to an embodiment of the present disclosure. Figure 6 The information processing device 100 shown in is used as, for example, the cloud server 100_1 and the MEC servers 100_21 and 100_22 described above.

[0128] The information processing device 100 includes a communication unit 110, a storage unit 120, and a control unit 130. Note that Figure 6The configuration shown in is a functional configuration. The hardware configuration may be different from this configuration. The functions of the information processing device 100 may be statically or dynamically distributed and implemented in multiple physically separated components. For example, the information processing device 100 may be configured by multiple server devices.

[0129] The communication unit 110 is a communication interface for communicating with other devices. The communication unit 110 may be a network interface, or may be an equipment connection interface. For example, the communication unit 110 may be a LAN (local area network) interface such as a NIC (network interface card), or may be a USB interface configured by a USB (universal serial bus) host controller, a USB port, etc. The communication unit 110 may be a wired interface or a wireless interface. The communication unit 110 is used as a communication component of the information processing device 100. The communication unit 110 communicates with other information processing devices 100, PSink 20P, etc. according to the control of the control unit 130.

[0130] The storage unit 120 is a data readable / writable storage device such as a DRAM (Dynamic Random Access Memory), an SRAM (Static Random Access Memory), a flash memory, or a hard disk. The storage unit 120 serves as a storage means of the information processing device 100 .

[0131] The control unit 130 is a controller that controls the units of the information processing device 100. The control unit 130 is implemented by a processor such as a CPU (Central Processing Unit), an MPU (Micro Processing Unit), or a GPU (Graphics Processing Unit). For example, the control unit 130 is implemented by the processor using a RAM (Random Access Memory) or the like as a work area and executing various programs stored in a storage device inside the information processing device 100. Note that the control unit 130 can be implemented by an integrated circuit such as an ASIC (Application Specific Integrated Circuit) or an FPGA (Field Programmable Gate Array). All CPUs, MPUs, GPUs, ASICs, and FPGAs can be regarded as controllers.

[0132] (Communication device 200)

[0133] Figure 7 2 is a block diagram illustrating an example of a configuration of a communication device 200 according to an embodiment of the present disclosure. Figure 7 The communication device 200 shown in FIG. 1 is used as, for example, the PSink 20P described above.

[0134] The communication device 200 includes an antenna unit 210 , a wireless communication unit 220 , a network communication unit 230 , a storage unit 240 , and a control unit 250 . Figure 7The configuration shown in is a functional configuration, and the hardware configuration may be different from the functional configuration. The functions of the communication device 200 may be statically or dynamically distributed and implemented in multiple physically separated components. For example, the communication device 200 may be configured by multiple server devices.

[0135] The antenna unit 210 radiates the signal output from the wireless communication unit 220 as radio waves into space. The antenna unit 210 converts the radio waves in space into signals and outputs the signals to the wireless communication unit 220. Note that the antenna unit 210 in this embodiment includes a plurality of antenna elements and can form a beam.

[0136] The wireless communication unit 220 transmits and receives signals. For example, the wireless communication unit 220 transmits a signal to the PNode 30P and receives a signal from the PNode 30P. The wireless communication unit 220 operates according to the control of the control unit 250. Note that the wireless communication unit 220 in this embodiment can form a plurality of beams using the antenna unit 210 and communicate with the PNode 30P.

[0137] The network communication unit 230 sends and receives information. For example, the network communication unit 230 sends information to the information processing device 100 and receives information from the information processing device 100. In addition to communicating with the information processing device 100, the network communication unit 230 can also communicate with other communication devices 200 and core network nodes, for example. The network communication unit 230 communicates with other devices according to the control of the control unit 250.

[0138] The storage unit 240 is a data readable / writable storage device such as a DRAM (Dynamic Random Access Memory), an SRAM (Static Random Access Memory), a flash memory, or a hard disk. The storage unit 240 serves as a storage means of the communication device 200.

[0139] The control unit 250 is a controller that controls the units of the communication device 200. The control unit 250 is implemented by a processor such as a CPU (Central Processing Unit) or an MPU (Micro Processing Unit). For example, the control unit 250 is implemented by the processor using a RAM (Random Access Memory) or the like as a work area and executing various programs stored in a storage device inside the communication device 200. Note that the control unit 250 can be implemented by an integrated circuit such as an ASIC (Application Specific Integrated Circuit) or an FPGA (Field Programmable Gate Array). All CPUs, MPUs, ASICs, and FPGAs can be regarded as controllers.

[0140] (Wireless Communication Device 300)

[0141] Figure 8is a block diagram illustrating an example of a configuration of a wireless communication device 300 according to an embodiment of the present disclosure. Figure 8 The wireless communication device 300 shown in FIG. 1 functions as, for example, the PNode 30P and the PMNode 30PM explained above.

[0142] The wireless communication device 300 includes an antenna unit 310 , a wireless communication unit 320 , a sensor unit 330 , a storage unit 340 , and a control unit 350 . Figure 8 The configuration shown in is a functional configuration, and the hardware configuration may be different from the functional configuration.

[0143] The antenna unit 310 radiates the signal output from the wireless communication unit 320 as radio waves into space. The antenna unit 310 converts the radio waves in space into signals and outputs the signals to the wireless communication unit 320. Note that the antenna unit 310 in this embodiment includes a plurality of antenna elements and can form a beam.

[0144] The wireless communication unit 320 sends and receives signals. For example, the wireless communication unit 320 sends a signal to the PSink 20P and receives a signal from the PSink 20P. The wireless communication unit 320 operates according to the control of the control unit 350. Note that the wireless communication unit 320 in this embodiment can form a plurality of beams using the antenna unit 310 and communicate with the PSink 20P.

[0145] The sensor unit 330 senses the surroundings of the wireless communication device 300 and generates sensing information. For example, the sensor unit 330 may be an imaging device that captures surrounding images or a measuring device that measures temperature, etc. Note that, here, the wireless communication device 300 includes the sensor unit 330. However, in addition to or instead of the sensor unit 330, the wireless communication device 300 may further include an actuator.

[0146] The storage unit 340 is a data readable / writable storage device such as a DRAM (Dynamic Random Access Memory), an SRAM (Static Random Access Memory), a flash memory, or a hard disk. The storage unit 340 serves as a storage means of the wireless communication device 300.

[0147] The control unit 350 is a controller that controls the units of the wireless communication device 300. The control unit 350 is implemented by a processor such as a CPU (Central Processing Unit) or an MPU (Micro Processing Unit). For example, the control unit 350 is implemented by the processor executing various programs stored in a storage device inside the wireless communication device 300 using a RAM (Random Access Memory) or the like as a work area. Note that the control unit 350 can be implemented by an integrated circuit such as an ASIC (Application Specific Integrated Circuit) or an FPGA (Field Programmable Gate Array). All CPUs, MPUs, ASICs, and FPGAs can be regarded as controllers.

[0148] <3.2. Example of system configuration in virtual space>

[0149] Return to Figure 5 , illustrating an example of a configuration of an M2M system in a virtual space. Figure 5 As shown in (b) of FIG. 1 , in the virtual space, the M2M system includes an M2M application (M2M App) 10_11, an M2M API 40_1, VPoints 20V_11 and 20V_21, VNodes 30V_11 and 30V_21, and VMNodes 30VM_11 and 30VM_21.

[0150] In the virtual space, M2M App 10_11 as an M2M application operates on MEC server 100_21. M2M API 40_1 operates on MEC server 100_21. M2M API 40_1 connects M2M App 10_11 with VPoint 20V_11 and 20V_21, VNode 30V_11 and 30V_21, and VMNode 30VM_11 and 30VM_21 using M2M API functions and Prim API functions.

[0151] VPoint 20V_11 etc., which are virtual modules corresponding to PSink 20P_11 etc. and PNode 30P_11 etc., operate on MEC server 100_21. VNode 30V_11 etc., which are virtual modules corresponding to PNode 30P_11 etc., operate on MEC server 100_21.

[0152] Since MEC server 100_21 is the home MEC Server of PMNode 30PM_11, VMNode30VM_11, which is a virtual module corresponding to PMNode30PM_11, also operates on MEC server 100_21.

[0153] Similarly, in addition to VPoint 20V_21, etc. and Vnode 30V_21, etc., VMNode30VM_21 also operates on MEC server 100_22.

[0154] The VNodes 30V_11 and 30V_21 and the VMNodes 30VM_11 and 30VM_21 as virtual nodes may internally store sensor data received from the PNodes 30P_11 and 30P_21 and the PMNodes 30PM_11 and 30PM_21 corresponding thereto, or may store the sensor data in an external database.

[0155] Notice, Figure 5 The configuration of the M2M system shown in is an example, and the number of components is not limited to Figure 5 The example shown in . For example, there may be two or more cloud servers, M2M applications, and M2M APIs, and there may be one MEC server or three or more MEC servers. The number of PSinks and VSinks may be one or may be three or more. The number of PNodes, PMNodes, VNodes, and VMNodes may be two or more. Multiple PSinks and multiple VPoints may be arranged in one MEC server.

[0156] <<4. Processing Example>>

[0157] The following describes an overview of the data acquisition process (sensor data analysis) executed in the M2M system described above.

[0158] <4.1. Node-specific sensor data analysis>

[0159] First, the outline of the node-specified type sensor data analysis is described: The M2M application 10 specifies one of a fixed node or a mobile node, and acquires data from the specified node.

[0160] <4.1.1. Fixed nodes>

[0161] Fig. 9 3 is a diagram for explaining an example of node designation type sensor data parsing for designating a fixed node according to an embodiment of the present disclosure. Here, it is assumed that the M2M application 10_11 designates the VNode 30V_11 and acquires data.

[0162] First, the M2M application 10_11 specifies the VNode 30V_11 using the function of the M2M API 40_1 and requests the M2M API 40_1 to perform node-specified type sensor data parsing (step S301). The M2M API 40_1 acquires sensor data from the VNode 30V_11 using the function of the Prim API (step S302).

[0163] The VNode 30V_11 acquires sensor data from the PNode 30P_11 using the function of the Dev API (step S303). The VNode 30V_11 returns the acquired sensor data to the M2M application 10_11 via the M2M API 40_1. Alternatively, the VNode 30V_11 may return the sensor data stored in itself to the M2M application 10_11.

[0164] <4.1.2. Mobile Node>

[0165] Fig.10 1 is a diagram for explaining an example of node-specified type sensor data parsing of a specified mobile node according to an embodiment of the present disclosure. Here, it is assumed that the M2M application 10_11 specifies the VMNode 30VM_21 and acquires data.

[0166] First, the M2M application 10_11 specifies the VMNode 30VM_21 using the function of the M2M API 40_1 and requests the M2M API 40_1 to perform node-specified type sensor data parsing (step S401). The M2M API 40_1 obtains sensor data from the VNode 30V_21 using the function of the PrimAPI regardless of the physical location of the PMNode 30PM_11 (step S402).

[0167] VMNode 30VM_21 acquires sensor data from PMNode 30PM_21 using the function of Dev API (step S403). VMNode 30VM_21 returns the acquired sensor data to M2M application 10_11 via M2M API 40_1. Alternatively, VMNode 30VM_21 may return sensor data stored in itself to M2M application 10_11.

[0168] <4.2. Location-specific sensor data analysis>

[0169] Next, the outline of the location-specifying type sensor data analysis will be described. Fig.112 is a diagram for explaining an example of location-specified type sensor data parsing according to an embodiment of the present disclosure. Here, it is assumed that the M2M application 10_11 specifies VPoint20V_11 and acquires data.

[0170] First, the M2M application 10_11 specifies VPoint20V_11 using the function of the M2M API 40_1 and requests the M2M API 40_1 to perform location-specified type sensor data parsing (step S501). The M2M API 40_1 inquires VPoint20V_11 using the function of the Prim API (step S502).

[0171] Then, the VPoint 20V_11 communicates with the VNode 30V_11, the VMNode 30VM_11, the VMNode 30VM_21, etc. using the function of the Prim API (step S503).

[0172] The VNode 30V_11, VMNode 30VM_11, and VMNode 30VM_21 communicate with the PNode 30P_11, PMNode 30PM_11, and PMNode 30PM_21 corresponding thereto using the function of the Dev API, and obtain sensor data (step S504).

[0173] It is assumed that PMNode 30PM_11 in the case where MEC server 100_21 is set as the home MEC server exists within the communication range of PSink 20P_11 corresponding to VPoint 20V_11, where VPoint 20V_11 operates in MEC server 100_21. In this case, VPoint 20V_11 can obtain sensor data from VMNode 30VM_11 or PMNode 30PM_11 using the functions of Prim API and Dev API.

[0174] It is assumed that PMNode 30PM_21 temporarily exists in the communication range of PSink 20P_11 corresponding to VPoint 20V_11 when MEC server 100_22 other than MEC server 100_21 is set as the home MEC server, where VPoint 20V_11 operates in MEC server 100_22. In this case, VPoint 20V_11 recognizes that PMNode 30PM_21 exists in the communication range of PSink 20P_11. To this end, VPoint 20V_11 can use the functions of PrimAPI and Dev API to obtain sensor data from VMNode30VM_21 or PMNode 30PM_21.

[0175] As described above, the M2M application 10 according to the present embodiment communicates with at least one of a virtual node (e.g., VNode 30V_11 or VMNode 30VM_11 and 30VM_21) and a virtual point (e.g., VPoint 20V_11). Thus, the M2M application 10 can more securely perform M2M communication with a physical node (e.g., PNode 30P_11 or PMNode 30PM_11 and 30PM_21).

[0176] Notice, Figures 9 to 11 Steps S301, S401, and S501 shown in indicate the execution of the function of the M2M API. Steps S302, S402, S502, and S503 indicate the execution of the function of the Prim API (an example of a lower layer API) at a lower level than the M2M API. Steps S303, S403, and S504 indicate the execution of the function of the Dev API (an example of a device API) at a lower level than the Prim API.

[0177] <<5. Details of the proposed technology>>

[0178] <5.1. Representation methods for geographic information: class definition>

[0179] In the proposed technology, the relationship between geographic information and physical equipment or software modules is expressed through ontology. In ontology, as a relationship, the relationship between things is expressed through a triple of subject, characteristic and object. Since an object can be the subject of another triple, the relationship between things is extended in a grid form. The type of thing is called a class, and a specific thing is expressed as an instance of the class corresponding to it. The characteristic that expresses the relationship between classes or instances is called object characteristic, and the characteristic that expresses the relationship between a class or instance and its attributes is called data characteristic.

[0180] Fig.12is a diagram illustrating a relationship between classes in an M2M system according to an embodiment of the present disclosure. In the M2M system according to an embodiment of the present disclosure, eleven classes described below are defined.

[0181] System class, representing the proposed M2M system

[0182] Server class, which represents the cloud server 100_1 and MEC servers 100_21 and 100_22 that configure the M2M system

[0183] Application (App) class, representing M2M applications used as software modules 10

[0184] API class, which represents a software module that provides M2M API to the M2M application 10

[0185] Area class, which represents a geographical area

[0186] PNode class, representing a fixed installed physical node 30 (sensor or actuator)

[0187] VNode class, which represents a software module obtained by virtualizing the node 30

[0188] PMNode class, representing a physical mobile node 30M, such as a car or smartphone

[0189] VMNode class, which represents the software module obtained by virtualizing the mobile node 30M

[0190] PSink class, representing a physical device that acts as a gateway (sink 20) ​​between a node 30 performing wireless communication and a network

[0191] VPoint class, which represents a software module obtained by virtualizing the sink 20, the node 30 connected thereto, and the mobile node 30M

[0192] (System class)

[0193] The System class is the class at the root of the class relationship. The System class uses the isComposedOf object property to represent the relationship between the System instance and the Server instance.

[0194] (Server class)

[0195] The Server class uses the is aMemberOf object property to indicate the relationship between a Server instance and a System instance. Additionally, the Server class uses the supports object property to indicate the relationship between a Server instance and an App instance, API instance, VPoint instance, or VNode instance. Additionally, the Server class uses the isRegardedAs object property to indicate the relationship between a Server instance and a PMNode instance.

[0196] By defining this relationship, a mobile node 30M such as a car or a smartphone can be treated in the same way as a node 30 used as a sensor or actuator, and at the same time treated as an MEC server.

[0197] The Server class has data properties such as Server ID (an identifier for a Server instance) and Address (an address specified for access via a network).

[0198] (Application (App) class)

[0199] The App class uses the isRunningOn object property to indicate the relationship between the App instance and the Server instance. In addition, the App class uses the requestsViaM2MApi object property to indicate the relationship between the App instance and the API instance.

[0200] The Application (App) class has data properties such as Application (App) ID (application identifier), Address (Address), and Description (Description) (comments).

[0201] (API Class)

[0202] The API class uses the object property of respondsViaM2MApi (responds to the request of M2M API) to represent the relationship between the API instance and the application (App) instance. In addition, the API class uses the object property of requestViaPrimAPI (makes a request using the original API) to represent the relationship between the API class and the VPoint class or VNode class. In addition, the API class uses the object property of isRunningOn to represent the relationship between the API instance and the server (Server) instance.

[0203] The API class has data properties such as API ID (an identifier of the API instance) and Address.

[0204] (Area class)

[0205] An Area is defined as a rectangle enclosing a geographic area by 0.1 minute (6 seconds) of latitude and meridian. 0.1 minute of latitude and longitude is approximately 185 meters near Japan. Note that the length of a side of an Area can be any length. The shape of an Area is not limited to a rectangle and can be optional.

[0206] The Area class has object properties of isEastOf, isWestOf, isSouthOf, and isNorthOf, and expresses the east, west, south, and north adjacency relationships between Area instances. In addition, the Area class uses the contains object property to express the relationship between Area instances and PSink instances.

[0207] The Area class has data properties such as Area ID (area identifier), Address, SW Lat Lon (latitude and longitude of the southwest corner), NW Lat Lon (latitude and longitude of the northeast corner), and Description.

[0208] (PSink class)

[0209] The PSink class uses the object properties of isInstalledIn (installed in), requestsViaDevApi (making requests using the device API), and isVirtualizedWith (virtualized with) to represent the relationship between the PSink instance and the area (Area) instance, PNode instance, and VPoint instance, respectively.

[0210] The PSink class has data properties such as PSink ID (physical sink identifier), Address, LatLon (latitude and longitude), and Description.

[0211] (PNode class)

[0212] The PNode class uses the object property of respondsViaDevAPI (responds to the request of Device API) to represent the relationship between the PNode instance and the PSink instance. In addition, the PNode class uses the object property of isVirtualizedWith to represent the relationship between the PNode instance and the VNode instance or VPoint instance.

[0213] The PNode class has data properties such as PNode ID (Physical Node Identifier), PNType (PNode Type), Address, Lat Lon, Capabilities (Functions), Credentials (Credential Information), and Description.

[0214] (PMNode class)

[0215] The PMNode class is defined as a subclass of the PNode class. The PMNode class uses the object property isRegardedAs to represent the relationship between a PMNode instance and a server instance. By defining this relationship, a mobile node 30M such as a car or a smart phone can be treated as a node 30 used as a sensor or actuator, and at the same time can be treated as a MEC server. In addition to the data properties of the PNode class, the PMNode class also has data properties such as Home MEC ID (identifier of the home MEC server of the PMNode30PM), Time (date and time), and LatLon.

[0216] (VPoint class)

[0217] The VPoint class uses the object property of isComposedOf to indicate the relationship between a VPoint instance and a PSink instance or a PNode instance. In addition, the VPoint class uses the object property of respondsViaPrim API (responds to the original API request) to indicate the relationship between a VPoint instance and a VNode instance or an API instance. In addition, the VPoint class uses the object property of isRunningOn to indicate the relationship between a VPoint instance and a server instance.

[0218] The VPoint class has data properties such as VPoint ID (Virtual Point Identifier), Address, LatLon, and Description.

[0219] (VNode class)

[0220] The VNode class uses the requestsViaPrimAPI object property to represent the relationship between a VNode instance and a VPoint instance. Additionally, the VNode class uses the respondsViaPrimAPI object property to represent the relationship between a VNode instance and an API instance. Additionally, the VNode class uses the isComposedOf object property to represent the relationship between a VNode instance and a PNode instance.

[0221] The VNode class has data properties such as VNode ID (virtual node identifier), PNType (type of the corresponding PNode), address (Address), capabilities (Capabilities) and description (Description).

[0222] The VMNode class is defined as a subclass of the VNode class.

[0223] Fig.13 1 is a diagram illustrating the relationship between instances in an M2M system according to an embodiment of the present disclosure. Although detailed description is omitted, as an example, since PMNode 30PM_21 as a mobile node 30M also has aspects of an MEC server, PMNode30PM_21 and MEC 100_21 are bidirectionally connected through the object property of isRegardedAs. The connection destination starting from MEC 100_21 through the object property of supports or isRunningOn is omitted. However, the M2M application 10, etc. operating inside the PMNode 30PM_21 serving as an MEC server exists in the front.

[0224] <5.2.M2M system architecture>

[0225] Fig.14 is a diagram illustrating an example of the architecture of an M2M system according to an embodiment of the present disclosure. Note that Fig.14 The modules included in the server shown in FIG. 1 may be implemented as, for example, Figure 6 The functional blocks included in the control unit 130 of the information processing device 100 shown in FIG. 1 and FIG. 2 may be implemented as an application executed by the information processing device 100. Similarly, the modules included in PMNode30PM_21 may be implemented as, for example, Figure 8 The functional blocks included in the control unit 350 of the wireless communication device 300 shown in FIG. 1 , or may be implemented as an application executed by the wireless communication device 300 .

[0226] like Fig.14As shown in , the M2M system may include a network configured by a core network of a mobile phone, the Internet, etc. In this embodiment, an environment is assumed in which a data center (not shown) and an MEC base are connected to the network. It is assumed that the cloud server 100_1 is installed in the data center. It is assumed that MEC servers 100_21 and 100_22 are installed in the MEC base.

[0227] In the following description, cloud server 100_1 is a general term for a server installed in a data center. It is assumed that MEC servers 100_21 and 100_22 are servers installed in MEC sites. When MEC servers 100_21 and 100_22 are not distinguished, MEC servers 100_21 and 100_22 are referred to as MEC servers 100_20. MEC server 100_20 is a general term for a server installed in a MEC site.

[0228] Note that PSink 20P, PNode 30P, PMNode 30PM, VPoint 20V, VNode 30V, VMNode30VM, M2M App (M2M application) 10 and M2MAPI 40 are as described above. The M2M application (App) 10 may be arranged in at least one of the cloud server 100_1 and the MEC server 100_20. PNode 30P and VNode 30V may be associated in a one-to-one relationship, or may be associated in a many-to-one relationship. PMNode30PM and VMNode 30VM may be associated in a one-to-one relationship, or may be associated in a many-to-one relationship. PSink 20P and VPoint 20V may be associated in a one-to-one relationship, or may be associated in a many-to-one relationship.

[0229] The graph DB is a database that stores the geographical arrangement relationship between each physical equipment and the relationship between the physical equipment and the modules obtained by virtualizing the physical equipment as a graph. The local map DB 124 is installed in the MEC server 100_20. The local map DB 124 stores information about the nodes 30 and virtual modules arranged in the geographical area controlled by the MEC server 100_20. The global graph DB 122 is installed in the cloud server 100_1 and stores information about the nodes 30 and virtual modules of the entire system.

[0230] The sensing DB is a database that stores sensor data measured by sensors. The local sensing DB 123 is installed in the MEC server 100_20. The global sensing DB 121 is installed in the cloud server 100_1.

[0231] The local sensing DB 123 in the MEC server 100_20 stores sensor data measured by sensors installed near the MEC base. In addition, the sensor data stored in the local sensing DB 123 in the MEC server 100_20 is also stored in the global sensing DB 121 in the cloud server 100_1 as a backup.

[0232] User U is a user who starts and uses the M2M application (App) 10. Fig.14 In the example, user U1 uses M2M application (App) 10_31 via cloud server 100_1, while user U2 uses M2M application (App) 10_211 via PMNode 30PM_21.

[0233] The manager (Mgr) is a module that manages and controls the M2M system. In the MEC server 100_20, the local manager (local Mgr) 136 operates. In the cloud server 100_1, the global manager (global Mgr) 132 operates.

[0234] The user U1 requests the global manager 132 to start the M2M application 10. Alternatively, when the user U2 uses the mobile node 30M (for example, when the user U2 rides in a car or uses a smart phone), the user U2 sometimes requests the local manager 136_21 operating on the mobile node 30M to start the M2M application 10. The user UA is an administrator of the M2M system and manages the M2M system via the global manager 132.

[0235] AAA (Authentication, Authorization, and Accounting) is a module that manages authentication, authorization, and usage history of a user U, a node 30, etc. Local AAA 135 operates on the MEC server 100_20. Global AAA 131 operates on the cloud server 100_1.

[0236] The repository (Repo) is a database storing the program image of the M2M application 10. The global repository (global Repo) 133 is installed in the cloud server 100_1. The local repository (local Repo) 137 is installed in the MEC server 100_20 or the mobile node 30M.

[0237] MANO (Management and Orchestration) is a module that calculates whether the M2M application 10 is optimally arranged in the MEC server 100_20 or the cloud server 100_1 when the user U starts the M2M application 10. The global MANO 134 is installed in the cloud server 100_1, and the local MANO 138 is installed in the mobile node 30M.

[0238] Since the mobile node 30M also has aspects of the MEC server 100_20, the same software modules as those of the MEC server 100_20 operate inside the mobile node 30M, and the local MANO 138 also operates inside the mobile node 30M. In addition, since the mobile node 30M also has aspects of the node 30, there are also PNode 30P_211 and PSink20P_211.

[0239] <5.3. Definition of message types>

[0240] In the following description of the M2M system, the message types described below are used.

[0241] Examples of message types related to the M2M application 10 include an application start request, an application start response, an application configuration information request, an application configuration information response, an application launch request, an application launch response, an application acquisition request, and an application acquisition response.

[0242] Examples of MANO-related message types include MANO Request and MANO Response.

[0243] Examples of message types related to the PNode 30P include a PN Registration Request, a PN Registration Response, a PN Disconnection Report, a PN Deletion Request, and a PN Deletion Response.

[0244] Examples of message types related to a graph indicating relationships between modules include a graph search request, a graph search response, a graph update request, and a graph update response.

[0245] Examples of connection-related message types include connection requests and connection responses.

[0246] Examples of data-related message types include data parsing request, data parsing response, data write, data search request, data search response, data update request, data update response, data get request, data get response, data notification, data read request, and data read response.

[0247] Examples of message types related to the operation of the M2M system include an operation request, an operation response, an operation indication request, and an operation indication response.

[0248] Examples of authentication-related message types include authentication request, authentication response, authentication authorization request, and authentication authorization response.

[0249] Examples of other message types include load reports, location resolution requests, and location resolution responses.

[0250] <5.4. Field Definition>

[0251] The message, the entry of the global map DB 122 and the local map DB 124, and the management table (not shown) saved by the VPoint 20V and the VMNode 20VM include the fields described below. Note that the fields included in the management table are examples. Fields other than the fields described below may be included in the management table.

[0252] Action field: indicates the action to be instructed to the actuator.

[0253] Address field: indicates the network address.

[0254] Application Image (AppImage) field: represents image data of an application.

[0255] Application Name (AppName) field: indicates the name of the M2M application.

[0256] Capability field: indicates the function.

[0257] Computation Load (CompLoad) field: indicates the load information of the computing resources.

[0258] Condition field: indicates whether the condition meets the data parsing condition.

[0259] Configuration Information (ConfInfo) field: indicates configuration information related to the application (size of the program, requested computing resources, network bandwidth, etc.).

[0260] Credential field: indicates the credit information.

[0261] Data field: stores sensor data.

[0262] Description field: indicates comments.

[0263] End Time field: indicates the end time.

[0264] Home MEC ID field: indicates the identifier of the home MEC server of the PMNode.

[0265] isComposedOf field: represents the identifier of the instance associated by the isComposedOf property.

[0266] isInstalledIn field: represents the identifier of the instance associated by the isInstalledIn property.

[0267] isRegardedAs field: represents the identifier of the instance associated by the property isRegardedAs.

[0268] isRunningOn field: represents the identifier of the instance associated with the isRunningOn property.

[0269] isVirtualizedWith field: represents the identifier of the instance associated with the isVirtualizedWith property.

[0270] Lat Lon field: indicates latitude and longitude.

[0271] MECID field: indicates the identifier of the MEC server 100_20.

[0272] NE Lat Lon field: Indicates the latitude and longitude of the northeast corner of the geographic area.

[0273] Network Load (NetLoad) field: indicates the network load information.

[0274] ·No Values ​​field: indicates the number of sensor data.

[0275] ·VN number (No VN) field: indicates the number of VNode 30V.

[0276] · VP number (No VP) field: indicates the number of VPoint 20V.

[0277] Parameter (Param) field: indicates the parameters when the M2M application 10 is started.

[0278] PNID field: indicates the identifier of the PNode 30P.

[0279] PNType field: indicates the type of the PNode 30P.

[0280] PSID field: indicates the identifier of PSink 20P.

[0281] Query Type field: indicates the type of data analysis request.

[0282] The requestsViaDevApi field indicates the identifier of the instance associated with the requestViaDevApi property.

[0283] · requestsViaPrimApi field: represents the identifier of the instance associated with the requestViaPrimApi property.

[0284] ·respondsViaDevApi field: represents the identifier of the instance associated via the property respondsViaDevApi.

[0285] ·respondsViaPrimApi field: represents the identifier of the instance associated through the property respondsViaPrimApi.

[0286] Session Key field: indicates the authenticated session key.

[0287] Start Time field: indicates the start time.

[0288] Status field: indicates the result of the processing. OK indicates that the processing was successful.

[0289] SW Lat Lon field: indicates the latitude and longitude of the southwest corner of the geographic area.

[0290] Time field: indicates date and time.

[0291] Type field: indicates the type of the packet.

[0292] UserID field: indicates the identifier of user U.

[0293] VNAddress field: indicates the address of VNode 30V.

[0294] VNID field: indicates the identifier of the VNode 30V.

[0295] VPAddress field: indicates the address of VPoint 20V

[0296] VPID field: indicates the identifier of VPoint 20V.

[0297] For example, the value of the Query Type field is as follows: Note that the value of the Query Type field described below is an example and may be a value other than the value described below.

[0298] Node Search #1

[0299] Node Search #2

[0300] Location search

[0301] Node conditions

[0302] Node current

[0303] ·Node past

[0304] ·Location conditions

[0305] Current location

[0306] · Location in the past

[0307] <5.5. Other definitions>

[0308] Here, in addition to the definitions described above, definitions used in the following description are described. Note that the following definitions are examples, and definitions other than the definitions described below may also be used as an embodiment of the present disclosure.

[0309] (Actuator)

[0310] The action name (Act Name) is an example of the action instructed to the actuator. The action parameter (Act Param) is an example of the parameter in the instruction to the actuator.

[0311] (Network address)

[0312] Addr PMN#n is the network address of PMNode 30PM_n (n is a natural number of 1 or more). Addr PN#n is the network address of PNode 30P_n. Addr PS#n is the network address of PSink 20P_n. Addr VMN#n is the network address of VMNode 30VM_n.

[0313] Addr VN is an example of a network address of VNode 30V. Addr VN#n is a network address of VNode 30V_n (n is a natural number of 1 or more). Addr VP is an example of a network address of VPoint. Addr VP#n is a network address of VPoint 20V_n.

[0314] (application)

[0315] An application image (App Image) is an example of a program image of an application. Application information (App Info) is an example of configuration information of an application. An application name (App Name) is an example of a name of an application. Application parameters (App Param) are an example of parameters when an application is started.

[0316] (Function)

[0317] Caps PMN#n is a function of PMNode 30PM_n. Caps PN#n is a function of PNode 30P_n. Caps VMN#n is a function of VMNode 30VM_n.

[0318] CapType is an example of a function. CondType is an example of a condition. Cred PMN#n is the credit information of the PMNode 30PM_n. Cred PN#n is the credit information of the PNode 30P_n. Cred User#n is the credit information of the user Un.

[0319] (Update information)

[0320] Data Update (Data Update) is an example of update information sent by the local sensing DB 123 to the global sensing DB 121. Data Graph Update (Data GraphUpdate) is an example of update information sent by the local graph DB 124 to the global graph DB 122.

[0321] (Sensor data)

[0322] Data (Data) PMN#n is an example of sensor data transmitted by PMNode 30PM_n. Data (Data) PN#n is an example of sensor data transmitted by PNode 30P_n. Sensed data (Data Sensed) is an example of sensor data.

[0323] (Notes)

[0324] Desc PN#n is the annotation of PNode 30P_n. Desc PS#n is the annotation of PSink 20P_n. Desc PMN#n is the annotation of PMNode 30PM_n. Desc VMN#n is the annotation of VMNode 30VM_n. Desc VN#n is the annotation of VNode 30V_n. Desc VP#n is the annotation of VPoint 20V_n.

[0325] (Identifier)

[0326] Id Area#n is the identifier of area n. Id MEC#n is the identifier of MEC server 100_n. Id PMN#n is the identifier of PMNode 30PM_n. Id PN#n is the identifier of PNode 30P_n. Id PS#n is the identifier of PSink 20P_n. Id User#n is the identifier of user Un.

[0327] Id VMN#n is an identifier of VMNode 30VM_n. Id VN is an example of an identifier of VNode 30V. Id VN#n is an example of an identifier of VNode 30V_n. Id VP is an example of an identifier of VPoint 20V. Id VP#n is an identifier of VPoint 20V_n.

[0328] (latitude and longitude)

[0329] LatLon NE is an example of the latitude and longitude of the northeast corner of the region. LatLon PMN#n is the latitude and longitude of PMNode 30PM_n. LatLon PN#n is the latitude and longitude of PNode 30P_n. LatLon PS#n is the latitude and longitude of PSink 20P_n. LatLon SW is an example of the latitude and longitude of the southwest corner of the region.

[0330] (Load Information)

[0331] Load Comp is an example of load information for a computing resource. Load Net is an example of load information for a network resource.

[0332] (quantity)

[0333] Num VNs is an example of the number of VNode 30V. Num VPs is an example of the number of VPoint 20V.

[0334] (type)

[0335] PNType PMN#n is the type of PMNode 30PM_n. PNType PN#n is the type of PNode 30P_n. PNType VMN#n is the type of PNode 30PM corresponding to VMNode 30VM_n. PNType VN#n is the type of PNode 30P corresponding to VNode 30V_n.

[0336] (Session Key)

[0337] SKey PMN#n is a session key shared between PMNode 30PM_n and VPoint 20V_n. SKey PN#n is a session key shared between PNode 30P_n and VPoint 20V_n.

[0338] (Date and Time)

[0339] Time End is an example of the end time of the specified date and time. Time PMN#n is an example of the date and time when the PMNode 30PM_n is connected to the PSink 20P. Time PMN#n_D is an example of the date and time when the PMNode 30PM_n sends sensor data.

[0340] The time (Time) PN#n is an example of the date and time when the PNode 30P_n is installed. The time (Time) PN#n_D is an example of the date and time when the PNode 30P_n transmits the sensor data.

[0341] Time DataUpdate is an example of the date and time when the local sensing DB 123 sends update data to the global sensing DB 121. Time GraphUpdate is an example of the date and time when the local graph DB 124 sends update data to the global graph DB 122. Time LoadUpdate is an example of the date and time when the local manager 136 sends load information to the global manager 132.

[0342] The sensed time (Time Sensed) is an example of the date and time when the sensor data is measured. The time start (Time Start) is an example of the start time of the specified date and time.

[0343] <5.6. Initial state>

[0344] M2M systems (see Fig.14 )’s initial state is as follows.

[0345] All software modules in MEC server 100_20 have been started. The instance information of MEC server 100_20 has been registered in the local map DB 124. PSink 20P has been installed. The instance information of PSink 20 has been registered in the local map DB 124.

[0346] PMNode 30PM operates as an MEC server. To this end, the instance information of PMNode 30PM has been registered in the local map DB 124 in the initial state. However, in the initial state, PMNode 30PM has not been physically connected to PSink 20P. PNode 20P and the like have not been connected to PSink 20P.

[0347] (Instance information of PSink 20P_11)

[0348] Table 1 is a table illustrating entries of PSink 20P_11 in an initial state in the local map DB 124_1. Table 1 illustrates an example of instance information of PSink 20P_11 according to an embodiment of the present disclosure. The instance information shown in Table 1 is registered (entered) in the local map DB 124_1, for example, in an initial state.

[0349] (Table 1) Entries of PSink 20P_11 in the initial state in the local map DB 124_1

[0350] PSID=Id_PS#11 isVirtualizedWtih=Id_VP#11 isInstalledIn=Id_Area#1 requestsViaDevApi=[null] Address = Address_PS#11 Lat Lon=LatLon PS#11 Description = Desc_PS#11

[0351] In the example shown in Table 1, the local map DB 124_1 stores the ID of the PSink 20P_11 (PSID=Id_PS#11), information related to the corresponding virtual point (isVirtualizedWtih=Id_VP#11), and the like as instance information of the PSink 20P_11.

[0352] Note that the instance information shown in Table 1 is an example. The present map DB 124_1 may store information other than the information shown in Table 1 as the instance information of the PSink 20P_11.

[0353] (Instance information of VPoint 20V_11)

[0354] Table 2 is a table illustrating entries of VPoint 20V_11 in the initial state in the local map DB 124_1. Table 2 illustrates an example of instance information of VPoint 20V_11 according to an embodiment of the present disclosure. The instance information shown in Table 2 is registered (input) in the local map DB 124_1, for example, in the initial state.

[0355] (Table 2) Entry of VPoint 20V_11 in the initial state in the local map DB 124_1

[0356] VPID=Id_VP#11 isRunningOn=Id_MEC#1 isComposedOf=Id_PS#11 Address = Address_VP#11 Lat Lon=LatLon_PS#11 Description = Desc_VP#11

[0357] In the example shown in Table 2, the local map DB 124_1 stores the ID of the VPoint 20V_11 (VPID=Id_VP#11), information related to the operating MEC server (isRunningOn=Id_MEC#1), etc. as instance information of the VPoint 20V_11. Note that Id_MEC#1 is an identifier for identifying the MEC server 100_21.

[0358] Note that the instance information shown in Table 2 is an example. The present map DB 124_1 may store information other than the information shown in Table 2 as the instance information of the VPoint 20V_11.

[0359] (Instance information of VNode 30V_11)

[0360] Table 3 is a table illustrating entries of the VNode 30V_11 in the initial state in the local map DB 124_1. Table 3 illustrates an example of instance information of the VNode 30V_11 according to an embodiment of the present disclosure. The instance information shown in Table 3 is registered (input) in the local map DB 124_1, for example, in the initial state.

[0361] (Table 3) Entry of VNode 30V_11 in the initial state in the local map DB 124_1

[0362] VNID=Id_VN#11 isRunningOn=Id_MEC#1 requestsViaPrimApi=Id_VP#11 isComposedOf=[empty] PNType=PNType_VN#11 Address = Address_VN#11 Capability = [blank] Description = Desc_VN#11

[0363] In the example shown in Table 3, the local map DB 124_1 stores the ID of the VNode 30V_11 (VNID=Id_VN#11), information related to the operating MEC server (isRunningOn=Id_MEC#1), and the like as instance information of the VNode 30V_11.

[0364] Note that the instance information shown in Table 3 is an example. The present map DB 124_1 may store information other than the information shown in Table 3 as the instance information of the VNode 30V_11.

[0365] (Instance information of VMNode 30VM_11)

[0366] Table 4 is a table illustrating entries of VMNode30VM_11 in the initial state in the local map DB 124_1. Table 4 illustrates an example of instance information of VMNode30VM_11 according to an embodiment of the present disclosure. The instance information shown in Table 4 is registered (input) in the local map DB 124_1, for example, in the initial state.

[0367] (Table 4) Entry of VMNode 30VM_11 in the initial state in the local map DB 124_1

[0368] VNID=Id_VMN#11 isRunningOn=Id_MEC#1 isComposedOf=Id_PMN#11 PNType = PNType_VMN#11 Address = Address_VMN#11 Capability = Caps_VMN#11 Description = Desc_VMN#11

[0369] In the example shown in Table 4, the local map DB 124_1 stores the ID of the VMNode 30VM_11 (VNID=Id_VMN#11), information related to the operating MEC server (isRunningOn=Id_MEC#1), and the like as instance information of the VMNode 30VM_11.

[0370] Note that the instance information shown in Table 4 is an example. The present map DB 124_1 may store information other than the information shown in Table 4 as the instance information of the VMNode 30VM_11.

[0371] (Instance information of VMNode 30VM_21)

[0372] Table 5 is a table illustrating entries of VMNode30VM_21 in the initial state in the local map DB 124_2. Table 5 illustrates an example of instance information of VMNode30VM_21 according to an embodiment of the present disclosure. The instance information shown in Table 5 is registered (input) in the local map DB 124_2, for example, in the initial state.

[0373] (Table 5) Entry of VMNode 30VM_21 in the initial state in the local map DB 124_2

[0374] VNID=Id_VMN#21 isRunningOn=Id_MEC#2 isComposedOf=Id_PMN#21 PNType = PNType_VMN#21 Address = Address_VMN#21 Capability = Caps_VMN#21 Description = Desc_VMN#21

[0375] In the example shown in Table 5, the local map DB 124_2 stores the ID of the VMNode 30VM_21 (VNID=Id_VMN#21), information related to the operating MEC server (isRunningOn=Id_MEC#2), etc. as instance information of the VMNode 30VM_21. Note that Id_MEC#2 is an identifier for identifying the MEC server 100_22.

[0376] Note that the instance information shown in Table 5 is an example. The present map DB 124_2 may store information other than the information shown in Table 5 as the instance information of the VMNode 30VM_21.

[0377] (PMNode 30PM_11 instance information)

[0378] Table 6 is a table illustrating entries of PMNode30PM_11 in the initial state in the local map DB 124_1. Table 6 illustrates an example of instance information of PMNode30PM_11 according to an embodiment of the present disclosure. The instance information shown in Table 6 is registered (input) in the local map DB 124_1, for example, in the initial state.

[0379] (Table 6) Entry of PMNode 30PM_11 in the initial state in the local map DB 124_1

[0380] VNID=Id_PMN#11 isRegardedAs=Id_MEC#11 isVirtualizedWith=Id_VMN#11 PNType = PNType_PMN#11 Address = [blank] Time = [blank] Lat Lon = [blank] Capability = Caps_PMN#11 Credential = Cred_PMN#11 Description = Desc_PMN#11

[0381] In the example shown in Table 6, the local map DB 124_1 stores the ID (VNID=Id_PMN#11) of the PMNode 30PM_11 as the instance information of the PMNode 30PM_11. When the PMNode 30PM_11 operates as an MEC server, the local map DB 124_1 stores information related to the MEC server (isRegardedAs=Id_MEC#11), etc. Note that Id_MEC#11 is an identifier for identifying the MEC server 100_211.

[0382] Note that the instance information shown in Table 6 is an example. The present map DB 124_1 may store information other than the information shown in Table 6 as the instance information of the PMNode 30PM_11.

[0383] (PMNode 30PM_21 instance information)

[0384] Table 7 is a table illustrating entries of PMNode30PM_21 in the initial state in the local map DB 124_2. Table 7 illustrates an example of instance information of PMNode30PM_21 according to an embodiment of the present disclosure. The instance information shown in Table 7 is registered (input) in the local map DB 124_2, for example, in the initial state.

[0385] (Table 7) Entries of PMNode 30PM_21 in the initial state in the local map DB 124_2

[0386] VNID=Id_PMN#21 isRegardedAs=Id_MEC#21 isVirtualizedWith=Id_VMN#21 PNType = PNType_PMN#21 Address = [blank] Time = [blank] Lat Lon = [blank] Capability = Caps_PMN#21 Credential = Cred_PMN#21 Description = Desc_PMN#21

[0387] In the example shown in Table 7, the local map DB 124_2 stores the ID (VNID=Id_PMN#21) of the PMNode 30PM_21 as the instance information of the PMNode 30PM_21. When the PMNode 30PM_21 operates as an MEC server, the local map DB 124_2 stores information related to the Mec server (isRegardedAs=Id_MEC#21), etc. Note that Id_MEC#21 is an identifier for identifying the MEC server when the PMNode 30PM_21 operates as an MEC server.

[0388] Note that the instance information shown in Table 7 is an example. The present map DB 124_2 may store information other than the information shown in Table 7 as instance information of the PMNode 30PM_21.

[0389] <5.7. Fixed Node Installation Process>

[0390] Subsequently, a process of reinstalling PNode 30P_11 as a fixed node in the M2M system via PSink 20P_11 is described. Note that although the installation process for PNode 30P_11 is described here, other fixed nodes (eg, PNode 30P_21) may be installed in a similar manner.

[0391] Table 8 is a table illustrating an entry of the PNode 30P_11 in an initial state in the local map DB 124_1. Table 8 illustrates another example of instance information of the PNode 30P_11 according to an embodiment of the present disclosure.

[0392] (Table 8) Entry of PNode 30P_11 in the initial state in the local map DB 124_1

[0393] VNID=Id_PN#11 isVirtualizedWith = [null] isVirtualizedWith = [null] requestsViaDevApi=[null] PNType=[empty] Address = [blank] Time = [blank] Lat Lon = [blank] Capability = [blank] Credential = Cred_PN#11 Description = [empty]

[0394] First, when the PNode 30P_11 is installed in the M2M system, the administrator (user) UA registers the instance information shown in Table 8 in the local map DB 124_1.

[0395] That is, the administrator UA assigns Id PN#11 as an identifier to the PNode 30P_11. In addition, the administrator UA registers Cred PN#11 as the credit information of the PNode 30P_11 in the local AAA 135_1.

[0396] Fig.15 1 is a sequence diagram illustrating an example of an installation process for a fixed node according to an embodiment of the present disclosure. When a PNode 30P, which is basically a fixed node, is first connected to an M2M system, Fig.15 The process shown in .

[0397] First, PNode 30P_11 establishes a wireless link with PSink 20P_11 (step S601).

[0398] The PNode 30P_11 sends a connection request message to the PSink 20P_11 which is the virtual module corresponding thereto (step S602).

[0399] Table 9 is a table illustrating a connection request message. Table 9 illustrates an example of a connection request message sent by the PNode 30P_11 to the PSink 20P_11 according to an embodiment of the present disclosure.

[0400] (Table 9) Connection Request Message

[0401] Type = Connection Request PNID=Id_PN#11 PNType=PNType_PN#11 Time = Time_PN#11 Lat Lon=LatLon_PN#11 Capability = Caps_PN#11 Credential = Cred_PN#11 Home MEC ID = [empty] Description = Desc_PN#11

[0402] The connection request message may include, for example, an identifier of the PNode 30P_11 and information related to the type of the PNode 30P_11, the connection time, etc. Note that since the PNode 30P_11 is a fixed node, the Home MEC ID field is blank (Home MEC ID = [empty]). Note that the connection request message shown here is an example. The PNode 30P_11 may send a connection request message including information other than that shown in Table 9 to the PSink 20P_11.

[0403] like Fig.15 As shown in FIG. 6 , when receiving the connection request message, the PSink 20P_11 sends the connection request message to the VPoint 20V_11 which is the virtual module corresponding thereto (step S603 ).

[0404] When receiving the Connection Request message, the VPoint 20V_11 determines that the PNode 30P_11 is a fixed node because the value of the Home MEC ID field is blank.

[0405] The VPoint 20V_11 sends an authentication request message to the local AAA 135_1. When the authenticity check succeeds, the local AAA 135_1 sends an authentication response message to the VPoint 20V_11 (step S604).

[0406] Table 10 is a table illustrating an authentication request message. Table 10 illustrates an example of an authentication request message sent by the VPoint 20V_11 to the local AAA 135_1.

[0407] (Table 10) Authentication Request Message

[0408] Type = Authentication Request PNID=Id_PN#11 Credential = Cred_PN#11

[0409] The authentication request message may include, for example, an identifier of the PNode 30P_11 and credit information of the PNode 30P_11. Note that the authentication request message shown here is an example. The VPoint 20V_11 may send an authentication request message including information other than that shown in Table 10 to the local AAA 135_1.

[0410] Table 11 is a table illustrating an authentication response message. Table 11 illustrates an example of an authentication response message sent by the local AAA 135_1 to the VPoint 20V_11.

[0411] (Table 11) Authentication Response Message

[0412] Type = Authentication Response PNID=Id_PN#11 Status = OK

[0413] The authentication response message may include, for example, an identifier of the PNode 30P_11 and information related to the authentication result (Status). Table 11 illustrates an authentication response message in the case where the authentication is successful. Note that the authentication response message shown here is an example. The local AAA 135_1 may send an authentication response message including information other than the information shown in Table 11 to the VPoint 20V_11.

[0414] like Fig.15 As shown in , when receiving the authentication response message, the VPoint 20V_11 creates SKey PN#11, which is a session key indicating that the PNode 30P_11 has been authenticated.

[0415] Subsequently, a graph search request / response is exchanged between the VPoint 20V_11 and the local graph DB 124_1 (step S605). The VPoint 20V_11 sends a graph search request message to the local graph DB 124_1, and searches for the VNode 30V corresponding to the PNode 30P_11.

[0416] When receiving the graph search request message, the local graph DB 124_1 searches the database for a VNode 30V corresponding to the PNode 30P_11 based on the value of the PNType field, and sends a graph search response message to the VPoint 20V_11. In this example, the VNode 30V_11 is found as the VNode 30V corresponding to the PNode 30P_11.

[0417] Table 12 is a table illustrating a graph search request message. Table 12 illustrates an example of a graph search request message transmitted by the VPoint 20V_11 to the local graph DB 124_1.

[0418] (Table 12) Graph search request message

[0419]

[0420] The graph search request message may include, for example, an identifier of the PNode 30P_11 and a query type indicating the type of data resolution request. Note that the graph search request message shown here is an example. The VPoint 20V_11 may send a graph search request message including information other than the information shown in Table 12 to the local graph DB 124_1.

[0421] Table 13 is a table illustrating a graph search response message. Table 13 illustrates an example of a graph search response message transmitted by the local graph DB 124_1 to the VPoint 20V_11.

[0422] (Table 13) Graph Search Response Message

[0423]

[0424] The graph search response message may include, for example, an identifier of PNode 30P_11 and a query type indicating a data resolution request type. Table 13 illustrates the following situation, in which the VNode 30V corresponding to PNode 30P_11 is VNode 30V_11 as a graph search result. Note that the graph search response message illustrated here is an example. The present map DB 124_1 may send a graph search response message including information other than the information shown in Table 13 to VPoint 20V_11.

[0425] Subsequently, the VPoint 20V_11 sends a PN registration request message to the VNode 30V_11 (step S606). Using the PN registration request message, the VPoint 20V_11 requests the VNode 30V_11 to register the PNode 30P_11.

[0426] Table 14 is a table illustrating a PN registration request message. Table 14 illustrates an example of a PN registration request message transmitted by the VPoint 20V_11 to the VNode 30V_11.

[0427] (Table 14) PN Registration Request Message

[0428] Type = PN Registration Request PNID=Id_PN#11 Address = Address_PN#11 VNID=Id_VN#11 PSID=Id_PSink#11

[0429] The PN registration request message may include, for example, an identifier of the PNode 30P_11 and information related to the network address of the PNode 30P_11. Note that the PN registration request message shown here is an example. The VPoint 20V_11 may send a PN registration request message including information other than that shown in Table 14 to the VNode 30V_11.

[0430] When receiving the PN Registration Request message, the VNode 30V_11 recognizes that the PNode 30P_11 has been added as a management target of the VNode 30V_11.

[0431] Subsequently, PN registration request / response is exchanged between the VNode 30V_11 and the local map DB 124_1 (step S607).

[0432] VNode 30V_11 sends a PN registration request message to the local map DB 124_1. Upon receiving the PN registration request message, the local map DB 124_1 writes information related to PNode 30P_11 into the database. Subsequently, the local map DB 124_1 sends a PN registration response message to VNode 30V_11. The PN registration request message sent by VNode 30V_11 may be the same as the PN registration request message shown in Table 14.

[0433] Table 15 is a table illustrating a PN registration response message. Table 15 illustrates an example of a PN registration response message transmitted by the local map DB 124_1 to the VNode 30V_11.

[0434] (Table 15) PN Registration Response Message

[0435] Type = PN Registration Response PNID=Id_PN#11 Status = OK

[0436] The PN registration response message may include, for example, an identifier of the PNode 30P_11 and information related to the registration result (status). Table 15 illustrates a PN registration response message in the case where the registration is successful. Note that the PN registration response message shown here is an example. The map DB 124_1 may send a PN registration response message including information other than the information shown in Table 15 to the VNode 30V_11.

[0437] like Fig.15 As shown in FIG. 6 , upon receiving the PN registration response message, the VNode 30V_11 sends a PN registration response message to the VPoint 20V_11 (step S608 ).

[0438] When receiving the PN registration response message, the VPoint 20V_11 sends a connection response message to the PSink 20P_11 (step S609).

[0439] Table 16 is a table illustrating a connection response message. Table 16 illustrates an example of a connection response message sent by the VPoint 20V_11 to the PSink 20P_11.

[0440] (Table 16) Connection response message

[0441] Type = Connection Response Status = OK PNID=Id_PN#11 Session Key = SKey_PN#11

[0442] The connection response message may include, for example, an identifier of the PNode 30P_11 and information related to the connection result (status). Table 16 illustrates a connection response message in the case of a successful connection. Note that the connection response message shown here is an example. VPoint20V_11 may send a connection response message including information other than the information shown in Table 16 to PSink 20P_11.

[0443] When receiving the connection response message, the PSink 20P_11 sends the connection response message to the PNode 30P_11 (step S610). The PNode 30P_11 receives the connection response message. Therefore, the PNode 30P_11 and the VPoint 20V_11 share the SKey PN#11 as the session key (step S611).

[0444] By executing Fig.15 , the VPoint 20V_11 and the VNode 30V_11 add the entries shown in Table 17 to the PNode management tables respectively included in the VPoint 20V_11 and the VNode 30V_11. Table 17 is a table illustrating PNode management table entries for the PNode 30P_11.

[0445] (Table 17) PNode Management Table Entries for PNode 30P_11

[0446]

[0447]

[0448] The PNode management table entry may include, for example, an identifier of the PNode 30P_11 and information related to the network address. Note that the PNode management table entry shown here is an example. VPoint 20V_11 and VNode 30V_11 may manage the PNode management table entry as a PNode management table entry that includes information other than the information shown in Table 17 as the PNode management table entry. VPoint 20V_11 and VNode 30V_11 may manage different kinds of information as PNode management table entries, respectively.

[0449] In the following description, when transmitting sensor data to VPoint 20V_11 via PSink 20P_11, PNode 30P_11 transmits a data notification message including SKey PN# 11. Thus, VPoint 20V_11 can confirm that PNode 30P_11 has been authenticated without querying the local AAA 135_1.

[0450] The local map DB 124_1 updates the instance information of the PNode 30P_11 shown in Table 8 as shown in Table 18. Table 18 is a table illustrating the entry of the PNode 30P_11 in the local map DB 124_1 after the PNode 30P_11 is installed.

[0451] (Table 18) PNode in local map DB 124_1 after installing PNode 30P_11

[0452] 30P_11's entry

[0453]

[0454]

[0455] Furthermore, the local map DB 124_1 updates the instance information of the VNode 30V_11 shown in Table 3 as shown in Table 19. Table 19 is a table illustrating the entry of the VNode 30V_11 in the local map DB 124_1 after the PNode 30P_11 is installed.

[0456] (Table 19) VNodes in the local map DB 124_1 after installing PNode 30P_11

[0457] 30V_11's entry

[0458] VNID=Id_VN#11 isRunningOn=Id_MEC1 requestsViaPrimApi=Id_VP#11 isComposedOf=Id_PN#11 PNType=PNType_VN#11 Address = Address_VN#11 Capability = Caps_PN#11 Description = Desc_VN#11

[0459] The local map DB 124_1 updates the instance information of the PSink 20P_11 shown in Table 1 as shown in Table 20. Table 20 is a table illustrating the entries of the PSink 20P_11 in the local map DB 124_1 after the PNode 30P_11 is installed.

[0460] (Table 20) PSink in local map DB 124_1 after installing PNode 30P_11

[0461] 20P_11's entry

[0462] PSID=Id_PS#11 isVirtualizedWtih=Id_VP#11 isInstalledIn=Id_Area#1 requestsViaDevApi=Id_PN#11 Address = Address_PS#11 Lat Lon=LatLon_PS#11 Description = Desc_PS#11

[0463] The local map DB 124_1 updates the instance information of the VPoint 20V_11 shown in Table 4 to be as shown in Table 21. Table 21 is a table illustrating the entry of the VPoint 20V_11 in the local map DB 124_1 after the PNode 30P_11 is installed.

[0464] (Table 21) VPoint in local map DB 124_1 after installing PNode 30P_11

[0465] 20V_11's entry

[0466] VPID=Id_VP#11 isRunningOn=Id_MEC1 isComposedOf=Id_PS#11 isComposedOf=Id_PN#11 respondsViaPrimApi=Id_VN#11 Address = Address_VP#11 Lat Lon=LatLon_PN#11 Description = Desc_VP#11

[0467] Assume that PNode 30P_12 exists near PNode 30P_11, and PNode 30P_11 and PNode 30P_12 have the same PNType. In this case, when PNode 30P_12 is connected, the same Fig.15 At this time, since PNode 30P_11 and PNode 30P_12 have the same PNType, VNode 30V_11 is selected as the virtual module of PNode 30P_12 as a result of step S605. As described above, for example, a plurality of PNodes 30P having the same PNType can be associated with one VNode 30V.

[0468] In addition, when PMNode 30PM_11 as a mobile node connects to PSink20P_11 under the home MEC server, the same method is used to execute Fig.15 The process shown in . The mobile node 30PM executes this process every time the PSink 20P_11 at the connection destination changes.

[0469] As a result of this process, the VPoint 20V_11 and the VNode 30V_11 add the entries shown in Table 22 to the PNode management table included in the VPoint 20V_11 and the VNode 30V_11. Table 22 is a table illustrating PNode management table entries for the PMNode 30PM_11.

[0470] (Table 22) PNode Management Table Entries for PMNode 30PM_11

[0471]

[0472]

[0473] The PNode management table entry may include, for example, an identifier of the PMNode 30PM_11 and information related to the network address. Note that the PNode management table entry shown here is an example. VPoint 20V_11 and VNode 30V_11 may manage the PNode management table entry as a PNode management table entry that includes information other than the information shown in Table 22 as the PNode management table entry. VPoint 20V_11 and VNode 30V_11 may manage different kinds of information as PNode management table entries, respectively.

[0474] Therefore, the VPoint 20V_11 and the VNode 30V_11 recognize that the PMNode 30PM_11 is currently connected to the PSink 20P_11.

[0475] When PMNode 30PM_11 is connected to PSink 20P_11, a session key is shared between PMNode 30PM_11 and VPoint 20V_11. Thus, when PMNode 30PM_11 sends sensor data, VPoint 20V_11 can confirm that PMNode 30PM_11 has been authenticated without asking the local AAA 135_1.

[0476] The local map DB 124_1 updates the instance information of the PMNode 30PM_11 shown in Table 6 to be as shown in Table 23. Table 23 is a table illustrating the entry of the PMNode 30PM_11 in the local map DB 124_1 after the PMNode 30PM_11 is connected.

[0477] (Table 23) Entries of PMNode 30PM_11 in local map db 124_1 after PMNode 30PM_11 is connected

[0478]

[0479]

[0480] For example, the local map DB 124_1 adds information related to the PSink 20P_11 to which the PMNode 30PM_11 is connected (e.g., respondsViaDevApi=Id_PS#11) to the instance information of the PMNode 30PM_11. For example, the local map DB 124_1 adds information related to the VPoint 20V_11 corresponding to the same PSink 20P_11 (e.g., isVirtualizedWith=Id_VP#11) to the instance information of the PMNode 30PM_11. The local map DB 124_1 updates a blank field (e.g., a time field or a Lat Lon field).

[0481] The local map DB 124_1 updates the instance information of the PSink 20P_11 shown in Table 20 as shown in Table 24. Table 24 is a table illustrating the entry of the PSink 20P_11 in the local map DB 124_1 after the PMNode 30PM_11 is connected.

[0482] (Table 24) Entries of PSink 20P_11 in local map DB 124_1 after PMNode 30PM_11 is connected

[0483] PSID=Id_PS#11 isVirtualizedWtih=Id_VP#11 isInstalledIn=Id_Area1 requestsViaDevApi=Id_PN#11 requestsViaDevApi=Id_PMN#11 Address = Address_PS#11 Lat Lon=LatLon PS#11 Description = Desc_PS#11

[0484] For example, the local map DB 124_1 updates a field that is blank in the instance information of the PSink 20P_11 (eg, the requestsViaDevApi field). For example, the local map DB 124_1 adds information related to the physical nodes 30 (PMNode 30PM_11 and PNode 30P_11) connected to the PSink 20P_11.

[0485] The local map DB 124_1 updates the instance information of the VPoint 20V_11 shown in Table 21 to be as shown in Table 25. Table 25 is a table illustrating the entry of the VPoint 20V_11 in the local map DB 124_1 after the PMNode 30PM_11 is connected.

[0486] (Table 25) Entry of VPoint 20V_11 in local map DB 124_1 after PMNode 30PM_11 is connected

[0487] VPID=Id_VP#11 isRunningOn=Id_MEC1 isComposedOf=Id_PS#11 isComposedOf=Id_PN#11 isComposedOf=Id_PMN#11 respondsViaPrimApi=Id_VN#11 respondsViaPrimApi=Id_VMN#11 Address = Address_VP#11 Lat Lon=LatLon_PS#11 Lat Lon=LatLon_PN#11 Lat Lon=LatLon_PMN#11 Description = Desc_VP#11

[0488] For example, the local map DB 124_1 adds information related to the physical node 30 (PMNode 30PM_11 and PNode 30P_11) connected to the PSink 20P_11 corresponding to the VPoint 20V_11 to the instance information of the VPoint 20V_11.

[0489] Therefore, the local map DB 124_1 recognizes that the PMNode 30PM_11 is currently connected to the PSink 20P_11.

[0490] <5.8. Connection process for mobile nodes (except home MEC server)>

[0491] Then, Fig.16 2 is a sequence diagram illustrating an example of a mobile node connection process according to an embodiment of the present disclosure. Here, a process in which PMNode 30PM_21 as a mobile node connects to PSink 20P_11 is described.

[0492] Since the home MEC server of PMNode 30PM_21 is MEC server 100_22, Fig.16 The example shown in indicates the process when the mobile node connects to a server other than the home MEC server. Whenever the PSink20P to be connected changes, the mobile node executes Fig.16 The process shown in .

[0493] PMNode 30PM_21 establishes a wireless link with PSink 20P_11 (step S701).

[0494] PMNode 30PM_21 sends a connection request message to PSink 20P_11 (step S702).

[0495] Table 26 is a table illustrating a connection request message. Table 26 illustrates an example of a connection request message sent by PMNode 30PM_21 to PSink 20P_11 according to an embodiment of the present disclosure.

[0496] (Table 26) Connection Request Message

[0497] Type = Connection Request PNID=Id_PMN#21 PNType = PNType_PMN#21 Time = Time_PMN#21 Lat Lon=LatLon_PMN#21 Capability = Caps_PMN#21 Credential = Cred_PMN#21 Home MEC ID = Id_MEC#2 Description = Desc_PMN#21

[0498] The connection request message may include, for example, an identifier of PMNode 30PM_21 and information related to the type of PMNode 30PM_21, connection time, etc. Note that since PMNode 30PM_21 is a mobile node, the Home MECID field includes information indicating the MEC server 100_22 as the Home MEC server.

[0499] Note that the connection request message shown here is an example. PMNode 30PM_21 may send a connection request message including information other than the information shown in Table 26 to PSink 20P_11.

[0500] When receiving the connection request message, PSink 20P_11 sends the connection request message to VPoint20V_11 which is the virtual module corresponding thereto (step S703).

[0501] When the VPoint 20V_11 receives the connection request message, authentication request / response is exchanged between the VPoint 20V_11 and the local AAA 135_2 (step S704).

[0502] Specifically, because the value of the Home MEC ID field of the received connection request message indicates the identifier of the MEC server 100_22, VPoint 20V_11 sends an authentication request message to the local AAA 135_2.

[0503] Table 27 is a table illustrating an authentication request message. Table 27 illustrates an example of an authentication request message sent by the VPoint 20V_11 to the local AAA 135_2.

[0504] (Table 27) Authentication Request Message

[0505] Type = Authentication Request PNID=Id_PMN#21 Credential = Cred_PMN#21

[0506] The authentication request message may include, for example, an identifier of the PMNode 30PM_21 and credit information of the PMNode 30PM_21. Note that the authentication request message shown here is an example. The VPoint 20V_11 may send an authentication request message including information other than that shown in Table 27 to the local AAA 135_2.

[0507] When receiving the authentication request message, the local AAA 135_2 uses the content of the Credential field to confirm the authenticity of the PMNode 30PM_21 indicated by the PNID field. When the authenticity check succeeds, the local AAA 135_2 sends an authentication response message to the VPoint 20V_11.

[0508] Table 28 is a table illustrating an authentication response message. Table 28 illustrates an example of an authentication response message sent by the local AAA 135_2 to the VPoint 20V_11.

[0509] (Table 28) Authentication Response Message

[0510] Type = Authentication Response PNID=Id_PMN#21 Status = OK

[0511] The authentication response message may include, for example, an identifier of the PMNode 30PM_21 and information related to the authentication result (Status). Table 28 illustrates an authentication response message in the case where the authentication is successful. Note that the authentication response message shown here is an example. The local AAA 135_2 may send an authentication response message including information other than the information shown in Table 28 to the VPoint 20V_11.

[0512] like Fig.16 As shown in , when receiving the authentication response message, the VPoint 20V_11 creates SKey PN#21, which is a session key indicating that the PMNode 30PM_21 has been authenticated.

[0513] Subsequently, a graph search request / response is exchanged between the VPoint 20V_11 and the local graph DB 124_2 (step S705). The VPoint 20V_11 sends a graph search request message to the local graph DB 124_2, and searches for the VNode 30V corresponding to the PMNode 30PM_21.

[0514] Table 29 is a table illustrating a graph search request message. Table 29 illustrates an example of a graph search request message transmitted by the VPoint 20V_11 to the local graph DB 124_2.

[0515] (Table 29) Graph Search Request Message

[0516]

[0517] The graph search request message may include, for example, an identifier of PMNode 30PM_21 and a query type indicating the type of data resolution request. Note that the graph search request message shown here is an example. VPoint 20V_11 may send a graph search request message including information other than the information shown in Table 29 to the local graph DB 124_2.

[0518] When receiving the graph search request message, the local graph DB 124_2 searches the database for a VNode 30V corresponding to PMNode 30PM_21 based on the value of the PNType field, and sends a graph search response message to VPoint 20V_11. In this example, VMNode 30VM_21 is found as a VNode 30V corresponding to PMNode 30PM_21.

[0519] Table 30 is a table illustrating a graph search response message. Table 30 illustrates an example of a graph search response message transmitted by the local graph DB 124_2 to the VPoint 20V_11.

[0520] (Table 30) Graph Search Response Message

[0521]

[0522] The graph search response message may include, for example, an identifier of PMNode 30PM_21 and a query type indicating the type of data resolution request. Table 30 illustrates the following situation, where, as a result of the graph search, the VNode 30V corresponding to PMNode 30PM_21 is VMNode30VM_21. Note that the graph search response message shown here is an example. The present map DB 124_2 may send a graph search response message including information other than the information shown in Table 30 to VPoint 20V_11.

[0523] As a result of this exchange, it is seen that the VNode 30V corresponding to the PMNode 30PM_21 is the VMNode 30VM_21. In other words, the VPoint 20V_11 sends a graph search request message to the local graph DB 124_2 to inform the VMNode 30VM_21 that the PMNode 30PM_21 is connected to the PSink 20P_11.

[0524] Subsequently, PN registration request / response is exchanged between VPoint 20V_11 and local map DB 124_1 (step S706). Specifically, VPoint 20V_11 sends a PN registration request message to local map DB 124_1.

[0525] Table 31 is a table illustrating a PN registration request message. Table 31 illustrates an example of a PN registration request message transmitted by VPoint20V_11 to the local map DB 124_1.

[0526] (Table 31) PN Registration Request Message

[0527] Type = PN Registration Request PNID=Id_PMN#21 Address = Address_PMN#21 VNID=Id_VMN#21 PSID=Id_PSink#11

[0528] The PN registration request message may include, for example, an identifier of the PMNode 30PM_21 and information related to the network address of the PMNode 30PM_21. Note that the PN registration request message shown here is an example. The VPoint 20V_11 may send a PN registration request message including information other than that shown in Table 31 to the local map DB 124_1.

[0529] When receiving the PN registration request message, the local map DB 124_1 writes the information related to PMNode 30PM_21 into the database. Subsequently, the local map DB 124_1 sends a PN registration response message to VPoint 20V_11.

[0530] Table 32 is a table illustrating a PN registration response message. Table 32 illustrates an example of a PN registration response message transmitted by the local map DB 124_1 to the VPoint 20V_11.

[0531] (Table 32) PN Registration Response Message

[0532] Type = PN Registration Response PNID=Id_PMN#21 Status = OK

[0533] The PN registration response message may include, for example, an identifier of the PMNode 30PM_21 and information related to the registration result (status). Table 32 illustrates a PN registration response message in the case where the registration is successful. Note that the PN registration response message shown here is an example. The map DB 124_1 may send a PN registration response message including information other than the information shown in Table 32 to the VPoint 20V_11.

[0534] Subsequently, VPoint 20V_11 sends a PN registration request message to VMNode 30VM_21 (step S707). The PN registration request message may be the same message as shown in Table 31. When receiving the PN registration request message, VMNode 30VM_21 recognizes that PMNode 30PM_21 has been added as a management target of VMNode 30VM_21.

[0535] PN registration request / response is exchanged between VMNode 30VM_21 and local map DB 124_2 (step S708). VMNode 30VM_21 sends a PN registration request message to local map DB 124_2. The PN registration request message sent by VMNode 30VM_21 may be the same as the PN registration request message shown in Table 31.

[0536] When receiving the PN registration request message, the local map DB 124_2 writes the information related to VMNode30VM_21 into the database. The local map DB 124_2 sends a PN registration response message to VMNode30VM_21. The PN registration response message sent by the local map DB 124_2 may be the same as the PN registration request message shown in Table 32.

[0537] When receiving the PN registration response message, VMNode 30VM_21 sends a PN registration response message to VPoint 20V_11 (step S709).

[0538] When receiving the PN registration response message, VPoint 20V_11 sends a connection response message to PSink 20P_11 (step S710).

[0539] Table 33 is a table illustrating a connection response message. Table 33 illustrates an example of a connection response message sent by the VPoint 20V_11 to the PSink 20P_11.

[0540] (Table 33) Connection response message

[0541] Type = Connection Response Status = OK PNID=Id_PMN#21 Session Key = SKey_PMN#21

[0542] The connection response message may include, for example, an identifier of the PMNode 30PM_21 and information related to the connection result (status). Table 33 illustrates a connection response message in the case where the connection is successful. Note that the connection response message shown here is an example. VPoint20V_11 may send a connection response message including information other than the information shown in Table 33 to PSink 20P_11.

[0543] When receiving the connection response message, the PSink 20P_11 sends the connection response message to the PMNode 30PM_21 (step S711). The PMNode 30PM_21 receives the connection response message. Therefore, the PMNode 30PM_21 and the VPoint 20V_11 share the SKey PN#12 as the session key (step S712).

[0544] By executing Fig.16 According to the process shown in , VPoint 20V_11 and VMNode 30VM_21 add entries shown in Table 34 to the PNode management tables respectively included in VPoint 20V_11 and VMNode 30VM_21. Table 34 is a table illustrating PNode management table entries for PMNode 30PM_21.

[0545] (Table 34) PNode Management Table Entry for PMNode 30PM_21

[0546] PNID=Id_PMN#21 Address = Address_PMN#21 VNID=Id_VMN#21 PSID=Id_PSink#11 Time = Time_PMN#21 Session Key = SKey_PMN#21

[0547] The PNode management table entry may include, for example, an identifier of the PMNode 30PM_21 and information related to the network address. Note that the PNode management table entry shown here is an example. VPoint 20V_11 and VMNode 30VM_21 may manage the PNode management table entry as a PNode management table entry that includes information other than the information shown in Table 34 as the PNode management table entry. VPoint 20V_11 and VMNode 30VM_21 may manage different kinds of information as PNode management table entries, respectively.

[0548] By executing Fig.16 In the process shown in , VPoint 20V_11 and VMNode30VM_21 recognize that PMNode30PM_21 is currently connected to PSink 20P_11.

[0549] When sending sensor data to VPoint 30P_11 via PSink 20P_11, PMNode 30PM_21 sends a data notification message including SKey PN# 21. Thus, VPoint 30P_11 can confirm that PMNode 30PM_21 has been authenticated without asking the local AAA 135_2.

[0550] The local map DB 124_2 updates the instance information of the PMNode 30PM_21 shown in Table 7 to be as shown in Table 35. Table 35 is a table illustrating the entry of the PMNode 30PM_21 in the local map DB 124_2 after the PMNode 30PM_21 is connected.

[0551] (Table 35) Entries of PMNode 30PM_21 in the local map DB 124_2 after PMNode 30PM_21 is connected

[0552] VNID=Id_PMN#21 isRegardedAs=Id_MEC#21 isVirtualizedWith=Id_VMN#21 isVirtualizedWith=Id_VP#11 respondsWithDevApi=Id_PS#11 PNType = PNType_PMN#21 Address = Address_PMN#21 Time = Time_PMN#21 Lat Lon=LatLon_PMN#21 Capability = Caps_PMN#21 Credential = Cred_PMN#21 Description = Desc_PMN#21

[0553] For example, the local map DB 124_2 adds information related to the PSink 20P_11 to which the PMNode 30PM_21 is connected (e.g., respondsViaDevApi=Id_PS#11) to the instance information of the PMNode 30PM_21. For example, the local map DB 124_2 adds information related to the VPoint 20V_11 corresponding to the same PSink 20P_11 (e.g., isVirtualizedWith=Id_VP#11) to the instance information of the PMNode 30PM_21. The local map DB 124_2 updates a blank field (e.g., a Time field or a Lat Lon field).

[0554] The local map DB 124_1 updates the instance information of the PSink 20P_11 shown in Table 24 to be as shown in Table 36. Table 36 is a table illustrating the entry of the PSink 20P_11 in the local map DB 124_1 after the PMNode 30PM_21 is connected.

[0555] (Table 36) Entries of PSink 20P_11 in local map DB 124_1 after PMNode 30PM_21 is connected

[0556] PSID=Id_PS#11 isVirtualizedWtih=Id_VP#11 isInstalledIn=Id_Area#1 requestsViaDevApi=Id_PN#11 requestsViaDevApi=Id_PMN#11 requestsViaDevApi=Id_PMN#21 Address = Address_PS#11 Lat Lon=LatLon_PS#11 Description = Desc_PS#11

[0557] For example, the local map DB 124_1 adds information related to PMNode 30PM_21 connected to PSink 20P_11 to the instance information of PSink 20P_11.

[0558] The local map DB 124_1 updates the instance information of the VPoint 20V_11 shown in Table 25 to be as shown in Table 37. Table 37 is a table illustrating the entry of the VPoint 20V_11 in the local map DB 124_1 after the PMNode 30PM_21 is connected.

[0559] (Table 37) Entry of VPoint 20V_11 in local map DB 124_1 after PMNode 30PM_21 is connected

[0560]

[0561]

[0562] For example, the local map DB 124_1 adds information related to the PMNode 30PM_21 connected to the PSink 20P_11 corresponding to the VPoint 20V_11 to the instance information of the VPoint 20V_11.

[0563] <5.9. Mobile node disconnection process (except home MEC server)>

[0564] Fig.17 1 is a sequence diagram illustrating an example of a mobile node disconnection process according to an embodiment of the present disclosure. Here, a process in which a PMNode 30PM_21 as a mobile node is disconnected from a PSink 20P_11 under a server other than a home MEC server is described.

[0565] Since PMNode 30PM_21 has moved and left the wireless communication range of PSink 20P_11, the wireless link between PMNode 30PM_21 and PSink 20P_11 is disconnected (step S801).

[0566] PSink 20P_11 detects that the wireless link with PMNode 30PM_21 is disconnected, and sends a PN disconnection report message to VPoint 20V_11 (step S802). Table 38 is a table illustrating a PN disconnection report message. Table 38 illustrates an example of a PN disconnection report message sent by PSink 20P_11 to VPoint 20V_11 according to an embodiment of the present disclosure.

[0567] (Table 38) PN disconnection report message

[0568] Type = PN disconnect report PNID=Id_PMN#21

[0569] The PN disconnection report message may include, for example, an identifier of the PMNode 30PM_21. Note that the PN disconnection report message shown here is an example. The PSink 20P_11 may send a PN disconnection report message including information other than the information shown in Table 38 to the VPoint 20V_11.

[0570] When receiving the PN disconnection report message, the VPoint 20V_11 recognizes that the PMNode 30PM_21 has left its subordinate. Subsequently, the VNode 30V_11 exchanges a PN deletion request / response with the local map DB 124_1 (step S803).

[0571] Specifically, the VPoint 20V_11 sends a PN deletion request message to the local map DB 124_1. Table 39 is a table illustrating a PN deletion request message. Table 39 illustrates an example of a PN deletion request message sent by the VPoint 20V_11 to the local map DB 124_1 according to an embodiment of the present disclosure.

[0572] (Table 39) PN Delete Request Message

[0573] Type = PN delete request PNID=Id_PMN#21 VNID=Id_VMN#21

[0574] The PN deletion request message may include, for example, an identifier of the PMNode 30PM_21 and an identifier of the VMNode 30VM_21 corresponding to the PMNode 30PM_21. Note that the PN deletion request message shown here is an example. The VPoint 20V_11 may send a PN deletion request message including information other than that shown in Table 39 to the local map DB 124_1.

[0575] When receiving the PN deletion request message, the local map DB 124_1 deletes the information related to the PMNode 30PM_21 from the database. Subsequently, the local map DB 124_1 sends a PN deletion response message to the VPoint 20V_11.

[0576] Table 40 is a table illustrating a PN delete response message. Table 40 illustrates an example of a PN delete response message transmitted by the local map DB 124_1 to the VPoint 20V_11.

[0577] (Table 40) PN Delete Response Message

[0578] Type = PN Delete Response PNID=Id_PMN#21 Status = OK

[0579] The PN deletion response message may include, for example, an identifier of the PMNode 30PM_21 and information related to the deletion result (status). Table 40 illustrates a PN deletion response message in the case where the deletion is successful. Note that the PN deletion response message shown here is an example. The map DB 124_1 may send a PN deletion response message including information other than the information shown in Table 40 to the VPoint 20V_11.

[0580] Subsequently, VPoint 20V_11 sends a PN deletion request message to VMNode 30VM_21 (step S804). The PN deletion request message may be the same message as shown in Table 39. When receiving the PN deletion request message, VMNode 30VM_21 recognizes that PMNode 30PM_21 has left the communication range of PSink 20P_11.

[0581] Subsequently, PN deletion request / response is exchanged between VMNode 30VM_21 and local map DB 124_2 (step S805). VMNode 30VM_21 sends a PN deletion request message to local map DB 124_2. The PN deletion request message sent by VMNode 30VM_21 may be the same as the PN deletion request message shown in Table 39.

[0582] When receiving the PN deletion request message, the local map DB 124_2 deletes the information related to VMNode 30VM_21 from the database. The local map DB 124_2 sends a PN deletion response message to VMNode 30VM_21. The PN deletion response message sent by the local map DB 124_2 may be the same as the PN deletion request message shown in Table 40.

[0583] When receiving the PN deletion response message, VMNode 30VM_21 sends a PN deletion response message to VPoint 20V_11 (step S806).

[0584] When receiving the PN deletion response message, VPoint 20V_11 deletes SKey PMN#21 as the session key shared with PMNode 30PM_21. Similarly, PMNode 30PM_21 also deletes SKey PMN#21 as the session key shared with VPoint 20V_11. Thus, the session key is deleted from VPoint 20V_11 and PMNode 30PM_21 (step S807).

[0585] When executing Fig.17 During the process shown in , VPoint 20V_11 and VMNode 30VM_21 delete the entries of the PNode management table shown in Table 34.

[0586] The local map DB 124_1 updates the instance information of the PSink 20P_11 shown in Table 36 as shown in Table 24. The local map DB 124_1 updates the instance information of the VPoint 20V_11 shown in Table 37 as shown in Table 25. The local map DB 124_2 updates the instance information of the PMNode 30PM_21 shown in Table 35 as shown in Table 7.

[0587] Therefore, the VPoint 20V_11 and the local map DB 124_1 do not retain the management information of the PMNode 30PM_21. Therefore, the PMNode 30PM_21 is removed from the control of the M2M system until the PMNode 30PM_21 is connected to the PSink 20P next time.

[0588] <5.10. Mobile Node Disconnection Process (Home MEC Server)>

[0589] Fig.181 is a sequence diagram illustrating another example of a mobile node disconnection process according to an embodiment of the present disclosure. Here, a process in which a PMNode 30PM_11 as a mobile node is disconnected from a PSink 20P_11 under a home MEC server is described.

[0590] Since PMNode 30PM_11 has moved and left the wireless communication range of PSink 20P_11, the wireless link between PMNode 30PM_21 and PSink 20P_11 is disconnected (step S901).

[0591] PSink 20P_11 detects that the wireless link with PMNode 30PM_11 is disconnected, and sends a PN disconnection report message to VPoint 20V_11 (step S902). Table 41 is a table illustrating a PN disconnection report message. Table 41 illustrates an example of a PN disconnection report message sent by PSink 20P_11 to VPoint 20V_11 according to an embodiment of the present disclosure.

[0592] (Table 41) PN disconnection report message

[0593] Type = PN disconnect report PNID=Id_PMN#11

[0594] The PN disconnection report message may include, for example, an identifier of the PMNode 30PM_11. Note that the PN disconnection report message shown here is an example. The PSink 20P_11 may send a PN disconnection report message including information other than the information shown in Table 41 to the VPoint 20V_11.

[0595] The VPoint 20V_11 sends a PN deletion request message to the VNode 30V_11 (step S903). Table 42 is a table illustrating a PN deletion request message. Table 42 illustrates an example of a PN deletion request message sent by the VPoint 20V_11 to the VNode 30V_11 according to an embodiment of the present disclosure.

[0596] (Table 42) PN Delete Request Message

[0597] Type = PN delete request PNID=Id_PMN#11 VNID=Id_VMN#11

[0598] The PN deletion request message may include, for example, an identifier of the PMNode 30PM_11 and an identifier of the VNode 30V_11 corresponding to the PMNode 30PM_11. Note that the PN deletion request message shown here is an example. The VPoint 20V_11 may send a PN deletion request message including information other than that shown in Table 42 to the VNode 30V_11.

[0599] When receiving the PN deletion request message, the VNode 30V_11 recognizes that the PMNode 30PM_11 has left its subordinates. Subsequently, the VNode 30V_11 exchanges PN deletion request / response with the local map DB 124_1 (step S904).

[0600] Specifically, the VNode 30V_11 sends a PN deletion request message to the local map DB 124_1. The PN deletion request message may be the same message as that shown in Table 42.

[0601] When receiving the PN deletion request message, the local map DB 124_1 deletes the information related to the PMNode 30PM_11 from the database. Subsequently, the local map DB 124_1 sends a PN deletion response message to the VNode 30V_11.

[0602] Table 43 is a table illustrating a PN delete response message. Table 43 illustrates an example of a PN delete response message sent by the local map DB 124_1 to the VNode 30V_11.

[0603] (Table 43) PN Delete Response Message

[0604] Type = PN Delete Response PNID=Id_PMN#11 Status = OK

[0605] The PN deletion response message may include, for example, an identifier of the PMNode 30PM_11 and information related to the deletion result (status). Table 43 illustrates a PN deletion response message in the case where the deletion is successful. Note that the PN deletion response message shown here is an example. The map DB 124_1 may send a PN deletion response message including information other than the information shown in Table 43 to the VNode 30V_11.

[0606] When receiving the PN deletion response message, the VNode 30V_11 sends a PN deletion response message to the VPoint 20V_11 (step S905).

[0607] When receiving the PN deletion response message, VPoint 20V_11 deletes SKey PMN#21 as the session key shared with PMNode 30PM_11. Similarly, PMNode 30PM_11 also deletes SKey PMN#21 as the session key shared with VPoint 20V_11. Thus, the session key is deleted from VPoint 20V_11 and PMNode 30PM_11 (step S906).

[0608] When executing Fig.18During the process shown in , VPoint 20V_11 and VNode 30V_11 delete the entries of the PNode management table shown in Table 22.

[0609] The local map DB 124_1 updates the instance information of the PMNode 30PM_11 shown in Table 23 as shown in Table 6. The local map DB 124_1 updates the instance information of the PSink 20P_11 shown in Table 24 as shown in Table 20. The local map DB 124_1 updates the instance information of the VPoint 20V_11 shown in Table 25 as shown in Table 21.

[0610] Therefore, PMNode 30PM_11 is removed from the control of the M2M system until PMNode 30PM_11 is connected to PSink 20P next time.

[0611] <5.11. Sensor data registration process from fixed nodes>

[0612] Fig.19 1 is a sequence diagram illustrating an example of a data registration process for registering sensor data from a fixed node according to an embodiment of the present disclosure. Here, a process in which a PNode 30P_11 as a fixed node registers sensor data in an MEC server 100_21 is described.

[0613] PNode 30P_11 establishes a wireless link with PSink 20P_11 as a physical sink (step S1001). PNode 30P_11 sends a data notification message to PSink 20P_11 (step S1002).

[0614] Table 44 is a table illustrating a data notification message. Table 44 illustrates an example of a data notification message transmitted by the PNode 30P_11 to the PSink 20P_11 according to an embodiment of the present disclosure.

[0615] (Table 44) Data notification message

[0616] Type = Data Notification PNID=Id_PN#11 Session Key = SKey_PN#11 Time = Time_PN#11_D Data = Data_PN#11

[0617] The data notification message may include, for example, an identifier of the PNode 30P_11 and information related to the session key (Session Key field). Note that the data notification message shown here is an example. The PNode 30P_11 may send a data notification message including information other than the information shown in Table 44 to the PSink 20P_11.

[0618] The PSink 20P_11 sends a data notification message to the VPoint 20V_11 which is the virtual module corresponding thereto (step S1003). The data notification message may be the same message as that shown in Table 44.

[0619] When receiving the data notification message, the VPoint 20V_11 recognizes that the PNode 30P_11 has passed the authentication based on the value of the Session Key field, and sends a data write message to the VNode 30V_11 (step S1004).

[0620] Table 45 is a table illustrating a data write message. Table 45 illustrates an example of a data write message sent by VPoint 20V_11 to VNode 30V_11 according to an embodiment of the present disclosure.

[0621] (Table 45) Data write message

[0622] Type = Data write PNID=Id_PN#11 VNID=Id_VN#11 PSID=Id_PSink#11 VPID=Id_VP#11 Time = Time_PN#11_D Data = Data_PN#11

[0623] The data write message may include, for example, an identifier of the PNode 30P_11, an identifier of the VNode 30V_11, and information related to the sensed data (Data field). Note that the data write message shown here is an example. VPoint 20V_11 may send a data write message including information other than that shown in Table 45 to VNode 30V_11.

[0624] When receiving the data notification message, the VNode 30V_11 sends a data write message to the local sense DB 123_1 (step S1005). When receiving the data write request message, the local sense DB 123_1 writes the content of the data field into the database.

[0625] When executing Fig.19 , the local sensing DB 123_1 adds the entries shown in Table 46 to the database. Table 46 is a table illustrating sensor data entries of the PNode 30P_11.

[0626] (Table 46) Sensor data entries of PNode 30P_11

[0627]

[0628]

[0629] The sensor data entry may include, for example, an identifier of the PNode 30P_11 and information related to the sensor data. Note that the sensor data entry shown here is an example. The local sensing DB 123_1 may manage the sensor data entry as a sensor data entry including information other than the information shown in Table 46 as the sensor data entry.

[0630] In addition, VNode 30V_11 can also retain sensor data entries as cache.

[0631] Note that when the PMNode 30PM_11 as a mobile node registers data via the PSink 20P_11 under the home MEC server, the same Fig.19 The same process as shown in .

[0632] <5.12. Sensor data registration process from mobile nodes (except home MEC server)>

[0633] Fig. 20 2 is a sequence diagram illustrating an example of a data registration process of registering sensor data from a mobile node according to an embodiment of the present disclosure. Here, PMNode 30PM_21 as a mobile node performs sensor data registration via PSink 20P_11 temporarily connected thereto.

[0634] The home MEC server of PMNode 30PM_21 is MEC server 100_22. Fig. 20 In the example shown in , the data registration process is illustrated when the mobile node connects to a server other than the home MEC server.

[0635] PMNode 30PM_21 establishes a wireless link with PSink 20P_11 as a physical sink (step S1101). PMNode 30PM_21 sends a data notification message to PSink 20P_11 (step S1102).

[0636] Table 47 is a table illustrating a data notification message. Table 47 illustrates an example of a data notification message sent by PMNode 30PM_21 to PSink 20P_11 according to an embodiment of the present disclosure.

[0637] (Table 47) Data notification message

[0638]

[0639]

[0640] The data notification message may include, for example, an identifier of the PMNode 30PM_21 and information related to the session key (Session Key field). Note that the data notification message shown here is an example. The PMNode 30PM_21 may send a data notification message including information other than that shown in Table 47 to the PSink 20P_11.

[0641] The PSink 20P_11 sends a data notification message to the VPoint 20V_11 which is the virtual module corresponding thereto (step S1103). The data notification message may be the same message as that shown in Table 47.

[0642] When receiving the data notification message, the VPoint 20V_11 recognizes that the PMNode 30PM_21 has been authenticated according to the value of the Session Key field, and sends a data write message to the local sensing DB 123_1 (step S1104).

[0643] Table 48 is a table illustrating a data write message. Table 48 illustrates an example of a data write message transmitted by VPoint20V_11 to the local sense DB 123_1 according to an embodiment of the present disclosure.

[0644] (Table 48) Data write message

[0645] Type = Data write PNID=Id_PMN#21 VNID=Id_VMN#21 Time = Time_PMN#21_D Data = Data_PMN#21

[0646] The data write message may include, for example, an identifier of the PMNode 30PM_21, an identifier of the VMNode 30VM_11, and information related to the sensing data (Data field). Note that the data write message shown here is an example. The VPoint 20V_11 may send a data write message including information other than that shown in Table 48 to the local sensing DB 123_1.

[0647] When receiving the data write request message, the local sensing DB 123_1 writes the content of the data field into the database.

[0648] Furthermore, when PMNode 30PM_21 is connected to PSink 20P_11, VPoint 20V_11 recognizes that the virtual module corresponding to PMNode 30PM_21 is VMNode 30VM_21. Therefore, VPoint 20V_11 sends a data notification message to VMNode 30VM_21 (step S1105). The data notification message may be the same message as shown in Table 47.

[0649] When receiving the data notification message, the VMNode 30VM_21 sends a data write message to the local sensing DB 123_2 (step S1106). The data write message may be the same message as shown in Table 48.

[0650] When receiving the data write request message, the local sensing DB 123_2 writes the content of the data field into the database.

[0651] When executing Fig. 20 49, the local sensing DBs 123_1 and 123_2 add the entries shown in Table 49 to the database. Table 49 is a table illustrating sensor data entries of the PMNode 30PM_21.

[0652] (Table 49) Sensor data entries for PMNode 30PM_21

[0653] PNID=Id_PMN#21 VNID=Id_VMN#21 VSID = Id_PSink#11 Capability = Cap_PMN#21 Time = Time_PMN#21_D Data = Data_PMN#21

[0654] The sensor data entry may include, for example, an identifier of PMNode 30PM_21 and information related to the sensor data. Note that the sensor data entry shown here is an example. The local sensing DBs 123_1 and 123_2 may be managed as sensor data entries including information other than that shown in Table 49 as sensor data entries.

[0655] VMNode 30VM_21 may also retain sensor data entries as cache.

[0656] <5.13. Global Map DB Update Process>

[0657] For example, the local graph DB 124 of the MEC server 100_20 periodically sends update data to the global graph DB 122. Fig.21 is a sequence diagram illustrating an example of an update process for the global graph DB 122 according to an embodiment of the present disclosure. Fig.21 The diagram illustrates a process in which the local map DB 124_1 sends update data to the global map DB 122 .

[0658] The local map DB 124_1 detects update information from the last map information update execution, and sends a map update request message to the global map DB 122 (step S1201).

[0659] Table 50 is a table illustrating a graph update request message. Table 50 illustrates an example of a graph update request message transmitted by the local graph DB 124_1 to the global graph DB 122 according to an embodiment of the present disclosure.

[0660] (Table 50) Map Update Request Message

[0661] Type = Graph Update Request Time = Time_GraphUpdate Time(Data) = Data_GraphUpdate

[0662] The map update request message may include, for example, information related to the date and time of sending the update data and information related to the update data of the map (Data field). Note that the map update request message shown here is an example. The local map DB 124_1 may send a map update request message including information other than the information shown in Table 50 to the global map DB 122.

[0663] When receiving the graph update request message, the global graph DB 122 updates the database using the content of the data field, and sends a graph update response message to the local graph DB 124_1 (step S1202).

[0664] Table 51 is a table illustrating a graph update response message. Table 51 illustrates an example of a graph update response message transmitted by the global graph DB 122 to the local graph DB 124_1.

[0665] (Table 51) Image update response message

[0666] Type = Graph Update Response Status = OK

[0667] The graph update response message may include, for example, information related to the graph update result (status). Table 51 illustrates a graph update response message in the case where the graph update is successful. Note that the graph update response message shown here is an example. The global graph DB 122 may send a graph update response message including information other than the information shown in Table 51 to the local graph DB 124_1.

[0668] Thereafter, the local map DB 124_1 and the global map DB 122 repeat Fig.21 The local map DB 124_1 may send a map update request message at a predetermined period, or may send a map update request message at a timing when a node is registered / deleted. Alternatively, the local map DB 124_1 may send a map update request message in response to a request from the global map DB 122.

[0669] As a result of this process, according to the present embodiment, the global map DB 122 becomes able to grasp the configuration information of the entire M2M system.

[0670] <5.14. Global sensor DB update process>

[0671] For example, the local sensing DB 123 of the MEC server 100_20 periodically sends update data (sensor data) to the global sensing DB 121. Fig. 22 is a sequence diagram illustrating an example of an update procedure for the global sensing DB 121 according to an embodiment of the present disclosure. Fig. 22 A process in which the local sensing DB 123_1 sends update data to the global sensing DB 121 is illustrated.

[0672] The local sensing DB 123_1 detects update information from the last sensor data update execution and sends a data update request message to the global sensing DB 121 (step S1301 ).

[0673] Table 52 is a table illustrating a data update request message. Table 52 illustrates an example of a data update request message transmitted by the local sensing DB 123_1 to the global sensing DB 121 according to an embodiment of the present disclosure.

[0674] (Table 52) Data Update Request Message

[0675] Type = Data Update Request Time = Time_DataUpdate Data = Data_Update

[0676] The data update request message may include, for example, information related to the date and time of transmission of the update data and information related to the update data of the sensor data (Data field). Note that the data update request message shown here is an example. The local sensing DB 123_1 may send a data update request message including information other than the information shown in Table 52 to the global sensing DB 121.

[0677] When receiving the data update request message, the global sensing DB 121 updates the database using the content of the data field, and sends a data update response message to the local sensing DB 123_1 (step S1302 ).

[0678] Table 53 is a table illustrating a data update response message. Table 53 illustrates an example of a data update response message transmitted by the global sensing DB 121 to the local sensing DB 123_1.

[0679] (Table 53) Data Update Response Message

[0680] Type = Data Update Response Status = OK

[0681] The data update response message may include, for example, information related to the data update result (status). Table 53 illustrates a data update response message in the case where the data update is successful. Note that the data update response message shown here is an example. The global sensing DB 121 may send a data update response message including information other than the information shown in Table 53 to the local sensing DB 123_1.

[0682] Thereafter, the local sensing DB 123_1 and the global sensing DB 121 repeat Fig. 22 The local sensing DB 123_1 may send a data update request message at a predetermined period, or may send a data update request message at a timing when a data write message is received. Alternatively, the local sensing DB 123_1 may send a data update request message in response to a request from the global sensing DB 121.

[0683] As a result of this process, according to the present embodiment, the global sensing DB 121 becomes able to store sensor data measured in the entire M2M system.

[0684] <5.15. M2M application start process (in the case of cloud server)>

[0685] Fig.23 is a sequence diagram illustrating an example of a start procedure for the M2M application 10 according to an embodiment of the present disclosure. Fig.23 The process in the case where the M2M application 10 is started on the cloud server 100_1 is illustrated.

[0686] The local manager 136 (in Fig.23 In the example shown in , the local manager 136_1) operating on the MEC server 100_21 periodically sends a load report message to the global MANO 134 operating on the cloud server 100_1 (step S1401).

[0687] Note that, although not shown, since PMNode 30PM also serves as MEC server 100_211, the local manager 136_21 in PMNode30PM also periodically sends load report messages to the global MANO 134.

[0688] Table 54 is a table illustrating a load report message. Table 54 illustrates an example of a load report message sent by the local manager 136_1 to the global MANO 134 according to an embodiment of the present disclosure.

[0689] (Table 54) Load report message

[0690] Type = Load Report MECID=Id_MEC#1 Time = Time_LoadUpdate CompLoad=Load_Comp NetLoad=Load_Net

[0691] The load report message may include, for example, identification information of the operating MEC server 100_21 and load information of computing resources. Note that the load report message shown here is an example. The local manager 136_1 may send a load report message including information other than that shown in Table 54 to the global MANO 134.

[0692] The global MANO 134 may grasp the load status of the entire M2M system by periodically receiving load report messages from the local manager 136 .

[0693] The user U1 sends an application start request message to the global manager 132 (step S1402). Table 55 is a table illustrating an application start request message. Table 55 illustrates an example of an application start request message sent by the user U1 to the global manager 132 according to an embodiment of the present disclosure.

[0694] (Table 55) Application start request message

[0695] Type = Application Start Request UserID=Id_User#4 Credential = Cred_User#4 AppName=App_Name Param=App_Param

[0696] The application start request message may include, for example, identification information of user U1, credit information of user U1, and information related to the application (AppName field). Note that the application start request message shown here is an example. User U1 may send an application start request message including information other than that shown in Table 55 to the global manager 132.

[0697] When receiving the application start request message, the global manager 132 exchanges authentication and authorization requests / responses with the global AAA 131 (step S1403).

[0698] Specifically, the global manager 132 sends an authentication authorization request message to the global AAA 131. Table 56 is a table illustrating an authentication authorization request message. Table 56 illustrates an example of an authentication authorization request message sent by the global manager 132 to the global AAA 131 according to an embodiment of the present disclosure.

[0699] (Table 56) Authentication and Authorization Request Message

[0700] Type = Authentication and Authorization Request UserID=Id_User#4 Credential = Cred_User#4 AppName=App_Name

[0701] The authentication and authorization request message may include, for example, identification information of user U1 (UserID field), credit information of user U1, and information related to the application (AppName field). Note that the authentication and authorization request message shown here is an example. The global manager 132 may send an authentication and authorization request message including information other than that shown in Table 56 to the global AAA 131.

[0702] When receiving the authentication and authorization request message, the global AAA 131 checks the authenticity of the user U1 indicated by the UserID field and the execution authority of the application indicated by AppName. When the check succeeds, the global AAA 131 sends an authentication and authorization response message to the global manager 132.

[0703] Table 57 is a table illustrating an authentication authorization response message. Table 57 illustrates an example of an authentication authorization response message sent by the global AAA 131 to the global manager 132.

[0704] (Table 57) Authentication and Authorization Response Message

[0705] Type = Authentication and Authorization Response UserID=Id_User#4 Status = OK

[0706] The authentication and authorization response message may include, for example, identification information of user U1 (UserID field) and information related to the authentication and authorization result (Status). Table 57 illustrates a data update response message in the case where the authentication and authorization is successful. Note that the authentication and authorization response message shown here is an example. The global AAA 131 may send an authentication and authorization response message including information other than the information shown in Table 57 to the global manager 132.

[0707] Subsequently, the global manager 132 exchanges application configuration information request / response with the global repository 133 (step S1404 ). Specifically, the global manager 132 sends an application configuration information request message to the global repository 133 .

[0708] Table 58 is a table illustrating an application configuration information request message. Table 58 illustrates an example of an application configuration information request message sent by the global manager 132 to the global repository 133 according to an embodiment of the present disclosure.

[0709] (Table 58) Application configuration information request message

[0710] Type = Application configuration information request AppName=App_Name

[0711] The application configuration information request message may include, for example, information related to the application (AppName field). Note that the application configuration information request message shown here is an example. The global manager 132 may send an application configuration information request message including information other than that shown in Table 58 to the global repository 133.

[0712] When receiving the application configuration information request message, global repository 133 reads configuration information related to the application indicated by the AppName field from the database (program size, requested computing resources, network bandwidth, etc.) and sends an application configuration information response message to global manager 132 .

[0713] Table 59 is a table illustrating an application configuration information response message. Table 59 illustrates an example of an application configuration information response message sent by the global repository 133 to the global manager 132.

[0714] (Table 59) Application configuration information response message

[0715] Type = Application Configuration Information Response AppName=App_Name Status = OK Confinfo=App_Info

[0716] The application configuration information response message may include, for example, information related to the application and information related to the request result of the application configuration information (status). Table 59 illustrates an application configuration information response message in the case where the request for the application configuration information is successful. Note that the application configuration information response message shown here is an example. The global repository 133 may send an application configuration information response message including information other than the information shown in Table 59 to the global manager 132.

[0717] Subsequently, the global manager 132 exchanges MANO request / response with the global MANO 134 (step S1405 ). Specifically, the global manager 132 sends a MANO request message to the global MANO 134 .

[0718] Table 60 is a table illustrating a MANO request message. Table 60 illustrates an example of a MANO request message sent by the global manager 132 to the global MANO 134 according to an embodiment of the present disclosure.

[0719] (Table 60) MANO request message

[0720] Type = MANO request AppName=App_Name Confinfo=App_Info

[0721] The MANO request message may include, for example, information related to the application. Note that the MANO request message shown here is an example. The global manager 132 may send a MANO request message including information other than the information shown in Table 60 to the global MANO 134.

[0722] Based on the load report from MEC server 100_20, the global MANO 134 determines whether the application indicated by the AppName field is deployed in MEC server 100_20 or cloud server 100_1. In this example, it is assumed that MEC server 100_21 is selected.

[0723] Subsequently, the global MANO 134 transmits a MANO response message to the global manager 132. Table 61 is a table illustrating a MANO response message. Table 61 illustrates an example of a MANO response message transmitted by the global MANO 134 to the global manager 132.

[0724] (Table 61) MANO response message

[0725] Type = MANO response AppName=App_Name MECID=Id_MEC#1

[0726] The MANO response message may include, for example, information related to the application and information related to the device in which the application is deployed (MECID). Note that the MANO response message shown here is an example. The global MANO 134 may send a MANO response message including information other than that shown in Table 61 to the global manager 132.

[0727] Subsequently, the global manager 132 sends an application activation request message to the local manager 136_1 operating on the MEC server 100_21 (step S1406).

[0728] Table 62 is a table illustrating an application activation request message. Table 62 illustrates an example of an application activation request message sent by the global manager 132 to the local manager 136_1 according to an embodiment of the present disclosure.

[0729] (Table 62) Application Activation Request Message

[0730] Type = Application Activation Request UserID=Id_User#4 AppName=App_Name Param=App_Param

[0731] The application activation request message may include, for example, identification information of the user U1 and information related to the application. Note that the application activation request message shown here is an example. The global manager 132 may send an application activation request message including information other than the information shown in Table 62 to the local manager 136_1.

[0732] The local manager 136_1 sends an application acquisition request message to the local repository 137_1 (step S1407). Table 63 is a table illustrating an application acquisition request message. Table 63 illustrates an example of an application acquisition request message sent by the local manager 136_1 to the local repository 137_1 according to an embodiment of the present disclosure.

[0733] (Table 63) Application acquisition request message

[0734] Type = Application acquisition request AppName=App_Name

[0735] The application acquisition request message may include, for example, information related to the application (AppName field). Note that the application acquisition request message shown here is an example. The local manager 136_1 may send an application acquisition request message including information other than the information shown in Table 63 to the local repository 137_1.

[0736] When receiving the application acquisition request message, the local repository 137_1 searches its database for the application indicated by the AppName field. Fig.23 As shown in , the local repository 137_1 exchanges application acquisition requests / responses with the global repository 133 operating on the cloud server 100_1 (step S1408).

[0737] Specifically, the local repository 137_1 sends an application acquisition request message to the global repository 133. The application acquisition request message may be the same message as that shown in Table 63.

[0738] When receiving the application acquisition request message, the global repository 133 searches its database for the application indicated by the AppName field, and sends an application acquisition response message to the local repository 137_1.

[0739] Table 64 is a table illustrating an application acquisition response message. Table 64 illustrates an example of an application acquisition response message sent by the global repository 133 to the local repository 137_1.

[0740] (Table 64) Application Get Response Message

[0741] Type = Application Get Response AppName=App_Name Status = OK AppImage=App_Image

[0742] The application acquisition response message may include, for example, information related to the application and information related to the application acquisition result (status). Table 64 illustrates an application acquisition response message in the case where the acquisition of the application is successful. Note that the application acquisition response message shown here is an example. The global repository 133 may send an application acquisition response message including information other than the information shown in Table 64 to the local repository 137_1.

[0743] When receiving the application acquisition response message, the local repository 137_1 sends the application acquisition response message to the local manager 136_1 (step S1409).

[0744] When receiving the application acquisition response message, the local manager 136_1 activates the application (step S1410 ). The local manager 136_1 activates, for example, the M2M application 10 .

[0745] Subsequently, the local manager 136_1 sends an application activation response message to the global manager 132 (step S1411). Table 65 is a table illustrating an application activation response message. Table 65 illustrates an example of an application activation response message sent by the local manager 136_1 to the global manager 132.

[0746] (Table 65) Application Activation Response Message

[0747] Type = Application Activation Response AppName=App_Name Status = OK

[0748] The application activation response message may include, for example, information related to the application and information related to the application activation result (status). Table 65 illustrates an application activation response message in the case where the activation of the application is successful. Note that the application activation response message shown here is an example. The local manager 136_1 may send an application activation response message including information other than the information shown in Table 65 to the global manager 132.

[0749] When receiving the application activation response message, the global manager 132 sends an application start response message to the user U1 (step S1412). Table 66 is a table illustrating an application start response message. Table 66 illustrates an example of an application start response message sent by the global manager 132 to the user U1.

[0750] (Table 66) Application start response message

[0751] Type = Application starts responding AppName=App_Name Status = OK

[0752] The application start response message may include, for example, information related to the application and information related to the application start result (status). Table 66 illustrates an application start response message in the case where the start of the application is successful. Note that the application start response message shown here is an example. The global manager 132 may send an application start response message including information other than the information shown in Table 66 to the user U1.

[0753] By executing Fig.23 According to the process shown in , when the M2M application 10 is started on the cloud server 100_1, the M2M system can place the M2M application 10 on the optimal device (cloud server 100_1 or MEC server 100_20) taking into account the computing load and network load (e.g., communication delay).

[0754] <5.16.M2M Application Start Procedure (In the Case of Mobile Node)>

[0755] Fig.24 is a sequence diagram illustrating another example of a start procedure for the M2M application 10 according to an embodiment of the present disclosure. Fig.24 The process is illustrated in the case where the M2M application 10 is started in the PMNode 30PM_21 by the user U2.

[0756] The user U2 sends an application start request message to the local manager 136_21 (step S1501). Table 67 is a table illustrating an application start request message. Table 67 illustrates an example of an application start request message sent by the user U2 to the local manager 136_21 according to an embodiment of the present disclosure.

[0757] (Table 67) Application start request message

[0758]

[0759]

[0760] The application start request message is the same as the application start request message shown in Table 55, except that the information related to the user U is not the information related to the user U1 but the information related to the user U2.

[0761] When receiving the application start request message, the local manager 136_21 exchanges authentication and authorization requests / responses with the local AAA 135_21 (step S1502).

[0762] Specifically, the local manager 136_21 sends an authentication authorization request message to the local AAA 135_21. Table 68 is a table illustrating an authentication authorization request message. Table 68 illustrates an example of an authentication authorization request message sent by the local manager 136_21 to the local AAA 135_21 according to an embodiment of the present disclosure.

[0763] (Table 68) Authentication and Authorization Request Message

[0764] Type = Authentication and Authorization Request UserID=Id_User#2 Credential = Cred_User#2 AppName=App_Name

[0765] The authentication authorization request message is the same as the authentication authorization request message shown in Table 56, except that the information related to the user U1 is not the information related to the user U1 but the information related to the user U2.

[0766] When receiving the authentication and authorization request message, the local AAA 135_21 checks the authenticity of the user U2 indicated by the UserID field and the execution authority of the application indicated by AppName. When the check is successful, the local AAA 135_21 sends an authentication and authorization response message to the local manager 136_21.

[0767] Table 69 is a table illustrating an authentication authorization response message. Table 69 illustrates an example of an authentication authorization response message sent by the local AAA 135_21 to the local manager 136_21.

[0768] (Table 69) Authentication and Authorization Response Message

[0769]

[0770]

[0771] The authentication-authorization response message is the same as the authentication-authorization response message shown in Table 57, except that the information related to the user U1 is not the information related to the user U1 but the information related to the user U2.

[0772] Subsequently, the local manager 136_21 sends an application configuration information request message to the local repository 137_21 (step S1503). The application configuration information request message may be the same as the message shown in Table 58.

[0773] When receiving the application configuration information request message, the local repository 137_21 searches the database for configuration information related to the application indicated by the AppName field (size of the program, requested computing resources, network bandwidth, etc.). Fig.24 As shown in , the local repository 137_21 exchanges application configuration information requests / responses with the global repository 133 (step S1504).

[0774] Specifically, the local repository 137_21 sends an application configuration information request message to the global repository 133. The application configuration information request message may be the same as the message shown in Table 58.

[0775] When receiving the application configuration information request message, the global repository 133 reads the configuration information related to the application indicated by the AppName field from the database (the size of the program, the requested computing resources, the network bandwidth, etc.). The global repository 133 sends an application configuration information response message to the local repository 137_21. The application configuration information response message can be the same as the message shown in Table 59.

[0776] When receiving the application configuration information response message, the local repository 137_21 sends the application configuration information response message to the local manager 136_21 (step S1505).

[0777] Subsequently, the local manager 136_21 exchanges MANO requests / responses with the global MANO 134 (step S1506). Specifically, the local manager 136_21 sends a MANO request message to the global MANO 134. The MANO request message may be the same as the message shown in Table 60.

[0778] When receiving the MANO request message, the global MANO 134 determines whether the application indicated by the AppName field is arranged in the MEC server 100_20 or the cloud server 100_1 based on the load report from the MEC server 100_20. In this example, it is assumed that the PMNode 30PM_21 is selected.

[0779] Subsequently, the global MANO 134 sends a MANO response message to the local manager 136_21. Table 70 is a table illustrating a MANO response message. Table 70 illustrates an example of a MANO response message sent by the global MANO 134 to the local manager 136_21.

[0780] (Table 70) MANO response message

[0781] Type = MANO response AppName=App_Name MECID=Id_MEC#21

[0782] The MANO response message is the same as the MANO response message shown in Table 61, except that the information related to the device in which the application is deployed (MECID) is the identifier of PMNode30PM_21.

[0783] When receiving the MANO response message, the local manager 136_21 sends an application acquisition request message to the local repository 137_21 (step S1507). The application acquisition request message can be the same as the message shown in Table 63.

[0784] When receiving the application acquisition request message, the local repository 137_21 searches its database for the application indicated by the AppName field. Fig.24 As shown in , the local repository 137_21 exchanges application acquisition requests / responses with the global repository 133 operating on the cloud server 100_1 (step S1508).

[0785] Specifically, the local repository 137_21 sends an application acquisition request message to the global repository 133. The application acquisition request message may be the same message as that shown in Table 63.

[0786] When receiving the application acquisition request message, the global repository 133 searches for the application indicated by the AppName field in its database and sends an application acquisition response message to the local repository 137_21. The application response request message may be the same message as that shown in Table 64.

[0787] When receiving the application acquisition response message, the local repository 137_21 sends an application acquisition response message to the local manager 136_21 (step S1509).

[0788] When receiving the application acquisition response message, the local manager 136_21 activates the application (step S1510). The local manager 136_21 activates, for example, the M2M application 10.

[0789] When the application is activated, the local manager 136_21 sends an application start response message to the user U2 (step S1511). The application start request message can be the same message as the message shown in Table 66.

[0790] By executing Fig.24 According to the process shown in , when the M2M application 10 is started on PMNode 30PM_21, the M2M system can place the M2M application 10 in the optimal device (cloud server 100_1 or MEC server 100_20) considering the computing load and network load (e.g., communication delay).

[0791] <5.17. Location analysis process>

[0792] As described above, in the present embodiment, the process of specifying a geographical area and searching for a VPoint 20V installed in the geographical area is referred to as location resolution.

[0793] Fig.25 is a sequence diagram illustrating an example of a place resolution process according to an embodiment of the present disclosure. Fig.25 The diagram illustrates a process in which an M2M application 10_11, which is an M2M application 10 operating on an MEC server 100_21, performs location resolution.

[0794] The M2M application 10_11 sends a location resolution request message to the M2M API 40_1 operating on the MEC server 100_21 (step S1601).

[0795] Table 71 is a table illustrating a location resolution request message. Table 71 illustrates an example of a location resolution request message sent by the M2M application 10_11 to the M2M API 40_1 according to an embodiment of the present disclosure.

[0796] (Table 71) Location resolution request message

[0797] Type = Location resolution request SW Lat Lon = LatLon_SW NE Lat Lon=LatLon_NE

[0798] The location resolution request message may include, for example, information related to a geographic area (eg, SW LatLon field or NE LatLon field). Note that the location resolution request message shown here is an example. The M2M application 10_11 may send a location resolution request message including information other than the information shown in Table 71 to the M2M API 40_1.

[0799] When receiving the location resolution request message, the M2M API 40_1 sends a map search request message to the local map DB 123_1 (step S1602).

[0800] Table 72 is a table illustrating a graph search request message. Table 72 illustrates an example of a graph search request message transmitted by the M2M API 40_1 to the local graph DB 123_1 according to an embodiment of the present disclosure.

[0801] (Table 72) Graph Search Request Message

[0802] Type = Graph Search Request Query Type = Location Search SW Lat Lon = LatLon_SW NE Lat Lon=LatLon_NE

[0803] The graph search request message may include, for example, information related to the type of data parsing request or information related to the geographical area (e.g., SW LatLon field or NE LatLon field). Note that the graph search request message shown here is an example. The M2M API 40_1 may send a graph search request message including information other than the information shown in Table 72 to the local graph DB 123_1.

[0804] When receiving the map search request message, the local map DB 123_1 determines whether the geographical area indicated by the SW LatLon field and the NE LatLon field is the control range of the local map DB 123_1. When the designated geographical area is the control range of the local map DB 123_1, the local map DB 123_1 searches the database for VPoint20V existing in the designated geographical area and proceeds to step S1604.

[0805] On the other hand, when the designated geographical area is not the control range of the local map DB 123_1, the local map DB 123_1 exchanges a map search request / response with the global map DB 122 operating on the cloud server 100_1 (step S1603).

[0806] Specifically, the local graph DB 123_1 sends a graph search request message to the global graph DB 122. The graph search request message may be the same as the message shown in Table 72.

[0807] When receiving the graph search request message, the global graph DB 122 accesses the database and searches for VPoints 20V existing in the designated geographical area. Subsequently, the global graph DB 122 transmits a graph search response message to the local graph DB 124_1.

[0808] Table 73 is a table illustrating a graph search response message. Table 73 illustrates an example of a graph search response message transmitted by the global graph DB 122 to the local graph DB 124_1.

[0809] (Table 73) Graph Search Response Message

[0810]

[0811]

[0812] The graph search response message may include, for example, information related to the search results. Note that Table 73 illustrates the graph search response message in the case where the graph search is successful.

[0813] When multiple VPoints 20V may exist in the designated geographic area as a result of the graph search, the global graph DB 122 sends a graph search response message including information related to the multiple VPoints 20V to the local graph DB 124_1. Examples of the information related to the multiple VPoints 20V include identifiers of the VPoints 20V and information related to network addresses.

[0814] Note that the graph search response message shown here is an example. The global graph DB 122 may send a graph search response message including information other than the information shown in Table 73 to the local graph DB 124_1.

[0815] When searching for VPoint 20V, the global map DB 122 refers to the Lat Lon field included in the instance information of VPoint 20V shown in Table 37, for example.

[0816] like Fig.25 As shown in , the local map DB 124_1 combines the information related to VPoint 20V searched by itself with the information related to VPoint 20V received from the global map DB 122, and sends a map search response message to the M2M API 40_1 (step S1604). The map search response message can be a message of the same format as the message shown in Table 73.

[0817] For example, the local map DB 124_1 adds the information related to the VPoint 20V searched by itself to the map search response message received from the global map DB 122 to generate a new map search response message. The local map DB 124_1 sends the generated map search response message to the M2M API 40_1.

[0818] When receiving the map search response message, the M2M API 40_1 sends a location resolution response message to the M2M application 10_11 (step S1605).

[0819] Table 74 is a table illustrating a location resolution response message. Table 74 illustrates an example of a location resolution response message sent by the M2M API 40_1 to the M2M application 10_11.

[0820] (Table 74) Location resolution response message

[0821]

[0822]

[0823] The place resolution response message may include, for example, information related to the place resolution result. Note that Table 74 illustrates the place resolution response message in the case where the place resolution is successful.

[0824] When a plurality of VPoints 20V may exist in the designated geographic area as a result of location resolution, the M2M API 40_1 transmits a location resolution response message including information related to the plurality of VPoints 20V to the M2M application 10_11. Examples of the information related to the plurality of VPoints 20V include identifiers of the VPoints 20V.

[0825] Note that the location resolution response message shown here is an example. The M2M API 40_1 may send a location resolution response message including information other than the information shown in Table 74 to the M2M application 10_11.

[0826] In this process, the location resolution request / response is a function of the M2M API 40_1, and the graph search request / response is a function of the Prim API.

[0827] <5.18. Node parsing process>

[0828] When performing node designation type data resolution, first, the M2M application 10 performs location resolution to search for a VPoint 20V, and searches for a VNode 30V having a desired function for the obtained VPoint 20V. In the present embodiment, as described above, this search process is called node resolution.

[0829] The M2M application 10 specifies the VNode 30V obtained by, for example, node resolution, and performs node specification type data resolution.

[0830] Fig.26 is a sequence diagram illustrating an example of a node resolution process according to an embodiment of the present disclosure. Fig.26 The process is illustrated in which the M2M application 10_11, which is the M2M application 10 operating on the MEC server 100_21, performs node resolution.

[0831] The M2M application 10_11 sends a node resolution request message to the M2M API 40_1 operating on the MEC server 100_21 (step S1701).

[0832] Table 75 is a table illustrating a node resolution request message. Table 75 illustrates an example of a node resolution request message sent by the M2M application 10_11 to the M2M API 40_1 according to an embodiment of the present disclosure.

[0833] (Table 75) Node resolution request message

[0834]

[0835] The node resolution request message may include, for example, information related to the VPoint 20V as the search range and information related to the desired function. Note that when there are multiple VPoint 20Vs as the search range, information related to the multiple VPoint 20Vs (e.g., identifiers) may be included in the node resolution request message.

[0836] Note that the node resolution request message shown here is an example. The M2M application 10_11 may send a node resolution request message including information other than the information shown in Table 75 to the M2M API 40_1.

[0837] When receiving the node resolution request message, the M2M API 40_1 sends a graph search request message to the local graph DB 123_1 (step S1702).

[0838] Table 76 is a table illustrating a graph search request message. Table 76 illustrates an example of a graph search request message transmitted by the M2M API 40_1 to the local graph DB 123_1 according to an embodiment of the present disclosure.

[0839] (Table 76) Graph Search Request Message

[0840]

[0841] The graph search request message differs from the graph search request message shown in Table 72 in, for example, the type of data parsing request. The graph search request message may include not information related to the geographic area, but information related to VPoint 20V as a search range, or information related to a desired function.

[0842] Note that the graph search request message shown here is an example. The M2M API 40_1 may send a graph search request message including information other than the information shown in Table 76 to the local graph DB 123_1.

[0843] When receiving the graph search request message, the local map DB 123_1 searches the database for the VNode 30V having the specified capability for the VPoint 20V controlled by the local map DB 123_1 among the specified VPoint 20V, and proceeds to step S1704.

[0844] On the other hand, regarding the VPoint 20V outside the control of the local map DB 123_1, the local map DB 123_1 exchanges a map search request / response with the global map DB 122 operating on the cloud server 100_1 (step S1703).

[0845] Specifically, the local graph DB 123_1 sends a graph search request message to the global graph DB 122. The graph search request message may be the same as the message shown in Table 76.

[0846] When receiving the graph search request message, the global graph DB 122 accesses the database and searches the database for a VNode 30V having the specified capability with respect to the specified VPoint 20V. Subsequently, the global graph DB 122 sends a graph search response message to the local graph DB 124_1.

[0847] Table 77 is a table illustrating a graph search response message. Table 77 illustrates an example of a graph search response message transmitted by the global graph DB 122 to the local graph DB 124_1.

[0848] (Table 77) Graph Search Response Message

[0849]

[0850] The graph search response message differs from the graph search response message shown in Table 73 in the type of data resolution request. The graph search response message may not include information related to the VPoint 20V, but may include information related to the VNode 30V as the search range (e.g., an identifier or a network address). When multiple VNodes 30V are found as a result of the graph search, the global graph DB 122 sends a graph search response message including information related to the multiple VNodes 30V to the local graph DB 124_1.

[0851] Note that the graph search response message shown here is an example. The global graph DB 122 may send a graph search response message including information other than the information shown in Table 77 to the local graph DB 124_1.

[0852] The global graph DB 122 refers to the respondsViaPrimApi field included in the instance information of the VPoint 20V, such as shown in Table 37, to know the identifier of the VNode 30V. The global graph DB 122 refers to the capability field included in the instance information of the VNode 30V, such as shown in Table 19, to search for a VNode 30V having a desired function.

[0853] like Fig.26 As shown in , the local graph DB 124_1 combines the information related to the VNode 30V found by itself and the information related to the VNode 30V received from the global graph DB 122, and sends a graph search response message to the M2M API 40_1 (step S1704). The graph search response message may be a message of the same format as that shown in Table 77.

[0854] For example, the local map DB 124_1 adds the information related to the VNode 30V found by itself to the graph search response message received from the global graph DB 122 to generate a new graph search response message. The local map DB 124_1 sends the generated graph search response message to the M2M API 40_1.

[0855] When receiving the graph search response message, the M2M API 40_1 stores information related to the VNode 30V (eg, a value of the VNID field or a value of the VNAddress field), and sends a node resolution response message to the M2M application 10_11 (step S1705).

[0856] Table 78 is a table illustrating a node resolution response message. Table 78 illustrates an example of a node resolution response message sent by the M2M API 40_1 to the M2M application 10_11.

[0857] (Table 78) Node parsing response message

[0858]

[0859] The node resolution response message may include, for example, information related to the node resolution result. Note that Table 78 illustrates the node resolution response message in the case where the node resolution is successful.

[0860] When a plurality of VNodes 30V are found as a result of the node resolution, the M2M API 40_1 transmits a node resolution response message including information related to the plurality of VNodes 30V to the M2M application 10_11. Examples of the information related to the plurality of VNodes 30V include identifiers of the VNodes 30V.

[0861] Note that the node resolution response message shown here is an example. The M2M API 40_1 may send a node resolution response message including information other than the information shown in Table 78 to the M2M application 10_11.

[0862] In this process, the node resolution request / response is a function of the M2M API 40_1, and the graph search request / response is a function of the Prim API.

[0863] <5.19. Node type past data analysis process (fixed node)>

[0864] The M2M application 10 may perform the node-specified type data resolution after performing the location resolution and / or node resolution described above. Fig. 27 is a sequence diagram illustrating an example of a node designation type past data parsing process according to an embodiment of the present disclosure. Fig. 27 The diagram illustrates a process in which the M2M application 10_11 specifies the VNode 30V_11 and acquires sensor data observed in the past.

[0865] The M2M application 10_11 sends a data parsing request message to the M2M API 40_1 (step S1801). Table 79 is a table illustrating a data parsing request message. Table 79 illustrates an example of a data parsing request message sent by the M2M application 10_11 to the M2M API 40_1 according to an embodiment of the present disclosure.

[0866] (Table 79) Data parsing request message

[0867] Type = Data parsing request Query Type = Node_Past VNID=Id_VN#11 Capability = CapType Start Time = Time_Start End Time = Time_End

[0868] The data analysis request message may include, for example, information related to VNode30V_11 as the data acquisition destination and time-related information. For example, the time-related information may include time information for specifying a period of time when sensor data was observed in the past (eg, the start time and end time of the period).

[0869] Note that the data parsing request message shown here is an example. The M2M application 10_11 may send a data parsing request message including information other than the information shown in Table 79 to the M2M API 40_1.

[0870] When receiving the data parsing request message, the M2M API 40_1 sends a data search request message to the VNode 30V_11 (step S1802).

[0871] Table 80 is a table illustrating a data search request message. Table 80 illustrates an example of a data search request message transmitted by the M2M API 40_1 to the VNode 30V_11 according to an embodiment of the present disclosure.

[0872] (Table 80) Data Search Request Message

[0873] Type = Data search request Query Type = Node_Past VNID=Id_VN#11 Capability = CapType Start Time = Time_Start End Time = Time_End

[0874] The data search request message may include, for example, information related to the type of data parsing request and information related to time. The information related to time may be the same information as the time information included in the data parsing request message.

[0875] Note that the data search request message shown here is an example. The M2M API 40_1 may send a data search request message including information other than the information shown in Table 80 to the VNode 30V_11.

[0876] When receiving the data search request message, the VNode 30V_11 exchanges data search request / response with the local sensing DB 123_1 (step S1803). Specifically, when receiving the data search request message, the VNode 30V_11 sends the data search request message to the local sensing DB 123_1.

[0877] When receiving the data search request message, the local sense DB 123_1 accesses the database and reads the requested data. Thereafter, the local sense DB 123_1 sends a data search response message to the VNode 30V_11.

[0878] Table 81 is a table illustrating a data search response message. Table 81 illustrates an example of a data search response message transmitted by the local sensing DB 123_1 to the VNode 30V_11.

[0879] (Table 81) Data Search Response Message

[0880]

[0881] The data search response message may include, for example, information related to the data search result and information related to the data (e.g., sensor data and acquisition date and time of the data sensor). When a plurality of sensor data are found as a result of the data search, the local sensing DB 123_1 sends a data search response message including information related to the plurality of sensor data to the VNode 30V_11.

[0882] Note that the data search response message shown here is an example. The local sensing DB 123_1 may transmit a data search response message including information other than the information shown in Table 81 to the VNode 30V_11.

[0883] Note that the local sensing DB 123_1 searches for sensor data with reference to the VNID field, the Capability field, and the Time field included in the registration data (sensor data entry) shown in Table 46, for example.

[0884] like Fig. 27 As shown in , when receiving the data search response message, the VNode 30V_11 sends a data search response message to the M2M API 40_1 (step S1804).

[0885] When receiving the data search response message, the M2M API 40_1 sends a data parsing response message to the M2M application 10_11 (step S1805).

[0886] Table 82 is a table illustrating a data parsing response message. Table 82 illustrates an example of a data parsing response message sent by the M2M API 40_1 to the M2M application 10_11.

[0887] (Table 82) Data analysis response message

[0888]

[0889]

[0890] The data parsing response message may include, for example, information related to the data parsing result. Note that Table 82 illustrates the data parsing response message in the case where the data parsing is successful.

[0891] When a plurality of sensor data are found as a result of data parsing, the M2M API 40_1 transmits a data parsing response message including information related to the plurality of sensor data to the M2M application 10_11. Examples of the information related to the plurality of sensor data include the sensor data and the acquisition date and time of the sensor data.

[0892] Note that the data parsing response message shown here is an example. The M2M API 40_1 may send a data parsing response message including information other than the information shown in Table 82 to the M2M application 10_11.

[0893] In this process, the data parsing request / response is a function of the M2M API 40_1, and the data searching request / response is a function of the Prim API.

[0894] Note that, assuming that the M2M application 10_11 specifies VMNode 30VM_11 and performs node-specified type data parsing, VMNode 30VM_11 is a virtual module corresponding to PMNode 30PM_11, where the MEC server 100_21 on which the M2M application 10_11 operates is the home MEC server. In this case, when the M2M application 10_11 obtains sensor data observed in the past from VMNode 30VM_11, it can also perform the same Fig. 27 The same process as shown in .

[0895] <5.20. Node type past data analysis process (mobile node)>

[0896] Fig.28 is a sequence diagram illustrating another example of a node designation type past data parsing process according to an embodiment of the present disclosure. Fig.28 The process of M2M application 10_11 specifying VMNode 30VM_21 and acquiring sensor data observed in the past is illustrated. Note that VMNode 30VM_21 is a virtual module corresponding to PMNode 30PM_11, where servers other than MEC server 100_21 on which M2M application 10_11 operates are home MEC servers.

[0897] The M2M application 10_11 sends a data parsing request message to the M2M API 40_1 (step S1901). Table 83 is a table illustrating a data parsing request message. Table 83 illustrates an example of a data parsing request message sent by the M2M application 10_11 to the M2M API 40_1 according to an embodiment of the present disclosure.

[0898] (Table 83) Data analysis request message

[0899] Type = Data parsing request Query Type = Node_Past VNID=Id_VMN#21 Capability = CapType Start Time = Time_Start End Time = Time_End

[0900] The data parsing request message may be the same as the message shown in Table 79, for example, except that the data acquisition destination is VMNode 30VM_21.

[0901] Note that the data parsing request message shown here is an example. The M2M application 10_11 may send a data parsing request message including information other than the information shown in Table 83 to the M2M API 40_1.

[0902] When receiving the data parsing request message, the M2M API 40_1 sends a data search request message to the VMNode 30VM_21 (step S1902).

[0903] Table 84 is a table illustrating a data search request message. Table 84 illustrates an example of a data search request message transmitted by the M2MAPI 40_1 to the VMNode 30VM_21 according to an embodiment of the present disclosure.

[0904] (Table 84) Data search request message

[0905] Type = Data search request Query Type = Node_Past VNID=Id_VMN#21 Capability = CapType Start Time = Time_Start End Time = Time_End

[0906] The data search request message may be the same as the message shown in Table 80, for example, except that the data acquisition destination is VMNode 30VM_21.

[0907] Note that the data search request message shown here is an example. The M2M API 40_1 may send a data search request message including information other than the information shown in Table 80 to the VMNode 30VM_21.

[0908] When receiving the data search request message, the VMNode 30VM_21 exchanges data search request / response with the local sensing DB 123_2 (step S1903). Specifically, when receiving the data search request message, the VMNode 30VM_21 sends the data search request message to the local sensing DB 123_2.

[0909] When receiving the data search request message, the local sensing DB 123_2 accesses the database and reads the requested data. Thereafter, the local sensing DB 123_2 sends a data search response message to VMNode30VM_21. The data search response message may have the same format as that shown in Table 81.

[0910] When receiving the data search response message, the VMNode 30VM_21 sends a data search response message to the M2M API 40_1 (step S1904).

[0911] When receiving the data search response message, the M2M API 40_1 sends a data parsing response message to the M2M application 10_11 (step S1905). The data parsing response message may have the same format as that of the message shown in Table 82.

[0912] In this process, the data parsing request / response is a function of the M2M API 40_1, and the data searching request / response is a function of the Prim API.

[0913] As described above, the M2M application 10_11 according to the present embodiment can acquire sensor data measured in the past from a mobile node in the same process as that for a fixed node. As described above, the M2M application 10_11 according to the present embodiment can acquire sensor data from a mobile node more easily.

[0914] <5.21. Current data parsing process of node specified type (fixed node)>

[0915] Fig.29 is a sequence diagram illustrating an example of a node-specified type current data parsing process according to an embodiment of the present disclosure. Fig.29 The diagram illustrates a process in which the M2M application 10_11 specifies the VNode 30V_11 and obtains current sensor data.

[0916] The M2M application 10_11 sends a data parsing request message to the M2M API 40_1 (step S2001). Table 85 is a table illustrating a data parsing request message. Table 85 illustrates an example of a data parsing request message sent by the M2M application 10_11 to the M2M API 40_1 according to an embodiment of the present disclosure.

[0917] (Table 85) Data analysis request message

[0918] Type = Data parsing request Query Type = Node_Current VNID=Id_VN#11 Capability = CapType

[0919] In the data analysis request message, for example, the type of the data analysis request is a type indicating data analysis for current data (Query Type = Node_Current). A field indicating a data acquisition period is not included. Other information is the same as that of the data analysis request message shown in Table 79, for example.

[0920] Note that the data parsing request message shown here is an example. The M2M application 10_11 may send a data parsing request message including information other than the information shown in Table 85 to the M2M API 40_1.

[0921] When receiving the data parsing request message, the M2M API 40_1 sends a data obtaining request message to the VNode 30V_11 (step S2002 ).

[0922] Table 86 is a table illustrating a data acquisition request message. Table 86 illustrates an example of a data acquisition request message transmitted by the M2MAPI 40_1 to the VNode 30V_11 according to an embodiment of the present disclosure.

[0923] (Table 86) Data acquisition request message

[0924] Type = Data acquisition request Query Type = Node_Current VNID=Id_VN#11 Capability = CapType

[0925] The data acquisition request message may include, for example, information related to the type of data parsing request and information related to the VNode 30V_11 that is the data acquisition target.

[0926] Note that the data acquisition request message shown here is an example. The M2M API 40_1 may send a data acquisition request message including information other than the information shown in Table 86 to the VNode 30V_11.

[0927] When receiving the data acquisition request message, the VNode 30V_11 sends a data read request message to the PSink 20P_11 (step S2003).

[0928] Table 87 is a table illustrating a data read request message. Table 87 illustrates an example of a data read request message transmitted from VNode 30V_11 to PSink 20P_11 according to an embodiment of the present disclosure.

[0929] (Table 87) Data read request message

[0930] Type = Data read request Capability = CapType

[0931] The data read request message may include, for example, information related to the type of data parsing request. Note that the data read request message shown here is an example. The VNode 30V_11 may send a data read request message including information other than the information shown in Table 87 to the PSink 20P_11.

[0932] When receiving the data search request message, the PSink 20P_11 exchanges data search request / response with the PNode 30P_11 (step S2004). Specifically, when receiving the data read request message, the PSink 20P_11 sends the data read request message to the PNode 30P_11.

[0933] When receiving the data read request message, the PNode 30P_11 measures the sensor data. Thereafter, the PNode 30P_11 sends a data read response message including the measured sensor data to the PSink 20P_11.

[0934] Table 88 is a table illustrating a data read response message. Table 88 illustrates an example of a data read response message sent by PNode30P_11 to PSink 20P_11.

[0935] (Table 88) Data read response message

[0936] Type = Data read response Status = OK Capability = CapType Time = Time_Sensed Data = Data_Sensed

[0937] The data read response message may include, for example, information related to success or failure of measurement and information related to measurement data (eg, sensor data and acquisition date and time of the data sensor). Table 88 illustrates a data read response message in case that data measurement is successful.

[0938] Note that the data read response message shown here is an example. PNode 30P_11 may send a data read response message including information other than the information shown in Table 88 to PSink 20P_11.

[0939] When receiving the data read response message, the PSink 20P_11 sends a data read response message to the VNode 30V_11 (step S2005).

[0940] When receiving the data read response message, the VNode 30V_11 sends a data acquisition response message to the M2M API 40_1 (step S2006 ).

[0941] Table 89 is a table illustrating a data acquisition response message. Table 89 illustrates an example of a data acquisition response message transmitted by the VNode 30V_11 to the M2M API 40_1.

[0942] (Table 89) Data acquisition response message

[0943] Type = Data Acquisition Response Query Type = Node_Current Status = OK Capability = CapType Time = Time_Sensed Data = Data_Sensed

[0944] The data acquisition response message may include, for example, information related to success or failure of acquisition and information related to measurement data (eg, sensor data and acquisition date and time of the data sensor). Table 89 illustrates a data acquisition response message in the case where data acquisition is successful.

[0945] Note that the data acquisition response message shown here is an example. The VNode 30V_11 may send a data acquisition response message including information other than the information shown in Table 89 to the M2M API 40_1.

[0946] When receiving the data acquisition response message, the M2M API 40_1 sends a data parsing response message to the M2M application 10_11 (step S2007).

[0947] Table 90 is a table illustrating a data parsing response message. Table 90 illustrates an example of a data parsing response message sent by the M2M API 40_1 to the M2M application 10_11.

[0948] (Table 90) Data analysis response message

[0949] Type = Data parsing response Query Type = Node_Current Status = OK Capability = CapType Time = Time_Sensed Data = Data_Sensed

[0950] The data parsing response message may include, for example, information related to the data parsing result and information related to the measurement data (eg, sensor data and acquisition date and time of the data sensor). Note that Table 90 illustrates the data parsing response message in the case where the data parsing is successful.

[0951] Note that the data parsing response message shown here is an example. The M2M API 40_1 may send a data parsing response message including information other than the information shown in Table 90 to the M2M application 10_11.

[0952] In this process, data parsing request / response is the function of M2M API 40_1, while data acquisition request / response is the function of Prim API. Data reading request / response is the function of Dev API.

[0953] <5.22. Current data analysis process of node specified type (mobile node)>

[0954] Fig.30 is a sequence diagram illustrating another example of a node-specified type current data parsing process according to an embodiment of the present disclosure. Fig.30The diagram illustrates a process in which the M2M application 10_11 specifies the VMNode 30VM_21 and obtains current sensor data. Note that the VMNode 30VM_21 is a virtual module corresponding to the PMNode 30PM_11, where the server other than the MEC server 100_21 on which the M2M application 10_11 operates is the home MEC server.

[0955] The M2M application 10_11 sends a data parsing request message to the M2M API 40_1 (step S2101). Table 91 is a table illustrating a data parsing request message. Table 91 illustrates an example of a data parsing request message sent by the M2M application 10_11 to the M2M API 40_1 according to an embodiment of the present disclosure.

[0956] (Table 91) Data analysis request message

[0957]

[0958]

[0959] The data parsing request message may be the same as the message shown in Table 85, for example, except that the data acquisition destination is VMNode 30VM_21.

[0960] Note that the data parsing request message shown here is an example. The M2M application 10_11 may send a data parsing request message including information other than the information shown in Table 91 to the M2M API 40_1.

[0961] When receiving the data parsing request message, the M2M API 40_1 sends a data obtaining request message to the VMNode 30VM_21 (step S2102).

[0962] Table 92 is a table illustrating a data acquisition request message. Table 92 illustrates an example of a data acquisition request message transmitted by the M2MAPI 40_1 to the VMNode 30VM_21 according to an embodiment of the present disclosure.

[0963] (Table 92) Data acquisition request message

[0964] Type = Data acquisition request Query Type = Node_Current VNID=Id_VMN#21 Capability = CapType

[0965] The data acquisition request message may be the same as the message shown in Table 86, for example, except that the data acquisition destination is VMNode 30VM_21.

[0966] Note that the data acquisition request message shown here is an example. The M2M API 40_1 may send a data acquisition request message including information other than the information shown in Table 92 to the VMNode 30VM_21.

[0967] When receiving the data acquisition request message, VMNode 30VM_21 sends a data read request message to PSink20P_11 (step S2103). The data read request message may be the same as the message shown in Table 86, for example.

[0968] When receiving the data search request message, PSink 20P_11 exchanges data search request / response with PMNode30PM_21 (step S2104). Specifically, when receiving the data read request message, PSink 20P_11 sends a data read request message to PMNode30PM_21.

[0969] When receiving the data read request message, PMNode 30PM_21 measures the sensor data. Thereafter, PMNode 30PM_21 sends a data read response message including the measured sensor data to PSink 20P_11. The data read response message may be the same as the message shown in Table 88, for example.

[0970] When receiving the data read response message, PSink 20P_11 sends a data read response message to VMNode30VM_21 (step S2105).

[0971] When receiving the data read response message, VMNode 30VM_21 sends a data acquisition response message to M2M API 40_1 (step S2106). The data acquisition response message may be the same as the message shown in Table 89, for example.

[0972] When receiving the data acquisition response message, the M2M API 40_1 sends a data parsing response message to the M2M application 10_11 (step S2107). The data parsing response message may be the same as the message shown in Table 90, for example.

[0973] In this process, data parsing request / response is the function of M2M API 40_1, while data acquisition request / response is the function of Prim API. Data reading request / response is the function of Dev API.

[0974] As described above, the M2M application 10_11 according to the present embodiment can obtain current sensor data from the mobile node in the same process as that for the fixed node. As described above, the M2M application 10_11 according to the present embodiment can more easily obtain sensor data from the mobile node.

[0975] <5.23. Node type specification conditions meet data parsing process (fixed node)>

[0976] Fig.31 is a sequence diagram illustrating an example of a node-specified type condition-satisfying data parsing process according to an embodiment of the present disclosure. Fig.31 The diagram illustrates a process in which the M2M application 10_11 specifies the VNode 30V_11 and obtains sensor data that satisfies the conditions.

[0977] At a timing when a predetermined condition is satisfied, the M2M application 10_11 acquires sensor data from the VNode 30V_11. That is, the M2M application 10_11 performs a node-specifying type future data parsing process for specifying a node and acquiring future data.

[0978] The M2M application 10_11 sends a data parsing request message to the M2M API 40_1 (step S2201). Table 93 is a table illustrating a data parsing request message. Table 93 illustrates an example of a data parsing request message sent by the M2M application 10_11 to the M2M API 40_1 according to an embodiment of the present disclosure.

[0979] (Table 93) Data analysis request message

[0980] Type = Data parsing request Query Type = Node_Condition VNID=Id_VN#11 Capability = CapType Condition = CondType

[0981] In the data analysis request message, for example, the type of the data analysis request is a type indicating that a condition satisfies data analysis (query type = Node_Condition). The data analysis request message includes information for specifying a data acquisition condition. Other information is the same as that of the data analysis request message shown in Table 85, for example.

[0982] Note that the data parsing request message shown here is an example. The M2M application 10_11 may send a data parsing request message including information other than the information shown in Table 93 to the M2M API 40_1.

[0983] When receiving the data parsing request message, the M2M API 40_1 sends a data obtaining request message to the VNode 30V_11 (step S2202).

[0984] Table 94 is a table illustrating a data acquisition request message. Table 94 illustrates an example of a data acquisition request message transmitted by the M2MAPI 40_1 to the VNode 30V_11 according to an embodiment of the present disclosure.

[0985] (Table 94) Data acquisition request message

[0986] Type = Data acquisition request Query Type = Node_Condition VNID=Id_VN#11 Capability = CapType Condition = CondType

[0987] In the data acquisition request message, for example, the type of data parsing request is a type indicating that a condition satisfies data parsing (Query Type = Node_Condition). The data acquisition request message includes information for specifying the data acquisition condition. Other information is the same as that of the data acquisition request message shown in Table 86, for example.

[0988] Note that the data acquisition request message shown here is an example. The M2M API 40_1 may send a data acquisition request message including information other than the information shown in Table 94 to the VNode 30V_11.

[0989] When receiving the data acquisition request message, the VNode 30V_11 waits for receiving a data notification message including sensor data satisfying the condition (Condition=CondType) included in the data acquisition request message. That is, the VNode 30V_11 determines whether the acquired sensor data satisfies the condition.

[0990] PNode 30P_11 notifies VPoint 20V_11 of data via PSink 20P_11 at a predetermined timing, for example. VPoint 20V_11 writes the data in VNode 30V_11 (step S2203). Note that the predetermined timing may be a predetermined periodic timing, or may be a timing corresponding to an instruction from M2M application 10_11 or the like.

[0991] Finally, the PNode 30P_11 notifies the VPoint 20V_11 of the sensor data satisfying the condition via the PSink 20P_11. The VPoint 20V_11 writes the data into the VNode 30V_11 (step S2204).

[0992] Then, the VNode 30V_11 sends a data acquisition response message including the sensor data satisfying the condition to the M2M API 40_1 (step S2205 ).

[0993] Table 95 is a table illustrating a data acquisition response message. Table 95 illustrates an example of a data acquisition response message transmitted by the VNode 30V_11 to the M2M API 40_1.

[0994] (Table 95) Data acquisition response message

[0995] Type = Data Acquisition Response Query Type = Node_Condition VNID=Id_VN#11 Status = OK Capability = CapType Time = Time_Sensed Data = Data_Sensed

[0996] In the data acquisition response message, for example, the type of the data parsing request is a type indicating that the condition satisfies the data parsing (Query Type = Node_Condition). The data acquisition response message includes information for specifying the data acquisition condition. Other information is the same as that of the data acquisition response message shown in Table 89, for example.

[0997] Note that the data acquisition response message shown here is an example. The VNode 30V_11 may send a data acquisition response message including information other than the information shown in Table 95 to the M2M API 40_1.

[0998] When receiving the data acquisition response message, the M2M API 40_1 sends a data parsing response message to the M2M application 10_11 (step S2206).

[0999] Table 96 is a table illustrating a data parsing response message. Table 96 illustrates an example of a data parsing response message sent by the M2M API 40_1 to the M2M application 10_11.

[1000] (Table 96) Data analysis response message

[1001] Type = Data parsing response Query Type = Node_Condition VNID=Id_VN#11 Status = OK Capability = CapType Time = Time_Sensed Data = Data_Sensed

[1002] In the data analysis response message, for example, the type of the data analysis request is a type indicating that the condition satisfies the data analysis (query type = Node_Condition). The data analysis response message includes information for specifying the data acquisition condition. Other information is the same as that of the data analysis response message shown in Table 90, for example.

[1003] Note that the data parsing response message shown here is an example. The M2M API 40_1 may send a data parsing response message including information other than the information shown in Table 96 to the M2M application 10_11.

[1004] In this process, the data parsing request / response is the function of the M2M API 40_1, and the data acquisition request / response is the function of the Prim API.

[1005] <5.24. Node type specification conditions meet data parsing process (mobile node)>

[1006] Fig.32 is a sequence diagram illustrating another example of a node-specified type condition-satisfying data parsing process according to an embodiment of the present disclosure. Fig.32 The process of M2M application 10_11 specifying VMNode 30VM_21 and acquiring condition satisfaction data is illustrated. Note that VMNode 30VM_21 is a virtual module corresponding to PMNode 30PM_11, where servers other than MEC server 100_21 on which M2M application 10_11 operates are home MEC servers.

[1007] The M2M application 10_11 acquires sensor data from the VMNode 30VM_21 at a timing when a predetermined condition is satisfied. That is, the M2M application 10_11 performs a node-specified type future data parsing process for specifying a node and acquiring future data.

[1008] The M2M application 10_11 sends a data parsing request message to the M2M API 40_1 (step S2301). Table 97 is a table illustrating a data parsing request message. Table 97 illustrates an example of a data parsing request message sent by the M2M application 10_11 to the M2M API 40_1 according to an embodiment of the present disclosure.

[1009] (Table 97) Data analysis request message

[1010] Type = Data parsing request Query Type = Node_Condition VNID=Id_VMN#21 Capability = CapType Condition = CondType

[1011] The data parsing request message may be the same as the message shown in Table 93, for example, except that the data acquisition destination is VMNode 30VM_21.

[1012] Note that the data parsing request message shown here is an example. The M2M application 10_11 may send a data parsing request message including information other than the information shown in Table 97 to the M2M API 40_1.

[1013] When receiving the data parsing request message, the M2M API 40_1 sends a data obtaining request message to the VMNode30VM_21 (step S2302).

[1014] Table 98 is a table illustrating a data acquisition request message. Table 98 illustrates an example of a data acquisition request message transmitted by the M2MAPI 40_1 to the VMNode 30VM_21 according to an embodiment of the present disclosure.

[1015] (Table 98) Data acquisition request message

[1016]

[1017]

[1018] The data acquisition request message may be the same as the message shown in Table 94, for example, except that the data acquisition destination is VMNode 30VM_21.

[1019] Note that the data acquisition request message shown here is an example. The M2M API 40_1 may send a data acquisition request message including information other than the information shown in Table 98 to the VMNode 30VM_21.

[1020] When receiving the data acquisition request message, VMNode 30VM_21 waits for receiving a data notification message including sensor data satisfying the condition (Condition=CondType) included in the data acquisition request message. That is, VMNode 30VM_21 determines whether the acquired sensor data satisfies the condition.

[1021] The PMNode 30PM_21 notifies the VPoint 20V_11 of data via the PSink 20P_11 at a predetermined timing, for example. The VPoint 20V_11 writes the data into the VMNode 30VM_21 (step S2303).

[1022] Note that the predetermined timing may be a predetermined periodic timing, or may be a timing corresponding to an instruction from the M2M application 10_11 or the like.

[1023] Here, since PMNode 30PM_21 is communicating with PSink 20P_11, PMNode 30PM_21 notifies VMNode 30VM_21 of the sensor data via PSink 20P_11 and VPoint 20V_11. PMNode 30PM_21 notifies VMNode 30VM_21 of the sensor data via PSink 20P connected at the time point when the sensor data is notified and VPoint 20V_11 corresponding to PSink 20P. For this purpose, PMNode 30PM_21 may notify the sensor data via PSink 20P other than PSink 20P_11.

[1024] Finally, the PMNode 30PM_21 notifies the VPoint 20V_11 of the sensor data satisfying the condition via the PSink 20P_11, and the VPoint 20V_11 writes the data in the VMNode 30VM_21 (step S2304).

[1025] Then, the VMNode 30VM_21 sends a data acquisition response message including the sensor data satisfying the condition to the M2M API 40_1 (step S2305).

[1026] Table 99 is a table illustrating a data acquisition response message. Table 99 illustrates an example of a data acquisition response message transmitted by VMNode30VM_21 to M2M API 40_1.

[1027] (Table 99) Data acquisition response message

[1028] Type = Data Acquisition Response Query Type = Node_Condition VNID=Id_VMN#21 Status = OK Capability = CapType Time = Time_Sensed Data = Data_Sensed

[1029] The data acquisition response message may be the same as the message shown in Table 95, for example, except that the data acquisition destination is VMNode 30VM_21.

[1030] Note that the data acquisition response message shown here is an example. The VMNode 30VM_21 may send a data acquisition response message including information other than the information shown in Table 99 to the M2M API 40_1.

[1031] When receiving the data acquisition response message, the M2M API 40_1 sends a data parsing response message to the M2M application 10_11 (step S2306).

[1032] Table 100 is a table illustrating a data parsing response message. Table 100 illustrates an example of a data parsing response message sent by the M2M API 40_1 to the M2M application 10_11.

[1033] (Table 100) Data analysis response message

[1034] Type = Data parsing response Query Type = Node_Condition VNID=Id_VMN#21 Status = OK Capability = CapType Time = Time_Sensed Data = Data_Sensed

[1035] The data acquisition response message may be the same as the message shown in Table 96, for example, except that the data acquisition destination is VMNode 30VM_21.

[1036] Note that the data parsing response message shown here is an example. The M2M API 40_1 may send a data parsing response message including information other than the information shown in Table 100 to the M2M application 10_11.

[1037] In this process, the data parsing request / response is the function of the M2M API 40_1, and the data acquisition request / response is the function of the Prim API.

[1038] As described above, the M2M application 10_11 according to the present embodiment can acquire condition satisfaction data from the mobile node in the same process as that for the fixed node. As described above, the M2M application 10_11 according to the present embodiment can more easily acquire sensor data from the mobile node.

[1039] <5.25. Location Designation Type Past Data Analysis Process>

[1040] Fig.33 is a sequence diagram illustrating an example of a place designation type past data parsing process according to an embodiment of the present disclosure. Fig.33 The diagram illustrates a process in which the M2M application 10_11 specifies the VPoint20V_11 and obtains sensor data observed in the past.

[1041] The M2M application 10_11 sends a data parsing request message to the M2M API 40_1 (step S2401). Table 101 is a table illustrating a data parsing request message. Table 101 illustrates an example of a data parsing request message sent by the M2M application 10_11 to the M2M API 40_1 according to an embodiment of the present disclosure.

[1042] (Table 101) Data analysis request message

[1043] Type = Data parsing request Query Type = Point_Past VPID=Id_VP#11 Capability = CapType Start Time = Time_Start End Time = Time_End

[1044] In the data resolution request message, for example, the type of the data resolution request is a type indicating a location-specified type of past data resolution (Query Type = Point_Past). A field for specifying VPoint 20V_11 (VPID = Id_VP#11) is included instead of a field for specifying VNode 30V_11. Other information is the same as that of the data resolution request message shown in Table 79, for example.

[1045] Note that the data parsing request message shown here is an example. The M2M application 10_11 may send a data parsing request message including information other than the information shown in Table 101 to the M2M API 40_1.

[1046] When receiving the data parsing request message, the M2M API 40_1 sends a data searching request message to the VPoint 20V_11 (step S2402 ).

[1047] Table 102 is a table illustrating a data search request message. Table 102 illustrates an example of a data search request message transmitted by the M2MAPI 40_1 to the VPoint 20V_11 according to an embodiment of the present disclosure.

[1048] (Table 102) Data search request message

[1049] Type = Data search request Query Type = Point_Past VPID=Id_VP#11 Capability = CapType Start Time = Time_Start End Time = Time_End

[1050] In the data search request message, for example, the type of data resolution request is a type indicating a location-specified type of past data resolution (Query Type = Point_Past). A field (VPID = Id_VP#11) for specifying VPoint 20V_11 is included instead of a field for specifying VNode 30V_11. Other information is the same as that of the data search request message shown in Table 80, for example.

[1051] Note that the data search request message shown here is an example. The M2M API 40_1 may transmit a data search request message including information other than the information shown in Table 102 to the VPoint 20V_11.

[1052] When receiving the data search request message, the VPoint 20V_11 exchanges data search request / response with the local sensing DB 123_1 (step S2403). Specifically, when receiving the data search request message, the VPoint 20V_11 sends the data search request message to the local sensing DB 123_1.

[1053] When receiving the data search request message, the local sense DB 123_1 accesses the database and reads the requested data. Thereafter, the local sense DB 123_1 transmits a data search response message including the read data to the VPoint20V_11.

[1054] Table 103 is a table illustrating a data search response message. Table 103 illustrates an example of a data search response message transmitted by the local sense DB 123_1 to the VPoint20V_11.

[1055] (Table 103) Data search response message

[1056]

[1057] In the data search response message, for example, the type of the data analysis request is a type indicating a point-specified type past data analysis (Query Type = Point_Past). Other information is the same as that of the data search response message shown in Table 81, for example.

[1058] Note that the data search response message shown here is an example. The local sense DB 123_1 may transmit a data search response message including information other than the information shown in Table 103 to the VPoint20V_11.

[1059] Note that the local sensing DB 123_1 searches for sensor data with reference to the VNID field, the Capability field, and the Time field included in the registration data (sensor data entry) shown in Table 46, for example.

[1060] like Fig.33 As shown in FIG. 24 , when receiving the data search response message, the VPoint 20V_11 sends a data search response message to the M2M API 40_1 (step S2404 ).

[1061] When receiving the data search response message, the M2M API 40_1 sends a data parsing response message to the M2M application 10_11 (step S2405).

[1062] Table 104 is a table illustrating a data parsing response message. Table 104 illustrates an example of a data parsing response message sent by the M2M API 40_1 to the M2M application 10_11.

[1063] (Table 104) Data analysis response message

[1064]

[1065] In the data search response message, for example, the type of the data analysis request is a type indicating a point-specified type past data analysis (Query Type = Point_Past). Other information is the same as that of the data search response message shown in Table 82, for example.

[1066] Note that the data parsing response message shown here is an example. The M2M API 40_1 may send a data parsing response message including information other than the information shown in Table 104 to the M2M application 10_11.

[1067] As mentioned above Fig. 20 As described above, the data measured by the PMNode 30PM_21 temporarily connected to the PSink 20P_11 and registered in the VMNode 30VM_21 is also stored in the local sensing DB 123_1. To this end, the M2M application 10 can also perform Fig.33 The sensor data registered by the mobile node is obtained by the process shown in . As described above, the M2M application 10 according to the present embodiment can more easily obtain sensor data from the mobile node.

[1068] <5.26. Location-specific type current data analysis process>

[1069] Fig.34is a sequence diagram illustrating an example of a place-specified type current data parsing process according to an embodiment of the present disclosure. Fig.34 The diagram illustrates a process in which the M2M application 10_11 specifies VPoint20V_11 and obtains current sensor data.

[1070] The M2M application 10_11 sends a data parsing request message to the M2M API 40_1 (step S2501). Table 105 is a table illustrating a data parsing request message. Table 105 illustrates an example of a data parsing request message sent by the M2M application 10_11 to the M2M API 40_1 according to an embodiment of the present disclosure.

[1071] (Table 105) Data analysis request message

[1072]

[1073]

[1074] In the data resolution request message, for example, the type of the data resolution request is a type indicating the current data resolution of the location type (Query Type = Point_Current). A field for specifying VPoint 20V_11 (VPID = Id_VP#11) is included instead of a field for specifying VNode 30V_11. Other information is the same as that of the data resolution request message shown in Table 85, for example.

[1075] Note that the data parsing request message shown here is an example. The M2M application 10_11 may send a data parsing request message including information other than the information shown in Table 105 to the M2M API 40_1.

[1076] When receiving the data parsing request message, the M2M API 40_1 sends a data obtaining request message to the VPoint 20V_11 (step S2502).

[1077] Table 106 is a table illustrating a data acquisition request message. Table 106 illustrates an example of a data acquisition request message transmitted by the M2MAPI 40_1 to the VPoint 20V_11 according to an embodiment of the present disclosure.

[1078] (Table 106) Data acquisition request message

[1079] Type = Data acquisition request Query Type = Point_Current VPID=Id_VP#11 Capability = CapType

[1080] In the data acquisition request message, for example, the type of data resolution request is a type indicating the current data resolution of the location type (Query Type = Point_Current). A field for specifying VPoint 20V_11 (VPID = Id_VP#11) is included instead of a field for specifying VNode 30V_11. Other information is the same as that of the data acquisition request message shown in Table 86, for example.

[1081] Note that the data acquisition request message shown here is an example. The M2M API 40_1 may transmit a data acquisition request message including information other than the information shown in Table 106 to the VPoint 20V_11.

[1082] When receiving the data acquisition request message, VPoint 20V_11 sends a data read request message to PSink 20P_11 (step S2503). The data read request message may be the same as the data read request message shown in Table 87, for example.

[1083] When receiving the data search request message, PSink 20P_11 communicates with PNode 30P ( Fig.34 30P_11 to 30P_13 in the PNode 30P_11 to 30P_13) exchange data search request / response (step S2504). Specifically, when receiving the data read request message, the PSink 20P_11 sends a data read request message to the PNode 30P_11 to 30P_13.

[1084] When receiving the data read request message, the PNodes 30P_11 to 30P_13 measure the sensor data. Thereafter, the PNodes 30P_11 to 30P_13 send data read response messages including the measured sensor data to the PSink 20P_11, respectively. The data read response message may be the same as the data read response message shown in Table 88, for example.

[1085] When receiving the data read response messages from the PNodes 30P_11 to 30P_13 respectively, the PSink 20P_11 sends the data read response message to the VPoint 20V_11 (step S2505).

[1086] When receiving the data read response message, the VPoint 20V_11 sends a data acquisition response message to the M2M API 40_1 (step S2506 ).

[1087] Table 107 is a table illustrating a data acquisition response message. Table 107 illustrates an example of a data acquisition response message transmitted by VPoint20V_11 to M2M API40_1.

[1088] (Table 107) Data acquisition response message

[1089]

[1090] In the data acquisition response message, for example, the type of the data resolution request is a type indicating the current data resolution of the location type (query type (Query Type) = Point_Current). For example, including at least one PNode 30P ( Fig.34 The data analysis request data includes information related to the data measured by the PNodes 30P_11 to 30P_13 in FIG. 8 (eg, sensor data and the acquisition date and time of the data sensor). In addition, the data analysis request data is the same as the data analysis request message shown in Table 89, for example.

[1091] Note that the data acquisition response message shown here is an example. The VPoint 20V_11 may send a data acquisition response message including information other than the information shown in Table 107 to the M2M API 40_1.

[1092] When receiving the data acquisition response message, the M2M API 40_1 sends a data parsing response message to the M2M application 10_11 (step S2507).

[1093] Table 108 is a table illustrating a data parsing response message. Table 108 illustrates an example of a data parsing response message sent by the M2M API 40_1 to the M2M application 10_11.

[1094] (Table 108) Data analysis response message

[1095]

[1096] In the data acquisition response message, for example, the type of the data resolution request is a type indicating the current data resolution of the location type (query type (Query Type) = Point_Current). For example, including at least one PNode 30P ( Fig.34 The data analysis response message includes information related to the data measured by the PNodes 30P_11 to 30P_13 in FIG. 9 (eg, sensor data and the acquisition date and time of the data sensor). Otherwise, the data analysis response message is the same as the data analysis request message shown in Table 90, for example.

[1097] Note that the data parsing response message shown here is an example. The M2M API 40_1 may send a data parsing response message including information other than the information shown in Table 108 to the M2M application 10_11.

[1098] Here, the PSink 20P_11 acquires sensor data from the PNode 30P connected to the PSink 20P_11. However, the PSink 20P_11 may also acquire data from a mobile node (eg, PMNode 30PM_11 or 30PM_21) connected to the PSink 20P_11.

[1099] As mentioned above Fig.17 As described above, VPoint 20V_11 manages the connection status of PMNode 30PM_21 temporarily connected to PSink 20P_11. To this end, the M2M application 10 can also execute Fig.34 The sensor data measured by the mobile node is obtained by the process shown in . As described above, the M2M application 10 according to the present embodiment can more easily obtain sensor data from the mobile node.

[1100] <5.27. Location Designation Type Conditions Satisfy Data Parsing Process>

[1101] Fig.35 is a sequence diagram illustrating an example of a place designation type condition satisfaction data parsing process according to an embodiment of the present disclosure. Fig.35 The diagram illustrates a process in which the M2M application 10_11 specifies the VPoint20V_11 and obtains sensor data that satisfies the condition.

[1102] At the timing when the predetermined condition is satisfied, the M2M application 10_11 acquires the sensor data from the VPoint 20V_11. That is, the M2M application 10_11 performs a location designation type future data parsing process for designating a node and acquiring future data.

[1103] The M2M application 10_11 sends a data parsing request message to the M2M API 40_1 (step S2601). Table 109 is a table illustrating a data parsing request message. Table 109 illustrates an example of a data parsing request message sent by the M2M application 10_11 to the M2M API 40_1 according to an embodiment of the present disclosure.

[1104] (Table 109) Data analysis request message

[1105]

[1106] In the data resolution request message, for example, the type of the data resolution request is a type indicating that the location type condition satisfies the data resolution (query type (Query Type) = Point_Condition). A field (VPID = Id_VP#11) for specifying VPoint 20V_11 is included instead of a field for specifying VNode 30V_11. Other information is the same as that of the data resolution request message shown in, for example, Table 93.

[1107] Note that the data parsing request message shown here is an example. The M2M application 10_11 may send a data parsing request message including information other than the information shown in Table 109 to the M2M API 40_1.

[1108] When receiving the data parsing request message, the M2M API 40_1 sends a data obtaining request message to the VPoint 20V_11 (step S2602).

[1109] Table 110 is a table illustrating a data acquisition request message. Table 110 illustrates an example of a data acquisition request message transmitted by the M2MAPI 40_1 to the VPoint 20V_11 according to an embodiment of the present disclosure.

[1110] (Table 110) Data acquisition request message

[1111]

[1112] In the data acquisition request message, for example, the type of the data parsing request is a type indicating that the location type condition satisfies the data parsing (Query Type = Point_Condition). A field for specifying VPoint 20V_11 (VPID = Id_VP#11) is included instead of a field for specifying VNode 30V_11. Other information is the same as that of the data acquisition request message shown in Table 94, for example.

[1113] Note that the data acquisition request message shown here is an example. The M2M API 40_1 may transmit a data acquisition request message including information other than the information shown in Table 110 to the VPoint 20V_11.

[1114] When receiving the data acquisition request message, the VPoint 20V_11 waits for receiving a data notification message including sensor data satisfying the condition (Condition=CondType) included in the data acquisition request message. That is, the VPoint 20V_11 determines whether the acquired sensor data satisfies the condition.

[1115] At least one PNode 30P connected to the PSink 20P_11 notifies the VPoint 20V_11 of data via the PSink 20P_11, for example, at a predetermined timing, and the VPoint 20V_11 writes the data in the VNode 30V_11 (step S2603).

[1116] PSink 20P_11 is the physical sink corresponding to VPoint 20V_11. Fig.35 An example in which the PNodes 30P_11 to 30P_13 notify data is illustrated. The predetermined timing may be a predetermined periodic timing, or may be a timing corresponding to an instruction from the M2M application 10_11 or the like.

[1117] Finally, at least one of the PNodes 30P_11 to 30P_13 notifies the VPoint 20V_11 of the sensor data satisfying the condition via the PSink 20P_11 (step S2604).

[1118] Then, the VPoint 20V_11 transmits a data acquisition response message including the sensor data satisfying the condition to the M2M API 40_1 (step S2605 ).

[1119] Table 111 is a table illustrating a data acquisition response message. Table 111 illustrates an example of a data acquisition response message transmitted by VPoint20V_11 to M2M API40_1.

[1120] (Table 111) Data acquisition response message

[1121]

[1122] In the data acquisition response message, for example, the type of the data parsing request is a type indicating that the location type condition satisfies the data parsing (Query Type = Point_Condition). A field for specifying VPoint 20V_11 (VPID = Id_VP#11) is included instead of a field for specifying VNode 30V_11. Other information is the same as that of the data acquisition response message shown in Table 95, for example.

[1123] Note that the data acquisition response message shown here is an example. The VPoint 20V_11 may send a data acquisition response message including information other than the information shown in Table 111 to the M2M API 40_1.

[1124] When receiving the data acquisition response message, the M2M API 40_1 sends a data parsing response message to the M2M application 10_11 (step S2606).

[1125] Table 112 is a table illustrating a data parsing response message. Table 112 illustrates an example of a data parsing response message sent by the M2M API 40_1 to the M2M application 10_11.

[1126] (Table 112) Data analysis response message

[1127]

[1128] In the data resolution response message, for example, the type of the data resolution request is a type indicating that the location type condition satisfies the data resolution (Query Type = Point_Condition). A field for specifying VPoint 20V_11 (VPID = Id_VP#11) is included instead of a field for specifying VNode 30V_11. Other information is the same as that of the data resolution response message shown in Table 96, for example.

[1129] Note that the data parsing response message shown here is an example. The M2M API 40_1 may send a data parsing response message including information other than the information shown in Table 112 to the M2M application 10_11.

[1130] Here, the VPoint 20V_11 acquires sensor data from the PNode 30P connected to the PSink 20P_11. However, the PSink 20P_11 may also acquire data from a mobile node (eg, PMNode 30PM_11 or 30PM_21) connected to the PSink 20P_11.

[1131] The timings at which the plurality of PNodes 30P report data may be different or the same among the PNodes 30P.

[1132] <5.28. Operation instruction process (fixed node)>

[1133] Fig.36 is a sequence diagram illustrating an example of an operation instruction process according to an embodiment of the present disclosure. Fig.36 The diagram illustrates a process in which the M2M application 10_11 specifies the VNode 30V_11 and instructs an operation.

[1134] The M2M application 10_11 sends an operation request message to the M2M API 40_1 (step S2701). Table 113 is a table illustrating an operation request message. Table 113 illustrates an example of an operation request message sent by the M2M application 10_11 to the M2M API 40_1 according to an embodiment of the present disclosure.

[1135] (Table 113) Operation request message

[1136] Type = Operation Request VNID=Id_VN#11 Action = Act_Name Parameter (Param) = Act_Param

[1137] The operation request message may include, for example, information for specifying an operation instruction target and information related to the operation content. Note that the operation request message shown here is an example. The M2M application 10_11 may send an operation request message including information other than the information shown in Table 113 to the M2M API 40_1.

[1138] When receiving the operation request message, the M2M API 40_1 sends the operation request message to the VNode 30V_11 (step S2702).

[1139] When receiving the operation request message, VNode 30V_11 sends an operation indication request message to PSink 20P_11 (step S2703). Table 114 is a table illustrating an operation indication request message. Table 114 illustrates an example of an operation indication request message sent by VNode 30V_11 to PSink 20P_11 according to an embodiment of the present disclosure.

[1140] (Table 114) Operation instruction request message

[1141] Type = Operation Instruction Request Action = Act_Name Parameter (Param) = Act_Param

[1142] The operation instruction request message may include, for example, information related to the operation content. Note that the operation instruction request message shown here is an example. VNode 30V_11 may send an operation instruction request message including information other than the information shown in Table 114 to PSink20P_11.

[1143] When receiving the operation instruction request message, PSink 20P_11 exchanges operation instruction request / response with PNode 30P_11 (step S2704). Specifically, when receiving the operation instruction request message, PSink 20P_11 sends the operation instruction request message to PNode 30P_11.

[1144] When receiving the operation instruction request message, PNode 30P_11 performs the operation according to the instruction and sends an operation instruction response message to PSink20P_11.

[1145] Table 115 is a table illustrating an operation indication response message. Table 115 illustrates an example of an operation indication response message sent by the PNode 30P_11 to the PSink 20P_11 according to an embodiment of the present disclosure.

[1146] (Table 115) Operation instruction response message

[1147] Type = Operation Instruction Response Status = OK

[1148] The operation instruction response message may include, for example, information related to the success or failure of the operation. Here, the operation instruction request message in the case of successful operation is illustrated. Note that the operation instruction request message shown here is an example. PNode 30P_11 may send an operation instruction response message including information other than the information shown in Table 115 to PSink 20P_11.

[1149] When receiving the operation instruction response message, PSink 20P_11 sends an operation instruction response message to VNode 30V_11 (step S2705).

[1150] When receiving the operation indication response message, the VNode 30V_11 sends an operation response message to the M2M API 40_1 (step S2706 ).

[1151] Table 116 is a table illustrating an operation response message. Table 116 illustrates an example of an operation response message sent by the VNode 30V_11 to the M2M API 40_1 according to an embodiment of the present disclosure.

[1152] (Table 116) Operation response message

[1153] Type = Operation Response VNID=Id_VN#11 Status = OK

[1154] The operation response message may include, for example, information related to the success or failure of the operation. Here, the operation request message in the case of successful operation is illustrated. Note that the operation request message shown here is an example. The VNode 30V_11 may send an operation response message including information other than the information shown in Table 116 to the M2M API 40_1.

[1155] When receiving the operation response message, the M2M API 40_1 sends the operation response message to the M2M application 10_11 (step S2707).

[1156] <5.29. Operation Instruction Process (Mobile Node)>

[1157] Fig.37is a sequence diagram illustrating another example of an operation instruction process according to an embodiment of the present disclosure. Fig.37 The diagram illustrates a process in which the M2M application 10_11 specifies the VMNode 30VM_21 and instructs the operation. Note that the VMNode 30VM_21 is a virtual module corresponding to the PMNode 30PM_11, where the server other than the MEC server 100_21 on which the M2M application 10_11 operates is a home MEC server.

[1158] The M2M application 10_11 sends an operation request message to the M2M API 40_1 (step S2801). Table 117 is a table illustrating an operation request message. Table 117 illustrates an example of an operation request message sent by the M2M application 10_11 to the M2M API 40_1 according to an embodiment of the present disclosure.

[1159] (Table 117) Operation request message

[1160] Type = Operation Request VNID=Id_VMN#21 Action = Act_Name Parameter (Param) = Act_Param

[1161] The operation request message may be the same as the message shown in Table 113 except that the operation indication target is VMNode 30VM_21, for example. Note that the operation request message shown here is an example. The M2M application 10_11 may send an operation request message including information other than that shown in Table 117 to the M2M API 40_1.

[1162] When receiving the operation request message, the M2M API 40_1 sends the operation request message to the VMNode 30VM_21 (step S2802).

[1163] When receiving the operation request message, VMNode 30VM_21 sends an operation instruction request message to PSink 20P_11 (step S2803). The operation instruction request message may be the same as the message shown in Table 114.

[1164] When receiving the operation instruction request message, PSink 20P_11 exchanges operation instruction request / response with PMNode30PM_21 (step S2804). Specifically, when receiving the operation instruction request message, PSink 20P_11 sends the operation instruction request message to PMNode30PM_21.

[1165] When receiving the operation instruction request message, PMNode 30PM_21 performs the operation as instructed and sends an operation instruction response message to PSink 20P_11. The operation instruction response message may be the same as the message shown in Table 115.

[1166] When receiving the operation instruction response message, PSink 20P_11 sends an operation instruction response message to VMNode30VM_21 (step S2805).

[1167] When receiving the operation indication response message, the VMNode 30VM_21 sends an operation response message to the M2M API 40_1 (step S2806).

[1168] Table 118 is a table illustrating an operation response message. Table 118 illustrates an example of an operation response message sent by VMNode30VM_21 to M2M API 40_1 according to an embodiment of the present disclosure.

[1169] (Table 118) Operation response message

[1170] Type = Operation Response VNID=Id_VMN#21 Status = OK

[1171] The operation response message may be the same as the message shown in Table 116 except that the operation indication target is VMNode 30VM_21, for example. Note that the operation response message shown here is an example. VMNode 30VM_21 may send an operation response message including information other than that shown in Table 118 to M2M API 40_1.

[1172] When receiving the operation response message, the M2M API 40_1 sends the operation response message to the M2M application 10_11 (step S2807).

[1173] As described above, the M2M application 10_11 according to the present embodiment can instruct the mobile node to perform an operation in the same procedure as that for the fixed node. As described above, the M2M application 10_11 according to the present embodiment can more easily instruct the mobile node to perform an operation.

[1174] <<6. Other embodiments>>

[1175] The embodiments described above indicate examples. Various changes and applications of the embodiments are possible.

[1176] For example, the control device that controls the information processing device 100, the communication device 200, and the wireless communication device 300 in the above-described embodiments may be realized by a dedicated computer system, or may be realized by a general-purpose computer system.

[1177] For example, the communication program for performing the operation described above is distributed by being stored in a computer-readable recording medium such as an optical disk, a semiconductor memory, a magnetic tape, or a floppy disk. Then, for example, the control device is configured by installing the program in a computer and performing the processing described above. At this time, the control device may be a device (e.g., a personal computer) outside the sending device and the receiving device. The control device may be a device (e.g., a control unit 130, 250, and 350) inside the sending device or the receiving device.

[1178] The communication program described above may be stored in a disk device included in a server device on a network such as the Internet so that the communication program can be downloaded to a computer. The functions described above may be implemented by cooperation of an OS (operating system) and application software. In this case, the portion other than the OS may be stored in a medium and distributed, or the portion other than the OS may be stored in a server device so that the portion may be downloaded to a computer.

[1179] Among the various processes described in the present embodiment, all or part of the processes described as being automatically performed may be manually performed, or all or part of the processes described as being manually performed may be automatically performed by a well-known method. In addition, unless otherwise specifically stated, the processing procedures, specific names, and information including various data and parameters described in the above documents and shown in the drawings may be optionally changed. For example, the various types of information shown in the drawings and tables are not limited to the information shown.

[1180] The components of the illustrated devices are conceptual in function and are not always required to be physically configured as shown. That is, the specific form of distribution and integration of the devices is not limited to the illustrated form, and all or part of them may be functionally or physically distributed and integrated in any unit according to various loads, usage conditions, etc. Note that this configuration by distribution and integration may also be performed dynamically.

[1181] The embodiments described above can be combined appropriately within the range that the processing contents are not contradictory to each other. In addition, the order of the steps shown in the flowcharts and sequence diagrams in the embodiments described above can be changed appropriately.

[1182] For example, the present embodiment can be implemented as any configuration for configuring a device or system, such as a processor used as a system LSI (large scale integration) or the like, a module using multiple processors or the like, a unit using multiple modules or the like, a set obtained by further adding other functions to a unit, etc. (i.e., a configuration of a part of a device).

[1183] Note that in this embodiment, a system refers to a collection of multiple components (devices, modules (components), etc.). It is not important whether all components exist in the same housing. Therefore, multiple devices housed in separate housings and connected via a network and a device in which multiple modules are housed in one housing are both systems.

[1184] For example, the present embodiment may adopt a cloud computing configuration in which one function is shared and processed by multiple devices in collaboration via a network.

[1185] <<7. Conclusion>>

[1186] Although the embodiments of the present disclosure are described above, the technical scope of the present disclosure is not limited to the embodiments themselves, and various modifications can be made within the scope that does not deviate from the gist of the present disclosure. Components in different embodiments and modifications can be appropriately combined.

[1187] The effects in the embodiments described in this specification are merely illustrative and not restrictive. Other effects may exist.

[1188] Note that the present technology can also adopt the following configurations. (1)

[1190] An information processing method, wherein an information processing device executes an M2M application for performing M2M communication with a physical node, the information processing method comprising:

[1191] The information processing device communicates with at least one of a virtual node and a virtual location, wherein:

[1192] The virtual node is a node in which at least one of a function of a physical node as a communication partner of M2M communication and a function of reinforcing the physical node is implemented as a software module, and

[1193] The virtual site is a site where a function of a physical sink that performs wireless communication with a physical node, a function of enhancing the physical sink, and an installation place of the physical sink are implemented as a software module. (2)

[1195] The information processing method according to (1), wherein the information processing device is one of a cloud device and an MEC device. (3)

[1197] The information processing method according to (1) or (2), wherein:

[1198] One of the cloud device and the MEC device functions as the information processing device and executes the M2M application according to an instruction from the management device, and

[1199] The management device determines a device that executes the M2M application according to at least one of a computation load of the M2M application and a communication delay with a physical node that performs the M2M communication. (4)

[1201] The information processing method according to any one of (1) to (3), wherein:

[1202] The physical node has at least one of a sensor function and an actuator function, and

[1203] The M2M application performs at least one of controlling a function through M2M communication and acquiring a measurement result through the function. (5)

[1205] The information processing method according to any one of (1) to (4), wherein:

[1206] The physical node is a mobile node, whose physical location moves and performs wireless communication with a physical destination corresponding to the physical location,

[1207] Regardless of the physical location of the physical node, the M2M application communicates with at least one of a virtual node corresponding to the physical node and a virtual site corresponding to the virtual node to perform M2M communication with the physical node. (6)

[1209] The information processing method according to (5), wherein the mobile node shares a session key with a virtual location corresponding to a physical destination that performs wireless communication with the mobile node. (7)

[1211] The information processing method according to (5) or (6), wherein:

[1212] When a wireless link with the mobile node is disconnected, the physical sink performing wireless communication with the mobile node notifies a virtual location obtained by virtualizing the physical sink of the disconnection of the wireless link, and

[1213] The virtual site receiving the notification of the disconnection of the wireless link deletes the session key shared with the mobile node. (8)

[1215] The information processing method according to any one of (5) to (7), wherein the virtual spot corresponding to the physical destination performing wireless communication with the mobile node notifies a virtual node obtained by virtualizing the mobile node that the virtual spot is connected to the mobile node. (9)

[1217] The information processing method according to any one of (5) to (8), wherein:

[1218] The mobile node notifies the physical sink of the sensing data.

[1219] The physical sink notifies the corresponding virtual location of the sensing data.

[1220] The virtual site stores the sensing data in a database of the MEC server operating as the virtual site.

[1221] The virtual location notifies the sensing data to the virtual node corresponding to the mobile node, and

[1222] The virtual node stores the sensing data in the database of the MEC server operating as the virtual node. (10)

[1224] An information processing method according to any one of (1) to (9), wherein, when an M2M application performs M2M communication with a physical node that satisfies a predetermined condition, at least one of a virtual node obtained by virtualizing the physical node and a virtual location corresponding to the virtual node determines whether the physical node satisfies the predetermined condition. (11)

[1226] The information processing method according to any one of (1) to (10), wherein:

[1227] The M2M application communicates with the physical node using at least one of an M2M API, a lower-level API than the M2M API, and a device API at a lower level than the lower-level API,

[1228] The lower layer API is used in at least one of communication between the M2M API and at least one of the virtual node and the virtual place and communication between the virtual node and the virtual place, and

[1229] The device API is used in the communication between the virtual nodes and the physical nodes. (12)

[1231] An information processing method, wherein an M2M application and a physical node perform M2M communication, the information processing method comprising:

[1232] The physical node communicates with the virtual node via the physical sink; and

[1233] The virtual node communicates with at least one of the virtual location and the M2M application, wherein:

[1234] The virtual node is a node in which at least one of the function of the physical node and the function of reinforcing the physical node is implemented as a software module, and

[1235] The virtual site is a site where a function of a physical sink that performs wireless communication with a physical node, a function of enhancing the physical sink, and an installation place of the physical sink are implemented as a software module. (13)

[1237] An information processing method, wherein an M2M application and a physical sink perform M2M communication, the information processing method comprising:

[1238] communicating, by the physical sink, with at least one of the physical node and the virtual location; and

[1239] The virtual location communicates with at least one of the virtual node and the M2M application, wherein:

[1240] The virtual node is a node in which at least one of the function of the physical node and the function of reinforcing the physical node is implemented as a software module, and

[1241] The virtual site is a site where a function of a physical sink that performs wireless communication with a physical node, a function of enhancing the physical sink, and an installation place of the physical sink are implemented as a software module. (14)

[1243] An information processing device, the information processing device executing an M2M application for performing M2M communication with a physical node,

[1244] The information processing device comprises:

[1245] a control unit communicating with at least one of the virtual node and the virtual location, wherein:

[1246] The virtual node is a node in which at least one of a function of a physical node as a communication partner of M2M communication and a function of reinforcing the physical node is implemented as a software module, and

[1247] The virtual site is a site where a function of a physical sink that performs wireless communication with a physical node, a function of enhancing the physical sink, and an installation place of the physical sink are implemented as a software module. (15)

[1249] The information processing device according to (14), wherein

[1250] The physical node is a mobile node whose physical location moves and performs wireless communication with a physical destination corresponding to the physical location, and

[1251] Regardless of the physical location of the physical node, the M2M application communicates with at least one of a virtual node corresponding to the physical node and a virtual site corresponding to the virtual node to perform M2M communication with the physical node. (16)

[1253] The information processing device according to (15), wherein the mobile node shares the session key with a virtual location corresponding to a physical destination that performs wireless communication with the mobile node. (17)

[1255] The information processing device according to (15) or (16), wherein:

[1256] When a wireless link with the mobile node is disconnected, the physical sink performing wireless communication with the mobile node notifies a virtual location obtained by virtualizing the physical sink of the disconnection of the wireless link, and

[1257] The virtual site receiving the notification of the disconnection of the wireless link deletes the session key shared with the mobile node. (18)

[1259] The information processing device according to any one of (15) to (17), wherein the virtual spot corresponding to the physical destination performing wireless communication with the mobile node notifies the virtual node obtained by virtualizing the mobile node that the virtual spot is connected to the mobile node. (19)

[1261] The information processing device according to any one of (15) to (18), wherein:

[1262] The mobile node notifies the physical sink of the sensing data.

[1263] The physical sink notifies the corresponding virtual location of the sensing data.

[1264] The virtual site stores the sensing data in a database of the MEC server operating as the virtual site.

[1265] The virtual location notifies the sensing data to the virtual node corresponding to the mobile node, and

[1266] The virtual node stores the sensing data in the database of the MEC server operating as the virtual node. (20)

[1268] An information processing device according to any one of (14) to (19), wherein, when an M2M application performs M2M communication with a physical node that satisfies a predetermined condition, at least one of a virtual node obtained by virtualizing the physical node and a virtual location corresponding to the virtual node determines whether the physical node satisfies the predetermined condition.

[1269] Reference Mark List

[1270] 10M2M Application

[1271] 20P Physical Sink

[1272] 20V Virtual Location

[1273] 30 nodes

[1274] 100 Information processing equipment

[1275] 110 Communication unit

[1276] 120, 240, 340 storage units

[1277] 130, 250, 350 control unit

[1278] 200 communication equipment

[1279] 210, 310 antenna units

[1280] 220, 320 wireless communication unit

[1281] 230 Network Communication Unit

[1282] 300 Wireless communication equipment

[1283] 330 Sensor unit

[1284] 350 Control Unit

Claims

1. An information processing method, wherein an information processing device executes an M2M application for performing M2M communication with a physical node, the information processing method comprising: The information processing device communicates with at least one of a virtual node and a virtual location, wherein: The virtual node is a node in which at least one of a function of a physical node as a communication partner of M2M communication and a function of reinforcing the physical node is implemented as a software module, and The virtual site is a site where a function of a physical sink that performs wireless communication with a physical node, a function of enhancing the physical sink, and an installation place of the physical sink are implemented as a software module.

2. The information processing method according to claim 1, wherein: The information processing device is one of a cloud device and a MEC device.

3. The information processing method according to claim 1, wherein: One of the cloud device and the MEC device functions as the information processing device and executes the M2M application according to an instruction from the management device, and The management device determines a device that executes the M2M application according to at least one of a computation load of the M2M application and a communication delay with a physical node that performs M2M communication.

4. The information processing method according to claim 1, wherein: The physical node has at least one of a sensor function and an actuator function, and The M2M application performs at least one of controlling a function through M2M communication and acquiring a measurement result through the function.

5. The information processing method according to claim 1, wherein: The physical node is a mobile node, whose physical location moves and performs wireless communication with a physical destination corresponding to the physical location, Regardless of the physical location of the physical node, the M2M application communicates with at least one of a virtual node corresponding to the physical node and a virtual site corresponding to the virtual node to perform M2M communication with the physical node.

6. The information processing method according to claim 5, wherein: The mobile node shares a session key with a virtual location corresponding to a physical destination that performs wireless communication with the mobile node.

7. The information processing method according to claim 5, wherein: When a wireless link with the mobile node is disconnected, the physical sink performing wireless communication with the mobile node notifies a virtual location obtained by virtualizing the physical sink of the disconnection of the wireless link, and The virtual site receiving the notification of the disconnection of the wireless link deletes the session key shared with the mobile node.

8. The information processing method according to claim 5, wherein: The virtual site corresponding to the physical destination performing wireless communication with the mobile node notifies a virtual node obtained by virtualizing the mobile node that the virtual site is connected to the mobile node.

9. The information processing method according to claim 5, wherein: The mobile node notifies the physical sink of the sensing data. The physical sink notifies the corresponding virtual location of the sensing data. The virtual site stores the sensing data in a database of the MEC server operating as the virtual site. The virtual location notifies the sensing data to the virtual node corresponding to the mobile node, and The virtual node stores the sensing data in the database of the MEC server operating as the virtual node.

10. The information processing method according to claim 1, wherein: When the M2M application performs M2M communication with a physical node satisfying a predetermined condition, at least one of a virtual node obtained by virtualizing the physical node and a virtual site corresponding to the virtual node determines whether the physical node satisfies the predetermined condition.

11. The information processing method according to claim 1, wherein: The M2M application communicates with the physical node using at least one of an M2M API, a lower-level API than the M2M API, and a device API at a lower level than the lower-level API, The lower layer API is used in at least one of communication between the M2M API and at least one of the virtual node and the virtual place and communication between the virtual node and the virtual place, and The device API is used in the communication between the virtual nodes and the physical nodes.

12. An information processing method, wherein an M2M application and a physical node perform M2M communication, the information processing method comprising: The physical node communicates with the virtual node via the physical sink; as well as The virtual node communicates with at least one of the virtual location and the M2M application, wherein: The virtual node is a node in which at least one of the function of the physical node and the function of reinforcing the physical node is implemented as a software module, and The virtual site is a site where a function of a physical sink that performs wireless communication with a physical node, a function of enhancing the physical sink, and an installation place of the physical sink are implemented as a software module.

13. An information processing method, wherein an M2M application and a physical sink perform M2M communication, the information processing method comprising: The physical sink communicates with at least one of the physical node and the virtual location; as well as The virtual location communicates with at least one of the virtual node and the M2M application, wherein: The virtual node is a node in which at least one of the function of the physical node and the function of reinforcing the physical node is implemented as a software module, and The virtual site is a site where a function of a physical sink that performs wireless communication with a physical node, a function of enhancing the physical sink, and an installation place of the physical sink are implemented as a software module.

14. An information processing device, the information processing device executing an M2M application for performing M2M communication with a physical node, The information processing device comprises: a control unit communicating with at least one of the virtual node and the virtual location, wherein: The virtual node is a node in which at least one of a function of a physical node as a communication partner of M2M communication and a function of reinforcing the physical node is implemented as a software module, and The virtual site is a site where a function of a physical sink that performs wireless communication with a physical node, a function of enhancing the physical sink, and an installation place of the physical sink are implemented as a software module.

15. The information processing device according to claim 14, wherein: The physical node is a mobile node whose physical location moves and performs wireless communication with a physical destination corresponding to the physical location, and Regardless of the physical location of the physical node, the M2M application communicates with at least one of a virtual node corresponding to the physical node and a virtual site corresponding to the virtual node to perform M2M communication with the physical node.

16. The information processing device according to claim 15, wherein: The mobile node shares a session key with a virtual location corresponding to a physical destination that performs wireless communication with the mobile node.

17. The information processing device according to claim 15, wherein: When a wireless link with the mobile node is disconnected, the physical sink performing wireless communication with the mobile node notifies a virtual location obtained by virtualizing the physical sink of the disconnection of the wireless link, and The virtual site receiving the notification of the disconnection of the wireless link deletes the session key shared with the mobile node.

18. The information processing device according to claim 15, wherein: The virtual site corresponding to the physical destination performing wireless communication with the mobile node notifies a virtual node obtained by virtualizing the mobile node that the virtual site is connected to the mobile node.

19. The information processing device according to claim 15, wherein: The mobile node notifies the physical sink of the sensing data. The physical sink notifies the corresponding virtual location of the sensing data. The virtual site stores the sensing data in a database of the MEC server operating as the virtual site. The virtual location notifies the sensing data to the virtual node corresponding to the mobile node, and The virtual node stores the sensing data in the database of the MEC server operating as the virtual node.

20. The information processing device according to claim 14, wherein: When the M2M application performs M2M communication with a physical node satisfying a predetermined condition, at least one of a virtual node obtained by virtualizing the physical node and a virtual site corresponding to the virtual node determines whether the physical node satisfies the predetermined condition.

Images