WO2018199523A1 - Method for processing machine to machine communication via public ip network, and apparatus therefor - Google Patents

Abstract

The present invention relates to a private Internet protocol (IP)-based machine to machine communication (M2M) method via a public IP in an M2M system, and an apparatus therefor. An embodiment provides a method and an apparatus in which an M2M device communicates with another M2M device through a public IP network, the method comprising the steps of: transmitting a connection packet for establishing a connection to a relay server through a relay client module and receiving response information for the connection packet for connection establishment, so as to establish a connection with the relay server; when a connection with the relay server is established, transmitting a publish packet including a request message to be transmitted to another M2M device, to the relay server; and receiving, from the relay server, a publish packet including a response message having been generated by the another M2M device in response to the request message.

Description

Method and apparatus for processing IoT through public IP network

The present invention relates to a private IP-based IoT communication method and apparatus through a public IP in a machine to machine communication (M2M) system.

M2M, "Machine to machine communication" or MTC, "Machine type communication" or smart device communication, "Smart Device communication" or "Machine oriented communication" or the Internet of Things, "Internet of Things" is a human communication process Refers to all communication methods in which communication is performed without intervening.

Since MOT typically does not directly perform communication and application control, there is a need for transmitting and receiving methods and procedures in order to exchange messages between objects. In addition, there is a need for a protocol for smooth message exchange between M2M devices.

In particular, according to the popularization of IoT devices, a plurality of things communication devices are used in homes and workplaces, and there are situations in which a plurality of things communication devices that perform the same or similar functions are deployed for a certain purpose.

In this situation, a plurality of things communication devices may be deployed in the same network or may be deployed in different networks. For example, there may be a need for communication between things configured in different private networks.

However, at present, the thing communication network defines only a communication protocol between the thing communication devices existing in the same network, and does not consider communication between the thing communication devices included in different networks.

In particular, when the IoT apparatuses configured in different private IP networks communicate through a public IP network, there is a problem that communication cannot be performed smoothly due to a firewall of the private IP network.

An embodiment devised in the above-described background is to provide a smooth communication method between communication apparatuses configured in different networks.

In addition, an embodiment of the present invention is to provide a method and apparatus for enabling a thing communication device using a private IP to communicate with a thing communication device using an external private IP so that the thing communication device using a private IP can be performed.

One embodiment for solving the above problems is a method for a machine to machine communication (M2M) device to communicate with other M2M devices through a public IP (Internet Protocol) network, to a relay server through a relay client module Transmitting a connection packet for establishing a connection, receiving a response information on the connection packet for establishing a connection, establishing a connection with the relay server, and requesting transmission to another M2M device when the connection with the relay server is established. The method includes transmitting a message to the relay server by including the message in a publish packet and receiving a publish packet from the relay server including a response message generated by another M2M device in response to the request message.

In addition, in one embodiment, a relay server relays communication between machine-to-machine communication (M2M) devices through a public IP (Internet Protocol) network, and establishes a connection setting from a relay client module of each M2M device and another M2M device. Receiving a connection packet for receiving the connection packet, establishing a connection with each of the M2M device and another M2M device, receiving a publish packet including a request message for transmitting from the relay client module of the M2M device to another M2M device, and a request message. Transmitting a publish packet including a publish packet including a response message to the relay client module of another M2M device and a request message from the relay client module of another M2M device, and a publish packet including the response message. Sending to the relay client module of the M2M device It provides a way.

In addition, an embodiment is a machine to machine communication (M2M) device that communicates with other M2M devices through a public IP (Internet Protocol) network, the connection packet for establishing a connection to a relay server through a relay client module When the connection between the control unit and the relay server that establishes a connection with the relay server by receiving response information about the connection packet for connection establishment and connection is established, the request packet for transmission to another M2M device is included in the publish packet. An M2M device including a transmitter for transmitting to a relay server and a request packet for receiving a publish packet including a response message generated by another M2M device from a relay server is provided.

In addition, an embodiment is a relay server for relaying communication between machine to machine communication (M2M) devices through a public IP (Internet Protocol) network, the connection for establishing the connection from the relay client module of each of the M2M device and other M2M devices A receiving unit for receiving a packet, a receiving unit for receiving a publish packet including a control unit for establishing a connection with each of the M2M device and another M2M device, and a request message for transmitting from the relay client module of the M2M device to the other M2M device. And a transmitter for transmitting a publish packet to a relay client module of another M2M device, wherein the receiver further receives a publish packet including a response message for a request message from a relay client module of another M2M device. Relay client module containing the publish packet containing the M2M device Provides a relay server for further transmission.

The present disclosure provides an effect that a plurality of things communication devices using different private IPs can send and receive messages smoothly through a public IP.

In addition, the present disclosure provides an effect of transmitting and receiving data as needed without restriction of a public or private IP between the thing communication devices configured in different networks.

1 is a diagram illustrating an M2M system from a high level functional point of view.

2 is a diagram illustrating in more detail an M2M system configuration diagram according to an embodiment.

3 is a diagram exemplarily illustrating a procedure of transmitting a request message and corresponding response information in an M2M system.

4 illustrates a functional structure of a common service entity according to an embodiment.

5 is a view for explaining a problem that may occur when using a public IP and a private IP.

FIG. 6 is a diagram illustrating a problem that may occur when communication is performed between M2M devices using private IP via a public IP network.

7 is a diagram illustrating an operation of an M2M device according to an embodiment.

8 is a diagram for describing an operation of a relay server according to an exemplary embodiment.

9 is a diagram exemplarily illustrating a structure in which a relay server is integrated with an M2M device according to an embodiment.

10 is a diagram illustrating a structure in which a relay server is configured independently according to an embodiment.

11 is a diagram illustrating a procedure for establishing a connection with a relay server using a connection packet according to an embodiment.

12 is a diagram for describing a procedure of establishing a connection with a relay server using a connection packet according to another embodiment.

FIG. 13 is a diagram for describing a procedure of delivering a message using a publish packet, according to an exemplary embodiment.

14 is a diagram for describing a procedure of delivering a message using a publish packet, according to another exemplary embodiment.

15 illustrates a structure of a connection packet format and a fixed header according to an embodiment.

16 illustrates a structure of a connection packet variable header according to an embodiment.

17 illustrates a structure of a connection packet payload according to an embodiment.

18 is a diagram illustrating a connection confirmation packet format and the structure of each header according to an embodiment.

19 illustrates a structure of a subscribe packet format, a fixed header, a variable header, and a payload according to an embodiment.

20 illustrates a structure of a subscribe confirmation packet format, fixed header, variable header, and payload according to an embodiment.

21 is a diagram illustrating a publish packet format, a fixed header, and a variable header structure according to an embodiment.

FIG. 22 is a diagram illustrating a publish confirmation packet format, a fixed header, and a variable header structure according to an embodiment.

23 is a diagram illustrating a structure of an M2M device according to one embodiment.

24 is a diagram illustrating a structure of a relay server according to an embodiment.

Hereinafter, some embodiments of the present invention will be described in detail with reference to the accompanying drawings. In adding reference numerals to the components of each drawing, it should be noted that the same reference numerals are assigned to the same elements as much as possible even though they are shown in different drawings. In addition, in describing the present invention, when it is determined that the detailed description of the related well-known configuration or function may obscure the gist of the present invention, the detailed description thereof will be omitted.

In addition, in describing the component of this invention, terms, such as 1st, 2nd, A, B, (a), (b), can be used. These terms are only for distinguishing the components from other components, and the nature, order or order of the components are not limited by the terms. If a component is described as being "connected", "coupled" or "connected" to another component, that component may be directly connected or connected to that other component, but between components It will be understood that may be "connected", "coupled" or "connected".

Embodiments of the present invention will be described based on communication of things. IoT can be variously referred to as Machine to Machine communication (M2M), Machine Type Communication (MTC), Internet of Things (IoT), Smart Device Communication (SDC), or Machine Oriented Communication. Can be. Recently, oneM2M has presented many technical matters related to IoT. The thing communication refers to various communication in which a communication is made without a person intervening in a communication process. IoT is the energy sector, the enterprise sector, the healthcare sector, the public services sector, the residential sector, the retail sector, the transportation sector, and others. It is divided into fields. The present invention includes the above fields, and can be applied to other fields.

1 illustrates an M2M system according to an embodiment from a high level functional perspective.

Application Entity (AE) 110 provides application service logic for an end-to-end M2M solution. For example, it may be a collective tracking application such as a vehicle, a remote blood sugar monitoring application, or a remote power metering and controlling application.

Common Services Entity (CSE) 120 includes energy, enterprise, healthcare, public services, residential, retail This is a collective service function that is commonly required in the field of transportation, transportation, and other fields.

This service function is exposed to other functions through Reference Points Mca and Mcc, and uses the base network service using the reference point Mcn. An example of a common service entity may be data management, device management, M2M subscription management, location service, or the like. The subfunctions provided by the CSE can be logically understood as Common Service Functions (CSFs). Some of the CSFs in the CSE of the oneM2M node may be mandatory and some may be optional. Similarly, sub-functions within the CSF may be mandatory or optional.

Underlying Network Services Function (NSF) 130 provides a service to a common service entity. Examples of services include device management, location services and device triggering.

Reference Points are supported by Common Service Entities (CSEs). Mca Reference Points are reference points for providing communication between application objects and Common Service Entities. The Mcc reference point is a reference point for providing communication thing communication between two common service entities. Mcn reference point is a reference point for providing the communication between the common service entity and one network service entity.

More specifically, the Mca reference point allows one application entity (AE) to use the services supported by the common service entity. Services provided through the Mca reference point are dependent on the functionality provided by the common service entity, and the application entity and the common service entity can exist in the same physical entity or in separate physical entities. The Mcc reference point makes such use available to common service entities that wish to use the services of other common service entities that provide the necessary functionality. Services provided through the Mcc reference point depend on the functionality provided by the common service entity. Mcc reference points may be supported between different M2M nodes. The Mcn reference point enables such use for common service entities that wish to use service entities in the underlying network that provide the necessary functionality, which provides services other than transport and connectivity. An instance of the Mcn reference point is implemented dependent on the services provided by the underlying network. Information exchange between two physical M2M nodes may use transport and connectivity services of an underlying network providing basic services.

In this specification, a common service entity may be described as a CSE, and a network service entity may be described as a network service entity (NSE). In addition, the M2M device in the present specification means a CSE or AE, or means a device including the CSE or AE, and means a device or a terminal constituting the M2M system.

2 is a diagram illustrating in more detail an M2M system configuration diagram according to an embodiment.

Referring to FIG. 2, an infrastructure node 250 performs a server function essential for providing M2M communication. The base node 250 is composed of a base node application entity (AE) 252 and a base node common service entity (CSE) 254. The base node common service entity 254 is configured using various resources. 252 and 254 are distinguished through Mca reference points, and are required for MSOs, especially request messages for creating, deleting, updating, retrieving, and notifying scheduler resources. It is used to construct and process response messages.

The relay node 200 relays M2M communication or Internet of Things, IoT communication functions of the application service node 220 and the base node 250. The relay node 200 includes a relay node application object 202 and a relay node common service object 204. The relay node common service entity 204 is configured using various resources. 202 and 204 are distinguished using Mca reference points, and 254 and 204 are distinguished using Mcc reference points, and messages necessary for MOT communication, in particular, create, delete, update, and Used to construct and process request and response messages to retrieve and notify.

The application service node 210 may be composed of an application object 212 and a relay node common service object 214. The application object 212 handles application functions required for the purpose of the device. The common service object 214 of the application service node 210 is configured using various resources. 212 and 214 are distinguished by Mca reference points, and 214 and 254 are distinguished by Mcc reference points, and messages necessary for MOT, in particular, create, delete, update, and Used to construct and process request and response messages to retrieve and notify. On the other hand, the application service node 220 may perform a thing communication function with the base node 250 through the relay node 200. The difference between 210 and 220 is that the communication interface constituting the node is different. For example, 220 communicates with 100 through 200 using an interface capable of ultra short-range communication such as Bluetooth, ZigBee, Zwave, and WiFi. In contrast, the 210 communicates with the 250 using a communication interface such as 3G, LTE, 5G, Ethernet, Gigabit Ethernet, or ADSL.

The application-only nodes 230 and 240 do not have a common service object, and are intended to communicate with only the application object 242. 230 is a case of communicating with 250 using a communication interface such as 3G, LTE, Ethernet, Gigabit Ethernet, ADSL, etc., 240 is a case of 200 through 250 using an interface capable of ultra short-range communication such as Bluetooth, ZigBee, Zwave, and WiFi. Communicate with

As described in FIG. 2, the M2M system may be configured with at least one or more of a base node, a relay node, an application service node, and an application-only node, and each node may be configured to include a CSE or an AE. The CSE and the AE may communicate with other CSEs or AEs through their respective reference points.

Referring to FIG. 3, the originator 300 transmits a request message to a receiver 310 (S320). The sender 300 and the receiver 310 may each be M2M devices, and may be CSE or AE as described above. In addition, sender 300 and receiver 310 may be nodes or servers or devices that include CSE or AE.

The request message may include one or more parameters. For example, the request message may include mandatory and optional parameters. For example, the From parameter, the To parameter, the Request Identifier parameter, and the Operation parameter are included as essential parameters. The From parameter contains information about the sender who sends the message, and the To parameter contains information about the recipient who receives the message. The Request Identifier parameter contains unique identification information for identifying the corresponding request message. In addition, the Operation parameter includes information for identifying the operation requested in the request message. The operation parameter may be set to any one of Create, Retrieve, Update, Delete, and Notify. In addition, optional parameters may be added to control various operations of the request message. For example, an optional parameter of Response Type can block the receiver's handling, blockingRequest, non-BlockingRequestSynch, non-BlockingRequestAsynch, and flexBlocking. Can be specified.

When the request message is received, the receiver 310 performs an operation for processing the request message (S330). For example, the receiver 310 may check whether the sender 300 that has sent the request message has the authority for the request. When it is determined that the sender 300 has the authority for the request, the sender 300 processes the request message after checking whether the requested resource exists. Alternatively, the receiver 310 may perform a corresponding operation according to the operation parameter of the request message. For example, when an operation parameter is set to creation and a subscription function is set to instruct the sender 300 when a change, addition, or deletion of specific data occurs, the receiver 310 receives subscription information. When an event such as a change, addition, deletion, etc. occurs in the data corresponding to the subscription information, the caller 300 may be notified to the caller 300.

The receiver 310 generates the processing result information according to the request operation and includes it in the response message and transmits it to the sender 300 (S340). Operation S340 may be performed before operation S330. That is, when the receiver 310 receives the request message, the receiver 310 generates an ACK response message indicating the simple reception of the request message and transmits it to the sender 300, and then performs the step S330 to process the request message.

4 is a diagram for configuring a common service entity according to an embodiment of the present invention. 4 includes a processing function of identification information.

The functions provided by the common service entity can be summarized as shown in FIG. 4 by addressing & identification, application and service layer management, data management & storage, location, Security, Communication Management / Delivery Handling, Registration, Service Session Management, Device Management, Subscription / Notification, Connection Management (Connectivity Management), Discovery, Service Charging / Accounting, Network Service Exposure / Service Execution and Triggering, Group Management.

Each function is as follows.

Application and Service Layer Management (ASM) is responsible for managing the AEs and CSEs of ADN, ASN, MN, and IN, including the configuration, troubleshoot, upgrade capabilities, and upgrades of AEs. .

Communication Management and Delivery Handling (CMDH) is responsible for communication between different CSEs, AEs, and NSEs. The CMDH is responsible for storing the communication request at what time using which communication connection (CSE-CSE communication), when it is needed and when it is authorized, and when delivery of the communication is subsequently delayed. CMDH is performed according to the provisioned policies and delivery handling parameters specific to each request for communication. In communication using the underlying network data transmission service, the underlying network may support the same forwarding handling function. In this case, the CMDH can use the underlying network and can act as a front end that accesses the same forwarding handling capabilities for the underlying network.

Data Management and Repository (DMR) allows M2M applications to exchange data with other entities. The DMR CSF provides data storage space and the ability to coordinate it. It also includes the ability to collect and combine large amounts of data, convert the data into a specific format, or store the data for analysis and semantic processing. "Data" may refer to raw data that is transparently extracted from an M2M device or may mean data that has been processed or calculated or combined by an M2M entity. Collecting large amounts of data constitutes what is known as big data storage.

The Device Management (DMG) CSF is responsible for managing device functions of devices in MNs, device nodes, and M2M local area networks. Enable device management to provide one or more of the following features: It includes installation and setting of application software, configuration setting and provisioning, firmware update, logging and monitoring and analysis, topology management of local network, and devices in local network management.

DIS The CSF is responsible for retrieving information and resources that correspond to the permissions granted within a given scope and topic (including those granted by M2M service subscriptions) and within the scope of the originator's request. The sender can be an application or another CSE. The scope of the search can be one CSE or multiple CSEs. The search result is sent to the caller.

Group Management (GMG) handles groups associated with the request. Requests are sent for the management of groups and their membership, and are also responsible for the bulk operations supported by the group. When you add or remove members from a group, you need to make sure that the members conform to the group's purpose. Bulk operations include reading, writing, subscribing, informing, and device management. Requests or subscriptions are made through a group, and the group is responsible for combining these requests and notifications. Members of the group have the same role for access to resources. In this case, access control is by group. If the underlying network provides broadcasting and multicasting capabilities, the GMG CSF should take advantage of these features.

LOC (Location) CSF enables M2M AEs to acquire geographic location information of M2M nodes (eg, ASNs, MNs) for location-based services. Such location information may be requested from M2M AEs that exist within the same or different M2M nodes.

Network Service Exposure (NSE) CSF manages communication with the underlying network to access network service functions through Mcn reference points in an available or supportable manner for service requests from M2M systems on behalf of M2M applications. The NSE CSF hides other CSFs and AFs from the specific technologies and mechanisms supported in the underlying network. Network service functions provided from the underlying network include, but are not limited to, device triggering, small data transfer, location notification, policy rule settings, location query, IMS service, device management, and the like. These features do not include general transport services

REG (Registration) is responsible for handling an application or other CSE to register with the CSE, to allow the registration of an entity that wants to use the services provided by the CSE. The REG CSF handles the registration of the device's properties / properties as well as the device's registration with the CSE.

Security (SEC) provides sensitive data handling, security operations, security association settings, authorization and access control, and identity protection that require attention. Sensitive data handling provided by the SEC CSF provides protection for local credentials that require security during storage and manipulation. Sensitive data handling also uses security algorithms. This feature supports a secure environment with various cryptographic techniques. The security operations function provides the following functions: first, it creates and operates the security environment dedicated to be supported by the sensitive data handling function. It also supports post-provisioning of root credentials protected in a secure environment, and supports the provisioning and operation of subscriptions related to M2M services and M2M application services. The security association configuration feature establishes a security association between M2M nodes to enable confidentiality, integration, authentication, and authorization. Authorization and access control controls service and data access to authorized objects according to provisioned security policies and assigned roles. The unique identifier of the entity is used for authorization, and the identity protection feature can provide anonymity, which acts as a temporary identifier so that it is not linked to the actual identifying information associated with the entity or user.

Service Charging and Accounting (SCA) provides the charging function of the service layer. It supports different charging models including online charging and offline charging. The SCA CSF secures billable events, stores information, and generates billing records and billing information. The SCA CSF can interact with the charging system of the underlying network. However, the SCA CSF is responsible for generating and recording billing information at the final service level. The SCA CSF of the base node or service layer charging server is responsible for handling the charging information for charging.

Service Session Management (SSM) CSF manages M2M service sessions, which are end-to-end service layer connections. The SSM CSF manages M2M service sessions between M2M applications, or between M2M applications and CSEs, or between CSEs. The management of M2M service sessions includes session state management, session authentication and establishment, management of underlying network connections and services associated with the session, coordination of session extensions in the CSE's multi-hop cse, exchange of information between session ends, and session termination. Include. The SSM CSF uses the CMDH CSF in the local CSE to send and receive messages to / from the next hop CSE or application within a given M2M service session. The SSM CSF uses the SEC CSF for session management related to the security credentials and authentication of session participants. The SSM CSF generates session-specific billing events and also communicates with the SCA CSF in the local CSE.

Subscription and Notification (SUB) provides a notification to keep a subscription and tracks resource changes (eg, deletion of resources). Subscriptions to resources are initiated by the M2M AE or CSE and are granted access by the hosting CSE. During an active subscription, the hosting CSE sends a notification to the address the resource subscriber wants to receive when a change in the subscribed resource occurs.

4 and the description thereof are embodiments for implementing a common service entity and the present invention is not limited thereto.

Meanwhile, an identifier applicable to the present embodiments will be described as follows. M2M identifiers include M2M Service Provider Identifier (M2M-SP-ID), Application Instance Identifier (App-Inst-ID), Application Identifier (App-ID), CSE Identifier (CSE-ID), M2M-Node-ID (M2M Node Identifier / Device Identifier), M2M Service Subscription Identifier (M2M-Sub-ID), and Request Identifier (M2M-Request-ID).

oneM2M is a requirement that must be met to implement the system. Overall System Requirements, Management Requirements, Data Model & Semantics Requirements, Security Requirements Requirements, Charging Requirements, and Operational Requirements.

In the present specification, a description will be given of M2M system technology, in particular, oneM2M service platform technology. However, this description is not limited to the M2M service platform technology, and is applicable to all systems and structures that provide device-to-device communication, that is, thing communication, and communication operations occurring in these systems.

In addition, the M2M device in the present specification will be described by describing the various nodes including the above-described AE, CSE, NSE, etc., and for the sake of understanding, the description will be made based on the hosting CSE. no. That is, the M2M device refers to a component device constituting the M2M system, and refers to various nodes, devices, entities, etc. that receive a request message, perform a processing thereof, and transmit a response message.

FIG. 5 is a diagram illustrating a problem that may occur when using a public IP and a private IP, and FIG. 6 may occur when communicating between M2M devices using a private IP via a public IP network. It is a figure for demonstrating a problem.

5 and 6, the M2M devices 500 and 550 may be configured in different network networks.

For example, the M2M device # 1 500 may be configured in a private IP network, and the M2M device # 2 550 may be configured in a public IP network. In this case, the M2M device # 1 500 is connected to the M2M device # 2 550 through TCP / IP through a firewall to perform communication.

As another example, the M2M device # 1 500 and the M2M device # 2 550 are configured in different private IP networks, and are connected through TCP / IP through a firewall to perform communication.

However, in both cases described above, communication may not be performed smoothly due to a communication problem between the private IP network and the public IP network. For example, the M2M device # 2 550 using the public IP may not start communication when communicating with the M2M device # 1 500 using the private IP. In addition, there is a problem in that no M2M device can start communication when performing communication between public M2M devices 500 and 550 using a private IP.

This is because the communication start packet in the private IP network is communicated to the public IP network, but the communication start packet in the public IP network is not delivered to the private IP network. That is, due to the firewall, a packet through the public IP network may not enter the private IP network, which may cause a problem in that a packet for starting communication cannot be delivered.

Therefore, in order to communicate with an M2M device using a public IP, the M2M device using the private IP has a problem that communication is possible only when starting communication in the M2M device using the private IP. In addition, there is a problem that neither M2M devices using the private IP can initiate communication through the public IP.

In order to solve this problem, the present disclosure proposes a specific method of performing a communication of things by a private IP based M2M device via a public IP in an M2M system. In particular, it presents a detailed procedure for the M2M device using the public IP to communicate with the M2M device using the private IP, and presents a specific procedure for performing communication of things between the M2M device using the private IP.

The M2M device described below refers to an entity using a private IP or a public IP, and another M2M device that exchanges messages with the corresponding M2M device also refers to an entity using a private IP or public IP. However, it is assumed that the M2M device and the other M2M devices are configured at locations causing the problems described above by the public IP network. For example, when the M2M device uses a private IP, another M2M device may use a public IP or use a private IP different from the M2M device. In contrast, when the M2M device uses a public IP, another M2M device may use a private IP.

Meanwhile, the relay server in the present specification means an entity for transmitting a message transmitted by the M2M device or another M2M device and may include a relay module, a delivery server, a relay protocol server, and the like. In addition, the relay server may operate based on various protocols for delivering messages of M2M devices. For example, the relay server may operate with a message queuing telemetry transport (MQTT) based protocol. That is, the relay server may mean an MQTT module, an MQTT server, or the like. Likewise, the relay client module may mean an MQTT client module.

Hereinafter, operations of the M2M device and the relay server will be described with reference to the drawings.

7 is a diagram illustrating an operation of an M2M device according to an embodiment.

Referring to FIG. 7, a machine to machine communication (M2M) device transmits a connection packet for establishing a connection to a relay server through a relay client module, and receives response information for the connection packet for establishing a connection with the relay server. A step of establishing a connection may be performed (S700). For example, an M2M device is connected to another M2M device using another private IP via a public IP network, or another M2M device using a private IP or another M2M device using a private IP (when the M2M device uses public IP). In order to perform communication, the connection to the relay server may be set first.

To this end, the M2M device may transmit a connection packet for establishing a connection with the relay server to the relay server, and receive a connection confirmation packet including response information about the connection packet from the relay server. In this case, the M2M device may transmit and receive a connection packet and a connection confirmation packet through a relay client module connected to the M2M device. The M2M device may receive a connection confirmation packet and perform connection establishment. Meanwhile, the relay client module may be a module configured inside the M2M device when the M2M device is a node, or may be a separate module configured in the same node when the M2M device is an AE or CSE. In the present specification, an M2M device is described as a node including an AE or CSE and a relay client module. However, the present disclosure is not limited thereto, and the present disclosure may be equally applied under the assumption that each entity is associated with a relay client module. have.

Alternatively, when the M2M device receives the connection confirmation packet, the M2M device may transmit a subscription packet to the relay server and receive a subscription confirmation packet thereto. The subscription packet may include identification information for identifying the AE or CSE of the corresponding M2M device in the relay server. The M2M device may receive a subscription confirmation packet and perform connection establishment.

Meanwhile, the connection packet between the relay server and the relay client module may be configured in the following format.

For example, the concatenated packet may consist of two bytes of fixed header, variable header and payload area. The variable header may include a protocol name field, a protocol level field, a connection flag field, and a keep alive field, and the payload region may include client module identifier information.

In addition, the relay server may be configured independently from the middle node and the infrastructure node that is a node constituting the M2M system. In this case, the middle node and the infrastructure node may communicate with an independently configured relay server using the relay client module.

Alternatively, the relay server may be configured in the middle node or the infrastructure node which is a node constituting the M2M system. Even in this case, a relay client module for communicating with each entity configured in the relay server and the middle node or infrastructure node may be configured in each node.

Meanwhile, the connection establishment procedure may be performed in the same manner with other M2M devices for communicating with the M2M device. For example, another M2M device may establish a connection with the relay server through a procedure for transmitting and receiving a connection packet and a connection confirmation packet. Alternatively, the other M2M device may perform a connection packet and a connection confirmation packet transmission / reception procedure with the relay server, and establish a connection through the transmission and reception of a subscription packet and a subscription confirmation packet.

When the connection with the relay server is established, the M2M device may include a request message for transmission to another M2M device in a publish packet and transmit it to the relay server (S710).

For example, when the M2M device establishes a connection with the relay server and completes the connection setting, the M2M device transmits a request message for sending to another M2M device in the publish packet to the relay server. The publish packet may include information indicating that the message is a thing communication message, information indicating a message type (request or response), identification information of the sender, and identification information of the receiver.

Meanwhile, the publish packet includes a fixed header, a variable header, and a payload region, and the fixed header includes a QoS level field, a duplicate transmission flag field, and a packet type field, which include information on the QoS level of the packet or relay protocol. The variable header may include a topic name field and a packet identification field. The payload area may include a request message and request information may be included in the request message. The request identification information may be included in a response message later to identify information on which request message the response message is a response to.

If necessary, the M2M device may receive a publish confirmation packet from the relay server including response information about the publish packet. The publish confirmation packet may include information on whether the publish packet is normally received.

The M2M device may perform a step of receiving a publish packet including a response message generated by another M2M device with respect to the request message from the relay server (S720).

For example, the relay server may transmit the publish packet in step S710 to another M2M device, and may transmit a publish packet including a response message received from another M2M device to the M2M device. Accordingly, the M2M device may receive a publish packet including a response message to the request message from the relay server through the relay client module. If necessary, the M2M device transmits acknowledgment information about the publish packet including the response message to the relay server in the publish acknowledgment packet. The publish confirmation packet may include information on whether the publish packet is normally received. In addition, as described above, the response message may be included in the payload of the publish packet, and the response message may include request identification information and response status code information. The request identification information may be set to the same value as the request message to indicate which request message the response message includes. The response status code contains a code value for the processing result of the procedure required in the corresponding request message. For example, when the processing for the corresponding request message is successful, the response result code may be set to '2000', which means a code value indicating the processing success.

Packet exchange between the relay client module and the relay server may be performed according to the relay protocol, and data exchange between the relay client module and the M2M entity (ex, AE or CSE) may be performed by the M2M protocol.

In addition, since data exchange between M2M devices and other M2M devices is established after establishing a connection with a relay server, each M2M device is based on a connection setting even when each M2M device is located in a different network or via a public IP network. You can start communicating.

Therefore, the above problem of initiating communication from the public IP network to the private IP network can be solved according to the present embodiment.

The above description may be equally performed in other M2M devices.

8 is a diagram for describing an operation of a relay server according to an exemplary embodiment.

Referring to FIG. 8, the relay server may receive a connection packet for connection establishment from a relay client module of each of the M2M device and another M2M device, and may establish a connection with each of the M2M device and another M2M device. (S800).

For example, the relay server may receive a connection packet from M2M devices that want to perform communication through the relay server, and perform connection establishment based on the connection packet. The connection packet may be received from a relay client module that may be configured in each M2M device. Also, the relay server may transmit a connection confirmation packet including response information about the connection packet to each M2M device.

Alternatively, the relay server may receive a subscription packet from each M2M device after receiving a connection packet and transmitting a connection confirmation packet, and transmit a subscription confirmation packet for the subscription packet to each M2M device to perform connection establishment. For example, the subscription packet may include identification information for the M2M device requesting connection establishment. Alternatively, the subscription packet may include identification information related to transmission of a request message of the M2M device requesting connection establishment and information on identification information related to reception of a response message. Of course, the information indicating that the M2M device is a M2M packet using the M2M network may be included.

Meanwhile, the relay server may be configured independently of the middle node and the infrastructure node, which are nodes constituting the M2M system. In this case, the middle node and the infrastructure node may communicate with an independently configured relay server using the relay client module.

Alternatively, the relay server may be configured in the middle node or the infrastructure node which is a node constituting the M2M system. Even in this case, a relay client module for communicating with each entity configured in the relay server and the middle node or infrastructure node may be configured in each node.

The relay server may perform a step of receiving a publish packet including a request message for transmitting to another M2M device from the relay client module of the M2M device (S810). For example, the relay server may receive a request message for the M2M device to transmit to another M2M device from the relay client module through a publish packet.

For example, the publish packet may include information indicating that the message is a thing communication message, information indicating a message type (request or response), identification information of the sender, and identification information of the receiver. Alternatively, the publish packet is composed of a fixed header, a variable header and a payload area, the fixed header includes a QoS level field, information on the QoS level of the packet or relay protocol, a duplicate transmission flag field and a packet type field, The variable header may include a topic name field and a packet identification field.

If necessary, the relay server may transmit a publish confirmation packet including response information to the publish packet to the M2M device. The publish confirmation packet may include information on whether the publish packet is normally received.

The relay server may perform a step of transmitting a publish packet including a request message to a relay client module of another M2M device (S820). For example, when a publish packet is received, the relay server checks identification information of another target M2M device indicated by the publish packet, and transmits a publish packet including a request message to a relay client module of another connected M2M device. Can be. That is, when a publish packet is received from the relay client module, the relay server transmits the packet to the relay client module at the receiver by referring to the topic name.

For example, the relay server may transmit the publish packet to another M2M device which is a receiver of the request message according to the identification information of another M2M device confirmed through the subscription packet using the publish packet received from the M2M device. Since the other M2M device performs a connection setup process with the relay server before receiving the publish packet, even if the relay server uses a public IP network, it may transmit a publish packet including a request message to another M2M device using a private IP.

If necessary, the relay server may receive a publish acknowledgment packet instructing receipt of a publish packet including a request message from another M2M device. The relay client module of another M2M device may transmit the request message of the publish packet to the AE or CSE of the M2M device.

The relay server may perform a step of receiving a publish packet including a response message for a request message from a relay client module of another M2M device (S830). The AE or CSE of another M2M device may transmit a response message processing the request message to another M2M device, and the relay client module of the other M2M device may include the response message in a publish packet and transmit the response message to the relay server. Accordingly, the relay server may receive a publish packet including a response message from the relay client module of another M2M device.

If necessary, the relay server may transmit a publish confirmation packet for the publish packet to another M2M device.

The relay server may perform a step of transmitting the publish packet including the response message to the relay client module of the M2M device (S840). The relay server may check the receiver identification information of the publish packet including the response message, and transmit the publish packet including the response message to the M2M device indicated by the corresponding receiver identification information.

If necessary, the relay server may receive a publish confirmation packet from the M2M device. The relay client module of the M2M device receives the publish packet from the relay server and delivers a response message included in the publish packet to the AE or CSE of the M2M device. In addition, the relay client module of the M2M device may transmit a publish acknowledgment packet indicating whether to normally receive the publish packet to the relay server.

Through the above operation, the relay server may control the M2M device and another M2M device to perform a smooth communication by relaying an operation of transmitting and receiving data through a public IP network. As described above, the relay server may be configured to be included in the infrastructure node or the middle node, or may be configured independently to communicate with the infrastructure node or the middle node.

Meanwhile, each operation in FIGS. 7 and 8 may be separated from each step as necessary, or the order thereof may be changed, and a part of the above description may be added as a step.

Hereinafter, various more detailed embodiments and procedures according to the present disclosure described above will be described in detail with reference to the drawings.

FIG. 9 is a diagram illustrating a structure in which a relay server is integrated with an M2M device according to an embodiment, and FIG. 10 is a diagram illustrating a structure in which a relay server is independently configured according to an embodiment. .

Referring to FIG. 9, the relay server may be included in a middle node or an infrastructure node. In this case, the M2M device of the ADN or ASN may exchange packets with the relay server through the relay client module. Similarly, the middle node may send and receive packets with the relay server of the middle node or the infrastructure node through the relay client module.

Referring to FIG. 10, the relay server may be configured independently of a node of the M2M system. In this case, the relay server may transmit and receive a packet through a relay client module and at least one of a node such as ASN and ADN, a middle node, and an infrastructure node.

Alternatively, the relay server may be configured independently, and the infrastructure node may be configured to include a relay server. In this case, a node such as a middle node, an ASN, ADN, and the relay server may transmit and receive a packet through a relay client protocol, and communicate with the infrastructure node through a packet exchange between the relay server.

As such, the relay server may be configured to coexist with or independently of the M2M system to perform the aforementioned packet exchange operation.

In the following description, the M2M device may be described as an AE or a caller as needed, and another M2M device may be described as a CSE or a receiver.

11 is a diagram illustrating a procedure for establishing a connection with a relay server using a connection packet according to an embodiment.

Referring to FIG. 11, the AE 1100 performs initial access to the relay client module 1110 to access the relay server 1150 (S1101). The relay client module 1110 transmits a connection packet to the relay server 1150 (S1102).

Similarly, the CSE 1190 also performs initial access to the relay client module 1180 to establish a connection (S1103), and the relay client module 1180 transmits a connection packet to the relay server 1150 (S1104).

At this time, the AE 1100, the CSE 1190 and the relay client modules 1110 and 1180 may use the M2M protocol instead of the relay protocol domain, and the relay client modules 1110 and 1180 and the relay server 1150 may be used. The relay protocol domain can be used. For example, the M2M message according to the M2M protocol may include a request message and a response message, and the M2M message may be expressed in Extensible Markup Language (XML), JavaScript Object Notation (JSON), and Concise Binary Object Representation (CBOR). At least one may be used. Accordingly, the relay client modules 1110 and 1180 may convert the M2M message into the relay protocol. For example, the Topic Name of the subscription packet may be set to 'oneM2M / req / + / SP-relative-AE-ID' or 'oneM2M / resp / SP-relative-AE-ID / +'. Similarly, the Topic Filter of the subscription packet may be set to '/ oneM2M / req / + / SP-relative-AE-ID' or '/ oneM2M / resp / SP-relative-AE-ID / +'.

Subsequently, the relay client module 1110 of the AE 1100 transmits a subscription packet to the relay server 1150 (S1105), and the relay client module 1180 of the CSE 1190 also subscribes to the relay server 1150. The packet is transmitted (S1106).

The subscription packet may include information indicating the M2M system, AE identification information related to the request message, and AE identification information related to the response message. Similarly, the subscription packet on the CSE 1190 side may include information indicating the M2M system, CSE identification information related to the request message, and CSE identification information related to the response message.

Through this procedure, the AE 1100 and the CSE 1190 may establish connection with the relay server 1150.

12 is a diagram for describing a procedure of establishing a connection with a relay server using a connection packet according to another embodiment.

Referring to FIG. 12, the relay server 1150 may transmit an acknowledgment packet (ACK) for the packet during the connection establishment process. For example, the AE 1100 performs initial access to the relay client module 1110 to access the relay server 1150 (S1210). The relay client module 1110 transmits a connection packet to the relay server 1150 (S1220).

The relay server 1150 may transmit a connection confirmation packet CONNACK to the relay client module 1110 including information indicating whether the connection packet is normally received (S1230).

Similarly, the CSE 1190 also performs initial access to the relay client module 1180 for connection establishment (S1240), and the relay client module 1180 transmits a connection packet to the relay server 1150 (S1250). The relay server 1150 may transmit a connection confirmation packet CONNACK to the relay client module 1180 including information indicating whether the connection packet is normally received (S1260).

In this case, the AE 1100, the CSE 1190, and the relay client modules 1110 and 1180 may use the M2M protocol instead of the relay protocol domain, and the relay client modules 1110 and 1180 and the relay server 1150 may relay. Protocol domains can be used. For example, the M2M message according to the M2M protocol may include a request message and a response message, and the M2M message may be expressed in Extensible Markup Language (XML), JavaScript Object Notation (JSON), and Concise Binary Object Representation (CBOR). At least one may be used. Accordingly, the relay client modules 1110 and 1180 may convert the M2M message into the relay protocol. For example, the Topic Name of the subscription packet may be set to 'oneM2M / req / + / SP-relative-AE-ID' or 'oneM2M / resp / SP-relative-AE-ID / +'. Similarly, the Topic Filter of the subscription packet may be set to '/ oneM2M / req / + / SP-relative-AE-ID' or '/ oneM2M / resp / SP-relative-AE-ID / +'.

Subsequently, the relay client module 1110 of the AE 1100 transmits a subscription packet to the relay server 1150 (S1270), and the relay client module 1180 of the CSE 1190 also subscribes to the relay server 1150. The packet is transmitted (S1280). As described above, the subscription packet may include information indicating the M2M system, AE identification information related to the request message, and AE identification information related to the response message. Similarly, the subscription packet on the CSE 1190 side may include information indicating the M2M system, CSE identification information related to the request message, and CSE identification information related to the response message.

In addition, the relay server 1150 may transmit a subscription confirmation packet SUBACK including information indicating whether the connection packet is normally received to the relay client module 1110 of the AE 1100 (S1290). Likewise, the relay server 1150 may transmit a subscription confirmation packet SUBACK including information indicating whether the subscription packet is normally received to the relay client module 1180 of the CSE 1180 (S1295).

Through this procedure, the AE 1100 and the CSE 1190 may establish connection with the relay server 1150.

When the connection setup is completed, the M2M device may communicate with the relay server using the publish packet.

FIG. 13 is a diagram for describing a procedure of delivering a message using a publish packet, according to an exemplary embodiment.

Referring to FIG. 13, after the connection establishment is completed, the AE 1100 transmits a request message to the relay client module 1110 in the form of an M2M message (S1310). The relay client module 1110 transmits a publish packet to the relay server 1150 (S1320). To this end, the relay client module 1110 may include the request message in the payload according to the publish packet format and transmit the request message.

The publish packet includes a QoS level field, a duplicate transmission flag field, and a packet type field in the fixed header including information on the QoS level of the packet or the relay protocol, and includes a topic name field and a packet identification field in the variable header. Can be. For example, the topic name of the publish packet may be set to 'oneM2M / req / SP-relative-AE-ID / SP-relative-CSE-ID'.

The relay server 1150 transmits the received publish packet to the receiving side relay client module 1180 of the request message (S1330). The relay client module 1180 converts the request message included in the payload of the publish packet into an M2M message and transmits it to the CSE 1190 (S1340).

Through this protocol conversion and relay process, the AE 1100 may transmit a request message to the CSE 1190, and the response message may be transferred from the CSE 1190 to the AE 1100 in the same manner.

For example, the CSE 1190 transfers the response message to the relay client module 1180 in the form of an M2M message (S1350). The relay client module 1180 transmits a publish packet to the relay server 1150 (S1360). To this end, the relay client module 1180 may include the response message in the payload according to the publish packet format and transmit the response message.

The publish packet includes a QoS level field, a duplicate transmission flag field, and a packet type field in the fixed header including information on the QoS level of the packet or the relay protocol, and includes a topic name field and a packet identification field in the variable header. Can be. For example, the topic name of the publish packet may be set to 'oneM2M / resp / SP-relative-AE-ID / SP-relative-CSE-ID'.

The relay server 1150 transmits the received publish packet to the receiving relay client module 1110 of the response message in operation S1370. The relay client module 1110 converts the response message included in the payload of the publish packet into an M2M message and transmits the response message to the AE 1100 (S1380). The relay client module 1110 converts the response message included in the payload of the received publish packet into an M2M message and forwards it to the AE 1100, whereby the AE 1100 and the CSE 1190 transmit and receive a request message and a response message. can do.

14 is a diagram for describing a procedure of delivering a message using a publish packet, according to another exemplary embodiment. In FIG. 14, the request message sender is described as an Originator, and the request message receiver is described as a Receiver. This may be a node of the AE or CSE or M2M system described above.

Referring to FIG. 14, after the connection setup is completed, the Originator 1400 transmits a request message to the relay client module 1110 in the form of an M2M message (S1400). The relay client module 1110 transmits a publish packet to the relay server 1150 (S1405). To this end, the relay client module 1110 may include the request message in the payload according to the publish packet format and transmit the request message.

The publish packet includes a QoS level field, a duplicate transmission flag field, and a packet type field in the fixed header including information on the QoS level of the packet or the relay protocol, and includes a topic name field and a packet identification field in the variable header. Can be. For example, the topic name of the publish packet may be set to '/ oneM2M / req / Originator-ID / Receiver-ID'.

The relay server 1150 transmits a publish acknowledgment (Publish ACK, PUBACK) packet including information on whether the received publish packet is normally received to the relay client module 1110 (S1410). For example, the relay server 1150 relays a publish acknowledgment packet including information indicating normal reception when a publish packet including a request message is normally received or when the publish packet can be processed as a receiver. 1110).

Thereafter, the relay server 1150 transmits the received publish packet to the receiving side relay client module 1180 of the request message (S1415). The relay client module 1180 converts the request message included in the payload of the publish packet into an M2M message and delivers it to the receiver 1490 (S1425). However, the receiving relay client module 1180 may receive a publish packet including a request message from the relay server 1150 and transmit a publish acknowledgment packet including information indicating whether the packet is normally received to the relay server 1150. There is (S1420). Operation S1420 may be performed before operation S1425 or may be performed afterwards.

Through such a protocol conversion and relay process, the Originator 1400 may transmit a request message to the Receiver 1490, and a response message may be delivered from the Receiver 1490 to the Originator 1400 in the same manner.

For example, the receiver 1490 transmits the response message to the relay client module 1180 in the form of an M2M message (S1430). The relay client module 1180 transmits a publish packet including a response message to the relay server 1150 (S1435). To this end, the relay client module 1180 may include the response message in the payload according to the publish packet format and transmit the response message.

The publish packet includes a QoS level field, a duplicate transmission flag field, and a packet type field in the fixed header including information on the QoS level of the packet or the relay protocol, and includes a topic name field and a packet identification field in the variable header. Can be. For example, the Topic Name of the publish packet including the response message may be set as '/ oneM2M / resp / Originator-ID / Receiver-ID'.

When the relay server 1150 receives the publish packet including the response message, the relay server 1150 may transmit a publish confirmation packet including information indicating whether the relay packet is normally received to the relay client module 1180 (S1440).

When the publish packet including the response message is normally received and the normal confirmation is possible to the originator 1400 and the publish confirmation packet is transmitted, the relay server 1150 relays the received publish packet to the receiving side relay client module of the response message. And transmits to 1110 (S1445). When a publish packet including a response message is received, the receiving relay client module 1110 may transmit a publish acknowledgment packet including information indicating whether the reception packet is normally received or processed normally, to the relay server 1150.

The relay client module 1110 converts the response message included in the payload of the publish packet into an M2M message and transmits it to the Originator 1400 (S1455). The relay client module 1110 converts the response message included in the payload of the received publish packet into an M2M message and forwards it to the Originator 1400, whereby the Originator 1400 and the Receiver 1490 transmit and receive a request message and a response message. can do.

Meanwhile, in order to efficiently handle one-to-many communication instead of one-to-one communication, the topic name of the publish packet described above may be set as shown in the following example to process an application service or a group.

-Topic Name for sharing Application: / oneM2M / resource / AE / App-ID

-Topic Name for sharing Group: / oneM2M / resource / group / groupName

In addition, the topic name may be set in various forms, and each configuration object may be set in advance.

Hereinafter, the configuration of the above-described packets and the configuration of each header and payload will be described in detail with reference to the accompanying drawings. The format and structure of the packet of each figure are shown by way of example and are not limited to the figure.

15 illustrates a structure of a connection packet format and a fixed header according to an embodiment.

Referring to FIG. 15, a concatenated packet may be composed of two bytes of a fixed header, a variable header, and a payload region. That is, the concatenated packet format may be set to a fixed header, a variable header and a payload. The fixed header may include two bytes of information, and the length of the variable header and the payload may be set to be variable.

For example, in the fixed header, the fixed header may include a field including a reserver field, packet type information, and a remaining length field. For example, the reservation field may be set to a value of 0, and the field including packet type information may be set to a specific value indicating that the corresponding packet is a CONNECT packet. The specific value may be set in advance. Meanwhile, the remaining length field may be configured to have a variable value according to the variable header and the payload. For example, the value of the remaining length field may be set to a value of “0” or “1”, and a value of 0 or 1 may be set depending on whether payload is present, payload length, or length or length of variable header. It may be determined by a preset rule. In addition to this, the header of the connection packet format and the length of each field may vary depending on the setting.

16 illustrates a structure of a connection packet variable header according to an embodiment.

Referring to FIG. 16, the variable header of the connection packet may include a protocol name field, a protocol level field, a connection flag field, and a keep alive field. For example, the protocol name field may include information indicating a relay protocol used by the packet. In more detail, the protocol name field may include information indicating that the packet is a packet using the MQTT protocol.

In addition, the protocol level field may include information indicating a version of a corresponding protocol, and may indicate MQTT version 3.1.1 when the protocol level value is 4, such as 1600.

Meanwhile, the connection flag field may include detailed flags such as a user name flag, a password flag, Will Retain, Will QoS, Will Flag, Clean session, Reserved, and the like. For example, the Clean Session field may contain information indicating whether the session is reset. For example, if Clean Session is set to 0, the server can resume communication with the client module based on the state of the current session. As another example, Will Flag can contain information about connection errors. For example, the server may include information about whether an input / output error and a network error condition, communication with a client module could not be performed within a maintenance time, or a protocol error. As another example, Will QoS includes information specifying the QoS level to use when initiating a Will message. As another example, Will Retaion may include information indicating whether or not to maintain the packet. As another example, the password flag may include information on whether a password exists in a corresponding payload. As such, the connection flag field may include various setting information about the connection packet. That is, when the value of the connection packet is set as shown in 1610, it may represent that the Will Flag value is set to 1.

On the other hand, the connection maintenance field of the variable header indicates information on the maximum time interval that can elapse between two consecutive control packets transmitted by the client module, it may be set in units of seconds.

In addition, if necessary, the length of the header and each region may vary depending on the setting.

17 illustrates a structure of a connection packet payload according to an embodiment.

Referring to FIG. 17, the payload may include client module identifier information. It may also include a username and password as needed. The client module identifier information may include identification information for identifying the client module in the corresponding relay server, and optionally include name information and password for the corresponding user.

Even in this case, each region and payload length may vary.

As described above, the connection packet may be configured to include various information. Hereinafter, the format and each field of the connection confirmation packet in response to the connection packet will be described.

18 is a diagram illustrating a connection confirmation packet format and the structure of each header according to an embodiment.

Referring to FIG. 18, the connection confirmation packet may consist of a fixed header of 2 bytes, a variable header, and a payload. For example, the fixed header may include a reserved field (ex, set to 0000), a packet type field, and a remaining length field. This may be set similar to the above-described connection packet.

The variable header may also include a reservation field (ex, set to 0), a remaining length field, and a concatenation return code information field. Through this, the client module can check the processing result of the connection packet requested to the relay server through the value of the connection return code field.

In addition, the variable header may include a session present flag (SP) and a reservation and connection response code field. On the other hand, the payload may be omitted.

19 illustrates a structure of a subscribe packet format, a fixed header, a variable header, and a payload according to an embodiment.

Referring to FIG. 19, a SUBSCRIBE packet is set in a format consisting of a fixed header, a variable header, and a payload. The fixed header may be set to 2 bytes, and the variable header and payload may be set to vary in length.

Like the connection packet, the fixed header may include a reservation field, a packet type information field, and a remaining length field, and a value included in each field may be set as shown in 1900. Meanwhile, the variable header may include packet identification information.

In addition, the payload includes a length field, a topic filter field, and a QoS field, and a plurality of QoSs corresponding to the topic filter and the topic filter may be included in pairs.

20 illustrates a structure of a subscribe confirmation packet format, fixed header, variable header, and payload according to an embodiment.

Referring to FIG. 20, a subscription confirmation packet including confirmation information on a subscription packet is composed of a fixed header, a variable header, and a payload.

Like the subscription packet, the fixed header may include a reservation field, a packet type information field, and a remaining length field, and each field may include information as in the example of 2000. Meanwhile, the variable header may include packet identification information.

In addition, the payload may include list information of the response code. Through this, the relay client module may obtain the processing result of the relay server for the subscription packet through the information set for each response code.

Hereinafter, a structure of a publish packet for relaying a request message and a response message and a publish confirmation packet therefor will be described.

21 is a diagram illustrating a publish packet format, a fixed header, and a variable header structure according to an embodiment.

Referring to FIG. 21, a publish packet includes a fixed header, a variable header, and a payload. For example, the fixed header may be composed of RETAIN, QoS level, DUG flag, packet type information, and remaining length field.

For example, the fixed header may consist of 2 bytes and carry information allocated for each bit. For example, the QoS level field contains information about the QoS level of a packet or relay protocol. In addition, the duplicate transmission flag field includes information indicating whether a corresponding packet is duplicate transmission. In addition, the packet type field includes information indicating that the packet is a publish packet.

As another example, the variable header may include a topic name and packet identification information. The topic name may vary according to the request and response message as described above, and may include sender information and receiver information. For example, it can be set to '/ oneM2M / req / Originator-ID / Receiver-ID' for a request message and to '/ oneM2M / resp / Originator-ID / Receiver-ID' for a response message. have. The packet identification information may include index information preset for identifying the packet. In addition, the packet identification information may exist only in a publish packet having a QoS level of 1 or 2.

Meanwhile, the payload of the publish packet may include a request message or response message defined in the M2M system. For example, the request message included in the payload may include information indicating a request type of the request message, caller identification information, receiver identification information, and request identification information. When the response message is included in the payload, the response message may include request identification information and response result code information.

FIG. 22 is a diagram illustrating a publish confirmation packet format, a fixed header, and a variable header structure according to an embodiment.

Referring to FIG. 22, a publish confirmation packet (PUBACK packet) may include at least one of a fixed header, a variable header, and a payload region.

Like the connection packet and the subscription packet, the fixed header includes a reserved area, a packet type information area, and a remaining length area, and a value included in each area may be included as shown in FIG. Meanwhile, the variable header may include packet identification information. For example, the packet identification information may indicate which publish packet is a response to the publish confirmation packet. In addition, the payload of the publish confirmation packet can be omitted.

The structure and fields of each packet described above have been described in one embodiment, and may be changed by setting or some fields may be omitted or added.

In addition, according to the present embodiments, when one of two M2M devices communicates through a firewall, communication may be initiated from either of two devices using an Internet protocol. In addition, even when both devices communicate through a public IP network through a firewall, communication can be initiated from either device using the Internet protocol. In addition, request and response messages can be exchanged using the relay protocol, and the same application can be used in multiple devices. In addition, it is possible to perform a collective processing function using a relay protocol. Therefore, according to the present embodiment, it is possible to confirm whether an operation requested by the sender is correctly performed while preventing an increase in traffic of the entire network.

Hereinafter, the configuration of the M2M device and the relay server that can implement all of the embodiments described with reference to FIGS. 1 to 22 will be described once again with reference to the drawings.

23 is a diagram illustrating a structure of an M2M device according to one embodiment.

Referring to FIG. 23, an M2M device 2300 that communicates with another M2M device through a public IP (Internet Protocol) network transmits a connection packet for establishing a connection to a relay server through a relay client module, and connects. When the connection with the relay server and the control unit 2310 for establishing a connection with the relay server by receiving the response information on the connection packet for setting is established, the request packet for transmission to another M2M device is included in the publish packet and relayed. It may include a transmitter 2320 for transmitting to the server and a receiver 2330 for receiving a publish packet including a response message generated by another M2M device for the request message from the relay server.

In addition, the transmitter 2320 may transmit a connection packet for establishing a connection with the relay server to the relay server, and the receiver 2330 may receive a connection confirmation packet including response information about the connection packet from the relay server.

Meanwhile, when the M2M device receives the connection confirmation packet, the transmitter 2320 may transmit a subscription packet to the relay server, and the receiver 2330 may receive a subscription confirmation packet thereto. The subscription packet may include identification information for identifying the AE or CSE of the corresponding M2M device in the relay server. The controller 2310 may receive a subscription confirmation packet and perform connection establishment.

Meanwhile, the connection packet between the relay server and the relay client module may be configured in the following format. For example, the concatenated packet may consist of two bytes of fixed header, variable header and payload area. The variable header may include a protocol name field, a protocol level field, a connection flag field, and a keep alive field, and the payload region may include client module identifier information.

Meanwhile, the connection establishment procedure may be performed in the same manner with other M2M devices for communicating with the M2M device. For example, another M2M device may establish a connection with the relay server through a procedure for transmitting and receiving a connection packet and a connection confirmation packet. Alternatively, the other M2M device may perform a connection packet and a connection confirmation packet transmission / reception procedure with the relay server, and establish a connection through the transmission and reception of a subscription packet and a subscription confirmation packet.

The publish packet may include information indicating that the message is a thing communication message, information indicating a message type (request or response), identification information of the sender, and identification information of the receiver.

Meanwhile, the publish packet includes a fixed header, a variable header, and a payload region, and the fixed header includes a QoS level field, a duplicate transmission flag field, and a packet type field, which include information on the QoS level of the packet or relay protocol. The variable header may include a topic name field and a packet identification field. The payload area may include a request message and request information may be included in the request message. The request identification information may be included in a response message later to identify information on which request message the response message is a response to.

If necessary, the receiving unit 2330 may receive a publish confirmation packet including response information about the publish packet from the relay server. The publish confirmation packet may include information on whether the publish packet is normally received.

In addition, the transmitter 2320 transmits acknowledgment information about the publish packet including the response message to the relay server in the publish acknowledgment packet. The publish confirmation packet may include information on whether the publish packet is normally received. In addition, as described above, the response message may be included in the payload of the publish packet and may include request identification information and response status code information. The request identification information may be set to the same value as the request message to indicate which request message the response message includes. The response status code contains a code value for the processing result of the procedure required in the corresponding request message.

In addition, the controller 2310 transmits a request message using the relay server according to the present embodiment, and controls the overall operation of the M2M device 2300 according to the response message.

In addition, the transmitter 2320 and the receiver 2330 are used to transmit and receive messages, signals, and data necessary to perform the present embodiment with at least one of a relay server, another M2M device, a relay client module.

24 is a diagram illustrating a structure of a relay server according to an embodiment.

Referring to FIG. 24, the relay server 2400 which relays communication between M2M devices through a public IP (Internet Protocol) network may receive a connection packet for connection establishment from a relay client module of each of the M2M device and another M2M device. A receiving unit 2430 for receiving a publish packet including a request message for transmitting from the relay client module of the M2M device and the other M2M device to another M2M device; It may include a transmitter 2420 for transmitting a publish packet including a to a relay client module of another M2M device.

The receiving unit 2430 further receives a publish packet including a response message to the request message from the relay client module of another M2M device, and the transmitting unit 2420 further sends the publish packet including the response message to the relay client module of the M2M device. Can transmit

The receiver 2430 may receive a connection packet from M2M devices that wish to perform communication through the relay server. The connection packet may be received from a relay client module that may be configured in each M2M device. In addition, the transmitter 2420 may transmit a connection confirmation packet including response information to the connection packet to each M2M device.

Alternatively, the receiver 2430 receives a subscription packet from each M2M device after receiving a connection packet and transmitting a connection confirmation packet, and the transmitter 2420 transmits a subscription confirmation packet for the subscription packet to each M2M device to perform connection establishment. It may be. For example, the subscription packet may include identification information for the M2M device requesting connection establishment. Alternatively, the subscription packet may include identification information related to transmission of a request message of the M2M device requesting connection establishment and information on identification information related to reception of a response message. Of course, the information indicating that the M2M device is a M2M packet using the M2M network may be included.

Meanwhile, the relay server 2400 may be configured independently of the middle node and the infrastructure node, which are nodes constituting the M2M system. In this case, the middle node and the infrastructure node may communicate with an independently configured relay server using the relay client module.

Alternatively, the relay server 2400 may be configured in a middle node or an infrastructure node that is a node constituting the M2M system. Even in this case, a relay client module for communicating with each entity configured in the relay server and the middle node or infrastructure node may be configured in each node.

Meanwhile, the publish packet may include information indicating that the message is a thing communication message, information indicating a message type (a request or response), identification information of the sender, and identification information of the receiver. Alternatively, the publish packet is composed of a fixed header, a variable header and a payload area, the fixed header includes a QoS level field, information on the QoS level of the packet or relay protocol, a duplicate transmission flag field and a packet type field, The variable header may include a topic name field and a packet identification field.

If necessary, the transmitter 2420 may transmit a publish confirmation packet including response information about the publish packet to the M2M device. The publish confirmation packet may include information on whether the publish packet is normally received.

 When the publish packet is received, the controller 2410 checks identification information of another target M2M device indicated by the publish packet, and the transmitter 2420 includes a request message to a relay client module of another connected M2M device. A publish packet may be transmitted. That is, when the publish packet is received from the relay client module, the controller 2410 transmits the packet to the relay client module at the receiver by referring to the topic name. The receiver 2430 may receive a publish acknowledgment packet indicating an acknowledgment of a publish packet including a request message from another M2M device. In addition, the transmitter 2420 may transmit a publish confirmation packet for the publish packet to another M2M device. In addition, the receiver 2430 may receive a publish confirmation packet from the M2M device.

In addition, the controller 2410 transmits a request message using the relay server according to the present embodiment, and controls the overall operation of the relay server 2400 according to the response message.

In addition, the transmitter 2420 and the receiver 2430 are used to transmit and receive messages, signals, and data necessary for performing the present embodiment with at least one of another relay server, an M2M device, another M2M device, and a relay client module. do.

The standard contents or standard documents mentioned in the above embodiments are omitted to simplify the description of the specification and form a part of the present specification. Therefore, the addition of the contents of the standard and part of the standard documents to the specification or the description in the claims should be construed as falling within the scope of the present invention.

The above description is merely illustrative of the technical idea of the present invention, and those skilled in the art to which the present invention pertains may make various modifications and changes without departing from the essential characteristics of the present invention. Therefore, the embodiments disclosed in the present invention are not intended to limit the technical spirit of the present invention but to describe the present invention, and the scope of the technical idea of the present invention is not limited by these embodiments. The protection scope of the present invention should be interpreted by the following claims, and all technical ideas within the equivalent scope should be interpreted as being included in the scope of the present invention.

CROSS-REFERENCE TO RELATED APPLICATION

This patent application is filed with the patent application No. 10-2017-0054667 filed in Korea on April 27, 2017 and the patent application No. 10-2017-0064401 filed in Korea on May 24, 2017 and April 2018 Patent Application No. 10-2018-0042814, filed in Korea on 12 December, claims priority under 35 USC § 119 (a) of the United States Patent Act, all of which are hereby incorporated by reference. Incorporated into the application. In addition, if this patent application claims priority for the same reason for countries other than the United States, all its contents are incorporated into this patent application by reference.

Claims (16)

In the method that the M2M (Machine to Machine communication) device communicates with other M2M devices through the public Internet (IP) network Transmitting a connection packet for establishing a connection to a relay server through a relay client module, receiving response information on the connection packet for establishing the connection, and establishing a connection with the relay server; If a connection with the relay server is established, including a request message for transmission to another M2M device in a publish packet and transmitting the message to the relay server; And And receiving from the relay server a publish packet including a response message generated by the other M2M device in response to the request message. The method of claim 1, The relay server, And configured in the middle node or the infrastructure node. The method of claim 1, The relay server, And configured to be independent of the middle node and the infrastructure node, and to communicate with a relay client module configured in the middle node or the infrastructure node. The method of claim 1, The other M2M device, And receiving a publish packet including the request message from the relay server after completing a connection packet transmission / reception procedure with the relay server. The method of claim 1, The connection packet, Consists of 2 bytes of fixed header, variable header and payload area, The variable header includes a protocol name field, a protocol level field, a connection flag field, and a keep alive field, And the payload region includes the client module identifier information. The method of claim 1, The publish packet is, It consists of a fixed header, a variable header, and a payload area. The fixed header includes a QoS level field, a duplicate transmission flag field, and a packet type field, which include information on the QoS level of a packet or relay protocol. And the variable header includes a topic name field and a packet identification field. In the relay server relays communication between machine to machine communication (M2M) device over a public Internet (IP) network, Receiving a connection packet for connection establishment from a relay client module of each of an M2M device and another M2M device, and establishing a connection with each of the M2M device and another M2M device; Receiving a publish packet including a request message for transmitting from the relay client module of the M2M device to the other M2M device; Transmitting a publish packet including the request message to a relay client module of the other M2M device; Receiving a publish packet including a response message to the request message from a relay client module of the other M2M device; And And sending a publish packet including the response message to a relay client module of the M2M device. The method of claim 7, wherein The relay server, And configured in the middle node or the infrastructure node. The method of claim 7, wherein The connection packet, Consists of 2 bytes of fixed header, variable header and payload area, The variable header includes a protocol name field, a protocol level field, a connection flag field, and a keep alive field, And the payload region includes the client module identifier information. The method of claim 7, wherein The publish packet is, It consists of a fixed header, a variable header, and a payload area. The fixed header includes a QoS level field, a duplicate transmission flag field, and a packet type field, which include information on the QoS level of a packet or relay protocol. And the variable header includes a topic name field and a packet identification field. In a machine to machine communication (M2M) device that communicates with other M2M devices through a public IP (Internet Protocol) network, A control unit which transmits a connection packet for connection establishment to a relay server through a relay client module, and receives response information on the connection packet for establishing connection and establishes a connection with the relay server; A transmitter configured to transmit a request message for transmission to another M2M device in a publish packet to the relay server when the connection with the relay server is established; And M2M device including a receiving unit for receiving from the relay server a publish packet including a response message generated by the other M2M device for the request message. The method of claim 11, The relay server, M2M device, characterized in that configured in the middle node or infrastructure node. The method of claim 11, The relay server, The M2M apparatus, configured independently of the middle node and the infrastructure node, performs communication with a relay client module configured in the middle node or the infrastructure node. The method of claim 11, The other M2M device, M2M device, characterized in that for receiving a publish packet including the request message from the relay server after completing the connection setup and transmission procedure with the relay server. The method of claim 11, The connection packet, Consists of 2 bytes of fixed header, variable header and payload area, The variable header includes a protocol name field, a protocol level field, a connection flag field, and a keep alive field, The payload area M2M device comprising the client module identifier information. The method of claim 11, The publish packet is, It consists of a fixed header, a variable header, and a payload area. The fixed header includes a QoS level field, a duplicate transmission flag field, and a packet type field, which include information on the QoS level of a packet or relay protocol. The variable header includes a topic name field and a packet identification field.

Images