WO2020166927A1 - 구독 및 통지를 수행하는 방법 및 장치 - Google Patents

구독 및 통지를 수행하는 방법 및 장치 Download PDF

Info

Publication number
WO2020166927A1
WO2020166927A1 PCT/KR2020/001882 KR2020001882W WO2020166927A1 WO 2020166927 A1 WO2020166927 A1 WO 2020166927A1 KR 2020001882 W KR2020001882 W KR 2020001882W WO 2020166927 A1 WO2020166927 A1 WO 2020166927A1
Authority
WO
WIPO (PCT)
Prior art keywords
subscription
notification
resource
cross
event
Prior art date
Application number
PCT/KR2020/001882
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 CN202080013622.1A priority Critical patent/CN113412634A/zh
Priority to EP20756307.3A priority patent/EP3908016A4/en
Priority to US17/426,280 priority patent/US11937206B2/en
Publication of WO2020166927A1 publication Critical patent/WO2020166927A1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W68/00—User notification, e.g. alerting and paging, for incoming communication, change of service or the like
    • H04W68/005—Transmission of information for alerting of incoming communication
    • 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
    • H04W68/00—User notification, e.g. alerting and paging, for incoming communication, change of service or the like
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/50—Allocation or scheduling criteria for wireless resources
    • H04W72/56—Allocation or scheduling criteria for wireless resources based on priority criteria
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/18—Service support devices; Network management devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data
    • H04W8/20—Transfer of user or subscriber data
    • H04W8/205—Transfer to or from user equipment or user record carrier

Definitions

  • the present invention can provide a method and apparatus for performing subscriptions and notifications in a system. More specifically, it relates to a method and apparatus for performing subscription and notification in a Machine-to-Machine (M2M) system.
  • M2M Machine-to-Machine
  • M2M communication may refer to communication performed between a machine and a machine without human intervention.
  • M2M may refer to Machine Type Communication (MTC), Internet of Things (IoT), or Device-to-Device (D2D).
  • MTC Machine Type Communication
  • IoT Internet of Things
  • D2D Device-to-Device
  • the terminal used for M2M communication may be an M2M terminal (M2M device).
  • M2M terminal may generally be a device having low mobility while transmitting little data.
  • the M2M terminal may be used in connection with an M2M server that centrally stores and manages communication information between machines.
  • the M2M terminal can be applied in various systems such as object tracking, vehicle linkage, and power metering.
  • An object of the present invention is to provide a method of performing subscription and notification in a system.
  • An object of the present invention is to provide a method of performing a notification based on cross-subscription in a system.
  • An object of the present invention is to provide a method of setting priorities for a plurality of subscriptions based on cross-subscription in a system.
  • An object of the present invention is to provide a method for setting an expiration condition of a cross-subscription in a system.
  • the method of transmitting the notification is the step of setting a plurality of subscription conditions based on the cross resource, detecting each event that satisfies each of the plurality of subscription conditions, and when all of the plurality of subscription conditions are satisfied, cross-over It may include transmitting a notification about the resource to the subscriber.
  • a plurality of subscription conditions may have priority.
  • a host that transmits a notification to a subscriber based on a cross resource
  • the host may include a transceiving unit for transmitting and receiving a signal and a processor for controlling the transceiving unit.
  • the processor sets a plurality of subscription conditions based on the cross resource, detects each event that satisfies each of the plurality of subscription conditions, and when all of the plurality of subscription conditions are satisfied, the subscriber receives notification of the cross resource.
  • a plurality of subscription conditions may have priority.
  • the method of receiving the notification may include receiving a notification about the cross resource from the host when all of the plurality of subscription conditions are satisfied, and performing an operation based on the received notification.
  • the host sets a plurality of subscription conditions based on the cross resource, and when the host detects each event that satisfies each of the plurality of subscription conditions, a notification is sent to the subscriber, but the plurality of subscription conditions should have priority. I can.
  • the subscriber may include a transceiver for transmitting and receiving a signal and a processor for controlling the transceiver.
  • the processor may receive a notification about the cross resource from the host and perform an operation based on the received notification.
  • the host sets a plurality of subscription conditions based on the cross resource, and when the host detects each event that satisfies each of the plurality of subscription conditions, a notification is sent to the subscriber, but the plurality of subscription conditions should have priority. I can.
  • a notification about a cross resource may be transmitted to a subscriber only when each event that satisfies each of a plurality of subscription conditions is detected within a time window.
  • the im window may be started when an event for any one of a plurality of subscription conditions is detected.
  • a time window may be started only when an event for a subscription condition having the highest priority among the plurality of subscription conditions is detected.
  • the cross resource is Notifications about this can be sent to subscribers.
  • a host requests a single resource for each of a plurality of subscription conditions to each M2M entity, and each M2M entity receives a single resource when an event is triggered based on each subscription condition.
  • Each notification can be sent to the host based on it.
  • the host when the host receives each notification from each M2M entity within a time window, the host may transmit a notification on the cross resource to the subscriber.
  • an expiration counter for the cross resource may be set.
  • an expiration counter for the preceding subscription is It can be updated based on the expiration counter.
  • an expiration counter for a preceding subscription may be rewritten as an expiration counter for a cross-subscription.
  • the current number of notifications issued for the preceding subscription may be reset.
  • the current number of notifications issued for the preceding subscription may be reset only when the number of remaining notifications is smaller than the expiration counter of the cross resource based on the current number of notifications issued for the preceding subscription.
  • a system can perform subscription and notification.
  • the system may perform notification based on cross-subscription.
  • the system may set priorities for a plurality of subscriptions based on cross-subscription.
  • the system may set an expiration condition for cross-subscription.
  • FIG 1 illustrates an M2M system according to an embodiment.
  • FIG. 2 shows a layered structure of an M2M system according to an embodiment.
  • FIG. 3 is a diagram illustrating a communication flow between each entity according to an embodiment.
  • FIG. 4 shows a configuration of an M2M system according to an embodiment.
  • FIG. 5 is a diagram illustrating a method of exchanging messages between a sender and a receiver.
  • 6 is a diagram showing attribute information on a subscription resource.
  • FIG. 7 and 8 are diagrams illustrating a method of operating based on a cross resource.
  • 9 is a diagram showing attribute information for cross resource subscription.
  • FIG. 10 is a diagram illustrating a subscription and notification operation.
  • 11 is a diagram showing a subscription and notification operation.
  • 12 and 13 are diagrams illustrating a method of updating an expiration counter for a cross resource.
  • FIG. 14 is a diagram showing a device configuration.
  • 15 is a diagram showing a device configuration.
  • first and second are used only for the purpose of distinguishing one component from other components, and do not limit the order or importance of the components unless otherwise stated. Accordingly, within the scope of the present disclosure, a first component in one embodiment may be referred to as a second component in another embodiment, and similarly, a second component in one embodiment is a first component in another embodiment. It can also be called.
  • a component when a component is said to be “connected”, “coupled” or “connected” with another component, it is not only a direct connection relationship, but an indirect connection relationship in which another component exists in the middle. It can also include.
  • a certain component when a certain component “includes” or “have” another component, it means that other components may be further included rather than excluding other components unless otherwise stated. .
  • components that are distinguished from each other are intended to clearly describe each feature, and do not necessarily mean that the components are separated. That is, a plurality of components may be integrated to be formed in one hardware or software unit, or one component may be distributed in a plurality of hardware or software units. Therefore, even if not stated otherwise, such integrated or distributed embodiments are also included in the scope of the present disclosure.
  • components described in various embodiments do not necessarily mean essential components, and some may be optional components. Accordingly, an embodiment consisting of a subset of components described in an embodiment is also included in the scope of the present disclosure. In addition, embodiments including other elements in addition to the elements described in the various embodiments are included in the scope of the present disclosure.
  • the system may be a system using Internet of Things (IoT), a system using Machine To Machine (M2M), or the like.
  • IoT Internet of Things
  • M2M Machine To Machine
  • the system to which the operation based on the present invention is applied may be a system referred to in the present invention, and is not limited to the above-described embodiment.
  • the present specification describes a network based on M2M communication, and an operation performed in the M2M communication network may be performed in a process of controlling the network and transmitting data in a system in charge of the communication network.
  • the M2M terminal may be a terminal that performs M2M communication, but may be a terminal operating in a wireless communication system in consideration of backward compatibility. That is, the M2M terminal may mean a terminal that can be operated based on the M2M communication network, but is not limited to the M2M communication network. The M2M terminal may be capable of operating based on other wireless communication networks, and is not limited to the above-described embodiment.
  • a terminal used for M2M communication may be referred to as an M2M device.
  • the M2M device generally has characteristics such as low mobility, time tolerant or delay tolerant, and small data transmission, and centrally stores communication information between machines. It can be used in connection with the managed M2M server.
  • the M2M device and the M2M server are connected through the M2M gateway in a section in which the communication method is changed, through which the entire M2M system can be configured.
  • transportation service e.g., Intelligent Transport System (ITS), transportation safety service, etc.
  • object tracking Tracking
  • power metering Metaling
  • Payment automatic payment system
  • Services such as medical service and remote control
  • the M2M device may be fixed or mobile, and communicate with the M2M server to transmit and receive user data and/or control information.
  • M2M devices include Terminal Equipment, Mobile Station (MS), Mobile Terminal (MT), User Terminal (UT), Subscribe Station (SS), wireless device, Personal Digital Assistant (PDA), and wireless modem ( wireless modem), a 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 exchange data and control information by communicating with M2M devices and/or another M2M server.
  • the M2M gateway may refer to a device that serves as a connection point 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 can function as an M2M device, and in addition, for example, it manages the M2M device connected to the M2M gateway, receives a message and delivers the same or changed message to the connected M2M devices (message fan out), message aggregation may be performed.
  • the term M2M device may be used as a concept including an M2M gateway and an M2M server, and therefore, an M2M gateway and an M2M server may be referred to as an M2M device.
  • entity in this specification may be used to refer to hardware such as an M2M device, an M2M gateway, or an M2M server, or the software of the M2M application layer and the M2M (common) service layer described below. It can be used to refer to a software component.
  • the present invention is described centering on the M2M system, but the present invention is not limitedly applied only to the M2M system, for example, the same to the system according to the client-server (or sender-responder) model / It can be applied similarly.
  • FIG 1 illustrates an M2M system according to an embodiment.
  • M2M system defines a common M2M service framework for various M2M applications.
  • M2M application 10 refers to a software component that implements M2M service solutions such as e-Health, City Automation, Connected Consumer, and Automotive. I can.
  • M2M services functions commonly required to implement such various M2M applications are provided, and functions commonly required may be referred to as M2M services or M2M common services.
  • M2M common services By using these M2M common services, M2M applications can be easily implemented without having to reconfigure the basic service framework for each M2M application.
  • M2M service is provided in the form of a set of service capabilities (Service Capability, SC; 20), and the M2M application 10 accesses a set of SC (Service Capability) or SC (Service Capability) through an open interface.
  • M2M services or functions provided by SC (Service Capability) can be used.
  • the M2M service capability 20 may provide a function (eg, device management, location, discovery, group management, registration, security, etc.) that constitutes an M2M service, and an SC layer (Service Capabilities Layer) or an SC entity (Service Capability). Entity) can be said to be a set of functions for M2M services that can be used when an M2M application is provided on a service framework.
  • SC Service Capability
  • x may be expressed as one of N/G/D, and indicates where the SC (Service Capability) exists among a network (and/or a server), a gateway, and a device.
  • NSC represents SC (Service Capability) existing on the network and/or server
  • GSC represents SC (Service Capability) existing on the gateway.
  • the M2M application may exist on a network, a gateway, or a device.
  • An M2M application existing on a network or directly connected to a server is referred to as an M2M network application and may be briefly represented as a network application (NA).
  • NA is software that is directly connected to a server and implemented, and may communicate with and manage an M2M gateway or M2M device.
  • the M2M application existing on the device is referred to as an M2M device application and may be simply referred to as a device application (DA).
  • DA device application
  • DA software running on an M2M device, and sensor information may be delivered to NA.
  • the M2M application existing on the gateway is referred to as an M2M gateway application and may be briefly referred to as a GA (Gateway Application).
  • the GA may also play a role of managing an M2M gateway and may provide an M2M service or function (eg, Service Capabilities (SCs) or Service Capability (SC)) to a DA.
  • M2M service or function eg, Service Capabilities (SCs) or Service Capability (SC)
  • SCs Service Capabilities
  • SC Service Capability
  • the M2M application may collectively refer to an application entity (AE) and an application layer.
  • the M2M system architecture may be divided into a network domain 10 and a device and gateway domain 20.
  • the network domain may include functions (11) for M2M system management and functions (12) for network management.
  • the function for M2M system management can be performed by the M2M application and M2M SCs (Service Capabilities) that manage devices existing in the device and gateway domain, and the function for network management can be performed by the core network and the access network. have.
  • the core network 13 and the access network 14 may provide connections between entities rather than performing M2M functions.
  • M2M communication can be performed between the M2M SCs (Service Capabilities) in the network domain 10 and the device and gateway domain 20 through the core network 13 and the access network 14, and the M2M application in each domain is It is possible to send and receive signals or information through M2M Service Capabilities (SCs).
  • SCs Service Capabilities
  • the access network 14 is an entity that enables the M2M device and gateway domain to communicate with the core network 13.
  • Examples of the access network 14 include Digital Subscriber Line (xDSL), Hybrid Fiber Coax (HFC), satellite, GERAN, UTRAN, eUTRAN, wireless LAN, and WiMAX.
  • xDSL Digital Subscriber Line
  • HFC Hybrid Fiber Coax
  • satellite GERAN, UTRAN, eUTRAN, wireless LAN, and WiMAX.
  • Core Network may be an entity that provides functions such as Internet Protocol (IP) connection, service and network control, interconnection, and roaming.
  • the core network 13 may include a 3rd Generation Partnership Project (3GPP) core network, an ETSI Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN) core network, a 3GPP2 core network, and the like.
  • 3GPP 3rd Generation Partnership Project
  • TISPAN Internet converged Services and Protocols for Advanced Networking
  • M2M SC Service Capability
  • CSF M2M common service function
  • SCL M2M Service Capability Layer
  • the M2M application 16 is an entity capable of operating service logic and using M2M Service Capabilities (SCs) through an open interface.
  • the M2M application layer may refer to a layer including such an M2M application and related operational logic.
  • the M2M device 21 is an entity that operates an M2M device application through M2M Service Capabilities (SCs).
  • the M2M device 21 may directly communicate with the M2M server in the network domain, or may communicate with the M2M server in the network domain through the M2M gateway 22.
  • the M2M gateway 22 When connected through the M2M gateway 22, the M2M gateway 22 operates like a proxy.
  • the M2M device 21 may include an M2M application and/or M2M Service Capabilities (SCs).
  • the M2M area network 23 provides connectivity between the M2M device and the M2M gateway.
  • 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.
  • the M2M area network includes PAN (Personal Area Network) technologies such as IEEE 802.15.1, Zigbee, Bluetooth, IETF ROLL, and ISA100.11a, and PLC (Power Line Communication), M-BUS, and wireless. It can be implemented using local network technologies such as M-BUS and KNX.
  • the M2M gateway 22 may be an entity that manages M2M applications through M2M Service Capabilities (SCs) and provides services to M2M applications.
  • the M2M gateway 22 may serve as a proxy between the M2M device 21 and the network domain 10 and may serve to provide services to non-compliant M2M devices.
  • the M2M gateway 22 may refer to an entity having a gateway function among M2M devices 21.
  • the M2M gateway 22 may include M2M applications and/or M2M Service Capabilities (SCs).
  • M2M SC Service Capability
  • SCL Service Capability Layer
  • CSL Common Service Layer
  • CSE Common Service Entity
  • the M2M application may be referred to as an application entity (AE)
  • the M2M application layer may be simply referred to as an application layer.
  • the name of each domain may also be different.
  • the network domain may be referred to as an infrastructure domain
  • the device and gateway domain may be referred to as a field domain.
  • the 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 shows a layered structure of an M2M system according to an embodiment.
  • the 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 such as device management, location service, and device triggering that exist in the core network to the common service layer 204.
  • an Mca reference point 312 may designate a communication flow between an application entity (AE) 302 and a common service entity (CSE) 304.
  • the Mca reference point 312 may enable the AE 302 to use the services provided by the CSE 304 and allow 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 may designate a communication flow between different common service entities (CSEs) 304.
  • the Mcc reference point 314 may enable the CSE 304 to use the services of other CSEs when providing the necessary functions.
  • the service provided through the Mcc reference point 314 may depend on functions supported by the CSE 304.
  • the Mcc reference point 314 may refer to an interface between M2M common service layers.
  • the Mcn reference point 316 may specify a communication flow between the CSE 304 and the underlying network service entity (NSE) 306.
  • the Mcn reference point 316 enables the CSE 304 to use the services provided by the underlying NSE 306 to provide the required functions.
  • the Mcn reference point 316 may refer to an interface between the M2M common service layer and the M2M base network layer.
  • CSE 304 may provide various common service functions/capabilities.
  • CSE (304) is an application and service layer management (Application and Service Layer Management) function, communication management and delivery processing (Communication Management and Delivery Handling) function, data management and storage (Data Management and Repository) function, device Device Management function, Group Management function, Discovery function, Location function, Network Service Exposure/ Service Execution and Triggering function, Registration ) May include at least one of a function, a security function, a service charging and accounting function, a service session management function, and a subscription/notification function.
  • the 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. A brief description of common service functions is as follows.
  • ASM Application and Service Layer Management
  • CMDH -Communication Management and Delivery Handling
  • DMR Data Management and Repository
  • DMG -Device Management
  • DIS -Discovery
  • a group can be created by binding a resource, an M2M device, or an M2M gateway, and a group-related request can be handled.
  • An M2M application may play a role of acquiring location information of an M2M device or an M2M gateway.
  • NSSE Network Service Exposure/ Service Execution and Triggering
  • M2M application or other CSE performs a role of handling registration to a specific CSE. Registration may be performed to use the M2M service function of a specific CSE.
  • SEC Security
  • SCA Service Charging and Accounting
  • SSM Service Session Management
  • Subscribing to a change for a specific resource can serve to notify when a corresponding 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 that has at least one application entity (AE) but does not have a common service entity (CSE).
  • the ADN can 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 (M2M device having a constrained capability), and an M2M device having a limited capability is an M2M device that does not include a common service layer or a common service entity (CSE). May refer to.
  • An M2M device with limited capabilities may be simply referred to 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.
  • the middle node may refer to a node having one common service entity (CSE) and zero or more M2M application entities (AE).
  • MN can communicate with one infrastructure node (IN) or another intermediate node (MN) through Mcc, or can communicate with IN/MN/ASN through Mcc, or can communicate with ADN through Mca. have.
  • the MN may be referred to as an M2M gateway.
  • An infrastructure node may refer to a node having one common service entity (CSE) and zero or more application entities (AE).
  • the IN may communicate with at least one intermediate node (MN) through the Mcc and/or may communicate with at least one ASN.
  • IN can communicate with one or more ADNs through Mca.
  • IN may be referred to as an M2M server.
  • Example 1 illustrates communication between ADN and IN.
  • ADN may be an M2M device with limited capabilities.
  • the ADN since the ADN does not have a CSE or a common service layer, it can communicate with the CSE of the IN through the Mca. Also, in this case, the ADN does not have a CSE or a common service layer, and thus data generated in the AE or application layer cannot be stored/shared with other entities. Therefore, in “Example 1", the data generated in the AE of the ADN or the application layer may be stored and shared in the CSE of the IN.
  • Example 2 exemplifies communication between ADN and MN.
  • ADN may also be an M2M device with limited capabilities. Therefore, it can operate similarly to Example 1 except that the ADN communicates with the CSE of the MN. That is, the ADN can communicate with the CSE of the MN through the Mca.
  • the ADN since the ADN does not have a CSE or a common service layer, data generated in the AE or application layer cannot be stored/shared to other entities. Accordingly, data generated in the AE of the ADN or the application layer may be stored and shared in the CSE of the MN.
  • the MN can communicate with the IN through the MN.
  • MN and MN, and MN and IN can communicate through Mcc. It is also possible for MN to communicate with IN directly without going through MN.
  • Example 3 illustrates communication between ASN and MN. Unlike “Example 1” or “Example 2”, the ASN has a CSE or a common service layer, so data generated in the AE or application layer of the ASN can be stored in its CSE or a 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 communication between ASN and MN. Compared with “Example 3”, the CSE of ASN can communicate with the CSE of IN directly without going through the MN.
  • the IN may be located in the infrastructure domain or network domain and may contain one CSE and may contain zero or more AEs. INs can communicate with each other through Mcc.
  • FIG. 5 is a diagram illustrating a method of exchanging messages between a sender and a receiver.
  • a sender may transmit a request message to a receiver (Receiver, 520).
  • the sender 510 and the receiver 520 may be the aforementioned M2M terminals. However, it is not limited to the M2M terminal, other terminals may be possible, and are not limited to the above-described embodiment.
  • the sender 510 and the receiver 520 may be the above-described node, entity, server, or gateway. That is, the sender 510 and the receiver 520 may have a hardware configuration or a software configuration, and are not limited to the above-described embodiments.
  • At least one parameter may be included in the request message transmitted by the sender 510.
  • the parameter may be an essential parameter or an optional parameter.
  • a parameter related to a transmitting end, a parameter related to a receiving end, an identification parameter, and an operation parameter may be essential parameters.
  • other information may be an optional parameter.
  • the parameter related to the transmitting end may be a parameter for the sender 510.
  • the parameter related to the receiver may be a parameter for the receiver 520.
  • the identification parameter may be a parameter required for mutual identification.
  • the operation parameter may be a parameter for classifying an operation.
  • the operation parameter may be set to at least one of Create, Retrieve, Update, Delete, and Notify. That is, it may be a parameter for distinguishing an operation.
  • the receiver 520 may process the request message. For example, the receiver 520 may perform an operation included in the request message, and for this, determine whether a parameter is valid and whether or not there is authority. In this case, the receiver 520 may check whether the parameter is valid, and if there is authority, whether a resource to be requested exists, and perform processing based thereon.
  • the sender 510 may transmit a request message including a parameter for notification to the receiver 520.
  • the receiver 520 may check the parameters for the notification included in the request message, perform an operation based thereon, and transmit the response message back to the sender 510.
  • each resource and its properties are described.
  • the name is described in consideration of the characteristics of the resource or attribute, but is not limited thereto. That is, it can be applied in the same manner as in the present invention to a resource or attribute having the same or similar characteristics to the resource or attribute described below.
  • it is described with a specific name in consideration of features, and related contents are described centering on this. However, it is not limited thereto.
  • 6 is a diagram showing properties of a subscription resource.
  • a subscription resource may include attributes.
  • the properties of the subscription resource are described in FIG. 6, this is only an example and may be added, deleted, or changed.
  • information necessary for subscription-notification may be shared through the properties of the subscription resource.
  • information necessary to perform an operation required for subscription-notification may be defined as attribute information, and is not limited to the above-described embodiment.
  • the subscription resource may include an "expirationCounter", which will be described later.
  • M2M terminals may operate on the basis of a subscription-notification.
  • an event may be registered through a subscription resource in the M2M platform, and a notification message may be delivered when a corresponding event occurs.
  • a target system allocates subscription resources to a hosting system, and the hosting system may deliver a notification message to the target system when an event occurs.
  • the hosting system and the target system may be entities operating based on the above-described M2M terminal.
  • a resource host 710 as an M2M entity and a subscriber 720 as an M2M entity may request a subscription.
  • the subscriber 720 may request a subscription to a plurality of resources.
  • the subscriber 720 may request a subscription request for a first sensor and a subscription request for a second sensor from the resource host 710, respectively.
  • a notification for each subscription may be transmitted to a subject other than the subscriber 720.
  • the following description is based on a case where the subscriber 720 receives a notification, but is not limited thereto.
  • the subscriber 720 may receive a first notification, which is a notification for the first sensor, from the host 710.
  • the subscriber 720 may receive a second notification, which is a notification for the second sensor, from the host 720. That is, the first notification and the second notification may be notified according to respective conditions based on each subscription resource.
  • the first notification and the second notification may be notifications related to the same event.
  • the event may be a fire detection event
  • the first notification and the second notification may be a notification by a temperature sensor and a notification to a smoke sensor, respectively.
  • the event may be a speeding notification event
  • the first notification and the second notification may be notification by detection of a surveillance camera and notification of exceeding a preset speed or higher value. That is, as described above, the first notification and the second notification may be notifications for events related to each other.
  • the subscriber 720 may analyze the first notification and the second notification to determine whether or not an event of interest occurs. That is, the subscriber 720 may check whether an event of interest occurs based on an additional operation based on each notification.
  • FIG. 8 is a diagram illustrating a method of operating based on a cross resource.
  • the host e.g. IN-CSE, 750
  • the subscriber e.g. IN-AE, 760
  • the subscriber 760 may wish to receive a single notification under a certain criterion based on a change of a plurality of resources as target resources. That is, the subscriber 760 may receive a single notification based on the satisfaction of conditions for a plurality of resources through the cross resource.
  • the cross resource request may include information shown in Table 1 below.
  • the cross-resource request may include “target regular resources (regularResourcesAsTarget)” and “target subscription resources (subscriptionResourcesAsTarget)” information based on the following attribute information.
  • target general resources (regularResourcesAsTarget)” may include list information of regular resources that may be targets to target resources that may be used for cross resource subscription.
  • the general resource may include at least one or more of oneM2M resources that may be subscribed, and is not limited to the above-described embodiment.
  • target subscription resources may mean resources that exist for actual subscription. That is, as a target resource used for cross resource subscription, it may mean an actual subscription resource. That is, it may include target resource information that is a target for generating a notification.
  • timeWindowType is a type for a time period for cross resource subscription, indicating a certain period without overlapping, or as a sliding time window, indicating the type of a time window for cross resource subscription. have.
  • time window size may indicate the size of the time window, and is not limited to the above.
  • notificationContentType One RW See clause 9.6.8 notificationEventCat 0..1 RW See clause 9.6.8 subscriberURI 0..1 RW See clause 9.6.8 regularResourcesAsTarget 0..1(L) RW
  • This attribute indicates a list of regular resources (i.e. normal resources rather than ⁇ subscription> resources), which shall be used as the target resource for this cross-resource subscription.
  • the regular resource is referred to as any subscribable oneM2M resources.
  • subscriptionResourcesAsTarget 0..1(L) RW This attribute indicates a list of existing ⁇ subscription> resources, which shall be used as the target resource for this cross-resource subscription.
  • timeWindowType One RW
  • timeWindowSize One RW This attribute indicates the size or time duration (e.g. in seconds) of the time window, based on which cross-resource notifications shall be generated. Note that the maximum window size (e.g.
  • eventNotificationCriteriaSet 0..1(L) RW
  • This attribute lists eventNotificationCriteria for each regular target resource as indicated in regularResourcesAsTarget attribute and involved in a cross-resource subscription. If there is only one eventNotificationCriteria contained in this attribute, it shall be applied to all target resources as indicated by regularResourcesAsTarget attribute. If only subscriptionResourcesAsTarget attribute appears (i.e. no regularResourcesAsTarget attribute), eventNotificationCriteriaSet shall not be needed. See clause 9.6.8 for the description of eventNotificationCriteria.
  • the host 750 may indicate that the request for a single resource is for a cross resource and transmit it to each of the M2M entities 730 and 740. Through this, each of the M2M entities 730 and 740 may recognize that a single resource notification is a cross resource.
  • each M2M entity (730, 740) when each M2M entity (730, 740) receives a message indicating that it is not cross-resource, if each of the M2M entities (730, 740) is in a notification impossible state, a message indicating that the notification is impossible May be transmitted to the host 750.
  • each of the M2M entities 730 and 740 when receiving a message indicating that each of the M2M entities 730 and 740 is a cross resource, each of the M2M entities 730 and 740 hosts a message indicating that the notification is impossible when the notification is disabled. It can be transmitted to 750 and the subscriber 760.
  • the entire cross-resource may be meaningless, and each of the M2M entities 730 and 740 is a subscriber ( 760)
  • the notification impossible message may also be transmitted to the subscriber 760 based on the identification information, and is not limited to the above-described embodiment.
  • each of the M2M entities 730 and 740 may transmit a response message for a single resource subscription request to the host 750. (S774, S776) That is, each of the M2M entities 730 and 740 may determine whether to grant a single resource subscription, and transmit a response thereto to the host 750. Thereafter, the host 750 may transmit the final response to the subscriber 760.
  • each of the M2M entities 730 and 740 each has a first notification (S779) and The second notification S781 may be transmitted to the host 750.
  • the host 750 may buffer the above-described notifications.
  • the host 750 may determine whether the first notification and the second notification match the satisfied criteria based on the above-described cross resource attribute information.
  • Host 750 may perform time window mechanisms to determine whether a notification is sent to subscriber 760.
  • the host 750 may generate a notification and transmit the notification to the subscriber 760 (S783).
  • the host 750 It is possible to determine whether or not the notification is to be transmitted to the subscriber 760 in consideration of the occurrence of the first notification and the second notification within a predetermined time window size, which will be described later. That is, in the case of cross-resource subscription, it may be performed when the subscriber 760 desires a cross-notification in consideration of events before and after the first sensor and the second sensor are satisfied. For example, when it is desired to first satisfy the subscription condition for the first sensor, the time window mechanism may not be performed even if the notification for the second sensor is first notified.
  • the host 750 can initiate the time window mechanism only after receiving a notification that must be satisfied first.
  • the notification message is only application dependent, but may be an indication for triggering an operation based on a preconfigured rule.
  • the host 750 may transmit a command to the sensor and perform injection to suppress the fire. That is, the host 750 may transmit a notification to the subscriber 760 based on the notification message and perform necessary actions at the same time.
  • the host 750 may notify the subscriber 760 when detecting vehicle damage based on the first sensor and the second sensor. At the same time, the host 750 may capture an image based on a preset rule and store information on the captured image, and the embodiment is not limited thereto.
  • Subscriptions and notifications for resources or subscriptions and notifications for cross resources may be performed based on the above.
  • the attribute information on the subscription may be as in FIG. 6 described above, and the specific attribute information may be as in Table 2 below.
  • Table 2 is only an example of subscription attribute information, and other attribute information may be set. That is, information related to subscription and notification may be set as attribute information.
  • information on whether to allow read/write of a corresponding attribute may be displayed for each attribute.
  • the above-described information may be one of “READ/WRITE(RW)”, “READ ONLY(RO)”, and “WRITE ONLY(WO)”.
  • the number of occurrences may indicate the number of times a corresponding attribute can occur in a subscription resource.
  • Table 2 below is only an example, and other attribute information may be further set as a subscription resource attribute.
  • EventNotificationCriteria 0..1 RW This attribute (notification policy) indicates the event criteria for which a notification is to be generated. When no eventNotificationCriteria attribute is present in a ⁇ subscription> resource, the Hosting CSE shall trigger notifications for this subscription when any of the attributes of the subscribed-to resource is modified. expirationCounter 0..1 RW This attribute (notification policy) indicates that the subscriber wants to set the life of this subscription to a limit of a maximum number of notifications. When the number of notifications sent reaches the count of this counter, the ⁇ subscription> resource shall be deleted, regardless of any other policy.
  • notificationURI 1 (L) RW This attribute shall be configured as a list consisting of one or more targets that the Hosting CSE shall send notifications to.
  • a target shall be formatted as a oneM2M compliant Resource-ID as defined in clause 7.2 or as an identifier compliant with a oneM2M supported protocol binding (e.g. http, coap, mqtt). ... ... subscriberURI 0..1 WO
  • This attribute shall be configured with the target of the subscriber. The target is used by the Hosting CSE to determine where to send a notification when the subscription is deleted.
  • a target shall be formatted as a oneM2M compliant Resource-ID as defined in clause 7.2 or as an identifier compliant with one of the oneM2M supported protocol bindings (the detailed format of which are defined by each respective oneM2M protocol binding specification).
  • associatedCrossResourceSub 0..1 RW This attribute lists the identifier of ⁇ crossResourceSubscription> resources where this ⁇ subscription> is involved in.
  • the event notification criterion attribute (eventNotificationCriteria) is a list of conditions for modification and change of a subscription target resource, and may be shown in Table 3 below. However, Table 3 below is only some information on the event notification criterion attribute, and other information may be further included.
  • each condition of the event notification criterion attribute list may be in a logical AND relationship. For example, when the event notification criterion attribute includes two conditions, a notification may be transmitted when the modification/change of a subscription target resource satisfies both conditions. That is, the amount of the notification message can be adjusted by setting the event notification criterion attribute in the subscription resource based on the above description. When the set event notification criterion attribute is satisfied, a notification is transmitted to a notification target entity, thereby preventing the problem of overflowing notification messages.
  • Condition tag Multiplicity Matching condition createdBefore 0..1 The creationTime attribute of the resource is chronologically before the specified value. createdAfter 0..1 The creationTime attribute of the resource is chronologically after the specified value. modifiedSince 0..1 The lastModifiedTime attribute of the resource is chronologically after the specified value. unmodifiedSince 0..1 The lastModifiedTime attribute of the resource is chronologically before the specified value. stateTagSmaller 0..1 The stateTag attribute of the resource is smaller than the specified value. stateTagBigger 0..1 The stateTag attribute of the resource is bigger than the specified value. expireBefore 0..1 The expirationTime attribute of the resource is chronologically before the specified value. expireAfter 0..1 The expirationTime attribute of the resource is chronologically after the specified value.
  • notificationEventType 0..6 The type of event that shall trigger a notification. If multiple notificationEventType tags are present, a notification shall be triggered if any of the configured events occur. Note that not all permutations of event type are meaningful.
  • Possible notification event type values are: A.Update to attributes of the subscribed-to resource B.Deletion of the subscribed-to resource, C.Creation of a direct child of the subscribed-to resource, D.Deletion of a direct child of the subscribed-to resource E.An attempt to retrieve a ⁇ contentInstance> direct-child-resource of a subscribed-to ⁇ container> ... ... attribute 0..n A list of attribute names of a subscribed-to-resource. This list is only applicable when notificationEventType has a value of "Update to attributes of the subscribed-to resource". or “”If this list is present, then it is used to specify a subset of a subscribed-to resource's attributes for which updates shall result in a notification.
  • ChildResourceType 0.. 1 (L) A list of resource types. This list is only applicable when notificationEventType has a value of "Creation of a direct child of the subscribed-to resource ". If this list is present, then it is used to specify a subset of resource type for direct child resource of which creation shall result in a notification. If ANY resource type specified on this list is created, then a notification shall be generated.
  • missingData 0..1
  • the missing Data includes two values: a minimum specified missing number of the Time Series Data within the specified window duration, and the window duration. The condition only applies to subscribed-to resources of type ⁇ timeSeries>.
  • the missing Data includes two values: a minimum specified missing number of the Time Series Data within the specified window duration, and the window duration. The condition only applies to subscribed-to resources of type ⁇ timeSeries>.
  • the first detected missing data point starts the timer associated with the window duration. The window duration is restarted upon its expiry until such time as the entire subscription is terminated or not refreshed.
  • filterOperation 0..1 Indicates the logical operation (AND/OR) to be used for the condition tags createdBefore, createdAfter, modifiedSince, unmodifiedSince, stateTagSmaller, stateTagBigger, expireBefore, expireAfter, sizeAbove, sizeBelow.
  • the default value is logical AND.
  • a vehicle consumable detection sensor and a gateway connected thereto may exist in a vehicle.
  • the state of consumables of the vehicle is monitored based on the subscription and notification operation, and notification may be performed based on a sensing value for the vehicle consumables.
  • the vehicle consumables may be auxiliary batteries, tires, and engine oil.
  • the same can be applied to other consumables, and is not limited to the above-described embodiment.
  • a subscription and a notification may be set based on an event in which a value sensed by a vehicle consumable detection sensor and a preset value are compared.
  • the vehicle consumables detection sensor may transmit information on the sensed value to the gateway.
  • the gateway may transmit a notification to the application when the sensing value does not satisfy a preset value.
  • a vehicle consumable detection sensor, a gateway, and an application may all exist in the vehicle.
  • subscriptions and notifications may occur based on events in the vehicle.
  • an application may be included in another device through a network, and is not limited to the above-described embodiment. That is, a notification may be transmitted to the subscriber based on the subscription and notification.
  • the gateway 1010 as an M2M entity may receive a subscription request from the application 1020 as an M2M entity.
  • the subscription may be a subscription to a vehicle consumable sensor-related resource as described above. (S1110)
  • the gateway 1010 may monitor a subscription condition for the vehicle consumable sensor. That is, the gateway 1010 may receive a sensing value from the vehicle consumable sensor periodically or at a specific time point.
  • the event may be a case in which the sensing value does not satisfy a preset value. For example, when the wear degree of the tire is measured as a value and is less than a preset value, it is determined that the wear is severe, and an event may be triggered.
  • the gateway 1010 may transmit a notification about the vehicle consumable sensor-related resource to the application 1020 based on the sensing value. Through this, the user of the application 1020 can check the replacement of vehicle consumables.
  • an incorrect notification may occur based on a sensing value error.
  • a sensing value error for example, in the case of a vehicle, a case in which a vehicle may be operated or exposed under severe conditions may be considered.
  • an error may occur temporarily in a specific sensor in the above-described environment. That is, an event may be triggered based on a sensing value error in a specific situation even though the replacement cycle has not been reached for the consumable.
  • the gateway may detect event triggering based on the above-described value and generate a notification based on the subscription. That is, when a notification occurs based on a temporary error, an incorrect notification may occur. That is, different from the intention of the subscriber creator, a notification may be made as a temporary subscription condition is satisfied. Accordingly, as described above, a method for minimizing unnecessary notification may be required, but the above-described subscription-related attribute or event notification criterion attribute may have a limit in preventing unnecessary notification in the above-described case.
  • the attribute for the number of times the event is satisfied may be defined.
  • the number of times the event is satisfied may be defined as attribute information for a subscription as shown in Table 4 or Table 5 below. That is, the event fulfillment count may be set in parallel with the event notification criterion attribute as one attribute information for a subscription.
  • the number of times the event is satisfied may be any one of event notification criterion attributes. That is, the number of times of meeting the event may be set as one of tag values of the event notification criterion attribute, and may be the same as Table 6 or Table 7.
  • This attribute indicates a case where the subscriber wants to receive notification only when event conditions are satisfied by a predetermined number within a predetermined time frame.
  • This attribute includes a predetermined number and a predetermined time frame.
  • Attributes of ⁇ subscription> Description nrOfmatchingCriteria This attribute indicates that the subscriber wants to receive anotification only when the event criteria are matched repeatedly upto predefined number within the specified timeframe. This attribute indicates the predefined number of iterations and the designated timeframe.
  • This attribute indicates a case where the subscriber wants to receive notification only when event conditions are satisfied by a predetermined number within a predetermined time frame.
  • This attribute includes a predetermined number and a predetermined time frame.
  • the number of times the above-described event is satisfied may minimize the occurrence of notification due to a temporary error. That is, the number of times the event is satisfied may be set so as not to be judged as a temporary error as a requirement of occurrence of notification.
  • the sensing value for the vehicle consumable sensor does not satisfy a preset value may be considered.
  • additional sensing may be required.
  • the additional sensing may be performed based on a predetermined time interval.
  • additional sensing may be continuously performed, and is not limited to the above-described embodiment.
  • the gateway may count a case in which the sensing value does not satisfy a preset value based on the number of times the event is satisfied. In this case, when the sensing value does not satisfy the preset value by more than the value set in the event fulfillment count, the above-described situation may not be a temporary error. Accordingly, the gateway can determine the replacement timing for the consumable and transmit the above-described notification.
  • the subscription resource may include an attribute for the event fulfillment period (ex, periodOfMathingCriteria) or may include an event fulfillment period (ex, periodOfMatchingCriteria) as one matching tag of the event notification criteria. have.
  • reset information may be additionally set in relation to the number of times the event is satisfied.
  • event criterion meeting count reset (nrOfmatchingCriteriaReset) information may be defined. More specifically, the number of times the event is met may be counted as described above. In this case, when the number of times of meeting the event is counted, the number of times of meeting the event may be continuously counted. As an example, when detecting a case in which the sensing value does not satisfy a preset value, the number of times that the event is satisfied may be reset and counted again. As another example, a reset for counting the number of times of meeting events based on probabilistic information or other information may also be set to a separate value.
  • the number of times of meeting the event may be continuously counted. For example, when detecting a case in which the sensing value does not satisfy a preset value as much as a value set in the event criterion meeting count reset (nrOfmatchingCriteriaReset), the event meeting count may be reset and counted again. That is, when a certain case is satisfied, the counting of the number of times the event is satisfied may be reset, and is not limited to the above-described embodiment.
  • priority (or order) for a plurality of subscription conditions may be set in relation to the above-described cross resource. More specifically, as described above, after receiving a notification based on a single resource from each sensor, the host may perform notification to the subscriber based on the notification. In this case, the cross resource may notify the subscriber when the above-described notifications occur based on the time window period. As an example, there is a need to set a priority (or order) for notifications in relation to notifications for cross resources. More specifically, when there are a plurality of notifications based on the cross resource, a priority order for a specific notification may be set.
  • notification may occur to a subscriber based on the first notification and the second notification based on the first subscription condition and the second subscription condition.
  • the first notification may have priority over the second notification. That is, when the second notification is detected after the first notification occurs, the final notification may be performed to the subscriber as described above.
  • the above-described time window may be started when the first notification occurs. Thereafter, upon receiving the second notification during a period corresponding to the size of the time window, a final notification may be transmitted to the subscriber based on the cross resource condition.
  • the time window may not start. That is, the first notification may take precedence over the second notification.
  • a vehicle speed violation prevention notification service may be considered.
  • the first subscription condition may be notification/notification occurrence according to discovery of a surveillance camera.
  • the second subscription condition may be notification/notification when the vehicle is driving at a speed greater than or equal to a threshold value.
  • a notification may be generated when the vehicle detects a speed greater than or equal to the threshold value after passing through the surveillance camera, but this may be unnecessary notification.
  • the time window may be set, and it is possible to determine whether to notify for a period corresponding to the size of the time window, and thus unnecessary notification may occur as described above. For example, a time window may be started based on a first subscription condition according to a speeding camera monitoring.
  • the vehicle may maintain a speed below the threshold value and pass through the camera.
  • the size of the time window may be larger than the time from when the first subscription condition is satisfied to when the camera passes. That is, even when the vehicle has passed the camera, the notification on the cross resource may be effective.
  • the host may notify the subscriber based on the cross resource. Therefore, as described above, since the camera has already passed through, unnecessary notification may occur.
  • the second subscription condition may be set to have priority over the first subscription condition. That is, even if the first subscription condition is satisfied, the time window may not start.
  • the time window may not start.
  • a time window may be started based on the second subscription condition.
  • the host may transmit a notification to the subscriber based on the cross resource.
  • priority (or order) according to the subscription conditions may exist. Through this, it is possible to prevent unnecessary notifications from occurring.
  • various settings may be possible in relation to the priority (or order). For example, three or more single resources may exist as a plurality of subscription conditions. In this case, as an example, the host may transmit the final notification to the subscriber based on the cross resource only when each subscription condition is detected based on a preset order.
  • a subscription condition for starting a time window is set, and the priority of other subscription conditions may be the same.
  • the first subscription condition may be a subscription condition for starting a time window. That is, the first subscription condition may have priority over the second subscription condition and the third subscription condition.
  • a final notification may be transmitted to the subscriber when the second subscription condition and the third subscription condition are satisfied during the time window size. That is, the priority is set as a specific subscription condition for starting the time window, and the other subscription conditions may have the same priority.
  • the above may be equally applied even when a plurality of subscription conditions are applied, and are not limited to the above-described embodiment.
  • the crossResourceSubscription resource may include an attribute (or function) capable of generating a cross-subscription notification in consideration of the satisfaction of the subscription condition for the target resource.
  • the corresponding attribute is a new attribute indicating a relationship before and after a subscription condition is satisfied with a crossResourceSubscription resource, and may be shown in Table 8 or Table 9 below.
  • "event notification criterion order (or priority)" may be added as a new attribute.
  • the order of the event notification criteria may be the order of the event notification criteria.
  • the order of event notification criteria may not be considered as in the past.
  • the attribute is a sequence of event notification criteria, and if the event notification criterion of the first order is not satisfied, the time window mechanism may not be applied, as described above.
  • attribute information may be set to “StartofTimeWindow”.
  • a time window start value may be set in relation to a resource that is a target of the cross resource.
  • the resource for the time window start may have the above-described time window start value set to “1”.
  • the above-described time window start value may be set to “0”.
  • priority when priority is set in the subscription condition based on the event notification criterion order, it may be indicated whether a subscription to a resource is a subscription starting a time window based on the above-described time window start value.
  • a new attribute for the event notification criterion is not defined, and information on the event notification criterion order may be included in the “eventNotificationCriteriaSet” as described above based on Table 10 or Table 11 below. have. That is, the above-described information can be added to the property information included in the resource for the existing cross-resource subscription, and through this, information on the event notification criterion order can be reflected without defining a new property. This may be the same as in FIGS. 12 and 13.
  • Event Notification CriteriaSet 0..1(L) RW
  • This property relates to cross-resource subscriptions and lists the event notification criteria for each regular target resource, as shown in the target regularResourcesAsTarget property. If there is one event notification criterion contained in this property, it will be applied to all target resources indicated by the target generic resource (regularResourcesAsTarget) property. If only the target subscription resource (subscriptionResourceAsTarget) property is present, then the eventNotificationCriteriaSet will not be needed. This attribute may contain an indication of the order of the eventNotificationCriteria.
  • the stipulated event notification criteria (eventNotificationCriteria) must be satisfied in the order in which the event notification criteria (eventNotificationCriteria) are specified so that the subscriber can be notified only when a number of event notification criteria (eventNotificationCriteria) are met in the prescribed order.
  • eventNotificationCriteriaSet 0..1(L) RW
  • This attribute lists eventNotificationCriteria for each regular target resource as indicated in regularResourcesAsTarget attribute and involved in a cross-resource subscription. If there is only one eventNotificationCriteria contained in this attribute, it shall be applied to all target resources as indicated by regularResourcesAsTarget attribute. If only subscriptionResourcesAsTarget attribute appears (ie no regularResourcesAsTarget attribute), eventNotificationCriteriaSet shall not be needed.
  • This attribute may include an indiation of a sequenceof eventNotificationCriteria. In this case, the specified eventNotificationCriteria should be satisfied in the given sequence so that the subscriber can get a notification only when mutipleeventNotificaionCriteria are met in the specified sequence.
  • “eventNotificationCriteriaorder or eventNotificationCriteriaSequence” may be newly added to the resource of the cross resource subscription as a property.
  • the order of the event notification criteria may be indicated as described above by modifying information included in the “eventNotificationCriteriaSet” as shown in FIG. 13, but is not limited to the above embodiment.
  • the maximum number of notifications may be set based on the “expirationCounter”, and when the number of notifications exceeds the maximum number of notifications, the subscription may be deleted.
  • a cross resource a plurality of subscriptions may exist, and a relationship between deletion of a target subscription and deletion of a cross subscription may be unclear.
  • cross-resource if the target subscription is deleted, it may not be possible to satisfy the condition. Accordingly, when the target subscription is deleted, a mechanism in which cross-subscription is deleted can be performed. In this case, as an example, a case in which a cross-subscription is generated when the target subscription is about to expire may be considered. At this time, the cross-subscription is created, but when the target subscription expires, the cross-subscription may be deleted by the target subscription. Accordingly, since the cross-subscription is deleted as soon as it is created, an meaningless operation may be performed. In consideration of the above points, there is a need to set an "expirationCounter" for cross-subscription.
  • the “expirationCounter” for the cross-subscription may be set as “crosssubexpirationCounter” as shown in Table 12 below. That is, as shown in Table 12 below, the maximum number of notifications for the cross resource may be set. In this case, when a notification failure occurs as much as the number of notifications for the cross resource exceeds the maximum number of notifications, the cross resource may be deleted regardless of other policies.
  • This attribute indicates that the subscriber wants to set the life of this cross resource subscription to a limit of a maximum number of notifications.
  • the ⁇ crossResourcesubscription> resource shall be deleted, regardless of any other policy.
  • cross-subscription may become meaningless when the target subscription is deleted.
  • the ⁇ crossResourceSubscription> resource if the number of previously issued notifications of the preceding subscription resource is close to the expirationCounter, the ⁇ crossResourceSubscription> resource is determined by the subscriber's intention and Alternatively, it may be deleted together due to deletion of the preceding subscription resource, especially shortly after the ⁇ crossResourceSubscription> resource is created. Therefore, when creating a cross-subscription, a policy for adjusting the “expirationCounter” of the target subscription may be required, which may be shown in Table 13 below. However, Table 13 is only an example, and may be set in other ways.
  • the “expirationCounter” of the target subscription may instruct that the cross subscription expiration counter is added to the target counter based on the cross subscription.
  • the expiration counter of the target subscription may not be updated.
  • the “expirationCounter” of the target subscription may be set based on a manual, and is not limited to the above-described embodiment. That is, the target subscription may be updated in consideration of the case in which the cross-subscription is set, and is not limited to the above-described embodiment.
  • the resource of the cross resource subscription may define an update policy for “expirationCounter”, which may be shown in Table 14 below.
  • ExpirationCounter a case in which a cross-subscription resource is generated may be considered in a state in which the expiractionCounter of the first preceding subscription resource is 10 times and the currentNotificationCounter is 8 times. In this case, if the crosssubexpiractionCounter of the cross-subscription resource is 5 times, the expirationCounter of the first preceding subscription resource may be updated to 15 times. Accordingly, it is possible to prevent the cross-subscription resource from being deleted or to operate meaninglessly according to the deletion of the first preceding subscription resource.
  • an expiration counter (expiractionCounter) update policy that increases the expiration counter (expiractionCounter) of the existing subscription by the cross-sub expiration counter (crosssubexpiractionCounter) of the cross-subscription may be provided, as shown in Table 14 or Table 15 below. Properties can be defined.
  • This attribute(or notification policy) indicates whether an existing subscription is updated when the subscriber creates crossResourceSubscription. If a value of the expirationCounterUpdate is "yes", an expiration counter of the existing subscription is added to the crosssubexpiratinCounter of the crossReosourceSubscription.
  • a problem in which the cross-subscription resource is deleted at the same time as the creation of the cross-subscription resource may be solved by resetting the current notification issue count (currentNotificaionCounter) of the existing subscription.
  • the current notification issue count may be reset and an expiration counter of an existing subscription may be changed to a crosssubexpirationCounter of a cross-subscription. That is, when a subscriber who creates a cross-subscription sets a previous subscription set before cross-subscription creation to be deleted depending on the cross-subscription, the above-described operation may be performed.
  • a subscriber who creates a cross-subscription may not want to receive a single notification according to a prior subscription at the present time. Therefore, when the cross-subscription is deleted, the preceding subscription is also dependent on the cross-subscription and can operate together.
  • a policy for an expiration counter update may be set differently. More specifically, when a cross resource is created, the number of notifications remaining up to the expiration counter (expiractionCounter) of the preceding subscription and the cross-sub expiration counter (crosssubexpirationCounter) of the cross subscription may be compared. At this time, if the number of notifications remaining up to the expiration counter of the preceding subscription (expiractionCounter) is less than the crosssubexpirationCounter of the cross-subscription, the crosssubexpirationCounter of the cross-subscription is added to the expirationCounter of the preceding subscription. Can be updated to increase.
  • the number of notifications remaining up to the expiration counter (expiractionCounter) of the preceding subscription is compared with the crosssubexpiration counter (crosssubexpirationCounter) of the cross-subscription. If an update is not necessary, the expiration counter (expirationCounter) can be prevented from being updated. It is not limited to the examples.
  • the operation of Table 16 below may be set to be performed in consideration of the relationship between the preceding subscription resource and the cross-subscription resource. More specifically, when a cross-subscription resource is created, it may be set to reset an expiration counter of a preceding subscription resource. In this case, in the case of the above-described operation, since an additional command or the like may not be required, the operation may be simple.
  • an expiration counter of a preceding subscription resource may be rewritten as an expirationCounter of a cross-subscription resource. That is, the expiration counter (expirationCounter) of the preceding subscription resource may be replaced by the expiration counter (expirationCounter) of the cross-subscription resource.
  • each case can be considered as follows.
  • the third value which is the expirationCounter value of the cross-subscription
  • the third value may be smaller than the expirationCounter value of the existing subscription. Accordingly, even if a cross-subscription is created, there may be no need to adjust the expirationCounter of the preceding subscription. However, when the number of current notifications of the preceding subscriptions is smaller than the expirationCounter of the cross-subscription, it may be necessary to reset the number of current notifications issued for the corresponding subscription.
  • the cross-subscription expiration counter (expirationCounter) and the preceding subscription expiration counter (expirationCounter) may be compared, and the cross-subscription expiration counter (expirationCounter) may be operated by comparing the current number of notifications issued by the preceding subscription.
  • the expiration counter of the cross-subscription may be larger than the expiration counter (expirationCounter) of the preceding subscription.
  • prior subscriptions are likely to be deleted based on an expiration counter (expirationCounter), and cross-subscriptions can be deleted as well.
  • an expiration counter readjustment attribute may be included.
  • the expiration counter readjustment attribute may be an attribute instructing to change the expiration counter (expirationCounter) of the preceding subscription.
  • the expiration counter (expirationCounter) of the preceding subscription may be instructed to rewrite the expiration counter (expirationCounter) of the preceding subscription to the expiration counter (expirationCounter) of the cross-subscription. That is, based on the above, it is possible to prevent an operation in which the cross-subscription is deleted or meaningless by the preceding subscription.
  • the expiration counter of the cross-subscription may be larger than the expiration counter (expirationCounter) of the specific preceding subscription and smaller than the expiration counter (expirationCounter) of other preceding subscriptions. Accordingly, when the first subscription is deleted as a specific preceding subscription, the cross-subscription may also be deleted. Accordingly, the above-described expiration counter readjustment attribute may be included when creating a cross-subscription resource so that the cross-subscription does not expire. At this time, based on the expiration counter readjustment attribute, the expiration counter of the first subscription (expirationCounter) may be rewritten as an expiration counter of the cross subscription (expirationCounter).
  • the number of current notifications may be reset.
  • the expiration counter of the preceding subscription and the number of current publication notifications may be adjusted in consideration of the expirationCounter of the cross-subscription. In this case, for example, as described above, it may be set to operate differently in consideration of each case.
  • the operation when a cross-subscription is generated, the operation may be performed regardless of the expirationCounter value of the preceding subscription.
  • the expiration counter of the preceding subscription (expirationCounter) may be rewritten as an expiration counter of the cross-subscription (expirationCounter) based on the above-described expiration counter readjustment attribute. That is, since the preceding subscription can be viewed as being dependent on the cross resource when the cross resource is created, it can be rewritten as an expiration counter of the cross subscription regardless of the existing expiration counter (expirationCounter).
  • it when a cross-subscription is created, it may be considered that a new resource has been created.
  • the number of current notification issuances of prior subscriptions needs to be counted anew. Accordingly, when a cross resource is generated, the current number of notification issuances of the preceding subscription may be reset without comparing the current number of notification issuances of the preceding subscription with the expirationCounter value of the cross-subscription.
  • FIG. 14 is a diagram showing the device configuration of the present invention.
  • a device 1100 may include a memory 1110, a processor 1120, a transceiver 1130, and a peripheral device 1140.
  • the device 1100 may further include other configurations, and is not limited to the above-described embodiment.
  • the device may be a device operating based on the above-described M2M system.
  • the device 1100 of FIG. 14 may be an exemplary hardware/software architecture of an M2M network node such as an M2M device, an M2M gateway, and an M2M server.
  • the memory 1110 may be a non-removable memory or a removable memory.
  • the peripheral device 1140 may include a display, GPS, or other peripheral devices, and is not limited to the above-described embodiment.
  • the device 1100 described above may be a node.
  • the node may include a communication circuit, such as the transmission/reception unit 1130, and may perform communication with an external device based on this.
  • the processor 1120 is a general-purpose processor, a digital signal processor (DSP), a DSP core, a controller, a microcontroller, ASICs (Application Specific Integrated Circuits), FPGA (Field Programmable Gate Array) circuits, and any other It may be at least one or more of one or more microprocessors associated with a tangible integrated circuit (IC) and state machine. That is, it may be a hardware/software configuration that performs a control role for controlling the device 1100 described above. In this case, the processor 1120 may execute computer-executable instructions stored in the memory 1110 to perform various essential functions of the node.
  • DSP digital signal processor
  • DSP digital signal processor
  • controller a microcontroller
  • ASICs Application Specific Integrated Circuits
  • FPGA Field Programmable Gate Array circuits
  • the processor 1120 may execute computer-executable instructions stored in the memory 1110 to perform various essential functions of the node.
  • the processor 1120 may control at least one of signal coding, data processing, power control, input/output processing, and communication operations. Also, the processor 1120 may control a physical layer, a MAC layer, and an application layer. In addition, as an example, the processor 1120 may perform authentication and security procedures in the access layer and/or the application layer, and the like, but is not limited to the above-described embodiment.
  • the processor 1120 may communicate with other devices through the transceiver 1130.
  • the processor 1120 may control a node to communicate with other nodes through a network through execution of computer-executable instructions. That is, the communication performed in the present invention can be controlled.
  • other nodes may be an M2M gateway, an M2M server, and other devices.
  • the transceiver 1130 may transmit an RF signal through an antenna, and may transmit a signal based on various communication networks.
  • MIMO technology, beamforming, and the like may be applied as an antenna technology, and are not limited to the above-described embodiment.
  • signals transmitted and received through the transceiver 1130 may be modulated and demodulated and controlled by the processor 1120, but is not limited to the above-described embodiment.
  • the 15 may be a device configuration for a device. Referring to FIG. 15, it may be controlled by a processor as described above.
  • memory and RAM, ROM, and network may be included.
  • other removable memories may be further included, and are not limited to the above-described embodiments.
  • the processor may perform a command based on information stored in the above-described memories and control the above-described operations of the present invention to be performed.
  • the processor may receive power by a power source or the like, and may receive input information or the like by peripheral devices, and is not limited to the above-described embodiment.
  • the device may acquire location information and related information based on GPS or the like.
  • the device may receive input information based on other input devices, and is not limited to the above-described embodiment.
  • embodiments of the present invention described above can be implemented through various means.
  • embodiments of the present invention may be implemented by hardware, firmware, software, or a combination thereof.
  • the present invention can be applied to various systems as well as oneM2M system.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

본 발명은 교차 리소스에 기초하여 호스트가 구독자에게 통지를 전송하는 방법을 제공할 수 있다. 이때, 통지를 전송하는 방법은 교차 리소스에 기초하여 복수 개의 구독 조건을 설정하는 단계, 복수 개의 구독 조건 각각을 만족하는 각각의 이벤트를 디텍트하는 단계 및 복수 개의 구독 조건이 모두 만족되는 경우, 교차 리소스에 대한 통지를 구독자에게 전송하는 단계를 포함할 수 있다. 이때, 복수 개의 구독 조건은 우선 순위를 가질 수 있다.

Description

구독 및 통지를 수행하는 방법 및 장치
본 발명은 시스템에서 구독 및 통지를 수행하는 방법 및 장치를 제공할 수 있다. 보다 상세하게는, M2M(Machine-to-Machine) 시스템에서 구독 및 통지를 수행하는 방법 및 장치에 대한 것이다.
최근 M2M(Machine-to-Machine) 시스템에 대한 도입이 활발해지고 있다. M2M 통신은 사람의 개입 없이 기계(Machine)와 기계 사이에 수행되는 통신을 의미할 수 있다. M2M은 MTC(Machine Type Communication), IoT(Internet of Things) 또는 D2D(Device-to-Device)를 지칭할 수 있다. 다만, 하기에서는 설명의 편의를 위해 M2M로 통일하게 지칭하지만, 이에 한정되지 않는다. M2M 통신에 사용되는 단말은 M2M 단말(M2M device)일 수 있다. M2M 단말은 일반적으로 적은 데이터를 전송하면서 낮은 이동성을 갖는 디바이스일 수 있다. 이때, M2M 단말은 기계 간 통신 정보를 중앙에서 저장하고 관리하는 M2M 서버와 연결되어 사용될 수 있다.
또한, M2M 단말은 사물 추적, 자동차 연동, 전력 계량 등과 같이 다양한 시스템에서 적용될 수 있다.
한편, M2M 단말과 관련하여, 다양한 표준화 기구에서 서비스 제공을 위한 방법을 제공하고 있다.
본 발명은 시스템에서 구독 및 통지를 수행하는 방법을 제공하는데 목적이 있다.
본 발명은 시스템에서 교차 구독에 기초하여 통지를 수행하는 방법을 제공하는데 목적이 있다.
본 발명은 시스템에서 교차 구독에 기초하여 복수 개의 구독에 대한 우선 순위를 설정하는 방법을 제공하는데 목적이 있다.
본 발명은 시스템에서 교차 구독의 만료 조건을 설정하는 방법을 제공하는데 목적이 있다.
본 발명의 일 실시예에 따르면, 교차 리소스에 기초하여 호스트가 구독자에게 통지를 전송하는 방법을 제공할 수 있다. 이때, 통지를 전송하는 방법은 교차 리소스에 기초하여 복수 개의 구독 조건을 설정하는 단계, 복수 개의 구독 조건 각각을 만족하는 각각의 이벤트를 디텍트하는 단계 및 복수 개의 구독 조건이 모두 만족되는 경우, 교차 리소스에 대한 통지를 구독자에게 전송하는 단계를 포함할 수 있다. 이때, 복수 개의 구독 조건은 우선 순위를 갖을 수 있다.
또한, 본 발명의 일 실시예에 따라, 교차 리소스에 기초하여 구독자에게 통지를 전송하는 호스트를 제공할 수 있다. 이때, 호스트는 신호를 송수신하는 송수신부, 송수신부를 제어하는 프로세서를 포함할 수 있다. 이때, 프로세서는 교차 리소스에 기초하여 복수 개의 구독 조건을 설정하고, 복수 개의 구독 조건 각각을 만족하는 각각의 이벤트를 디텍트하고, 복수 개의 구독 조건이 모두 만족되는 경우, 교차 리소스에 대한 통지를 구독자에게 전송하되, 복수 개의 구독 조건은 우선 순위를 갖을 수 있다.
또한, 본 발명의 일 실시예에 따라, 교차 리소스에 기초하여 구독자가 호스트로부터 통지를 수신하는 방법을 제공할 수 있다. 이때, 통지를 수신하는 방법은 복수 개의 구독 조건이 모두 만족되는 경우, 교차 리소스에 대한 통지를 호스트로부터 수신하는 단계, 수신한 통지에 기초하여 동작을 수행하는 단계를 포함할 수 있다. 이때, 호스트는 교차 리소스에 기초하여 복수 개의 구독 조건을 설정하고, 호스트가 복수 개의 구독 조건 각각을 만족하는 각각의 이벤트를 디텍트하면 구독자로 통지를 전송하되, 복수 개의 구독 조건은 우선 순위를 갖을 수 있다.
또한, 본 발명의 일 실시예에 따라, 교차 리소스에 기초하여 호스트로부터 통지를 수신하는 구독자를 제공할 수 있다. 이때, 구독자는 신호를 송수신하는 송수신부, 송수신부를 제어하는 프로세서를 포함할 수 있다. 이때, 프로세서는 복수 개의 구독 조건이 모두 만족되는 경우, 교차 리소스에 대한 통지를 호스트로부터 수신하고, 수신한 통지에 기초하여 동작을 수행할 수 있다. 이때, 호스트는 교차 리소스에 기초하여 복수 개의 구독 조건을 설정하고, 호스트가 복수 개의 구독 조건 각각을 만족하는 각각의 이벤트를 디텍트하면 구독자로 통지를 전송하되, 복수 개의 구독 조건은 우선 순위를 갖을 수 있다.
또한, 다음의 사항들은 통지를 전송하는 호스트 및 통지를 수신하는 구독자에 대해서 공통으로 적용될 수 있다.
본 발명의 일 실시예에 따라, 복수 개의 구독 조건 각각을 만족하는 각각의 이벤트가 타임 윈도우 내에 디텍트되는 경우에만 교차 리소스에 대한 통지를 구독자에게 전송할 수 있다.
이때, 본 발명의 일 실시예에 따라, 임 윈도우는 복수 개의 구독 조건 중 어느 하나의 구독 조건에 대한 이벤트가 감지되면 시작될 수 있다.
이때, 본 발명의 일 실시예에 따라, 복수 개의 구독 조건에 우선 순위가 설정된 경우, 복수 개의 구독 조건 중 우선 순위가 가장 높은 구독 조건에 대한 이벤트가 디텍트되는 경우에만 타임 윈도우가 시작될 수 있다.
이때, 본 발명의 일 실시예에 따라, 우선 순위가 가장 높은 구독 조건에 대한 이벤트가 디텍트되어 타임 윈도우가 시작된 경우, 타임 윈도우에 대응하는 시간 구간 동안 내에 복수 개의 구독 조건이 만족되면 교차 리소스에 대한 통지를 구독자에게 전송될 수 있다.
또한, 본 발명의 일 실시예에 따라, 호스트는 복수 개의 구독 조건 각각에 대한 단일 리소스를 각각의 M2M 엔티티에 요청하고, 각각의 M2M 엔티티들은 각각의 구독 조건에 기초하여 이벤트가 트리거링되면 단일 리소스에 기초하여 각각의 통지를 호스트로 전송할 수 있다.
이때, 본 발명의 일 실시예에 따라, 호스트가 타임 윈도우 내에 각각의 M2M 엔티티로부터 각각의 통지를 수신하는 경우, 호스트는 교차 리소스에 대한 통지를 구독자에게 전송할 수 있다.
이때, 본 발명의 일 실시예에 따라, 교차 리소스에 기초하여 복수 개의 구독 조건이 설정되는 경우, 교차 리소스에 대한 만료 카운터(expirationCounter)가 설정될 수 있다.
이때, 본 발명의 일 실시예에 따라, 복수 개의 구독 조건이 설정되기 전에 복수 개의 구독 조건 중 어느 하나 이상과 관련된 선행 구독이 존재하는 경우, 선행 구독에 대한 만료 카운터(expirationCounter)는 교차 리소스에 대한 만료 카운터에 기초하여 업데이트될 수 있다.
또한, 본 발명의 일 실시예에 따라, 선행 구독에 대한 만료 카운터는 교차 구독에 대한 만료 카운터로 재작성(Rewrite)될 수 있다.
이때, 본 발명의 일 실시예에 따라, 선행 구독에 대한 만료 카운터가 교차 구독에 대한 만료 카운터보다 작은 경우에만 교차 구독에 대한 만료 카운터로 재작성될 수 있다.
또한, 본 발명의 일 실시예에 따라, 선행 구독에 대한 만료 카운터가 교차 리소스에 대한 만료 카운터에 기초하여 업데이트되는 경우, 선행 구독에 대한 현재 통지 발행 수는 리셋될 수 있다.
이때, 본 발명의 일 실시예에 따라, 선행 구독에 대한 현재 통지 발행 수에 기초하여 남은 통지 수가 교차 리소소의 만료 카운터보다 작은 경우에만 선행 구독에 대한 현재 통지 발행 수가 리셋될 수 있다.
본 개시에 따르면, 시스템에서 구독 및 통지를 수행할 수 있다.
본 개시에 따르면, 시스템에서 교차 구독에 기초하여 통지를 수행할 수 있다.
본 개시에 따르면, 시스템에서 교차 구독에 기초하여 복수 개의 구독에 대한 우선 순위를 설정할 수 있다.
본 개시에 따르면, 시스템에서 교차 구독의 만료 조건을 설정할 수 있다.
본 개시에서 얻을 수 있는 효과는 이상에서 언급한 효과들로 제한되지 않으며, 언급하지 않은 또 다른 효과들은 아래의 기재로부터 본 개시가 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
도 1은 일 실시 예에 따른 M2M 시스템을 도시한다.
도 2는 일 실시 예에 따른 M2M 시스템의 계층 구조(layered structure)를 도시한다.
도 3은 일 실시 예에 따른 각 엔티티 간의 통신 흐름을 도시한다.
도 4는 일 실시 예에 따른 M2M 시스템의 구성을 도시한다.
도 5는 송신자와 수신자가 메시지를 교환하는 방법을 나타낸 도면이다.
도 6은 구독 리소스에 대한 속성 정보를 나타낸 도면이다.
도 7 및 도8은 교차 리소스에 기초하여 동작하는 방법을 나타낸 도면이다.
도 9는 교차 리소스 구독에 대한 속성 정보를 나타낸 도면이다.
도 10은 구독 및 통지 동작을 나타낸 도면이다.
도 11은 구독 및 통지 동작을 나타낸 도면이다.
도 12 및 도 13은 교차 리소스에 대한 만료 카운터 업데이트 방법을 나타낸 도면이다.
도 14는 디바이스 구성을 나타낸 도면이다.
도 15는 디바이스 구성을 나타낸 도면이다.
이하에서는 첨부한 도면을 참고로 하여 본 개시의 실시예에 대하여 본 개시가 속하는 기술 분야에서 통상의 지식을 가진 자가 용이하게 실시할 수 있도록 상세히 설명한다. 그러나, 본 개시는 여러 가지 상이한 형태로 구현될 수 있으며 여기에서 설명하는 실시예에 한정되지 않는다.
본 개시에 있어서, 제1, 제2 등의 용어는 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만 사용되며, 특별히 언급되지 않는 한 구성요소들간의 순서 또는 중요도 등을 한정하지 않는다. 따라서, 본 개시의 범위 내에서 일 실시예에서의 제1 구성요소는 다른 실시예에서 제2 구성요소라고 칭할 수도 있고, 마찬가지로 일 실시예에서의 제2 구성요소를 다른 실시예에서 제1 구성요소라고 칭할 수도 있다.
본 개시에 있어서, 어떤 구성요소가 다른 구성요소와 "연결", "결합" 또는 "접속"되어 있다고 할 때, 이는 직접적인 연결관계뿐만 아니라, 그 중간에 또 다른 구성요소가 존재하는 간접적인 연결관계도 포함할 수 있다. 또한 어떤 구성요소가 다른 구성요소를 "포함한다" 또는 "가진다"고 할 때, 이는 특별히 반대되는 기재가 없는 한 다른 구성요소를 배제하는 것이 아니라 또 다른 구성요소를 더 포함할 수 있는 것을 의미한다.
본 개시에 있어서, 서로 구별되는 구성요소들은 각각의 특징을 명확하게 설명하기 위함이며, 구성요소들이 반드시 분리되는 것을 의미하지는 않는다. 즉, 복수의 구성요소가 통합되어 하나의 하드웨어 또는 소프트웨어 단위로 이루어질 수도 있고, 하나의 구성요소가 분산되어 복수의 하드웨어 또는 소프트웨어 단위로 이루어질 수도 있다. 따라서, 별도로 언급하지 않더라도 이와 같이 통합된 또는 분산된 실시예도 본 개시의 범위에 포함된다.
본 개시에 있어서, 다양한 실시예에서 설명하는 구성요소들이 반드시 필수적인 구성요소들은 의미하는 것은 아니며, 일부는 선택적인 구성요소일 수 있다. 따라서, 일 실시예에서 설명하는 구성요소들의 부분집합으로 구성되는 실시예도 본 개시의 범위에 포함된다. 또한, 다양한 실시예에서 설명하는 구성요소들에 추가적으로 다른 구성요소를 포함하는 실시예도 본 개시의 범위에 포함된다.
본 개시의 실시예를 설명함에 있어서 공지 구성 또는 기능에 대한 구체적인 설명이 본 개시의 요지를 흐릴 수 있다고 판단되는 경우에는 그에 대한 상세한 설명은 생략한다. 그리고, 도면에서 본 개시에 대한 설명과 관계없는 부분은 생략하였으며, 유사한 부분에 대해서는 유사한 도면 부호를 붙였다.
또한, 일 예로, 본 발명에서 시스템이라 함은 IoT(Internet of Things)를 활용한 시스템, M2M(Machine To Machine)을 활용하는 시스템 등일 수 있다. 또한, 그 밖에도 본 발명에 기초한 동작이 적용되는 시스템에 대해서는 본 발명에서 지칭하는 시스템일 수 있으며, 상술한 실시예로 한정되지 않는다.
또한 본 명세서는 M2M 통신에 기초한 네트워크에 대해 설명하며, M2M 통신 네트워크에서 이루어지는 작업은 해당 통신 네트워크를 관할하는 시스템에서 네트워크를 제어하고 데이터를 송신하는 과정에서 이루어질 수 있다.
또한, 본 명세서에서 M2M 단말은 M2M 통신을 수행하는 단말일 수 있으나, 호환성(Backward Compatibility)을 고려하여 무선 통신 시스템에서 동작하는 단말일 수 있다. 즉, M2M 단말은 M2M 통신 네트워크에 기초하여 동작될 수 있는 단말을 의미할 수 있으나, M2M 통신 네트워크로 한정되는 것은 아니다. M2M 단말은 다른 무선 통신 네트워크에 기초하여 동작하는 것도 가능할 수 있으며, 상술한 실시예로 한정되지 않는다.
일 예로, M2M 통신에 사용되는 단말을 M2M 디바이스(M2M device)라고 지칭할 수 있다. 이때, M2M 디바이스는 일반적으로 낮은 이동성(low mobility), 시간 내성(time tolerant) 또는 지연 내성(delay tolerant), 작은 데이터 전송(small data transmission)등과 같은 특성을 가지며, 기계 간 통신 정보를 중앙에서 저장하고 관리하는 M2M 서버와 연결되어 사용될 수 있다. 또한, M2M 디바이스가 서로 다른 통신 방식에 따라 연결되면, 통신 방식이 변경되는 구간에서 M2M 게이트웨이를 통해 M2M 디바이스와 M2M 서버가 연결되며, 이를 통해 전체 M2M 시스템이 구성될 수 있다. 일 예로, 해당 시스템을 기반으로 교통분야 서비스 (예, 지능형 교통 시스템(ITS, Intelligent Transport System), 운송안전 서비스 등), 사물 추적(Tracking), 전력 계량(Metering), 자동 지불 시스템(Payment), 의료 분야 서비스, 원격 조정 등의 서비스가 제공될 수 있다.
본 발명에서, 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 fan out), 메시지를 집적(message aggregation)하는 기능을 수행할 수 있다. M2M 디바이스라는 용어는 M2M 게이트웨이와 M2M 서버를 포함하는 개념으로 사용될 수 있고, 따라서 M2M 게이트웨이와 M2M 서버는 M2M 디바이스로 지칭될 수 있다.
또한, 본 명세서에서 “엔티티(entity)”라는 용어는 M2M 디바이스, M2M 게이트웨이, M2M 서버와 같은 하드웨어를 지칭하는 데 사용될 수 있고, 또는 아래에서 설명되는 M2M 어플리케이션 계층과 M2M (공통) 서비스 계층의 소프트웨어 컴포넌트(software component)를 지칭하는 데 사용될 수 있다.
이하에서, 본 발명은 M2M 시스템을 중심으로 설명되지만 본 발명은 M2M 시스템에만 제한적으로 적용되는 것은 아니며, 예를 들어 클라이언트-서버(또는 송신자-응답자(sender-responder)) 모델에 따른 시스템에도 동일/유사하게 적용될 수 있다.
도 1은 일 실시 예에 따른 M2M 시스템을 도시한다.
M2M 시스템은 다양한 M2M 어플리케이션(Application)을 위한 공통 M2M 서비스 프레임워크(Service Framework)를 정의한다. M2M 어플리케이션(10)은 e헬스(e-Health), 도시 자동화(City Automation), 커넥티드 컨슈머(Connected Consumer), 오토모티브(Automotive)와 같은 M2M 서비스 솔루션을 구현하는 소프트웨어 컴포넌트(software component)를 지칭할 수 있다. M2M 시스템에서는 이러한 다양한 M2M 어플리케이션을 구현하기 위해 공통적으로 필요한 기능들을 제공되며, 공통적으로 필요한 기능들은 M2M 서비스 또는 M2M 공통 서비스라고 지칭될 수 있다. 이러한 M2M 공통 서비스를 이용하면 각 M2M 어플리케이션마다 기본 서비스 프레임워크를 다시 구성할 필요 없이 M2M 어플리케이션이 쉽게 구현될 수 있다.
M2M 서비스는 서비스 능력(Service Capability, SC; 20)의 집합 형태로 제공되며, M2M 어플리케이션(10)은 오픈 인터페이스(open interface)를 통해 SC(Service Capability)의 집합 또는 SC(Service Capability)에 접근하여 SC(Service Capability)가 제공하는 M2M 서비스 또는 기능을 이용할 수 있다. M2M 서비스 능력(20)은 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 시스템 아키텍처는 네트워크 도메인(10)과 디바이스 및 게이트웨이 도메인(20)으로 구분될 수 있다. 네트워크 도메인은 M2M 시스템 관리를 위한 기능(function) (11)들과 네트워크 관리를 위한 기능(function)(12)들을 포함할 수 있다. M2M 시스템 관리를 위한 기능은 디바이스 및 게이트웨이 도메인에 존재하는 디바이스들을 관리하는 M2M 어플리케이션과 M2M SCs(Service Capabilities)에 의해 수행될 수 있고, 네트워크 관리를 위한 기능은 코어 네트워크와 액세스 네트워크에 의해 수행될 수 있다. 따라서, 도 1의 예에서, 코어 네트워크(13)와 액세스 네트워크(14)는 M2M 기능을 수행한다기보다는 각 엔티티들 간의 연결을 제공할 수 있다. 코어 네트워크(13)와 액세스 네트워크(14)를 통해 네트워크 도메인(10)과 디바이스 및 게이트웨이 도메인(20)에서 M2M SCs(Service Capabilities) 간에 M2M 통신이 수행될 수 있으며, 각 도메인의 M2M 어플리케이션은 각 도메인의 M2M SCs(Service Capabilities)를 통해 신호 또는 정보를 주고 받을 수 있다.
액세스 네트워크(Access Network; 14)는 M2M 디바이스 및 게이트웨이 도메인이 코어 네트워크(13)와 통신을 가능하게 하는 엔티티이다. 액세스 네트워크(14)의 예로는 xDSL(Digital Subscriber Line), HFC(Hybrid Fiber Coax), 위성(satellite), GERAN, UTRAN, eUTRAN, 무선(Wireless) LAN, WiMAX 등이 있다.
코어 네트워크(Core Network); 13)는 IP(Internet Protocol) 연결, 서비스와 네트워크 제어, 상호연결, 로밍(roaming) 등의 기능을 제공하는 엔티티일 수 있다. 코어 네트워크(13)는 3GPP(3rd Generation Partnership Project) 코어 네트워크, ETSI TISPAN(Telecommunications and Internet converged Services and Protocols for Advanced Networking) 코어 네트워크와 3GPP2 코어 네트워크 등을 포함할 수 있다.
M2M SC(Service Capability) (15)는 여러 M2M 네트워크 어플리케이션들에서 공유될 수 있는 M2M 공통 서비스 기능 (Common Service Function, CSF)을 제공하고 M2M 서비스를 오픈 인터페이스(open interface)를 통해 노출하여 M2M 어플리케이션(16)들이 M2M 서비스를 이용할 수 있게 한다. M2M SCL(Service Capability Layer)은 이러한 M2M SC 엔티티들 또는 M2M 공통 서비스 기능들을 포함하는 계층을 지칭할 수 있다.
M2M 어플리케이션(16)은 서비스 로직(service logic)을 동작시키고, 오픈 인터페이스를 통해 M2M SCs(Service Capabilities)를 사용할 수 있는 엔티티이다. M2M 어플리케이션 계층은 이러한 M2M 어플리케이션 및 관련 동작 로직(operational logic)을 포함하는 계층을 지칭할 수 있다.
M2M 디바이스(21)는 M2M SCs(Service Capabilities)를 통해 M2M 디바이스 어플리케이션을 동작시키는 엔티티이다. M2M 디바이스(21)는 직접 네트워크 도메인의 M2M 서버와 통신할 수도 있으며, M2M 게이트웨이(22)를 통해서 네트워크 도메인의 M2M 서버와 통신할 수도 있다. M2M 게이트웨이(22)를 통해서 연결될 경우에는 M2M 게이트웨이(22)는 프록시(proxy)와 같이 동작한다. M2M 디바이스(21)는 M2M 어플리케이션 및/또는 M2M SCs(Service Capabilities)를 포함할 수 있다.
M2M 영역 네트워크(M2M area network) (23)는 M2M 디바이스와 M2M 게이트웨이 간의 연결(connectivity)을 제공한다. 이 경우, M2M 게이트웨이와 M2M 서버 간 네트워크와 M2M 디바이스와 M2M 게이트웨이 간 네트워크가 서로 상이할 수 있다. 일 예로, M2M 영역 네트워크는 IEEE 802.15.1, 지그비(Zigbee), 블루투스(Bluetooth), IETF ROLL, ISA100.11a와 같은 PAN(Personal Area Network) 기술과 PLC(Power Line Communication), M-BUS, 무선 M-BUS, KNX와 같은 로컬 네트워크 기술을 이용하여 구현될 수 있다.
M2M 게이트웨이(22)는 M2M SCs(Service Capabilities)를 통해 M2M 어플리케이션을 관리하고 M2M 어플리케이션에 대해 서비스를 제공하는 엔티티일 수 있다. M2M 게이트웨이(22)는 M2M 디바이스(21)와 네트워크 도메인(10)간의 프록시 역할을 수행하고 비-호환(non-compliant) M2M 디바이스에도 서비스를 제공하는 역할을 수행할 수 있다. M2M 게이트웨이(22)는 M2M 디바이스(21)들 중 게이트웨이 기능을 갖는 엔티티를 지칭할 수 있다. M2M 게이트웨이(22)는 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을 참조하면, 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/capabilities)들을 제공할 수 있다. 예를 들어, 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): 주어진 범위 및 조건 내에서 요청에 따라 정보 및 리소스([0054] 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는 송신자와 수신자가 메시지를 교환하는 방법을 나타낸 도면이다.
도 5를 참조하면, 송신자(Originator, 510)는 요청 메시지를 수신자(Receiver, 520)로 전송할 수 있다. 이때, 송신자(510)와 수신자(520)는 상술한 M2M 단말일 수 있다. 다만, M2M 단말에 한정되지 않고, 다른 단말도 가능할 수 있으며, 상술한 실시예로 한정되지 않는다. 또한, 일 예로, 송신자(510) 및 수신자(520)는 상술한 노드, 엔티티, 서버 또는 게이트웨이일 수 있다. 즉, 송신자(510) 및 수신자(520)는 하드웨어적인 구성 또는 소프트웨어적인 구성일 수 있으며, 상술한 실시예로 한정되지 않는다.
이때, 일 예로, 송신자(510)가 전송하는 요청 메시지에는 적어도 하나 이상의 파라미터가 포함될 수 있다. 이때, 일 예로, 파라미터는 필수 파라미터 또는 선택 파라미터가 있을 수 있다. 일 예로, 송신단과 관련된 파라미터, 수신단과 관련된 파라미터, 식별 파라미터 및 동작 파라미터 등은 필수적인 파라미터일 수 있다. 또한, 그 밖에 다른 정보에 대해서는 선택 파라미터일 수 있다. 이때, 송신단 관련 파라미터는 송신자(510)에 대한 파라미터일 수 있다. 또한, 수신단 관련 파라미터는 수신자(520)에 대한 파라미터일 수 있다. 또한, 식별 파라미터는 상호 간의 식별을 위해 요구되는 파라미터일 수 있다.
또한, 동작 파라미터는 동작을 구분하기 위한 파라미터일 수 있다. 일 예로, 동작 파라미터는 생성(Create), 조회(Retrieve), 갱신(Update), 삭제(Delete) 및 통지(Notify) 중 적어도 어느 하나로 설정될 수 있다. 즉, 동작을 구별하기 위한 파라미터일 수 있다.
이때, 수신자(520)는 송신자(510)로부터 요청 메시지를 수신하면 해당 요청 메시지를 처리할 수 있다. 일 예로, 수신자(520)는 요청 메시지에 포함된 동작을 수행할 수 있으며, 이를 위해 파라미터가 유효한지 여부 및 권한이 있는지 여부 등을 판단할 수 있다. 이때, 수신자(520)는 파라미터가 유효하고, 권한이 있다면 요청 대상이 되는 자원 존재하는지 여부를 확인하고, 이에 기초하여 프로세싱을 수행할 수 있다.
일 예로, 이벤트가 발생하는 경우, 송신자(510)는 수신자(520)에게 통지에 대한 파라미터를 포함하는 요청 메시지를 전송할 수 있다. 수신자(520)는 요청 메시지에 포함된 통지에 대한 파라미터를 확인하고, 이에 기초하여 동작을 수행할 수 있으며, 응답 메시지를 송신자(510)로 다시 전송할 수 있다.
하기 에서는 각각의 자원 및 자원의 속성에 대해 서술한다. 일 예로, 하기에서는 자원 또는 속성의 특징을 고려한 명칭으로 기재하지만, 이에 한정되지 않는다. 즉, 하기에서 서술하는 자원 또는 속성과 동일 또는 유사한 특징을 가진 자원 또는 속성에 대해서 본 발명과 동일하게 적용될 수 있다. 다만, 하기에서는 설명의 편의를 위해 특징을 고려한 특정 명칭으로 기재하고, 이를 중심으로 관련 내용을 서술한다. 다만, 이에 한정되는 것은 아니다.
도 6은 구독 자원에 대한 속성을 나타낸 도면이다.
도 6을 참조하면, 구독 자원은 속성들을 포함할 수 있다. 일 예로, 도 6에서는 구독 자원의 속성들을 기재하였으나, 이는 하나의 예시일 뿐, 추가, 삭제 또는 변경되는 것이 가능할 수 있다. 이때, 구독 자원에 대한 속성을 통해 구독-통지에 필요한 정보들이 공유될 수 있다. 또한, 일 예로, 구독-통지에 필요한 동작을 수행하기 위해 필요한 정보들이 속성 정보로서 정의될 수 있으며, 상술한 실시예로 한정되지 않는다. 일 예로, 구독 자원에는 “만료카운터(expirationCounter)”가 포함될 수 있으며, 이에 대해서는 후술한다.
한편, 일 예로, M2M 시스템에서 M2M 단말들은 구독-통지(subscription-Notification)에 기초하여 동작할 수 있다. 보다 상세하게는, M2M 플랫폼에서 구독(Subscription) 자원을 통해 이벤트를 등록하고, 해당 이벤트가 발생하면 통지(Notification) 메시지를 전달할 수 있다.
일 예로, 타겟 시스템(Target System)은 호스팅 시스템(Hosting System)으로 구독 자원을 할당하고, 호스팅 시스템은 이벤트가 발생하면 타겟 시스템으로 통지 메시지를 전달할 수 있다. 이때, 호스팅 시스템 및 타겟 시스템은 상술한 M2M 단말에 기초하여 동작하는 엔티티일 수 있다.
도 7은 리소스 통지 방법을 나타낸 도면이다. 일 예로, 도 7을 참조하면, M2M 엔티티로써 리소스 호스트(710)로 M2M 엔티티로써 구독자(720)는 구독을 요청할 수 있다. 이때, 일 예로, 도 7을 참조하면, 구독자(720)는 복수의 리소스들에 구독을 요청할 수 있다. 일 예로, 구독자(720)는 제 1 센서에 대한 구독 요청 및 제 2 센서에 대한 구독 요청을 리소스 호스트(710)로 각각 요청할 수 있다. 한편, 일 예로, 각각의 구독에 대한 통지는 구독자(720)가 아닌 다른 주체로 전송될 수 있다. 다만, 설명의 편의를 위해 하기에서는 구독자(720)가 통지를 수신하는 경우를 기준으로 서술하나 이에 한정되는 것은 아니다.
이때, 일 예로, 구독자(720)는 제 1 센서에 대한 구독 조건이 충족되면 호스트(710)로부터 제 1 센서에 대한 통지인 제 1 통지를 수신할 수 있다. 또한, 일 예로, 구독자(720)는 제 2 센서에 대한 구독 조건이 충족되면 호스트(720)로부터 제 2 센서에 대한 통지인 제 2 통지를 수신할 수 있다. 즉, 제 1 통지 및 제 2 통지는 각각의 구독 리소스에 기초하여 각각의 조건에 따라 통지될 수 있다. 다만, 일 예로, 제 1 통지 및 제 2 통지는 동일 이벤트와 관련된 통지일 수 있다. 일 예로, 이벤트는 화재 감지 이벤트이고, 제 1 통지 및 제 2 통지는 각각 온도 센서에 의한 통지 및 연기 센서에 대한 통지일 수 있다. 또한, 일 예로, 이벤트는 과속 통지 이벤트이고, 제 1 통지 및 제 2 통지는 감시 카메라 감지에 의한 통지 및 기설정된 속도 이상 값 초과에 대한 통지일 수 있다. 즉, 상술한 바처럼 제 1 통지 및 제 2 통지는 서로 관련된 이벤트에 대한 통지일 수 있다. 이때, 상술한 경우에 구독자(720)는 제 1 통지 및 제 2 통지를 분석하여 관심 이벤트에 대한 발생 여부를 결정할 수 있다. 즉, 구독자(720)는 각각의 통지에 기초하여 추가 동작에 기초하여 관심 이벤트에 대한 발생 여부를 확인할 수 있다.
이때, 일 예로, 도 8은 교차 리소스에 기초하여 동작하는 방법을 나타낸 도면이다. 상술한 바에 기초하여 동일한 관심 이벤트에 대한 구독은 교차 리소스에 기초하여 같이 처리될 수 있다. 보다 상세하게는, M2M 엔티티로써 호스트(e.g. IN-CSE, 750)는 M2M 엔티티로써 구독자(e.g. IN-AE, 760)로부터 교차 리소스 가입(또는 구독)을 위한 요청 메시지를 전송할 수 있다. 이때, 구독자(760)는 타겟 리소스들로써 복수 개의 리소스들의 변경에 기초하여 일정 기준 하에 단일 통지를 수신하고자 할 수 있다. 즉, 구독자(760)는 교차 리소스를 통해 복수 개의 리소스에 대한 조건 충족에 기초하여 단일 통지를 수신할 수 있다. 이때, 일 예로, 교차 리소스 요청에는 하기 표 1과 같은 정보들이 포함될 수 있다. 일 예로, 교차 리소스 요청에는 하기 속성 정보에 기초하여 “타겟 일반 리소스 (regularResourcesAsTarget)” 및 “타겟 구독 리소스 (subscriptionResourcesAsTarget)” 정보가 포함될 수 있다. 이때, 일 예로, 도 9를 참조하면, “타겟 일반 리소스(regularResourcesAsTarget)”는 교차 리소스 구독을 위해 사용될 수 있는 타겟 리소스에 대상이 될 수 있는 일반 리소스(regular resource)의 리스트 정보를 포함할 수 있다. 이때, 일반 리소스는 구독될 수 있는 oneM2M 리소스 중 적어도 어느 하나 이상을 포함할 수 있으며, 상술한 실시예로 한정되지 않는다. 또한, 일 예로, “타겟 구독 리소스 (subscriptionResourcesAsTarget)”는 실제 구독을 위해 존재하는 리소스를 의미할 수 있다. 즉, 교차 리소스 구독을 위해 사용되는 타겟 리소스로서 실제 구독 리소스를 의미할 수 있다. 즉, 통지 발생에 대상이 되는 타겟 리소스 정보를 포함할 수 있다. 또한, 일 예로, “시간 구간 타입(timeWindowType)”은 교차 리소스 구독을 위한 시간 구간에 대한 타입으로 오버래핑 없는 일정 구간을 지시하거나, 슬라이딩 타임 윈도우로서 교차 리소스 구독을 위한 타임 윈도우의 타입을 지시할 수 있다. 또한, “시간 구간 크기 (timeWindowSize)”는 타임 윈도우에 대한 크기를 지시할 수 있으며, 상술한 바에 한정되지 않는다.
Attributes of Multiplicity RW/RO/WO Description
notificationContentType 1 RW See clause 9.6.8
notificationEventCat 0..1 RW See clause 9.6.8
subscriberURI 0..1 RW See clause 9.6.8
regularResourcesAsTarget 0..1(L) RW This attribute indicates a list of regular resources (i.e. normal resources rather than <subscription> resources), which shall be used as the target resource for this cross-resource subscription. Here, the regular resource is referred to as any subscribable oneM2M resources.
subscriptionResourcesAsTarget 0..1(L) RW This attribute indicates a list of existing <subscription> resources, which shall be used as the target resource for this cross-resource subscription.
timeWindowType 1 RW This attribute indicates the type of time window mechanisms (e.g. timeWindowType=1 stands for periodic time window without any overlapping and timeWindowType=2 represents sliding time window where current time window will be slided to become next time window when a cross-resource notification is generated for instance) which will be used to determine the generation of a cross-resource notification.
timeWindowSize 1 RW This attribute indicates the size or time duration (e.g. in seconds) of the time window, based on which cross-resource notifications shall be generated. Note that the maximum window size (e.g. 60 seconds) may be enforced by the Hosting CSE for a subscriber; if the timeWindowSize indicated or requested by a subscriber is larger than the maximum window size, the Hosting CSE may reject the subscriber’
eventNotificationCriteriaSet 0..1(L) RW This attribute lists eventNotificationCriteria for each regular target resource as indicated in regularResourcesAsTarget attribute and involved in a cross-resource subscription. If there is only one eventNotificationCriteria contained in this attribute, it shall be applied to all target resources as indicated by regularResourcesAsTarget attribute. If only subscriptionResourcesAsTarget attribute appears (i.e. no regularResourcesAsTarget attribute), eventNotificationCriteriaSet shall not be needed. See clause 9.6.8 for the description of eventNotificationCriteria.
한편, 또 다른 일 예로, 교차 리소스의 경우, 복수 개의 통지가 모두 만족되어야지만 의미가 있을 수 있고, 하나의 리소스에 대한 통지를 수행할 수 없는 경우에는 전체 통지에 문제가 발생할 수 있다. 상술한 점을 고려하여, 호스트(750)는 단일 리소스에 대한 요청을 전송하는 경우에 교차 리소스에 대한 것임을 표시하여 각각의 M2M 엔티티들(730, 740)에게 전송할 수 있다. 이를 통해 각각의 M2M 엔티티들(730, 740)은 교차 리소스에 의한 단일 리소스 통지임을 인식할 수 있다. 이때, 일 예로, 각각의 M2M 엔티티들(730, 740)이 교차 리소스가 아님을 표시한 메시지를 수신한 경우, 각각의 M2M 엔티티들(730, 740)이 통지 불가 상태가 되면 통지 불가에 대한 메시지를 호스트(750)에게 전송할 수 있다. 반면, 일 예로, 각각의 M2M 엔티티들(730, 740)이 교차 리소스임을 표시한 메시지를 수신한 경우, 각각의 M2M 엔티티들(730, 740)은 통지 불가 상태가 되면 통지 불가에 대한 메시지를 호스트(750) 및 구독자(760)에게 전송할 수 있다. 즉, 교차 리소스인 점을 고려하여 각각의 M2M 엔티티들(730, 740)에서 통지 불가 상태가 된 경우, 교차 리소스 전체가 무의미할 수 있는바, 각각의 M2M 엔티티들(730, 740)은 구독자(760) 식별 정보에 기초하여 통지 불가 메시지를 구독자(760)에게도 전송할 수 있으며, 상술한 실시예로 한정되지 않는다.
또한, 일 예로, 각각의 M2M 엔티티들(730, 740)은 단일 리소스 구독 요청에 대한 응답 메시지를 호스트(750)에게 전송할 수 있다. (S774, S776) 즉, 각각의 M2M 엔티티들(730, 740)은 단일 리소스 구독에 대한 허여 여부를 결정하고, 이에 대한 응답을 호스트(750)에 전송할 수 있다. 그 후, 호스트(750)는 최종 응답을 구독자(760)에게 전송할 수 있다.
그 후, 각각의 M2M 엔티티들(730, 740)에서 타겟 리소스에 대한 이벤트가 발생할 수 있다.(S778, S780) 이때, 각각의 M2M 엔티티들(730, 740)은 각각 제 1 통지(S779) 및 제 2 통지(S781)를 호스트(750)에게 전송할 수 있다. 이때, 호스트(750)는 상술한 통지들을 버퍼링할 수 있다. 이때, 일 예로, 호스트(750)는 상술한 교차 리소스 속성 정보에 기초하여 제 1 통지 및 제 2 통지가 충족된 기준들과 일치하는지 여부를 판단할 수 있다. 호스트(750)는 시간 윈도우 메커니즘들을 수행하여 통지가 구독자(760)에게 전송되는지 여부를 결정할 수 있다. 일 예로, 제 1 통지 및 제 2 통지 모두 지정된 시간 윈도우 동안 수신된 경우, 호스트(750)는 통지를 생성하고, 이를 구독자(760)에게 전송할 수 있다.(S783) 일 예로, 호스트(750)는 정해진 시간 윈도우 크기 내에서 제1 통지 및 제2 통지의 발생 선후를 고려하여 통지가 구독자(760)로 전송될지 여부를 결정할 수 있으며, 이에 대해서는 후술한다. 즉, 교차 리소스 구독의 경우, 구독자(760)가 제1 센서 및 제2 센서에 대한 이벤트 충족 선후를 고려하여 교차 통지를 원할 경우 수행될 수 있다. 일 예로, 제1 센서에 대한 구독조건 충족이 먼저 수행되기를 원할 경우, 제2 센서에 대한 통지가 먼저 통지되더라도 시간 윈도우 매커니즘은 수행되지 않을 수 있다. 즉, 호스트(750)는 먼저 충족되어야하는 통지를 수신한 후에만 시간 윈도우 매커니즘을 시작할 수 있다. 또한, 일 예로, 호스트(750)가 구독자(760)에게 통지를 전송하는 경우, 통지 메시지는 단지 어플리케이션 의존이지만 미리 구성된 규칙에 기반하여 동작을 트리거링하기 위한 표시일 수 있다. 일 예로, 이벤트가 화재 감지인 경우, 호스트(750)는 센서에 명령을 전송하고, 화재 진압을 위한 분사를 수행할 수 있다. 즉, 호스트(750)는 통지 메시지에 기초하여 구독자(760)에게 통지를 전송함과 동시에 필요한 조치를 수행할 수 있다.
또한, 일 예로, 이벤트가 차량 감시인 경우, 호스트(750)는 제 1 센서 및 제 2 센서에 기초하여 차량 파손을 감지하면 구독자(760)에게 통지를 수행할 수 있다. 동시에, 호스트(750)는 기설정된 규칙에 기초하여 영상을 촬영하고, 촬영된 영상에 대한 정보를 저장할 수 있으며, 상술한 실시예로 한정되지 않는다.
상술한 바에 기초하여 리소스에 대한 구독 및 통지 또는 교차 리소스에 대한 구독 및 통지가 수행될 수 있다. 이때, 구독에 대한 속성 정보는 상술한 도 6과 같을 수 있으며, 구체적인 속성 정보는 하기 표 2와 같을 수 있다. 다만, 표 2는 구독 속성 정보의 일 예일 뿐, 다른 속성 정보가 설정될 수 있다. 즉, 구독 및 통지와 관련된 정보들이 속성 정보로서 설정될 수 있다. 이때, 일 예로, 학 표 2에서 해당 속성의 읽기(read)/쓰기(write) 허용여부(permission)에 대한 정보가 각각의 속성별로 표시될 수 있다. 일 예로, 상술한 정보는 “READ/WRITE(RW)”, “READ ONLY(RO)”, “WRITE ONLY(WO)” 중 하나일 수 있다. 또한, 일 예로, 표 2에서 발생횟수(multiplicity)는 해당 속성이 구독 리소스에서 발생 가능한 횟수를 나타낼 수 있다. 이때, 하기 표 2는 하나의 일 예일 뿐, 구독 리소스 속성으로서 다른 속성 정보가 더 설정될 수 있다.
Attributes of <subscription> Multiplicity RW/RO/WO Description
eventNotificationCriteria 0..1 RW This attribute (notification policy) indicates the event criteria for which a notification is to be generated. When no eventNotificationCriteria attribute is present in a <subscription> resource, the Hosting CSE shall trigger notifications for this subscription when any of the attributes of the subscribed-to resource is modified.
expirationCounter 0..1 RW This attribute (notification policy) indicates that the subscriber wants to set the life of this subscription to a limit of a maximum number of notifications. When the number of notifications sent reaches the count of this counter, the <subscription> resource shall be deleted, regardless of any other policy.
notificationURI 1 (L) RW This attribute shall be configured as a list consisting of one or more targets that the Hosting CSE shall send notifications to. A target shall be formatted as a oneM2M compliant Resource-ID as defined in clause 7.2 or as an identifier compliant with a oneM2M supported protocol binding (e.g. http, coap, mqtt).
... ...
subscriberURI 0..1 WO This attribute shall be configured with the target of the subscriber. The target is used by the Hosting CSE to determine where to send a notification when the subscription is deleted. A target shall be formatted as a oneM2M compliant Resource-ID as defined in clause 7.2 or as an identifier compliant with one of the oneM2M supported protocol bindings (the detailed format of which are defined by each respective oneM2M protocol binding specification).
associatedCrossResourceSub 0..1 RW This attribute lists the identifier of <crossResourceSubscription> resources where this <subscription> is involved in.
또한, 일 예로, 구독 및 통지와 관련하여 이벤트 통지 기준 속성(eventNotificationCriteria)은 구독 대상 리소스의 수정 및 변화 조건에 대한 리스트이며, 하기 표 3과 같을 수 있다. 다만, 하기 표 3도 이벤트 통지 기준 속성에 대한 일부 정보일 뿐 다른 정보들이 더 포함될 수 있다. 이때, 이벤트 통지 기준 속성 리스트의 각각의 조건들은 논리적 AND 관계에 있을 수 있다. 일 예로, 이벤트 통지 기준 속성이 2개의 조건을 포함하는 경우, 구독 대상 리소스의 수정/변화가 2개의 조건을 모두 만족하는 경우 통지가 전송될 수 있다. 즉, 상술한 바에 기초하여 구독 리소스에 이벤트 통지 기준 속성을 설정함으로써 통지 메시지의 양을 조절할 수 있다. 설정한 이벤트 통지 기준 속성을 만족하는 경우, 통지대상 엔티티(notification target entity)에게 통지가 전송되도록 하여 통지 메시지가 넘쳐나는 문제를 방지할 수 있다.
Condition tag Multiplicity Matching condition
createdBefore 0..1 The creationTime attribute of the resource is chronologically before the specified value.
createdAfter 0..1 The creationTime attribute of the resource is chronologically after the specified value.
modifiedSince 0..1 The lastModifiedTime attribute of the resource is chronologically after the specified value.
unmodifiedSince 0..1 The lastModifiedTime attribute of the resource is chronologically before the specified value.
stateTagSmaller 0..1 The stateTag attribute of the resource is smaller than the specified value.
stateTagBigger 0..1 The stateTag attribute of the resource is bigger than the specified value.
expireBefore 0..1 The expirationTime attribute of the resource is chronologically before the specified value.
expireAfter 0..1 The expirationTime attribute of the resource is chronologically after the specified value.
sizeAbove 0..1 The contentSize attribute of the <contentInstance> resource is equal to or greater than the specified value.
sizeBelow 0..1 The contentSize attribute of the <contentInstance> resource is smaller than the specified value.
notificationEventType 0..6 The type of event that shall trigger a notification. If multiple notificationEventType tags are present, a notification shall be triggered if any of the configured events occur. Note that not all permutations of event type are meaningful. Possible notification event type values are: A.Update to attributes of the subscribed-to resource B.Deletion of the subscribed-to resource, C.Creation of a direct child of the subscribed-to resource, D.Deletion of a direct child of the subscribed-to resource E.An attempt to retrieve a <contentInstance> direct-child-resource of a subscribed-to <container>
... ...
attribute 0..n A list of attribute names of a subscribed-to-resource. This list is only applicable when notificationEventType has a value of "Update to attributes of the subscribed-to resource". or “”If this list is present, then it is used to specify a subset of a subscribed-to resource's attributes for which updates shall result in a notification. If ANY attribute specified on this list is updated, then a notification shall be generated. If an attribute that is not specified in this list is updated, then a notification shall not be generated. If this list is not presented, then the default attribute list is the full set of a subscribed-to resource's attributes. If ANY attribute of a subscribed-to resource is updated, then a notification shall be generated.
childResourceType 0.. 1 (L) A list of resource types. This list is only applicable when notificationEventType has a value of "Creation of a direct child of the subscribed-to resource ". If this list is present, then it is used to specify a subset of resource type for direct child resource of which creation shall result in a notification. If ANY resource type specified on this list is created, then a notification shall be generated. If a resource type that is not specified in this list is created, then a notification shall not be generated. If this list is not present, then the default resource type list is the full set of a direct child resource.
missingData 0..1 The missingData includes two values: a minimum specified missing number of the Time Series Data within the specified window duration, and the window duration. The condition only applies to subscribed-to resources of type <timeSeries>. The missingData includes two values: a minimum specified missing number of the Time Series Data within the specified window duration, and the window duration. The condition only applies to subscribed-to resources of type <timeSeries>. The first detected missing data point starts the timer associated with the window duration. The window duration is restarted upon its expiry until such time as the entire subscription is terminated or not refreshed. More details about NOTIFICATIONS related to data reporting is found in section 10.2.39
filterOperation 0..1 Indicates the logical operation (AND/OR) to be used for the condition tags createdBefore, createdAfter, modifiedSince, unmodifiedSince, stateTagSmaller, stateTagBigger, expireBefore, expireAfter, sizeAbove, sizeBelow. The default value is logical AND.
한편, 일 예로, 구독 및 통지와 관련하여 상술한 바와 같이 통지 메시지가 전송되는 양을 제어할 필요성이 있다. 보다 상세하게는, 상술한 바처럼 일정한 조건에서만 통지 메시지가 전송되도록 하여 무분별하게 통지 메시지가 전송되는 것을 방지할 수 있다. 이때, 일 예로, 상술한 바에 기초하여 무분별한 통지를 막기 위해 이벤트 충족 횟수에 대한 정보가 필요할 수 있다. 일 예로, 도 10을 참조하면, 자동차 내에서는 차량 소모품 감지 센서 및 이와 연결된 게이트웨이가 존재할 수 있다. 이때, 구독 및 통지 동작에 기초하여 차량의 소모품 상태가 모니터링되고, 차량 소모품에 대한 센싱 값에 기초하여 통지가 수행될 수 있다. 일 예로, 차량 소모품은 보조 배터리, 타이어, 엔진 오일일 수 있다. 또한, 다른 소모품에 대해서도 동일하게 적용될 수 있으며, 상술한 실시예로 한정되지 않는다. 이때, 일 예로, 차량 소모품 감지 센서에 의해 센싱되는 값과 기설정된 값이 비교되는 이벤트에 기초하여 구독 및 통지가 설정될 수 있다. 이때, 차량 소모품 감지 센서는 센싱한 값에 대한 정보를 게이트웨이로 전송할 수 있다. 이때, 게이트웨이는 센서값을 판독한 후, 센싱값이 기설정된 값을 만족하지 못하는 경우, 어플리케이션으로 통지를 전송할 수 있다. 이때, 일 예로, 차량 내에 차량 소모품 감지 센서, 게이트웨이 및 어플리케이션이 모두 존재할 수 있다. 이를 통해 차량 내에서 이벤트에 기초하여 구독 및 통지가 발생할 수 있다. 또 다른 일 예로, 도 11을 참조하면, 어플리케이션은 네트워크를 통해 다른 장치에 포함될 수 있으며, 상술한 실시예로 한정되지 않는다. 즉, 구독 및 통지에 기초하여 구독자에게 통지가 전송될 수 있다.
보다 구체적인 동작과 관련하여, M2M 엔티티로써 게이트웨이(1010)는 M2M 엔티티로써 어플리케이션(1020)으로부터 구독 요청을 수신할 수 있다. 이때, 일 예로, 구독은 상술한 바와 같이 차량 소모품 센서 관련 리소스에 대한 구독일 수 있다. (S1110) 그 후, 게이트웨이(1010)는 차량 소모품 센서에 대한 구독 조건을 모니터링할 수 있다. 즉, 게이트웨이(1010)는 차량 소모품 센서로부터 센싱 값을 주기적 또는 특정 시점에 전달 받을 수 있다. 이때, 이벤트는 센싱 값이 기설정된 값을 만족하지 못하는 경우일 수 있다. 일 예로, 타이어의 마모도가 값으로 측정되고 기설정된 값보다 작은 경우에 마모가 심해진 것으로 판단하여 이벤트가 트리거링될 수 있다. 이때, 게이트웨이(1010)는 센싱값에 기초하여 차량 소모품 센서 관련 리소스에 대한 통지를 어플리케이션(1020)으로 전송할 수 있다. 이를 통해, 어플리케이션(1020) 사용자는 차량 소모품 교체를 확인할 수 있다.
이때, 일 예로, 상술한 경우에 관련하여, 센싱값 오류에 기초하여 부정확한 통지가 발생할 수 있다. 일 예로, 차량의 경우 가혹한 조건에서 운행되거나 노출될 수 있는 경우를 고려할 수 있다. 이때, 상술한 환경에서 특정 센서에 일시적으로 오류가 발생할 수 있다. 즉, 소모품에 대해 교체 주기가 도달되지 않았음에도 특정 상황에서 센싱값 오류에 기초하여 이벤트가 트리거될 수 있다.
일 예로, 엔진오일 상태를 모니터링하는 센서의 경우, 극저온 또는 극고온 상태에서 엔진오일의 상태 모니터링 값에 영향을 미칠 수 있다. 이때, 구독 조건에 기초하여 정상상태에 있음에도 극한의 조건에서 이상 상태에 있는 것처럼 센서값이 검출될 수 있다. 이때, 게이트웨이는 상술한 값에 기초하여 이벤트 트리거링을 감지하고 구독에 기초하여 통지를 발생시킬 수 있다. 즉, 일시적인 오류에 기초하여 통지가 발생하는 경우에 부정확한 통지가 발생할 수 있다. 즉, 구독 생성자의 의도와 다르게 일시적인 구독조건 충족으로 통지를 될 수 있다. 따라서, 상술한 바와 같이 불필요한 통지를 최소화하기 위한 방안이 필요할 수 있으나, 상술한 구독 관련 속성이나, 이벤트 통지 기준 속성은 상술한 경우에 불필요한 통지를 방지하기에 한계가 있을 수 있다.
상술한 바에 기초하여 이벤트 충족 횟수에 대한 속성이 정의될 수 있다. 일 예로, 이벤트 충족 횟수는 하기 표 4 또는 표 5와 같이 구독에 대한 속성 정보로서 정의될 수 있다. 즉, 이벤트 충족 횟수는 구독에 대한 하나의 속성 정보로서 이벤트 통지 기준 속성과 병렬적으로 설정될 수 있다. 또한, 일 예로, 이벤트 충족 횟수는 이벤트 통지 기준 속성 중 어느 하나일 수 있다. 즉, 이벤트 충족 횟수는 이벤트 통지 기준 속성의 태그(tag) 값 중 하나로서 설정될 수 있으며, 표 6 또는 표7과 같을 수 있다.
<subscription>속성 설명
이벤트기준충족횟수(nrOfmatchingCriteria) 본 속성은 정해진 타임 프레임내에 이벤트 조건이 미리 정해진 수로 만족하는 경우에만 구독자가 통지를 받고 싶은 경우를 나타낸다. 이 속성은 미리 정해진 수 및 미리 정해진 타임 프레임을 포함한다.
Attributes of <subscription> Description
nrOfmatchingCriteria This attribute indicates that the subscriber wants to receive anotification only when the event criteria are matched repeatedly upto predefined number within the specified timeframe. This attribute indicates the predefined number of iterations and the designated timeframe.
조건태그(Condition tag) 발생횟수(Multiplicity) Matching condition
이벤트기준충족횟수(nrOfmatchingCriteria) 0..1 본 속성은 정해진 타임 프레임내에 이벤트 조건이 미리 정해진 수로 만족하는 경우에만 구독자가 통지를 받고 싶은 경우를 나타낸다. 이 속성은 미리 정해진 수 및 미리 정해진 타임 프레임을 포함한다.
Condition tag Multiplicity Matching condition
nrOfmatchingCriteria 0..1 This tag indicates that the subscriber wants to receive a notification only when the event criteria are matched repeatedly upto predefined number within the specified timeframe. This tag indicates the predefined number of iterations and the designated timeframe.
이때, 일 예로, 상술한 이벤트 충족 횟수는 일시적 오류로 인한 통지 발생을 최소화할 수 있다. 즉, 통지 발생의 요건으로 일시적 오류로 판단되지 않도록 이벤트 충족 횟수가 설정될 수 있다. 이때, 상술한 경우를 고려하면 차량 소모품 센서에 대한 센싱 값이 기설정된 값을 만족하지 못하는 경우를 고려할 수 있다. 다만, 상술한 바처럼 일시적 오류일 수 있는바, 추가 센싱이 필요할 수 있다. 이때, 일 예로, 추가 센싱은 일정한 시간 간격에 기초하여 수행될 수 있다. 또한, 일 예로, 추가 센싱은 연속적으로 수행될 수 있으며, 상술한 실시예로 한정되지 않는다. 이때, 게이트웨이는 상술한 이벤트 충족 횟수에 기초하여 센싱 값이 기설정된 값을 만족하지 못하는 경우를 카운팅할 수 있다. 이때, 이벤트 충족 횟수에 설정된 값 이상으로 센싱 값이 기설정된 값을 만족하지 못하는 경우에 상술한 상황은 일시적인 오류가 아닐 수 있다. 따라서, 게이트웨이는 소모품에 대한 교체 시기를 판단하고, 상술한 통지를 전송할 수 있다.
또한, 구독자는 이벤트 조건을 특정 기간 동안 유지되는 경우에만 통지를 받고 싶을 수 있다. 오히려, 구독자는 특정조건이 계속 유지되는 것을 전제로 하고 있을 수 있다. 일 예로, 상술한 바를 고려하여 구독 리소스는 이벤트 충족 기간에 대한 속성(ex, periodOfMathingCriteria)을 포함하거나 이벤트 통지 기준의 하나의 매칭 태그(matching tag)로서 이벤트 충족 기간(ex, periodOfMatchingCriteria)을 포함할 수 있다.
한편, 일 예로, 이벤트 충족 횟수와 관련해서는 리셋 정보가 추가로 설정될 수 있다. 일 예로, 이벤트기준충족횟수리셋 (nrOfmatchingCriteriaReset) 정보가 정의될 수 있다. 보다 상세하게는, 이벤트 충족 횟수는 상술한 바와 같이 카운팅될 수 있다. 이때, 이벤트 충족 횟수가 카운팅되는 경우에 있어서 연속적으로 이벤트 충족 횟수가 카운팅될 수 있다. 일 예로, 센싱값이 기설정된 값을 만족하지 않는 경우를 디텍트하면 이벤트 충족 횟수를 리셋하고, 다시 카운팅할 수 있다. 또 다른 일 예로, 확률적인 정보 또는 다른 정보에 기초하여 이벤트 충족 횟수 카운팅에 대한 리셋도 별도의 값으로 설정될 수 있다. 즉, 이벤트 충족 횟수가 카운팅되는 경우에 있어서 연속적으로 이벤트 충족 횟수가 카운팅될 수 있다. 일 예로, 센싱값이 기설정된 값을 만족하지 않는 경우를 이벤트기준충족횟수리셋 (nrOfmatchingCriteriaReset)에 설정된 값만큼 디텍트할 때, 이벤트 충족 횟수를 리셋하고, 다시 카운팅할 수 있다. 즉, 일정한 경우를 만족하는 경우에 이벤트 충족 횟수에 대한 카운팅이 리셋될 수 있으며, 상술한 실시예로 한정되지 않는다.
또한, 일 예로, 상술한 교차 리소스와 관련하여 복수의 구독 조건에 대한 우선 순위(또는 순서)가 설정될 수 있다. 보다 상세하게는, 상술한 바에서 호스트는 각각의 센서로부터 단일 리소스에 기초하여 통지를 수신한 후, 이에 기초하여 구독자에게 통지를 수행할 수 있다. 이때, 교차 리소스는 타임 윈도우 구간에 기초하여 상술한 통지들이 발생한 경우에 구독자에게 통지를 수행할 수 있다. 일 예로, 교차 리소스에 대한 통지와 관련하여 통지에 대한 우선 순위(또는 순서)가 설정될 필요성이 있다. 보다 상세하게는, 교차 리소스에 기초하여 복수 개의 통지가 존재하는 경우, 특정 통지에 대한 우선 순위가 설정될 수 있다. 일 예로, 복수 개의 통지로서 제 1 구독 조건 및 제 2 구독 조건에 기초하여 제 1 통지 및 제 2 통지에 기초하여 구독자로 통지가 발생할 수 있다. 이때, 일 예로, 제 1 통지가 제 2 통지보다 우선할 수 있다. 즉, 제 1 통지가 발생한 후에 제 2 통지를 디텍트 한 경우에 상술한 바와 같이 구독자에게 최종 통지를 수행할 수 있다. 일 예로, 상술한 타임 윈도우는 제 1 통지가 발생하면 시작될 수 있다. 그 후, 타임 윈도우 크기에 해당하는 기간 동안 제 2 통지를 수신하면 교차 리소스 조건에 기초하여 최종 통지가 구독자에게 전송될 수 있다. 반면, 제 2 통지가 제 1 통지보다 먼저 발생한 경우, 타임 윈도우는 시작되지 않을 수 있다. 즉, 제 1 통지가 제 2 통지보다 우선할 수 있다. 구체적인 일 예로, 차량 차속 위반 방지 통지 서비스를 고려할 수 있다. 이때, 일 예로, 제 1 구독 조건은 감시 카메라 발견에 따른 통지/알림 발생일 수 있다. 또한, 제 2 구독 조건은 차량이 임계값 이상의 속도 운행시 통지/알림 발생일 수 있다. 이때, 차량이 감시 카메라를 통과한 이후에 임계값 이상의 속도를 감지한 경우에 통지가 발생할 수 있으나, 이는 불필요한 통지일 수 있다. 다만, 상술한 바처럼 타임 윈도우가 설정될 수 있고, 타임 윈도우 크기에 대응되는 기간만큼 통지 여부를 판단할 수 있는바, 상술한 바와 같이 불필요한 통지가 발생할 수 있다. 일 예로, 과속 카메라 감시에 따른 제 1 구독 조건에 기초하여 타임 윈도우가 시작될 수 있다. 이때, 차량은 임계값 이하의 속도를 유지하고, 카메라를 통과할 수 있다. 다만, 타임 윈도우의 크기는 제 1 구독 조건 만족 시점부터 카메라 통과 시점까지보다 클 수 있다. 즉, 차량이 카메라를 통과하였음에도 교차 리소스에 대한 통지가 유효할 수 있다. 이때, 차량이 카메라 통과 후 임계값 이상의 속도로 주행하는 경우, 교차 리소스에 기초하여 호스트는 구독자에게 통지를 수행할 수 있다. 따라서, 상술한 바와 같이, 이미 카메라 통과 상태인바, 불필요한 통지가 발생할 수 있다. 상술한 점을 고려하여 제 2 구독 조건이 제 1 구독 조건보다 우선하도록 설정할 수 있다. 즉, 제 1 구독 조건을 만족하여도 타임 윈도우가 시작되지 않을 수 있다. 일 예로, 차량이 카메라를 감지하더라도 타임 윈도우가 시작되지 않을 수 있다. 반면, 차량이 임계값 이상의 속도로 주행하는 경우, 제 2 구독 조건에 기초하여 타임 윈도우가 시작될 수 있다. 이때, 감시 카메라에 따른 제 1 구독 조건을 만족하는 경우, 호스트는 교차 리소스에 기초하여 구독자에게 통지를 전송할 수 있다.
즉, 상술한 경우처럼 복수 개의 구독 조건이 존재하는 경우에는 구독 조건에 따른 우선 순위(또는 순서)가 존재할 수 있다. 이를 통해, 불필요한 통지 발생을 방지할 수 있다. 한편 , 우선 순위(또는 순서)와 관련하여 다양한 설정이 가능할 수 있다. 일 예로, 복수 개의 구독 조건으로서 세 개 이상이 단일 리소스가 존재할 수 있다. 이때, 일 예로, 각각의 구독 조건이 기설정된 순서에 기초하여 디텍트되는 경우에만 호스트가 교차 리소스에 기초하여 구독자에게 최종 통지를 전송할 수 있다.
또 다른 일 예로, 우선 순위와 관련하여, 타임 윈도우를 시작하는 구독 조건만이 설정되고, 다른 구독 조건의 우선 순위는 동등할 수 있다. 일 예로, 제 1 구독 조건, 제 2 구독 조건 및 제 3 구독 조건이 존재하는 경우에 있어서, 제 1 구독 조건만이 타임 윈도우를 시작하기 위한 구독 조건일 수 있다. 즉, 제 1 구독 조건이 제 2 구독 조건 및 제 3 구독 조건보다 우선할 수 있다. 이때, 제 1 구독 조건이 만족되어 타임 윈도우가 시작되는 경우, 타임 윈도우 크기 동안 제 2 구독 조건 및 제 3 구독 조건이 만족되면 구독자에게 최종 통지가 전송될 수 있다. 즉, 우선 순위는 타임 윈도우를 시작하기 위한 특정 구독 조건으로 설정되고, 다른 구독 조건에 대해서는 동일한 우선 순위를 가지도록 할 수 있다. 일 예로, 상술한 바는 복수 개의 구독 조건이 적용되는 경우에도 동일하게 적용될 수 있으며, 상술한 실시예로 한정되지 않는다.
이때, 일 예로, 상술한 바에 기초하여 교차리소스구독 (crossResourceSubscription) 리소스는 타겟 리소스에 대한 구독 조건의 충족 선후를 고려하여 교차 구독 통지를 발생시킬 수 있는 속성(또는 기능)을 포함할 수 있다. 일 예로, 해당 속성은 교차리소스구독 (crossResourceSubscription) 리소스에 구독 조건의 충족 선후 관계를 나타내는 신규 속성으로 하기 표 8 또는 표 9와 같을 수 있다. 일 예로, 신규 속성으로 “이벤트 통지 기준 순서(또는 우선순위)”를 추가할 수 있다. 이때, 하기 표 8에 기초하여 이벤트 통지 기준 순서는 이벤트 통지 기준에 대한 순서일 수 있다. 이때, 하기 속성이 존재하지 않는 경우에는 기존과 동일하게 이벤트 통지 기준의 순서를 고려하지 않을 수 있다. 반면, 해당 속성이 포함되는 경우, 해당 속성은 이벤트 통지 기준의 순서로서 첫 번째 순서의 이벤트 통지 기준을 충족하지 않은 경우 타임 윈도우 메커니즘이 적용되지 않을 수 있으며, 이는 상술한 바와 같다.
<crossResourceSubscription>속성 발생 횟수(Multiplicity) RW/RO/WO 설명(Description)
이벤트통지기준발생순서(eventNotificationCriteriaOrderor eventNotificaionCriteriaSequence) 0..1(L) RW 본 속성은 이벤트 통지 기준의 순서를 나타낸다. 본 속성이 없거나 그 값이 없는 경우, 이벤트 통지 기준의 순서는 고려하지 않을 것이다. 본 속성은 이벤트 통지 기준의 순서를 포함하고 있는 경우, 첫번째 순서의 이벤트 통지 기준을 충족하지 않는 경우 시간 구간(timeWindow) 매커니즘은 적용되지 않을 것이다.
Attributes of <crossResourceSubscription> Multiplicity RW/RO/WO Description
eventNotificationCriteriaOrderor eventNotificaionCriteriaSequence 0..1(L) RW This attribute indicates event notification criteria order(or sequence). If this attribute is not present or a value of this attribute is not present, it shall be not applied event notification criteria order (or sequence)If this attribute includes event notification criteria order (or sequence), time window mechanism is not applied when a first order (or sequence) of event notification criteria is not satisfied
또한, 일 예로, 첫 번째 순서의 이벤트 통지 기준으로서 타임 윈도우 메커니즘을 시작하는 구독 조건임을 고려하여 속성 정보가 “타임 윈도우 시작 (StartofTimeWindow)”로 설정될 수 있다. 일 예로, 교차 리소스의 대상이 되는 리소스와 관련하여 타임 윈도우 시작 값이 설정될 수 있다. 일 예로, 교차 리소스에 포함된 복수 개의 리소스 중 타임 윈도우 시작에 대한 리소스는 상술한 타임 윈도우 시작 값이 “1”로 설정될 수 있다. 반면, 다른 리소스들에 대해서는 상술한 타임 윈도우 시작 값이 “0”으로 설정될 수 있다. 일 예로, 이벤트 통지 기준 순서에 기초하여 구독 조건에 우선 순위가 설정된 경우, 상술한 타임 윈도우 시작 값에 기초하여 어느 리소스에 대한 구독이 타임 윈도우를 시작하는 구독인지 여부를 지시할 수 있다.
또 다른 일 예로, 이벤트 통지 기준에 대한 새로운 속성이 정의되지 않고, 하기 표 10 또는 표 11에 기초하여 상술한 바와 같이 이벤트 통지 기준 순서에 대한 정보가 “이벤트 통지 기준 셋(eventNotificationCriteriaSet)”에 포함될 수 있다. 즉, 기존의 교차 리소스 구독에 대한 리소스에 포함된 속성 정보에 상술한 바와 같은 정보를 더 추가할 수 있으며, 이를 통해 새로운 속성을 정의하지 않고, 이벤트 통지 기준 순서에 대한 정보를 반영할 수 있으며, 이는 도 12 및 도 13와 같을 수 있다.
<crossResourceSubscription>속성 발생횟수 RW/RO/WO 설명 (Description)
이벤트통지기준셋(eventNotificationCriteriaSet) 0..1(L) RW 본속성은교차-리소스구독과관련되고타겟일반리소스 (regularResourcesAsTarget)속성에나타난것치럼각레귤러타겟리소스를위한이벤트통지기준을리스트한다. 만약이속성에포함된하나의이벤트통지기준에있다면, 타겟일반리소스 (regularResourcesAsTarget)속성에의해나타낸모든타겟리소스에적용될것이다. 만약타겟구독리소스 (subscriptionResourceAsTarget)속성만나타난경우, 이벤트통지기준셋 (eventNotificationCriteriaSet)은필요하지않을것이다. 본속성은이벤트통지기준 (eventNotificationCriteria)의순서에대한표시를포함할수있다. 이경우, 규정된이벤트통지기준(eventNotificationCriteria)은구독자가다수의이벤트통지기준(eventNotificationCriteria)가규정된순서로충족되는경우에만통지를받을수있도록규정된이벤트통지기준(eventNotificationCriteria)가주어진순서로만족되어야한다.
Attributes of <crossResourceSubscription> Multiplicity RW/RO/WO Description
eventNotificationCriteriaSet 0..1(L) RW This attribute lists eventNotificationCriteria for each regular target resource as indicated in regularResourcesAsTarget attribute and involved in a cross-resource subscription. If there is only one eventNotificationCriteria contained in this attribute, it shall be applied to all target resources as indicated by regularResourcesAsTargetattribute. If only subscriptionResourcesAsTarget attribute appears (i.e. no regularResourcesAsTarget attribute), eventNotificationCriteriaSet shall not be needed. This attribute may include an indiation of a sequenceofeventNotificationCriteria. In this case, the specified eventNotificationCriteria should be satisfied in the given sequence so that the subscriber can get a notification only when mutipleeventNotificaionCriteria are met in the specified sequence.
일 예로, 도 12는 상술한 바와 같이, “이벤트통지기준발생순서 (eventNotificationCriteriaorder or eventNotificationCriteriaSequence)”이 교차 리소스 구독의 리소스에 새롭게 속성으로 추가될 수 있다. 또 다른 일 예로, 도 13과 같이 “이벤트 통지 기준 셋 (eventNotificationCriteriaSet)”에 포함된 정보를 수정하여 상술한 바와 같이 이벤트 통지 기준의 순서를 지시할 수 있으며, 상술한 실시예로 한정되지 않는다.
또한, 일 예로, 상술한 구독 자원에 대한 속성으로서 표 2의 “만료 카운터 (expirationCounter)”에 대한 정보가 교차 리소스에 설정될 필요성이 있다. 보다 상세하게는, 상술한 표 2를 참조하면, “만료 카운터 (expirationCounter)”에 기초하여 최대 통지 횟수가 설정될 수 있고, 최대 통지 횟수 이상이 되는 경우에 구독은 삭제될 수 있다. 다만, 교차 리소스의 경우에는 복수 개의 구독이 존재할 수 있고, 타겟 구독의 삭제와 교차 구독의 삭제 관계가 불명확할 수 있다. 일 예로, 교차 리소스에서 독자적인 교차 구독의 최대 통지 발생 수에 대한 설정 지원이 필요할 수 있다.
보다 상세하게는, 교차 리소스의 경우 타겟 구독이 삭제되면 조건 충족이 불가능할 수 있다. 따라서, 타겟 구독이 삭제되는 경우에 교차구독이 삭제되는 매커니즘이 수행될 수 있다. 이때, 일 예로, 타겟 구독의 만료가 임박한 시점에서 교차 구독이 생성된 경우를 고려할 수 있다. 이때, 교차 구독은 생성되었지만, 타겟 구독이 만료되면 교차구독은 타겟 구독에 의해 삭제될 수 있다. 따라서, 교차 구독은 생성되자마자 삭제되는바, 무의미한 동작이 수행될 수 있다. 상술한 점을 고려하여 교차 구독에 대한 “만료 카운터 (expirationCounter)”가 설정될 필요성이 있다. 이때, 교차 구독에 대한 “만료 카운터 (expirationCounter)”는 “교차 서브 만료 카운터 (crosssubexpirationCounter)”로 하기 표 12와 같이 설정될 수 있다. 즉, 하기 표 12처럼 교차 리소스에 대한 최대 통지 횟수가 설정될 수 있다. 이때, 교차 리소스에 대한 최대 통지 횟수를 초과하는 만큼 통지 실패가 발생하는 경우에는 다른 정책과 상관없이 교차 리소스가 삭제될 수 있다.
This attribute (notification policy) indicates that the subscriber wants to set the life of this cross resource subscription to a limit of a maximum number of notifications. When the number of notifications sent reaches the count of this counter, the <crossResourcesubscription> resource shall be deleted, regardless of any other policy.
또한, 일 예로, 상술한 바와 같이, 교차 구독은 타겟 구독이 삭제되면 무의미해질 수 있다. 일 예로, <교차 리소스 구독 (crossResourceSubscription)> 리소스를 생성할 때, 선행 구독 리소스의 기존에 발행된 통지수가 만료 카운터 (expirationCounter)에 근접한 경우, <교차 리소스 구독 (crossResourceSubscription)> 리소스는 구독자의 의도와 달리, 특히 <교차 리소스 구독 (crossResourceSubscription)> 리소스 생성 후 얼마 지나지 않아, 선행 구독 리소스의 삭제로 인해 함께 삭제될 수 있다. 따라서, 교차 구독을 생성하는 경우, 타겟 구독의 “만료카운터 (expirationCounter)”를 조정하기 위한 정책 (policy)이 필요할 수 있으며, 이는 하기 표 13과 같을 수 있다. 다만, 표 13은 하나의 일 예일 뿐, 다른 방법으로 설정되는 것도 가능할 수 잇다. 즉, 타겟 구독의“만료카운터(expirationCounter)”는 교차 구독에 기초하여 교차 구독 만료 카운터가 타겟 카운터에 더해지도록 지시할 수 있다. 또한, 일 예로, 타겟 구독에 대한 조정이 없어도 교차 구독을 수행함에 문제가 없는 경우 타겟 구독의 만료 카운터가 업데이트되지 않을 수 있다. 또 다른 일 예로, 타겟 구독의 “만료카운터(expirationCounter)”는 매뉴얼에 기초하여 설정되도록 할 수 있으며, 상술한 실시예로 한정되지 않는다. 즉, 교차 구독이 설정되는 경우를 고려하여 타겟 구독이 업데이트 되도록할 수있으며, 상술한 실시예로 한정되지않는다.
값 (Value) 동작 (Operation)
0 NO - 타겟구독의만료카운터를업데이트하지않음
1 Add - 교차구독의만료카운터를타겟카운터에더함
2 Manual
3 Reserved
또한, 일 예로, 상술한 바에 기초하여 교차 리소스 구독의 리소스는 “만료 카운터(expirationCounter)”에 대한 업데이트 정책(Update Policy)를 정의할 수 있으며, 이는 하기 표 14와 같을 수 있다. 구체적인 일 예로서, 제 1 선행 구독 리소스의 만료 카운터(expiractionCounter)가 10회이고, 현재통지수카운터(currentNotificationCounter)가 8회인 상태에서, 교차구독 리소스가 생성된 경우를 고려할 수 있다. 이때, 교차 구독 리소소의 교차 서브 만료 카운터(crosssubexpiractionCounter)가 5회인 경우라면 제 1 선행 구독 리소스의 만료 카운터(expirationCounter)를 15회로 업데이트 할 수 있다. 이를 통해, 제 1 선행 구독 리소스의 삭제에 따라 교차 구독 리소스가 삭제되거나 무의미하게 동작하는 것을 방지할 수 있다. 즉, 교차 구독 리소스의 생성시 기존 구독의 만료 카운터(expiractionCounter)를 교차 구독의 교차 서브 만료 카운터 (crosssubexpiractionCounter)만큼 증가시키는 만료 카운터(expiractionCounter) 업데이트 정책을 가질 수 있으며, 하기 표 14 또는 표 15와 같이 속성이 정의될 수 있다.
<crossResourceSubscription>속성 발생횟수(Multiplicity) RW/RO/WO 설명(Description)
만료카운터업데이트(expirationCounterUpdate) 0..1 RW 이속성(통지정책)은구독자가교차구독리소스의생성시, 기존구독의만료카운터(expirationCounter)를업데이트하고자하는경우를나타낸다. 만료카운터업데이트 (expirationCounterUpdate)가 Yes 인경우, 기존구독의만료카운터 (expiratinCounter)에교차구독리소스의교차구독만료카운터 (crosssubexpiratinCounter)가더해지게된다.
attribute of<crossResourceSubscription> Multiplicity RW/RO/WO Description
expirationCounterUpdate 0..1 RW This attribute(or notification policy) indicates whether an existing subscription is updated when the subscriber creates crossResourceSubscription. If a value of the expirationCounterUpdate is "yes", an expiration counter of the existing subscription is added to the crosssubexpiratinCounter of the crossReosourceSubscription.
또 다른 일 예로, 교차 구독 리소스를 생성하는 경우, 기존 구독의 현재 통지 발행 수(currentNotificaionCounter)를 리셋하여 교차 구독 리소스의 생성과 동시에 교차 구독 리소스가 삭제되는 문제를 해결할 수 있을 것이다.
또 다른 일 예로, 현재 통지 발행수(currentNotificaionCounter)의 리셋과 함께 기존 구독의 만료 카운터 (expirationCounter)를 교차 구독의 교차 서브 만료 카운터 (crosssubexpirationCounter)로 변경할 수 있다. 즉, 교차 구독을 생성하는 구독자가 교차 구독 생성 이전에 설정된 이전 구독을 교차 구독에 종속하여 삭제되도록 설정하는 경우, 상술한 바와 같은 동작이 수행될 수 있다. 또한, 일 예로, 교차구독을 생성하는 구독자는 현 시점에서는 선행 구독에 따른 단독 통지를 받고 싶지 않을 수 있다. 따라서, 교차 구독이 삭제되는 경우, 선행 구독도 교차 구독에 종속되어 같이 동작하도록 할 수 있다. 즉, 선행 구독의 경우에 교차 구독이 생성되면 종속되는 것이 바람직할 수 있는바, 상술한 바에 기초하여 동작할 수 있다. 다만, 일 예로, 다른 방법에 기초하여 동작하는 것도 가능할 수 있으며, 상술한 실시예로 한정되지 않는다.
또 다른 일 예로, 만료 카운터 업데이트 (expirationCounterUpdate)에 대한 정책이 다르게 설정될 수 있다. 보다 상세하게는, 교차 리소스가 생성될 때, 선행 구독의 만료 카운터 (expiractionCounter)까지 남아있는 통지수와 교차 구독의 교차 서브 만료 카운터 (crosssubexpirationCounter)가 비교될 수 있다. 이때, 선행 구독의 만료 카운터 (expiractionCounter)까지 남아있는 통지수가 교차 구독의 교차 서브 만료 카운터 (crosssubexpirationCounter)보다 작은 경우, 선행 구독의 만료 카운터 (expirationCounter)에 교차 구독의 교차 서브 만료 카운터 (crosssubexpirationCounter)가 추가되어 증가하도록 업데이트될 수 있다. 즉, 선행 구독의 만료 카운터 (expiractionCounter)까지 남아있는 통지 수와 교차 구독의 교차 서브 만료 카운터 (crosssubexpirationCounter)가 비교하여 업데이트가 불필요할 경우에는 만료 카운터 (expirationCounter)를 업데이트하지 않도록 할 수 있으며, 상술한 실시예로 한정되지 않는다.
한편, 또 다른 일 예로, 선행 구독 리소스와 교차 구독 리소스의 관계를 고려하여 하기 표 16의 동작이 수행되도록 설정할 수 있다. 보다 상세하게는, 교차 구독 리소스가 생성되는 경우, 선행 구독 리소스의 만료 카운터 (expirationCounter)를 리셋하도록 설정할 수 있다. 이때, 상술한 동작의 경우에는 추가 명령 등이 필요하지 않을 수 있는바, 동작이 간편할 수 있다.
또 다른 일 예로, 교차 구독 리소스가 생성되는 경우, 선행 구독 리소스의 만료 카운터 (expirationCounter)를 교차 구독 리소스의 만료 카운터 (expirationCounter)로 재작성(Rewrite)할 수 있다. 즉, 선행 구독 리소스의 만료 카운터 (expirationCounter)가 교차 구독 리소스의 만료 카운터 (expirationCounter)로 대체될 수 있다. 이를 통해, 교차 구독 리소스가 선행 구독 리소스의 삭제에 의해 삭제되거나 무의미한 동작이 수행되는 것을 방지할 수 있다. 또 다른 일 예로, 선행 구독 리소스의 현재 통지수를 리셋하는 방법을 고려할 수 있다. 즉, 교차 리소스가 생성되는 경우에는 새로운 리소스에 대한 동작일 수 있는바, 기존의 통지 수를 리셋하고 새롭게 동작하도록 할 수 있다.
- 교차구독리소스생성시, 선행구독리소스의expirationCounter를 Reset - 교차구독리소스생성시, 선행구독리소스의expirationCounter를교차구독리소스의expirationCounter로 Rewrite- 현재발행된통지수를 Reset
구체적인 일 예로, 제1 구독의 만료 카운터(expirationCounter)가 제 1값이고, 제2 구독의 만료 카운터 (expirationCounter)가 제 2 값이고, 교차 구독의 만료 카운터(expirationCounter)가 제 3 값인 경우를 고려할 수 있다. 이때, 하기와 같이 각각의 경우를 고려할 수 있다.
제 3 값 < 제 1 값 < 제 2 값인 경우
상술한 경우, 교차 구독의 만료 카운터 (expirationCounter) 값인 제 3 값이 기존 구독의 만료 카운터 (expirationCounter)값보다 작을 수 있다. 따라서, 교차 구독이 생성되더라도 선행 구독의 만료 카운터 (expirationCounter)를 조정할 필요성이 없을 수 있다. 다만, 선행 구독들의 현재 통지 수가 교차 구독의 만료 카운터 (expirationCounter)보다 작은 경우에는 해당 구독의 현행 통지 발행 수를 리셋하는 것이 필요할 수 있다. 즉, 교차 구독의 만료 카운터 (expirationCounter)과 선행 구독의 만료 카운터 (expirationCounter)를 비교하고, 교차 구독의 만료 카운터 (expirationCounter)와 선행 구독의 현재 통지 발행 수를 비교하여 동작할 수 있다.
제 1 값 < 제 2 값 < 제 3 값인 경우
상술한 경우, 교차 구독의 만료 카운터 (expirationCounter)가 선행 구독의 만료 카운터 (expirationCounter)보다 클 수 있다. 따라서, 선행 구독들은 만료 카운터 (expirationCounter)에 기초하여 삭제될 여지가 있고, 교차 구독도 삭제될 수 있다. 상술한 점을 고려하여 제 1 구독 및 제 2 구독에 대한 만료 카운터 (expirationCounter)가 재조정될 필요성이 있다. 일 예로, 상술한 경우를 고려하여 교차 구독 리소스를 생성하는 경우, 만료 카운터 재조정 속성이 포함될 수 있다. 이때, 일 예로, 만료 카운터 재조정 속성은 선행 구독의 만료 카운터 (expirationCounter)를 변경하도록 지시하는 속성일 수 있다. 보다 상세하게는, 선행 구독의 만료 카운터 (expirationCounter)를 교차 구독의 만료 카운터 (expirationCounter)로 재작성(Rewrite)하도록 지시할 수 있다. 즉, 상술한 바에 기초하여 교차 구독이 선행 구독에 의해 삭제되거나 무의미해지는 동작을 방지할 수 있다. 또한, 일 예로, 제 1 구독 및 제 2 구독의 만료 카운터 (expirationCounter)가 재조정되는 동작과 별개로 제 1 구독 및 제 2 구독에 대한 현재 통지수에 대한 확인이 필요할 수 있다. 이때, 남아 있는 통지 수가 교차 구독의 만료 카운터 (expirationCounter)보다 작은 경우, 현행 통지 발행 수를 리셋될 수 있다.
제 1 값 < 제 3 값 < 제 2 값인 경우
상술한 경우, 교차 구독의 만료 카운터 (expirationCounter)는 특정 선행 구독의 만료 카운터 (expirationCounter)보다 크고, 다른 선행 구독의 만료 카운터 (expirationCounter)보다 작을 수 있다. 따라서, 특정 선행 구독으로서 제 1 구독이 삭제되는 경우, 교차 구독도 삭제될 수 있다. 따라서, 교차 구독이 만료되지 않도록 상술한 만료 카운터 재조정 속성을 교차 구독 리소스 생성시 포함시킬 수 있다. 이때, 만료 카운터 재조정 속성에 기초하여 제 1 구독의 만료 카운터 (expirationCounter)는 교차 구독의 만료 카운터 (expirationCounter)로 재작성될 수 있다. 또한, 일 예로, 제 1 구독 및 제 2 구독의 만료 카운터 (expirationCounter)가 재조정되는 동작과 별개로 제 1 구독 및 제 2 구독에 대한 현재 통지 수에 대한 확인이 필요할 수 있다. 이때, 남아 있는 통지 수가 교차 구독의 만료 카운터 (expirationCounter)보다 작은 경우, 현행 통지 발행 수를 리셋될 수 있다.
상술한 바에 기초하여, 경우에 따라 교차 구독의 만료 카운터 (expirationCounter)를 고려하여 선행 구독의 만료 카운터 (expirationCounter) 및 현재 발행 통지 수가 조정될 수 있다. 이때, 일 예로, 상술한 바처럼 각각의 경우를 고려하여 서로 다르게 동작하도록 설정할 수 있다.
또 다른 일 예로, 동작의 편의를 위해 교차 구독이 생성되는 경우에 선행 구독의 만료 카운터 (expirationCounter)값과 무관하게 동작하도록 할 수 있다. 일 예로, 교차 구독이 생성되는 경우, 상술한 만료 카운터 재조정 속성에 기초하여 선행 구독의 만료 카운터 (expirationCounter)은 교차 구독의 만료 카운터 (expirationCounter)로 재작성될 수 있다. 즉, 선행 구독은 교차 리소스가 생성되면 교차 리소스에 종속되는 것으로 볼 수 있는바, 기존 만료 카운터 (expirationCounter)과 무관하게 교차 구독의 만료 카운터 (expirationCounter)로 재작성될 수 있다. 또한, 일 예로, 교차 구독이 생성되는 경우, 새로운 리소스가 생성된 것으로 볼 수 있다. 따라서, 선행 구독의 현재 통지 발행 수는 새롭게 카운팅될 필요성이 있다. 따라서, 교차 리소스가 생성되는 경우, 선행 구독의 현재 통지 발행 수와 교차 구독의 만료 카운터 (expirationCounter) 값을 비교하지 않고, 선행 구독의 현재 통지 발행 수가 리셋될 수 있다.
즉, 교차 구독이 생성되는 경우, 선행 구독의 만료 카운터 (expirationCounter)값이 교차 구독의 만료 카운터 (expirationCounter)로 재작성되고, 선행 구독의 현재 통지 발행 수는 재작성될 수 있으며, 상술한 실시예로 한정되지 않는다.
도 14는 본 발명의 장치 구성을 나타낸 도면이다.
도 14를 참조하면, 디바이스(1100)은 메모리(1110), 프로세서(1120), 송수신부(1130) 및 주변 장치(1140)를 포함할 수 있다. 또한, 일 예로, 디바이스(1100)는 다른 구성을 더 포함할 수 있으며, 상술한 실시예로 한정되지 않는다. 이때, 일 예로, 디바이스는 상술한 M2M 시스템에 기초하여 동작하는 장치일 수 있다. 보다 상세하게는, 도 14의 디바이스(1100)는 M2M 디바이스, M2M 게이트웨이 및 M2M 서버와 같은 M2M 네트워크 노드의 예시적인 하드웨어/소프트웨어 아키텍처일 수 있다. 이때, 일 예로, 메모리(1110)는 비이동식 메모리 또는 이동식 메모리일 수 있다. 또한, 일 예로, 주변 장치(1140)는 디스플레이, GPS 또는 다른 주변기기들을 포함할 수 있으며, 상술한 실시예로 한정되지 않는다. 또한, 일 예로, 상술한 디바이스(1100)는 노드일 수 있다. 이때, 노드는 송수신부(1130)와 같이 통신 회로를 포함할 수 있으며, 이에 기초하여 외부 디바이스와 통신을 수행할 수 있다.
또한, 일 예로, 프로세서(1120)는 범용 프로세서, DSP(digital signal processor), DSP 코어, 제어기, 마이크로제어기, ASIC들(Application Specific Integrated Circuits), FPGA(Field Programmable Gate Array) 회로들, 임의의 다른 유형의 IC(integrated circuit) 및 상태머신과 관련되는 하나 이상의 마이크로프로세서 중 적어도 하나 이상일 수 있다. 즉, 상술한 디바이스(1100)를 제어하기 위한 제어 역할을 수행하는 하드웨어적/소프트웨어적 구성일 수 있다. 이때, 프로세서(1120)는 노드의 다양한 필수 기능들을 수행하기 위해 메모리(1110) 에 저장된 컴퓨터 실행가능한 명령어들을 실행할 수 있다. 일 예로, 프로세서(1120)는 신호 코딩, 데이터 처리, 전력 제어, 입출력 처리 및 통신 동작 중 적어도 어느 하나를 제어할 수 있다. 또한, 프로세서(1120)는 물리 계층, MAC 계층, 어플리케이션 계층들을 제어할 수 있다. 또한, 일 예로, 프로세서(1120)는 액세스 계층 및/또는 어플리케이션 계층 등에서 인증 및 보안 절차를 수행할 수 있으며, 상술한 실시예로 한정되지 않는다.
또한, 일 예로, 프로세서(1120)는 송수신부(1130)를 통해 다른 장치들과 통신을 수행할 수 있다. 일 예로, 프로세서(1120)는 컴퓨터 실행가능한 명령어들의 실행을 통해 노드가 네트워크를 통해 다른 노드들과 통신을 수행하게 제어할 수 있다. 즉, 본 발명에서 수행되는 통신이 제어될 수 있다. 일 예로, 다른 노드들은 M2M 게이트웨이, M2M 서버 및 그 밖의 다른 디바이스들일 수 있다. 일 예로, 송수신부(1130)는 안테나를 통해 RF 신호를 전송할 수 있으며, 다양한 통신망에 기초하여 신호를 전송할 수 있다. 또한, 일 예로, 안테나 기술로서 MIMO 기술, 빔포밍 등이 적용될 수 있으며, 상술한 실시예로 한정되지 않는다. 또한, 송수신부(1130)를 통해 송수신한 신호는 변조 및 복조되어 프로세서(1120)에 의해 제어될 수 있으며, 상술한 실시예로 한정되지 않는다.
도 15는 디바이스에 대한 장치 구성일 수 있다. 도 15를 참조하면, 상술한 바와 같이 프로세서에 의해 제어될 수 있다. 이때, 일 예로, 메모리 및 RAM, ROM 및 네트워크 등이 포함될 수 있다. 또한, 그 밖에 이동식 메모리가 더 포함될 수 있으며, 상술한 실시예로 한정되지 않는다. 이때, 프로세서는 상술한 메모리들에 저장된 정보에 기초하여 명령을 수행하고, 본 발명의 상술한 동작들을 수행하도록 제어할 수 있다. 또한, 프로세서는 전원 등에 의해 전력을 공급받고, 주변 장치들에 의해 입력 정보 등을 제공 받을 수 있으며, 상술한 실시예로 한정되지 않는다. 또한, 일 예로, 디바이스는 GPS 등에 기초하여 위치 정보 및 관련 정보를 획득할 수 있다. 또한, 일 예로, 디바이스는 기타 입력 장치에 기초하여 입력 정보를 수신할 수 있으며, 상술한 실시예로 한정되지 않는다.
상술한 본 발명의 실시예들은 다양한 수단을 통해 구현될 수 있다. 일 예로, 본 발명의 실시예들은 하드웨어, 펌웨어(firmware), 소프트웨어 또는 그것들의 결합 등에 의해 구현될 수 있다.
상술한 바와 같이 개시된 본 발명의 바람직한 실시형태에 대한 상세한 설명은 당업자가 본 발명을 구현하고 실시할 수 있도록 제공되었다. 상기에서는 본 발명의 바람직한 실시 형태를 참조하여 설명하였지만, 해당 기술 분야의 숙련된 당업자는 하기의 특허 청구의 범위에 기재된 본 발명의 사상 및 영역으로부터 벗어나지 않는 범위 내에서 본 발명을 다양하게 수정 및 변경시킬 수 있음을 이해할 수 있을 것이다. 따라서, 본 발명은 여기에 나타난 실시형태들에 제한되려는 것이 아니라, 여기서 개시된 원리들 및 신규한 특징들과 일치하는 최광의 범위를 부여하려는 것이다. 또한, 이상에서는 본 명세서의 바람직한 실시예에 대하여 도시하고 설명하였지만, 본 명세서는 상술한 특정의 실시예에 한정되지 아니하며, 청구범위에서 청구하는 본 명세서의 요지를 벗어남이 없이 당해 발명이 속하는 기술분야에서 통상의 지식을 가진 자에 의해 다양한 변형실시가 가능한 것은 물론이고, 이러한 변형 실시들은 본 명세서의 기술적 사상이나 전망으로부터 개별적으로 이해되어서는 안될 것이다.
그리고 당해 명세서에서는 물건 발명과 방법 발명이 모두 설명되고 있으며, 필요에 따라 양 발명의 설명은 보충적으로 적용될 수 있다.?
또한, 본 발명에 대하여 그 바람직한 실시예들을 중심으로 살펴보았다. 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자는 본 발명이 본 발명의 본질적인 특성에서 벗어나지 않는 범위에서 변형된 형태로 구현될 수 있음을 이해할 수 있을 것이다. 그러므로 개시된 실시예들은 한정적인 관점이 아니라 설명적인 관점에서 고려되어야 한다. 본 발명의 범위는 전술한 설명이 아니라 특허청구범위에 나타나 있으며, 그와 동등한 범위 내에 있는 모든 차이점은 본 발명에 포함된 것으로 해석되어야 할 것이다.
본 발명은 oneM2M 시스템뿐만 아니라 다양한 시스템에 적용될 수 있다.

Claims (20)

  1. 교차 리소스에 기초하여 호스트가 구독자에게 통지를 전송하는 방법에 있어서,
    상기 교차 리소스에 기초하여 복수 개의 구독 조건을 설정하는 단계;
    상기 복수 개의 구독 조건 각각을 만족하는 각각의 이벤트를 디텍트하는 단계; 및
    상기 복수 개의 구독 조건이 모두 만족되는 경우, 상기 교차 리소스에 대한 통지를 상기 구독자에게 전송하는 단계;를 포함하되,
    상기 복수 개의 구독 조건은 우선 순위를 갖는, 교차 리소스에 기초한 통지 방법.
  2. 제 1 항에 있어서,
    상기 복수 개의 구독 조건 각각을 만족하는 상기 각각의 이벤트가 타임 윈도우(Time Window) 내에 디텍트되는 경우에만 상기 교차 리소스에 대한 상기 통지를 구독자에게 전송하는, 교차 리소스에 기초한 통지 방법.
  3. 제 2 항에 있어서,
    상기 타임 윈도우는 상기 복수 개의 구독 조건 중 어느 하나의 구독 조건에 대한 이벤트가 감지되면 시작되는, 교차 리소스에 기초한 통지 방법.
  4. 제 3 항에 있어서,
    상기 복수 개의 구독 조건에 상기 우선 순위가 설정된 경우, 상기 복수 개의 구독 조건 중 우선 순위가 가장 높은 구독 조건에 대한 이벤트가 디텍트되는 경우에만 상기 타임 윈도우가 시작되는, 교차 리소스에 기초한 통지 방법.
  5. 제 4 항에 있어서,
    상기 우선 순위가 가장 높은 구독 조건에 대한 상기 이벤트가 디텍트되어 상기 타임 윈도우가 시작된 경우, 상기 타임 윈도우에 대응하는 시간 구간 동안 내에 상기 복수 개의 구독 조건이 만족되면 상기 교차 리소스에 대한 상기 통지를 상기 구독자에게 전송하는, 교차 리소스에 기초한 통지 방법.
  6. 제 1 항에 있어서,
    상기 호스트는 상기 복수 개의 구독 조건 각각에 대한 단일 리소스를 각각의 M2M 엔티티에 요청하고,
    상기 각각의 M2M 엔티티들은 각각의 구독 조건에 기초하여 이벤트가 트리거링되면 상기 단일 리소스에 기초하여 각각의 통지를 상기 호스트로 전송하는, 교차 리소스에 기초한 통지 방법.
  7. 제 6 항에 있어서,
    상기 호스트가 타임 윈도우 내에 상기 각각의 M2M 엔티티로부터 상기 각각의 통지를 수신하는 경우, 상기 호스트는 상기 교차 리소스에 대한 상기 통지를 상기 구독자에게 전송하는, 교차 리소스에 기초한 통지 방법.
  8. 제 1 항에 있어서,
    상기 교차 리소스에 기초하여 상기 복수 개의 구독 조건이 설정되는 경우, 상기 교차 리소스에 대한 만료 카운터(expirationCounter)가 설정되는, 교차 리소스에 기초한 통지 방법.
  9. 제 8 항에 있어서,
    상기 복수 개의 구독 조건이 설정되기 전에 상기 복수 개의 구독 조건 중 어느 하나 이상과 관련된 선행 구독이 존재하는 경우, 상기 선행 구독에 대한 만료 카운터(expirationCounter)는 상기 교차 리소스에 대한 상기 만료 카운터에 기초하여 업데이트되는, 교차 리소스에 기초한 통지 방법.
  10. 제 9 항에 있어서,
    상기 선행 구독에 대한 상기 만료 카운터는 상기 교차 구독에 대한 상기 만료 카운터로 재작성(Rewrite)되는, 교차 리소스에 기초한 통지 방법.
  11. 제 10 항에 있어서,
    상기 선행 구독에 대한 상기 만료 카운터가 상기 교차 구독에 대한 상기 만료 카운터보다 작은 경우에만 상기 교차 구독에 대한 상기 만료 카운터로 재작성되는, 교차 리소스에 기초한 통지 방법.
  12. 제 9항에 있어서,
    상기 선행 구독에 대한 상기 만료 카운터가 상기 교차 리소스에 대한 상기 만료 카운터에 기초하여 업데이트되는 경우, 상기 선행 구독에 대한 현재 통지 발행 수는 리셋되는, 교차 리소스에 기초한 통지 방법.
  13. 제 12 항에 있어서,
    상기 선행 구독에 대한 상기 현재 통지 발행 수에 기초하여 남은 통지 수가 상기 교차 리소소의 상기 만료 카운터보다 작은 경우에만 상기 선행 구독에 대한 상기 현재 통지 발행 수가 리셋되는, 교차 리소스에 기초한 통지 방법.
  14. 교차 리소스에 기초하여 구독자에게 통지를 전송하는 호스트에 있어서,
    신호를 송수신하는 송수신부;
    상기 송수신부를 제어하는 프로세서;를 포함하되,
    상기 프로세서는,
    상기 교차 리소스에 기초하여 복수 개의 구독 조건을 설정하고,
    상기 복수 개의 구독 조건 각각을 만족하는 각각의 이벤트를 디텍트하고,
    상기 복수 개의 구독 조건이 모두 만족되는 경우, 상기 교차 리소스에 대한 통지를 상기 구독자에게 전송하되,
    상기 복수 개의 구독 조건은 우선 순위를 갖는, 호스트.
  15. 제 14 항에 있어서,
    상기 복수 개의 구독 조건 각각을 만족하는 상기 각각의 이벤트가 타임 윈도우(Time Window) 내에 디텍트되는 경우에만 상기 교차 리소스에 대한 상기 통지를 구독자에게 전송하는, 호스트.
  16. 제 15 항에 있어서,
    상기 타임 윈도우는 상기 복수 개의 구독 조건 중 어느 하나의 구독 조건에 대한 이벤트가 감지되면 시작되는, 호스트.
  17. 제 16 항에 있어서,
    상기 복수 개의 구독 조건에 상기 우선 순위가 설정된 경우, 상기 복수 개의 구독 조건 중 우선 순위가 가장 높은 구독 조건에 대한 이벤트가 디텍트되는 경우에만 상기 타임 윈도우가 시작되는, 호스트.
  18. 제 17 항에 있어서,
    상기 우선 순위가 가장 높은 구독 조건에 대한 상기 이벤트가 디텍트되어 상기 타임 윈도우가 시작된 경우, 상기 타임 윈도우에 대응하는 시간 구간 동안 내에 상기 복수 개의 구독 조건이 만족되면 상기 교차 리소스에 대한 상기 통지를 상기 구독자에게 전송하는, 호스트.
  19. 교차 리소스에 기초하여 구독자가 호스트로부터 통지를 수신하는 방법에 있어서,
    복수 개의 구독 조건이 모두 만족되는 경우, 상기 교차 리소스에 대한 통지를 상기 호스트로부터 수신하는 단계; 및
    상기 수신한 통지에 기초하여 동작을 수행하는 단계;를 포함하되,
    상기 호스트는 상기 교차 리소스에 기초하여 복수 개의 구독 조건을 설정하고,
    상기 호스트가 상기 복수 개의 구독 조건 각각을 만족하는 각각의 이벤트를 디텍트하면 상기 구독자로 상기 통지를 전송하되, 상기 복수 개의 구독 조건은 우선 순위를 갖는, 교차 리소스에 기초한 통지를 수신하는 방법.?
  20. 교차 리소스에 기초하여 호스트로부터 통지를 수신하는 구독자에 있어서,
    신호를 송수신하는 송수신부;
    상기 송수신부를 제어하는 프로세서;를 포함하되,
    상기 프로세서는,
    복수 개의 구독 조건이 모두 만족되는 경우, 상기 교차 리소스에 대한 통지를 상기 호스트로부터 수신하고,
    상기 수신한 통지에 기초하여 동작을 수행하되,
    상기 호스트는 상기 교차 리소스에 기초하여 복수 개의 구독 조건을 설정하고,
    상기 호스트가 상기 복수 개의 구독 조건 각각을 만족하는 각각의 이벤트를 디텍트하면 상기 구독자로 상기 통지를 전송하되, 상기 복수 개의 구독 조건은 우선 순위를 갖는, 구독자.
PCT/KR2020/001882 2019-02-11 2020-02-11 구독 및 통지를 수행하는 방법 및 장치 WO2020166927A1 (ko)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN202080013622.1A CN113412634A (zh) 2019-02-11 2020-02-11 用于订阅和通知的方法和设备
EP20756307.3A EP3908016A4 (en) 2019-02-11 2020-02-11 METHOD AND DEVICE FOR SUBSCRIBE AND NOTIFICATION
US17/426,280 US11937206B2 (en) 2019-02-11 2020-02-11 Method and device for subscribing and notifying

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR10-2019-0015652 2019-02-11
KR1020190015652A KR102598045B1 (ko) 2019-02-11 2019-02-11 구독 및 통지를 수행하는 방법 및 장치

Publications (1)

Publication Number Publication Date
WO2020166927A1 true WO2020166927A1 (ko) 2020-08-20

Family

ID=72044392

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2020/001882 WO2020166927A1 (ko) 2019-02-11 2020-02-11 구독 및 통지를 수행하는 방법 및 장치

Country Status (5)

Country Link
US (1) US11937206B2 (ko)
EP (1) EP3908016A4 (ko)
KR (1) KR102598045B1 (ko)
CN (1) CN113412634A (ko)
WO (1) WO2020166927A1 (ko)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102557011B1 (ko) * 2021-02-24 2023-07-20 주식회사 더트라이브 차량 구독 서비스에 제공되는 차량을 관리하는 방법 및 장치

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016039549A1 (ko) * 2014-09-12 2016-03-17 주식회사 케이티 M2m 시스템에서 위치정보 업데이트 주기를 변경하는 방법
US20160088420A1 (en) * 2013-05-16 2016-03-24 Lg Electronics Inc. Method for subscription and notification in m2m communication system and apparatus for same
WO2017087367A1 (en) * 2015-11-16 2017-05-26 Convida Wireless, Llc Cross-resource subscription for m2m service layer
KR101852727B1 (ko) * 2017-07-28 2018-04-27 전자부품연구원 크로스-리소스 구독 관리 방법

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6502157B1 (en) * 1999-03-24 2002-12-31 International Business Machines Corporation Method and system for perfetching data in a bridge system
US9141628B1 (en) * 2008-11-07 2015-09-22 Cloudlock, Inc. Relationship model for modeling relationships between equivalent objects accessible over a network
US20130188483A1 (en) * 2012-01-20 2013-07-25 Alcatel-Lucent Canada, Inc. Resource Threshold Overload Protection
EP3832989A1 (en) * 2013-08-29 2021-06-09 Convida Wireless, LLC Internet of things event management systems and methods
CN105580396B (zh) * 2013-09-27 2019-04-16 Lg电子株式会社 用于在m2m系统中传送通知消息的方法及其装置
KR20190002340A (ko) * 2017-06-29 2019-01-08 주식회사 케이티 M2m 시스템에서 요청 메시지를 처리하는 방법 및 그 장치
KR20190004233A (ko) * 2017-07-03 2019-01-11 주식회사 케이티 M2m 시스템에서 메시지를 전송하는 방법 및 그 장치

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160088420A1 (en) * 2013-05-16 2016-03-24 Lg Electronics Inc. Method for subscription and notification in m2m communication system and apparatus for same
WO2016039549A1 (ko) * 2014-09-12 2016-03-17 주식회사 케이티 M2m 시스템에서 위치정보 업데이트 주기를 변경하는 방법
WO2017087367A1 (en) * 2015-11-16 2017-05-26 Convida Wireless, Llc Cross-resource subscription for m2m service layer
KR101852727B1 (ko) * 2017-07-28 2018-04-27 전자부품연구원 크로스-리소스 구독 관리 방법

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
ONEM2M: "Service Layer Core Protocol Specification", 6 April 2018 (2018-04-06), pages 1 - 258, XP009523094, Retrieved from the Internet <URL:https://www.onem2m.org/technical/published-drafts/release-1> [retrieved on 20200421] *
See also references of EP3908016A4 *

Also Published As

Publication number Publication date
US20210400629A1 (en) 2021-12-23
EP3908016A4 (en) 2022-10-05
KR102598045B1 (ko) 2023-11-02
US11937206B2 (en) 2024-03-19
CN113412634A (zh) 2021-09-17
KR20200098046A (ko) 2020-08-20
EP3908016A1 (en) 2021-11-10

Similar Documents

Publication Publication Date Title
WO2015046960A1 (ko) M2m 시스템에서 통지 메시지 전달 방법 및 이를 위한 장치
WO2015069038A1 (ko) M2m 통신 시스템에서 구독 및 통지를 위한 방법 및 이를 위한 장치
WO2014185754A1 (ko) M2m 통신 시스템에서 구독 및 통지를 위한 방법 및 이를 위한 장치
WO2018199649A1 (en) Method and apparatus for registration type addition for service negotiation
WO2021091285A1 (en) Method and apparatus for controlling network slice in wireless communication system
WO2020204530A1 (en) Apparatus and method for supporting one-to-one communication service in wireless communication system
WO2014109597A1 (ko) M2m(machine-to-machine)시스템에서 게이트웨이 변경 방법 및 이를 위한 장치
WO2015005651A1 (en) Lawful interception method and apparatus of d2d communication-capable terminal
WO2016068548A1 (ko) 무선 통신 시스템에서 통지 메시지를 처리하기 위한 방법 및 이를 위한 장치
EP3574693A1 (en) Method and apparatus for registration type addition for service negotiation
WO2020251240A1 (en) Method and apparatus for improving service reliability in wireless communication system
WO2021167277A1 (ko) 에지 컴퓨팅 시스템에서 무선 통신 네트워크 타입에 따른 서비스 제공 장치 및 방법
WO2021091307A1 (ko) 무선 통신 시스템에서 mbs 서비스 제공에 대한 mbs 서비스 세션의 설정을 위한 장치 및 방법
WO2011139098A2 (ko) 이동통신 시스템에서의 mtc 서비스 네트워크 오버로드의 제어 방법 및 그 장치
WO2016126021A1 (ko) 무선 통신 시스템에서 통지 수신 중단 요청을 처리하기 위한 방법 및 이를 위한 장치
WO2016195199A1 (ko) 무선 통신 시스템에서 폴링 채널을 통해 요청을 처리하기 위한 방법 및 이를 위한 장치
WO2021141291A1 (ko) 무선 통신 시스템에서 네트워크 트래픽을 수집하는 방법 및 장치
WO2010082801A2 (en) Method for delivering cpm message and server thereof
WO2013105816A1 (ko) 무선통신 시스템에서 서비스 도메인을 선택하는 방법 및 장치
WO2019221493A1 (ko) 5g 이동통신 시스템에서 셀룰러 iot 서비스를 위해 단말을 제어하는 방법
WO2016064235A2 (ko) 무선 통신 시스템에서 그룹 멤버의 자식 자원을 관리하기 위한 방법 및 이를 위한 장치
WO2017073876A1 (ko) 무선 통신 시스템에서 서비스 요청을 처리하기 위한 방법 및 이를 위한 장치
WO2020009537A1 (ko) 리소스 관리 방법 및 장치
WO2020166927A1 (ko) 구독 및 통지를 수행하는 방법 및 장치
WO2020130245A1 (en) Network connection method and apparatus

Legal Events

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

Ref document number: 20756307

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2020756307

Country of ref document: EP

Effective date: 20210805