KR20180120576A - Methods for processing M2M communication via public IP And Apparatuses thereof - Google Patents

Abstract

The present invention relates to a private IP-based M2M communication method via a public IP in a machine to machine (M2M) communication system and an apparatus thereof. An embodiment of the present invention provides a method for enabling a M2M communication apparatus to communicate with another M2M communication apparatus through a public internet protocol (IP) network, including the steps of: transmitting a connection packet for setting a connection to a relay server through a relay client module; setting the connection with the relay server by receiving response information to the connection packet for setting the connection; including a request message to be transmitted to another M2M communication apparatus in a publish packet to be transmitted to the relay server when the connection with the relay server is set; and receiving the publish packet including a response message generated by another M2M communication apparatus with regard to the request message, from the relay server, and the apparatus thereof. Accordingly, the present invention can provide a smooth communication method configured in different networks between the M2M communication apparatuses.

Description

METHOD FOR PROCESSING < RTI ID = 0.0 > M2M < / RTI > communication via IP &

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

"Machine to Machine Communication" or MTC, "Machine Type Communication" or "Smart Device Communication" or "Machine oriented communication" or "Internet of Things" In which communication is performed without intervening in the network.

Since object communication does not normally perform communication and application control directly by a person, transmission and reception methods and procedures are required to exchange messages between objects. There is also a need for a protocol for smooth message exchange between M2M devices.

Particularly, in accordance with popularization of IoT devices, a plurality of object communication devices are used in the home and office, and a plurality of object communication devices performing the same or similar functions are deployed for a certain purpose.

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

However, current object communication networks only define communication protocols between object communication devices existing in the same network, and communication between object communication devices included in different networks is not considered.

In particular, when the object communication apparatus configured in different private IP networks performs communication through the public IP network, communication can not be smoothly performed due to a firewall of the private IP network or the like.

One embodiment disclosed in the above background is to provide a method for smooth communication between object communication devices formed in different networks.

In addition, one embodiment of the present invention is to provide a method and apparatus for enabling a object communication apparatus using a private IP to communicate with a object communication apparatus using an external private IP so as to be able to perform through a public IP.

According to an embodiment of the present invention, there is provided a method of communicating with another M2M device through a public IP (Internet Protocol) network, the method comprising: A step of transmitting a connection packet for establishing a connection, receiving response information for a connection packet for establishing a connection and establishing a connection with a relay server, and transmitting a request for transmission to another M2M device Transmitting the message to the relay server by including the message in a public packet, and receiving a public packet including the response message generated by another M2M device with respect to the request message from the relay server.

According to an embodiment of the present invention, there is provided a method of relaying communication between M2M (machine to machine communication) devices via a public IP (Internet Protocol) network, Receiving a connection packet for establishing a connection with each of the M2M device and the other M2M devices, receiving a public packet including a request message for transferring from the relay client module of the M2M device to another M2M device, Receiving a public packet including a response message for a request message from the relay client module of the other M2M device and transmitting a public packet including a response message to the relay client module of the other M2M device; To the relay client module of the M2M device It provides a way.

In an exemplary embodiment of the present invention, an M2M (Machine to Machine Communication) device for communicating with another M2M device through a public IP network includes a connection packet for establishing a connection to a relay server through a relay client module When the connection between the control server and the relay server is established, the request message for transmission to another M2M device is included in the public packet, And a receiving unit for receiving, from a relay server, a transmission packet including a transmission unit for transmitting the request message and a response message generated by another M2M device to the relay server.

In an exemplary embodiment, a relay server for relaying communication between M2M (machine to machine communication) devices through a public IP (Internet Protocol) network, the relay server comprising: A receiving unit for receiving a public packet including a control unit for receiving a packet and establishing a connection with each of the M2M device and the other M2M devices and a request message for transferring the request message from the relaying client module of the M2M device to another M2M device, And a transmitting unit for transmitting the public packet to the relay client module of the other M2M apparatus, wherein the receiving unit further receives a public packet including a response message for the request message from the relay client module of the other M2M apparatus, And transmits the included public packet to the relay client module To the relay server.

The present disclosure provides an effect that a plurality of object communication apparatuses using different private IPs can smoothly transmit and receive messages through the public IP.

The present disclosure also provides the effect that data can be transmitted and received as needed between object communication apparatuses configured in different networks without limitation of public or private IP.

BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 is a diagram illustrating the M2M system from a high level functional view.
FIG. 2 is a view showing a more detailed structure of the M2M system according to one embodiment.
FIG. 3 is an exemplary diagram illustrating a procedure for transmitting a request message and receiving response information in the M2M system.
FIG. 4 is a diagram illustrating a functional structure of a common service entity according to an embodiment.
FIG. 5 is a diagram for explaining a problem that may occur when using a public IP and a private IP.
FIG. 6 is a diagram for explaining a problem that may occur when communication is performed between M2M devices using a private IP via a public IP network.
7 is a diagram for explaining the operation of the M2M device according to an embodiment.
8 is a diagram for explaining the operation of a relay server according to an embodiment.
FIG. 9 is a diagram illustrating a structure in which a relay server according to an embodiment is integrated with an M2M device.
10 is a diagram illustrating a structure in which a relay server according to an embodiment is configured independently.
11 is a diagram for explaining a procedure for establishing a connection with a relay server using a connection packet according to an embodiment.
12 is a diagram for explaining a procedure for establishing a connection with a relay server using a connection packet according to another embodiment.
13 is a diagram for explaining a procedure for delivering a message using a public packet according to an embodiment.
14 is a diagram for explaining a procedure of delivering a message using a public packet according to another embodiment.
15 is a diagram illustrating a structure of a connection packet format and a fixed header according to an embodiment.
16 is a diagram illustrating a structure of a connection packet variable header according to an embodiment.
17 is a diagram illustrating a structure of a connection packet payload according to an embodiment.
18 is a diagram illustrating a connection acknowledgment packet format and the structure of each header according to an embodiment.
FIG. 19 is a diagram illustrating a structure of a subscribe packet format, a fixed header, a variable header, and a payload according to an embodiment.
FIG. 20 is a diagram illustrating a structure of a subscribe acknowledgment packet format, a fixed header, a variable header, and a payload according to an embodiment.
21 is a diagram illustrating a public packet format, a fixed header, and a variable header structure according to an embodiment.
FIG. 22 is a diagram illustrating another format of a public-key confirmation packet, a fixed header, and a variable header according to an embodiment of the present invention.
23 is a diagram illustrating a structure of an M2M device according to an 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 exemplary drawings. It should be noted that, in adding reference numerals to the constituent elements of the drawings, the same constituent elements are denoted by the same reference symbols as possible even if they are shown in different drawings. In the following description of the present invention, a detailed description of known functions and configurations incorporated herein will be omitted when it may make the subject matter of the present invention rather unclear.

In describing the components of the present invention, terms such as first, second, A, B, (a), and (b) may be used. These terms are intended to distinguish the constituent elements from other constituent elements, and the terms do not limit the nature, order or order of the constituent elements. When a component is described as being "connected", "coupled", or "connected" to another component, the component may be directly connected or connected to the other component, Quot; may be " connected, " " coupled, " or " connected. &Quot;

Embodiments of the present invention will be described with reference to object communication. Object communication is variously called M2M (Machine to Machine communication), MTC (Machine Type Communication), IoT (Internet of Things), Smart Device Communication (SDC), or Machine Oriented Communication . OneM2M has recently introduced many technical issues related to object communication. Object communication refers to various communication in which communication is performed without a person intervening in the communication process. In the field of telecommunication, there are various fields such as energy field, enterprise field, healthcare field, public service field, residential field, retail field, transportation field, and others Field, and so on. The present invention includes the above-mentioned fields, and is applicable to other fields.

1 is a diagram illustrating a high-level functional view of an M2M system according to an embodiment.

An application entity (AE) 110 provides application service logic for an end-to-end M2M solution. For example, a fleet tracking application such as a vehicle, a remote blood sugar monitoring application, or a remote power metering and controlling application.

The Common Services Entity (CSE) 120 may be used for various services such as an energy field, an enterprise field, a healthcare field, a public service field, a residential field, ), Transportation (transportation), and other fields.

This service function is exposed as a different function through reference points Mca, Mcc, and uses the base network service using the reference point Mcn. One example of the common service entity may be data management, device management, M2M subscription management, location service, and the like. The subfunctions provided by the CSE can be logically understood as a CSF (Common Service Function). Some of the CSFs within the CSE of oneM2M node are mandatory and some may be optional. Similarly, the subfunctions in the CSF may also be mandatory or optional.

An underlying network services function (NSF) 130 provides services to the common service entity. Examples of services include device management, location services and device triggering.

Reference Points are supported in a common service entity (CSE), and the Mca reference point is a reference point for providing object communication between an application entity and a common service entity. The Mcc reference point is a reference point for providing communications between the two common service entities. The Mcn reference point is a reference point for providing object communication between a 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. The 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 may reside in the same physical entity or in different physical entities. The Mcc reference point enables such use by a common service entity that wishes to use the services of other common service entities that provide the necessary functionality. The services provided through the Mcc reference point are dependent on the functionality provided by the common service entity. Mcc reference points can be supported between different M2M nodes. The Mcn reference point enables such use by a common service entity that wishes to use the service object of the underlying network providing the necessary functionality, which provides services other than transport and connection. The instance of the Mcn reference point is implemented dependent on the service provided in the underlying network. Information exchange between two physical M2M nodes can use the transport and connectivity services of the underlying network to provide basic services.

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

FIG. 2 is a view showing a more detailed structure of the M2M system according to one embodiment.

Referring to FIG. 2, an infrastructure node 250 performs a server function necessary to provide M2M communication. The originating node 250 is comprised of an originating node application entity (AE) 252 and an originating node common service entity (CSE) 254. Based node common service entity 254 is configured using various resources. 252 and 254 are divided through an Mca reference point and a message for communication of objects, particularly a request message for creating, deleting, updating, retrieving, and notifying the scheduler resource And for constructing and processing response messages.

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

The application service node 210 may include an application entity 212 and a relay node common service entity 214. The application entity 212 processes the application functions required for the purpose of the device. The common service entity 214 of the application service node 210 is configured using various resources. 212 and 214 are divided through Mca reference points and 214 and 254 are classified using Mcc reference points and messages necessary for object communication, in particular, create, delete, update, Used to construct and process request and response messages to retrieve and notify. Meanwhile, the application service node 220 may perform the object communication function with the base node 250 through the relay node 200. The difference between 210 and 220 is that the communication interfaces constituting the node are different. For example, the 220 communicates with 200 through 200 using an interface capable of a near-field communication such as Bluetooth, ZigBee, Zwave, and WiFi. On the other hand, the 210 communicates with 250 using a communication interface such as 3G, LTE, 5G, Ethernet, Gigabit Ethernet, ADSL and the like.

The application dedicated nodes 230 and 240 do not have a common service entity but do object communication using only the application entity 242. [ 230 is used to communicate with 250 using a communication interface such as 3G, LTE, Ethernet, Gigabit Ethernet, ADSL and the like, and 240 is used to communicate with 250 through 200 using an interface capable of Bluetooth communication, ZigBee, Zwave, WiFi, Lt; / RTI >

As described in FIG. 2, the M2M system may be configured as at least one of an infrastructure node, a relay node, an application service node, and an application dedicated node, and each node may be configured to include a CSE or an AE. CSE and AE can 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 an M2M device and may be CSE or AE as described above. Also, the sender 300 and the recipient 310 may be nodes or servers or devices, including 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 side parameter, the To parameter, the Request Identifier parameter and the Operation parameter are included as mandatory parameters. The From parameter includes information about the sender sending the message, and the To parameter includes information about the recipient receiving the message. The Request Identifier parameter contains unique identification information for identifying the request message. In addition, the operation parameter includes information for distinguishing the requested operation from the request message. The operation parameter may be set to 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, the optional parameters of the response type include a blocking processing method, a non-blocking blocking request method, a non-blocking blocking method, a non-blocking blocking method, a flexBlocking method, .

When the request message is received, the receiver 310 performs an operation for processing the request message (S330). For example, the receiver 310 can check whether the sender 300 having transmitted the request message has the right to the request. When it is determined that the sender 300 has the authority for the request, the request message is processed after confirming 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 be generated and a subscription function for instructing the sender 300 to inform the sender 300 of a change, addition, deletion, or the like of specific data occurs, the receiver 310 transmits the subscription information And notifies the sender 300 of the occurrence of an event such as change, addition, deletion, etc. in the data corresponding to the subscription information.

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

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

The functions provided by the common service object can be summarized as shown in FIG. 4, and can be classified into Addressing & Identification, Application and Service Layer Management, Data Management & Repository, Location, Security, Communication Management / Delivery Handling, Registration, Service Session Management, Device Management, Subscription / Notification, Connection Management Service Charging / Accounting, Network Service Exposure / Service Execution and Triggering, Group Management, and so on.

Each of the functions will be described as follows.

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

Communication Management and Delivery Handling (CMDH) is responsible for communication between other CSEs, AEs, and NSEs. CMDH is responsible for storing the communication requests at which time to communicate using which communication connection (CSE-CSE communication), when it is needed and when it is allowed, and when the transmission of the communication is postponed. CMDH is performed according to the provisioning policy and delivery handling parameters specific to each request for communication. Based network data transmission service, the underlying network can support the same forwarding handling function. In this case, the CMDH can use the underlying network and can act as a front end accessing the same forwarding handling function to the underlying network.

Data Management and Repository (DMR) allows M2M applications to exchange data with other objects. The DMR CSF provides the ability to provide and coordinate data storage. It also includes the ability to collect and combine large amounts of data, convert data to a specific format, or store data for analysis and semantic processing. &Quot; Data " means raw raw data that is transparently extracted from an M2M device, or may refer to data processed or combined and processed by an M2M entity. Collecting large amounts of data constitutes what is known as Big Data Storage.

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

The DIS (Search) CSF is responsible for retrieving information and resources granted in the given scope and subject (including those allowed in the M2M service subscription) and within the given scope for the Originator's request. The sender can be an application or another CSE. The scope of the search may be one CSE or multiple CSEs. The search results are delivered to the caller.

Group Management (GMG) handles the group associated with the request. Requests are sent for the management of group and group membership, and are also responsible for the bulk operations supported by the group. When adding or deleting members to a group, you need to make sure that the members conform to the purpose of the group. Bulk operations include read, write, subscribe, notify, and device management. The request or subscription is made through the group, and the group is responsible for combining these requests and notifications. Members of a group have the same role in access rights to resources. In this case, access control is done by the group. If the underlying network provides broadcasting and multicasting capabilities, the GMG CSF should use these functions.

LOC (Location) The CSF enables the M2M AE to acquire the geographical location information of M2M nodes (eg ASN, MN) for location based services. This location information may be requested from an M2M AE that is in the same or a different M2M node.

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

REG (Registration) is responsible for handling applications or other CSEs to register with the CSE, which allows the registration of entities that want to use the services provided by the CSE. The REG CSF handles not only device registration for the CSE, but also device property / attribute registration.

SEC (Security) provides sensitive data handling, security operation, security association setting, authorization and access control, and identification protection. The sensitive data handling functionality provided by the SEC CSF provides the ability to protect local credentials that require security during storage and manipulation. Sensitive data handling also uses security algorithms. This feature supports separate security environments with different cryptographic techniques. The security operations function provides the following functions, first providing the creation and operation functions of a dedicated security environment to be supported by sensitive data handling functions. 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 setting function establishes a security association between M2M nodes to enable confidentiality, integrity, authentication, and authorization. Authorization and access control functions control the access of services and data to authorized entities according to the provisioned security policies and assigned roles. The unique identifier of the entity is used for authorization, and the identity protection function can provide anonymity that serves as a temporary identifier so that it is not linked to the actual identity information associated with the entity or user.

Service Charging and Accounting (SCA) provides billing for the service layer. Supports different billing models, including online and offline billing. The SCA CSF acquires billable events, stores information, and generates billing records and billing information. The SCA CSF can interact with the billing 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 billing information for billing.

SSM (Service Session Management) The CSF manages M2M service sessions that 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. Management of the M2M service session includes management of the session state, establishment and authentication of the session, management of the underlying network connection and service related to the session, coordination of the session expansion of the CSE multi-hop cse, . Within a given M2M service session, the SSM CSF uses the CMDH CSF in the local CSE to send / receive messages to / from the next hop CSE or application. The SSM CSF uses the SEC CSF for session credentials for session participants and for session management related to authentication. The SSM CSF generates session-specific billing events and also communicates with the SCA CSF in the local CSE.

Subscription and Notification (SUB) provides notifications to maintain subscriptions and tracks changes in resources (for example, deletion of resources). The subscription of the resource is initiated by the M2M AE or CSE and is authorized by the hosting CSE. During an active subscription, the hosting CSE sends a notification to the address that the resource subscriber wants to receive in the event of a change in the subscribed resource.

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

An identifier that can be applied to the present embodiments will be described as follows. The M2M identifier includes an M2M Service Provider Identifier (M2M-SP-ID), an App-Inst-ID (Application Instance Identifier), an App-ID (Application Identifier), a CSE-ID (CSE Identifier), an M2M- A Node Identifier / Device Identifier, an M2M Service Subscription Identifier (M2M-Sub-ID), and an M2M-Request-ID (Request Identifier).

oneM2M is a requirement that must be fulfilled to implement the system. It includes overall system requirements, management requirements, data model & semantics requirements, security requirements Requirements, Charging Requirements, and Operational Requirements.

This document focuses on M2M system technology, especially oneM2M service platform technology. However, this description is not limited to the M2M service platform technology, but is applicable to all systems and structures that provide inter-device communication, i.e., object communication, and communication operations occurring in these systems.

The M2M device in this specification describes the various nodes including the above-mentioned AE, CSE, NSE, and the like, and for the sake of understanding, the description will be made with reference to the hosting CSE. However, no. That is, the M2M device refers to a constituent device that constitutes the M2M system, and refers to various nodes, devices, and entities that receive a request message, perform processing thereon, and transmit a response message.

FIG. 5 is a view for explaining a problem that may occur when using a public IP and a private IP, and FIG. 6 is a diagram for explaining a problem that may occur when communication is performed via a public IP network among M2M devices using a private IP Fig.

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 the firewall to perform communication.

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

However, in both of the cases described above, the communication between the private IP network and the public IP network may not be smooth. For example, when the M2M device # 2 550 using the public IP communicates with the M2M device # 1 500 using the private IP, communication can not be started. In addition, when the communication is performed through the public IP between the M2M devices 500 and 550 using the private IP, there is a problem that any M2M device can not start communication.

This is because the communication start packet in the private IP network is communicated to the public IP network and communication is possible, but the communication start packet in the public IP network can not be transmitted to the private IP network. That is, a packet through the public IP network due to the firewall can not enter into the private IP network, so that a packet for starting communication can not be delivered.

Therefore, the M2M device using the private IP has a problem that communication can be performed only when communication is started in the M2M device using the private IP to communicate with the M2M device using the public IP. In addition, there is a problem that M2M devices using private IP can not start communication through public IP.

To solve this problem, the present disclosure which has been devised to solve this problem is to propose a concrete method of performing object communication by a private IP-based M2M device via public IP in the M2M system. In particular, the M2M device using the public IP provides a specific procedure for performing communication with the M2M device using the private IP, and a concrete procedure for performing the object communication between the M2M device using the private IP is presented.

The M2M device described below refers to an entity using a private IP or a public IP, and another M2M device exchanging messages with the corresponding M2M device also means an entity using a private IP or a public IP. However, it is assumed that the M2M device and the other M2M device are configured in a position causing the problem described above by the public IP network. For example, if an M2M device uses private IP, other M2M devices may use public IP or use a different private IP than the M2M device. Alternatively, if the M2M device uses public IP, the other M2M device may use the private IP.

In the present specification, the relay server means an entity for delivering 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 on a variety of protocols for communicating messages of M2M devices. For example, the relay server can 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, and the relay client module may also mean an MQTT client module.

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

7 is a diagram for explaining the operation of the M2M device according to an embodiment.

Referring to FIG. 7, a machine-to-machine communication (M2M) apparatus transmits a connection packet for establishing a connection to a relay server through a relay client module, receives response information for a connection packet for establishing a connection, (S700). ≪ / RTI > For example, an M2M device may communicate with another M2M device that uses another private IP or another M2M device that uses public IP, or another M2M device that uses a private IP (when the M2M device uses public IP) In order to perform communication, connection setup to the relay server can be performed 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 for the connection packet from the relay server. In this case, the M2M device can transmit and receive the connection packet and the connection confirmation packet through the relay client module connected to the M2M device. The M2M device can receive the connection confirmation packet and perform connection setup. Meanwhile, the relay client module may be one module configured in the M2M device when the M2M device is a node, and may be a separate module configured in the same node when the M2M device is AE, CSE, and the like. In this specification, the M2M device is assumed to be a node including an AE or a CSE and a relay client module. However, the present disclosure is not limited thereto. have.

Alternatively, when the M2M device receives the connection confirmation packet, the M2M device can transmit the subscription packet to the relay server and receive the registration confirmation packet. 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 the subscription confirmation packet and perform the connection setup.

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

For example, the connection packet may consist of a 2-byte fixed header, a variable header, and a payload area. In addition, 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 area may include client module identifier information.

In addition, the relay server can be configured independently of the middle node and the infrastructure node, which constitute the M2M system. In this case, the middle node and the infrastructure node can communicate with the relay server independently configured using the relay client module.

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

Meanwhile, the connection establishment procedure may be performed in the same manner as other M2M devices for performing communication with the M2M device. For example, another M2M device can establish a connection with a relay server through connection packet and connection acknowledgment packet transmission / reception procedures. Alternatively, the other M2M device may proceed with the connection packet and connection acknowledgment packet transmission / reception procedure with the relay server, and establish the connection through the connection packet and the connection acknowledgment packet transmission / reception procedure.

When the connection with the relay server is established, the M2M device may perform a step of including a request message for transmission to another M2M device in a public packet and transmitting the message to the relay server (S710).

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

The public packet includes a fixed header, a variable header, and a payload field. The fixed header includes a QoS level field including information on a QoS level of a packet or a 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. The payload field may include a request message, and the request message may include request identification information. The request identification information includes information that can be included in a later response message to identify which response message is a response to the request message.

Optionally, the M2M device may receive a publish confirmation packet containing response information for the publish packet from the relay server. The public confirmation packet may include information on whether or not the public packet is normally received.

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

For example, the relay server may forward the public packet in step S710 to another M2M device, and may transmit a public packet including a response message received from another M2M device to the M2M device. Accordingly, the M2M device can receive the public packet including the response message for the request message from the relay server through the relay client module. If necessary, the M2M device includes confirmation information for the public packet including the response message in the publicity confirmation packet, and transmits it to the relay server. The public confirmation packet may include information on whether or not the public packet is normally received. Also, as described above, the response message may be included in the payload of the public packet, and the response message may include the request identification information and the response status code information. The request identification information may be set to the same value as the request message, indicating that the response message includes the result of the response to the request message. The response status code includes a code value for the processing result of the procedure required in the corresponding request message. For example, if the processing of the request message is successful, the response result code may be set to '2000', which means a code value indicating a success of the processing.

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

Also, since the data exchange between the M2M device and the other M2M devices is performed after establishing the connection with the relay server, when the M2M devices are located in different networks or pass through the public IP network, Communication can be started.

Therefore, the problem that the communication from the public IP network to the private IP network can not be started can be solved according to the present embodiment.

The above description can be similarly performed in other M2M devices.

8 is a diagram for explaining the operation of a relay server according to an embodiment.

8, the relay server may perform a step of receiving a connection packet for establishing connection from the relay client module of each of the M2M device and the other M2M devices, and establishing a connection with each of the M2M device and the other M2M devices (S800).

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

Alternatively, the relay server may receive the connection packet, transmit the connection confirmation packet, receive the subscription packet from each M2M device, and transmit the subscription confirmation packet for the subscription packet to each M2M device to perform the connection setup. 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 the transmission of the request message of the M2M device requesting the connection establishment and information on the identification information related to the reception of the response message. Of course, information indicating that the corresponding M2M device is an object communication device packet using the M2M network may also be included.

Meanwhile, the relay server can 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 can communicate with the relay server independently configured using the relay client module.

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

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

For example, the public packet may include information indicating that the message is a message of object communication, information indicating a message type (request or response), identification information of the sender, and identification information of the receiver. Alternatively, the public packet is composed of a fixed header, a variable header, and a payload field, and the fixed header includes a QoS level field including information on the QoS level of the packet or the 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 publicity confirmation packet including response information to the public packet to the M2M device. The public confirmation packet may include information on whether or not the public packet is normally received.

The relay server may perform a step of transmitting the public packet including the request message to the relay client module of the other M2M device (S820). For example, when the relay server receives the public packet, the relay server confirms the identification information of the target other M2M device indicated by the corresponding public packet, and transmits the public packet including the request message to the relay client module of another connected M2M device . That is, when the relay server receives the broadcast packet from the relay client module, the relay server refers to the topic name and transmits the packet to the relay client module on the receiver side.

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

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

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

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

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

If necessary, the relay server can receive the publish confirmation packet from the M2M device. The relay client module of the M2M device receives the public packet from the relay server and transmits the response message included in the public packet to the AE or CSE of the M2M device. In addition, the relay client module of the M2M apparatus can transmit a broadcast confirmation packet indicating whether the public packet is normally received to the relay server.

Through the above operation, the relay server can relay the operation of transmitting and receiving data through the public IP network by the M2M device and the other M2M device so that the communication can be smoothly performed. As described above, the relay server may be included in an infrastructure node or a middle node, and may be independently configured to perform communication with an infrastructure node or a middle node.

On the other hand, each of the operations in Figs. 7 and 8 may be divided into steps as required or the order thereof may be changed, and some of the above description may be added as steps.

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

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

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

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

Alternatively, the relay server may be configured independently, and the infrastructure node may also be configured including the relay server. In this case, the nodes such as the middle node, the ASN, and the ADN and the relay server can exchange packets through the relay client protocol, and perform communication through the packet exchange between the infrastructure node and the relay server.

In this manner, the relay server can coexist with the M2M system or independently, and can perform the above-described packet exchange operation.

Hereinafter, an M2M device may be described as an AE or a caller as necessary, and another M2M device may be described as a CSE or a receiver.

11 is a diagram for explaining 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 connection 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 performs initial connection to the relay client module 1180 for connection establishment (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 can use the M2M protocol instead of the relay protocol domain, and the relay client modules 1110 and 1180 and the relay server 1150 can relay Protocol domains can be used. For example, an M2M message according to the M2M protocol may include a request message and a response message, and an M2M message may be expressed using Extensible Markup Language (XML), JavaScript Object Notation (JSON), and Concise Binary Object Representation At least one can be used. Accordingly, the relay client module 1110, 1180 can convert the M2M message into a 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 / +'.

Thereafter, the relay client module 1110 on the AE 1100 side transmits the subscription packet to the relay server 1150 (S1105), and the relay client module 1180 on the CSE 1190 side also registers with the relay server 1150 And transmits the packet (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 the above procedure, the AE 1100 and the CSE 1190 can establish a connection with the relay server 1150.

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

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

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

Similarly, the CSE 1190 performs initial connection to the relay client module 1180 in step S 1240 for connection establishment, and the relay client module 1180 transmits a connection packet to the relay server 1150 in step S 1250. The relay server 1150 can transmit a connection confirmation packet (CONNACK) including information indicating whether the connection packet is normally received to the relay client module 1180 (S1260).

At this time, the AE 1100, the CSE 1190 and the relay client modules 1110 and 1180 can use the M2M protocol instead of the relay protocol domain, and the relay client modules 1110 and 1180 and the relay server 1150 can relay Protocol domains can be used. For example, an M2M message according to the M2M protocol may include a request message and a response message, and an M2M message may be expressed using Extensible Markup Language (XML), JavaScript Object Notation (JSON), and Concise Binary Object Representation At least one can be used. Accordingly, the relay client module 1110, 1180 can convert the M2M message into a 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 / +'.

Thereafter, the relay client module 1110 on the AE 1100 side transmits the subscription packet to the relay server 1150 (S1270), and the relay client module 1180 on the CSE 1190 side also subscribes to the relay server 1150 And transmits the packet (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 acknowledgment packet (SUBACK) including information indicating normal reception of the connection packet to the relay client module 1110 on the AE 1100 side (S1290). Similarly, the relay server 1150 can transmit a subscription acknowledgment packet (SUBACK) including information indicating normal reception of the subscription packet to the relay client module 1180 on the CSE 1180 side (S1295).

Through the above procedure, the AE 1100 and the CSE 1190 can establish a connection with the relay server 1150.

Once the connection setup is completed, the M2M device can communicate with the relay server using the public packet.

13 is a diagram for explaining a procedure for delivering a message using a public packet according to an embodiment.

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

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

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

The AE 1100 can forward the request message to the CSE 1190 through the protocol conversion and the relay process, and the response message can be transferred from the CSE 1190 to the AE 1100 in the same manner.

For example, the CSE 1190 transmits a response message to the relay client module 1180 in the M2M message format (S1350). The relay client module 1180 transmits the public packet to the relay server 1150 (S1360). For this purpose, the relay client module 1180 can transmit the response message in the payload according to the public packet format.

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

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

14 is a diagram for explaining a procedure of delivering a message using a public packet according to another embodiment. 14, the sender of the request message is described as Originator, and the recipient of the request message is described as Receiver. This can be the node of the AE or CSE or M2M system described above.

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

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

The relay server 1150 transmits a Publish ACK (PUBACK) packet including information on whether or not the received public packet is normally received to the relay client module 1110 (S1410). For example, the relay server 1150 transmits a publicity confirmation packet including information indicating that a public packet including a request message has been received normally or normal reception if the public packet can be processed as a receiver, to the relay client module 1110).

Then, the relay server 1150 transmits the received public packet to the relay client module 1180 on the receiving side of the request message (S1415). The relay client module 1180 converts the request message included in the payload of the public packet into an M2M message and transmits the message to the receiver 1490 (S1425). However, the receiving-side relay client module 1180 may receive the public packet including the request message from the relay server 1150, and may transmit the publicity check packet including the information indicating the normal reception status to the relay server 1150 (S1420). The step S1420 may be performed before or after the step S1425.

Through the protocol conversion and relay process, the originator 1400 can transmit a request message to the receiver 1490 and the response message can be transmitted from the receiver 1490 to the originator 1400 in the same manner.

For example, the receiver 1490 transmits a response message to the relay client module 1180 in an M2M message format (S1430). The relay client module 1180 transmits a public packet including a response message to the relay server 1150 (S1435). For this purpose, the relay client module 1180 can transmit the response message in the payload according to the public packet format.

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

Upon receiving the public packet including the response message, the relay server 1150 may transmit a publicity confirmation packet including information indicating normal reception of the public packet to the relay client module 1180 in operation S1440.

When the public packet including the response message is normally received and the originator 1400 can normally relay the packet, the relay server 1150 transmits the received public packet to the relay client module (Step S1445). Upon reception of the public packet including the response message, the receiving-side relay client module 1110 can transmit a broadcast confirmation packet including information indicating normal reception or normal processing to the relay server 1150.

The relay client module 1110 converts the response message included in the payload of the public packet into an M2M message and transmits the message to the originator 1400 (S1455). The relay client module 1110 converts the response message included in the payload of the received public packet into an M2M message and transmits the message to the originator 1400. The originator 1400 and the receiver 1490 send and receive a request message and a response message, can do.

Meanwhile, in order to efficiently process one-to-many communication rather than one-to-one communication, the topic name of the public 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 can be set in various forms, which can be set in advance for each constituent entity.

Hereinafter, the configuration of the above-described packets and the configuration of each header and payload will be described in more detail with reference to the drawings. The format and structure of packets in each drawing are illustratively shown and are not limited to those drawings.

15 is a diagram illustrating a structure of a connection packet format and a fixed header according to an embodiment.

Referring to FIG. 15, the connection packet may be composed of a 2-byte fixed header, a variable header, and a payload area. That is, the connection packet format can be set as a fixed header, a variable header, and a payload, and the fixed header includes 2 bytes of information, and the variable header and the payload length can be set to be variable.

For example, a fixed header may be composed of a fixed header including a Reserver field, a field including packet type information, and a remaining length field. For example, the reserved field may be set to a value of 0, and a field containing packet type information may be set to a specific value to indicate that the packet is a CONNECT packet. The specific value can be preset. On the other hand, the remaining length field may be variable in value depending on 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 may be a value of 0 or 1 depending on the presence or absence of a payload, And can be determined by a predetermined rule. In addition, the header of the connection packet format and the length of each field may vary depending on the setting.

16 is a diagram illustrating 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. Specifically, 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 the version of the protocol, and may indicate MQTT version 3.1.1 when the value of the protocol level is 4, such as 1600.

On the other hand, the connection flag field may include a detailed flag such as a user name flag, a password flag, a Will Retain, a Will QoS, a Will Flag, a Clean session, and a Reserved. As an example, the Clean Session field can contain information that indicates whether the session is reset. For example, if the Clean Session is set to 0, the server can resume communication with the client module based on the current state of the session. As another example, the Will Flag can contain information about connection errors. For example, the server may include information on whether there is an input / output error and a network error situation, a communication failure within the retention time with the client module, a protocol error, and the like. As another example, the Will QoS includes information specifying the QoS level to use when initiating the Will message. As another example, the Will Retaion may include information indicating whether to keep the packet. As another example, the password flag may include information on whether or not a password exists in the payload. As such, the connection flag field may include various configuration information for the connection packet. That is, when the value of the connection packet is set as 1610, it can be shown that the Will Flag value is set to 1. [

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

Also, the lengths of the header and each area may be changed depending on the setting, if necessary.

17 is a diagram illustrating a structure of a connection packet payload according to an embodiment.

Referring to FIG. 17, the payload may include client module identifier information. Also, it can include a user name and a password as needed. The client module identifier information includes identification information for identifying the client module in the relay server, and may optionally include name information and a password for the corresponding user when set.

Even in this case, each area and payload length can be varied.

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

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

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

The variable header may also be composed of a reserved field (ex, set to 0), a remaining length field, and a linked 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.

The variable header may also include a Session Present Flag (SP) and a Reservation and Connection Response Code field. On the other hand, the payload can be omitted.

FIG. 19 is a diagram illustrating 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 composed of a fixed header, a variable header, and a payload. The fixed header can be set to two bytes, and the variable header and the payload can be set to have a variable length.

Like the connection packet, the fixed header may be composed of a reserved field, a packet type information field, and a remaining length field, and a value included in each field such as 1900 may be set. On the other hand, 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 QoS corresponding to the topic filter and the topic filter may be included in pairs.

FIG. 20 is a diagram illustrating a structure of a subscribe acknowledgment packet format, a fixed header, a variable header, and a payload according to an embodiment.

Referring to FIG. 20, the subscription confirmation packet including confirmation information on the subscription packet includes a fixed header, a variable header, and a payload.

Like the subscription packet, the fixed header may be composed of 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. [ On the other hand, the variable header may include packet identification information.

The payload may also include list information of the response code. Through this, the relay client module can acquire the processing result of the relay server for the subscription packet through the information set for each response code.

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

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

Referring to FIG. 21, a public packet includes a fixed header, a variable header, and a payload. For example, the fixed header may comprise RETAIN, a QoS level, a DUG flag, packet type information, and a residual length field.

For example, the fixed header may be composed of two bytes and may carry information allocated for each bit. For example, the QoS level field includes information about the QoS level of a packet or a relaying protocol. Also, the redundant transmission flag field includes information indicating whether the packet is a redundant transmission. In addition, the packet type field includes information indicating that the packet is a public packet.

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

Meanwhile, the payload of the public packet may include a request message or a 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, recipient identification information, and request identification information. In the case where the response message is included in the payload, the response message may include the request identification information and the response result code information.

FIG. 22 is a diagram illustrating another format of a public-key confirmation packet, a fixed header, and a variable header according to an embodiment of the present invention.

Referring to FIG. 22, the PUBACK packet may include at least one of a fixed header, a variable header, and a payload area.

Like the connection packet, the subscription packet, etc., the fixed header is composed of the reserved area, the packet type information area and the remaining length area, and the value included in each area may be included as shown in FIG. On the other hand, the variable header may include packet identification information. For example, through packet identification information, it is possible to indicate to which broadcast packet the corresponding broadcast confirmation packet is a response. In addition, the payload of the publish confirmation packet can be omitted.

The structure and fields of each packet described above are illustrative of 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 the two M2M devices communicates through a firewall, communication can be started from either of the two devices using the Internet protocol. In addition, even when both devices communicate through a firewall through a public IP network, both devices can start communication using the Internet protocol. In addition, the request message and the response message can be exchanged using the relay protocol, and the same application can be used in a plurality of devices. Also, collective processing functions can be performed using a relay protocol. Therefore, according to the present embodiment, it is possible to check whether the operation requested by the caller is correctly performed while preventing the increase of the traffic of the entire network.

Hereinafter, the configuration of the M2M device and the configuration of 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 an embodiment.

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, When the connection between the control unit 2310 and the relay server is established by receiving the response information for the connection packet for setting and establishing a connection with the relay server, the request message for transmission to another M2M device is included in the public packet, And a receiving unit 2330 for receiving from the relay server a public packet including a transmitting unit 2320 for transmitting the request message and a response message generated by another M2M device to the request message.

The transmitting unit 2320 transmits a connection packet for establishing a connection with the relay server to the relay server, and the receiving unit 2330 can receive the connection confirmation packet including the response information for the connection packet from the relay server.

Meanwhile, when the connection confirmation packet is received by the M2M device, the transmitter 2320 transmits the subscription packet to the relay server, and the receiver 2330 can receive the subscription confirmation packet. 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 the subscription confirmation packet and perform the connection setup.

The connection packet between the relay server and the relay client module may be configured in the following format. For example, the connection packet may consist of a 2-byte fixed header, a variable header, and a payload area. In addition, 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 area may include client module identifier information.

Meanwhile, the connection establishment procedure may be performed in the same manner as other M2M devices for performing communication with the M2M device. For example, another M2M device can establish a connection with a relay server through connection packet and connection acknowledgment packet transmission / reception procedures. Alternatively, the other M2M device may proceed with the connection packet and connection acknowledgment packet transmission / reception procedure with the relay server, and establish the connection through the connection packet and the connection acknowledgment packet transmission / reception procedure.

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

The public packet includes a fixed header, a variable header, and a payload field. The fixed header includes a QoS level field including information on a QoS level of a packet or a 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. The payload field may include a request message, and the request message may include request identification information. The request identification information includes information that can be included in a later response message to identify which response message is a response to the request message.

If necessary, the receiving unit 2330 may receive a publicity confirmation packet including response information for the public packet from the relay server. The public confirmation packet may include information on whether or not the public packet is normally received.

In addition, the transmitting unit 2320 transmits confirmation information about the public packet including the response message to the relay server in the publicity confirmation packet. The public confirmation packet may include information on whether or not the public packet is normally received. Also, as described above, the response message may be included in the payload of the public packet, and may include the request identification information and the response status code information. The request identification information may be set to the same value as the request message, indicating that the response message includes the result of the response to the request message. The response status code includes a code value for the processing result of the procedure required in the corresponding request message.

In addition, the control unit 2310 transmits the request message using the relay server according to the present embodiment, and controls the overall operation of the M2M apparatus 2300 according to receiving the response message.

The transmitting unit 2320 and the receiving unit 2330 are used to transmit and receive messages, signals, and data necessary for performing the present embodiment with at least one of the relay server, the other M2M device, and the relay client module.

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

24, a relay server 2400 for relaying communication between M2M devices via a public IP (Internet Protocol) network receives a connection packet for establishing connection from the relay client module of each of the M2M device and the other M2M devices A controller 2410 for establishing a connection with each of the M2M device and the other M2M devices, a receiver 2430 for receiving a public packet including a request message for transferring the request message from the relay client module of the M2M device to another M2M device, And a transmitting unit 2420 for transmitting the public packet including the received public packet to the relay client module of the other M2M device.

The receiving unit 2430 further receives a public packet including a response message to the request message from the relay client module of the other M2M device and the transmitting unit 2420 transmits the public packet including the response message to the relay client module of the M2M device Lt; / RTI >

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

Alternatively, the receiving unit 2430 receives the connection packet and the connection confirmation packet from the M2M device, and the transmission unit 2420 transmits a connection confirmation packet for the connection packet to each M2M device to perform connection setup It is possible. 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 the transmission of the request message of the M2M device requesting the connection establishment and information on the identification information related to the reception of the response message. Of course, information indicating that the corresponding M2M device is an object communication device packet using the M2M network may also be included.

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

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

Meanwhile, the public packet may include information indicating that it is a message communication message, information indicating a message type (request or response), identification information of the sender, and identification information of the receiver. Alternatively, the public packet is composed of a fixed header, a variable header, and a payload field, and the fixed header includes a QoS level field including information on the QoS level of the packet or the 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 transmitting unit 2420 may transmit a publicity confirmation packet including response information to the public packet to the M2M device. The public confirmation packet may include information on whether or not the public packet is normally received.

 When receiving the public packet, the control unit 2410 confirms the identification information of the target other M2M device indicated by the corresponding public packet, and the transmitting unit 2420 transmits a request message to the relaying client module of another connected M2M device A public packet can be transmitted. That is, when the broadcast packet is received from the relay client module, the control unit 2410 refers to the topic name and transmits the packet to the relay client module on the receiver side. The receiving unit 2430 may receive a publicity confirmation packet from the other M2M device that instructs the reception confirmation of the public packet including the request message. In addition, the transmitting unit 2420 may transmit a publicity confirmation packet for the public packet to another M2M device. Also, the receiving unit 2430 can receive the publish confirmation packet from the M2M device.

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

The transmitting unit 2420 and the receiving unit 2430 are used for transmitting and receiving messages, signals, and data necessary for performing the present embodiment with at least one of the other relay server, the M2M device, the other M2M device, and the relaying client module do.

The standard content or standard documents referred to in the above-mentioned embodiments constitute a part of this specification, for the sake of simplicity of description of the specification. Therefore, it is to be understood that the content of the above standard content and portions of the standard documents are added to or contained in the scope of the present invention.

The foregoing description is merely illustrative of the technical idea of the present invention, and various changes and modifications may be made by those skilled in the art without departing from the essential characteristics of the present invention. Therefore, the embodiments disclosed in the present invention are intended to illustrate rather than limit the scope of the present invention, and the scope of the technical idea of the present invention is not limited by these embodiments. The scope of protection of the present invention should be construed according to the following claims, and all technical ideas within the scope of equivalents should be construed as falling within the scope of the present invention.

Claims (20)

1. A method for a M2M (Machine to Machine Communication) device to communicate with another M2M device through a public IP (Internet Protocol) network,
Transmitting a connection packet for establishing a connection to a relay server through a relay client module, receiving response information for a connection packet for establishing the connection, and establishing a connection with the relay server;
When the connection with the relay server is established, including a request message for transmission to another M2M device in a public packet and transmitting the request message to the relay server; And
And receiving from the relay server a public packet including a response message generated by the other M2M device with respect to the request message. The method according to claim 1,
The relay server includes:
A middle node or an infrastructure node. The method according to claim 1,
The relay server includes:
Wherein the central node and the infrastructure node are independently configured to communicate with a middle node or a relay client module configured in the infrastructure node. The method according to claim 1,
The other M2M device,
Receiving a broadcast packet including the request message from the relay server after completion of connection establishment by performing a connection packet transmission / reception procedure with the relay server. The method according to claim 1,
The connection packet includes:
A 2-byte fixed header, a variable header, and a payload area,
The variable header includes a protocol name field, a protocol level field, a connection flag field, and a keep alive field,
Wherein the payload area comprises the client module identifier information. The method according to claim 1,
The public packet includes:
A fixed header, a variable header, and a payload area,
The fixed header includes a QoS level field including information on a QoS level of a packet or a relay protocol, a duplicate transmission flag field, and a packet type field,
Wherein the variable header comprises a topic name field and a packet identification field. A method for a relay server relaying communication between M2M (machine to machine communication) devices via a public IP (Internet Protocol) network,
Receiving a connection packet for establishing a connection from the relay client module of each of the M2M device and the other M2M devices, and establishing a connection with the M2M device and each of the other M2M devices;
Receiving a public packet including a request message for transfer from the relay client module of the M2M device to the other M2M device;
Transmitting a public packet including the request message to a relay client module of the other M2M device;
Receiving a public packet including a response message for the request message from a relay client module of the other M2M device; And
And sending a public packet containing the response message to a relay client module of the M2M device. 8. The method of claim 7,
The relay server includes:
A middle node or an infrastructure node. 8. The method of claim 7,
The connection packet includes:
A 2-byte fixed header, a variable header, and a payload area,
The variable header includes a protocol name field, a protocol level field, a connection flag field, and a keep alive field,
Wherein the payload area comprises the client module identifier information. 8. The method of claim 7,
The public packet includes:
A fixed header, a variable header, and a payload area,
The fixed header includes a QoS level field including information on a QoS level of a packet or a relay protocol, a duplicate transmission flag field, and a packet type field,
Wherein the variable header comprises a topic name field and a packet identification field. 1. An M2M (Machine to Machine Communication) device for performing communication with another M2M device via a public IP (Internet Protocol) network,
A control unit for transmitting a connection packet for establishing a connection to a relay server through a relay client module, receiving response information for a connection packet for establishing the connection, and establishing a connection with the relay server;
A transmitter for transmitting a request message for transmission to another M2M device in a public packet to the relay server when the connection with the relay server is established; And
And a receiving unit for receiving, from the relay server, a public packet including a response message generated by the other M2M device with respect to the request message. 12. The method of claim 11,
The relay server includes:
The middle node or the infrastructure node. 12. The method of claim 11,
The relay server includes:
Wherein the intermediate node and the infrastructure node are independently configured to perform communication with the relay node module configured in the middle node or the infrastructure node. 12. The method of claim 11,
The other M2M device,
Receiving a public packet including the request message from the relay server after completion of connection establishment by performing a connection packet transmission / reception procedure with the relay server. 12. The method of claim 11,
The connection packet includes:
A 2-byte fixed header, a variable header, and a 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 area includes the client module identifier information. 12. The method of claim 11,
The public packet includes:
A fixed header, a variable header, and a payload area,
The fixed header includes a QoS level field including information on a QoS level of a packet or a relay protocol, a duplicate transmission flag field, and a packet type field,
Wherein the variable header comprises a topic name field and a packet identification field. 1. A relay server for relaying communication between M2M (machine to machine communication) devices via a public IP (Internet Protocol) network,
A controller for receiving a connection packet for establishing a connection from the relay client module of each of the M2M device and the other M2M devices and establishing connection with the M2M device and each of the other M2M devices;
A receiving unit for receiving a public packet including a request message for transfer from the relay client module of the M2M device to the other M2M device; And
And a transmitter for transmitting the public packet including the request message to the relay client module of the other M2M device,
Wherein the receiving unit further receives a public packet including a response message for the request message from the relay client module of the other M2M device,
Wherein the transmitter further transmits a public packet including the response message to the relay client module of the M2M device. 18. The method of claim 17,
The relay server includes:
A middle node or an infrastructure node. 18. The method of claim 17,
The connection packet includes:
A 2-byte fixed header, a variable header, and a payload area,
The variable header includes a protocol name field, a protocol level field, a connection flag field, and a keep alive field,
Wherein the payload area includes the client module identifier information. 18. The method of claim 17,
The public packet includes:
A fixed header, a variable header, and a payload area,
The fixed header includes a QoS level field including information on a QoS level of a packet or a relay protocol, a duplicate transmission flag field, and a packet type field,
Wherein the variable header includes a topic name field and a packet identification field.

Images