[go: up one dir, main page]

WO2018199523A1 - Procédé de traitement de communication de machine à machine via un réseau ip public, et appareil associé - Google Patents

Procédé de traitement de communication de machine à machine via un réseau ip public, et appareil associé Download PDF

Info

Publication number
WO2018199523A1
WO2018199523A1 PCT/KR2018/004373 KR2018004373W WO2018199523A1 WO 2018199523 A1 WO2018199523 A1 WO 2018199523A1 KR 2018004373 W KR2018004373 W KR 2018004373W WO 2018199523 A1 WO2018199523 A1 WO 2018199523A1
Authority
WO
WIPO (PCT)
Prior art keywords
packet
connection
relay server
relay
publish
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/KR2018/004373
Other languages
English (en)
Korean (ko)
Inventor
김상언
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
KT Corp
Original Assignee
KT Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from KR1020180042814A external-priority patent/KR102092100B1/ko
Application filed by KT Corp filed Critical KT Corp
Publication of WO2018199523A1 publication Critical patent/WO2018199523A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications

Definitions

  • the present invention relates to a private IP-based IoT communication method and apparatus through a public IP in a machine to machine communication (M2M) system.
  • M2M machine to machine communication
  • M2M "Machine to machine communication” or MTC, “Machine type communication” or smart device communication, “Smart Device communication” or “Machine oriented communication” or the Internet of Things, “Internet of Things” is a human communication process Refers to all communication methods in which communication is performed without intervening.
  • a plurality of things communication devices are used in homes and workplaces, and there are situations in which a plurality of things communication devices that perform the same or similar functions are deployed for a certain purpose.
  • a plurality of things communication devices may be deployed in the same network or may be deployed in different networks. For example, there may be a need for communication between things configured in different private networks.
  • the thing communication network defines only a communication protocol between the thing communication devices existing in the same network, and does not consider communication between the thing communication devices included in different networks.
  • an embodiment of the present invention is to provide a method and apparatus for enabling a thing communication device using a private IP to communicate with a thing communication device using an external private IP so that the thing communication device using a private IP can be performed.
  • a relay server relays communication between machine-to-machine communication (M2M) devices through a public IP (Internet Protocol) network, and establishes a connection setting from a relay client module of each M2M device and another M2M device.
  • M2M machine-to-machine communication
  • Receiving a connection packet for receiving the connection packet establishing a connection with each of the M2M device and another M2M device, receiving a publish packet including a request message for transmitting from the relay client module of the M2M device to another M2M device, and a request message.
  • Sending to the relay client module of the M2M device It provides a way.
  • an embodiment is a machine to machine communication (M2M) device that communicates with other M2M devices through a public IP (Internet Protocol) network, the connection packet for establishing a connection to a relay server through a relay client module
  • M2M machine to machine communication
  • An M2M device including a transmitter for transmitting to a relay server and a request packet for receiving a publish packet including a response message generated by another M2M device from a relay server is provided.
  • an embodiment is a relay server for relaying communication between machine to machine communication (M2M) devices through a public IP (Internet Protocol) network, the connection for establishing the connection from the relay client module of each of the M2M device and other M2M devices
  • a receiving unit for receiving a packet a receiving unit for receiving a publish packet including a control unit for establishing a connection with each of the M2M device and another M2M device, and a request message for transmitting from the relay client module of the M2M device to the other M2M device.
  • a transmitter for transmitting a publish packet to a relay client module of another M2M device, wherein the receiver further receives a publish packet including a response message for a request message from a relay client module of another M2M device.
  • Relay client module containing the publish packet containing the M2M device Provides a relay server for further transmission.
  • the present disclosure provides an effect that a plurality of things communication devices using different private IPs can send and receive messages smoothly through a public IP.
  • the present disclosure provides an effect of transmitting and receiving data as needed without restriction of a public or private IP between the thing communication devices configured in different networks.
  • FIG. 1 is a diagram illustrating an M2M system from a high level functional point of view.
  • FIG. 3 is a diagram exemplarily illustrating a procedure of transmitting a request message and corresponding response information in an M2M system.
  • FIG. 4 illustrates a functional structure of a common service entity according to an embodiment.
  • FIG. 5 is a view for explaining a problem that may occur when using a public IP and a private IP.
  • FIG. 6 is a diagram illustrating a problem that may occur when communication is performed between M2M devices using private IP via a public IP network.
  • FIG. 7 is a diagram illustrating an operation of an M2M device according to an embodiment.
  • FIG. 8 is a diagram for describing an operation of a relay server according to an exemplary embodiment.
  • FIG. 9 is a diagram exemplarily illustrating a structure in which a relay server is integrated with an M2M device according to an embodiment.
  • FIG. 10 is a diagram illustrating a structure in which a relay server is configured independently according to an embodiment.
  • 11 is a diagram illustrating a procedure for establishing a connection with a relay server using a connection packet according to an embodiment.
  • FIG. 12 is a diagram for describing a procedure of establishing a connection with a relay server using a connection packet according to another embodiment.
  • FIG. 13 is a diagram for describing a procedure of delivering a message using a publish packet, according to an exemplary embodiment.
  • FIG. 14 is a diagram for describing a procedure of delivering a message using a publish packet, according to another exemplary embodiment.
  • connection packet format 15 illustrates a structure of a connection packet format and a fixed header according to an embodiment.
  • connection packet variable header illustrates a structure of a connection packet variable header according to an embodiment.
  • connection packet payload 17 illustrates a structure of a connection packet payload according to an embodiment.
  • connection confirmation packet format is a diagram illustrating a connection confirmation packet format and the structure of each header according to an embodiment.
  • 19 illustrates a structure of a subscribe packet format, a fixed header, a variable header, and a payload according to an embodiment.
  • 20 illustrates a structure of a subscribe confirmation packet format, fixed header, variable header, and payload according to an embodiment.
  • 21 is a diagram illustrating a publish packet format, a fixed header, and a variable header structure according to an embodiment.
  • FIG. 22 is a diagram illustrating a publish confirmation packet format, a fixed header, and a variable header structure according to an embodiment.
  • FIG. 23 is a diagram illustrating a structure of an M2M device according to one embodiment.
  • 24 is a diagram illustrating a structure of a relay server according to an embodiment.
  • Embodiments of the present invention will be described based on communication of things.
  • IoT can be variously referred to as Machine to Machine communication (M2M), Machine Type Communication (MTC), Internet of Things (IoT), Smart Device Communication (SDC), or Machine Oriented Communication. Can be.
  • M2M Machine to Machine communication
  • MTC Machine Type Communication
  • IoT Internet of Things
  • SDC Smart Device Communication
  • M2M has presented many technical matters related to IoT.
  • the thing communication refers to various communication in which a communication is made without a person intervening in a communication process.
  • IoT is the energy sector, the enterprise sector, the healthcare sector, the public services sector, the residential sector, the retail sector, the transportation sector, and others. It is divided into fields.
  • the present invention includes the above fields, and can be applied to other fields.
  • FIG. 1 illustrates an M2M system according to an embodiment from a high level functional perspective.
  • Application Entity (AE) 110 provides application service logic for an end-to-end M2M solution.
  • AE application service logic
  • it may be a collective tracking application such as a vehicle, a remote blood sugar monitoring application, or a remote power metering and controlling application.
  • Common Services Entity (CSE) 120 includes energy, enterprise, healthcare, public services, residential, retail This is a collective service function that is commonly required in the field of transportation, transportation, and other fields.
  • Underlying Network Services Function (NSF) 130 provides a service to a common service entity. Examples of services include device management, location services and device triggering.
  • Mca Reference Points are supported by Common Service Entities (CSEs). Mca Reference Points are reference points for providing communication between application objects and Common Service Entities. The Mcc reference point is a reference point for providing communication thing communication between two common service entities. Mcn reference point is a reference point for providing the communication between the common service entity and one network service entity.
  • CSEs Common Service Entities
  • the Mca reference point allows one application entity (AE) to use the services supported by the common service entity.
  • Services provided through the Mca reference point are dependent on the functionality provided by the common service entity, and the application entity and the common service entity can exist in the same physical entity or in separate physical entities.
  • the Mcc reference point makes such use available to common service entities that wish to use the services of other common service entities that provide the necessary functionality. Services provided through the Mcc reference point depend on the functionality provided by the common service entity.
  • Mcc reference points may be supported between different M2M nodes.
  • the Mcn reference point enables such use for common service entities that wish to use service entities in the underlying network that provide the necessary functionality, which provides services other than transport and connectivity.
  • An instance of the Mcn reference point is implemented dependent on the services provided by the underlying network. Information exchange between two physical M2M nodes may use transport and connectivity services of an underlying network providing basic services.
  • a common service entity may be described as a CSE
  • a network service entity may be described as a network service entity (NSE).
  • the M2M device in the present specification means a CSE or AE, or means a device including the CSE or AE, and means a device or a terminal constituting the M2M system.
  • FIG. 2 is a diagram illustrating in more detail an M2M system configuration diagram according to an embodiment.
  • an infrastructure node 250 performs a server function essential for providing M2M communication.
  • the base node 250 is composed of a base node application entity (AE) 252 and a base node common service entity (CSE) 254.
  • the base node common service entity 254 is configured using various resources. 252 and 254 are distinguished through Mca reference points, and are required for MSOs, especially request messages for creating, deleting, updating, retrieving, and notifying scheduler resources. It is used to construct and process response messages.
  • the relay node 200 relays M2M communication or Internet of Things, IoT communication functions of the application service node 220 and the base node 250.
  • the relay node 200 includes a relay node application object 202 and a relay node common service object 204.
  • the relay node common service entity 204 is configured using various resources. 202 and 204 are distinguished using Mca reference points, and 254 and 204 are distinguished using Mcc reference points, and messages necessary for MOT communication, in particular, create, delete, update, and Used to construct and process request and response messages to retrieve and notify.
  • the application service node 210 may be composed of an application object 212 and a relay node common service object 214.
  • the application object 212 handles application functions required for the purpose of the device.
  • the common service object 214 of the application service node 210 is configured using various resources. 212 and 214 are distinguished by Mca reference points, and 214 and 254 are distinguished by Mcc reference points, and messages necessary for MOT, in particular, create, delete, update, and Used to construct and process request and response messages to retrieve and notify.
  • the application service node 220 may perform a thing communication function with the base node 250 through the relay node 200. The difference between 210 and 220 is that the communication interface constituting the node is different.
  • the application-only nodes 230 and 240 do not have a common service object, and are intended to communicate with only the application object 242.
  • 230 is a case of communicating with 250 using a communication interface such as 3G, LTE, Ethernet, Gigabit Ethernet, ADSL, etc.
  • 240 is a case of 200 through 250 using an interface capable of ultra short-range communication such as Bluetooth, ZigBee, Zwave, and WiFi. Communicate with
  • the M2M system may be configured with at least one or more of a base node, a relay node, an application service node, and an application-only node, and each node may be configured to include a CSE or an AE.
  • the CSE and the AE may communicate with other CSEs or AEs through their respective reference points.
  • the originator 300 transmits a request message to a receiver 310 (S320).
  • the sender 300 and the receiver 310 may each be M2M devices, and may be CSE or AE as described above.
  • sender 300 and receiver 310 may be nodes or servers or devices that include CSE or AE.
  • the request message may include one or more parameters.
  • the request message may include mandatory and optional parameters.
  • the From parameter, the To parameter, the Request Identifier parameter, and the Operation parameter are included as essential parameters.
  • the From parameter contains information about the sender who sends the message
  • the To parameter contains information about the recipient who receives the message.
  • the Request Identifier parameter contains unique identification information for identifying the corresponding request message.
  • the Operation parameter includes information for identifying the operation requested in the request message.
  • the operation parameter may be set to any one of Create, Retrieve, Update, Delete, and Notify.
  • optional parameters may be added to control various operations of the request message.
  • an optional parameter of Response Type can block the receiver's handling, blockingRequest, non-BlockingRequestSynch, non-BlockingRequestAsynch, and flexBlocking. Can be specified.
  • the receiver 310 When the request message is received, the receiver 310 performs an operation for processing the request message (S330). For example, the receiver 310 may check whether the sender 300 that has sent the request message has the authority for the request. When it is determined that the sender 300 has the authority for the request, the sender 300 processes the request message after checking whether the requested resource exists. Alternatively, the receiver 310 may perform a corresponding operation according to the operation parameter of the request message. For example, when an operation parameter is set to creation and a subscription function is set to instruct the sender 300 when a change, addition, or deletion of specific data occurs, the receiver 310 receives subscription information. When an event such as a change, addition, deletion, etc. occurs in the data corresponding to the subscription information, the caller 300 may be notified to the caller 300.
  • the receiver 310 generates the processing result information according to the request operation and includes it in the response message and transmits it to the sender 300 (S340). Operation S340 may be performed before operation S330. That is, when the receiver 310 receives the request message, the receiver 310 generates an ACK response message indicating the simple reception of the request message and transmits it to the sender 300, and then performs the step S330 to process the request message.
  • 4 is a diagram for configuring a common service entity according to an embodiment of the present invention. 4 includes a processing function of identification information.
  • the functions provided by the common service entity can be summarized as shown in FIG. 4 by addressing & identification, application and service layer management, data management & storage, location, Security, Communication Management / Delivery Handling, Registration, Service Session Management, Device Management, Subscription / Notification, Connection Management (Connectivity Management), Discovery, Service Charging / Accounting, Network Service Exposure / Service Execution and Triggering, Group Management.
  • ASM Application and Service Layer Management
  • CMDH Communication Management and Delivery Handling
  • CSE-CSE communication communication connection
  • CMDH is performed according to the provisioned policies and delivery handling parameters specific to each request for communication.
  • the underlying network may support the same forwarding handling function.
  • the CMDH can use the underlying network and can act as a front end that accesses the same forwarding handling capabilities for the underlying network.
  • DMR Data Management and Repository
  • the DMR CSF provides data storage space and the ability to coordinate it. It also includes the ability to collect and combine large amounts of data, convert the data into a specific format, or store the data for analysis and semantic processing.
  • Data may refer to raw data that is transparently extracted from an M2M device or may mean data that has been processed or calculated or combined by an M2M entity. Collecting large amounts of data constitutes what is known as big data storage.
  • the Device Management (DMG) CSF is responsible for managing device functions of devices in MNs, device nodes, and M2M local area networks. Enable device management to provide one or more of the following features: It includes installation and setting of application software, configuration setting and provisioning, firmware update, logging and monitoring and analysis, topology management of local network, and devices in local network management.
  • the CSF is responsible for retrieving information and resources that correspond to the permissions granted within a given scope and topic (including those granted by M2M service subscriptions) and within the scope of the originator's request.
  • the sender can be an application or another CSE.
  • the scope of the search can be one CSE or multiple CSEs.
  • the search result is sent to the caller.
  • Group Management handles groups associated with the request. Requests are sent for the management of groups and their membership, and are also responsible for the bulk operations supported by the group. When you add or remove members from a group, you need to make sure that the members conform to the group's purpose. Bulk operations include reading, writing, subscribing, informing, and device management. Requests or subscriptions are made through a group, and the group is responsible for combining these requests and notifications. Members of the group have the same role for access to resources. In this case, access control is by group. If the underlying network provides broadcasting and multicasting capabilities, the GMG CSF should take advantage of these features.
  • Network Service Exposure (NSE) CSF manages communication with the underlying network to access network service functions through Mcn reference points in an available or supportable manner for service requests from M2M systems on behalf of M2M applications.
  • the NSE CSF hides other CSFs and AFs from the specific technologies and mechanisms supported in the underlying network.
  • Network service functions provided from the underlying network include, but are not limited to, device triggering, small data transfer, location notification, policy rule settings, location query, IMS service, device management, and the like. These features do not include general transport services
  • REG Registration
  • the REG CSF handles the registration of the device's properties / properties as well as the device's registration with the CSE.
  • SEC SEC
  • Sensitive data handling provided by the SEC CSF provides protection for local credentials that require security during storage and manipulation. Sensitive data handling also uses security algorithms.
  • This feature supports a secure environment with various cryptographic techniques.
  • the security operations function provides the following functions: first, it creates and operates the security environment dedicated to be supported by the sensitive data handling function. It also supports post-provisioning of root credentials protected in a secure environment, and supports the provisioning and operation of subscriptions related to M2M services and M2M application services.
  • the security association configuration feature establishes a security association between M2M nodes to enable confidentiality, integration, authentication, and authorization.
  • Authorization and access control controls service and data access to authorized objects according to provisioned security policies and assigned roles.
  • the unique identifier of the entity is used for authorization, and the identity protection feature can provide anonymity, which acts as a temporary identifier so that it is not linked to the actual identifying information associated with the entity or user.
  • SCA Service Charging and Accounting
  • the SCA CSF secures billable events, stores information, and generates billing records and billing information.
  • the SCA CSF can interact with the charging system of the underlying network. However, the SCA CSF is responsible for generating and recording billing information at the final service level.
  • the SCA CSF of the base node or service layer charging server is responsible for handling the charging information for charging.
  • SSM Service Session Management
  • the SSM CSF manages M2M service sessions, which are end-to-end service layer connections.
  • the SSM CSF manages M2M service sessions between M2M applications, or between M2M applications and CSEs, or between CSEs.
  • the management of M2M service sessions includes session state management, session authentication and establishment, management of underlying network connections and services associated with the session, coordination of session extensions in the CSE's multi-hop cse, exchange of information between session ends, and session termination. Include.
  • the SSM CSF uses the CMDH CSF in the local CSE to send and receive messages to / from the next hop CSE or application within a given M2M service session.
  • the SSM CSF uses the SEC CSF for session management related to the security credentials and authentication of session participants.
  • the SSM CSF generates session-specific billing events and also communicates with the SCA CSF in the local CSE.
  • Subscription and Notification provides a notification to keep a subscription and tracks resource changes (eg, deletion of resources). Subscriptions to resources are initiated by the M2M AE or CSE and are granted access by the hosting CSE. During an active subscription, the hosting CSE sends a notification to the address the resource subscriber wants to receive when a change in the subscribed resource occurs.
  • M2M identifiers include M2M Service Provider Identifier (M2M-SP-ID), Application Instance Identifier (App-Inst-ID), Application Identifier (App-ID), CSE Identifier (CSE-ID), M2M-Node-ID (M2M Node Identifier / Device Identifier), M2M Service Subscription Identifier (M2M-Sub-ID), and Request Identifier (M2M-Request-ID).
  • M2M Service Provider Identifier M2M-SP-ID
  • App-Inst-ID Application Instance Identifier
  • App-ID Application Identifier
  • CSE-ID CSE Identifier
  • M2M-Node-ID M2M Node Identifier / Device Identifier
  • M2M Service Subscription Identifier M2M-Sub-ID
  • Request Identifier M2M-Request-ID
  • oneM2M is a requirement that must be met to implement the system.
  • the M2M device in the present specification will be described by describing the various nodes including the above-described AE, CSE, NSE, etc., and for the sake of understanding, the description will be made based on the hosting CSE. no. That is, the M2M device refers to a component device constituting the M2M system, and refers to various nodes, devices, entities, etc. that receive a request message, perform a processing thereof, and transmit a response message.
  • FIG. 5 is a diagram illustrating a problem that may occur when using a public IP and a private IP
  • FIG. 6 may occur when communicating between M2M devices using a private IP via a public IP network. It is a figure for demonstrating a problem.
  • the M2M devices 500 and 550 may be configured in different network networks.
  • 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.
  • the M2M device # 1 500 is connected to the M2M device # 2 550 through TCP / IP through a firewall to perform communication.
  • communication may not be performed smoothly due to a communication problem between the private IP network and the public IP network.
  • the M2M device # 2 550 using the public IP may not start communication when communicating with the M2M device # 1 500 using the private IP.
  • no M2M device can start communication when performing communication between public M2M devices 500 and 550 using a private IP.
  • the M2M device using the private IP has a problem that communication is possible only when starting communication in the M2M device using the private IP.
  • the present disclosure proposes a specific method of performing a communication of things by a private IP based M2M device via a public IP in an M2M system.
  • it presents a detailed procedure for the M2M device using the public IP to communicate with the M2M device using the private IP, and presents a specific procedure for performing communication of things between the M2M device using the private IP.
  • the M2M device described below refers to an entity using a private IP or a public IP
  • another M2M device that exchanges messages with the corresponding M2M device also refers to an entity using a private IP or public IP.
  • the M2M device and the other M2M devices are configured at locations causing the problems described above by the public IP network.
  • the M2M device uses a private IP
  • another M2M device may use a public IP or use a private IP different from the M2M device.
  • another M2M device may use a private IP.
  • the relay server in the present specification means an entity for transmitting a message transmitted by the M2M device or another M2M device and may include a relay module, a delivery server, a relay protocol server, and the like.
  • the relay server may operate based on various protocols for delivering messages of M2M devices.
  • the relay server may operate with a message queuing telemetry transport (MQTT) based protocol. That is, the relay server may mean an MQTT module, an MQTT server, or the like.
  • the relay client module may mean an MQTT client module.
  • FIG. 7 is a diagram illustrating an operation of an M2M device according to an embodiment.
  • a machine to machine communication (M2M) device transmits a connection packet for establishing a connection to a relay server through a relay client module, and receives response information for the connection packet for establishing a connection with the relay server.
  • a step of establishing a connection may be performed (S700). For example, an M2M device is connected to another M2M device using another private IP via a public IP network, or another M2M device using a private IP or another M2M device using a private IP (when the M2M device uses public IP).
  • the connection to the relay server may be set first.
  • the M2M device may transmit a connection packet for establishing a connection with the relay server to the relay server, and receive a connection confirmation packet including response information about the connection packet from the relay server.
  • the M2M device may transmit and receive a connection packet and a connection confirmation packet through a relay client module connected to the M2M device.
  • the M2M device may receive a connection confirmation packet and perform connection establishment.
  • the relay client module may be a module configured inside the M2M device when the M2M device is a node, or may be a separate module configured in the same node when the M2M device is an AE or CSE.
  • an M2M device is described as a node including an AE or CSE and a relay client module.
  • the present disclosure is not limited thereto, and the present disclosure may be equally applied under the assumption that each entity is associated with a relay client module. have.
  • the M2M device may transmit a subscription packet to the relay server and receive a subscription confirmation packet thereto.
  • the subscription packet may include identification information for identifying the AE or CSE of the corresponding M2M device in the relay server.
  • the M2M device may receive a subscription confirmation packet and perform connection establishment.
  • the concatenated packet may consist of two bytes of fixed header, variable header and payload area.
  • the variable header may include a protocol name field, a protocol level field, a connection flag field, and a keep alive field
  • the payload region may include client module identifier information.
  • the relay server may be configured independently from the middle node and the infrastructure node that is a node constituting the M2M system.
  • the middle node and the infrastructure node may communicate with an independently configured relay server using the relay client module.
  • the relay server may be configured in the middle node or the infrastructure node which is a node constituting the M2M system. Even in this case, a relay client module for communicating with each entity configured in the relay server and the middle node or infrastructure node may be configured in each node.
  • connection establishment procedure may be performed in the same manner with other M2M devices for communicating with the M2M device.
  • another M2M device may establish a connection with the relay server through a procedure for transmitting and receiving a connection packet and a connection confirmation packet.
  • the other M2M device may perform a connection packet and a connection confirmation packet transmission / reception procedure with the relay server, and establish a connection through the transmission and reception of a subscription packet and a subscription confirmation packet.
  • the M2M device may include a request message for transmission to another M2M device in a publish packet and transmit it to the relay server (S710).
  • the M2M device when the M2M device establishes a connection with the relay server and completes the connection setting, the M2M device transmits a request message for sending to another M2M device in the publish packet to the relay server.
  • the publish packet may include information indicating that the message is a thing communication message, information indicating a message type (request or response), identification information of the sender, and identification information of the receiver.
  • the publish packet includes a fixed header, a variable header, and a payload region
  • the fixed header includes a QoS level field, a duplicate transmission flag field, and a packet type field, which include information on the QoS level of the packet or relay protocol.
  • the variable header may include a topic name field and a packet identification field.
  • the payload area may include a request message and request information may be included in the request message.
  • the request identification information may be included in a response message later to identify information on which request message the response message is a response to.
  • the M2M device may receive a publish confirmation packet from the relay server including response information about the publish packet.
  • the publish confirmation packet may include information on whether the publish packet is normally received.
  • the M2M device may perform a step of receiving a publish packet including a response message generated by another M2M device with respect to the request message from the relay server (S720).
  • the relay server may transmit the publish packet in step S710 to another M2M device, and may transmit a publish packet including a response message received from another M2M device to the M2M device.
  • the M2M device may receive a publish packet including a response message to the request message from the relay server through the relay client module. If necessary, the M2M device transmits acknowledgment information about the publish packet including the response message to the relay server in the publish acknowledgment packet.
  • the publish confirmation packet may include information on whether the publish packet is normally received.
  • the response message may be included in the payload of the publish packet, and the response message may include request identification information and response status code information.
  • the request identification information may be set to the same value as the request message to indicate which request message the response message includes.
  • Packet exchange between the relay client module and the relay server may be performed according to the relay protocol, and data exchange between the relay client module and the M2M entity (ex, AE or CSE) may be performed by the M2M protocol.
  • M2M entity ex, AE or CSE
  • each M2M device is based on a connection setting even when each M2M device is located in a different network or via a public IP network. You can start communicating.
  • FIG. 8 is a diagram for describing an operation of a relay server according to an exemplary embodiment.
  • the relay server may receive a connection packet from M2M devices that want to perform communication through the relay server, and perform connection establishment based on the connection packet.
  • the connection packet may be received from a relay client module that may be configured in each M2M device.
  • the relay server may transmit a connection confirmation packet including response information about the connection packet to each M2M device.
  • the relay server may receive a subscription packet from each M2M device after receiving a connection packet and transmitting a connection confirmation packet, and transmit a subscription confirmation packet for the subscription packet to each M2M device to perform connection establishment.
  • the subscription packet may include identification information for the M2M device requesting connection establishment.
  • the subscription packet may include identification information related to transmission of a request message of the M2M device requesting connection establishment and information on identification information related to reception of a response message.
  • the information indicating that the M2M device is a M2M packet using the M2M network may be included.
  • the relay server may be configured independently of the middle node and the infrastructure node, which are nodes constituting the M2M system.
  • the middle node and the infrastructure node may communicate with an independently configured relay server using the relay client module.
  • the relay server may be configured in the middle node or the infrastructure node which is a node constituting the M2M system. Even in this case, a relay client module for communicating with each entity configured in the relay server and the middle node or infrastructure node may be configured in each node.
  • the relay server may perform a step of receiving a publish packet including a request message for transmitting to another M2M device from the relay client module of the M2M device (S810).
  • the relay server may receive a request message for the M2M device to transmit to another M2M device from the relay client module through a publish packet.
  • the publish packet may include information indicating that the message is a thing communication message, information indicating a message type (request or response), identification information of the sender, and identification information of the receiver.
  • the publish packet is composed of a fixed header, a variable header and a payload area, the fixed header includes a QoS level field, information on the QoS level of the packet or relay protocol, a duplicate transmission flag field and a packet type field,
  • the variable header may include a topic name field and a packet identification field.
  • the relay server may transmit a publish confirmation packet including response information to the publish packet to the M2M device.
  • the publish confirmation packet may include information on whether the publish packet is normally received.
  • the relay server may perform a step of transmitting a publish packet including a request message to a relay client module of another M2M device (S820). For example, when a publish packet is received, the relay server checks identification information of another target M2M device indicated by the publish packet, and transmits a publish packet including a request message to a relay client module of another connected M2M device. Can be. That is, when a publish packet is received from the relay client module, the relay server transmits the packet to the relay client module at the receiver by referring to the topic name.
  • the relay server may transmit the publish packet to another M2M device which is a receiver of the request message according to the identification information of another M2M device confirmed through the subscription packet using the publish packet received from the M2M device. Since the other M2M device performs a connection setup process with the relay server before receiving the publish packet, even if the relay server uses a public IP network, it may transmit a publish packet including a request message to another M2M device using a private IP.
  • the relay server may receive a publish acknowledgment packet instructing receipt of a publish packet including a request message from another M2M device.
  • the relay client module of another M2M device may transmit the request message of the publish packet to the AE or CSE of the M2M device.
  • the relay server may transmit a publish confirmation packet for the publish packet to another M2M device.
  • the relay server may perform a step of transmitting the publish packet including the response message to the relay client module of the M2M device (S840).
  • the relay server may check the receiver identification information of the publish packet including the response message, and transmit the publish packet including the response message to the M2M device indicated by the corresponding receiver identification information.
  • the relay server may receive a publish confirmation packet from the M2M device.
  • the relay client module of the M2M device receives the publish packet from the relay server and delivers a response message included in the publish packet to the AE or CSE of the M2M device.
  • the relay client module of the M2M device may transmit a publish acknowledgment packet indicating whether to normally receive the publish packet to the relay server.
  • the relay server may control the M2M device and another M2M device to perform a smooth communication by relaying an operation of transmitting and receiving data through a public IP network.
  • the relay server may be configured to be included in the infrastructure node or the middle node, or may be configured independently to communicate with the infrastructure node or the middle node.
  • each operation in FIGS. 7 and 8 may be separated from each step as necessary, or the order thereof may be changed, and a part of the above description may be added as a step.
  • FIG. 9 is a diagram illustrating a structure in which a relay server is integrated with an M2M device according to an embodiment
  • FIG. 10 is a diagram illustrating a structure in which a relay server is independently configured according to an embodiment. .
  • the relay server may be included in a middle node or an infrastructure node.
  • the M2M device of the ADN or ASN may exchange packets with the relay server through the relay client module.
  • the middle node may send and receive packets with the relay server of the middle node or the infrastructure node through the relay client module.
  • the relay server may be configured independently of a node of the M2M system.
  • the relay server may transmit and receive a packet through a relay client module and at least one of a node such as ASN and ADN, a middle node, and an infrastructure node.
  • the relay server may be configured to coexist with or independently of the M2M system to perform the aforementioned packet exchange operation.
  • the M2M device may be described as an AE or a caller as needed, and another M2M device may be described as a CSE or a receiver.
  • 11 is a diagram illustrating a procedure for establishing a connection with a relay server using a connection packet according to an embodiment.
  • the AE 1100 performs initial access to the relay client module 1110 to access the relay server 1150 (S1101).
  • the relay client module 1110 transmits a connection packet to the relay server 1150 (S1102).
  • the CSE 1190 also performs initial access to the relay client module 1180 to establish a connection (S1103), and the relay client module 1180 transmits a connection packet to the relay server 1150 (S1104).
  • the AE 1100, the CSE 1190 and the relay client modules 1110 and 1180 may use the M2M protocol instead of the relay protocol domain, and the relay client modules 1110 and 1180 and the relay server 1150 may be used.
  • the relay protocol domain can be used.
  • the M2M message according to the M2M protocol may include a request message and a response message, and the M2M message may be expressed in Extensible Markup Language (XML), JavaScript Object Notation (JSON), and Concise Binary Object Representation (CBOR). At least one may be used. Accordingly, the relay client modules 1110 and 1180 may convert the M2M message into the relay protocol.
  • XML Extensible Markup Language
  • JSON JavaScript Object Notation
  • CBOR Concise Binary Object Representation
  • the Topic Name of the subscription packet may be set to 'oneM2M / req / + / SP-relative-AE-ID' or 'oneM2M / resp / SP-relative-AE-ID / +'.
  • the Topic Filter of the subscription packet may be set to '/ oneM2M / req / + / SP-relative-AE-ID' or '/ oneM2M / resp / SP-relative-AE-ID / +'.
  • the relay client module 1110 of the AE 1100 transmits a subscription packet to the relay server 1150 (S1105), and the relay client module 1180 of the CSE 1190 also subscribes to the relay server 1150.
  • the packet is transmitted (S1106).
  • the subscription packet may include information indicating the M2M system, AE identification information related to the request message, and AE identification information related to the response message.
  • 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.
  • the AE 1100 and the CSE 1190 may establish connection with the relay server 1150.
  • FIG. 12 is a diagram for describing a procedure of establishing a connection with a relay server using a connection packet according to another embodiment.
  • the relay server 1150 may transmit an acknowledgment packet (ACK) for the packet during the connection establishment process.
  • ACK acknowledgment packet
  • the AE 1100 performs initial access to the relay client module 1110 to access the relay server 1150 (S1210).
  • the relay client module 1110 transmits a connection packet to the relay server 1150 (S1220).
  • the relay server 1150 may transmit a connection confirmation packet CONNACK to the relay client module 1110 including information indicating whether the connection packet is normally received (S1230).
  • the CSE 1190 also performs initial access to the relay client module 1180 for connection establishment (S1240), and the relay client module 1180 transmits a connection packet to the relay server 1150 (S1250).
  • the relay server 1150 may transmit a connection confirmation packet CONNACK to the relay client module 1180 including information indicating whether the connection packet is normally received (S1260).
  • the AE 1100, the CSE 1190, and the relay client modules 1110 and 1180 may use the M2M protocol instead of the relay protocol domain, and the relay client modules 1110 and 1180 and the relay server 1150 may relay.
  • Protocol domains can be used.
  • the M2M message according to the M2M protocol may include a request message and a response message, and the M2M message may be expressed in Extensible Markup Language (XML), JavaScript Object Notation (JSON), and Concise Binary Object Representation (CBOR). At least one may be used. Accordingly, the relay client modules 1110 and 1180 may convert the M2M message into the relay protocol.
  • XML Extensible Markup Language
  • JSON JavaScript Object Notation
  • CBOR Concise Binary Object Representation
  • the Topic Name of the subscription packet may be set to 'oneM2M / req / + / SP-relative-AE-ID' or 'oneM2M / resp / SP-relative-AE-ID / +'.
  • the Topic Filter of the subscription packet may be set to '/ oneM2M / req / + / SP-relative-AE-ID' or '/ oneM2M / resp / SP-relative-AE-ID / +'.
  • the relay client module 1110 of the AE 1100 transmits a subscription packet to the relay server 1150 (S1270), and the relay client module 1180 of the CSE 1190 also subscribes to the relay server 1150.
  • the packet is transmitted (S1280).
  • 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.
  • 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.
  • the AE 1100 and the CSE 1190 may establish connection with the relay server 1150.
  • the M2M device may communicate with the relay server using the publish packet.
  • FIG. 13 is a diagram for describing a procedure of delivering a message using a publish packet, according to an exemplary embodiment.
  • the AE 1100 transmits a request message to the relay client module 1110 in the form of an M2M message (S1310).
  • the relay client module 1110 transmits a publish packet to the relay server 1150 (S1320).
  • the relay client module 1110 may include the request message in the payload according to the publish packet format and transmit the request message.
  • the relay server 1150 transmits the received publish packet to the receiving side relay client module 1180 of the request message (S1330).
  • the relay client module 1180 converts the request message included in the payload of the publish packet into an M2M message and transmits it to the CSE 1190 (S1340).
  • the AE 1100 may transmit a request message to the CSE 1190, and the response message may be transferred from the CSE 1190 to the AE 1100 in the same manner.
  • the CSE 1190 transfers the response message to the relay client module 1180 in the form of an M2M message (S1350).
  • the relay client module 1180 transmits a publish packet to the relay server 1150 (S1360).
  • the relay client module 1180 may include the response message in the payload according to the publish packet format and transmit the response message.
  • the publish packet includes a QoS level field, a duplicate transmission flag field, and a packet type field in the fixed header including information on the QoS level of the packet or the relay protocol, and includes a topic name field and a packet identification field in the variable header.
  • the topic name of the publish packet may be set to 'oneM2M / resp / SP-relative-AE-ID / SP-relative-CSE-ID'.
  • the relay server 1150 transmits the received publish packet to the receiving relay client module 1110 of the response message in operation S1370.
  • the relay client module 1110 converts the response message included in the payload of the publish packet into an M2M message and transmits the response message to the AE 1100 (S1380).
  • the relay client module 1110 converts the response message included in the payload of the received publish packet into an M2M message and forwards it to the AE 1100, whereby the AE 1100 and the CSE 1190 transmit and receive a request message and a response message. can do.
  • the Originator 1400 transmits a request message to the relay client module 1110 in the form of an M2M message (S1400).
  • the relay client module 1110 transmits a publish packet to the relay server 1150 (S1405).
  • the relay client module 1110 may include the request message in the payload according to the publish packet format and transmit the request message.
  • the relay server 1150 transmits a publish acknowledgment (Publish ACK, PUBACK) packet including information on whether the received publish packet is normally received to the relay client module 1110 (S1410).
  • a publish acknowledgment packet including information indicating normal reception when a publish packet including a request message is normally received or when the publish packet can be processed as a receiver. 1110).
  • the relay server 1150 transmits the received publish packet to the receiving side relay client module 1180 of the request message (S1415).
  • the relay client module 1180 converts the request message included in the payload of the publish packet into an M2M message and delivers it to the receiver 1490 (S1425).
  • the receiving relay client module 1180 may receive a publish packet including a request message from the relay server 1150 and transmit a publish acknowledgment packet including information indicating whether the packet is normally received to the relay server 1150. There is (S1420). Operation S1420 may be performed before operation S1425 or may be performed afterwards.
  • the Originator 1400 may transmit a request message to the Receiver 1490, and a response message may be delivered from the Receiver 1490 to the Originator 1400 in the same manner.
  • the receiver 1490 transmits the response message to the relay client module 1180 in the form of an M2M message (S1430).
  • the relay client module 1180 transmits a publish packet including a response message to the relay server 1150 (S1435).
  • the relay client module 1180 may include the response message in the payload according to the publish packet format and transmit the response message.
  • the relay server 1150 may transmit a publish confirmation packet including information indicating whether the relay packet is normally received to the relay client module 1180 (S1440).
  • the relay server 1150 relays the received publish packet to the receiving side relay client module of the response message. And transmits to 1110 (S1445).
  • the receiving relay client module 1110 may transmit a publish acknowledgment packet including information indicating whether the reception packet is normally received or processed normally, to the relay server 1150.
  • the relay client module 1110 converts the response message included in the payload of the publish packet into an M2M message and transmits it to the Originator 1400 (S1455).
  • the relay client module 1110 converts the response message included in the payload of the received publish packet into an M2M message and forwards it to the Originator 1400, whereby the Originator 1400 and the Receiver 1490 transmit and receive a request message and a response message. can do.
  • the topic name of the publish packet described above may be set as shown in the following example to process an application service or a group.
  • topic name may be set in various forms, and each configuration object may be set in advance.
  • connection packet format 15 illustrates a structure of a connection packet format and a fixed header according to an embodiment.
  • a concatenated packet may be composed of two bytes of a fixed header, a variable header, and a payload region. That is, the concatenated packet format may be set to a fixed header, a variable header and a payload.
  • the fixed header may include two bytes of information, and the length of the variable header and the payload may be set to be variable.
  • the fixed header may include a field including a reserver field, packet type information, and a remaining length field.
  • the reservation field may be set to a value of 0, and the field including packet type information may be set to a specific value indicating that the corresponding packet is a CONNECT packet.
  • the specific value may be set in advance.
  • the remaining length field may be configured to have a variable value according to the variable header and the payload.
  • the value of the remaining length field may be set to a value of “0” or “1”, and a value of 0 or 1 may be set depending on whether payload is present, payload length, or length or length of variable header. It may be determined by a preset rule.
  • the header of the connection packet format and the length of each field may vary depending on the setting.
  • connection packet variable header illustrates a structure of a connection packet variable header according to an embodiment.
  • 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.
  • the protocol name field may include information indicating a relay protocol used by the packet.
  • the protocol name field may include information indicating that the packet is a packet using the MQTT protocol.
  • the protocol level field may include information indicating a version of a corresponding protocol, and may indicate MQTT version 3.1.1 when the protocol level value is 4, such as 1600.
  • connection flag field may include detailed flags such as a user name flag, a password flag, Will Retain, Will QoS, Will Flag, Clean session, Reserved, and the like.
  • the Clean Session field may contain information indicating whether the session is reset. For example, if Clean Session is set to 0, the server can resume communication with the client module based on the state of the current session.
  • Will Flag can contain information about connection errors.
  • the server may include information about whether an input / output error and a network error condition, communication with a client module could not be performed within a maintenance time, or a protocol error.
  • Will QoS includes information specifying the QoS level to use when initiating a Will message.
  • Will Retaion may include information indicating whether or not to maintain the packet.
  • the password flag may include information on whether a password exists in a corresponding payload.
  • the connection flag field may include various setting information about the connection packet. That is, when the value of the connection packet is set as shown in 1610, it may represent that the Will Flag value is set to 1.
  • connection maintenance field of the variable header indicates information on the maximum time interval that can elapse between two consecutive control packets transmitted by the client module, it may be set in units of seconds.
  • the length of the header and each region may vary depending on the setting.
  • connection packet payload 17 illustrates a structure of a connection packet payload according to an embodiment.
  • the payload may include client module identifier information. It may also include a username and password as needed.
  • the client module identifier information may include identification information for identifying the client module in the corresponding relay server, and optionally include name information and password for the corresponding user.
  • each region and payload length may vary.
  • connection packet may be configured to include various information.
  • the format and each field of the connection confirmation packet in response to the connection packet will be described.
  • connection confirmation packet format is a diagram illustrating a connection confirmation packet format and the structure of each header according to an embodiment.
  • connection confirmation packet may consist of a fixed header of 2 bytes, a variable header, and a payload.
  • the fixed header may include a reserved field (ex, set to 0000), a packet type field, and a remaining length field. This may be set similar to the above-described connection packet.
  • variable header may also include a reservation field (ex, set to 0), a remaining length field, and a concatenation return code information field.
  • variable header may include a session present flag (SP) and a reservation and connection response code field.
  • SP session present flag
  • the payload may be omitted.
  • 19 illustrates a structure of a subscribe packet format, a fixed header, a variable header, and a payload according to an embodiment.
  • a SUBSCRIBE packet is set in a format consisting of a fixed header, a variable header, and a payload.
  • the fixed header may be set to 2 bytes, and the variable header and payload may be set to vary in length.
  • the fixed header may include a reservation field, a packet type information field, and a remaining length field, and a value included in each field may be set as shown in 1900.
  • the variable header may include packet identification information.
  • the payload includes a length field, a topic filter field, and a QoS field, and a plurality of QoSs corresponding to the topic filter and the topic filter may be included in pairs.
  • 20 illustrates a structure of a subscribe confirmation packet format, fixed header, variable header, and payload according to an embodiment.
  • a subscription confirmation packet including confirmation information on a subscription packet is composed of a fixed header, a variable header, and a payload.
  • the fixed header may include a reservation field, a packet type information field, and a remaining length field, and each field may include information as in the example of 2000.
  • the variable header may include packet identification information.
  • the payload may include list information of the response code.
  • the relay client module may obtain the processing result of the relay server for the subscription packet through the information set for each response code.
  • 21 is a diagram illustrating a publish packet format, a fixed header, and a variable header structure according to an embodiment.
  • a publish packet includes a fixed header, a variable header, and a payload.
  • the fixed header may be composed of RETAIN, QoS level, DUG flag, packet type information, and remaining length field.
  • the fixed header may consist of 2 bytes and carry information allocated for each bit.
  • the QoS level field contains information about the QoS level of a packet or relay protocol.
  • the duplicate transmission flag field includes information indicating whether a corresponding packet is duplicate transmission.
  • the packet type field includes information indicating that the packet is a publish packet.
  • variable header may include a topic name and packet identification information.
  • the topic name may vary according to the request and response message as described above, and may include sender information and receiver information. For example, it can be set to '/ oneM2M / req / Originator-ID / Receiver-ID' for a request message and to '/ oneM2M / resp / Originator-ID / Receiver-ID' for a response message. have.
  • the packet identification information may include index information preset for identifying the packet.
  • the packet identification information may exist only in a publish packet having a QoS level of 1 or 2.
  • the payload of the publish packet may include a request message or response message defined in the M2M system.
  • the request message included in the payload may include information indicating a request type of the request message, caller identification information, receiver identification information, and request identification information.
  • the response message may include request identification information and response result code information.
  • FIG. 22 is a diagram illustrating a publish confirmation packet format, a fixed header, and a variable header structure according to an embodiment.
  • a publish confirmation packet may include at least one of a fixed header, a variable header, and a payload region.
  • the fixed header includes a reserved area, a packet type information area, and a remaining length area, and a value included in each area may be included as shown in FIG.
  • the variable header may include packet identification information.
  • the packet identification information may indicate which publish packet is a response to the publish confirmation packet.
  • the payload of the publish confirmation packet can be omitted.
  • each packet described above has been described in one embodiment, and may be changed by setting or some fields may be omitted or added.
  • communication when one of two M2M devices communicates through a firewall, communication may be initiated from either of two devices using an Internet protocol.
  • communication even when both devices communicate through a public IP network through a firewall, communication can be initiated from either device using the Internet protocol.
  • request and response messages can be exchanged using the relay protocol, and the same application can be used in multiple devices.
  • FIG. 23 is a diagram illustrating a structure of an M2M device according to one embodiment.
  • an M2M device 2300 that communicates with another M2M device through a public IP (Internet Protocol) network transmits a connection packet for establishing a connection to a relay server through a relay client module, and connects.
  • the request packet for transmission to another M2M device is included in the publish packet and relayed. It may include a transmitter 2320 for transmitting to the server and a receiver 2330 for receiving a publish packet including a response message generated by another M2M device for the request message from the relay server.
  • the transmitter 2320 may transmit a connection packet for establishing a connection with the relay server to the relay server, and the receiver 2330 may receive a connection confirmation packet including response information about the connection packet from the relay server.
  • the transmitter 2320 may transmit a subscription packet to the relay server, and the receiver 2330 may receive a subscription confirmation packet thereto.
  • the subscription packet may include identification information for identifying the AE or CSE of the corresponding M2M device in the relay server.
  • the controller 2310 may receive a subscription confirmation packet and perform connection establishment.
  • connection establishment procedure may be performed in the same manner with other M2M devices for communicating with the M2M device.
  • another M2M device may establish a connection with the relay server through a procedure for transmitting and receiving a connection packet and a connection confirmation packet.
  • the other M2M device may perform a connection packet and a connection confirmation packet transmission / reception procedure with the relay server, and establish a connection through the transmission and reception of a subscription packet and a subscription confirmation packet.
  • the publish packet includes a fixed header, a variable header, and a payload region
  • the fixed header includes a QoS level field, a duplicate transmission flag field, and a packet type field, which include information on the QoS level of the packet or relay protocol.
  • the variable header may include a topic name field and a packet identification field.
  • the payload area may include a request message and request information may be included in the request message.
  • the request identification information may be included in a response message later to identify information on which request message the response message is a response to.
  • the receiving unit 2330 may receive a publish confirmation packet including response information about the publish packet from the relay server.
  • the publish confirmation packet may include information on whether the publish packet is normally received.
  • the transmitter 2320 transmits acknowledgment information about the publish packet including the response message to the relay server in the publish acknowledgment packet.
  • the publish confirmation packet may include information on whether the publish packet is normally received.
  • the response message may be included in the payload of the publish packet and may include request identification information and response status code information.
  • the request identification information may be set to the same value as the request message to indicate which request message the response message includes.
  • the response status code contains a code value for the processing result of the procedure required in the corresponding request message.
  • controller 2310 transmits a request message using the relay server according to the present embodiment, and controls the overall operation of the M2M device 2300 according to the response message.
  • the transmitter 2320 and the receiver 2330 are used to transmit and receive messages, signals, and data necessary to perform the present embodiment with at least one of a relay server, another M2M device, a relay client module.
  • 24 is a diagram illustrating a structure of a relay server according to an embodiment.
  • the relay server 2400 which relays communication between M2M devices through a public IP (Internet Protocol) network may receive a connection packet for connection establishment from a relay client module of each of the M2M device and another M2M device.
  • the receiving unit 2430 further receives a publish packet including a response message to the request message from the relay client module of another M2M device, and the transmitting unit 2420 further sends the publish packet including the response message to the relay client module of the M2M device.
  • the receiver 2430 may receive a connection packet from M2M devices that wish to perform communication through the relay server.
  • the connection packet may be received from a relay client module that may be configured in each M2M device.
  • the transmitter 2420 may transmit a connection confirmation packet including response information to the connection packet to each M2M device.
  • the receiver 2430 receives a subscription packet from each M2M device after receiving a connection packet and transmitting a connection confirmation packet, and the transmitter 2420 transmits a subscription confirmation packet for the subscription packet to each M2M device to perform connection establishment.
  • the subscription packet may include identification information for the M2M device requesting connection establishment.
  • the subscription packet may include identification information related to transmission of a request message of the M2M device requesting connection establishment and information on identification information related to reception of a response message.
  • the information indicating that the M2M device is a M2M packet using the M2M network may be included.
  • the relay server 2400 may be configured independently of the middle node and the infrastructure node, which are nodes constituting the M2M system.
  • the middle node and the infrastructure node may communicate with an independently configured relay server using the relay client module.
  • the publish packet may include information indicating that the message is a thing communication message, information indicating a message type (a request or response), identification information of the sender, and identification information of the receiver.
  • the publish packet is composed of a fixed header, a variable header and a payload area, the fixed header includes a QoS level field, information on the QoS level of the packet or relay protocol, a duplicate transmission flag field and a packet type field,
  • the variable header may include a topic name field and a packet identification field.
  • the controller 2410 checks identification information of another target M2M device indicated by the publish packet, and the transmitter 2420 includes a request message to a relay client module of another connected M2M device.
  • a publish packet may be transmitted. That is, when the publish packet is received from the relay client module, the controller 2410 transmits the packet to the relay client module at the receiver by referring to the topic name.
  • the receiver 2430 may receive a publish acknowledgment packet indicating an acknowledgment of a publish packet including a request message from another M2M device.
  • the transmitter 2420 may transmit a publish confirmation packet for the publish packet to another M2M device.
  • the receiver 2430 may receive a publish confirmation packet from the M2M device.
  • controller 2410 transmits a request message using the relay server according to the present embodiment, and controls the overall operation of the relay server 2400 according to the response message.
  • the transmitter 2420 and the receiver 2430 are used to transmit and receive messages, signals, and data necessary for performing the present embodiment with at least one of another relay server, an M2M device, another M2M device, and a relay client module. do.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

La présente invention concerne un procédé de communication de machine à machine (M2M) basé sur un protocole internet privé (IP) via un IP public dans un système M2M, et un appareil associé. Selon un mode de réalisation du procédé et de l'appareil, un dispositif M2M communique avec un autre dispositif M2M par l'intermédiaire d'un réseau IP public, et le procédé comprend les étapes suivantes : transmission d'un paquet de connexion pour l'établissement d'une connexion à un serveur relais par l'intermédiaire d'un module client relais, et réception d'informations de réponse concernant le paquet de connexion pour l'établissement d'une connexion, de façon à établir une connexion avec le serveur relais ; lorsqu'une connexion avec le serveur relais est établie, transmission au serveur relais d'un paquet de publication contenant un message de requête à transmettre à un autre dispositif M2M ; et réception d'un paquet de publication provenant du serveur relais et contenant un message de réponse ayant été généré par l'autre dispositif M2M en réponse au message de requête.
PCT/KR2018/004373 2017-04-27 2018-04-16 Procédé de traitement de communication de machine à machine via un réseau ip public, et appareil associé Ceased WO2018199523A1 (fr)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
KR20170054667 2017-04-27
KR10-2017-0054667 2017-04-27
KR10-2017-0064401 2017-05-24
KR20170064401 2017-05-24
KR1020180042814A KR102092100B1 (ko) 2017-04-27 2018-04-12 공인 ip 네트워크를 통해서 사물통신을 처리하는 방법 및 그 장치
KR10-2018-0042814 2018-04-12

Publications (1)

Publication Number Publication Date
WO2018199523A1 true WO2018199523A1 (fr) 2018-11-01

Family

ID=63919018

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2018/004373 Ceased WO2018199523A1 (fr) 2017-04-27 2018-04-16 Procédé de traitement de communication de machine à machine via un réseau ip public, et appareil associé

Country Status (1)

Country Link
WO (1) WO2018199523A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101466210B1 (ko) * 2013-09-27 2014-11-27 에스케이 텔레콤주식회사 Ｍ2ｍ 단말기로 장문 메시지를 전달하는 방법 및 장치
KR20150112039A (ko) * 2011-06-29 2015-10-06 프리스타일 테크놀러지 피티와이 리미티드 다른 통신 프로토콜들을 이용해 디바이스들 간에 통신을 가능하게 하기 위한 시스템, 방법 및/또는 기기
KR20160036690A (ko) * 2014-09-25 2016-04-05 가온미디어 주식회사 다중 M2M/IoT 디바이스들과 연계된 M2M/IoT 디바이스를 취급하기 위한 멀티 링크 메카니즘
WO2016123778A1 (fr) * 2015-02-05 2016-08-11 华为技术有限公司 Procédé, dispositif et système de traitement de données m2m
US9596596B2 (en) * 2010-02-15 2017-03-14 Telefonaktiebolaget Lm Ericsson (Publ) Machine-to-machine device triggering using session initiation protocol uniform resourse identifier

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9596596B2 (en) * 2010-02-15 2017-03-14 Telefonaktiebolaget Lm Ericsson (Publ) Machine-to-machine device triggering using session initiation protocol uniform resourse identifier
KR20150112039A (ko) * 2011-06-29 2015-10-06 프리스타일 테크놀러지 피티와이 리미티드 다른 통신 프로토콜들을 이용해 디바이스들 간에 통신을 가능하게 하기 위한 시스템, 방법 및/또는 기기
KR101466210B1 (ko) * 2013-09-27 2014-11-27 에스케이 텔레콤주식회사 Ｍ2ｍ 단말기로 장문 메시지를 전달하는 방법 및 장치
KR20160036690A (ko) * 2014-09-25 2016-04-05 가온미디어 주식회사 다중 M2M/IoT 디바이스들과 연계된 M2M/IoT 디바이스를 취급하기 위한 멀티 링크 메카니즘
WO2016123778A1 (fr) * 2015-02-05 2016-08-11 华为技术有限公司 Procédé, dispositif et système de traitement de données m2m

Similar Documents

Publication Publication Date Title
WO2017003175A1 (fr) Procédé et appareil de fourniture d'un service dans un système de communication sans fil
WO2012141556A2 (fr) Procédure d'annulation pour des noeuds de communication entre machines
WO2015046960A1 (fr) Procédé de délivrance d'un message de notification dans un système m2m et dispositifs associés
WO2015069038A1 (fr) Procédé d'abonnement et de notification dans un système de communication m2m et dispositif associé
WO2018101775A1 (fr) Appareil et procédé d'installation et de gestion de profils esim
WO2014185754A1 (fr) Procédé d'abonnement et de notification dans un système de communications m2m et appareil associé
WO2021066452A1 (fr) Procédé et dispositif d'activation d'un utlisateur 5g
WO2016024695A1 (fr) Procédé et appareil de téléchargement de profil de dispositifs de groupe
WO2021054747A1 (fr) Appareil et procédé de relocalisation d'upf psa dans un système de communication sans fil
WO2017057962A1 (fr) Procédé et appareil destinés à la gestion d'un service de mcptt
WO2016195199A1 (fr) Procédé de traitement de requête par un canal d'interrogation dans un système de communication sans fil et appareil associé
WO2014129802A1 (fr) Procédé pour modifier un paramètre de service m2m et appareil associé
WO2023277542A1 (fr) Procédé et appareil de transmission d'un paramètre de service
WO2022225295A1 (fr) Procédé et appareil d'authentification parmi des dispositifs de réseau central dans un système de communication mobile
WO2021091307A1 (fr) Appareil et procédé d'établissement d'une session de service mbs pour fourniture de service mbs dans un système de communication sans fil
WO2018062940A1 (fr) Procédé de gestion de communications vidéo critiques de mission (mcvidéo) dans un système de communication mcvidéo hors réseau
WO2016013846A1 (fr) Procédé de traitement de message de demande dans un système de communications sans fil, et appareil associé
WO2012081882A2 (fr) Procédé et appareil pour la transmission fiable d'une diffusion multiple vers un groupe au moyen d'une technique de radiodiffusion cellulaire dans un système de communication mobile
WO2016204514A1 (fr) Procédé et appareil de mise en oeuvre de service dans un système de communication sans fil
EP3314931A1 (fr) Procédé et appareil de fourniture d'un service dans un système de communication sans fil
WO2016148527A1 (fr) Procédé et appareil de génération d'un paquet dans un système de communications mobiles
WO2018030861A1 (fr) Procédé pour exécuter une commande de connexion légère sur un équipement d'utilisateur et équipement correspondant
EP3530016A1 (fr) Appareil et procédé d'installation et de gestion de profils esim
WO2022092624A1 (fr) Dispositif de nœud de traitement de données et procédé de transmission d'informations mis en œuvre dans le même dispositif
WO2020111761A1 (fr) Procédé et dispositif de transmission répétée de message dans un système m2m

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18791910

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18791910

Country of ref document: EP

Kind code of ref document: A1