WO2015046960A1 - M2m 시스템에서 통지 메시지 전달 방법 및 이를 위한 장치 - Google Patents

M2m 시스템에서 통지 메시지 전달 방법 및 이를 위한 장치 Download PDF

Info

Publication number
WO2015046960A1
WO2015046960A1 PCT/KR2014/009041 KR2014009041W WO2015046960A1 WO 2015046960 A1 WO2015046960 A1 WO 2015046960A1 KR 2014009041 W KR2014009041 W KR 2014009041W WO 2015046960 A1 WO2015046960 A1 WO 2015046960A1
Authority
WO
WIPO (PCT)
Prior art keywords
resource
notification message
receiving device
subscription
notification
Prior art date
Application number
PCT/KR2014/009041
Other languages
English (en)
French (fr)
Inventor
최희동
박승규
김성윤
안홍범
정승명
Original Assignee
엘지전자 주식회사
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
Application filed by 엘지전자 주식회사 filed Critical 엘지전자 주식회사
Priority to EP14849785.2A priority Critical patent/EP3051849B1/en
Priority to JP2016538869A priority patent/JP6254702B2/ja
Priority to KR1020167002529A priority patent/KR102208119B1/ko
Priority to US14/909,633 priority patent/US10051404B2/en
Priority to CN201480053463.2A priority patent/CN105580396B/zh
Publication of WO2015046960A1 publication Critical patent/WO2015046960A1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/55—Push-based network services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/62—Establishing a time schedule for servicing the requests
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/12—Setup of transport tunnels

Definitions

  • the present invention relates to a machine-to-machine communication system, and more particularly, to a method and apparatus for subscribing and notifying a specific resource in an M2M system.
  • M2M communication refers to communication performed between a machine and a machine without human intervention, and is also referred to as machine type communication (MTC) or internet of things (IoT) communication.
  • MTC machine type communication
  • IoT internet of things
  • a terminal used for M2M communication is referred to as an M2M device, which is generally low mobility, time tolerant or delay tolerant, and small data transmission. It is used in connection with M2M server that centrally stores and manages communication information between machines.
  • M2M device when the M2M device is connected according to different communication methods, the M2M device and the M2M server are connected through the M2M gateway in a section in which the communication method is changed, thereby forming the entire M2M system.
  • services such as tracking, power metering, automatic payment system, medical service, and remote control may be provided.
  • the present invention relates to an M2M system.
  • Another object of the present invention is to provide a method and apparatus for transmitting and receiving a notification message in an environment in which connection status between entities is not guaranteed in an M2M system.
  • Another object of the present invention is to provide a method and apparatus for improving data transmission efficiency and overall system performance by not transmitting unnecessary notification messages in an M2M system.
  • a method of performing a notification for a resource subscription (resource subscription) in a machine-to-machine device (M2M) includes a subscription target including a subscription resource as a child resource Detecting a change in resource; Generating a notification message including a value indicating an event category of the change according to second attribute information set in the subscription resource; And determining the reachability to the receiving device based on the scheduling information set in the scheduling resource for the M2M device and the scheduling information set in the scheduling resource for the receiving device.
  • the notification message When it is determined that it is reachable, the notification message is immediately sent to the receiving device, and when it is determined that the receiving device is not reachable according to the scheduling information, the notification message indicates that the first attribute information set in the subscription resource is determined.
  • the processed notification message may be transmitted to the receiving device after the receiving device recovers to an reachable state according to a value having a value.
  • a Machine-to-Machine (M2M) device comprising: a Network Interface Unit; And a processor operatively connected with the network interface unit, the processor detecting a change in a subscription target resource including a subscription resource as a child resource, and according to the second attribute information set in the subscription resource.
  • M2M Machine-to-Machine
  • a notification message including a value indicating the event category of the change and reachability to the receiving device based on the scheduling information set in the scheduling resource for the M2M device and the scheduling information set in the scheduling resource for the receiving device And if the receiving device is determined to be reachable according to the scheduling information, the notification message is immediately sent to the receiving device, and if the receiving device is determined to be unreachable according to the scheduling information.
  • the notification message may be processed in the M2M device according to a value of the first attribute information set in the subscription resource, and the processed notification message may be transmitted to the receiving device after the receiving device recovers to an reachable state.
  • each of the subscription resource and the scheduling resource may represent a uniquely addressable data structure using a unique address.
  • said second attribute information defines an event category for said notification message triggered by said subscription resource, and a value indicating an event category included in said notification message indicates that said receiving device correctly identifies said notification message. It can be used to handle.
  • the first attribute information may indicate a processing operation of a notification message to be performed by the M2M device after a time interval that is not reachable to the receiving device according to the scheduling information.
  • processing the notification message is equivalent to discarding the generated notification message if the first attribute information has a first value.
  • the first attribute information has a second value, storing the generated notification message and discarding a previously stored notification message; and when the first attribute information has a third value, the generated notification message. It may include storing all.
  • the receiving device may be determined to be reachable.
  • the receiving device may be determined to be unreachable.
  • a notification message can be transmitted and received in an environment in which the connection state between entities is not guaranteed in the M2M system.
  • data transmission efficiency and overall system performance can be improved by not transmitting unnecessary notification messages in the M2M system.
  • the present invention it is possible to preferentially transmit the important message set by the user by enabling the importance of the notification message to be set in the M2M system.
  • FIG. 2 illustrates a layered structure of an M2M system.
  • FIG. 3 illustrates a functional architecture of an M2M system.
  • FIG. 5 illustrates a resource used in an M2M system.
  • FIG. 6 illustrates a resource for a particular M2M application.
  • FIG. 7 illustrates a communication flow of a typical M2M system.
  • FIG 8 illustrates an example in which different entities interoperate in an M2M system.
  • FIG. 9 illustrates a procedure related to a subscription resource.
  • 11 and 12 illustrate the subscription and notification process in an environment where the connection state is not guaranteed.
  • 13 through 16 illustrate a notification method according to notification policy information.
  • FIG 17 illustrates a notification process in accordance with the present invention.
  • FIG. 18 illustrates an embodiment of a notification process in accordance with the present invention.
  • FIG. 19 illustrates a block diagram of an apparatus to which the present invention can be applied.
  • an M2M device refers to a device for machine-to-machine communication.
  • the M2M device may be fixed or mobile and may communicate with the M2M server to send and receive user data and / or control information.
  • M2M devices may include a terminal equipment, a mobile station (MS), a mobile terminal (MT), a user terminal (UT), a subscriber station (SS), a wireless device, a personal digital assistant (PDA), and a wireless modem ( wireless modem, handheld device, and the like.
  • the M2M server refers to a server for M2M communication and may be implemented as a fixed station or a mobile station.
  • the M2M server may communicate with M2M devices and / or other M2M servers to exchange data and control information.
  • the M2M gateway refers to a device that serves as a connection point for entering a network from one network to another when the network to which the M2M device is connected and the network to which the M2M server is connected are different.
  • the M2M gateway may perform a function as an M2M device, for example, manage an M2M device connected to the M2M gateway, receive a message, and deliver the same or changed message to the connected M2M devices (message fanout). ), A function of message aggregation may be performed.
  • the term M2M device may be used as a concept including an M2M gateway and an M2M server, and thus, the M2M gateway and the M2M server may be referred to as an M2M device.
  • entity can be used herein to refer to hardware such as an M2M device, an M2M gateway, an M2M server, or software of the M2M application layer and the M2M (common) service layer described below. It may be used to refer to a software component.
  • the present invention will be described with reference to the M2M system, but the present invention is not limited to the M2M system, and the same applies to a system according to a client-server (or sender-responder) model. Similarly it can be applied.
  • FIG. 1 illustrates an M2M system.
  • 1 illustrates an M2M system according to the European Telecommunications Standards Institute (ETSI) Technical Specification (TS).
  • ETSI European Telecommunications Standards Institute
  • TS Technical Specification
  • the M2M system according to the ETSI TS M2M technical standard defines a common M2M service framework for various M2M applications.
  • An M2M application may refer to a software component that implements an M2M service solution such as e-Health, City Automation, Connected Consumer, or Automotive.
  • M2M service functions necessary in common for implementing such various M2M applications are provided, and the functions commonly required may be referred to as M2M service or M2M common service.
  • the M2M service is provided in the form of a set of Service Capabilities (SC), and the M2M application accesses a set of Service Capabilities (SCs) or a Service Capability (SC) through an open interface. You can use M2M service or function provided by.
  • the SC can provide the capabilities to configure M2M services (eg device management, location, discovery, group management, registration, security, etc.), and the SC Layer (Service Capabilities Layer) or SC Entity (Service Capability Entity) A set of functions for M2M services that can be used when provided on this service framework.
  • SC Service Capability
  • x may be expressed as one of N / G / D, and indicates where SC (Service Capability) exists among a network (and / or a server), a gateway, and a device.
  • NSC Service Capability
  • GSC Service Capability
  • M2M applications can reside on a network, gateway, or device.
  • An M2M application present on a network or directly connected to a server is referred to as an M2M network application and may be briefly referred to as a network application (NA).
  • NA is software that is implemented by connecting directly to a server and may be responsible for communicating with and managing an M2M gateway or M2M device.
  • the M2M application existing on the device is referred to as an M2M device application and may be briefly referred to as a device application (DA).
  • the DA is software running on the M2M device, and may transmit sensor information and the like to the NA.
  • the M2M application existing on the gateway is referred to as an M2M gateway application and may be briefly referred to as a gateway application (GA).
  • the GA may also serve to manage an M2M gateway and provide DA with M2M services or capabilities (eg, Service Capabilities (SCs) or Service Capability (SC)).
  • M2M application may collectively refer to an application entity (AE) and an application layer.
  • an M2M system architecture may be divided into a network domain, a device, and a gateway domain.
  • the network domain may include functions for M2M system management and functions for network management. Functions for M2M system management may be performed by M2M applications and M2M Service Capabilities (SCs) that manage devices existing in the device and gateway domains, and functions for network management may be performed by the core network and the access network. have.
  • SCs M2M Service Capabilities
  • the core network and access network provide connectivity between each entity rather than perform M2M functions.
  • M2M communication can be performed between M2M Service Capabilities (M2M SCs) in the network domain and device and gateway domains through the core network and the access network, and M2M applications in each domain can receive signals or information through M2M Service Capabilities (SCs) in each domain. Can give and receive.
  • M2M SCs M2M Service Capabilities
  • SCs M2M Service Capabilities
  • An access network is an entity that allows M2M devices and gateway domains to communicate with the core network.
  • Examples of access networks include xDSL (Digital Subscriber Line), Hybrid Fiber Coax (HFC), satellite, GERAN, UTRAN, eUTRAN, Wireless LAN, WiMAX, and the like.
  • a core network is an entity that provides functions such as Internet Protocol (IP) connectivity, service and network control, interconnection, and roaming.
  • Core networks include 3rd Generation Partnership Project (3GPP) core networks, ETSI Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN) core networks, and 3GPP2 core networks.
  • 3GPP 3rd Generation Partnership Project
  • TISPAN Internet converged Services and Protocols for Advanced Networking
  • M2M Service Capability provides the M2M Common Service Function (CSF), which can be shared among multiple M2M network applications, and exposes M2M services through an open interface, allowing M2M applications to access M2M services. Make it available.
  • the M2M Service Capability Layer may refer to a layer including such M2M SC entities or M2M common service functions.
  • An M2M application is an entity that operates service logic and can use M2M SCs (Service Capabilities) through an open interface.
  • An M2M application layer may refer to a layer that contains such M2M application and associated operational logic.
  • the M2M device is an entity that operates an M2M device application through M2M SCs (Service Capabilities).
  • the M2M device may directly communicate with an M2M server in a network domain, or may communicate with an M2M server in a network domain through an M2M gateway. When connected through an M2M gateway, the M2M gateway acts like a proxy.
  • the M2M device may include an M2M application and / or M2M SCs (Service Capabilities).
  • An M2M area network provides connectivity between M2M devices and M2M gateways.
  • the network between the M2M gateway and the M2M server and the network between the M2M device and the M2M gateway may be different from each other.
  • M2M area networks include Personal Area Network (PAN) technologies such as IEEE802.15.1, Zigbee, Bluetooth, IETF ROLL, ISA100.11a, Power Line Communication (M-BUS), Wireless It can be implemented using local network technologies such as M-BUS and KNX.
  • PAN Personal Area Network
  • M-BUS Power Line Communication
  • the M2M gateway is an entity that manages M2M applications and provides services for M2M applications through M2M SCs (Service Capabilities).
  • the M2M gateway may serve as a proxy between the M2M device and the network domain and provide a service to an ETSI non-compliant M2M device.
  • the M2M gateway may refer to an entity having a gateway function among M2M devices.
  • the M2M gateway may include M2M applications and / or M2M SCs (Service Capabilities).
  • the M2M system architecture illustrated in FIG. 1 is merely an example and the names of each entity may be different.
  • the M2M Service Capability (SC) may be referred to as an M2M common service function (CSF)
  • the Service Capability Layer (SCL) may be a common service layer (CSL) or a common service entity (CSL).
  • Common Service Entity (CSE)
  • an M2M application may be referred to as an application entity (AE), and the M2M application layer may be referred to simply as an application layer.
  • the name of each domain may also vary.
  • a network domain may be referred to as an infrastructure domain and a device and gateway domain may be referred to as a field domain.
  • an M2M system may be understood as a hierarchical structure including an M2M application layer and an M2M Service Capability (SC) layer for M2M communication.
  • SC M2M Service Capability
  • FIG. 2 illustrates a layered structure of an M2M system.
  • an M2M system may include an application layer 202, a common service layer 204, and an underlying network services layer 206.
  • the application layer 202 may correspond to the M2M application layer
  • the common service layer 204 may correspond to the M2M SCL.
  • the underlying network service layer 206 provides services to the common service layer 204, such as device management, location services, and device triggering, present in the core network.
  • the M2M system architecture includes an application entity (AE) 302, a common service entity (CSE) 304, an underlying network service entity (NSE) 306. ) May be included.
  • Each entity 302, 304, 306 may communicate via a reference point supported by the common service entity 304.
  • the reference point serves to specify a communication flow between the entities 302, 304, and 306.
  • the reference point can be expressed as Mcx and Mc means “M2M communications”.
  • Mca reference point, the Mcc reference point, and the Mcn reference point may be denoted as Mca, Mcc, and Mcn, respectively.
  • the Mca reference point 312 specifies the communication flow of the application entity (AE) 302 and the common service entity (CSE) 304.
  • the Mca reference point 312 enables the AE 302 to use the services provided by the CSE 304 and allows the CSE 304 to communicate with the AE 302.
  • the Mca reference point 312 may refer to an interface between the M2M application layer and the M2M common service layer (or entity).
  • the Mcc reference point 314 specifies the flow of communication between different common service entities (CSEs) 304.
  • CSEs common service entities
  • the Mcc reference point 314 allows the CSE 304 to use the services of another CSE when providing the necessary functions. Services provided via the Mcc reference point 314 may depend on the functions supported by the CSE 304.
  • the Mcc reference point 314 may refer to an interface between M2M common service layers.
  • Mcn reference point 316 specifies the communication flow between the CSE 304 and the underlying network service entity (NSE) 306. Mcn reference point 316 enables CSE 304 to use the services provided by underlying NSE 306 to provide the required functions. Mcn reference point 316 may refer to an interface between the M2M common service layer and the M2M underlying network layer.
  • the CSE 304 may provide various common service functions (CSFs).
  • CSFs common service functions
  • the CSE 304 may include application and service layer management functions, communication management and delivery handling functions, data management and storage functions, devices, and the like.
  • Device Management Function Group Management Function, Discovery Function, Location Function, Network Service Exposure / Service Execution and Triggering Function, Registration ), A security function, a service charging and accounting function, a service session management function, and a subscription / notification function.
  • CSE 304 points to an instance of the common service functions and provides a subset of common service functions that M2M applications can use and share.
  • the common service functions are briefly described as follows.
  • ASM Application and Service Layer Management
  • CMDH Communication Management and Delivery Handling
  • DMR Data Management and Repository
  • DMG Device Management: Manages device functions for devices existing in M2M area networks as well as M2M gateways and M2M devices.
  • the DMG function can perform application installation and configuration, firmware update, logging, monitoring, diagnostics, and network topology management.
  • Discovery, DIS searches for information, such as information and resources, on request within a given range and condition.
  • GMG Group Management
  • a group may be created by binding a resource, an M2M device, or an M2M gateway to handle a group related request.
  • the M2M application plays a role of obtaining location information of the M2M device or the M2M gateway.
  • Network Service Exposure / Service Execution and Triggering Enables communication of the underlying network and enables the use of services or features provided by the underlying network.
  • Registration An M2M application or other CSE handles registration to a specific CSE. Registration is performed to use the M2M service function of a specific CSE.
  • SEC Handles sensitive data such as security keys, establishes security associations, authenticates, authorizes, and protects identity.
  • SCA Service Charging and Accounting
  • SSM Service Session Management
  • Subscription / Notification When a subscription is made to a change to a specific resource, it plays a role of notifying when the resource is changed.
  • a node refers to an entity including one or more M2M applications or an entity including one CSE and zero or more M2M applications.
  • An application dedicated node may refer to a node having at least one application entity (AE) but no common service entity (CSE).
  • the ADN may communicate with one middle node (MN) or one infrastructure node (IN) through Mca.
  • MN middle node
  • I infrastructure node
  • ADN may be referred to as an M2M device having a constrained capability, where an M2M device with limited capabilities does not include a common service layer or a common service entity (CSE). May be referred to.
  • An M2M device with limited capabilities may be referred to simply as a constrained M2M device.
  • An application service node may refer to a node having at least one common service entity (CSE) and at least one M2M application entity (AE).
  • CSE common service entity
  • AE M2M application entity
  • the ASN may communicate with one middle node or one infrastructure node through Mcc.
  • Mcc common service entity
  • ASN may be referred to as an M2M device.
  • a middle node may refer to a node having one common service entity (CSE) and zero or more M2M application entities (AEs).
  • CSE common service entity
  • AEs M2M application entities
  • the MN can communicate with one infrastructure node (IN) or another intermediate node (MN) via Mcc, can communicate with IN / MN / ASN via Mcc, or can communicate with ADN via Mca. have.
  • MN may be referred to as M2M gateway.
  • An infrastructure node may refer to a node having one common service entity (CSE) and zero or more application entities (AEs).
  • the IN may communicate with at least one intermediate node (MN) via Mcc and / or may communicate with at least one ASN.
  • the IN may communicate with one or more ADN through Mca.
  • IN may be referred to as an M2M server.
  • Example 1 illustrates communication between ADN and IN.
  • the ADN may be an M2M device with limited capabilities.
  • the ADN since the ADN does not have a CSE or a common service layer, the ADN may communicate with the CSE of the IN through Mca. Also, in this case, since the ADN does not have a CSE or common service layer, data generated at the AE or application layer cannot be stored / shared to another entity. Thus, in Example 1, data generated at the AE or the application layer of the ADN may be stored and shared in the CSE of the IN.
  • Example 2 illustrates the communication between ADN and MN.
  • ADN can also be an M2M device with limited capabilities.
  • ADN may operate similarly to Example 1 except that the ADN communicates with the CSE of the MN. That is, the ADN may communicate with the CSE of the MN through the Mca.
  • ADN since ADN does not have a CSE or common service layer, data generated at the AE or application layer cannot be stored / shared to other entities. Therefore, data generated at the AE or the application layer of the ADN may be stored and shared in the CSE of the MN.
  • the MN may communicate with the IN via the MN.
  • MN and MN, and MN and IN can communicate through Mcc. It is also possible for the MN to communicate with IN directly without passing through the MN.
  • Example 3 illustrates the communication between ASN and MN. Unlike example 1 or example 2, since the ASN has a CSE or common service layer, data generated at the AE or application layer of the ASN can be stored in its CSE or common service layer. In addition, the AE of the ASN may communicate with the CSE of the MN through the CSE of the ASN.
  • Example 4 illustrates the communication between ASN and MN.
  • the CSE of the ASN can communicate with the CSE of the IN directly without going through the MN.
  • the IN may be located in an infrastructure domain or a network domain and may include one CSE and zero or more AEs.
  • the INs can communicate with each other via Mcc.
  • 5 illustrates a resource or resource used in an M2M system.
  • an application entity a CSE, data, etc.
  • a resource refers to a uniquely addressable entity using a unique address (eg, a Universal Resource Identifier or Uniform Resource Identifier (URI)).
  • resources are represented as specific data structures, and each resource can be logically connected to each other. Resources may be managed and stored by the CSE or common service layer. Thus, the CSE or common service layer of the M2M device, the M2M gateway, the M2M server may have these resources.
  • the AE or application layer of the M2M system may not have such a resource structure.
  • Each resource has a child resource and attributes.
  • a root resource may have an attribute and a child resource.
  • resources can be represented as a tree structure.
  • the type of the root resource may be represented as ⁇ baseURI> or ⁇ CSEBase>.
  • the type of resource may be indicated by " ⁇ " and ">".
  • M2M applications can communicate based on resources whose resource types are instantiated. For example, it can be used to perform M2M services such as registering an application and reading sensor values.
  • Each resource is given unique address information (e.g. URI) when an instance of that resource type is created, and can have the same properties and child resources as the root resource.
  • Each resource is addressed using unique address information.
  • the specific resource type defines the child resources and attributes that the resource can have when instantiated. In a specific resource instantiation, a resource may have attributes and child resources defined in the resource type of the resource.
  • Child resources can have their own attributes and their own child resources.
  • child resources include remote CSE resources, application entity resources, access control resources, container resources, group resources, subscription resources, and so on.
  • the remote CSE resource contains information of other CSEs registered (connected) to the CSE.
  • the type of the remote CSE resource may be indicated as ⁇ entity> or ⁇ remoteCSE>.
  • Application entity resources of the root resource e.g. ⁇ baseURI> / ⁇ application> or ⁇ CSEBase> / ⁇ AE>
  • remote CSE resources of the root resource e.g. ⁇ baseURI> / ⁇ entity> or ⁇ CSEBase
  • ⁇ remote CSE> e.g. ⁇ remote CSE>
  • the information of the registered application entity is stored, and the information of the application entities registered in the specific remote CSE when it exists under the remote CSE resource (eg, ⁇ baseURI> / ⁇ entity> or ⁇ CSEBase> / ⁇ remote CSE>) of the root resource. Save it.
  • the type of application entity resource may be indicated as ⁇ application> or ⁇ AE>.
  • -Access Control Resource Resource that stores information related to access authority. Authorization may be performed using the access right information included in the resource.
  • the type of access control resource may be represented as ⁇ accessRight> or ⁇ accessControlPolicy>.
  • -Container resource Stores data generated for each CSE or AE.
  • the type of container resource may be represented as ⁇ container>.
  • -Group Resource Provides a function to group several resources together and process them together.
  • the type of group resource may be indicated as ⁇ group>.
  • -Subscription resource This function informs the status of resource change through notification.
  • the type of the subscription resource may be indicated as ⁇ subscription>.
  • resources for a specific M2M application may be stored in an Application Resource in a resource of a CSE or a common service layer of the M2M Gateway.
  • Resources for a particular M2M application may have attributes and child resources similar to the entire resource.
  • the child resource is defined as a type (eg, denoted by “ ⁇ ”, “>”), and the actual name is given and stored when materialized.
  • FIG. 7 illustrates a communication flow of a typical M2M system.
  • the operation of the M2M system is performed based on the data exchange.
  • a specific device may transmit a corresponding command in the form of data to another device to stop the operation of another device.
  • a specific type of data structure is used to store data in the device, which is called a resource. Resources can be accessed using unique addresses (eg URIs).
  • a Request and Response Scheme is used in the connection between the AE and the CSE or in the connection between the CSEs.
  • the originator may send a request message to request a resource stored in a receiver and receive a response message in response.
  • the recipient may receive a message requesting a resource from the sender and send a response message to the sender in response.
  • a request message may be abbreviated as a request and a response message may be abbreviated as a response.
  • the request message transmitted from the sender to the receiver may include the following information.
  • op the type of operation to be performed. It may be one of Create / Retrieve / Update / Delete / Notify.
  • information corresponding to an operation may be referred to as a command.
  • URI Uniform Resource Identifier
  • the event category indicates the event category used to handle the request.
  • the event category may affect how requests that access remote hosted resources will be handled at the recipient (eg, the recipient's CMDH CSF).
  • the event category may indicate information indicating the importance of the caller request.
  • the ec of the request message may be set to, for example, 'immediate', 'bestEffort', 'latest', and the like. If ec is set to 'immediate', requests in this category are sent as soon as possible because they represent important requests and no further CMDH processing is performed. For example, if communication over the underlying network is possible, these requests may be sent without being stored in the CMDH buffer.
  • requests in this category may be stored in the CMDH buffer for any time at the discretion of the CSE and delivered on Mcc on a best effort basis. If ec is set to 'latest', requests in this category go through normal CMDH processing, and if requests are pending, older requests are replaced by recent requests within the maximum buffer size.
  • the response message may include the following information.
  • the response message may include at least one of the following information, or may include only the result value rs.
  • identification information (or ID) of the originator that created the request
  • rs the result of the request (e.g. Okay, Okay and Done, Okay and in progress)
  • the response message may include the following information.
  • a sender may refer to a sender device or sender entity (or CSE or AE therein), and a receiver may refer to a receiver device or receiver entity (or CSE or AE therein).
  • an entity that relays a message transmitted from the originator device to the recipient device in the middle may be referred to as a relay device or a relay entity (or CSE therein).
  • a device having a resource (or CSE therein) may be referred to as a hosting device or hosting entity (or hosting CSE).
  • FIG 8 illustrates an example in which different entities interoperate in an M2M system.
  • the M2M device may include a sensor that is a physical device, and the AE registered in the IN may read the sensor value of the M2M device.
  • the AE (application1) existing on the M2M device reads the value from the sensor and stores the read value in the form of a resource (eg, ⁇ container> resource) in the CSE (dcse) registered by the sensor. To this end, the AE (application1) existing on the M2M device must first register with the CSE present in the M2M device. As illustrated in FIG. 8, when registration is completed, M2M application related information registered in the form of a dcse / applications / application1 resource is stored.
  • a resource eg, ⁇ container> resource
  • an AE application2 registered in an IN (Infrastructure Node) may access the value.
  • AE application2 must be registered in the CSE (ncse) of the IN (Infrastructure Node) in order to access the M2M device. This is stored in the ncse / applications / application2 resource information about the AE (application2), such as how the AE (application1) is registered in the CSE (dcse).
  • the AE (application1) may communicate directly with the intermediate CSE (ncse) and CSE (dcse) rather than directly communicating with the AE (application2).
  • CSE (ncse) and CSE (dcse) must be mutually registered.
  • CSE (dcse) registers with CSE (ncse) dcse related information (eg, Link) is stored under ncse / cses / dcse resource.
  • the AE (application2) obtains a path for accessing the information of the AE (application1) and can read the value of the sensor through the corresponding path.
  • FIG. 9 illustrates a procedure related to a subscription resource.
  • an entity that is interested in a change of a resource according to a change of a resource may subscribe to a notification of the change.
  • a resource for subscription in order to subscribe to the notification, a resource for subscription must be set.
  • the resource for the subscription may be referred to as a subscription resource or a ⁇ subscription> resource.
  • the device (or entity) for which a subscription resource is set up and / or containing a subscription target resource is referred to as a hosting device (or hosting entity).
  • a subscription target resource may exist in the CSE of the M2M gateway.
  • the M2M gateway may be referred to as a hosting device and the CSE of the M2M gateway may be referred to as a hosting CSE.
  • the subscription resource may be used to perform a subscription procedure in a resource-oriented manner.
  • a subscription resource can be created to subscribe to a specific subscription target resource, a subscription condition can be changed by modifying the subscription resource, and the subscription resource can be deleted when the subscription is no longer desired.
  • the subscription resource includes information about subscribed-to resources.
  • the relationship between the subscription target resource and the subscription resource may be expressed as a parent-child relationship.
  • a ⁇ container> resource including a subscription target resource may have a ⁇ subscription> resource as a child resource.
  • the parent subscription target resource is deleted, the ⁇ subscription> resource may be deleted.
  • the subscription resource is a child resource
  • an entity indicating a change in the status of the parent resource according to the configuration (attribute setting) of the subscription resource is specified in the address information (e.g., notificationURI or contact attribute) in the subscription resource. Can be passed to.
  • the sender has a RETRIEVE (or READ) permission on a subscribeable resource, the sender may create a subscription resource.
  • the sender of a subscription resource becomes a resource subscriber. If there is a modification to a subscription target resource, the modification is compared to a specific attribute (eg, notificationCriteria attribute) to determine whether a notification is sent to the resource subscriber.
  • a specific attribute eg, notificationCriteria attribute
  • Subscription resources can have various attributes and child resources.
  • a subscription resource eg, a ⁇ subscription> resource
  • R / W represents read / write permission of the property and may be one of READ / WRITE (RW), READ ONLY (RO), and WRITE ONLY (WO).
  • Table 1 is only an example and the properties of the subscription resource may be configured differently from Table 1.
  • the filtering attribute (eg, notificationCriteria) is a list of conditions for modification / change of the subscription target resource, and each condition may be in a logical AND relationship.
  • the filtering attribute eg, notificationCriteria
  • the filtering attribute includes two conditions
  • a notification may be sent when the modification / change of the subscription target resource satisfies both conditions.
  • the filtering attribute includes two conditions
  • the amount of the notification message can be adjusted, and when the set filtering attribute is satisfied, the notification can be sent to the notification target entity, thereby preventing the notification message from overflowing.
  • Table 2 illustrates the conditions that may be included in the filtering attribute.
  • the subscription resource may have a scheduling resource (eg, ⁇ schedule>) resource including scheduling information as a child resource.
  • a scheduling resource eg, ⁇ schedule>
  • the scheduling resource represents scheduling information in the context of the parent resource.
  • a scheduling resource (eg, ⁇ schedule>) defines reachability schedule information of a corresponding node.
  • the scheduling resource is realized as a child resource of the subscription resource, it may be referred to as a notification scheduling resource (eg, notificationSchedule resource).
  • a scheduling resource or a notification scheduling resource (eg, a ⁇ schedule> or notificationSchedule resource) may be referred to simply as a scheduling resource.
  • the scheduling information set in the scheduling resource may indicate scheduling information for notification of the subscription resource. Scheduling information may be referred to herein as reachability schedule information.
  • Reachable herein may refer to a state in which messages can be sent or received between nodes
  • unreachable unreachable or non-reachable refers to a state in which messages cannot be sent or received between nodes. May be referred to.
  • a particular node may be referred to as being in reachable mode when the particular node is in a reachable state.
  • a particular node may be referred to as in an unreachable mode if the particular node is in an unreachable state.
  • reachability schedule information may indicate the time at which message transmission and reception can occur between nodes.
  • the connection state between nodes may be referred to as reachability.
  • the scheduling resource may have various attributes.
  • the scheduling resource may include attributes such as resource type, resourceID, parentID, expirationTime, creationTime, and lastModifiedTime (see Table 3).
  • RW / RO / WO represents the read / write permission of the property and can be one of READ / WRITE (RW), READ ONLY (RO), and WRITE ONLY (WO). Can be.
  • the frequency of occurrence indicates the number of times a corresponding attribute can occur in a ⁇ schedule> resource.
  • Table 3 is only an example and the attributes of the scheduling resource may be configured differently from Table 3.
  • the scheduling resource may include an attribute (eg, scheduleElement) for scheduling time information.
  • the attribute for scheduling time information may represent a time defined by seconds, minutes, hours, days, months, years, etc., may represent a repetition of time, and may be expressed as a wildcard (eg '*'). have.
  • the attribute for scheduling time information may indicate a time interval in which a specific node is in reachable mode or may indicate a time interval in which a specific node is in unreachable mode. For example, if the attribute for scheduling time information indicates a time interval in which a specific node is in reachable mode, the node may send and receive messages and connect with other nodes during the time interval specified in the attribute for scheduling time information. Can be in a state.
  • an attribute for scheduling time information indicates a time interval in which a node is in an unreachable mode
  • the node cannot transmit or receive a message during the time interval specified in the attribute for scheduling time information, and a connection with other nodes is not possible. May be in a missing state.
  • device 1 910 may perform the procedure illustrated in FIG. 9 to subscribe to a specific resource of device 2 920.
  • the device 1 910 may or may not be the target of notification of the change in the subscription target resource.
  • a specific resource corresponds to a subscription target resource
  • device 2 920 may correspond to a hosting device (or entity) because the device 2 920 includes a subscription target resource.
  • the device 1 910 may transmit a request for a subscription resource to the device 2 920 to subscribe to a specific resource.
  • the request for a subscription resource may be any one of a generation request, a collection request, a deletion request, and an update request of a subscription resource.
  • Each request may have the form of a request message according to the request-response scheme described with reference to FIG. 7.
  • the request for the subscription resource may include op information having C (Create), cn information including attribute information (eg, notificationURI, filterCriteria, expirationTime, etc.) of the subscription resource, and a device.
  • the request for the subscription resource may include all or part of the information described with reference to FIG. 7.
  • the device 2 920 processes the request if it can validate and process the request for the subscription resource. For example, when device 2 920 receives a creation request, whether the subscription target resource specified in the to information is available for subscription, and the request originator (eg, 910) has a RETRIEVE permission on the subscription target resource. Whether or not the address information (e.g. notificationURI) of the subscription resource does not point to the request originator (e.g. 910), the request originator (e.g. 910) notifies the entity or device specified in the address information (e.g. notificationURI) of the subscription resource.
  • the address information e.g. notificationURI
  • the host device or entity e.g., 920
  • the subscription resource's address information e.g. notificationURI
  • device 2 920 validates whether the request originator (eg, 910) has a DELETE permission, and if so, Delete a subscription resource.
  • the request originator eg, 910
  • the device 2 920 may process a request for a subscription resource, and then transmit a response message to the device 1 910.
  • the response message of S906 may have the same / similar form as the response message described with reference to FIG. 7.
  • the response message may include information to be returned.
  • the sender may be a device or entity (eg, 920) that is hosting a subscription resource.
  • the receiver may be a device (or entity) indicated by address information (eg, notificationURI) set in the subscription resource.
  • Predetermined policy information may be set for the procedure for notification and the sender may be set to send a notification message (eg NOTIFY) when the policy information is satisfied.
  • a notification message (eg NOTIFY) is a message triggered by a subscription resource.
  • the notification message can be sent to the receiver indicated by the address information (eg, notificationURI) set in the subscription resource when the change of the subscription target resource including the subscription resource as a child resource satisfies the filtering attribute (eg, notificationCriteria) set in the subscription resource.
  • the recipient of the notification message may be the same or different from the device or entity that created / set the subscription resource according to the setting of the subscription resource.
  • device 1 910 may be the same entity as device 3 930 or may be a different entity.
  • the notification message may include the following information.
  • fr identification or ID of the sender (eg 920)
  • Address information configured in the subscription resource e.g. notificationURI
  • cn data indicating the modified content of the subscribed resource and / or subscription reference information (e.g., the URI of the subscription resource) and / or other additional information that generated this notification message.
  • subscription reference information e.g., the URI of the subscription resource
  • the sender 920 may detect / detect a change in a subscription target resource.
  • the subscribed resource is the parent resource of the subscribed resource, and if a resource or attribute at the same level as the subscribed resource is modified / changed under the subscribed resource, the sender 920 (see, for example, SUB CSF or CSE FIG. 3) It can be recognized as a change of a subscription target resource.
  • an event may be generated.
  • step S1004 the sender 920 checks whether the change matches a specific attribute (eg, notificationCriteria) set in the subscription resource.
  • the particular attribute may include, for example, at least one of the attributes illustrated in Table 2. If the change in the subscription target resource does not satisfy all of the conditions included in the filtering attribute, the sender 920 may ignore the change.
  • the sender 920 transmits a notification message to the entity 930 indicated by address information (eg, notificationURI) set in the subscription resource.
  • the notification message of S1006 may include, for example, identification information of the caller 920, data indicating a change of the subscription target resource, and / or subscription reference information that generated the notification message. If the change of the subscription target resource does not satisfy any of the conditions included in the filtering attribute, the sender 920 may not transmit the generated notification message.
  • FIG. 11 illustrates a subscription and notification process in an environment where the connection state is not guaranteed.
  • a subscription and notification process occurs in a situation composed of two entities (eg, entity 1 and entity 2).
  • a subscription service may be performed as follows.
  • Entity 2 performs a subscription process for a specific resource of entity 1 (eg, “Resource n”). Through this process, entity2 may set up a subscription resource for a specific resource of entity1 (eg, “resource n”).
  • the entity 1 monitors a specific resource (eg, “resource n”) to which a subscription resource is set, and when a change occurs in the monitored resource, the entity 1 sends a notification message indicating the change of the entity. Can be sent to 2.
  • a specific resource eg, “resource n”
  • the notification message is transmitted to an address (eg, contact attribute in ETSI M2M, notificationURI attribute in oneM2M) set during the subscription process.
  • an address eg, contact attribute in ETSI M2M, notificationURI attribute in oneM2M
  • a connection state may not be guaranteed between entities due to a network failure, a device failure, a reachability schedule, or the like.
  • Notification messages generated in such an environment may not be transmitted from an originator (eg, entity 1) to a receiver (eg, entity 2). Therefore, in the prior art, in order to process notification messages generated when the connection status is not guaranteed, the generated notification messages are temporarily stored in the originator as shown in Fig. 12, and then transmitted to the receiver when the connection is restored. Can be.
  • FIG. 12 illustrates a method for sending messages to a recipient after a connection is recovered.
  • notification 1 to notification n occurs in a state where the connection state is not guaranteed
  • the caller returns a notification aggregation of the generated notification 1 to notification n. You can send to the receiver at once.
  • the sender may transmit the generated notification 1 to notification n one by one to the receiver one by one. .
  • notification messages sent after the connection is restored may not be needed at the receiver side.
  • the connection between the entities was lost at a certain time (eg, 1 pm to 3 pm) and then the connection was restored.
  • the data desired by the user at the time the connection is restored may be the latest data after 3 o'clock, or the data for the last 30 minutes.
  • the user When using the method illustrated in FIG. 12, the user must receive all data generated during a time when the connection state is not guaranteed. This method can reduce unnecessary data transmission efficiency and further reduce the performance of the entire system by sending and receiving unnecessary messages not only from the sender but also from the receiver side.
  • notification messages generated in an environment where the connection state is not guaranteed For example, suppose that the user has set up an emergency message when the temperature is higher than a certain temperature (eg, 30 degrees) as well as the room temperature. In the method illustrated in FIG. 12, since the priority for all the notification messages is set to be the same, there is no method of preferentially processing the important messages among the messages generated during the disconnection.
  • a certain temperature eg, 30 degrees
  • the present invention proposes attributes and a transmission algorithm for selectively processing a notification message generated during a time when there is no connection state between devices.
  • the examples according to the present invention are described around an M2M environment, but can be equally / similarly applied to other systems having a client-server (or sender-receiver) structure.
  • a subscriber may refer to an entity requesting a subscription and a hosting entity may refer to an entity having a monitored resource (or a subscription target resource).
  • the sender may refer to the entity transmitting the notification message
  • the receiver may refer to the entity finally receiving the notification message.
  • the hosting entity in the subscription process and the sender in the notification process may be the same entity.
  • connection state when the connection state is not guaranteed, the sender may not transmit the generated notification message to the receiver, and may be referred to as a connectionless state. Failure to guarantee connection status can occur for a variety of reasons, such as network failures, device failures, and reachability schedules. Meanwhile, when the connection state is guaranteed, it means a state in which the sender can normally transmit a notification message generated to the receiver, and may be referred to as a connected state or a connected state. In addition, the connection state may be referred to herein as reachability.
  • attribute information indicating the sender's notification policy is suggested. Attribute information indicating the sender's notification policy may be referred to as pendingNotification as a non-limiting example. Attribute information indicating the sender's notification policy may be set as one attribute of a subscription resource. Thus, attribute information indicating the sender's notification policy can be used in the subscription / notification process together with or separately from the attribute information illustrated in Table 1. For convenience of description, the attribute information indicating the sender's notification policy herein may be referred to as notification policy information and may be referred to as first attribute information.
  • the notification policy information (eg, pendingNotification attribute) indicates the action that the sender should take for the notification message during the unreachable period.
  • the unreachable time may be determined according to scheduling information indicated by the scheduling resource or the reachability schedule resource (see the description of FIG. 9).
  • notification policy information eg, pendingNotification attribute
  • Table 4 illustrates notification policy information (eg, pendingNotification attribute) according to the present invention.
  • RW / RO / WO represents the read / write permission of the property and can be one of READ / WRITE (RW), READ ONLY (RO), and WRITE ONLY (WO). Can be.
  • the number of occurrences (multiplicity) indicates the number of times a corresponding attribute can occur in a ⁇ subscription> resource.
  • notification policy information eg, pendingNotification attribute
  • both read / write may be allowed.
  • notification policy information (eg, pendingNotification attribute) may have four values. According to the value set in the notification policy information (eg, pendingNotification attribute), the sender processes notification messages generated when there is no connection state as follows. If there is no separate setting, for example, sendNone may be set as a default value among four illustrated values. In this specification, sendNone may be referred to as a first value, sendLatest is a second value, sendAllPending is a third value, and sendManual is a fourth value.
  • the sender does not store any notification messages that occur during times when the connection status is not guaranteed. In this case, all notification messages generated during a time when the connection state is not guaranteed may be discarded (not transmitted). When the sender recovers reachability, there is no stored notification message, so the sender does not need to send a notification message generated during a time when the connection state is not guaranteed.
  • This setting can be used when no pending notification is needed. For example, it can be applied to an application service that monitors the temperature of the current room.
  • notification policy information eg, pendingNotification attribute
  • notification 1 to notification n may occur according to the change of the subscription resource, and if there is no connection status between the sender and the receiver, a notification message is sent from the sender to the receiver. Can not.
  • the generated notification messages may be processed according to notification policy information (eg, pendingNotification attribute).
  • notification policy information eg, pendingNotification attribute
  • notification policy information eg, pendingNotification attribute
  • sendNone since notification policy information (eg, pendingNotification attribute) is set to sendNone, all notification messages generated while the connection status is not guaranteed are ignored and not stored. Therefore, it is not sent to the receiver even after recovering the connection state.
  • a notification message eg, notification n + 1 occurs in the connected state, it may be sent to the receiver.
  • the sender stores only the most recent message among the notification messages that occurred during times when the connection status is not guaranteed. In this case, the previously stored notification message is deleted. That is, the sender can save a new notification message and discard the remaining notification messages.
  • the sender may send the most recently stored notification message to the recipient when recovering reachability. This setting can be used when the most recent generated notification message among the residual notification messages is needed. For example, it may be applied to an application service that receives a report related to a device update.
  • the notification policy information eg, pendingNotification attribute
  • the ec value of the notification message may be set to 'latest' (see description related to FIG. 7).
  • notification policy information eg, pendingNotification attribute
  • notification 1 to notification n may occur according to the change of the subscription resource, and when the connection status between the sender and the receiver is not guaranteed, the notification message is sent from the sender to the receiver. It cannot be sent.
  • the generated notification messages may be processed according to notification policy information (eg, pendingNotification attribute).
  • notification policy information eg, pendingNotification attribute
  • the notification policy information eg, pendingNotification attribute
  • the most recently generated message eg, notification n
  • the newly generated message may be stored and the previously stored message may be discarded.
  • a notification message eg, notification n + 1 occurs in the connected state, it may be sent to the receiver.
  • the sender stores notification messages generated during times when the connection status is not guaranteed.
  • the notification message sent may be determined differently depending on what the sender can temporarily store.
  • the sender may send all stored notification messages to the receiver upon regainability. This setting can be used when all generated notification messages are needed. For example, it can be used for application services (car black boxes) that require statistical data or data analysis.
  • notification policy information eg, pendingNotification attribute
  • notification 1 to notification n may occur according to the change of the subscription resource, and when the connection status between the sender and the receiver is not guaranteed, the notification message is sent from the sender to the receiver. It cannot be sent.
  • the generated notification messages may be processed according to notification policy information (eg, pendingNotification attribute).
  • notification policy information eg, pendingNotification attribute
  • sendAllPending messages generated in a state where the connection state is not guaranteed may be stored.
  • all stored messages can be sent to the recipient after recovering the connection state.
  • all stored message aggregations are sent to the receiver since all generated notifications 1 through n are stored.
  • a notification message eg, notification n + 1 occurs in the connected state, it may be sent to the receiver.
  • the sender stores the notification message (s) arbitrarily set by the subscriber among all notification messages generated during the time when the connection state is not guaranteed.
  • a criterion that is arbitrarily set may be set, for example, such as a time (for example, 11 o'clock to 12 o'clock), a specific notification message designation (for example, 10 notification messages from a disconnected time point), and the like.
  • This setting may be used when setting subscriber's arbitrary criteria for the case that it cannot be processed by sendNone, sendLatest, and sendAllPending. For example, it may be used for a monitoring application service requesting a notification message generated between 18:00 and 16:00.
  • notification policy information eg, pendingNotification attribute
  • notification 1 to notification n may occur according to the change of the subscription resource, and when the connection status between the sender and the receiver is not guaranteed, the notification message is sent from the sender to the receiver. It cannot be sent.
  • the generated notification messages may be processed according to notification policy information (eg, pendingNotification attribute).
  • notification policy information eg, pendingNotification attribute
  • notification policy information is set to sendManual, only notification messages satisfying the set criteria among messages generated in a state where the connection state is not guaranteed may be stored. In addition, only messages stored after recovering the connection state can be sent to the recipient. In the example of FIG.
  • the set criteria indicate the notification messages generated after t 0 as relating to time, so that notifications 2 to n generated after t 0 can be stored and sent to the receiver after recovering the connection state. Can be.
  • the notification message bundle may be sent to the receiver based on the set criteria.
  • attribute information for setting the importance of a notification message generated at the sender.
  • attribute information eg, notificationEventCat attribute
  • notification importance information may be referred to as notification importance information and may be referred to as second attribute information.
  • the importance of the notification message may be set by dividing it into a specific number of event categories, and thus the importance of the notification message may be determined according to the corresponding event category.
  • notification importance information (eg, notificationEventCat attribute) defines an (event) category for the notification message triggered by the subscription resource.
  • notification importance information may indicate an event category to be included in the notification message to enable the receiver to correctly handle the notification message.
  • the notification importance information may be used in conjunction with pre-defined policy information for a specific system.
  • the notification importance information (eg, notificationEventCat attribute) may be set as one attribute of a subscription resource.
  • attribute information indicating the sender's notification policy can be used in the subscription / notification process together with or separately from the attribute information illustrated in Table 1.
  • notification importance information (eg, notificationEventCat attribute) may be set by the subscriber.
  • notification importance information may be defined as 'High', 'Medium' and 'Low'.
  • the notification message may be processed in preference to other notification messages.
  • Table 5 illustrates notification importance information (eg, notificationEventCat attribute) in accordance with the present invention.
  • notificationEventCat attribute the multiplicity of notification importance information (eg, notificationEventCat attribute) is 0 or 1
  • notification importance information eg, notificationEventCat attribute
  • both read / write may be allowed.
  • Figure 17 illustrates a notification process in accordance with the present invention.
  • the notification message may be transmitted in consideration of attribute information proposed by the present invention.
  • the reasons why the connection status between the entities is not guaranteed may be classified into network failures, device failures, and reachability schedules. If the connection is lost due to network and device failure, there is no way to recover it normally from the entity's perspective. However, if the connection status is due to the reachability schedule, the entity (eg, the sender) can send a message generated after changing the connection status. Therefore, in the present invention, when it is confirmed that the connection state is disconnected due to the reachability schedule in the notification process for the subscription, the attribute information (eg, notification policy information (eg, pendingNotification attribute) and / or notification importance information (eg, according to the present invention) , notificationEventCat property)).
  • notification policy information eg, pendingNotification attribute
  • notificationEventCat property notificationEventCat property
  • notification policy information eg, pendingNotification attribute
  • notification importance information eg, notificationEventCat attribute
  • the reachable mode and non-reachable mode described in the present invention may be defined as follows.
  • Reachable mode refers to a state in which a corresponding entity is in a normal operation state and can be connected to another entity or can transmit and receive messages with another entity.
  • the non-reachable mode refers to a state in which another entity cannot connect or cannot transmit or receive a message with another entity because of a limitation in the operation state of the corresponding entity.
  • an event may occur when a change occurs in a resource (or a subscription target resource) to which a subscription process is set.
  • An event may occur when a change of a subscription target resource is detected / detected.
  • a subscription resource may be preset as a child resource of a subscription target resource.
  • the sender checks the importance of the event occurred.
  • the sender can check the importance of the event generated based on the notification importance information (eg, notificationEventCat attribute) (refer to Table 5 related description).
  • the case of high importance may include a case where notificationEventCat is set to an immediate value.
  • the case where the importance level is not high may include a case where notificationEventCat is set to a value other than the immediate value (eg, bestEffort).
  • the sender may check the importance of the event and then set, for example, the ec value of the notification message to a value indicated by the notification importance information (eg, notificationEventCat attribute).
  • the notification importance information e.g., notificationEventCat attribute
  • at least one of other attributes (e.g., Table 1) and / or conditions (e.g., Table 2) set in the subscription resource together with notification importance information (e.g., notificationEventCat attribute) Can be used.
  • a notification message is generated after the process related to the attribute for event processing is finished. At this time, since the notification message is composed of event (s), the event category may be the same as the importance of the notification message.
  • the caller may proceed to step S1706 or S1714 according to the event importance. If the event importance is high at step S1704, the caller may proceed to step S1706. If the event importance is not high at step S1704, the caller may proceed to step S1714.
  • the caller may confirm / determine a connection state between the originator and the counterpart entity (or the receiver).
  • the connection state (or reachability) of the sender and the receiver may be determined based on scheduling resources (or scheduling information set therein) for each entity or device.
  • step S1706 or step S1714 the caller goes through a process of checking whether the status of the caller and the receiver are in reachable or unreachable mode. If there is no information to confirm the state of the entity, the caller may determine that the entity is in reachable mode.
  • the caller may check scheduling information (or reachability schedule information) through scheduling resources and check / determine a connection state (or reachability mode) through scheduling information of the corresponding entity.
  • the scheduling resource for the caller may be set as a child resource (eg, notificationSchedule resource) of the subscription resource.
  • the scheduling resource for the receiver may be set as a separate scheduling resource.
  • the scheduling resource eg, ⁇ schedule> or notificationSchedule resource
  • the caller can check the reachable or unreachable mode (and / or time interval) by using scheduling information (or an attribute (eg, scheduleElement) for scheduling time information) set in each scheduling resource. For example, if a sender checks a scheduling resource (eg, notificationSchedule resource) set as a child resource of a subscription resource and the caller corresponds to a time interval indicated by the scheduling information contained therein and the scheduling resource indicates an reachable time interval, the caller arrives. It may be determined that it is possible.
  • a scheduling resource eg, notificationSchedule resource
  • the receiver may be determined to be reachable. Can be. Similarly, whether the sender or the receiver is unreachable can be determined.
  • a separately set scheduling resource eg, ⁇ schedule> resource
  • connection status between entities can be classified into four types as follows.
  • step S1706 if it is determined that the generated notification message satisfies the "critical message" condition and there is no connection state (that is, case 1-both reachable mode of the sender and the receiver), the process may proceed to step S1708, respectively.
  • the process may proceed to step S1708, respectively.
  • it means that there is a connection state between the two entities, so the sender immediately sends the generated notification message to the receiver.
  • the generated notification message is an important message, the corresponding message may be processed in preference to other messages.
  • notification importance information eg, notificationEventCat attribute
  • the "important message” condition will cause the notification message with the ec value of the notification message set to 'immediate'.
  • ‘Immediate’ is only an example, and the “critical message” condition may be expressed in other values.
  • notification importance information such as the notificationEventCat attribute
  • the 'critical message' condition is It may mean a notification message in which the ec value is set to 'High'.
  • step S1706 if the generated notification message satisfies the "critical message" condition and there is no connection state (ie, Case 2-caller reachable mode, caller unreachable mode / Case 3-caller and caller unreachable mode), S1710 You can proceed to step.
  • the "critical message" condition ie, Case 2-caller reachable mode, caller unreachable mode / Case 3-caller and caller unreachable mode
  • the sender may process the notification messages generated according to a specific operation (for example, according to a value set in notification policy information (eg, pendingNotification attribute)) set for notification messages generated while the connection state is not established. .
  • the notification message processed according to the notification policy information (eg, pendingNotification attribute) may be sent to the receiver after the connection with the receiver is restored (see related description of Table 4). In this case, since the generated notification message is an important message, it may be processed in preference to other messages.
  • step S1706 if the generated notification message satisfies the "critical message" condition and there is no connection state (Case 4-caller unreachable mode, receiver reachable mode), step S1712 may be performed.
  • the generated notification message is an important message
  • the generated notification message may not be transmitted when there is no connection state between the two entities.
  • the sender may temporarily change the state of the originator from the unreachable mode to the reachable mode in order to transmit the notification message first.
  • the sender can send a notification message generated to the receiver and switch to the originally set device connection state (ie, unreachable mode) when the transmission is completed.
  • step S1716 may proceed.
  • the sender since there is a connection state between the two entities, the sender may immediately send the generated notification message to the receiver. In this case, since the importance of the generated notification message may be relatively low, the notification message may be processed at a low priority accordingly.
  • notification importance information eg, notificationEventCat attribute
  • 'immediate' which means that the ec value of the notification message is 'immediate' It may mean a notification message set to a value other than this. ‘Immediate’ is only an example, and the “critical message” condition may be expressed in other values.
  • notification importance information e.g., notificationEventCat attribute
  • notificationEventCat attribute is defined as 'High', 'Medium', or 'Low', it will not satisfy the 'critical message' condition. In this case, the ec value of the notification message may be set to 'Medium' or 'Low'.
  • step S1704 If the notification message in step S1704 does not satisfy the "critical message" condition, and it is determined in step S1714 that there is no connection state (that is, Case 2-caller reachable mode, caller not reachable mode / Case 3-caller and receiver reached Unavailable Mode / Case 4-Caller Unreachable, Callable Reachable), and proceeds to step S1718.
  • connection state that is, Case 2-caller reachable mode, caller not reachable mode / Case 3-caller and receiver reached Unavailable Mode / Case 4-Caller Unreachable, Callable Reachable
  • step S1718 the notification message generated when there is no connection state between the two entities may not be transmitted. Therefore, in step S1718, the sender may process the notification messages generated according to a specific operation (for example, according to the value set in the notification policy information (eg, pendingNotification attribute)) set for the notification messages generated while there is no connection state. (See description in Table 4).
  • the notification message processed according to the notification policy information (eg, pendingNotification attribute) may be sent to the receiver after the connection with the receiver is restored. At this time, since the importance of the generated notification message is relatively low, it can be processed with low priority accordingly.
  • FIG. 18 illustrates an embodiment of a notification process in accordance with the present invention.
  • FIG. 18 illustrates a specific embodiment of a caller operation performed in S1712 of FIG. 17.
  • a value representing “important message” to be processed first by the sender is “immediate”, and it is assumed that there is no connection state from t0 to t3 due to the preset unreachable mode of the sender.
  • the receiver may be in reachable mode.
  • the sender temporarily reaches the unreachable mode at time t1. It can be switched to the enabled mode and can send the corresponding notification message.
  • the sender can switch from reachable mode to unreachable mode at time t2. Only when there is an important message can the caller's connection be temporarily recovered to send the message, and after returning to the preset connection state after sending the important message.
  • the M2M gateway, M2M server or M2M device may operate as the transmitter 10 or the receiver 20, respectively.
  • the transmitter 10 and the receiver 20 are radio frequency (RF) units 13 and 23 capable of transmitting or receiving radio signals carrying information and / or data, signals, messages, and the like, and in a wireless communication system. It is operatively connected with components such as the memory (12, 22), the RF unit (13, 23) and the memory (12, 22) for storing a variety of information related to communication, by controlling the component
  • the apparatus comprises processors 11 and 21, respectively, configured to control the memory 12 and 22 and / or the RF units 13 and 23 to perform at least one of the embodiments of the invention described above.
  • the memories 12 and 22 may store programs for processing and control of the processors 11 and 21, and may store information input / output.
  • the memories 12 and 22 may be utilized as buffers.
  • the memories 12 and 22 may be used to store resources including various setting information and data.
  • the processors 11 and 21 typically control the overall operation of the various modules in the transmitter or receiver. In particular, the processors 11 and 21 may perform various control functions for carrying out the present invention.
  • the processors 11 and 21 may also be called controllers, microcontrollers, microprocessors, microcomputers, or the like.
  • the processors 11 and 21 may be implemented by hardware or firmware, software, or a combination thereof.
  • application specific integrated circuits ASICs
  • DSPs digital signal processors
  • DSPDs digital signal processing devices
  • PLDs programmable logic devices
  • FPGAs field programmable gate arrays
  • the firmware or software when implementing the present invention using firmware or software, may be configured to include a module, a procedure, or a function for performing the functions or operations of the present invention, and configured to perform the present invention.
  • the firmware or software may be provided in the processors 11 and 21 or stored in the memory 12 and 22 to be driven by the processors 11 and 21.
  • the processor 11 of the transmission apparatus 10 is predetermined from the processor 11 or a scheduler connected to the processor 11 and has a predetermined encoding and modulation on a signal and / or data to be transmitted to the outside. After performing the transmission to the RF unit 13.
  • the signal processing of the receiver 20 is the reverse of the signal processing of the transmitter 10.
  • the RF unit 23 of the receiving device 20 receives a radio signal transmitted by the transmitting device 10.
  • the processor 21 may decode and demodulate a radio signal received through a reception antenna to restore data originally transmitted by the transmission apparatus 10.
  • the RF units 13, 23 have one or more antennas.
  • the antenna transmits a signal processed by the RF units 13 and 23 to the outside under the control of the processors 11 and 21, or receives a radio signal from the outside to receive the RF unit 13. , 23).
  • the transmitter and the receiver are respectively communicated through the RF unit, but it is also possible for the transmitter and the receiver to communicate through a wired network.
  • the RF unit may be replaced with a network interface unit (NIU).
  • NNIU network interface unit
  • each component or feature is to be considered optional unless stated otherwise.
  • Each component or feature may be embodied in a form that is not combined with other components or features. It is also possible to combine some of the components and / or features to form an embodiment of the invention.
  • the order of the operations described in the embodiments of the present invention may be changed. Some components or features of one embodiment may be included in another embodiment or may be replaced with corresponding components or features of another embodiment. It is obvious that the claims may be combined to form an embodiment by combining claims that do not have an explicit citation relationship in the claims or as new claims by post-application correction.
  • Certain operations described in this document as being performed by a base station may in some cases be performed by an upper node thereof. That is, it is obvious that various operations performed for communication with the terminal in a network including a plurality of network nodes including a base station may be performed by the base station or other network nodes other than the base station.
  • a base station may be replaced by terms such as a fixed station, a Node B, an eNode B (eNB), an access point, and the like.
  • the terminal may be replaced with terms such as a user equipment (UE), a mobile station (MS), a mobile subscriber station (MSS), and the like.
  • Embodiments according to the present invention may be implemented by various means, for example, hardware, firmware, software, or a combination thereof.
  • an embodiment of the present invention may include one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), FPGAs ( field programmable gate arrays), processors, controllers, microcontrollers, microprocessors, and the like.
  • ASICs application specific integrated circuits
  • DSPs digital signal processors
  • DSPDs digital signal processing devices
  • PLDs programmable logic devices
  • FPGAs field programmable gate arrays
  • processors controllers, microcontrollers, microprocessors, and the like.
  • the present invention may be implemented by software code or instructions including a form of a module, procedure, function, etc. that performs the functions or operations described above.
  • the software code or instructions may be stored in a computer readable medium and driven by the processor and may perform operations according to the present invention when driven by the processor.
  • the computer readable medium may be located inside or outside the processor or remotely connected to the processor through a network, and may exchange data with the processor.
  • the present invention can be used in communication devices such as terminals, servers, gateways, and the like.

Abstract

본 발명은 M2M(Machine-to-Machine) 시스템에서 자원 구독(resource subscription)을 위한 통지(notification)를 수행하는 방법 및 이를 위한 장치에 관한 것으로서, 구독 자원을 자녀 자원으로서 포함하는 구독 대상 자원의 변화를 검출하는 단계; 상기 구독 자원에 설정된 제2 속성 정보에 따라 상기 변화의 이벤트 카테고리를 지시하는 값을 포함하는 통지 메시지를 생성하는 단계; 및 상기 M2M 디바이스를 위한 스케줄링 자원에 설정된 스케줄링 정보 및 수신 디바이스를 위한 스케줄링 자원에 설정된 스케줄링 정보를 기반으로 상기 수신 디바이스로의 도달가능성을 판별하는 단계를 포함하되, 상기 스케줄링 정보에 따라 상기 수신 디바이스가 도달가능하다고 판별되는 경우, 상기 통지 메시지는 즉시 상기 수신 디바이스로 전송되고, 상기 스케줄링 정보에 따라 상기 수신 디바이스가 도달가능하지 않다고 판별되는 경우, 상기 통지 메시지는 상기 구독 자원에 설정된 제1 속성 정보가 가지는 값에 따라 상기 M2M 디바이스에서 처리되고 상기 처리된 통지 메시지는 상기 수신 디바이스가 도달가능한 상태로 회복된 후 상기 수신 디바이스로 전송되는 방법 및 이를 위한 장치에 관한 것이다.

Description

M2M 시스템에서 통지 메시지 전달 방법 및 이를 위한 장치
본 발명은 M2M(Machine-to-Machine) 통신 시스템에 관한 것으로서, 보다 구체적으로 M2M 시스템에서 특정 자원을 구독하고 통지하는 방법 및 이를 위한 장치에 관한 것이다.
근래에 들어 M2M(Machine-to-Machine) 통신에 대한 관심이 높아지고 있다. M2M 통신은 사람의 개입 없이 기계(Machine)와 기계 사이에 수행되는 통신을 의미하며, MTC(Machine Type Communication) 또는 IoT(Internet of Things) 통신으로도 지칭된다. M2M 통신에 사용되는 단말을 M2M 디바이스(M2M device)라고 지칭하는데, M2M 디바이스는 일반적으로 낮은 이동성(low mobility), 시간 내성(time tolerant) 또는 지연 내성(delay tolerant), 작은 데이터 전송(small data transmission)등과 같은 특성을 가지며, 기계 간 통신 정보를 중앙에서 저장하고 관리하는 M2M 서버와 연결되어 사용된다. 또한, M2M 디바이스가 서로 다른 통신 방식을 따라 연결되면, 통신 방식이 변경되는 구간에서 M2M 게이트웨이를 통해 M2M 디바이스와 M2M 서버가 연결되며, 이를 통해 전체 M2M 시스템이 구성된다. 해당 시스템을 기반으로 사물 추적(Tracking), 전력 계량(Metering), 자동 지불 시스템(Payment), 의료 분야 서비스, 원격 조정 등의 서비스가 제공될 수 있다.
본 발명은 M2M 시스템에 관한 것이다.
본 발명의 목적은 M2M 시스템에서 효율적으로 신호를 송수신하는 방법 및 이를 위한 장치를 제공하는 데 있다.
본 발명의 다른 목적은 M2M 시스템에서 엔티티간의 연결 상태가 보장되지 않는 환경에서 통지 메시지를 송수신하는 방법 및 이를 위한 장치를 제공하는 데 있다.
본 발명의 또 다른 목적은 M2M 시스템에서 불필요한 통지 메시지를 전송하지 않음으로써 데이터 전송 효율 및 전체 시스템 성능을 개선하는 방법 및 이를 위한 장치를 제공하는 데 있다.
본 발명의 또 다른 목적은 M2M 시스템에서 통지 메시지의 중요도를 설정가능하게 함으로써 사용자에 의하여 설정된 중요 메시지에 대하여 우선적으로 전송하는 방법 및 이를 위한 장치를 제공하는 데 있다.
본 발명에서 이루고자 하는 기술적 과제들은 상기 기술적 과제로 제한되지 않으며, 언급하지 않은 또 다른 기술적 과제들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
본 발명의 일 양상으로, M2M(Machine-to-Machine) 디바이스에서 자원 구독(resource subscription)을 위한 통지(notification)를 수행하는 방법이 개시되며, 상기 방법은 구독 자원을 자녀 자원으로서 포함하는 구독 대상 자원의 변화를 검출하는 단계; 상기 구독 자원에 설정된 제2 속성 정보에 따라 상기 변화의 이벤트 카테고리를 지시하는 값을 포함하는 통지 메시지를 생성하는 단계; 및 상기 M2M 디바이스를 위한 스케줄링 자원에 설정된 스케줄링 정보 및 수신 디바이스를 위한 스케줄링 자원에 설정된 스케줄링 정보를 기반으로 상기 수신 디바이스로의 도달가능성을 판별하는 단계를 포함하되, 상기 스케줄링 정보에 따라 상기 수신 디바이스가 도달가능하다고 판별되는 경우, 상기 통지 메시지는 즉시 상기 수신 디바이스로 전송되고, 상기 스케줄링 정보에 따라 상기 수신 디바이스가 도달가능하지 않다고 판별되는 경우, 상기 통지 메시지는 상기 구독 자원에 설정된 제1 속성 정보가 가지는 값에 따라 상기 M2M 디바이스에서 처리되고 상기 처리된 통지 메시지는 상기 수신 디바이스가 도달가능한 상태로 회복된 후 상기 수신 디바이스로 전송될 수 있다.
본 발명의 다른 양상으로, M2M(Machine-to-Machine) 디바이스가 제공되며, 상기 M2M 디바이스는 네트워크 인터페이스 유닛(Network Interface Unit); 및 상기 네트워크 인터페이스 유닛과 동작시 연결되는(operatively connected) 프로세서를 포함하며, 상기 프로세서는 구독 자원을 자녀 자원으로서 포함하는 구독 대상 자원의 변화를 검출하고, 상기 구독 자원에 설정된 제2 속성 정보에 따라 상기 변화의 이벤트 카테고리를 지시하는 값을 포함하는 통지 메시지를 생성하고, 상기 M2M 디바이스를 위한 스케줄링 자원에 설정된 스케줄링 정보 및 수신 디바이스를 위한 스케줄링 자원에 설정된 스케줄링 정보를 기반으로 상기 수신 디바이스로의 도달가능성을 판별하도록 구성되며, 상기 스케줄링 정보에 따라 상기 수신 디바이스가 도달가능하다고 판별되는 경우, 상기 통지 메시지는 즉시 상기 수신 디바이스로 전송되고, 상기 스케줄링 정보에 따라 상기 수신 디바이스가 도달가능하지 않다고 판별되는 경우, 상기 통지 메시지는 상기 구독 자원에 설정된 제1 속성 정보가 가지는 값에 따라 상기 M2M 디바이스에서 처리되고 상기 처리된 통지 메시지는 상기 수신 디바이스가 도달가능한 상태로 회복된 후 상기 수신 디바이스로 전송될 수 있다.
바람직하게는, 상기 구독 자원과 상기 스케줄링 자원 각각은 고유한 주소를 이용하여 고유하게 어드레싱 가능한 데이터 구조를 나타낼 수 있다.
바람직하게는, 상기 제2 속성 정보는 상기 구독 자원에 의해 트리거링되는 상기 통지 메시지를 위한 이벤트 카테고리를 정의하며, 상기 통지 메시지에 포함된 이벤트 카테고리를 지시하는 값은 상기 수신 디바이스가 상기 통지 메시지를 정확하게 핸들링하는 데 이용될 수 있다.
바람직하게는, 상기 제1 속성 정보는 상기 스케줄링 정보에 따라 상기 수신 디바이스로 도달가능하지 않은 시간 구간이 지난 다음 상기 M2M 디바이스가 수행할 통지 메시지의 처리 동작을 지시할 수 있다.
바람직하게는, 상기 스케줄링 정보에 따라 상기 수신 디바이스가 도달가능하지 않다고 판별되는 경우, 상기 통지 메시지를 처리하는 것은 상기 제1 속성 정보가 제1 값을 갖는 경우, 상기 생성된 통지 메시지를 폐기하는 것과, 상기 제1 속성 정보가 제2 값을 갖는 경우, 상기 생성된 통지 메시지를 저장하고 이전에 저장된 통지 메시지를 폐기하는 것과, 상기 제1 속성 정보가 제3 값을 갖는 경우, 상기 생성된 통지 메시지를 모두 저장하는 것을 포함할 수 있다.
바람직하게는, 상기 M2M 디바이스의 스케줄링 정보가 도달가능함을 지시하고 상기 수신 디바이스의 스케줄링 정보가 도달가능함을 지시하는 경우, 상기 수신 디바이스는 도달가능하다고 판별될 수 있다.
바람직하게는, 상기 M2M 디바이스의 스케줄링 정보가 도달불가함을 지시하거나 상기 수신 디바이스의 스케줄링 정보가 도달불가함을 지시하는 경우, 상기 수신 디바이스는 도달불가하다고 판별될 수 있다.
본 발명에 의하면, M2M 시스템에서 효율적으로 신호를 송수신할 수 있다.
본 발명에 의하면, M2M 시스템에서 엔티티간의 연결 상태가 보장되지 않는 환경에서 통지 메시지를 송수신할 수 있다.
본 발명에 의하면, M2M 시스템에서 불필요한 통지 메시지를 전송하지 않음으로써 데이터 전송 효율 및 전체 시스템 성능을 개선할 수 있다.
본 발명에 의하면, M2M 시스템에서 통지 메시지의 중요도를 설정가능하게 함으로써 사용자에 의하여 설정된 중요 메시지에 대하여 우선적으로 전송할 수 있다.
본 발명에서 얻을 수 있는 효과는 이상에서 언급한 효과들로 제한되지 않으며, 언급하지 않은 또 다른 효과들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
첨부 도면은 본 발명에 관한 이해를 돕기 위해 상세한 설명의 일부로 포함되며, 본 발명에 대한 실시예를 제공하고, 상세한 설명과 함께 본 발명의 기술적 사상을 설명한다.
도 1은 M2M 시스템을 예시한다.
도 2는 M2M 시스템의 계층 구조(layered structure)를 예시한다.
도 3은 M2M 시스템의 기능적 아키텍처(functional architecture)를 예시한다.
도 4는 M2M 시스템의 구성을 예시한다.
도 5는 M2M 시스템에서 사용되는 리소스(resource)를 예시한다.
도 6은 특정 M2M 애플리케이션을 위한 리소스를 예시한다.
도 7은 일반적인 M2M 시스템의 통신 흐름을 예시한다.
도 8은 M2M 시스템에서 서로 다른 엔티티들이 상호 연동하는 예를 예시한다.
도 9는 구독 자원과 관련된 절차를 예시한다.
도 10은 통지를 위한 절차를 예시한다.
도 11 및 도 12는 연결 상태가 보장되지 않는 환경에서 구독 및 통지 과정을 예시한다.
도 13 내지 도 16은 통지 정책 정보에 따른 통지 방법을 예시한다.
도 17은 본 발명에 따른 통지 과정을 예시한다.
도 18은 본 발명에 따른 통지 과정의 실시예를 예시한다.
도 19는 본 발명이 적용될 수 있는 장치의 블록도를 예시한다.
본 발명에 따른 바람직한 실시예를 첨부된 도면을 참조하여 상세하게 설명한다. 첨부된 도면과 함께 이하에 개시될 상세한 설명은 본 발명의 예시적인 실시예를 설명하고자 하는 것이며, 본 발명이 실시될 수 있는 유일한 실시예를 나타내고자 하는 것이 아니다. 이하의 상세한 설명은 본 발명의 완전한 이해를 제공하기 위해서 구체적 세부사항을 포함한다. 그러나, 본 발명이 속하는 분야에서 통상의 기술자는 본 발명이 이러한 구체적 세부사항 없이도 실시될 수 있음을 안다.
몇몇 경우, 본 발명의 개념이 모호해지는 것을 피하기 위하여 공지의 구조 및 장치는 생략되거나, 각 구조 및 장치의 핵심기능을 중심으로 한 블록도 형식으로 도시될 수 있다. 또한, 본 명세서에서 동일한 구성요소에 대해 동일한 도면 부호가 사용될 수 있다.
본 명세서에서, M2M 디바이스(M2M device)는 M2M(Machine-to-Machine) 통신을 위한 디바이스를 지칭한다. M2M 디바이스는 고정되거나 이동성을 가질 수 있으며 M2M 서버와 통신하여 사용자 데이터 및/또는 제어 정보를 송수신할 수 있다. M2M 디바이스는 단말(Terminal Equipment), MS(Mobile Station), MT(Mobile Terminal), UT(User Terminal), SS(Subscribe Station), 무선 장치(wireless device), PDA(Personal Digital Assistant), 무선 모뎀(wireless modem), 휴대 장치(handheld device) 등으로 지칭될 수 있다. 본 발명에 있어서, M2M 서버는 M2M 통신을 위한 서버를 지칭하며 고정국(fixed station) 또는 이동국(mobile station)으로 구현될 수 있다. M2M 서버는 M2M 디바이스들 및/또는 다른 M2M 서버와 통신하여 데이터 및 제어 정보를 교환할 수 있다. 또한, M2M 게이트웨이는 M2M 디바이스가 연결된 네트워크와 M2M 서버가 연결된 네트워크가 서로 다른 경우, 한 네트워크에서 다른 네트워크로 들어가는 연결점 역할을 수행하는 장치를 지칭한다. 또한, M2M 게이트웨이는 M2M 디바이스로서 기능을 수행할 수 있으며, 이외에 예를 들어 M2M 게이트웨이에 연결된 M2M 디바이스를 관리하거나, 하나의 메시지를 수신하여 연결된 M2M 디바이스들에게 동일 또는 변경된 메시지를 전달하거나(message fanout), 메시지 집적(message aggregation)하는 기능을 수행할 수 있다. M2M 디바이스라는 용어는 M2M 게이트웨이와 M2M 서버를 포함하는 개념으로 사용될 수 있고, 따라서 M2M 게이트웨이와 M2M 서버는 M2M 디바이스로 지칭될 수 있다.
또한, 본 명세서에서 “엔티티(entity)”라는 용어는 M2M 디바이스, M2M 게이트웨이, M2M 서버와 같은 하드웨어를 지칭하는 데 사용될 수 있고, 또는 아래에서 설명되는 M2M 애플리케이션 계층과 M2M (공통) 서비스 계층의 소프트웨어 컴포넌트(software component)를 지칭하는 데 사용될 수 있다.
이하에서, 본 발명은 M2M 시스템을 중심으로 설명되지만 본 발명은 M2M 시스템에만 제한적으로 적용되는 것은 아니며, 예를 들어 클라이언트-서버(또는 송신자-응답자(sender-responder)) 모델에 따른 시스템에도 동일/유사하게 적용될 수 있다.
도 1은 M2M 시스템을 예시한다. 도 1은 ETSI(European Telecommunications Standards Institute) 기술 규격(Technical Specification, TS)에 따른 M2M 시스템을 예시한다.
ETSI TS M2M 기술 규격에 따른 M2M 시스템은 다양한 M2M 애플리케이션(Application)을 위한 공통 M2M 서비스 프레임워크(Service Framework)를 정의한다. M2M 애플리케이션은 e헬스(e-Health), 도시 자동화(City Automation), 커넥티드 컨슈머(Connected Consumer), 오토모티브(Automotive)와 같은 M2M 서비스 솔루션을 구현하는 소프트웨어 컴포넌트(software component)를 지칭할 수 있다. M2M 시스템에서는 이러한 다양한 M2M 애플리케이션을 구현하기 위해 공통적으로 필요한 기능들을 제공되며, 공통적으로 필요한 기능들은 M2M 서비스 또는 M2M 공통 서비스라고 지칭될 수 있다. 이러한 M2M 공통 서비스를 이용하면 각 M2M 애플리케이션마다 기본 서비스 프레임워크를 다시 구성할 필요 없이 M2M 애플리케이션이 쉽게 구현될 수 있다.
M2M 서비스는 서비스 능력(Service Capability, SC)의 집합 형태로 제공되며, M2M 애플리케이션은 오픈 인터페이스(open interface)를 통해 SC(Service Capability)의 집합 또는 SC(Service Capability)에 접근하여 SC(Service Capability)가 제공하는 M2M 서비스 또는 기능을 이용할 수 있다. SC는 M2M 서비스를 구성하는 기능 (예, 디바이스 관리, 위치, 발견, 그룹 관리, 등록, 보안 등)을 제공할 수 있고, SC 계층(Service Capabilities Layer) 또는 SC 엔티티(Service Capability Entity)는 M2M 애플리케이션이 서비스 프레임워크 상에서 제공될 때 사용할 수 있는 M2M 서비스를 위한 기능(function)들의 집합이라고 할 수 있다.
SC(Service Capability)는 xSC로 표현될 수 있다. 여기서, x는 N/G/D 중의 하나로 표현될 수 있으며, SC(Service Capability)가 네트워크(Network)(및/또는 서버), 게이트웨이(Gateway), 디바이스(Device) 중 어디에 존재하는지를 나타낸다. 예를 들어, NSC는 네트워크 및/또는 서버 상에 존재하는 SC(Service Capability)를 나타내고, GSC는 게이트웨이 상에 존재하는 SC(Service Capability)를 나타낸다.
M2M 애플리케이션은 네트워크, 게이트웨이, 또는 디바이스 상에 존재할 수 있다. 네트워크 상에 존재하거나 서버와 직접 연결되어 존재하는 M2M 애플리케이션은 M2M 네트워크 애플리케이션(M2M Network Application)라고 지칭되며 간략히 NA(Network Application)로 나타낼 수 있다. 예를 들어, NA는 서버에 직접 연결되어 구현되는 소프트웨어이며, M2M 게이트웨이 또는 M2M 디바이스와 통신하고 이들을 관리하는 역할을 수행할 수 있다. 디바이스 상에 존재하는 M2M 애플리케이션은 M2M 디바이스 애플리케이션(M2M Device Application)이라고 지칭되며 간략히 DA(Device Application)로 나타낼 수 있다. 예를 들어, DA는 M2M 디바이스에서 구동되는 소프트웨어이며, 센서 정보 등을 NA에게 전달할 수도 있다. 게이트웨이 상에 존재하는 M2M 애플리케이션은 M2M 게이트웨이 애플리케이션(Gateway Application)이라고 지칭되며 간략히 GA(Gateway Application)로 나타낼 수 있다. 예를 들어, GA는 M2M 게이트웨이를 관리하는 역할도 할 수 있고 DA에게 M2M 서비스 또는 기능(예, SCs(Service Capabilities) 또는 SC(Service Capability))를 제공할 수도 있다. M2M 애플리케이션은 애플리케이션 엔티티(AE)와 애플리케이션 계층을 통칭할 수 있다.
도 1을 참조하면, M2M 시스템 아키텍처는 네트워크 도메인과 디바이스 및 게이트웨이 도메인으로 구분될 수 있다. 네트워크 도메인은 M2M 시스템 관리를 위한 기능(function)들과 네트워크 관리를 위한 기능(function)들을 포함할 수 있다. M2M 시스템 관리를 위한 기능은 디바이스 및 게이트웨이 도메인에 존재하는 디바이스들을 관리하는 M2M 애플리케이션과 M2M SCs(Service Capabilities)에 의해 수행될 수 있고, 네트워크 관리를 위한 기능은 코어 네트워크와 액세스 네트워크에 의해 수행될 수 있다. 따라서, 도 1의 예에서, 코어 네트워크와 액세스 네트워크는 M2M 기능을 수행한다기보다는 각 엔티티들 간의 연결을 제공한다. 코어 네트워크와 액세스 네트워크를 통해 네트워크 도메인과 디바이스 및 게이트웨이 도메인에서 M2M SCs(Service Capabilities) 간에 M2M 통신이 수행될 수 있으며, 각 도메인의 M2M 애플리케이션은 각 도메인의 M2M SCs(Service Capabilities)를 통해 신호 또는 정보를 주고 받을 수 있다.
액세스 네트워크(Access Network)는 M2M 디바이스 및 게이트웨이 도메인이 코어 네트워크와 통신을 가능하게 하는 엔티티이다. 액세스 네트워크의 예로는 xDSL(Digital Subscriber Line), HFC(Hybrid Fiber Coax), 위성(satellite), GERAN, UTRAN, eUTRAN, 무선(Wireless) LAN, WiMAX 등이 있다.
코어 네트워크(Core Network)는 IP(Internet Protocol) 연결, 서비스와 네트워크 제어, 상호연결, 로밍(roaming) 등의 기능을 제공하는 엔티티이다. 코어 네트워크는 3GPP(3rd Generation Partnership Project) 코어 네트워크, ETSI TISPAN(Telecommunications and Internet converged Services and Protocols for Advanced Networking) 코어 네트워크와 3GPP2 코어 네트워크 등을 포함한다.
M2M SC(Service Capability)는 여러 M2M 네트워크 애플리케이션들에서 공유될 수 있는 M2M 공통 서비스 기능(Common Service Function, CSF)을 제공하고 M2M 서비스를 오픈 인터페이스(open interface)를 통해 노출하여 M2M 애플리케이션들이 M2M 서비스를 이용할 수 있게 한다. M2M SCL(Service Capability Layer)은 이러한 M2M SC 엔티티들 또는 M2M 공통 서비스 기능들을 포함하는 계층을 지칭할 수 있다.
M2M 애플리케이션은 서비스 로직(service logic)을 동작시키고, 오픈 인터페이스를 통해 M2M SCs(Service Capabilities)를 사용할 수 있는 엔티티이다. M2M 애플리케이션 계층은 이러한 M2M 애플리케이션 및 관련 동작 로직(operational logic)을 포함하는 계층을 지칭할 수 있다.
M2M 디바이스는 M2M SCs(Service Capabilities)를 통해 M2M 디바이스 애플리케이션을 동작시키는 엔티티이다. M2M 디바이스는 직접 네트워크 도메인의 M2M 서버와 통신할 수도 있으며, M2M 게이트웨이를 통해서 네트워크 도메인의 M2M 서버와 통신할 수도 있다. M2M 게이트웨이를 통해서 연결될 경우에는 M2M 게이트웨이는 프록시(proxy)와 같이 동작한다. M2M 디바이스는 M2M 애플리케이션 및/또는 M2M SCs(Service Capabilities)를 포함할 수 있다.
M2M 영역 네트워크(M2M area network)는 M2M 디바이스와 M2M 게이트웨이 간의 연결(connectivity)을 제공한다. 이 경우, M2M 게이트웨이와 M2M 서버 간 네트워크와 M2M 디바이스와 M2M 게이트웨이 간 네트워크가 서로 상이할 수 있다. 예를 들어, M2M 영역 네트워크는 IEEE802.15.1, 지그비(Zigbee), 블루투스(Bluetooth), IETF ROLL, ISA100.11a와 같은 PAN(Personal Area Network) 기술과 PLC(Power Line Communication), M-BUS, 무선 M-BUS, KNX와 같은 로컬 네트워크 기술을 이용하여 구현될 수 있다.
M2M 게이트웨이는 M2M SCs(Service Capabilities)를 통해 M2M 애플리케이션을 관리하고 M2M 애플리케이션에 대해 서비스를 제공하는 엔티티이다. M2M 게이트웨이는 M2M 디바이스와 네트워크 도메인간의 프록시 역할을 수행하고 ETSI 비-호환(non-compliant) M2M 디바이스에도 서비스를 제공하는 역할을 수행할 수 있다. M2M 게이트웨이는 M2M 디바이스들 중 게이트웨이 기능을 갖는 엔티티를 지칭할 수 있다. M2M 게이트웨이는 M2M 애플리케이션 및/또는 M2M SCs(Service Capabilities)를 포함할 수 있다.
도 1에 예시된 M2M 시스템 아키텍처는 예시에 불과하고 각 엔티티의 명칭은 달라질 수 있다. 예를 들어, M2M SC(Service Capability)는 M2M 공통 서비스 기능(common service function, CSF)로 지칭될 수 있고, SCL(Service Capability Layer)는 공통 서비스 계층(Common Service Layer, CSL) 또는 공통 서비스 엔티티(Common Service Entity, CSE)으로 지칭될 수 있다. 또한, M2M 애플리케이션은 애플리케이션 엔티티(application entity, AE)로 지칭될 수 있고, M2M 애플리케이션 계층은 간략히 애플리케이션 계층으로 지칭될 수 있다. 마찬가지로, 각 도메인의 명칭 또한 달라질 수 있다. 예를 들어, oneM2M 시스템에서 네트워크 도메인은 인프라스트럭처 도메인(infrastructure domain)으로 지칭될 수 있고, 디바이스 및 게이트웨이 도메인은 필드 도메인(field domain)으로 지칭될 수 있다.
도 1에 예시된 바와 같이, M2M 시스템은 M2M 통신을 위해 M2M 애플리케이션 계층과 M2M SC(Service Capability) 계층을 포함하는 계층 구조로서 이해될 수 있다.
도 2는 M2M 시스템의 계층 구조(layered structure)를 예시한다.
도 2를 참조하면, M2M 시스템은 애플리케이션 계층(202), 공통 서비스 계층(204), 기저 네트워크 서비스 계층(underlying network services layer)(206)을 포함할 수 있다. 앞서 설명된 바와 같이, 애플리케이션 계층(202)은 M2M 애플리케이션 계층에 대응되고, 공통 서비스 계층(204)은 M2M SCL에 대응될 수 있다. 기저 네트워크 서비스 계층(206)은 코어 네트워크에 존재하는 장치 관리(device management), 위치 서비스(location service), 및 장치 트리거링(device triggering)과 같은 서비스들을 공통 서비스 계층(204)에 제공한다.
도 3은 M2M 시스템의 기능적 아키텍처(functional architecture)를 예시한다. 기능적인 측면에서 M2M 시스템 아키텍처는 애플리케이션 엔티티(application entity, AE)(302), 공통 서비스 엔티티(common service entity, CSE)(304), 기저(underlying) 네트워크 서비스 엔티티(network service entity, NSE)(306)를 포함할 수 있다. 각 엔티티들(302, 304, 306)은 공통 서비스 엔티티(304)가 지원하는 기준점(reference point)을 통해 통신할 수 있다. 기준점(reference point)은 각 엔티티들(302, 304, 306) 간의 통신 흐름(communication flow)를 지정하는 역할을 한다. 기준점은 Mcx로 표현될 수 있고 Mc는 “M2M communications”을 의미한다. 본 명세서에서 Mca 기준점, Mcc 기준점, Mcn 기준점은 각각 Mca, Mcc, Mcn으로 표기될 수 있다.
도 3을 참조하면, Mca 기준점(312)은 애플리케이션 엔티티(AE)(302)와 공통 서비스 엔티티(CSE)(304)의 통신 흐름을 지정한다. Mca 기준점(312)은 AE(302)가 CSE(304)에 의해 제공되는 서비스를 이용할 수 있게 하고 CSE(304)가 AE(302)와 통신할 수 있게 한다. Mca 기준점(312)은 M2M 애플리케이션 계층과 M2M 공통 서비스 계층(또는 엔티티) 간의 인터페이스를 지칭할 수 있다.
Mcc 기준점(314)은 서로 다른 공통 서비스 엔티티(CSE)(304)들 간의 통신 흐름을 지정한다. Mcc 기준점(314)은 CSE(304)가 필요한 기능들을 제공할 때 다른 CSE의 서비스를 이용할 수 있게 한다. Mcc 기준점(314)을 통해 제공되는 서비스는 CSE(304)가 지원하는 기능들에 의존적일 수 있다. Mcc 기준점(314)은 M2M 공통 서비스 계층들 간의 인터페이스를 지칭할 수 있다.
Mcn 기준점(316)은 CSE(304)와 기저 네트워크 서비스 엔티티(NSE)(306) 간의 통신 흐름을 지정한다. Mcn 기준점(316)은 CSE(304)가 요구된 기능들을 제공하기 위해 기저 NSE(306)가 제공하는 서비스를 이용할 수 있게 한다. Mcn 기준점(316)은 M2M 공통 서비스 계층과 M2M 기저 네트워크 계층 간의 인터페이스를 지칭할 수 있다.
또한, 도 3의 예에서, CSE(304)는 다양한 공통 서비스 기능(common service function, CSF)들을 제공할 수 있다. 예를 들어, CSE(304)는 애플리케이션 및 서비스 계층 관리(Application and Service Layer Management) 기능, 통신 관리 및 전달 처리(Communication Management and Delivery Handling) 기능, 데이터 관리 및 저장(Data Management and Repository) 기능, 장치 관리(Device Management) 기능, 그룹 관리(Group Management) 기능, 발견(Discovery) 기능, 위치(Location) 기능, 네트워크 서비스 노출/서비스 실행 및 트리거링(Network Service Exposure/ Service Execution and Triggering) 기능, 등록(Registration) 기능, 보안(Security) 기능, 서비스 과금 및 계산(Service Charging and Accounting) 기능, 서비스 세션 관리 기능(Service Session Management), 구독/통지(Subscription/Notification) 기능 중에서 적어도 하나를 포함할 수 있다. CSE(304)는 상기 공통 서비스 기능들의 인스턴스(instance)를 가리키며, M2M 애플리케이션들이 사용하고 공유할 수 있는 공통 서비스 기능들의 서브세트를 제공한다. 공통 서비스 기능들을 개략적으로 설명하면 다음과 같다.
- 애플리케이션 및 서비스 계층 관리(Application and Service Layer Management, ASM) : AE들과 CSE들의 관리 기능을 제공한다. 예를 들어, ASM 기능은 CSE들의 기능을 설정(configure)하고 문제점을 해결(troubleshoot)하고 업그레이드(upgrade)할 뿐만 아니라 AE들의 기능을 업그레이드할 수 있다.
- 통신 관리 및 전달 처리(Communication Management and Delivery Handling, CMDH): 다른 CSE들, AE들, NSE들과의 통신을 제공한다. 예를 들어, CMDH 기능은 CSE-CSE 통신(CSE-to-CSE communication)을 위한 연결(connection)을 언제 어떻게 사용할지를 결정하고 특정 요청들이 지연 전달될 수 있도록 제어할 수 있다.
- 데이터 관리 및 저장(Data Management and Repository, DMR): M2M 애플리케이션들이 데이터를 교환, 공유할 수 있게 한다. 예를 들어, DMR 기능은 대량의 데이터를 수집(collecting)/병합(aggregating)하고 데이터를 특정 포맷으로 변환(converting)하고 저장(storing)할 수 있다.
- 장치 관리(Device Management, DMG): M2M 게이트웨이 및 M2M 디바이스 뿐만 아니라 M2M 영역 네트워크에 존재하는 디바이스들에 대한 디바이스 기능을 관리한다. 예를 들어, DMG 기능은 애플리케이션 설치 및 설정, 펌웨어(Firmware) 업데이트, 로깅(Logging), 모니터링(Monitoring), 진단(Diagnostics), 네트워크 토폴로지(Topology) 관리 등을 수행할 수 있다.
- 발견(Discovery, DIS): 주어진 범위 및 조건 내에서 요청에 따라 정보 및 리소스(resource)와 같은 정보를 검색(searching)한다.
- 그룹 관리(Group Management, GMG): 예를 들어 리소스(resource), M2M 디바이스, 또는 M2M 게이트웨이를 묶어 그룹을 생성할 수 있는데 그룹 관련 요청을 핸들링(handling)한다.
- 위치(Location, LOC): M2M 애플리케이션이 M2M 디바이스 또는 M2M 게이트웨이의 위치 정보를 획득하는 역할을 수행한다.
- 네트워크 서비스 노출/서비스 실행 및 트리거링(Network Service Exposure/ Service Execution and Triggering, NSSE): 기저 네트워크의 통신을 가능하게 하고 기저 네트워크가 제공하는 서비스 또는 기능을 사용할 수 있게 한다.
- 등록(Registration, REG): M2M 애플리케이션 또는 다른 CSE가 특정 CSE에 등록을 처리하는 역할을 수행한다. 등록은 특정 CSE의 M2M 서비스 기능을 사용하기 위해 수행된다.
- 보안(Security, SEC): 보안 키와 같은 민감한 데이터 핸들링, 보안 연관 관계(Association) 설립, 인증(Authentication), 권한 부여(Authorization), ID(Identity) 보호 등의 역할을 수행한다.
- 서비스 과금 및 계산(Service Charging and Accounting, SCA): AE 또는 CSE에 과금 기능을 제공하는 역할을 수행한다.
- 서비스 세션 관리(Service Session Management, SSM): 단대단(end-to-end) 통신을 위한 서비스 계층의 M2M 세션을 관리하는 역할을 수행한다.
- 구독/통지(Subscription/Notification, SUB): 특정 리소스(resource)에 대한 변경을 구독(Subscription)하면 해당 리소스(resource)이 변경되면 이를 통지(notification)하는 역할을 수행한다.
도 4는 M2M 시스템의 구성을 예시한다. 본 명세서에서, 노드(node)는 하나 이상의 M2M 애플리케이션을 포함하는 엔티티 또는 하나의 CSE와 0개 이상의 M2M 애플리케이션을 포함하는 엔티티를 의미한다.
애플리케이션 전용 노드(Application Dedicated Node, ADN)는 적어도 하나의 애플리케이션 엔티티(AE)를 가지지만 공통 서비스 엔티티(CSE)를 가지지 않는 노드를 지칭할 수 있다. ADN은 Mca를 통해 하나의 중간 노드(Middle Node, MN) 또는 하나의 인프라스트럭처 노드(Infrastructure Node, IN)와 통신할 수 있다. ADN은 제한된 능력을 갖는 M2M 디바이스(M2M device having a constrained capability)로 지칭될 수 있는데, 제한된 능력을 갖는 M2M 디바이스는 공통 서비스 계층(common service layer) 또는 공통 서비스 엔티티(CSE)를 포함하지 않는 M2M 디바이스를 지칭할 수 있다. 제한된 능력을 갖는 M2M 디바이스는 간략히 제한적인 M2M 디바이스(constrained M2M device)라고 지칭될 수 있다.
애플리케이션 서비스 노드(Application Service Node, ASN)는 적어도 하나의 공통 서비스 엔티티(CSE)를 가지고 적어도 하나의 M2M 애플리케이션 엔티티(AE)를 가지는 노드를 지칭할 수 있다. ASN은 Mcc를 통해 하나의 중간 노드(Middle Node) 또는 하나의 인프라스트럭처 노드(Infrastructure Node)와 통신할 수 있다. ASN은 M2M 디바이스로 지칭될 수 있다.
중간 노드(Middle Node, MN)는 하나의 공통 서비스 엔티티(CSE)와 0개 이상의 M2M 애플리케이션 엔티티(AE)를 가지는 노드를 지칭할 수 있다. MN은 Mcc를 통해 하나의 인프라스트럭처 노드(IN) 또는 다른 중간 노드(MN)와 통신할 수 있으며, 혹은 Mcc를 통해 IN/MN/ASN과 통신할 수 있으며, 혹은 Mca를 통해 ADN과 통신할 수 있다. MN은 M2M 게이트웨이로 지칭될 수 있다.
인프라스트럭처 노드(Infrastructure Node, IN)는 하나의 공통 서비스 엔티티(CSE)를 가지고 0개 이상의 애플리케이션 엔티티(AE)를 가지는 노드를 지칭할 수 있다. IN은 Mcc를 통해 적어도 하나의 중간 노드(MN)와 통신할 수 있고, 및/또는 적어도 하나의 ASN과 통신할 수 있다. 혹은 IN은 Mca를 통해 하나 이상의 ADN과 통신할 수 있다. IN은 M2M 서버로 지칭될 수 있다.
도 4를 참조하면, 예 1은 ADN과 IN 간의 통신을 예시한다. ADN은 제한된 능력을 갖는 M2M 디바이스일 수 있다. 이 경우, ADN은 CSE 또는 공통 서비스 계층을 갖지 않으므로 Mca를 통해 IN의 CSE와 통신할 수 있다. 또한, 이 경우, ADN은 CSE 또는 공통 서비스 계층을 갖지 않으므로 AE 또는 애플리케이션 계층에서 생성된 데이터를 다른 엔티티에 저장/공유할 수 없다. 따라서, 예 1에서 ADN의 AE 또는 애플리케이션 계층에서 생성된 데이터는 IN의 CSE에 저장되어 공유될 수 있다.
예 2는 ADN과 MN 간의 통신을 예시한다. ADN도 제한된 능력을 갖는 M2M 디바이스일 수 있다. 따라서, ADN이 MN의 CSE과 통신한다는 점을 제외하고 예 1과 유사하게 동작할 수 있다. 즉, ADN은 Mca를 통해 MN의 CSE와 통신할 수 있다. 또한, ADN은 CSE 또는 공통 서비스 계층을 갖지 않으므로 AE 또는 애플리케이션 계층에서 생성된 데이터를 다른 엔티티에 저장/공유할 수 없다. 따라서, ADN의 AE 또는 애플리케이션 계층에서 생성된 데이터는 MN의 CSE에 저장되어 공유될 수 있다.
한편, 예 2에서 MN은 MN을 거쳐 IN과 통신할 수 있다. 이 경우 MN과 MN, 그리고 MN과 IN은 Mcc를 통해 통신할 수 있다. MN이 MN을 거치지 않고 직접 IN과 통신하는 것도 가능하다.
예 3은 ASN과 MN 간의 통신을 예시한다. 예 1 또는 예 2와 달리, ASN은 CSE 또는 공통 서비스 계층을 가지므로 ASN의 AE 또는 애플리케이션 계층에서 생성된 데이터를 자신의 CSE 또는 공통 서비스 계층에 저장할 수 있다. 또한, ASN의 AE는 ASN의 CSE를 통해 MN의 CSE와 통신할 수 있다.
예 4는 ASN과 MN 간의 통신을 예시한다. 예 3과 비교하여, ASN의 CSE는 MN을 거치지 않고 직접 IN의 CSE와 통신할 수 있다.
IN은 인프라스트럭처 도메인 또는 네트워크 도메인에 위치할 수 있고 하나의 CSE를 포함하고 0개 이상의 AE를 포함할 수 있다. IN들은 Mcc를 통해 서로 통신할 수 있다.
도 5는 M2M 시스템에서 사용되는 자원 또는 리소스(resource)를 예시한다.
M2M 시스템에서 애플리케이션 엔티티(AE), CSE, 데이터 등은 리소스(resource)로서 표현될 수 있다. M2M 시스템에서 리소스는 고유한 주소(예, URI(Universal Resource Identifier 또는 Uniform Resource Identifier))를 이용하여 고유하게 어드레싱 가능한 엔티티(uniquely addressable entity)를 지칭한다. M2M 시스템에서 리소스는 특정 데이터 구조로서 표현되며 각 리소스는 서로 논리적으로 연결될 수 있다. 리소스는 CSE 또는 공통 서비스 계층에 의해 관리되고 저장될 수 있다. 따라서, M2M 디바이스, M2M 게이트웨이, M2M 서버의 CSE 또는 공통 서비스 계층에서는 이러한 리소스를 가질 수 있다. 반면, M2M 시스템의 AE 또는 애플리케이션 계층에서는 이러한 리소스 구조를 가질 수 없다. 각 리소소는 자녀 리소스와 속성을 가진다. M2M 리소스에서 루트(Root) 리소스는 속성(attribute)과 자녀 리소스(child resource)를 가질 수 있다. 예를 들어, 리소스는 트리 구조로서 표현될 수 있다. 예를 들어, 루트 리소스의 타입은 <baseURI> 또는 <CSEBase>로 표시될 수 있다. 리소스의 타입은 “<”과 “>”에 의해 표시될 수 있다.
M2M 시스템에서는 다양한 리소스 타입이 정의되는데 M2M 애플리케이션들은 리소스 타입이 실체화(Instantiation)된 리소스를 기반으로 통신을 수행할 수 있다. 예를 들어, 애플리케이션을 등록하고 센서 값을 읽어 오는 등의 M2M 서비스를 수행하는 데 사용될 수 있다. 각각의 리소스는 해당 리소스 타입의 인스턴스가 생성될 때 고유한 주소 정보(예, URI)가 주어지며, 루트 리소스와 동일하게 속성 및 자녀 리소스를 가질 수 있으며 각 리소스들은 고유한 주소 정보를 이용하여 어드레싱될 수 있다. 특정 리소스 타입은 해당 리소스가 실체화(Instantiation)되었을 때 가질 수 있는 자식 리소스와 속성을 정의한다. 특정 리소스 실체화(Instantiation) 시 리소스는 해당 리소스의 리소스 타입에 정의된 속성과 자식 리소스를 가질 수 있다.
속성은 리소스 자체에 대한 정보를 저장하며 자녀 리소스를 가질 수 없다. 자녀 리소스는 자신의 속성과 자신의 자녀 리소스를 가질 수 있으며, 예를 들어 자녀 리소스에는 원격 CSE 리소스, 애플리케이션 엔티티 리소스, 접근 제어 리소스, 컨테이너 리소스, 그룹 리소스, 구독 리소스 등이 있다.
- 원격 CSE 리소스는 해당 CSE에 등록(연결)된 다른 CSE의 정보를 포함한다. 예를 들어, 원격 CSE 리소스의 타입은 <entity> 또는 <remoteCSE>으로 표시될 수 있다.
- 애플리케이션 엔티티 리소스: 루트 리소스의 애플리케이션 엔티티 리소스(예, <baseURI>/<application> 또는 <CSEBase>/<AE>) 또는 루트 리소스의 원격 CSE 리소스(예, <baseURI>/<entity> 또는 <CSEBase>/<remote CSE>) 하위에 존재하는 리소스이며, 루트 리소스의 애플리케이션 엔티티 리소스(예, <baseURI>/<application> 또는 <CSEBase>/<AE>)의 하위에 존재할 경우 해당 CSE에 등록(연결)된 애플리케이션 엔티티의 정보가 저장되며, 루트 리소스의 원격 CSE 리소스(예, <baseURI>/<entity> 또는 <CSEBase>/<remote CSE>) 하위에 존재할 경우 특정 원격 CSE에 등록된 애플리케이션 엔티티들의 정보를 저장한다. 예를 들어, 애플리케이션 엔티티 리소스의 타입은 <application> 또는 <AE>로 표시될 수 있다.
- 접근 제어 리소스 : 접근 권한과 관련된 정보를 저장하는 리소스이다. 본 리소스에 포함된 접근 권한 정보를 이용하여 권한 부여(authorization)가 이루어질 수 있다. 예를 들어, 접근 제어 리소스의 타입은 <accessRight> 또는 <accessControlPolicy>으로 표시될 수 있다.
- 컨테이너 리소스 : CSE 또는 AE 별로 생성되는 데이터를 저장한다. 예를 들어, 컨테이너 리소스의 타입은 <container>로 표시될 수 있다.
- 그룹 리소스 : 여러 리소스를 하나로 묶어 함께 처리할 수 있도록 하는 기능을 제공한다. 예를 들어, 그룹 리소스의 타입은 <group>으로 표시될 수 있다.
- 구독 리소스 : 리소스의 상태가 변경되는 것을 통지(Notification)를 통해 알려주는 기능을 수행한다. 예를 들어, 구독 리소스의 타입은 <subscription>으로 표시될 수 있다.
도 6은 특정 M2M 애플리케이션을 위한 리소스 타입을 예시한다. 앞서 설명된 바와 같이, 특정 M2M 애플리케이션을 위한 리소스는 M2M 게이트웨이의 CSE 또는 공통 서비스 계층의 리소스에서 애플리케이션 리소스(Application Resource)에 저장될 수 있다. 특정 M2M 애플리케이션을 위한 리소스는 전체 리소스와 유사하게 속성(attribute)과 자녀 리소스(child resource)를 가질 수 있다. 도 6의 예에서, 자녀 리소스는 타입(예, “<”, “>”으로 표시)으로 정의되어 있으며 실체화 시 실제 이름이 부여되고 저장된다.
도 7은 일반적인 M2M 시스템의 통신 흐름을 예시한다. 일반적으로 M2M 시스템의 동작은 데이터 교환을 기반으로 수행된다. 예를 들어, 특정 디바이스가 다른 디바이스의 동작을 멈추기 위해 해당 명령을 데이터 형태로 다른 장치에 전달할 수 있다. 디바이스 내에서 데이터를 저장하기 위해 특정 형태의 데이터 구조가 이용되는데 이를 자원(Resource, 리소스)이라고 지칭한다. 자원은 고유의 주소(예, URI)를 이용하여 액세스할 수 있다.
도 7을 참조하면, AE와 CSE 간의 연결에서 또는 CSE들 간의 연결에서 요청 및 응답 방식(Request and Response Scheme)이 사용된다. 발신자(originator)는 수신자(receiver)에 저장된 자원(resource)을 요청하기 위해 요청 메시지를 전송하고 그에 대한 응답으로 응답 메시지를 수신할 수 있다. 마찬가지로, 수신자는 발신자로부터 자원을 요청하는 메시지를 수신하고 그에 대한 응답으로 응답 메시지를 발신자로 전송할 수 있다. 본 명세서에서, 요청 메시지는 요청으로 약칭될 수 있고 응답 메시지는 응답으로 약칭될 수 있다. 발신자에서 수신자로 전송되는 요청 메시지는 다음과 같은 정보를 포함할 수 있다.
- op: 실행되는 동작(Operation)의 형태. 생성(Create)/회수(Retrieve)/갱신(Update)/삭제(Delete)/통지(Notify) 중 하나일 수 있다. 본 명세서에서 동작에 해당하는 정보는 명령(command)라고 지칭될 수 있다.
- to: 목적 자원의 URI(Uniform Resource Identifier)
- fr: 요청(Request)을 생성한 발신자(Originator)의 식별 정보(또는 ID)
- mi: 해당 요청(Request)에 대한 추가 정보(Meta information)
- cn: 전달되는 자원의 내용
- ec: 요청을 핸들링하는 데 이용되는 이벤트 카테고리(Event Category)를 지시한다. 이벤트 카테고리는 원격 호스팅된 리소스들을 액세스하는 요청들이 수신자(예, 수신자의 CMDH CSF)에서 어떻게 처리될지에 대해 영향을 줄 수 있다. 예를 들어, 이벤트 카테고리는 발신자 요청의 중요도를 나타내는 정보를 나타낼 수 있다. 요청 메시지의 ec는 예를 들어 ‘immediate’, ‘bestEffort’, ‘latest’ 등의 값으로 설정될 수 있다. ec가 ‘immediate’로 설정되는 경우 이 카테고리의 요청들은 중요한 요청을 의미하기 때문에 가능한 빨리 전송되며 추가적인 CMDH 처리가 수행되지 않는다. 예를 들어, 기저 네트워크를 통한 통신이 가능한 경우 이 요청들은 CMDH 버퍼에 저장되지 않고 전송될 수 있다. ec가 ‘bestEffort’로 설정되는 경우 이 카테고리의 요청들은 CSE의 재량으로 임의의 시간 동안 CMDH 버퍼에 저장될 수 있고 최선의 노력으로(on a best effort basis) Mcc를 통해 전달될 수 있다. ec가 ‘latest’로 설정되는 경우 이 카테고리의 요청들은 정상적인 CMDH 처리를 거치며 요청들이 계류중인 경우 최대 버퍼 크기 내에서 오래된 요청이 최근 요청에 의해 교체된다.
해당 요청(Request)이 성공적으로 수행된 경우 응답(Response) 메시지는 다음과 같은 정보를 포함할 수 있다. 응답 메시지는 아래 정보 중에서 적어도 하나를 포함할 수 있으며, 또는 결과값(rs)만을 포함할 수도 있다.
- to: 요청(Request)을 생성한 발신자(Originator)의 식별 정보(또는 ID)
- fr: 요청(Request)을 수신한 수신자(receiver)의 식별 정보(또는 ID)
- mi: 요청(Request)에 대한 추가 정보(Meta information)
- rs: 요청(Request)에 대한 결과(예를 들어, Okay, Okay and Done, Okay and in progress)
- ai: 추가적인 정보
- cn: 전달되는 자원의 내용
해당 요청(Request)이 실패한 경우 응답(Response) 메시지는 다음과 같은 정보를 포함할 수 있다.
- to: 요청(Request)을 생성한 발신자(Originator)의 ID
- fr: 요청을 수신한 수신자(receiver)의 ID
- mi: 요청(Request)에 대한 추가 정보(Meta information)
- rs: 요청에 대한 결과 (예를 들어, Not Okay)
- ai: 추가적인 정보
본 명세서에서, 발신자는 발신자 디바이스 또는 발신자 엔티티(또는 그 안의 CSE 또는 AE)을 나타내고, 수신자는 수신자 디바이스 또는 수신자 엔티티(또는 그 안의 CSE 또는 AE)를 나타낼 수 있다. 또한, 발신자 디바이스로부터 전송된 메시지를 중간에서 중계하여 수신자 디바이스에게 전달하는 엔티티를 중계 디바이스 또는 중계 엔티티(또는 그 안에 CSE)라고 지칭할 수 있다. 자원을 가지고 있는 디바이스(또는 그 안의 CSE)를 호스팅 디바이스 또는 호스팅 엔티티(또는 호스팅 CSE)라고 지칭할 수 있다.
도 8은 M2M 시스템에서 서로 다른 엔티티들이 상호 연동하는 예를 예시한다.
도 8을 참조하면, IN(Infrastructure Node)에 등록된 AE(application2)가 M2M 디바이스(M2M Device)와 연동하는 예가 도시되어 있다. 예를 들어, M2M 디바이스는 물리적인 장치인 센서를 포함할 수 있으며 IN에 등록된 AE는 M2M 디바이스의 센서 값을 읽어올 수 있다.
M2M 디바이스 상에 존재하는 AE(application1)는 센서에서 값을 읽어 읽은 값을 자신이 등록한 CSE(dcse)에 자원 형태(예, <container> 자원)로 저장한다. 이를 위해, M2M 디바이스 상에 존재하는 AE(application1)는 M2M 디바이스에 존재하는 CSE에 먼저 등록해야 한다. 도 8에 예시된 바와 같이, 등록이 완료되면, dcse/applications/application1 자원의 형태로 등록된 M2M 애플리케이션 관련 정보가 저장된다. 예를 들어, M2M 디바이스의 센서 값이 AE(application1)에 의해 dcse/applications/application1 리소스 하위의 Container 자원에 저장되면, IN(Infrastructure Node)에 등록된 AE(application2)가 해당 값에 접근할 수 있다. 또한, AE(application2)가 M2M 디바이스에 접근하기 위해서는 IN(Infrastructure Node)의 CSE(ncse)에 등록되어야 한다. 이는 AE(application1)가 CSE(dcse)에 등록하는 방법과 같이 ncse/applications/application2 자원에 AE(application2)에 대한 정보가 저장된다. 또한, AE(application1)는 AE(application2)와 직접 통신하는 것이 아니라 중간의 CSE(ncse)와 CSE(dcse)를 통해 통신할 수 있다. 이를 위해, CSE(ncse)와 CSE(dcse)는 상호 등록되어야 한다. CSE(dcse)가 CSE(ncse)에 등록하면, ncse/cses/dcse 자원 하위에 dcse 관련 정보(예, Link)가 저장된다. 이를 통해 AE(application2)는 AE(application1)의 정보에 접근할 수 있는 경로를 얻게 되어 해당 경로를 통해 센서의 값을 읽을 수 있다.
도 9는 구독 자원과 관련된 절차를 예시한다.
M2M 시스템(예, oneM2M)에서는 자원의 변화에 따라 해당 자원의 변화에 관심이 있는 엔티티(Entity)가 해당 변화에 대한 통지(notification)를 구독(subscription)할 수 있다. 이 경우, 통지를 구독하기 위해서는 구독을 위한 자원이 설정되어야 한다. 구독을 위한 자원은 구독 자원 또는 <subscription> 자원으로 지칭될 수 있다. 구독 자원이 생성/설정된 경우, 구독 자원이 설정된 디바이스(또는 엔티티)는 구독 자원에 설정된 조건을 만족하는 수정/변화가 구독 대상 자원(subscribed-to resource 또는 subscribed resource)에서 발생하는 경우 구독 자원에 설정된 주소로 통지를 전송할 수 있다. 구독 자원이 설정되거나 및/또는 구독 대상 자원을 포함하는 디바이스(또는 엔티티)를 호스팅 디바이스(또는 호스팅 엔티티)라고 지칭한다. 예를 들어, M2M 게이트웨이의 CSE에 구독 대상 자원이 존재할 수 있으며 이 경우 M2M 게이트웨이를 호스팅 디바이스라고 지칭하고 M2M 게이트웨이의 CSE를 호스팅 CSE라고 지칭할 수 있다.
구독 자원을 이용하여 자원 지향적인 방식(resource-oriented manner)으로 구독 절차를 수행할 수 있다. 예를 들어, 특정 구독 대상 자원에 대하여 구독하기 위해 구독 자원을 생성할 수 있고, 구독 자원을 수정함으로써 구독을 위한 조건을 변경할 수 있으며, 구독을 더 이상 원치 않을 경우에는 구독 자원을 삭제할 수 있다.
구독 자원(subscription resource)은 구독 대상 자원(subscribed-to resource)에 대한 정보를 포함한다. 구독 대상 자원과 구독 자원 간의 관계는 부모-자식 관계로서 표현될 수 있다. 예를 들어, 구독 대상 자원을 포함하는 <container> 자원은 자식 자원으로서 <subscription> 자원을 가질 수 있다. 부모 구독 대상 자원이 삭제될 때 <subscription> 자원은 삭제될 수 있다.
구독(subscription) 자원이 자식 자원인 경우에는 구독 자원의 설정(속성 설정)에 따라 부모 자원의 상태 변화를 지시하는 통지(notification)가 구독 자원 내의 주소 정보(예, notificationURI 또는 contact 속성)에 명시된 엔티티에게 전달될 수 있다. 발신자가 구독가능한 자원에 대한 RETRIEVE(또는 READ) 권한(permission)을 가지는 경우 발신자는 구독 자원을 생성할 수 있다. 구독 자원의 발신자는 자원 구독자가 된다. 구독 대상 자원에 대한 수정이 있는 경우 그 수정을 특정 속성(예, notificationCriteria attribute)과 비교하여 통지가 자원 구독자로 전송될 지를 결정한다.
구독 자원(예, <subscription> 자원)은 다양한 속성과 자식 자원을 가질 수 있다. 예를 들어, 구독 자원(예, <subscription> 자원)은 표 1의 속성들을 가질 수 있다. 표 1에서 R/W는 해당 속성의 읽기(read)/쓰기(write) 허용여부(permission)을 나타내며, READ/WRITE(RW), READ ONLY(RO), WRITE ONLY(WO) 중 하나일 수 있다. 표 1은 오로지 예시일 뿐이며 구독 자원의 속성은 표 1과 다르게 구성될 수 있다.
표 1
Figure PCTKR2014009041-appb-T000001
표 1의 예에서, 필터링 속성(예, notificationCriteria)은 구독 대상 자원의 수정/변화에 대한 조건들의 리스트이며, 각 조건들은 논리적 AND 관계에 있을 수 있다. 예를 들어, 필터링 속성(예, notificationCriteria)이 2개의 조건을 포함하는 경우, 구독 대상 자원의 수정/변화가 2개의 조건을 모두 만족하는 경우 통지가 전송될 수 있다. 구독 자원에 필터링 속성을 설정함으로써 통지 메시지의 양을 조절할 수 있으며, 설정한 필터링 속성을 만족 시에 통지 대상 엔티티(notification target entity)에게 통지가 전송되도록 하여 통지 메시지가 넘쳐나는 문제를 방지할 수 있다. 표 2는 필터링 속성에 포함될 수 있는 조건들을 예시한다.
표 2
Figure PCTKR2014009041-appb-T000002
또한, 구독 자원(예, <subscription> 자원)은 자식 자원으로서 스케줄링 정보를 포함하는 스케줄링 자원(예, <schedule>) 자원을 가질 수 있다. 스케줄링 자원이 특정 자원의 자식 자원으로서 설정되는 경우 스케줄링 자원은 그 부모 자원의 맥락에서 스케줄링 정보를 나타낸다. 스케줄링 자원(예, <schedule>)은 해당 노드의 도달가능성 스케줄(reachability schedule) 정보를 정의한다. 스케줄링 자원이 구독 자원의 자식 자원으로 실체화되는 경우 통지 스케줄링 자원(예, notificationSchedule 자원)이라고 지칭될 수 있다. 본 명세서에서 스케줄링 자원 또는 통지 스케줄링 자원(예, <schedule> 또는 notificationSchedule 자원)은 간략히 스케줄링 자원이라고 지칭될 수 있다. 예를 들어, 스케줄링 자원이 구독 자원의 자식 자원인 경우 스케줄링 자원에 설정된 스케줄링 정보는 구독 자원의 통지를 위한 스케줄링 정보를 나타낼 수 있다. 본 명세서에서 스케줄링 정보는 도달가능성 스케줄(reachability schedule) 정보라고 지칭될 수 있다.
본 명세서에서 도달가능하다는 것(reachable)은 노드들 간에 메시지가 송수신될 수 있는 상태를 지칭할 수 있고, 도달가능하지 않다는 것(unreachable 또는 non-reachable)은 노드들 간에 메시지가 송수신될 수 없는 상태를 지칭할 수 있다. 또한, 특정 노드가 도달가능한 상태에 있는 경우 특정 노드는 도달가능 모드에 있다고 지칭될 수 있다. 또한, 특정 노드가 도달가능하지 않은 상태에 있는 경우 특정 노드는 도달불가 모드에 있다고 지칭될 수 있다. 따라서, 도달가능성 스케줄 정보는 노드들 간에 메시지 송수신이 발생할 수 있는 시간을 지시할 수 있다. 또한, 노드들 간의 연결 상태는 도달가능성으로 지칭될 수 있다.
스케줄링 자원(예, <schedule>)은 다양한 속성들을 가질 수 있다. 예를 들어, 스케줄링 자원은 resource Type, resourceID, parentID, expirationTime, creationTime, lastModifiedTime 등의 속성을 포함할 수 있다(표 3 참조). 표 3에서 RW/RO/WO는 해당 속성의 읽기(read)/쓰기(write) 허용여부(permission)을 나타내며, READ/WRITE(RW), READ ONLY(RO), WRITE ONLY(WO) 중 하나일 수 있다. 또한, 표 3에서 발생횟수(multiplicity)는 해당 속성이 <schedule> 자원에서 발생 가능한 횟수를 나타낸다. 표 3은 오로지 예시일 뿐이며 스케줄링 자원의 속성은 표 3과 다르게 구성될 수 있다.
표 3
Figure PCTKR2014009041-appb-T000003
또한, 예를 들어, 스케줄링 자원은 스케줄링 시간 정보를 위한 속성(예, scheduleElement)을 포함할 수 있다. 스케줄링 시간 정보를 위한 속성은 초, 분, 시, 일, 월, 년 등에 의해 정의되는 시간을 표현할 수 있으며, 시간의 반복을 표현할 수 있으며, 와일드카드(wildcard, 예 ‘*’)로서 표현될 수 있다. 스케줄링 시간 정보를 위한 속성은 특정 노드가 도달가능 모드에 있는 시간 구간을 나타내거나 특정 노드가 도달불가 모드에 있는 시간 구간을 나타낼 수 있다. 예를 들어, 스케줄링 시간 정보를 위한 속성은 특정 노드가 도달가능 모드에 있는 시간 구간을 나타내는 경우, 스케줄링 시간 정보를 위한 속성에 명시된 시간 구간 동안 해당 노드는 메시지를 송수신할 수 있으며 다른 노드들과 연결 상태에 있을 수 있다. 다른 예로, 스케줄링 시간 정보를 위한 속성은 특정 노드가 도달불가 모드에 있는 시간 구간을 나타내는 경우, 스케줄링 시간 정보를 위한 속성에 명시된 시간 구간 동안 해당 노드는 메시지를 송수신할 수 없으며 다른 노드들과 연결이 없는 상태에 있을 수 있다.
도 9를 참조하면, 디바이스 1(910)은 디바이스 2(920)의 특정 자원을 구독하기 위해 도 9에 예시된 절차를 수행할 수 있다. 디바이스 1(910)은 구독 대상 자원의 변화에 따른 통지를 받는 대상일 수도 있고 아닐 수도 있다. 도 9의 예에서, 특정 자원은 구독 대상 자원에 해당하며, 디바이스 2(920)는 구독 대상 자원을 포함하고 있으므로 호스팅 디바이스(또는 엔티티)에 해당할 수 있다.
S902 단계에서, 디바이스 1(910)은 특정 자원을 구독하기 위해 구독 자원에 대한 요청을 디바이스 2(920)로 전송할 수 있다. 예를 들어, 구독 자원에 대한 요청은 구독 자원의 생성 요청, 회수 요청, 삭제 요청, 갱신 요청 중에서 어느 하나일 수 있다. 각 요청은 도 7을 참조하여 설명된 요청-응답 방식에 따른 요청 메시지의 형태를 가질 수 있다. 예를 들어, S902의 요청이 생성 요청인 경우, 구독 자원에 대한 요청은 C(Create)를 가지는 op 정보, 구독 자원의 속성 정보(예, notificationURI, filterCriteria, expirationTime 등)를 포함하는 cn 정보, 디바이스 1(910)의 식별 정보를 가지는 fr 정보, 및/또는 디바이스 2(920)의 식별 정보를 가지는 to 정보를 포함할 수 있다. 다른 예로, S902의 요청이 삭제 또는 갱신 요청인 경우, 구독 자원에 대한 요청은 도 7을 참조하여 설명된 정보들의 전부 또는 일부를 포함할 수 있다.
S904 단계에서, 디바이스 2(920)는 구독 자원에 대한 요청을 처리할 수 있는지 검사(validate)하여 처리할 수 있는 경우 해당 요청을 처리한다. 예를 들어, 디바이스 2(920)가 생성 요청을 수신하는 경우, to 정보에 지정된 구독 대상 자원이 구독 가능하지 여부, 요청 발신자(예, 910)이 구독 대상 자원에 대해 RETRIEVE 권한(permission)을 가지는 여부, 구독 자원의 주소 정보(예, notificationURI)가 요청 발신자(예, 910)를 가리키지 않는 경우 요청 발신자(예, 910)가 구독 자원의 주소 정보(예, notificationURI)에 지정된 엔티티 또는 디바이스로 통지를 보낼 액세스 권한(access rights)를 가지는 여부, 호스팅 디바이스 또는 엔티티(예, 920)가 구독 자원의 주소 정보(예, notificationURI)에 지정된 엔티티 또는 디바이스로 통지를 보낼 액세스 권한(access rights)를 가지는 여부를 검사(validate)한다. 이들 모두를 만족하는 경우, 디바이스 2(920)는 to 정보에 지정된 구독 대상 자원 아래에 구독 자원을 생성할 수 있다.
다른 예로, 디바이스 2(920)가 삭제 요청을 수신하는 경우, 디바이스 2(920)는 요청 발신자(예, 910)가 DELETE 권한(permission)을 가지는지 여부를 검사(validate)하며, 이를 만족하는 경우 구독 자원을 삭제한다.
S906 단계에서, 디바이스 2(920)는 구독 자원에 대한 요청을 처리한 다음 응답 메시지를 디바이스 1(910)로 전송할 수 있다. S906의 응답 메시지는 도 7을 참조하여 설명된 응답 메시지와 동일/유사한 형태를 가질 수 있다. 또한, 회수 요청의 경우 응답 메시지는 반환될 정보를 포함할 수 있다.
도 10은 통지를 위한 절차를 예시한다. 통지를 위한 절차에서 발신자는 구독 자원을 호스팅하고 있는 디바이스 또는 엔티티(예, 920)일 수 있다. 또한, 수신자는 구독 자원에 설정된 주소 정보(예, notificationURI)가 가리키는 디바이스(또는 엔티티)일 수 있다. 통지를 위한 절차를 위해 소정의 정책 정보가 설정될 수 있으며, 이러한 정책 정보를 만족할 때 발신자가 통지 메시지(예, NOTIFY)를 전송하도록 설정될 수 있다.
통지 메시지(예, NOTIFY)는 구독 자원에 의해 트리거링되는 메시지이다. 통지 메시지는 구독 자원을 자식 자원으로서 포함하는 구독 대상 자원의 변화가 구독 자원에 설정된 필터링 속성(예, notificationCriteria)을 만족하는 경우 구독 자원에 설정된 주소 정보(예, notificationURI)가 가리키는 수신자로 전송될 수 있다. 통지 메시지의 수신자는 구독 자원의 설정에 따라 구독 자원을 생성/설정한 디바이스 또는 엔티티와 동일할 수도 있고 서로 다를 수 있다. 예를 들어, 디바이스 1(910)은 디바이스 3(930)과 동일한 엔티티일 수도 있고 서로 다른 엔티티일 수 있다. 통지 메시지는 다음과 같은 정보를 포함할 수 있다.
- fr : 발신자(예, 920)의 식별정보 또는 ID
- to : 구독 자원에 설정된 주소 정보(예, notificationURI)
- cn : 구독 대상 자원의 수정 내용(modified content)을 나타내는 데이터 및/또는 이 통지 메시지를 생성한 구독 참조(subscription reference) 정보(예, 해당 구독 자원의 URI) 및/또는 기타 부가 정보
도 10을 참조하면, S1002 단계에서, 발신자(920)는 구독 대상 자원의 변화를 검출/감지할 수 있다. 구독 대상 자원은 구독 자원의 부모 자원이며, 구독 대상 자원 아래에서 구독 자원과 동일한 레벨에 있는 자원 또는 속성이 수정/변화되는 경우 발신자(920)(예를 들어, SUB CSF 또는 CSE 도 3 참조)는 구독 대상 자원의 변화로서 인지할 수 있다. 구독 대상 자원의 변화가 검출/감지되는 경우 이벤트가 생성될 수 있다.
구독 대상 자원의 변화가 검출되는 경우, S1004 단계에서, 발신자(920)는 해당 변화가 구독 자원에 설정된 특정 속성(예, notificationCriteria)과 매칭되는지 여부를 확인한다. 특정 속성은 예를 들어 표 2에 예시된 속성들 중 적어도 하나를 포함할 수 있다. 구독 대상 자원의 변화가 필터링 속성에 포함된 조건들을 모두 만족하지 않는 경우 발신자(920)는 해당 변화를 무시할 수 있다.
만일 구독 대상 자원의 변화가 필터링 속성에 포함된 조건들을 모두 만족하는 경우, S1006 단계에서, 발신자(920)는 구독 자원에 설정된 주소 정보(예, notificationURI)가 가리키는 엔티티(930)로 통지 메시지를 전송할 수 있다. S1006의 통지 메시지는 예를 들어 발신자(920)의 식별정보, 구독 대상 자원의 변경 내용을 나타내는 데이터, 및/또는 통지 메시지를 생성한 구독 참조 정보를 포함할 수 있다. 만일 구독 대상 자원의 변화가 필터링 속성에 포함된 조건들 중 어느 하나라도 만족하지 않는 경우, 발신자(920)는 생성된 통지 메시지를 전송하지 않을 수 있다.
도 11은 연결 상태가 보장되지 않는 환경에서 구독 및 통지 과정을 예시한다. 도 11의 예에서, 2개의 엔티티(예, 엔티티1, 엔티티2)로 구성된 상황에서 구독(subscription) 및 통지(notification) 과정이 발생하는 것을 가정한다.
도 9와 도 10을 참조하여 설명한 바와 같이, 두 엔티티들 사이의 연결 상태가 보장된다면 구독 서비스는 다음과 같이 수행될 수 있다.
1. 엔티티2는 엔티티1의 특정 자원(예, “자원 n”)에 대하여 구독 과정을 실시한다. 이 과정을 통해 엔티티2는 엔티티1의 특정 자원(예, “자원 n”)에 대한 구독 자원을 설정할 수 있다.
2. 엔티티1은 구독 자원이 설정된 특정 자원(예, “자원 n”)에 대하여 모니터링을 실시하고, 모니터링 되고 있는 자원에 변화가 발생되면 엔티티1은 자원 변화를 지시하는 통지(notification) 메시지를 엔티티2로 전송할 수 있다.
앞서 설명된 바와 같이, 통지 메시지는 구독 과정에서 설정된 주소(예, Contact attribute in ETSI M2M, notificationURI attribute in oneM2M)로 전송된다. 본 예에서는 설명의 편의성을 위하여 구독 과정의 구독자(subscriber)와 통지 과정의 수신자(Receiver)가 동일한 엔티티 또는 디바이스라고 가정한다.
도 11을 참조하면, 구독 과정이 성공적으로 수행되었음에도 불구하고 네트워크 장애, 장치 고장 및 도달가능성 스케줄(reachability schedule) 등에 의하여 엔티티들 사이에는 연결 상태가 보장되지 못하는 경우가 발생할 수 있다. 상기와 같은 환경에서 발생된 통지 메시지들은 발신자(Originator)(예, 엔티티1)에서 수신자(Receiver)(예, 엔티티2)로 전송되지 못한다. 이에 종래 기술에서는 연결 상태가 보장되지 않는 경우에 발생된 통지 메시지들을 처리하기 위하여, 그림 12와 같이 발생된 통지 메시지들을 발신자(Originator)에 임시적으로 저장한 후 연결이 회복되면 수신자(Receiver)로 전송될 수 있다.
도 12는 연결이 회복된 후 메시지들을 수신자로 전송하는 방법을 예시한다.
일 예로, 도 12(a)를 참조하면, 연결 상태가 보장되지 않는 상태에서 통지 1 내지 통지 n이 발생한 후 다시 연결 상태가 되면 발신자는 발생된 통지 1 내지 통지 n의 통지 묶음(notification aggregation)을 한 번에 수신자로 전송할 수 있다.
다른 예로, 도 12(b)를 참조하면, 연결 상태가 보장되지 않는 상태에서 통지 1 내지 통지 n이 발생한 후 다시 연결 상태가 되면 발신자는 발생된 통지 1 내지 통지 n를 하나씩 차례로 수신자에게 전송할 수 있다.
도 12에 예시된 방법 대로 연결이 회복된 후 메시지를 전송할 경우 발생할 수 있는 문제점을 살펴보면 다음과 같다. 먼저, 연결이 회복된 후 전송되는 통지 메시지들이 수신자 측면에서 필요하지 않을 수 있다. 예를 들어, 방안의 온도에 대하여 특정 사용자에게 서비스하는 환경에서 특정 시간(예, 오후 1시부터 오후 3시)에 엔티티들 간의 연결 상태가 끊어졌고 이 후 연결이 복구되었다. 이 예에서, 연결이 회복된 시점에서 사용자가 원하는 데이터는 3시 이후의 최신 데이터일 수도 있고, 또는 최근 30분 동안의 데이터일 수도 있다. 도 12에 예시된 방법을 사용할 경우, 사용자는 연결 상태가 보장되지 않는 시간 동안 발생된 모든 데이터를 전달 받아야만 한다. 이러한 방식은 발신자뿐만 아니라 수신자 측면에서 불필요한 메시지들을 송수신하게 됨으로써 데이터 전송 효율을 저하시키고 나아가 전체 시스템의 성능을 저하시킬 수 있다.
또한, 연결 상태가 보장되지 않는 환경에서 발생된 통지 메시지들을 선택적으로 처리할 수 없다. 예를 들어, 사용자가 방안의 온도 상태뿐만 아니라 특정 값(예, 30도) 이상일 경우에는 긴급메시지를 설정하였다고 가정한다. 도 12에 예시된 방법을 사용할 경우, 모든 통지 메시지에 대한 중요도(priority)가 동일하게 설정되기 때문에 연결 상태가 끊어진 동안 발생된 메시지들 가운데 중요한 메시지가 있더라도 이를 우선적으로 처리할 수 있는 방법이 없다.
이에 본 발명에서는 디바이스들 간에 연결 상태가 없는 시간 동안 발생된 통지 메시지를 선택적으로 처리하기 위한 속성(attribute)들 및 전송 알고리즘에 대하여 제안한다. 본 발명에 따른 예들은 M2M 환경을 중심으로 기술되지만, 클라이언트-서버(또는, 발신자-수신자) 구조를 가지는 다른 시스템에도 동일/유사하게 적용될 수 있다.
본 명세서에서, 구독 과정에서 구독자(subscriber)는 구독을 요청하는 엔티티를 지칭하고 호스팅 엔티티(hosting entity)는 모니터링 되는 자원(또는 구독 대상 자원)을 가진 엔티티를 지칭할 수 있다. 또한, 통지 과정에서 발신자는 통지 메시지를 전송하는 엔티티를 지칭하고 수신자는 통지 메시지를 최종적으로 전달받는 엔티티를 지칭할 수 있다. 구독 과정에서 호스팅 엔티티와 통지 과정에서 발신자는 동일한 엔티티일 수 있다.
본 명세서에서 연결 상태가 보장되지 못하는 경우는 발신자가 발생된 통지 메시지를 수신자로 전송하지 못하는 상태를 포함하며, 연결이 없는(connectionless) 상태로 지칭될 수 있다. 연결 상태를 보장하지 못하는 경우는 네트워크 장애, 장치 고장 및 도달가능성 스케줄(reachability schedule) 등과 같이 다양한 이유로 발생될 수 있다. 한편, 연결 상태가 보장되는 경우는 발신자가 수신자에게 발생된 통지 메시지를 정상적으로 전송할 수 있는 상태를 의미하며, 연결이 있는(connection) 상태 또는 연결된(connected) 상태로 지칭될 수 있다. 또한, 본 명세서에서 연결 상태는 도달가능성(reachability)로 지칭될 수 있다.
먼저, 본 발명에 따른 구독 자원의 속성들을 제안한다.
통지 동작(notification action)을 위한 속성 정보
연결 상태가 보장되는 않는 경우 발신자의 통지 정책을 지시하는 속성 정보를 제안한다. 발신자의 통지 정책을 지시하는 속성 정보는 제한적이지 않은 예로서 pendingNotification으로 지칭될 수 있다. 발신자의 통지 정책을 지시하는 속성 정보는 구독 자원의 일 속성으로 설정될 수 있다. 따라서, 발신자의 통지 정책을 지시하는 속성 정보는 표 1에 예시된 속성 정보들과 함께 또는 별도로 구독/통지 과정에 이용될 수 있다. 설명의 편의를 위해, 본 명세서에서 발신자의 통지 정책을 지시하는 속성 정보는 통지 정책 정보라고 지칭될 수 있고 제1 속성 정보라고 지칭될 수 있다.
통지 정책 정보(예, pendingNotification 속성)는 도달불가 시간(unreachable period) 동안 통지 메시지에 대해 발신자가 취해야할 동작을 지시한다. 예를 들어, 도달불가 시간은 스케줄링 자원 또는 도달가능성 스케줄 자원이 지시하는 스케줄링 정보에 따라 결정될 수 있다(도 9 관련 설명 참조). 통지 정책 정보(예, pendingNotification 속성)가 구독 자원에 설정된 경우, 도달불가 시간(unreachable period) 동안 발생되어 계류중인 통지(들)은 통지 정책 정보에 따라 처리될 수 있다. 표 4는 본 발명에 따른 통지 정책 정보(예, pendingNotification 속성)를 예시한다.
표 4
Figure PCTKR2014009041-appb-T000004
표 4에서 RW/RO/WO는 해당 속성의 읽기(read)/쓰기(write) 허용여부(permission)을 나타내며, READ/WRITE(RW), READ ONLY(RO), WRITE ONLY(WO) 중 하나일 수 있다. 또한, 표 4에서 발생횟수(multiplicity)는 해당 속성이 <subscription> 자원에서 발생가능한 횟수를 나타낸다. 표 4의 예에서, 통지 정책 정보(예, pendingNotification 속성)의 발생횟수(multiplicity)가 0 또는 1이므로 통지 정책 정보(예, pendingNotification 속성)는 구독 자원에 선택적으로(optional) 포함될 수 있다. 또한, 읽기/쓰기가 모두 허용될 수 있다.
표 4에 예시된 바와 같이, 통지 정책 정보(예, pendingNotification 속성)는 4가지 값을 가질 수 있다. 통지 정책 정보(예, pendingNotification 속성)에 설정된 값에 따라 발신자는 연결 상태가 없는 경우에 발생되는 통지 메시지들을 다음과 같이 처리하게 된다. 별도의 설정이 없는 경우, 예를 들어 예시된 4개 값 중에서 sendNone이 디폴트 값으로 설정될 수 있다. 본 명세서에서 sendNone은 제1 값, sendLatest는 제2 값, sendAllPending은 제3 값, 그리고 sendManual은 제4 값으로 지칭될 수 있다.
(1) sendNone으로 설정된 경우
발신자는 연결 상태가 보장되지 않는 시간 동안 발생된 모든 통지 메시지들을 저장하지 않는다. 이 경우, 연결 상태가 보장되지 않는 시간 동안 발생된 모든 통지 메시지들은 (전송되지 않고) 폐기(discard)될 수 있다. 발신자는 도달가능성(reachability)을 회복한 경우 저장된 통지 메시지가 없으므로 연결 상태가 보장되지 않는 시간 동안 발생된 통지 메시지를 수신자에게 전송할 필요가 없다. 본 설정은 잔류 통지 메시지(pending notification)가 필요하지 않는 경우에 사용될 수 있다. 예를 들어, 현재 방안의 온도를 모니터링 하는 응용서비스에 적용될 수 있다.
도 13은 통지 정책 정보(예, pendingNotification 속성)가 sendNone으로 설정되는 경우 통지 방법을 예시한다.
도 13을 참조하면, 연결 상태가 보장되지 않는 상태에서 구독 자원의 변화에 따라 통지 1 내지 통지 n이 발생할 수 있는데 발신자와 수신자 간에 연결 상태가 없는 경우 통지 메시지(notification)는 발신자에서 수신자로 전송될 수 없다. 이 경우, 발생된 통지 메시지들은 통지 정책 정보(예, pendingNotification 속성)에 따라 처리될 수 있다. 본 예에서, 통지 정책 정보(예, pendingNotification 속성)가 sendNone으로 설정되어 있으므로 연결 상태가 보장되지 않는 상태에서 발생된 통지 메시지들은 모두 무시되고 저장되지 않는다. 따라서, 연결 상태를 회복한 후에도 수신자에게로 전송되지 않는다. 하지만, 연결 상태에서 통지 메시지(예, 통지 n+1)가 발생하는 경우 수신자에게로 전송될 수 있다.
(2) sendLatest로 설정된 경우
발신자는 연결 상태가 보장되지 않는 시간 동안 발생된 통지 메시지들 가운데 가장 최근에 발생한 메시지만 저장한다. 이 경우, 기존에 저장되어 있는 통지 메시지는 삭제된다. 즉, 발신자는 새로운 통지 메시지(notification)을 저장하고 나머지 통지 메시지들을 폐기할 수 있다. 발신자는 도달가능성(reachability)을 회복한 경우 가장 최근에 저장된 통지 메시지를 수신자에게 전송할 수 있다. 본 설정은 잔류 통지 메시지들 가운데 가장 최근의 발생한 통지 메시지가 필요한 경우에 사용될 수 있다. 예를 들어, 장치 업데이트와 관련된 보고를 받는 응용서비스에 적용될 수 있다. 또한, 통지 정책 정보(예, pendingNotification 속성)가 sendLatest로 설정된 경우 통지 메시지의 ec 값은 ‘latest’로 설정될 수 있다(도 7 관련 설명 참조).
도 14는 통지 정책 정보(예, pendingNotification 속성)가 sendLatest로 설정되는 경우 통지 방법을 예시한다.
도 14를 참조하면, 연결 상태가 보장되지 않는 상태에서 구독 자원의 변화에 따라 통지 1 내지 통지 n이 발생할 수 있으며 발신자와 수신자 간에 연결 상태가 보장되지 않는 경우 통지 메시지(notification)는 발신자에서 수신자로 전송될 수 없다. 이 경우, 발생된 통지 메시지들은 통지 정책 정보(예, pendingNotification 속성)에 따라 처리될 수 있다. 본 예에서, 통지 정책 정보(예, pendingNotification 속성)가 sendLatest로 설정되어 있으므로 연결 상태가 보장되지 않는 상태에서 발생된 메시지들 중에서 가장 최근에 발생된 메시지(예, 통지 n)가 저장될 수 있다. 또한, 연결 상태가 보장되지 않는 시간 구간 동안 다른 메시지가 발생되는 경우 새로이 발생된 메시지가 저장되고 기존에 저장된 메시지는 폐기될 수 있다. 물론, 연결 상태에서 통지 메시지(예, 통지 n+1)가 발생하는 경우 수신자에게로 전송될 수 있다.
(3) sendAllPending로 설정된 경우
발신자는 연결 상태가 보장되지 않는 시간 동안 발생된 통지 메시지들을 저장한다. 이 경우, 전송되는 통지 메시지는 발신자가 임시로 저장할 수 있는 것에 따라 다르게 결정될 수 있다. 발신자는 도달가능성(reachability)을 회복한 경우 저장된 모든 통지 메시지를 수신자에게 전송할 수 있다. 본 설정은 발생된 모든 통지 메시지가 필요한 경우에 사용될 수 있다. 예를 들어, 통계적인 데이터 또는 데이터 분석을 요구하는 응용서비스(자동차 블랙박스)에 사용될 수 있다.
도 15는 통지 정책 정보(예, pendingNotification 속성)가 sendAllPending으로 설정되는 경우 통지 방법을 예시한다.
도 15를 참조하면, 연결 상태가 보장되지 않는 상태에서 구독 자원의 변화에 따라 통지 1 내지 통지 n이 발생할 수 있으며 발신자와 수신자 간에 연결 상태가 보장되지 않는 경우 통지 메시지(notification)는 발신자에서 수신자로 전송될 수 없다. 이 경우, 발생된 통지 메시지들은 통지 정책 정보(예, pendingNotification 속성)에 따라 처리될 수 있다. 본 예에서, 통지 정책 정보(예, pendingNotification 속성)가 sendAllPending으로 설정되어 있으므로 연결 상태가 보장되지 않는 상태에서 발생된 메시지들이 저장될 수 있다. 또한, 연결 상태를 회복한 후 저장된 모든 메시지가 수신자에게 전송될 수 있다. 도 15의 예에서, 발생된 통지 1 내지 통지 n이 모두 저장되어 있으므로 모든 저장 메시지 묶음(aggregation)이 수신자에게 전송된다. 물론, 연결 상태에서 통지 메시지(예, 통지 n+1)가 발생하는 경우 수신자에게로 전송될 수 있다.
(4) sendManual로 설정된 경우
발신자는 연결 상태가 보장되지 않는 시간 동안 발생된 모든 통지 메시지들 중에서 구독자가 임의로 설정한 통지 메시지(들)을 저장한다. 이 때, 임의로 설정되는 기준은 예를 들어 시간(예, 11시~12시), 특정 통지 메시지 지정(예, 연결이 끊어진 시점부터 10개의 통지 메시지) 등과 같이 설정될 수 있다. 본 설정은 앞의 sendNone, sendLatest 및 sendAllPending로 처리되지 못하는 경우를 위하여 구독자 임의의 기준을 설정하는 경우에 사용될 수 있다. 예를 들어, 18시~06시 사이에 발생한 통지 메시지를 요청하는 모니터링 응용서비스에 사용될 수 있다.
도 16은 통지 정책 정보(예, pendingNotification 속성)가 sendManual로 설정되는 경우 통지 방법을 예시한다.
도 16을 참조하면, 연결 상태가 보장되지 않는 상태에서 구독 자원의 변화에 따라 통지 1 내지 통지 n이 발생할 수 있으며 발신자와 수신자 간에 연결 상태가 보장되지 않는 경우 통지 메시지(notification)는 발신자에서 수신자로 전송될 수 없다. 이 경우, 발생된 통지 메시지들은 통지 정책 정보(예, pendingNotification 속성)에 따라 처리될 수 있다. 본 예에서, 통지 정책 정보(예, pendingNotification 속성)가 sendManual로 설정되어 있으므로 연결 상태가 보장되지 않는 상태에서 발생된 메시지들 중 설정된 기준을 만족하는 통지 메시지들만이 저장될 수 있다. 또한, 연결 상태를 회복한 후 저장된 메시지들만이 수신자에게 전송될 수 있다. 도 16의 예에서, 설정된 기준은 시간에 관한 것으로서 t0 이후에 발생된 통지 메시지들을 지시하므로 t0 이후에 발생된 통지 2 내지 통지 n이 저장될 수 있고 연결 상태를 회복한 후 수신자에게 전송될 수 있다. 이 경우, 통지 메시지 묶음은 설정된 기준에 기초하여 수신자에게로 전송될 수 있다.
통지 중요도(notification priority 또는 notification category)를 위한 속성 정보
또한, 본 발명에서는 발신자에서 발생된 통지 메시지의 중요도를 설정하기 위한 속성 정보(예, notificationEventCat 속성)를 제안한다. 본 명세서에서 통지 메시지의 중요도를 설정하기 위한 속성 정보(예, notificationEventCat 속성)는 통지 중요도 정보라고 지칭될 수 있고 제2 속성 정보라고 지칭될 수 있다. 통지 중요도 정보는 구독자에 의하여 설정될 수 있으며 임의의 값 n(예, n=level-1, level-2, … , level-n)으로 표현될 수 있다. 통지 메시지의 중요도는 특정 개수의 이벤트 카테고리로 나뉘어 설정될 수 있으므로 통지 메시지의 중요도는 해당 이벤트 카테고리에 따라 결정될 수 있다. 따라서, 통지 메시지의 중요도는 발생된 이벤트 또는 메시지의 카테고리를 나타내며 (이벤트) 카테고리라고 지칭될 수 있다. 따라서, 통지 중요도 정보(예, notificationEventCat 속성)는 구독 자원에 의해 트리거링되는 통지 메시지를 위한 (이벤트) 카테고리를 정의한다. 또한, 통지 중요도 정보는 수신자가 통지 메시지를 정확히 핸들링할 수 있도록 하기 위해 통지 메시지에 포함될 이벤트 카테고리를 지시할 수 있다. 통지 중요도 정보는 특정 시스템에 미리 설정된 정책(pre-defined policy) 정보와 연동되어 사용될 수 있다.
통지 중요도 정보(예, notificationEventCat 속성)는 구독 자원의 일 속성으로 설정될 수 있다. 따라서, 발신자의 통지 정책을 지시하는 속성 정보는 표 1에 예시된 속성 정보들과 함께 또는 별도로 구독/통지 과정에 이용될 수 있다. 또한, 통지 중요도 정보(예, notificationEventCat 속성)는 구독자에 의해 설정될 수 있다.
예를 들어, 통지 중요도 정보(예, notificationEventCat 속성)는 ‘High(높은 중요도)’, ‘Medium(보통 중요도)’, ‘Low(낮은 중요도)’로 정의될 수 있다. 이 경우, 통지 메시지들 가운데 중요도가 높게 설정된 특정 통지 메시지가 발생하는 경우 발생된 메시지는 notificationEventCat=‘High’를 만족하는 통지 메시지일 수 있다. 해당 통지 메시지는 다른 통지 메시지에 비하여 우선적으로 처리될 수 있다. 표 5는 본 발명에 따른 통지 중요도 정보(예, notificationEventCat 속성)를 예시한다.
표 5
Figure PCTKR2014009041-appb-T000005
표 5의 예에서, 통지 중요도 정보(예, notificationEventCat 속성)의 발생횟수(multiplicity)가 0 또는 1이므로 통지 중요도 정보(예, notificationEventCat 속성)는 구독 자원에 선택적으로(optional) 포함될 수 있다. 또한, 읽기/쓰기가 모두 허용될 수 있다.
도 17은 본 발명에 따른 통지 과정을 예시한다. 본 발명에 따른 통지 과정의 예에서 통지 메시지는 본 발명에서 제안한 속성(attribute) 정보들을 고려하여 전송될 수 있다.
앞에서 기술된 바와 같이 엔티티들 간의 연결 상태가 보장되지 못하는 원인은 네트워크 장애, 장치 고장 및 도달가능성 스케줄(reachability schedule) 등으로 분류할 수 있다. 네트워크 및 장치 고장에 의하여 연결이 끊어진 경우에는 엔티티 측면에서 이를 정상적으로 복구할 수 있는 방법이 없다. 하지만 연결 상태가 도달가능성 스케줄에 의하여 기인한 것이라면 엔티티(예, 발신자)는 연결 상태를 변경한 후 발생된 메시지를 전송할 수 있다. 따라서 본 발명에서는 구독에 대한 통지 과정에서 도달가능성 스케줄에 의하여 연결 상태가 끊어진 것을 확인하였을 때, 본 발명에 따른 속성 정보(예, 통지 정책 정보(예, pendingNotification 속성) 및/또는 통지 중요도 정보(예, notificationEventCat 속성))들을 사용하여 해결할 수 있다.
본 발명에서 구독 과정은 성공적으로 수행된 것으로 가정한다. 즉, 본 발명에 다른 속성 정보들(예, 통지 정책 정보(예, pendingNotification 속성) 및/또는 통지 중요도 정보(예, notificationEventCat 속성))은 구독 과정에서 설정된 것으로 가정한다.
앞서 언급된 바와 같이, 본 발명에서 기술되는 도달가능 모드(reachable mode) 및 도달불가 모드(non-reachable mode)는 다음과 같이 정의될 수 있다. 도달가능 모드(reachable mode)는 해당 엔티티가 정상적으로 동작하여 다른 엔티티와 연결될 수 있는 상태에 있거나 다른 엔티티와 메시지를 송수신할 수 있는 상태를 의미한다. 도달불가 모드(non-reachable mode)는 해당 엔티티의 동작 상태에 제약이 있기 때문에 다른 엔티티가 연결될 수 없는 상태에 있거나 다른 엔티티와 메시지를 송수신할 수 없는 상태를 의미한다. 예를 들어, 센서 네트워크 환경에서는 배터리 등과 같은 문제로 인하여 도달가능 모드 및 도달불가 모드가 존재할 수 있다.
도 17을 참조하면, S1702 단계에서, 구독 과정이 설정된 자원(또는 구독 대상 자원)에 변경이 발생하는 경우 이벤트(event)가 발생할 수 있다. 이벤트는 구독 대상 자원의 변화가 검출/감지되는 경우 발생할 수 있다. 이러한 이벤트가 발생되기 위해 구독 대상 자원의 자녀 자원으로서 구독 자원이 미리 설정될 수 있다.
S1704 단계에서, 발신자는 발생된 이벤트의 중요도를 확인한다. 이 경우, 발신자는 통지 중요도 정보(예, notificationEventCat 속성)를 기반으로 발생된 이벤트의 중요도를 확인할 수 있다(표 5 관련 설명 참조). 예를 들어, 중요도가 높은 경우는 notificationEventCat가 immediate 값으로 설정된 경우를 포함할 수 있다. 다른 예로, 중요도가 높지 않은 경우는 notificationEventCat가 immediate 값 이외의 값(예, bestEffort)으로 설정된 경우를 포함할 수 있다.
발신자는 이벤트의 중요도를 확인한 다음 예를 들어 통지 메시지의 ec 값을 통지 중요도 정보(예, notificationEventCat 속성)가 지시하는 값으로 설정할 수 있다. 또한, 발생 이벤트의 중요도를 확인할 때 통지 중요도 정보(예, notificationEventCat 속성) 외에 구독 자원에 설정된 다른 속성들(예, 표 1 참조) 및/또는 조건들(예, 표 2 참조) 중 적어도 하나가 함께 사용될 수 있다. 이벤트 처리를 위한 속성과 관련된 과정이 끝난 후 통지 메시지(notification)가 생성된다. 이 때, 통지 메시지는 이벤트(들)로 구성되기 때문에 이벤트 카테고리가 통지 메시지의 중요도와 동일할 수 있다.
S1704 단계에서 이벤트 중요도를 확인한 후, 발신자는 이벤트 중요도에 따라 S1706 단계 또는 S1714 단계로 진행할 수 있다. S1704 단계에서 이벤트 중요도가 높은 경우 발신자는 S1706 단계로 진행할 수 있고, S1704 단계에서 이벤트 중요도가 높지 않은 경우 발신자는 S1714 단계로 진행할 수 있다.
S1706 단계 또는 S1714 단계에서 발신자는 자신(Originator) 및 상대방 엔티티(또는 수신자)의 연결 상태를 확인/판별할 수 있다. 발신자 및 수신자의 연결 상태(또는 도달가능성)는 각 엔티티 또는 디바이스를 위한 스케줄링 자원(또는 이에 설정된 스케줄링 정보)를 기반으로 판별될 수 있다.
특정 엔티티(예를 들어 Bluetooth 장치)들은 배터리 소모 등과 같은 이유로 연결 상태를 유동적으로 설정할 수 있다. 따라서 S1706 단계 또는 S1714 단계에서 에서는 발신자가 자신의 상태 및 수신자의 연결 상태가 도달가능 모드인지 도달불가 모드인지 확인하는 과정을 거친다. 만일 해당 엔티티의 상태를 확인할 수 있는 정보가 없다면, 발신자는 해당 엔티티가 도달가능 모드인 것으로 판단할 수 있다.
예를 들어, 발신자는 스케줄링 자원을 통해 스케줄링 정보(또는 도달가능성 스케줄 정보)를 확인할 수 있으며 해당 엔티티의 스케줄링 정보를 통해 연결 상태(또는 도달가능성 모드)를 확인/판별할 수 있다. 발신자를 위한 스케줄링 자원은 구독 자원의 자식 자원(예, notificationSchedule 자원)으로서 설정될 수 있다. 수신자를 위한 스케줄링 자원은 별도의 스케줄링 자원으로서 설정될 수 있다. 앞서 설명한 바와 같이, 스케줄링 자원(예, <schedule> 또는 notificationSchedule 자원)은 스케줄링 정보(또는 스케줄링 시간 정보를 위한 속성(예, scheduleElement))를 포함할 수 있으며 이는 해당 엔티티들의 동작과 관계될 수 있다(연도, 달, 일, 분, 초와 같은 구체적인 시간, 또는 반복 주기 등)(도 9 관련 설명 참조). 따라서, 발신자는 각 스케줄링 자원에 설정된 스케줄링 정보(또는 스케줄링 시간 정보를 위한 속성(예, scheduleElement))를 이용하여 도달가능 또는 도달불가 모드(및/또는 시간 구간)을 확인할 수 있다. 예를 들어, 발신자가 구독 자원의 자식 자원으로 설정된 스케줄링 자원(예, notificationSchedule 자원)을 확인한 결과 이에 포함된 스케줄링 정보가 지시하는 시간 구간에 해당하고 스케줄링 자원이 도달가능 시간 구간을 나타내는 경우 발신자는 도달가능하다고 판별될 수 있다. 다른 예로, 발신자가 별도로 설정된 스케줄링 자원(예, <schedule> 자원)을 확인한 결과 이에 포함된 스케줄링 정보가 지시하는 시간 구간에 해당하고 스케줄링 자원이 도달가능 시간 구간을 나타내는 경우 수신자는 도달가능하다고 판별될 수 있다. 이와 유사한 방법으로 발신자 또는 수신자가 도달불가인지 여부도 판별될 수 있다.
엔티티간의 연결 상태는 다음과 같이 4가지로 구분할 수 있다.
Case 1 - 발신자 및 수신자 모두 도달가능 모드(reachable mode)
Case 2 - 발신자 도달가능 모드, 수신자 도달불가 모드(unreachable mode)
Case 3 - 발신자 및 수신자 도달불가 모드
Case 4 - 발신자 도달불가 모드, 수신자 도달가능 모드
4가지 가운데 오직 Case 1만이 엔티티간의 연결 상태가 있다는 것을 의미할 수 있으며, 나머지 Case들(Case 2, 3 및 4)은 양쪽 또는 한쪽에 설정된 도달불가 모드로 인하여 연결 상태가 없는 것을 의미할 수 있다.
S1706 단계에서, 발생된 통지 메시지가 “중요한 메시지” 조건을 만족하고 연결 상태가 없다고 판별되는 경우(즉, Case 1- 발신자 및 수신자 모두 도달가능 모드), 각각 S1708 단계로 진행할 수 있다. 이 경우, 두 엔티티간의 연결 상태가 있다는 것을 의미하므로 발신자는 발생된 통지 메시지를 수신자에게 즉각적으로 전송한다. 이 때, 발생된 통지 메시지는 중요한 메시지이므로 다른 메시지에 비해 해당 메시지가 우선적으로 처리될 수 있다.
예를 들어, 통지 중요도 정보(예, notificationEventCat 속성)에서 통지 메시지를 우선적으로 처리할 수 있는 값을 ‘immediate’라고 한다면 “중요한 메시지” 조건은 통지 메시지의 ec 값이 ‘immediate’로 설정된 통지 메시지를 의미할 수 있다. ‘immediate’는 오로지 예시일 뿐이며, “중요한 메시지” 조건은 다른 값으로 표현될 수도 있다. 예를 들어, 통지 중요도 정보(예, notificationEventCat 속성)가 ‘High(높은 중요도)’, ‘Medium(보통 중요도)’, ‘Low(낮은 중요도)’로 정의되는 경우 “중요한 메시지” 조건은 통지 메시지의 ec 값이 ‘High’로 설정된 통지 메시지를 의미할 수 있다.
S1706 단계에서, 발생된 통지 메시지가 “중요한 메시지” 조건을 만족하고 연결 상태가 없는 경우(즉, Case 2 - 발신자 도달가능 모드, 수신자 도달불가 모드 / Case 3 - 발신자 및 수신자 도달불가 모드), S1710 단계로 진행할 수 있다.
S1710 단계에서, 발생한 통지 메시지가 중요한 메시지임에도 불구하고, 두 엔티티의 연결 상태가 없는 경우에 발생된 통지 메시지는 전송될 수 없다. 따라서 S1710 단계에서 발신자는 연결 상태가 없는 동안 발생된 통지 메시지들에 대하여 설정된 특정 동작에 따라(예, 통지 정책 정보(예, pendingNotification 속성)에 설정된 값에 따라) 발생된 통지 메시지들을 처리할 수 있다. 통지 정책 정보(예, pendingNotification 속성)에 따라 처리된 통지 메시지는 수신자와의 연결이 회복된 후 수신자에게 전송될 수 있다(표 4 관련 설명 참조). 이 때, 발생된 통지 메시지는 중요한 메시지이므로 다른 메시지에 비해 우선적으로 처리될 수 있다.
S1706 단계에서, 발생된 통지 메시지가 “중요한 메시지” 조건을 만족하고, 연결 상태가 없는 경우(Case 4 - 발신자 도달불가 모드, 수신자 도달가능 모드), S1712 단계로 진행할 수 있다.
S1712 단계에서, 발생한 통지 메시지가 중요한 메시지임에도 불구하고, 두 엔티티의 연결 상태가 없는 경우에 발생된 통지 메시지는 전송될 수 없다. 그러나 S1710 단계와 달리 S1712 단계에서 연결 상태가 없는 것은 오직 발신자 측에 설정된 도달불가 모드 때문이다. 따라서 S1712 단계에서 발신자는 해당 통지 메시지를 우선적으로 전송하기 위하여 자신(Originator)의 상태를 일시적으로 도달불가 모드에서 도달가능 모드로 전환할 수 있다. 발신자에 의하여 연결 상태가 일시적으로 복구된 후, 발신자는 수신자에게 발생된 통지 메시지를 전송하고 전송이 끝나면 원래 설정된 장치 연결 상태(즉, 도달불가 모드)로 전환할 수 있다.
S1704 단계에서 발생된 통지 메시지가 “중요한 메시지” 조건을 만족하지 못하고 S1714 단계에서 연결 상태가 있는 것으로 판별되는 경우(즉, Case 1 - 발신자 및 수신자 모두 도달가능 모드), S1716 단계로 진행할 수 있다.
S1716 단계에서는 두 엔티티간의 연결 상태가 있다는 것을 의미하므로, 발신자는 발생된 통지 메시지를 수신자에게 즉각적으로 전송할 수 있다. 이 때, 발생된 통지 메시지의 중요도는 상대적으로 낮을 수 있기 때문에 이에 따라 낮은 우선 순위로 통지 메시지가 처리될 수 있다.
예를 들어, 통지 중요도 정보(예, notificationEventCat 속성)에서 통지 메시지를 우선적으로 처리할 수 있는 값을 ‘immediate’라고 한다면 “중요한 메시지” 조건을 만족하지 못한다는 것은 통지 메시지의 ec 값이 ‘immediate’ 이외의 값으로 설정된 통지 메시지를 의미할 수 있다. ‘immediate’는 오로지 예시일 뿐이며, “중요한 메시지” 조건은 다른 값으로 표현될 수도 있다. 예를 들어, 통지 중요도 정보(예, notificationEventCat 속성)가 ‘High(높은 중요도)’, ‘Medium(보통 중요도)’, ‘Low(낮은 중요도)’로 정의되는 경우 “중요한 메시지” 조건을 만족하지 못할 경우 통지 메시지의 ec 값이 ‘Medium’, ‘Low’로 설정될 수 있다.
S1704 단계에서 통지 메시지가 “중요한 메시지” 조건을 만족하지 못하고, S1714 단계에서 연결 상태가 없는 것으로 판별되는 경우(즉, Case 2 - 발신자 도달가능 모드, 수신자 도달불가 모드 / Case 3 - 발신자 및 수신자 도달불가 모드 / Case 4 - 발신자 도달불가 모드, 수신자 도달가능 모드), S1718 단계로 진행할 수 있다.
S1718 단계에서, 두 엔티티간의 연결 상태가 없는 경우에 발생된 통지 메시지는 전송될 수 없다. 따라서 S1718 단계에서 발신자는 연결 상태가 없는 동안 발생된 통지 메시지들에 대하여 설정된 특정 동작에 따라(예, 통지 정책 정보(예, pendingNotification 속성)에 설정된 값에 따라) 발생된 통지 메시지들을 처리할 수 있다(표 4 관련 설명 참조). 통지 정책 정보(예, pendingNotification 속성)에 따라 처리된 통지 메시지는 수신자와의 연결이 회복된 후 수신자에게 전송될 수 있다. 이 때, 발생된 통지 메시지의 중요도는 상대적으로 낮기 때문에 이에 따라 낮은 우선 순위로 처리될 수 있다.
도 18은 본 발명에 따른 통지 과정의 실시예를 예시한다. 도 18은 도 17의 S1712에서 수행되는 발신자 동작에 대한 구체적인 실시예를 나타낼 수 있다.
도 18의 예에서, 발신자가 우선적으로 처리되어야 하는 “중요한 메시지”를 의미하는 값을 ‘immediate’라고 가정하고, 미리 설정된 발신자의 도달불가 모드로 인하여 t0부터 t3까지는 연결 상태가 없다고 가정한다. 이 경우, 수신자는 도달가능 모드일 수 있다. 이와 같은 조건에서 연결 상태가 없는 동안 발생된 통지 메시지 가운데 통지 중요도에 대한 조건을 만족하는 통지 메시지 B(예, notificationEventCat=‘immediate’)가 발생하였다면, 발신자는 t1 시점에 일시적으로 도달불가 모드에서 도달가능 모드로 전환되어 해당 통지 메시지를 전송할 수 있다. 통지 메시지를 전송한 후, 발신자는 t2 시점에 도달가능 모드에서 도달불가 모드로 전환할 수 있다. 중요한 메시지가 있는 경우에만 발신자의 연결 상태가 일시적으로 회복되어 해당 메시지를 전송하고, 중요 메시지를 전송한 후 미리 설정된 연결 상태로 복귀할 수 있다.
도 19는 본 발명이 적용될 수 있는 장치의 블록도를 예시한다. 본 발명에 있어서, M2M 게이트웨이, M2M 서버 또는 M2M 디바이스는 각각 전송장치(10) 또는 수신장치(20)로 동작할 수 있다.
전송장치(10)와 수신장치(20)는 정보 및/또는 데이터, 신호, 메시지 등을 나르는 무선 신호를 전송 또는 수신할 수 있는 RF(Radio Frequency) 유닛(13, 23)과, 무선통신 시스템 내 통신과 관련된 각종 정보를 저장하는 메모리(12, 22), 상기 RF 유닛(13, 23) 및 메모리(12, 22)등의 구성요소와 동작시 연결(operatively connected)되고, 상기 구성요소를 제어하여 해당 장치가 전술한 본 발명의 실시예들 중 적어도 하나를 수행하도록 메모리(12, 22) 및/또는 RF 유닛(13,23)을 제어하도록 구성된 프로세서(11, 21)를 각각 포함한다.
메모리(12, 22)는 프로세서(11, 21)의 처리 및 제어를 위한 프로그램을 저장할 수 있고, 입/출력되는 정보를 저장할 수 있다. 메모리(12, 22)가 버퍼로서 활용될 수 있다. 또한, 메모리(12, 22)는 각종 설정 정보와 데이터를 포함하는 리소스를 저장하는 데 사용될 수 있다.
프로세서(11, 21)는 통상적으로 전송장치 또는 수신장치 내 각종 모듈의 전반적인 동작을 제어한다. 특히, 프로세서(11, 21)는 본 발명을 수행하기 위한 각종 제어 기능을 수행할 수 있다. 프로세서(11, 21)는 컨트롤러(controller), 마이크로 컨트롤러(microcontroller), 마이크로 프로세서(microprocessor), 마이크로 컴퓨터(microcomputer) 등으로도 불릴 수 있다. 프로세서(11, 21)는 하드웨어(hardware) 또는 펌웨어(firmware), 소프트웨어, 또는 이들의 결합에 의해 구현될 수 있다. 하드웨어를 이용하여 본 발명을 구현하는 경우에는, 본 발명을 수행하도록 구성된 ASICs(application specific integrated circuits) 또는 DSPs(digital signal processors), DSPDs(digital signal processing devices), PLDs(programmable logic devices), FPGAs(field programmable gate arrays) 등이 프로세서(11, 21)에 구비될 수 있다. 한편, 펌웨어나 소프트웨어를 이용하여 본 발명을 구현하는 경우에는 본 발명의 기능 또는 동작들을 수행하는 모듈, 절차 또는 함수 등을 포함하도록 펌웨어나 소프트웨어가 구성될 수 있으며, 본 발명을 수행할 수 있도록 구성된 펌웨어 또는 소프트웨어는 프로세서(11, 21) 내에 구비되거나 메모리(12, 22)에 저장되어 프로세서(11, 21)에 의해 구동될 수 있다.
전송장치(10)의 프로세서(11)는 상기 프로세서(11) 또는 상기 프로세서(11)와 연결된 스케줄러로부터 스케줄링되어 외부로 전송될 신호 및/또는 데이터에 대하여 소정의 부호화(coding) 및 변조(modulation)를 수행한 후 RF 유닛(13)에 전송한다. 수신장치(20)의 신호 처리 과정은 전송장치(10)의 신호 처리 과정의 역으로 구성된다. 프로세서(21)의 제어 하에, 수신장치(20)의 RF 유닛(23)은 전송장치(10)에 의해 전송된 무선 신호를 수신한다. 상기 프로세서(21)는 수신 안테나를 통하여 수신된 무선 신호에 대한 복호(decoding) 및 복조(demodulation)를 수행하여, 전송장치(10)가 본래 전송하고자 했던 데이터를 복원할 수 있다.
RF 유닛(13, 23)은 하나 이상의 안테나를 구비한다. 안테나는, 프로세서(11, 21)의 제어 하에 본 발명의 일 실시예에 따라, RF 유닛(13, 23)에 의해 처리된 신호를 외부로 전송하거나, 외부로부터 무선 신호를 수신하여 RF 유닛(13, 23)으로 전달하는 기능을 수행한다. 도 19에서 송신장치와 수신장치가 각각 RF 유닛을 통해 통신하는 것으로 도시되어 있지만 송신장치와 수신장치가 유선 네트워크를 통해 통신하는 것도 가능하다. 이 경우, RF 유닛은 네트워크 인터페이스 유닛(network interface unit, NIU)으로 대체될 수 있다.
이상에서 설명된 실시예들은 본 발명의 구성요소들과 특징들이 소정 형태로 결합된 것들이다. 각 구성요소 또는 특징은 별도의 명시적 언급이 없는 한 선택적인 것으로 고려되어야 한다. 각 구성요소 또는 특징은 다른 구성요소나 특징과 결합되지 않은 형태로 실시될 수 있다. 또한, 일부 구성요소들 및/또는 특징들을 결합하여 본 발명의 실시예를 구성하는 것도 가능하다. 본 발명의 실시예들에서 설명되는 동작들의 순서는 변경될 수 있다. 어느 실시예의 일부 구성이나 특징은 다른 실시예에 포함될 수 있고, 또는 다른 실시예의 대응하는 구성 또는 특징과 교체될 수 있다. 특허청구범위에서 명시적인 인용 관계가 있지 않은 청구항들을 결합하여 실시예를 구성하거나 출원 후의 보정에 의해 새로운 청구항으로 포함시킬 수 있음은 자명하다.
본 문서에서 기지국에 의해 수행된다고 설명된 특정 동작은 경우에 따라서는 그 상위 노드(upper node)에 의해 수행될 수 있다. 즉, 기지국을 포함하는 복수의 네트워크 노드들(network nodes)로 이루어지는 네트워크에서 단말과의 통신을 위해 수행되는 다양한 동작들은 기지국 또는 기지국 이외의 다른 네트워크 노드들에 의해 수행될 수 있음은 자명하다. 기지국은 고정국(fixed station), Node B, eNode B(eNB), 액세스 포인트(access point) 등의 용어에 의해 대체될 수 있다. 또한, 단말은 UE(User Equipment), MS(Mobile Station), MSS(Mobile Subscriber Station) 등의 용어로 대체될 수 있다.
본 발명에 따른 실시예는 다양한 수단, 예를 들어, 하드웨어, 펌웨어(firmware), 소프트웨어 또는 그것들의 결합 등에 의해 구현될 수 있다. 하드웨어에 의한 구현의 경우, 본 발명의 일 실시예는 하나 또는 그 이상의 ASICs(application specific integrated circuits), DSPs(digital signal processors), DSPDs(digital signal processing devices), PLDs(programmable logic devices), FPGAs(field programmable gate arrays), 프로세서, 콘트롤러, 마이크로 콘트롤러, 마이크로 프로세서 등에 의해 구현될 수 있다.
펌웨어나 소프트웨어에 의한 구현의 경우, 본 발명은 이상에서 설명된 기능 또는 동작들을 수행하는 모듈, 절차, 함수 등의 형태를 포함하는 소프트웨어 코드 또는 명령어(instruction)로 구현될 수 있다. 소프트웨어 코드 또는 명령어는 컴퓨터 판독가능한 매체에 저장되어 프로세서에 의해 구동될 수 있으며 프로세서에 의해 구동될 때 본 발명에 따른 동작들을 수행할 수 있다. 상기 컴퓨터 판독가능한 매체는 상기 프로세서 내부 또는 외부에 위치하거나 원격으로 네트워크를 통해 상기 프로세서와 연결될 수 있으며, 상기 프로세서와 데이터를 주고 받을 수 있다.
본 발명은 본 발명의 특징을 벗어나지 않는 범위에서 다른 특정한 형태로 구체화될 수 있음은 당업자에게 자명하다. 따라서, 상기의 상세한 설명은 모든 면에서 제한적으로 해석되어서는 아니되고 예시적인 것으로 고려되어야 한다. 본 발명의 범위는 첨부된 청구항의 합리적 해석에 의해 결정되어야 하고, 본 발명의 등가적 범위 내에서의 모든 변경은 본 발명의 범위에 포함된다.
본 발명은 단말, 서버, 게이트웨이 등과 같은 통신 장치에 사용될 수 있다.

Claims (14)

  1. M2M(Machine-to-Machine) 디바이스에서 자원 구독(resource subscription)을 위한 통지(notification)를 수행하는 방법으로서,
    구독 자원을 자녀 자원으로서 포함하는 구독 대상 자원의 변화를 검출하는 단계;
    상기 구독 자원에 설정된 제2 속성 정보에 따라 상기 변화의 이벤트 카테고리를 지시하는 값을 포함하는 통지 메시지를 생성하는 단계; 및
    상기 M2M 디바이스를 위한 스케줄링 자원에 설정된 스케줄링 정보 및 수신 디바이스를 위한 스케줄링 자원에 설정된 스케줄링 정보를 기반으로 상기 수신 디바이스로의 도달가능성을 판별하는 단계를 포함하되,
    상기 스케줄링 정보에 따라 상기 수신 디바이스가 도달가능하다고 판별되는 경우, 상기 통지 메시지는 즉시 상기 수신 디바이스로 전송되고,
    상기 스케줄링 정보에 따라 상기 수신 디바이스가 도달가능하지 않다고 판별되는 경우, 상기 통지 메시지는 상기 구독 자원에 설정된 제1 속성 정보가 가지는 값에 따라 상기 M2M 디바이스에서 처리되고 상기 처리된 통지 메시지는 상기 수신 디바이스가 도달가능한 상태로 회복된 후 상기 수신 디바이스로 전송되는, 방법.
  2. 제1항에 있어서,
    상기 구독 자원과 상기 스케줄링 자원 각각은 고유한 주소를 이용하여 고유하게 어드레싱 가능한 데이터 구조를 나타내는, 방법.
  3. 제1항에 있어서,
    상기 제2 속성 정보는 상기 구독 자원에 의해 트리거링되는 상기 통지 메시지를 위한 이벤트 카테고리를 정의하며,
    상기 통지 메시지에 포함된 이벤트 카테고리를 지시하는 값은 상기 수신 디바이스가 상기 통지 메시지를 핸들링하는 데 이용되는, 방법.
  4. 제1항에 있어서,
    상기 제1 속성 정보는 상기 스케줄링 정보에 따라 상기 수신 디바이스로 도달가능하지 않은 시간 구간이 지난 다음 상기 M2M 디바이스가 수행할 통지 메시지의 처리 동작을 지시하는, 방법.
  5. 제4항에 있어서,
    상기 스케줄링 정보에 따라 상기 수신 디바이스가 도달가능하지 않다고 판별되는 경우, 상기 통지 메시지를 처리하는 것은
    상기 제1 속성 정보가 제1 값을 갖는 경우, 상기 생성된 통지 메시지를 폐기하는 것과,
    상기 제1 속성 정보가 제2 값을 갖는 경우, 상기 생성된 통지 메시지를 저장하고 이전에 저장된 통지 메시지를 폐기하는 것과,
    상기 제1 속성 정보가 제3 값을 갖는 경우, 상기 생성된 통지 메시지를 모두 저장하는 것을 포함하는, 방법.
  6. 제1항에 있어서,
    상기 M2M 디바이스의 스케줄링 정보가 도달가능함을 지시하고 상기 수신 디바이스의 스케줄링 정보가 도달가능함을 지시하는 경우, 상기 수신 디바이스는 도달가능하다고 판별되는, 방법.
  7. 제1항에 있어서,
    상기 M2M 디바이스의 스케줄링 정보가 도달불가함을 지시하거나 상기 수신 디바이스의 스케줄링 정보가 도달불가함을 지시하는 경우, 상기 수신 디바이스는 도달불가하다고 판별되는, 방법.
  8. M2M(Machine-to-Machine) 디바이스에 있어서, 상기 M2M 디바이스는
    네트워크 인터페이스 유닛(Network Interface Unit); 및
    상기 네트워크 인터페이스 유닛과 동작시 연결되는(operatively connected) 프로세서를 포함하며, 상기 프로세서는
    구독 자원을 자녀 자원으로서 포함하는 구독 대상 자원의 변화를 검출하고,
    상기 구독 자원에 설정된 제2 속성 정보에 따라 상기 변화의 이벤트 카테고리를 지시하는 값을 포함하는 통지 메시지를 생성하고,
    상기 M2M 디바이스를 위한 스케줄링 자원에 설정된 스케줄링 정보 및 수신 디바이스를 위한 스케줄링 자원에 설정된 스케줄링 정보를 기반으로 상기 수신 디바이스로의 도달가능성을 판별하도록 구성되며,
    상기 스케줄링 정보에 따라 상기 수신 디바이스가 도달가능하다고 판별되는 경우, 상기 통지 메시지는 즉시 상기 수신 디바이스로 전송되고,
    상기 스케줄링 정보에 따라 상기 수신 디바이스가 도달가능하지 않다고 판별되는 경우, 상기 통지 메시지는 상기 구독 자원에 설정된 제1 속성 정보가 가지는 값에 따라 상기 M2M 디바이스에서 처리되고 상기 처리된 통지 메시지는 상기 수신 디바이스가 도달가능한 상태로 회복된 후 상기 수신 디바이스로 전송되는, M2M 디바이스.
  9. 제8항에 있어서,
    상기 구독 자원과 상기 스케줄링 자원 각각은 고유한 주소를 이용하여 고유하게 어드레싱 가능한 데이터 구조를 나타내는, M2M 디바이스.
  10. 제8항에 있어서,
    상기 제2 속성 정보는 상기 구독 자원에 의해 트리거링되는 상기 통지 메시지를 위한 이벤트 카테고리를 정의하며,
    상기 통지 메시지에 포함된 이벤트 카테고리를 지시하는 값은 상기 수신 디바이스가 상기 통지 메시지를 핸들링하는 데 이용되는, M2M 디바이스.
  11. 제8항에 있어서,
    상기 제1 속성 정보는 상기 스케줄링 정보에 따라 상기 수신 디바이스로 도달가능하지 않은 시간 구간이 지난 다음 상기 M2M 디바이스가 수행할 통지 메시지의 처리 동작을 지시하는, M2M 디바이스.
  12. 제8항에 있어서,
    상기 스케줄링 정보에 따라 상기 수신 디바이스가 도달가능하지 않다고 판별되는 경우, 상기 통지 메시지를 처리하는 것은
    상기 제1 속성 정보가 제1 값을 갖는 경우, 상기 생성된 통지 메시지를 폐기하는 것과,
    상기 제1 속성 정보가 제2 값을 갖는 경우, 상기 생성된 통지 메시지를 저장하고 이전에 저장된 통지 메시지를 폐기하는 것과,
    상기 제1 속성 정보가 제3 값을 갖는 경우, 상기 생성된 통지 메시지를 모두 저장하는 것을 포함하는, M2M 디바이스.
  13. 제8항에 있어서,
    상기 M2M 디바이스의 스케줄링 정보가 도달가능함을 지시하고 상기 수신 디바이스의 스케줄링 정보가 도달가능함을 지시하는 경우, 상기 수신 디바이스는 도달가능하다고 판별되는, M2M 디바이스.
  14. 제8항에 있어서,
    상기 M2M 디바이스의 스케줄링 정보가 도달불가함을 지시하거나 상기 수신 디바이스의 스케줄링 정보가 도달불가함을 지시하는 경우, 상기 수신 디바이스는 도달불가하다고 판별되는, 방법.
PCT/KR2014/009041 2013-09-27 2014-09-26 M2m 시스템에서 통지 메시지 전달 방법 및 이를 위한 장치 WO2015046960A1 (ko)

Priority Applications (5)

Application Number Priority Date Filing Date Title
EP14849785.2A EP3051849B1 (en) 2013-09-27 2014-09-26 Method for delivering notification message in m2m system and devices for same
JP2016538869A JP6254702B2 (ja) 2013-09-27 2014-09-26 Ｍ２ｍシステムにおける通知メッセージ伝達方法及びこのための装置
KR1020167002529A KR102208119B1 (ko) 2013-09-27 2014-09-26 M2m 시스템에서 통지 메시지 전달 방법 및 이를 위한 장치
US14/909,633 US10051404B2 (en) 2013-09-27 2014-09-26 Method for delivering notification message in M2M system and devices for same
CN201480053463.2A CN105580396B (zh) 2013-09-27 2014-09-26 用于在m2m系统中传送通知消息的方法及其装置

Applications Claiming Priority (18)

Application Number Priority Date Filing Date Title
US201361883194P 2013-09-27 2013-09-27
US61/883,194 2013-09-27
US201461935846P 2014-02-05 2014-02-05
US61/935,846 2014-02-05
US201461937621P 2014-02-10 2014-02-10
US61/937,621 2014-02-10
US201461950230P 2014-03-10 2014-03-10
US61/950,230 2014-03-10
US201461952851P 2014-03-13 2014-03-13
US61/952,851 2014-03-13
US201461989536P 2014-05-07 2014-05-07
US61/989,536 2014-05-07
US201462011036P 2014-06-12 2014-06-12
US62/011,036 2014-06-12
US201462023886P 2014-07-13 2014-07-13
US62/023,886 2014-07-13
US201462025022P 2014-07-16 2014-07-16
US62/025,022 2014-07-16

Publications (1)

Publication Number Publication Date
WO2015046960A1 true WO2015046960A1 (ko) 2015-04-02

Family

ID=52743972

Family Applications (2)

Application Number Title Priority Date Filing Date
PCT/KR2014/009041 WO2015046960A1 (ko) 2013-09-27 2014-09-26 M2m 시스템에서 통지 메시지 전달 방법 및 이를 위한 장치
PCT/KR2014/009042 WO2015046961A1 (ko) 2013-09-27 2014-09-26 M2m 시스템에서 통지 메시지 전달 방법 및 이를 위한 장치

Family Applications After (1)

Application Number Title Priority Date Filing Date
PCT/KR2014/009042 WO2015046961A1 (ko) 2013-09-27 2014-09-26 M2m 시스템에서 통지 메시지 전달 방법 및 이를 위한 장치

Country Status (6)

Country Link
US (2) US10051404B2 (ko)
EP (1) EP3051849B1 (ko)
JP (1) JP6254702B2 (ko)
KR (2) KR101769386B1 (ko)
CN (2) CN105580327B (ko)
WO (2) WO2015046960A1 (ko)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106341775A (zh) * 2015-07-10 2017-01-18 华为技术有限公司 一种数据传输方法及装置
WO2017155162A1 (ko) * 2016-03-07 2017-09-14 엘지전자 주식회사 무선 통신 시스템에서 접근 제어 정책 자원을 어나운스하기 위한 방법 및 이를 위한 장치
CN107295554A (zh) * 2016-03-30 2017-10-24 中兴通讯股份有限公司 一种管理应用状态的方法和装置
KR20180082555A (ko) * 2015-11-16 2018-07-18 콘비다 와이어리스, 엘엘씨 M2m 서비스 계층에 대한 교차 리소스 가입
JP2018528689A (ja) * 2015-08-26 2018-09-27 クアルコム，インコーポレイテッド マシンツーマシン通信のためのカスタマイズされたリソースタイプ
EP3393085A4 (en) * 2015-12-31 2018-10-24 Huawei Technologies Co., Ltd. Method and device for time sequence data detection
JP2019527955A (ja) * 2016-07-14 2019-10-03 コンヴィーダ ワイヤレス， エルエルシー サブスクリプションおよび通知サービス

Families Citing this family (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104683289A (zh) * 2013-11-26 2015-06-03 中兴通讯股份有限公司 公共业务实体注册方法和系统
US10015684B2 (en) * 2013-12-01 2018-07-03 Lg Electronics Inc. Method and apparatus for managing specific resource in wireless communication system
CN103618800B (zh) * 2013-12-05 2017-11-03 华为技术有限公司 订阅通知的实现方法和装置
CN104796922B (zh) * 2014-01-22 2019-07-09 中兴通讯股份有限公司 Cse的触发管理方法及装置、cse、承载网网元
CN106471465B (zh) * 2014-04-09 2019-10-22 康维达无线有限责任公司 服务启用器功能
CN105578381A (zh) * 2014-10-10 2016-05-11 中兴通讯股份有限公司 一种创建订阅资源的方法和装置
WO2016123778A1 (zh) * 2015-02-05 2016-08-11 华为技术有限公司 M2m数据处理方法、设备及系统
CN108141727B (zh) * 2015-08-03 2021-05-04 康维达无线有限责任公司 用户设备的移动核心网络服务暴露
US10555170B2 (en) * 2015-09-04 2020-02-04 Huawei Technologies Co., Ltd. Method and apparatus for authentication of wireless devices
WO2017155161A1 (ko) * 2016-03-09 2017-09-14 엘지전자 주식회사 무선 통신 시스템에서 요청을 리-타겟팅(re-target)하기 위한 방법 및 이를 위한 장치
US10452414B2 (en) * 2016-06-30 2019-10-22 Microsoft Technology Licensing, Llc Assistive technology notifications for relevant metadata changes in a document
CN109478153B (zh) * 2016-07-07 2022-02-22 康维达无线有限责任公司 机器到机器服务层通信中的消息重定向
CN113159910A (zh) 2016-07-29 2021-07-23 京东方科技集团股份有限公司 进行通知的方法、装置和系统
CN106231538B (zh) * 2016-07-29 2019-12-27 海尔优家智能科技（北京）有限公司 一种OneM2M架构设备绑定的方法和装置
WO2018019281A1 (zh) * 2016-07-29 2018-02-01 京东方科技集团股份有限公司 进行通知的方法、装置和系统
US10650621B1 (en) 2016-09-13 2020-05-12 Iocurrents, Inc. Interfacing with a vehicular controller area network
WO2018067924A1 (en) * 2016-10-06 2018-04-12 Convida Wireless, Llc Service layer mobility management of applications
CN117170876A (zh) 2016-10-07 2023-12-05 康维达无线有限责任公司 用于通用互通和可扩展性的服务层资源管理
JP6957632B2 (ja) 2017-03-09 2021-11-02 グーグル エルエルシーＧｏｏｇｌｅ ＬＬＣ コンピューティング装置の通知のための通知チャネル
US20180270896A1 (en) * 2017-03-20 2018-09-20 Qualcomm Incorporated Enhanced session and mobility management interaction for mobile initiated connection only mode user equipments
CN106973118B (zh) * 2017-05-12 2021-04-27 京东方科技集团股份有限公司 生成和订阅通知的方法和装置
US10687279B2 (en) * 2017-08-25 2020-06-16 Verizon Patent And Licensing Inc. System and method of optimizing user equipment reachability notifications
CN109495524B (zh) * 2017-09-11 2022-03-04 华为云计算技术有限公司 一种物联网资源订阅的方法、设备和系统
KR102260656B1 (ko) * 2018-03-15 2021-06-04 한국전자기술연구원 M2m 시스템에서의 통지 메시지 실시간 전달 방법
KR102402145B1 (ko) * 2018-03-15 2022-05-26 한국전자기술연구원 M2m 시스템에서의 이벤트 기반 메시지 재전달 방법
CN110505591B (zh) 2018-05-18 2022-09-30 京东方科技集团股份有限公司 订阅服务实体、订阅终端及信息订阅方法和系统
KR102465844B1 (ko) * 2018-07-02 2022-11-09 현대자동차주식회사 M2m 시스템에서 통지 실패시 통지 메시지를 처리하는 방법 및 장치
KR102465843B1 (ko) * 2018-07-10 2022-11-09 현대자동차주식회사 M2m 시스템에서 누적 통지 메시지를 전송하는 방법 및 장치
CN110731074B (zh) * 2018-12-13 2023-01-31 Oppo广东移动通信有限公司 订阅消息的处理方法、装置、计算机设备和存储介质
KR102598045B1 (ko) * 2019-02-11 2023-11-02 현대자동차주식회사 구독 및 통지를 수행하는 방법 및 장치
KR102647498B1 (ko) * 2019-03-18 2024-03-15 주식회사 케이티 M2m 시스템에서 통지 메시지 전송 방법 및 그 장치
KR20210041488A (ko) * 2019-10-07 2021-04-15 현대자동차주식회사 M2m 시스템에서 주기적인 통지를 송수신하는 방법 및 장치
JP2023524367A (ja) * 2020-03-17 2023-06-12 オッポ広東移動通信有限公司 モノのインターネットの通信方法及び装置
CN116918363A (zh) * 2021-03-01 2023-10-20 Oppo广东移动通信有限公司 信息传输方法、装置、设备及存储介质
US11792165B2 (en) 2021-06-04 2023-10-17 Bank Of America Corporation Supporting data processing transactions using machine to machine (M2M) data transfer
US11784981B2 (en) 2021-06-04 2023-10-10 Bank Of America Corporation Data processing transactions using machine to machine (M2M) data transfer
US11265370B1 (en) 2021-07-27 2022-03-01 Bank Of America Corporation Machine to machine (M2M) data transfer between data servers

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012068465A1 (en) * 2010-11-19 2012-05-24 Interdigital Patent Holdings, Inc. Machine-to-machine (m2m) interface procedures for announce and de-announce of resources
US20120170451A1 (en) * 2011-01-05 2012-07-05 Harish Viswanathan System and method for communicating data between an application server and an m2m device
WO2012121552A2 (ko) * 2011-03-08 2012-09-13 엘지전자 주식회사 M2m 기기를 위한 제어정보를 송수신하는 방법 및 이를 위한 장치
WO2012150778A2 (ko) * 2011-05-03 2012-11-08 주식회사 케이티 연결 상태 확인 이벤트에 기반하여 m2m 통신 개체간 연결을 관리하는 방법 및 장치
KR20120127050A (ko) * 2011-05-13 2012-11-21 주식회사 케이티 Ｍ2ｍ 통신에서 네트워크를 선택하는 방법 및 장치

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5696486A (en) * 1995-03-29 1997-12-09 Cabletron Systems, Inc. Method and apparatus for policy-based alarm notification in a distributed network management environment
JP4714025B2 (ja) 2006-01-06 2011-06-29 株式会社日立製作所 センサノード、基地局、センサネット及びセンシングデータの送信方法
JP2008245102A (ja) * 2007-03-28 2008-10-09 Hitachi Kokusai Electric Inc ネットワーク通信方法
US8553883B2 (en) * 2008-02-22 2013-10-08 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for managing subscription credentials in a wireless communication device
US8560835B2 (en) * 2008-06-12 2013-10-15 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for machine-to-machine communication
ES2670371T3 (es) * 2009-07-17 2018-05-30 Koninklijke Kpn N.V. Transmisión de información en una red de telecomunicaciones entre máquinas
KR101601869B1 (ko) * 2009-10-08 2016-03-09 에스케이텔레콤 주식회사 망 정보 알림 서비스 시스템 및 망 정보 알림 서비스 방법
WO2011101032A1 (en) * 2010-02-19 2011-08-25 Telefonaktiebolaget Lm Ericsson (Publ) Apparatuses and methods for handling machine-to-machine communications
TWI569615B (zh) * 2010-03-01 2017-02-01 內數位專利控股公司 機器對機器閘道器
CN102907068A (zh) 2010-03-09 2013-01-30 交互数字专利控股公司 支持机器对机器通信的方法和设备
EP2375849B1 (en) * 2010-03-29 2015-08-12 Vodafone Holding GmbH Connection management for M2M device in a mobile communication network
US8792341B2 (en) 2010-10-27 2014-07-29 Futurewei Technologies, Inc. System and method for machine-to-machine application based congestion control
US8943132B2 (en) 2011-09-12 2015-01-27 Telefonaktiebolaget L M Ericsson (Publ) Systems and methods for optimization of subscriptions to resource changes in machine-to-machine (M2M) systems
US9324055B2 (en) * 2011-12-08 2016-04-26 Microsoft Technology Licensing, Llc Techniques to manage remote events
US20150055557A1 (en) * 2012-03-22 2015-02-26 Interdigital Patent Holdings, Inc. Method and apparatus for supporting machine-to-machine caching at a service capability layer
EP3720170A1 (en) 2013-02-15 2020-10-07 NEC Corporation Core network control parameter determination method and corresponding core network control node
JP6269649B2 (ja) 2013-03-01 2018-01-31 日本電気株式会社 通信システム、サービスプラットフォーム、通信方法及びプログラム
KR101472397B1 (ko) * 2013-04-04 2014-12-12 주식회사 팬택 휴대용 단말 및 노티피케이션 정보 처리 방법
EP2997761B1 (en) * 2013-05-14 2019-01-02 Telefonaktiebolaget LM Ericsson (publ) A node and a method for small data communications
CN111405493B (zh) 2014-07-07 2022-08-12 康维达无线有限责任公司 用于基于机器类型通信组的服务的协调分组

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012068465A1 (en) * 2010-11-19 2012-05-24 Interdigital Patent Holdings, Inc. Machine-to-machine (m2m) interface procedures for announce and de-announce of resources
US20120170451A1 (en) * 2011-01-05 2012-07-05 Harish Viswanathan System and method for communicating data between an application server and an m2m device
WO2012121552A2 (ko) * 2011-03-08 2012-09-13 엘지전자 주식회사 M2m 기기를 위한 제어정보를 송수신하는 방법 및 이를 위한 장치
WO2012150778A2 (ko) * 2011-05-03 2012-11-08 주식회사 케이티 연결 상태 확인 이벤트에 기반하여 m2m 통신 개체간 연결을 관리하는 방법 및 장치
KR20120127050A (ko) * 2011-05-13 2012-11-21 주식회사 케이티 Ｍ2ｍ 통신에서 네트워크를 선택하는 방법 및 장치

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3051849A4 *

Cited By (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106341775A (zh) * 2015-07-10 2017-01-18 华为技术有限公司 一种数据传输方法及装置
CN106341775B (zh) * 2015-07-10 2019-11-01 华为技术有限公司 一种数据传输方法及装置
JP2018528689A (ja) * 2015-08-26 2018-09-27 クアルコム，インコーポレイテッド マシンツーマシン通信のためのカスタマイズされたリソースタイプ
KR102116401B1 (ko) * 2015-11-16 2020-05-29 콘비다 와이어리스, 엘엘씨 M2m 서비스 계층에 대한 교차 리소스 가입
US11012839B2 (en) 2015-11-16 2021-05-18 Convida Wireless, Llc Cross-resource subscription for M2M service layer
KR20180082555A (ko) * 2015-11-16 2018-07-18 콘비다 와이어리스, 엘엘씨 M2m 서비스 계층에 대한 교차 리소스 가입
EP3378217B1 (en) * 2015-11-16 2024-01-03 Convida Wireless, LLC Cross-resource subscription for m2m service layer
CN108353094A (zh) * 2015-11-16 2018-07-31 康维达无线有限责任公司 用于m2m服务层的跨资源订阅
US11711682B2 (en) 2015-11-16 2023-07-25 Convida Wireless LLC Cross-resource subscription for M2M service layer
CN108353094B (zh) * 2015-11-16 2021-09-14 康维达无线有限责任公司 用于m2m服务层的跨资源订阅
EP3393085A4 (en) * 2015-12-31 2018-10-24 Huawei Technologies Co., Ltd. Method and device for time sequence data detection
US10911970B2 (en) 2015-12-31 2021-02-02 Huawei Technologies Co., Ltd. Method and apparatus for detecting time series data
WO2017155162A1 (ko) * 2016-03-07 2017-09-14 엘지전자 주식회사 무선 통신 시스템에서 접근 제어 정책 자원을 어나운스하기 위한 방법 및 이를 위한 장치
EP3439354A4 (en) * 2016-03-30 2019-10-30 ZTE Corporation METHOD AND DEVICES FOR MANAGING AN APPLICATION STATUS
CN107295554A (zh) * 2016-03-30 2017-10-24 中兴通讯股份有限公司 一种管理应用状态的方法和装置
US10798198B2 (en) 2016-07-14 2020-10-06 Convida Wireless, Llc Subscription and notification service
US11153398B2 (en) 2016-07-14 2021-10-19 Convida Wireless, Llc Subscription and notification service
US11582306B2 (en) 2016-07-14 2023-02-14 Convida Wireless, Llc Subscription and notification service
US11750702B2 (en) 2016-07-14 2023-09-05 Convida Wireless, Llc Subscription and notification service
JP2019527955A (ja) * 2016-07-14 2019-10-03 コンヴィーダ ワイヤレス， エルエルシー サブスクリプションおよび通知サービス

Also Published As

Publication number Publication date
KR20160061965A (ko) 2016-06-01
WO2015046961A1 (ko) 2015-04-02
CN105580396A (zh) 2016-05-11
CN105580327A (zh) 2016-05-11
JP2016535532A (ja) 2016-11-10
CN105580396B (zh) 2019-04-16
KR102208119B1 (ko) 2021-01-27
EP3051849A1 (en) 2016-08-03
US10051404B2 (en) 2018-08-14
US20160192111A1 (en) 2016-06-30
EP3051849B1 (en) 2018-11-07
CN105580327B (zh) 2018-12-18
KR101769386B1 (ko) 2017-08-18
KR20160039612A (ko) 2016-04-11
EP3051849A4 (en) 2017-04-12
US9723429B2 (en) 2017-08-01
US20160205217A1 (en) 2016-07-14
JP6254702B2 (ja) 2017-12-27

Similar Documents

Publication Publication Date Title
WO2015046960A1 (ko) M2m 시스템에서 통지 메시지 전달 방법 및 이를 위한 장치
WO2014185754A1 (ko) M2m 통신 시스템에서 구독 및 통지를 위한 방법 및 이를 위한 장치
WO2015069038A1 (ko) M2m 통신 시스템에서 구독 및 통지를 위한 방법 및 이를 위한 장치
WO2014129802A1 (ko) M2m 서비스 설정 변경 방법 및 이를 위한 장치
WO2019199028A1 (en) Method and device using network slicing in mobile communication system
WO2014200292A1 (ko) M2m 시스템에서 위치 측정 방법 및 이를 위한 장치
WO2014109597A1 (ko) M2m(machine-to-machine)시스템에서 게이트웨이 변경 방법 및 이를 위한 장치
WO2018199649A1 (en) Method and apparatus for registration type addition for service negotiation
WO2020226360A1 (en) Apparatus and method for supporting burst arrival time reference clock based on time-sensitive communication assistance information in wireless communication network
WO2016195199A1 (ko) 무선 통신 시스템에서 폴링 채널을 통해 요청을 처리하기 위한 방법 및 이를 위한 장치
EP3574693A1 (en) Method and apparatus for registration type addition for service negotiation
WO2021091307A1 (ko) 무선 통신 시스템에서 mbs 서비스 제공에 대한 mbs 서비스 세션의 설정을 위한 장치 및 방법
WO2012081882A2 (ko) 이동통신 시스템에서 셀 방송 기술을 이용한 신뢰성 있는 그룹 멀티캐스트 전송 방법 및 장치
WO2021167277A1 (ko) 에지 컴퓨팅 시스템에서 무선 통신 네트워크 타입에 따른 서비스 제공 장치 및 방법
EP4008117A1 (en) Method and apparatus for providing policy of user equipment in wireless communication system
WO2021225389A1 (ko) 네트워크 슬라이스를 이용하여 에지 컴퓨팅 서비스를 제공하는 장치 및 방법
WO2016068548A1 (ko) 무선 통신 시스템에서 통지 메시지를 처리하기 위한 방법 및 이를 위한 장치
WO2016126021A1 (ko) 무선 통신 시스템에서 통지 수신 중단 요청을 처리하기 위한 방법 및 이를 위한 장치
WO2021141291A1 (ko) 무선 통신 시스템에서 네트워크 트래픽을 수집하는 방법 및 장치
WO2017073876A1 (ko) 무선 통신 시스템에서 서비스 요청을 처리하기 위한 방법 및 이를 위한 장치
WO2016064235A2 (ko) 무선 통신 시스템에서 그룹 멤버의 자식 자원을 관리하기 위한 방법 및 이를 위한 장치
WO2020256484A1 (ko) 네트워크장치 및 네트워크장치에서 수행되는 엣지서비스 검색 방법
EP4085700A1 (en) Method and apparatus for registering with network slice in wireless communication system
WO2020111761A1 (ko) M2m 시스템에서 메시지 반복 전송 방법 및 장치
WO2023075214A1 (en) Method and apparatus for supporting edge computing service for roaming ue in wireless communication system

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 201480053463.2

Country of ref document: CN

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

Ref document number: 14849785

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 20167002529

Country of ref document: KR

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 14909633

Country of ref document: US

ENP Entry into the national phase

Ref document number: 2016538869

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

REEP Request for entry into the european phase

Ref document number: 2014849785

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2014849785

Country of ref document: EP