WO2015069038A1 - M2m 통신 시스템에서 구독 및 통지를 위한 방법 및 이를 위한 장치 - Google Patents
M2m 통신 시스템에서 구독 및 통지를 위한 방법 및 이를 위한 장치 Download PDFInfo
- Publication number
- WO2015069038A1 WO2015069038A1 PCT/KR2014/010616 KR2014010616W WO2015069038A1 WO 2015069038 A1 WO2015069038 A1 WO 2015069038A1 KR 2014010616 W KR2014010616 W KR 2014010616W WO 2015069038 A1 WO2015069038 A1 WO 2015069038A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- entity
- subscription
- resource
- request
- notification
- Prior art date
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/06—Authentication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/08—Access security
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/08—Access security
- H04W12/086—Access security using security domains
-
- 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
- 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
Definitions
- the present invention relates to a machine-to-machine communication system, and more particularly, to a method and apparatus for subscribing and notifying a specific resource in an M2M system.
- M2M communication refers to communication performed between a machine and a machine without human intervention, and is also referred to as machine type communication (MTC) or internet of things (IoT) communication.
- MTC machine type communication
- IoT internet of things
- a terminal used for M2M communication is referred to as an M2M device, which is generally low mobility, time tolerant or delay tolerant, and small data transmission. It is used in connection with M2M server that centrally stores and manages communication information between machines.
- M2M device when the M2M device is connected according to different communication methods, the M2M device and the M2M server are connected through the M2M gateway in a section in which the communication method is changed, thereby forming the entire M2M system.
- services such as tracking, power metering, automatic payment system, medical service, and remote control may be provided.
- the present invention relates to an M2M system.
- Another object of the present invention is to provide a method for efficiently performing privilege check in an M2M system and an apparatus therefor.
- Still another object of the present invention is to provide a method for preventing malicious attack using a subscription / communication mechanism in an M2M system and an apparatus therefor.
- Still another object of the present invention is to provide a method for preventing unauthorized theft of a right of a device hosting a specific resource in an M2M system and an apparatus therefor.
- a message processing method for resource subscription in a machine-to-machine device the method for receiving a subscription request message for a subscription target resource from a first device;
- the subscription request message includes identification information of the first device and identification information of a second device; Checking whether the first device has a right to the subscription target resource; Determining whether the first device and the second device are the same based on identification information of the first device and identification information of the second device; When the first device and the second device are different from each other, a notification message including identification information of the first device, identification information of the M2M device, and parameter information indicating a verification request is transmitted to the second device.
- M2M machine-to-machine device
- a Machine-to-Machine (M2M) device comprising: a Network Interface Unit; And a processor operatively connected with the network interface unit, the processor receiving a subscription request message for a subscription target resource from a first device, wherein the subscription request message is identification information of the first device. And identification information of a second device, checking whether the first device has a right to the subscription target resource, and based on the identification information of the first device and the identification information of the second device. It is determined whether a first device and the second device are the same, and when the first device and the second device are different from each other, the identification information of the first device, the identification information of the M2M device, and the verification request are instructed.
- M2M Machine-to-Machine
- Send a notification message including parameter information to the second device Receive a response message to the notification message from an e-mail, an authorization check for the subscription request is performed by the second device based on the identification information of the first device and the identification information of the M2M device, and The response message may include a result of the authorization check by the second device.
- the authorization check by the second device may include checking whether the M2M device has the authority to send a notification message to the second device.
- the authorization check by the second device may further include checking whether the first device has a right to set up a subscription for sending a notification message to the second device.
- the method may further comprise transmitting a temporary acceptance message for said subscription request message to said first device, before said sending said notification message to said second device.
- the method further comprises determining whether a result of the authorization check by said second device is successful; If the result of the authorization check is successful, transmitting a subscription approval message to the first device; And canceling the resource subscription when the result of the authorization check is unsuccessful.
- the method may further include transmitting a message indicating that the resource subscription has been canceled to the first device when the authority check result is unsuccessful.
- the subscription request message includes subscription information for generating a subscription resource in the M2M device, and the method may further include temporarily storing the subscription information.
- the subscription request message includes subscription information for generating a subscription resource in the M2M device, and the method may further include generating a subscription resource based on the subscription information.
- the identification information of the first device may be stored in creator attribute information of the subscription resource.
- the notification message is generated when a notification event occurs in the M2M device, the notification event may include a state change of the subscription target resource.
- said notification message may be generated independently of the occurrence of a notification event at said M2M device.
- the identification information of the first device includes address information indicating identification information of a sender of the subscription request message
- the identification information of the second device includes address information indicating a notification target of the notification message. It may include.
- the resource may represent a uniquely addressable data structure using a unique address.
- the response message type information in the subscription request message may indicate one of a blocking request, a synchronous non-blocking request, and an asynchronous non-blocking request.
- network load increase and / or system performance deterioration can be prevented by preventing malicious use or unauthorized use of a subscription / communication mechanism in an M2M system.
- FIG. 2 illustrates a layered structure of an M2M system.
- FIG. 3 illustrates a functional architecture of an M2M system.
- FIG. 5 illustrates a resource used in an M2M system.
- FIG. 6 illustrates a communication flow of a typical M2M system.
- FIG. 7 and 8 illustrate a procedure for accessing a resource based on a blocking request.
- 9 and 10 illustrate a procedure for accessing a resource based on a synchronous non-blocking request.
- FIG. 11 illustrates a procedure for accessing a resource based on an asynchronous non-blocking request.
- FIG. 12 illustrates a procedure related to a subscription resource.
- 15-17 illustrate a subscription and notification procedure in accordance with the present invention.
- FIG. 18 illustrates a block diagram of an apparatus to which the present invention can be applied.
- an M2M device refers to a device for machine-to-machine communication.
- the M2M device may be fixed or mobile and may communicate with the M2M server to send and receive user data and / or control information.
- M2M devices may include a terminal equipment, a mobile station (MS), a mobile terminal (MT), a user terminal (UT), a subscriber station (SS), a wireless device, a personal digital assistant (PDA), and a wireless modem ( wireless modem, handheld device, and the like.
- the M2M server refers to a server for M2M communication and may be implemented as a fixed station or a mobile station.
- the M2M server may communicate with M2M devices and / or other M2M servers to exchange data and control information.
- the M2M gateway refers to a device that serves as a connection point for entering a network from one network to another when the network to which the M2M device is connected and the network to which the M2M server is connected are different.
- the M2M gateway may perform a function as an M2M device, for example, manage an M2M device connected to the M2M gateway, receive a message, and deliver the same or changed message to the connected M2M devices (message fanout). ), A function of message aggregation may be performed.
- the term M2M device may be used as a concept including an M2M gateway and an M2M server, and thus, the M2M gateway and the M2M server may be referred to as an M2M device.
- entity can be used herein to refer to hardware such as an M2M device, an M2M gateway, an M2M server, or software of the M2M application layer and the M2M (common) service layer described below. It may be used to refer to a software component.
- the present invention will be described with reference to the M2M system, but the present invention is not limited to the M2M system, and the same applies to a system according to a client-server (or sender-responder) model. Similarly it can be applied.
- FIG. 1 illustrates an M2M system.
- 1 illustrates an M2M system according to the European Telecommunications Standards Institute (ETSI) Technical Specification (TS).
- ETSI European Telecommunications Standards Institute
- TS Technical Specification
- the M2M system according to the ETSI TS M2M technical standard defines a common M2M service framework for various M2M applications.
- An M2M application may refer to a software component that implements an M2M service solution such as e-Health, City Automation, Connected Consumer, or Automotive.
- M2M service functions necessary in common for implementing such various M2M applications are provided, and the functions commonly required may be referred to as M2M service or M2M common service.
- the M2M service is provided in the form of a set of Service Capabilities (SC), and the M2M application accesses a set of Service Capabilities (SCs) or a Service Capability (SC) through an open interface. You can use M2M service or function provided by.
- the SC can provide the capabilities to configure M2M services (eg device management, location, discovery, group management, registration, security, etc.), and the SC Layer (Service Capabilities Layer) or SC Entity (Service Capability Entity) A set of functions for M2M services that can be used when provided on this service framework.
- SC Service Capability
- x may be expressed as one of N / G / D, and indicates where SC (Service Capability) exists among a network (and / or a server), a gateway, and a device.
- NSC Service Capability
- GSC Service Capability
- M2M applications can reside on a network, gateway, or device.
- An M2M application present on a network or directly connected to a server is referred to as an M2M network application and may be briefly referred to as a network application (NA).
- NA is software that is implemented by connecting directly to a server and may be responsible for communicating with and managing an M2M gateway or M2M device.
- the M2M application existing on the device is referred to as an M2M device application and may be briefly referred to as a device application (DA).
- the DA is software running on the M2M device, and may transmit sensor information and the like to the NA.
- the M2M application existing on the gateway is referred to as an M2M gateway application and may be briefly referred to as a gateway application (GA).
- the GA may also serve to manage an M2M gateway and provide DA with M2M services or capabilities (eg, Service Capabilities (SCs) or Service Capability (SC)).
- M2M application may collectively refer to an application entity (AE) and an application layer.
- an M2M system architecture may be divided into a network domain, a device, and a gateway domain.
- the network domain may include functions for M2M system management and functions for network management. Functions for M2M system management may be performed by M2M applications and M2M Service Capabilities (SCs) that manage devices existing in the device and gateway domains, and functions for network management may be performed by the core network and the access network. have.
- SCs M2M Service Capabilities
- the core network and access network provide connectivity between each entity rather than perform M2M functions.
- M2M communication can be performed between M2M Service Capabilities (M2M SCs) in the network domain and device and gateway domains through the core network and the access network, and M2M applications in each domain can receive signals or information through M2M Service Capabilities (SCs) in each domain. Can give and receive.
- M2M SCs M2M Service Capabilities
- SCs M2M Service Capabilities
- An access network is an entity that allows M2M devices and gateway domains to communicate with the core network.
- Examples of access networks include xDSL (Digital Subscriber Line), Hybrid Fiber Coax (HFC), satellite, GERAN, UTRAN, eUTRAN, Wireless LAN, WiMAX, and the like.
- a core network is an entity that provides functions such as Internet Protocol (IP) connectivity, service and network control, interconnection, and roaming.
- Core networks include 3rd Generation Partnership Project (3GPP) core networks, ETSI Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN) core networks, and 3GPP2 core networks.
- 3GPP 3rd Generation Partnership Project
- TISPAN Internet converged Services and Protocols for Advanced Networking
- M2M Service Capability provides the M2M Common Service Function (CSF), which can be shared among multiple M2M network applications, and exposes M2M services through an open interface, allowing M2M applications to access M2M services. Make it available.
- the M2M Service Capability Layer may refer to a layer including such M2M SC entities or M2M common service functions.
- An M2M application is an entity that operates service logic and can use M2M SCs (Service Capabilities) through an open interface.
- An M2M application layer may refer to a layer that contains such M2M application and associated operational logic.
- the M2M device is an entity that operates an M2M device application through M2M SCs (Service Capabilities).
- the M2M device may directly communicate with an M2M server in a network domain, or may communicate with an M2M server in a network domain through an M2M gateway. When connected through an M2M gateway, the M2M gateway acts like a proxy.
- the M2M device may include an M2M application and / or M2M SCs (Service Capabilities).
- An M2M area network provides connectivity between M2M devices and M2M gateways.
- the network between the M2M gateway and the M2M server and the network between the M2M device and the M2M gateway may be different from each other.
- M2M area networks include Personal Area Network (PAN) technologies such as IEEE802.15.1, Zigbee, Bluetooth, IETF ROLL, ISA100.11a, Power Line Communication (M-BUS), Wireless It can be implemented using local network technologies such as M-BUS and KNX.
- PAN Personal Area Network
- M-BUS Power Line Communication
- the M2M gateway is an entity that manages M2M applications and provides services for M2M applications through M2M SCs (Service Capabilities).
- the M2M gateway may serve as a proxy between the M2M device and the network domain and provide a service to an ETSI non-compliant M2M device.
- the M2M gateway may refer to an entity having a gateway function among M2M devices.
- the M2M gateway may include M2M applications and / or M2M SCs (Service Capabilities).
- the M2M system architecture illustrated in FIG. 1 is merely an example and the names of each entity may be different.
- the M2M Service Capability (SC) may be referred to as an M2M common service function (CSF)
- the Service Capability Layer (SCL) may be a common service layer (CSL) or a common service entity (CSL).
- Common Service Entity (CSE)
- an M2M application may be referred to as an application entity (AE), and the M2M application layer may be referred to simply as an application layer.
- the name of each domain may also vary.
- a network domain may be referred to as an infrastructure domain and a device and gateway domain may be referred to as a field domain.
- an M2M system may be understood as a hierarchical structure including an M2M application layer and an M2M Service Capability (SC) layer for M2M communication.
- SC M2M Service Capability
- FIG. 2 illustrates a layered structure of an M2M system.
- an M2M system may include an application layer 202, a common service layer 204, and an underlying network services layer 206.
- the application layer 202 may correspond to the M2M application layer
- the common service layer 204 may correspond to the M2M SCL.
- the underlying network service layer 206 provides services to the common service layer 204, such as device management, location services, and device triggering, present in the core network.
- the M2M system architecture includes an application entity (AE) 302, a common service entity (CSE) 304, an underlying network service entity (NSE) 306. ) May be included.
- Each entity 302, 304, 306 may communicate via a reference point supported by the common service entity 304.
- the reference point serves to specify a communication flow between the entities 302, 304, and 306.
- the reference point can be expressed as Mcx and Mc means “M2M communications”.
- Mca reference point, the Mcc reference point, and the Mcn reference point may be denoted as Mca, Mcc, and Mcn, respectively.
- the Mca reference point 312 specifies the communication flow of the application entity (AE) 302 and the common service entity (CSE) 304.
- the Mca reference point 312 enables the AE 302 to use the services provided by the CSE 304 and allows the CSE 304 to communicate with the AE 302.
- the Mca reference point 312 may refer to an interface between the M2M application layer and the M2M common service layer (or entity).
- the Mcc reference point 314 specifies the flow of communication between different common service entities (CSEs) 304.
- CSEs common service entities
- the Mcc reference point 314 allows the CSE 304 to use the services of another CSE when providing the necessary functions. Services provided via the Mcc reference point 314 may depend on the functions supported by the CSE 304.
- the Mcc reference point 314 may refer to an interface between M2M common service layers.
- Mcn reference point 316 specifies the communication flow between the CSE 304 and the underlying network service entity (NSE) 306. Mcn reference point 316 enables CSE 304 to use the services provided by underlying NSE 306 to provide the required functions. Mcn reference point 316 may refer to an interface between the M2M common service layer and the M2M underlying network layer.
- the CSE 304 may provide various common service functions (CSFs).
- CSFs common service functions
- the CSE 304 may include application and service layer management functions, communication management and delivery handling functions, data management and storage functions, devices, and the like.
- Device Management Function Group Management Function, Discovery Function, Location Function, Network Service Exposure / Service Execution and Triggering Function, Registration ), A security function, a service charging and accounting function, a service session management function, and a subscription / notification function.
- CSE 304 points to an instance of the common service functions and provides a subset of common service functions that M2M applications can use and share.
- the common service functions are briefly described as follows.
- ASM Application and Service Layer Management
- CMDH Communication Management and Delivery Handling
- DMR Data Management and Repository
- DMG Device Management: Manages device functions for devices existing in M2M area networks as well as M2M gateways and M2M devices.
- the DMG function can perform application installation and configuration, firmware update, logging, monitoring, diagnostics, and network topology management.
- Discovery, DIS searches for information, such as information and resources, on request within a given range and condition.
- GMG Group Management
- a group may be created by binding a resource, an M2M device, or an M2M gateway to handle a group related request.
- the M2M application plays a role of obtaining location information of the M2M device or the M2M gateway.
- Network Service Exposure / Service Execution and Triggering Enables communication of the underlying network and enables the use of services or features provided by the underlying network.
- Registration An M2M application or other CSE handles registration to a specific CSE. Registration is performed to use the M2M service function of a specific CSE.
- SEC Handles sensitive data such as security keys, establishes security associations, authenticates, authorizes, and protects identity.
- SCA Service Charging and Accounting
- SSM Service Session Management
- Subscription / Notification When a subscription is made to a change to a specific resource, it plays a role of notifying when the resource is changed.
- a node refers to an entity including one or more M2M applications or an entity including one CSE and zero or more M2M applications.
- An application dedicated node may refer to a node having at least one application entity (AE) but no common service entity (CSE).
- the ADN may communicate with one middle node (MN) or one infrastructure node (IN) through Mca.
- MN middle node
- I infrastructure node
- ADN may be referred to as an M2M device having a constrained capability, where an M2M device with limited capabilities does not include a common service layer or a common service entity (CSE). May be referred to.
- An M2M device with limited capabilities may be referred to simply as a constrained M2M device.
- An application service node may refer to a node having at least one common service entity (CSE) and at least one M2M application entity (AE).
- CSE common service entity
- AE M2M application entity
- the ASN may communicate with one middle node or one infrastructure node through Mcc.
- Mcc common service entity
- ASN may be referred to as an M2M device.
- a middle node may refer to a node having one common service entity (CSE) and zero or more M2M application entities (AEs).
- CSE common service entity
- AEs M2M application entities
- the MN can communicate with one infrastructure node (IN) or another intermediate node (MN) via Mcc, can communicate with IN / MN / ASN via Mcc, or can communicate with ADN via Mca. have.
- MN may be referred to as M2M gateway.
- An infrastructure node may refer to a node having one common service entity (CSE) and zero or more application entities (AEs).
- the IN may communicate with at least one intermediate node (MN) via Mcc and / or may communicate with at least one ASN.
- the IN may communicate with one or more ADN through Mca.
- IN may be referred to as an M2M server.
- Example 1 illustrates communication between ADN and IN.
- the ADN may be an M2M device with limited capabilities.
- the ADN since the ADN does not have a CSE or a common service layer, the ADN may communicate with the CSE of the IN through Mca. Also, in this case, since the ADN does not have a CSE or common service layer, data generated at the AE or application layer cannot be stored / shared to another entity. Thus, in Example 1, data generated at the AE or the application layer of the ADN may be stored and shared in the CSE of the IN.
- Example 2 illustrates the communication between ADN and MN.
- ADN can also be an M2M device with limited capabilities.
- ADN may operate similarly to Example 1 except that the ADN communicates with the CSE of the MN. That is, the ADN may communicate with the CSE of the MN through the Mca.
- ADN since ADN does not have a CSE or common service layer, data generated at the AE or application layer cannot be stored / shared to other entities. Therefore, data generated at the AE or the application layer of the ADN may be stored and shared in the CSE of the MN.
- the MN may communicate with the IN via the MN.
- MN and MN, and MN and IN can communicate through Mcc. It is also possible for the MN to communicate with IN directly without passing through the MN.
- Example 3 illustrates the communication between ASN and MN. Unlike example 1 or example 2, since the ASN has a CSE or common service layer, data generated at the AE or application layer of the ASN can be stored in its CSE or common service layer. In addition, the AE of the ASN may communicate with the CSE of the MN through the CSE of the ASN.
- Example 4 illustrates the communication between ASN and MN.
- the CSE of the ASN can communicate with the CSE of the IN directly without going through the MN.
- the IN may be located in an infrastructure domain or a network domain and may include one CSE and zero or more AEs.
- the INs can communicate with each other via Mcc.
- 5 illustrates a resource or resource used in an M2M system.
- an application entity a CSE, data, etc. may be represented as a resource.
- a resource refers to a uniquely addressable entity using a unique address (eg, a Universal Resource Identifier or Uniform Resource Identifier (URI)).
- URI Uniform Resource Identifier
- resources are represented as specific data structures, and each resource can be logically connected to each other. Resources may be managed and stored by the CSE or common service layer. Thus, the CSE or common service layer of the M2M device, the M2M gateway, the M2M server may have these resources.
- each resource can have child resources and attributes, and child resources and attributes are also uniquely addressable.
- a root resource may have an attribute and a child resource.
- resources can be represented as a tree structure.
- the type of the root resource may be represented as ⁇ baseURI> or ⁇ CSEBase>.
- the type of resource may be indicated by " ⁇ " and ">".
- M2M applications can communicate based on resources whose resource types are instantiated. For example, it can be used to perform M2M services such as registering an application and reading sensor values.
- Each resource is given unique address information (e.g. URI) when an instance of that resource type is created, and can have the same properties and child resources as the root resource.
- Each resource is addressed using unique address information.
- the specific resource type defines the child resources and attributes that the resource can have when instantiated. In a specific resource instantiation, a resource may have attributes and child resources defined in the resource type of the resource.
- Child resources can have their own attributes and their own child resources.
- child resources include remote CSE resources, application entity resources, access control resources, container resources, group resources, subscription resources, and so on.
- the remote CSE resource contains information of other CSEs registered (connected) to the CSE.
- the type of the remote CSE resource may be indicated as ⁇ entity> or ⁇ remoteCSE>.
- Application entity resources of the root resource e.g. ⁇ baseURI> / ⁇ application> or ⁇ CSEBase> / ⁇ AE>
- remote CSE resources of the root resource e.g. ⁇ baseURI> / ⁇ entity> or ⁇ CSEBase
- ⁇ remote CSE> e.g. ⁇ remote CSE>
- the information of the registered application entity is stored, and the information of the application entities registered in the specific remote CSE when it exists under the remote CSE resource (eg, ⁇ baseURI> / ⁇ entity> or ⁇ CSEBase> / ⁇ remote CSE>) of the root resource. Save it.
- the type of application entity resource may be indicated as ⁇ application> or ⁇ AE>.
- -Access Control Resource A resource that stores information related to access rights. Authorization may be performed using the access right information included in the resource.
- the type of access control resource may be represented as ⁇ accessRight> or ⁇ accessControlPolicy>.
- -Container resource Stores data generated for each CSE or AE.
- the type of container resource may be represented as ⁇ container>.
- -Group resource Provides a function to group several resources together and process them together.
- the type of group resource may be indicated as ⁇ group>.
- -Subscription resource Performs a function of notifying that the status of a subscription target resource is changed through notification.
- the type of the subscription resource may be indicated as ⁇ subscription>.
- FIG. 6 illustrates a communication flow of a typical M2M system.
- the operation of the M2M system is performed based on the data exchange.
- a specific device may transmit a corresponding command in the form of data to another device to stop the operation of another device.
- Certain types of data structures are used to store data within the device, which may be referred to as resources. Resources can be accessed using unique addresses (eg URIs).
- a Request and Response Scheme is used in the connection between the AE and the CSE or in the connection between the CSEs.
- the originator may send a request message to request a resource stored in a receiver and receive a response message in response.
- the recipient may receive a message requesting a resource from the sender and send a response message to the sender in response.
- a request message may be abbreviated as a request and a response message may be abbreviated as a response.
- the request message transmitted from the sender to the receiver may include the following information.
- op the type of operation to be performed. It may be one of Create / Retrieve / Update / Delete / Notify. In this specification, information corresponding to an operation may be referred to as a command. If an op is set to create, it may be referred to as a create request message (or create message or a create request), if the op is set to retrieve, it may be referred to as a retrieve request message (or retrieve message or retrieve request), and If set to update, it may be referred to as an update request message (or update message or update request); if op is set to delete, it may be referred to as a delete request message (or delete message or delete request), and op is sent to the notification. When set, it may be referred to as a notification request message (or notification message or notification request).
- address information eg, Uniform Resource Identifier
- fr identification information (or ID) of the originator that generated the request, and may be used by the receiver to check the originator identification information for access privilege verification.
- the sender's identification information may include the sender's address information (eg, a URI).
- response message type Indicate what type of response to the request will be sent to the request originator and when the response will be sent to the request originator.
- the response message type may indicate, for example, one of a synchronous non-blocking request, an asynchronous non-blocking request, and a blocking request.
- the request recipient includes an acknowledgment that confirms that the request will be processed after receiving the request.
- the response message can be sent to the requester.
- the request recipient can include in the response message a reference that can be used to access the status of the request and the result of the requested action.
- the synchronous non-blocking request will be described in more detail with reference to FIGS. 9 and 10.
- the request receiver includes an acknowledgment that confirms that it will process the request after receiving it.
- the response message can be sent to the requester.
- a list of notification targets may be included in the request message as an option. If the list of notification targets is included in the request message, the result of the requested operation may be transmitted in the notification message to the notification targets. If the list of notification targets is not included in the request message, the result of the requested operation may be sent to the requesting sender.
- the asynchronous non-blocking request will be described in more detail with reference to FIG. 11.
- the request receiver may transmit a response message with the result of the requested operation after completing the requested operation through the corresponding request.
- the blocking request will be described in more detail with reference to FIGS. 7 and 8.
- the receiver of the request message may transmit the response message to the sender of the request message after performing the requested operation (eg, the operation set in the op).
- the response message may include the following information.
- the response message may include at least one of the following information, or may include only a result value (rs) and a request identifier (ri).
- response code indicating whether the requested operation was performed successfully or an acknowledgment.
- ri a request identifier, which matches the request identifier of the request corresponding to the response message.
- identification information (or ID) of the originator that created the request
- a sender may refer to a sender device or sender entity (or CSE or AE therein), and a receiver may refer to a receiver device or receiver entity (or CSE or AE therein).
- a device (or CSE therein) having a target resource of the requested operation may be referred to as a hosting device or hosting entity (or hosting CSE).
- a receiver that is not a hosting device or entity may be referred to as a transit device or entity (or CSE therein).
- the relay device or entity may serve to relay the received message to the receiver device in the middle.
- a device or entity in which another device (or CSE or AE therein) is registered may be referred to as a registrar device or entity.
- FIG. 7 and 8 illustrate a procedure for accessing a resource based on a blocking request.
- a blocking mode an operation mode of accessing a resource based on a blocking request.
- the term “hop” may refer to the number of relay entities that have delivered a request from a sender to a receiver (or hosting entity).
- the device or entity receiving the message may determine whether the addressed resource is stored in itself by referring to the address information (eg, to) of the operation target resource set in the request message.
- the addressed resource can forward to the next entity or device, in which case the device or entity that receives and delivers the message corresponds to the relay device or entity and the hop is incremented by one.
- the receiver may execute the requested operation and then send a response message with the result. Therefore, it is assumed that the request sender can wait enough time to receive a response to the request after the requested operation is completed. For the originator of the request, this means that the time until a response to a pending request is received is either unknown or potentially long.
- the originator 702 is assumed to be registered with the receiver-1 704, so that the receiver-1 704 is a registrar entity or device. It may correspond to.
- receiver-1 704 is storing an addressed resource (S702), and thus receiver-1 704 may correspond to a hosting entity or device. If there is no hop, the registration entity (or CSE) can be the same entity as the hosting entity (or CSE).
- request originator 702 may send a request to access a resource of recipient- 1 704 (S704).
- the request may be generated and sent at an application entity (or application layer) or CSE (or common service layer).
- the receiver-1 704 may receive a request and then verify whether the sender 702 has access rights to the addressed resource (S706).
- Step S706 may be performed at the CSE of the receiver-1704, for example. If access to the resource is allowed as a result of verifying the access right, the receiver-1 704 may access the resource and generate a response message with a success or failure response (S708). Then, the receiver-1 704 may transmit a response message to the sender 702 (S710).
- hop 1
- the originator 702 is assumed to be registered with the receiver-1 704, so the receiver-1 704 is a registrar entity or device. It may correspond to.
- receiver-2 706 is storing an addressed resource (S802), and thus receiver-2 706 may correspond to a hosting entity or device. If the hop is 1, the registration entity (or CSE) corresponds to a relay entity and may be a different entity from the hosting entity.
- request originator 702 may send a request to receiver-1 704 to access resource of receiver-2 704 (S804).
- the request may be generated and sent at an application entity (or layer) or CSE (or common service layer). Since the receiver-1 704 does not have an addressed resource (S806), the receiver-1 may forward a received request to a hosting entity having the addressed resource among registered entities (S808). In the example of FIG. 8, since the hosting entity is receiver-2 706, receiver-1 704 may send a request to receiver-2 706 to access the resource (S810). After receiving the request, the receiver-2 706 may verify whether the receiver-2 706 has access rights to the addressed resource (S812).
- the receiver-2 706 may access the resource and generate a response message with a success or failure response (S814). Then, receiver-2 706 may send a response message to receiver-1 704 (S816), and receiver-1 704 may forward the response message to sender 702.
- receiver-2 706 may not have an addressed resource and may correspond to a relay entity or device. Thus, receiver-2 706 can forward the request to another device or entity with which it is registered. If there is a hosting entity among the entities with which it is registered, receiver-2 706 may send the request to the hosting entity. However, if not registered with the hosting entity, receiver-2 706 may forward the request to another entity with which it is registered. In this case, if receiver-2 706 is registered with IN (or IN-CSE), it may send a request to IN (or IN-CSE).
- the hosting entity may verify whether it has access rights to the addressed resource. If the access rights are verified and access to the resource is allowed, the resource can be accessed and a response message can be generated / sent with a success or failure response.
- the response message may be delivered to the sender 702 in the reverse order in which the request message was delivered.
- the request originator has requested a reference to the request's acknowledgment and the result of the requested action as a response (eg, synchronous non-blocking request or asynchronous non-blocking request).
- the request recipient needs to provide an immediate response with a reference to an internal resource or other resource on the registration entity so that it can later retrieve the result of the requested operation.
- the reference may be provided in a response message to the request.
- the result of the requested operation may be divided into a synchronous non-blocking request and an asynchronous non-blocking request according to a method of allowing the request originator to retrieve the result.
- an operation mode of accessing a resource based on a synchronous non-blocking request is referred to as a synchronous non-blocking mode
- an operation mode of accessing a resource based on an asynchronous non-blocking request is referred to as an asynchronous non-blocking mode.
- Synchronous non-blocking mode and asynchronous non-blocking mode may be collectively referred to as non-blocking mode.
- receiver-1 704 is a registration entity and may correspond to a hosting entity.
- a synchronous non-blocking request In the case of a synchronous non-blocking request, it is assumed that the request originator cannot receive an asynchronous message. Thus, in the case of a synchronous non-blocking request, all information exchange between the sender and the registration entity needs to be initiated by the sender. Also, in the case of a synchronous non-blocking request, the request originator retrieves the result of the requested operation using a reference. In this case, the flow of information may vary as illustrated in FIGS. 9 and 10 according to the time point at which the result of the requested operation is recovered.
- the sender 702 may transmit a request for accessing a resource to the receiver-1 704 (S904).
- Receiver-1 704 creates a resource (e.g., a ⁇ request> resource) to store the access privilege, accepts the request, and stores the result of the requested action (e.g., Req-Ref). ) May be provided (S906).
- the receiver-1 704 may include the reference in the response message and transmit the reference to the sender (S908).
- the receiver-1 704 may access the operation target resource and execute the operation, and then record the state and the result of the operation in a resource (eg, a ⁇ request> resource) generated in S906 (S910).
- the sender 702 may send a request message to the receiver-1 704 to retrieve the reference received at S908 (S912).
- the receiver-1 704 may verify the access privilege and generate a response message including the contents of the resource (eg, ⁇ request> resource) in which the operation result is recorded (S914).
- the receiver-1 704 may transmit a response message including the operation result to the sender 702 (S916).
- the receiver may complete the request operation after the sender sends a request to retrieve the result of the request operation. Specifically, since S902 to S908 are the same as those described with reference to FIG. 9, the description of FIG. 9 is used.
- the receiver-1 704 accesses the operation target resource to start the requested operation, but may need more time to complete.
- the sender 702 may send a request message to the receiver- 1 704 to retrieve the result of the requested operation (S1004).
- the receiver-1 704 may generate a response message according to the resource (eg, ⁇ request> resource) generated in S906 (S1006).
- the result may indicate that the request operation is not completed.
- the receiver-1 704 may transmit a response message including a result (eg, op not completed) to the sender S702 (S1008).
- the receiver- 1 704 completes the requested operation, and records the operation state and the result in a resource (eg, a ⁇ request> resource) generated in S906.
- the sender may retrieve the operation result in the same manner as described with reference to FIG. 9 (S912 to S916).
- receiver-1 704 may correspond to a registration entity and receiver-2 706 may correspond to a hosting entity.
- the request originator or another entity that needs to know about the request result may receive a notification message.
- the entity performing the requested action may send a message to the sender or other directed entities at any time to send the status and results of the requested action to one or more notification targets.
- the notification message transmitted may operate in the same manner as the notification message transmitted after the subscription for the resource is triggered.
- the receiver e.g., receiver-1704
- the resource type e.g., ⁇ request> resource
- the sender 702 may transmit a request message indicating two notification targets to the receiver-1 704 (S1104).
- a notification message can be sent to the sender 702 and another notification destination 708 when the result of the request operation is available or the request fails.
- the receiver-1 704 accepts the request but does not have the target resource of the request operation (S1106).
- receiver-1 704 may send a response message to sender 702 that includes a reference (eg, Req-Ref) to the resource (eg, ⁇ request> resource) to which the result of the request operation is to be recorded (eg, Req-Ref) ( S1108).
- a reference eg, Req-Ref
- receiver-1 704 and receiver-2 706 may perform a message flow to forward the request to the hosting entity.
- receiver-2 706 since receiver-2 706 is a hosting entity, it may trigger a notification message to notification targets (S1112).
- Recipient-2 706 may send the notification message to recipient-1 704 and another notification destination 708 (S1114), and receiver-1 704 may send the notification message to sender 702 ( S1116).
- the sender 702 may send a response message for the received notification message to the receiver-1 704 (S1118), and the receiver-1 704 and the other notification target 708 respectively send the response message to the receiver-2 ( In step 706, it may be transmitted (S1120).
- FIG. 12 illustrates a procedure related to a subscription resource.
- an entity that is interested in a change of a resource according to a change of a resource may subscribe to a notification of the change.
- a resource for subscription in order to subscribe to the notification, a resource for subscription must be set.
- the resource for the subscription may be referred to as a subscription resource or a ⁇ subscription> resource.
- the device (or entity) to which the subscription resource is set is configured in the subscription resource if a modification / change occurs in the subscribed resource (subscribed-to resource or subscribed resource) that satisfies the conditions set in the subscription resource.
- Notification can be sent to an address (e.g., notificationURI or contact attribute).
- Address information (eg, notificationURI or contact attribute) set in the subscription resource may be used as identification information of a notification target.
- the device (or entity) for which a subscription resource is set up and / or containing a subscription target resource is referred to as a hosting device (or hosting entity).
- a subscription target resource may exist in the CSE of the M2M gateway.
- the M2M gateway may be referred to as a hosting device and the CSE of the M2M gateway may be referred to as a hosting CSE.
- the subscription resource may be used to perform a subscription procedure in a resource-oriented manner.
- a subscription resource can be created to subscribe to a specific subscription target resource, a subscription condition can be changed by modifying the subscription resource, and the subscription resource can be deleted when the subscription is no longer desired.
- the subscription resource includes information about subscribed-to resources.
- the relationship between the subscription target resource and the subscription resource may be expressed as a parent-child relationship.
- a ⁇ container> resource including a subscription target resource may have a ⁇ subscription> resource as a child resource.
- the parent subscription target resource is deleted, the ⁇ subscription> resource may be deleted.
- the subscription resource is a child resource
- an entity indicating a change in the status of the parent resource according to the configuration (attribute setting) of the subscription resource is specified in the address information (e.g., notificationURI or contact attribute) in the subscription resource. Can be passed to.
- the sender has a RETRIEVE (or READ) permission on a subscribeable resource, the sender may create a subscription resource.
- the resource subscriber may be the originator of the subscription request or another entity. If there is a modification to a subscription target resource, the modification is compared to a specific attribute (eg, notificationCriteria attribute) to determine whether a notification is sent to the resource subscriber.
- a specific attribute eg, notificationCriteria attribute
- Subscription resources can have various attributes and child resources.
- a subscription resource eg, a ⁇ subscription> resource
- R / W represents read / write permission of the property, and one of READ / WRITE (RW), READ ONLY (RO), WRITE ONLY or WRITE ONCE (WO). Can be.
- Table 1 is only an example and the properties of the subscription resource may be configured differently from Table 1.
- the filtering attribute (eg, notificationCriteria) is a list of conditions for modification / change of the subscription target resource, and each condition may be in a logical AND relationship.
- the filtering attribute eg, notificationCriteria
- the filtering attribute includes two conditions
- a notification may be sent when the modification / change of the subscription target resource satisfies both conditions.
- the filtering attribute includes two conditions
- the amount of the notification message can be adjusted, and when the set filtering attribute is satisfied, the notification can be sent to the notification target entity, thereby preventing the notification message from overflowing.
- Table 2 illustrates the conditions that may be included in the filtering attribute.
- entity 1 1210 may perform the procedure illustrated in FIG. 6 to subscribe to specific resources of entity 2 1220. Entity 1 1210 may or may not be informed of a change in the subscription target resource.
- a specific resource corresponds to a subscription target resource
- entity 2 1220 may correspond to a hosting device (or entity) because the resource 212 includes a subscription target resource.
- entity 1 1210 may transmit a request for a subscription resource to entity 2 1220 to subscribe to a specific resource.
- the request for a subscription resource may be any one of a generation request, a collection request, a deletion request, and an update request of a subscription resource.
- Each request may take the form of a request message according to the request-response scheme described with reference to FIG. 6.
- the request for a subscription resource may include op information having C (Create), cn information including attribute information (eg, notificationURI, filterCriteria, creator, etc.) of the subscription resource, an entity.
- the request for a subscription resource may include all or part of the information described with reference to FIG. 6.
- a request for generating a subscription resource may be referred to as a request for creating a subscription, a request for retrieving a subscription resource, a request for retrieving a subscription, a request for deleting a subscription for a subscription resource, and a request for renewing a subscription resource for a subscription resource.
- Requests associated with a subscription resource may be collectively referred to as a subscription request.
- the entity 21220 processes the request if it can validate and process the request for the subscription resource. For example, when entity 2 1220 receives a creation request, whether the subscription target resource specified in the to information is available for subscription, and the sender of the request (eg entity 1) has a RETRIEVE permission on the subscription target resource. Validate whether or not If all of these are satisfied, entity 2 1220 may create a subscription resource under a subscribed-to resource specified in the to information.
- entity 2 1220 validates whether the request originator (eg, 1310) has a DELETE permission, and if it is satisfied. Delete a subscription resource.
- entity 2 1220 may process a request for a subscription resource and then send a response message to entity 1 1210.
- the response message of S1206 may have the same / similar form as the response message described with reference to FIG. 6.
- the response message may include information to be returned.
- the sender may be a device or entity (eg, entity 2) that is hosting a subscription resource.
- the receiver may be a device (or entity) indicated by address information (eg, notificationURI) set in the subscription resource.
- Predetermined policy information may be set for the procedure for notification and the sender may be set to send a notification message (eg NOTIFY) when the policy information is satisfied.
- the notification message may refer to a request message in which op is set to NOTIFY.
- a notification message may be generated when a notification event (eg, a change in state of a subscription target resource) occurs.
- the notification event can be triggered by the subscription resource.
- a notification message may be a receiver pointed to by address information (eg, notificationURI) set on a subscription resource if a change in the subscription target resource including the subscription resource as a child resource satisfies a filtering attribute (eg, notificationCriteria) set on the subscription resource. Can be sent to.
- the recipient of the notification message may be the same or different from the device or entity that created / set the subscription resource according to the setting of the subscription resource.
- entity 1 1210 may be the same entity as entity 3 1230 or may be a different entity.
- the notification message may include the following information.
- cn data indicating the modified content of the subscribed resource and / or subscription reference information (e.g., the URI of the subscription resource) and / or other additional information that generated this notification message.
- subscription reference information e.g., the URI of the subscription resource
- the sender may detect / detect a change in a subscription target resource.
- the subscribed resource is the parent resource of the subscribed resource, and the sender (eg, entity 2) (eg, SUB CSF or CSE, if the resource or attribute at the same level as the subscribed resource under the subscribed resource is modified / changed). Can be recognized as a change in the subscription target resource.
- a notification event may be generated when a change in the subscription target resource is detected / detected.
- the sender eg, entity 2 checks whether the corresponding change matches a specific attribute (eg, notificationCriteria) set in the subscription resource.
- the particular attribute may include, for example, at least one of the attributes illustrated in Table 2. If the change of the subscription target resource does not satisfy all of the conditions included in the filtering attribute, the sender (eg, entity 2) may ignore the change.
- the sender (eg, entity 2) transmits to entity 31230 indicated by address information (eg, notificationURI) set in the subscription resource.
- the notification message can be sent.
- the notification message of S1306 may include, for example, identification information of the sender (eg, entity 2), data indicating a change of the subscription target resource, and / or subscription reference information that generated the notification message. If the change of the subscription target resource does not satisfy any of the conditions included in the filtering attribute, the sender (eg, entity 2) may not transmit the generated notification message.
- the request recipient e.g., entity 2 can verify whether the request originator (e.g., entity 1) has permission (or access rights) to the subscription resource or subscription target resource. have. If the request originator (eg, entity 1) does not have permission (or access rights) to the subscription resource or subscription target resource, the subscription request may be rejected and the response message may include a failure result. However, even if such verification is performed, there may be a problem related to subscription verification. Subscription verification herein may refer to the operation of verifying the permission (or access rights) for the subscription request.
- a subscription requester may be referred to as a request originator
- a subscription host may be referred to as a hosting entity.
- a request originator (eg, entity 1) may set a subscription resource to a hosting entity (eg, entity 2) using the notification receiver (eg, entity 3) as a subscriber.
- the hosting entity (eg, entity 2) may check whether the request originator (eg, entity 1) has a subscription target resource or a right to the subscription resource.
- the hosting entity eg, entity 2) can check whether the request originator (eg, entity 1) has access to RETRIEVE for the subscription target resource it has. If the access authority check is successful, in S1206, a response message for approving the subscription request may be sent to the request sender (eg, entity 1).
- a request originator e.g., entity 1
- the subscription resource is sent to send a notification message to the notification receiver (e.g., entity 3).
- the notification receiver e.g., entity 3
- the request originator e.g., entity 1 sets up a subscription resource with malicious intention
- the notification receiver e.g., entity 3 must receive an unsolicited notification message.
- the sender of the request e.g., entity 1 intends a malicious attack such as a DDoS attack
- not only the notification recipient e.g. entity 3) but also the hosting entity (e.g. entity 2) can increase the system load. This can happen as a result of the entire system crashing.
- the hosting entity e.g. entity 2
- the hosting entity e.g. entity 2
- the requesting sender e.g. entity 1
- the hosting entity e.g. entity 2
- another entity e.g, entity 2
- entity may set up separate subscription resources for the hosting entity (eg entity 2).
- the hosting entity e.g., entity 2
- the notification message generated through the subscription resource set up by entity 4 is not the hosting entity (e.g., entity). 2) can be transmitted to the notification recipient (e.g., entity 3) using the access rights of 2).
- the hosting entity e.g entity 2) and the notification recipient (eg entity 3) may be exposed to malicious attacks.
- the present invention proposes a privilege check method for subscription and notification.
- the present invention proposes two additional authorization checks as follows.
- a privilege (or access rights) for a hosting device or entity e.g. entity 2 to send a notification to an entity or device (e.g. entity 3) specified in the address information (e.g. notificationURI) of the subscription resource.
- the request sender e.g., entity 1 has the authority (or access rights) to set up a subscription resource whose notification message recipient (e.g., entity 3) is the notification target.
- the request sender e.g., entity 1 assigns the address information (e.g., notificationURI) of the subscribed resource to the address information (e.g., notificationURI) of the notification message recipient (e.g., entityURI). Whether or not. Or whether the request originator (e.g., entity 1) has the right (or access) to send a notification to the entity or device (e.g., entity 3) specified in the address information (e.g., notificationURI) of the subscription resource.
- the request originator e.g., entity 1 has the right (or access) to send a notification to the entity or device (e.g., entity 3) specified in the address information (e.g., notificationURI) of the subscription resource.
- the authorization check according to the present invention may be performed when the request originator (eg entity 1) and the notification receiver (eg entity 3) are different. For example, this may be performed when the address information (eg, notificationURI) of the subscription resource does not point to the request originator (eg, entity 1).
- the address information eg, notificationURI
- a privilege for sending a notification or a privilege for setting a subscription resource may be represented as NOTIFY / SUBSCRIBE permission / privilege, and may be used interchangeably.
- the ability for a request originator (e.g., entity 1) to set up a subscription resource that targets a notification receiver (e.g., entity 3) is such that the request originator (e.g., entity 1) can set up a notification recipient (e.g., entity 3).
- the ability for a request sender (e.g., entity 1) to set up a subscription for sending a notification message to a notification receiver (e.g., entity 3) may be determined by the request sender (e.g., entity 1). , May be used synonymously with authority to send a notification message to entity 3).
- the authority may be set before the request originator (eg, entity 1) requests subscription resource creation to the hosting entity (eg, entity 2).
- the request originator (eg entity 1) may have sufficient rights for the notification recipient (eg entity 3).
- the request sender e.g., entity 1
- requests a subscription to the hosting entity e.g., entity 2) and sets the notification destination as the notification receiver (e.g., entity 3)
- the hosting entity e.g., entity 2
- the hosting entity eg entity 2) may grant a subscription request of the request originator (eg entity 1) only if the authorization check according to the invention is successful.
- the identification information of the device or entity may include address information (eg, URI) indicating the device or entity.
- the identification information of the device or entity may include address information (eg, URI) indicating a resource that the device or entity has.
- Subscription Verification is possible when the hosting entity (eg, Entity 2) can verify the rights of the notification target. For example, verification cannot be performed if the authority of the notification subject cannot be verified.
- the request sender eg, Entity 1
- the hosting entity eg, Entity 2
- the verification may be performed by determining whether the hosting entity (eg, Entity 2) can verify the authority of the notification target.
- the verification request and the actual operation may be attempted regardless of whether the authority of the notification target may be verified. If the authority of the notification subject can be verified, the verification can be performed successfully and the result can be verified. If the authority of the notification subject cannot be verified, the verification is successful by passing a general error response or not sending a response at all. You can see that it is not.
- Method 1 in accordance with the present invention adds a process to verify whether the hosting entity (eg, entity 2) has access to send a notification message to the notification recipient (eg, entity 3) compared to the prior art. If the requesting sender (e.g., Entity 1) has no malicious intent and has the appropriate rights to the notification recipient (e.g., Entity 3), the hosting entity (e.g., Entity 2) is notified by the notification recipient (e.g., Entity 3) before the subscription setup request.
- the hosting entity e.g., entity 2 has access to send a notification message to the notification recipient (eg, entity 3) compared to the prior art. If the requesting sender (e.g., Entity 1) has no malicious intent and has the appropriate rights to the notification recipient (e.g., Entity 3), the hosting entity (e.g., Entity 2) is notified by the notification recipient (e.g., Entity 3) before the subscription setup request.
- a hosting entity that receives a subscription request e.g., Entity 2 checks if it has permission to send a notification to the notification recipient (e.g., Entity 3), and if not, the requesting sender (e.g., Entity 1) You can assume that you are not authorized to the notification recipient (eg, Entity 3) and decline the subscription request.
- 15 illustrates a subscription and notification procedure in accordance with the present invention. 15 illustrates an example in which Method 1 according to the present invention is applied.
- the hosting entity eg., entity 2 has the authority to send a notification to the notification recipient (eg, entity 3). It is further verified whether or not (S1506).
- a hosting entity e.g., entity 2 receives a subscription request from a request originator (e.g., entity 1)
- the hosting entity e.g., entity 2 causes the request originator (e.g., entity 1) to become a hosting entity (e.g., entity).
- S1506 In addition to checking whether or not there is a right to subscribe (S1204), it also verifies whether the hosting entity (eg, entity 2) has the right to send a notification to the notification receiver (eg, entity 3). (S1506).
- the hosting entity eg, entity 2
- the notification receiver eg, entity 3
- S1506 In the example of FIG. 15, it is illustrated as being performed in the order of S1504, S1506, but this is only an example and the order of each step is not limited to either. Therefore, S1504 and S1506 may be performed in different orders as necessary.
- the steps S1502, S1508, S1510, and S1512 may correspond to the steps S1202, S1206, S1302, and S1306, respectively. Therefore, the description regarding FIG. 12 and FIG. 13 is used.
- the request originator e.g entity 1
- the subscription request cannot be approved if the hosting entity (eg entity 2) is not authorized to send a notification to the notification recipient (eg entity 3).
- the network load is increased by the request originator (e.g., entity 1) attacking the hosting entity (e.g., entity 2) and the notification receiver (e.g., entity 3) with malicious intent. To reduce system performance or reduce system performance.
- the request originator e.g., Entity 1
- the hosting entity e.g. Entity 2
- the recipient of the notification e.g., regardless of the subscription request of the requesting sender (e.g. Entity 1) or by another entity with permission to change the settings on the notification receiver (e.g. In some cases, the entity may have a right to transmit a notification to the entity 3).
- the hosting entity eg, Entity 2 is a notification recipient (eg, if the hosting entity (eg, entity 2) has the authority to send notifications to the notification recipient (eg, entity 3). , Entity 3) can send a notification.
- a hosting entity e.g., Entity 2 notifies a notification recipient (e.g., Entity 3) by another entity (e.g., Entity 4) that has permission to change the settings on the notification receiver (e.g., Entity 3). You may have acquired the right to send.
- the request originator e.g., entity 1 can steal the rights obtained by the request of another entity (e.g., entity 4). In this case, there is a need for a hosting entity (eg Entity 2) to reject the request.
- the request sender e.g., entity 1 is authorized (or access right) to the notification receiver (e.g., entity 3) (e.g., NOTIFY / CREATE / UPDATE permission, etc.).
- the hosting entity e.g., Entity 2
- the hosting entity e.g., entity 2 is subscribed to from the requesting sender (e.g., entity 1). It may reject the request and send a response message containing the failure result to the request originator (eg entity 1).
- the request originator e.g., entity 1
- the notification recipient e.g., entity 3
- the hosting entity e.g., entity 2
- the request originator e.g., entity 1
- the hosting entity e.g., entity 2
- the notification recipient eg, Entity 3
- it may be verified whether the notification recipient (eg, Entity 3) is authorized to set up on behalf of the subscription to receive the notification.
- 16 illustrates a subscription and notification procedure in accordance with the present invention.
- Method 1 and method 2 according to the present invention can be applied together as needed.
- 16 illustrates an example in which Method 1 and Method 2 according to the present invention are applied together. However, this is only an example, and it is also possible to apply Method 1 and Method 2 according to the present invention independently.
- the request originator e.g., entity 1
- the notification receiver e.g., entity 3
- a hosting entity e.g., entity 2
- the hosting entity e.g., entity 2 causes the request originator (e.g., entity 1) to become a hosting entity (e.g., entity).
- S1504 in addition to checking whether or not there is a right to subscribe (S1504), verifying whether the hosting entity (e.g., entity 2) has the right to send a notification to a notification recipient (e.g., entity 3), and (S1506), the request originator (e.g., entity 1) also has the authority (or the authority to send a notification message or the subscription to send a notification message) to the notification receiver (e.g., entity 3). It can also be verified whether or not (S1607). Verification according to S1506 and verification according to S1607 may be performed when the request originator (eg, entity 1) and the notification receiver (eg, entity 3) are different. In the example of FIG. 16, it is illustrated as being performed in the order of S1504, S1506, S1607, but this is only an example and the order of each step is not limited to any one. Therefore, S1504, S1506, and S1607 may be performed in different orders as necessary.
- the request originator (e.g., Entity 1) may set up a subscription resource to the hosting entity (e.g., entity 2) for sending a notification to the notification receiver (e.g., entity 3).
- the request originator (eg Entity 1) can set two permissions in advance to the notification recipient (eg Entity 3). The first is for the hosting entity (e.g., Entity 2) to send notifications to the notification receiver (e.g., Entity 3), and the second is for the request sender (e.g., Entity 1) to notify the notification recipient (e.g., Entity 3).
- Rights that can be set as notification targets (eg, notification request rights for Entity 1) can be set.
- the hosting entity may determine whether the request originator (e.g., Entity 1) and the hosting entity (e.g., Entity 2) have rights to the notification receiver (e.g., Entity 3) as described above. You can confirm and approve the subscription.
- the hosting entity e.g, entity 2) may check the authority of the request originator (eg, Entity 1) and the notification receiver (eg, Entity 3) through the authority information of the notification receiver (eg, Entity 3).
- the request originator e.g., entity 1 or another entity
- the requesting sender e.g., entity 1 or another entity
- the notification recipient e.g. entity 3
- this theft prevents the problem of increased network load or reduced system performance between the hosting entity (eg entity 2) and the notification recipient (eg entity 3).
- a subscription / notification mechanism is maliciously used when a request originator (eg, Entity 1) and a notification receiver (eg, Entity 3) are different in a subscription request. Can be prevented.
- the hosting entity acquires the authority information set in the notification receiver (eg, Entity 3) to further perform the verification process (eg, S1506, S1607).
- the process is necessary and may not be efficient.
- the hosting entity eg, Entity 2 requests an additional verification process from the notification receiver (eg, Entity 3) without performing additional verification procedures (eg, S1506 and S1607).
- the notification receiver eg, Entity 3 proposes to perform an additional verification process and return the result to the hosting entity (eg, Entity 2).
- Authorization verification by a hosting entity (e.g., Entity 2) according to Method 1 and Method 2 is only possible if the hosting entity (e.g. Entity 2) has successfully obtained the latest entitlement information for the notification recipient (e.g., Entity 3). Do. If the information is not obtained, the successful verification cannot be performed, and the process of acquiring the authority information for the notification receiver (eg, Entity 3) may be a burden on the hosting entity (eg, Entity 2). Therefore, when applying Method 1 and / or Method 2, when performing verification by a hosting entity (eg, Entity 2) (Notification Sender), the authorization information may not be obtained or an overload for the authorization acquisition / confirmation may occur. May occur. On the other hand, when the method 3 is applied, the notification receiver (eg, entity 3) having the corresponding authority information performs verification, which may be more efficient.
- the hosting entity e.g. Entity 2
- the notification receiver (eg, entity 3) having the corresponding authority information performs verification, which may be more efficient.
- the notification receiver (eg, entity 3) assumes that the authority information is set in advance. Since the notification message is a request message (eg, a NOTIFY request), the notification message may include identification information (eg, fr) of a hosting entity (eg, entity 2) that generates and transmits the notification message. Therefore, based on the identification information of the hosting entity (eg, entity 2) included in the notification message and the preset authorization information, the notification receiver (eg, entity 3) is configured to be the notification entity (eg, entity). 3) it can be verified whether or not it has the authority to send a notification message. Through this, the notification receiver (eg, entity 3) may perform an operation corresponding to Method 1 of the present invention.
- identification information eg, fr
- the notification message may include identification information of the subscription creator (or request originator) (eg, entity 1) so that the notification receiver (eg, entity 3) may perform an operation corresponding to Method 2 of the present invention.
- attribute information for storing identification information of the subscription creator (or request originator) to be included in the notification message may be added to the subscription resource.
- the subscription resource may include attribute information (eg, creator attribute) indicating identification information of the entity or device that created the subscription resource.
- attribute information eg, creator attribute
- the constructor attribute information may include address information (eg, URI) of the entity or device that created the creator attribute information.
- a subscription creator (or request originator) (e.g., entity 1) sends a subscription request message to a hosting entity (e.g., entity 2)
- the hosting entity e.g., entity 2 becomes a subscription generator (e.g., included in the subscription request message).
- creator attribute information (eg, creator attribute) may be set based on identification information (eg, fr) of the request originator (eg, entity 1).
- the hosting entity eg, entity 2) may then include the identification information of the subscription creator (or request originator) (eg, entity 1) in the notification message when sending the notification message.
- the notification receiver based on the identification information of the subscription creator (or request sender) (eg entity 1) and preset authorization information included in the notification message, the notification receiver (eg entity 3) is configured to generate a subscription producer (or request originator) (eg Whether entity 1) has the right to send a notification message to the notification recipient (e.g. entity 3) (or has access to itself or has the right to set up a subscription to send a notification message to itself) Can be verified.
- the notification receiver eg, entity 3 may perform an operation corresponding to the method 2 of the present invention.
- a notification message sent to a notification receiver may be generated and sent by notification event occurrence, and verified by the hosting entity (eg entity 2) regardless of notification event occurrence. It may have been created for a request. If the request originator (e.g., entity 1) and the notification receiver (e.g., entity 3) are different, the notification message sent to the notification receiver (e.g., entity 3) is parameter information indicating a verification request for authorization verification according to the present invention. (Eg, verificationRequest). For example, when the notification receiver (eg entity 3) sends a notification message according to the method 3 of the present invention, the parameter information (eg verificationRequest) may be set to a constant value (eg TRUE).
- a hosting entity eg, entity 2 may receive a response to at least one notification message (or NOTIFY request) from a notification recipient (eg, entity 3) for verification.
- the received response may be a response message of the notification message first received after the subscription approval.
- the hosting entity eg, entity 2 is subject to the authorization of the request originator (eg, entity 1) (eg, the request originator (eg, entity 1) is subscribed to.
- the hosting entity After successfully verifying that the resource or subscription resource is authorized (S1704), the hosting entity (eg entity 2) immediately sends an acknowledgment of the subscription request to the request originator (eg entity 1). It may transmit (S1706).
- the acknowledgment of S1706 may indicate that the hosting entity (eg, entity 2) has temporarily accepted the subscription request. Thereafter, the hosting entity (e.g., entity 2) may temporarily approve the corresponding subscription request or store the relevant information internally until the response received from the notification receiver (e.g., entity 3) includes a successful verification result (S1716). have.
- the hosting entity may inform the request originator (eg, entity 1) of the status information of the subscription approval procedure.
- the hosting entity e.g., entity 2 in S1706 creates / approves a subscription and reconfirms it after successful verification in S1718,
- the subscription may be deleted, rejected, or canceled after the verification failure.
- the hosting entity e.g., entity 2 withholds the subscription approval and approves it after successful verification at S1718, or after verification failed at S1720. You can decline to approve the subscription.
- Step S1706 may be optional.
- the hosting entity may transmit a notification message to the notification recipient (eg, entity 3) that is the notification target.
- a notification message sent to a notification receiver (eg, entity 3) in S1708 may be generated and sent by a notification event occurrence, and verified by the hosting entity (eg, entity 2) regardless of the notification event occurrence. It may have been created for a request.
- the hosting entity eg, entity 2) may request a response to this by sending a notification message to the notification recipient (eg, entity 3).
- the notification receiver eg, entity 3) may check whether the hosting entity (eg, entity 2) is authorized to send a notification to it, and if not, may transmit a failure response message in S1714.
- the hosting entity (eg entity 2) can confirm this via a failure response message and delete the subscription resource later.
- the deletion of the subscription resource may be known to the request originator (eg entity 1).
- the hosting entity may determine whether the request originator (eg, Entity 1) and the notification receiver (eg, entity 3) are the same.
- the hosting entity e.g., entity 2) may be based on the identification information (or address information) of the request originator (e.g., Entity 1) and the identification information (or address information) of the notification receiver (e.g., entity 3). It is possible to determine whether the entities are identical.
- identification information (or address information) of the request originator (eg, Entity 1) may be obtained from fr information of the subscription request.
- the identification information (or address information) of the notification receiver may be obtained or extracted / inferred from notification target attribute information (eg, notificationURI attribute) of the subscription resource.
- the hosting entity eg, entity 2 may send a notification message if the request originator (eg, Entity 1) and the notification receiver (eg, entity 3) are different.
- the hosting entity e.g., entity 2
- the notification destination is not the request originator (e.g., Entity 1) (or the request originator (e.g., Entity 1) and the notification receiver (e.g., Entity 3) are different)
- the notification message e.g. Notify request message
- the request originator or subscription creator
- identification information e.g. ID
- the hosting entity e.g. entity 2 that is the notification sender. , May include identification information of entity 1).
- identification information of the request originator (eg, entity 1) may be stored in the hosting entity (eg, entity 2) as part of the subscription resource (eg, creator attribute information or creator attribute).
- the notification message (or NOTIFY request message) may not be transmitted only when a notification event actually occurs, and may be arbitrarily transmitted for verification. Also, for example, S1708 can be performed after S1706.
- the hosting entity e.g., entity 2
- the notification message may further include parameter information (eg, verificationRequest) indicating a verification request for authorization verification according to the present invention.
- the parameter information eg verificationRequest
- the parameter information may have a certain data type (eg boolean).
- the hosting entity e.g, entity 2) sends a notification message to the notification recipient (eg, entity 3) requesting authorization confirmation for subscription validation
- the parameter information is a constant value (eg, TRUE). Can be set.
- the notification receiver may recognize the notification message as a verification request.
- the notification receiver e.g. entity 3 may request a notification message according to a general notification procedure (e.g., by generating a notification event). It can be recognized as
- Notification recipients may determine whether the hosting entity (e.g., entity 2) has permission to send notification messages to them and / or subscription creators (or request senders) (e.g., entity 1) It is possible to verify whether or not to have the right to send a notification message (or the right to set up a subscription for sending a notification message to itself) (S1710, S1712). These verification processes may correspond to S1506 and S1607 illustrated in FIGS. 15 and 16. In FIG. 17, the order of S1710 and S1712 may be interchanged as necessary.
- the hosting entity judges the process S1706 to be a successful reception of a temporary approval or subscription request, even if a notification event occurs.
- (Or Notify requests) may not be sent to the notification recipient (eg Entity 3).
- the hosting entity eg, entity 2 may receive a subscription request, generate a subscription resource, and then send a notification message in step S1708.
- a notification event may occur due to the generated subscription resource.
- the notification message may be ignored or not transmitted to the notification receiver (eg, Entity 3).
- the information about the subscription approval state may be stored in the hosting entity (eg, Entity 2) as part of the subscription resource.
- the hosting entity (eg, Entity 2) may determine a corresponding subscription verification as success in S1716. If the S1706 temporarily approves the subscription request or maintains the subscription information internally, the subscription information may be explicitly created / stored. In S1718, the hosting entity (eg, Entity 2) may forward the final subscription approval confirmation to the subscription creator (or request originator) (eg, Entity 1).
- a response including a verification failure result is received in S1714, a timeout of the response message of S1714, or a notification receiver (for example, Entity 3) cannot recognize the request of S1708 and cannot perform verification.
- the hosting entity eg, Entity 2 recognizes the subscription verification as a failure and the corresponding subscription in S1720. You can cancel the procedure.
- the notification receiver eg, Entity 3 transmits a response message including a verification success result, it may be recognized as a timeout from the hosting entity (eg, Entity 2) due to a network problem. Therefore, in case of timeout, the hosting entity (eg, Entity 2) may repeat the process of S1708 without canceling the corresponding subscription procedure.
- the S1720 process may be a process of deleting the generated subscription information (or subscription resource).
- the hosting entity eg, Entity 2
- step S1720 may be a process of canceling / deleting such temporary / internal information.
- the hosting entity eg, Entity 2 may inform the subscription creator (or request originator) (eg, Entity 1) of the subscription cancellation / deletion.
- the subscription request may include multiple notification objects and in S1708 a notification message may be sent to a plurality of entities or devices.
- the hosting entity eg, Entity 2
- the hosting entity may take appropriate action in S1720.
- the entire subscription can be deleted / canceled or the notification target can be selectively deleted among all notification targets.
- This processing result may be delivered to the subscription creator (or request originator) (eg, Entity 1) in S1722.
- the request message of S1708 may correspond to a Notify request message transmitted by a hosting entity (eg, Entity 2) to a notification receiver (eg, Entity 3) when an actual notification event occurs.
- a hosting entity eg, Entity 2
- a notification receiver eg, Entity 3
- unnecessary subscription information should be generated / stored between S1706 and S1716.
- a very large Notify request message is transmitted in S1708 and then verification fails in S1714, it may cause problems such as unnecessary network resource consumption in S1708.
- step S1708 does not necessarily need to be a Notify request message due to the actual notification event occurrence, and the notification receiver (eg, Entity 3) may recognize a verify request of the hosting entity (eg, Entity 2) as shown in the drawing. Any message that can be is possible. Such a request message may be referred to as a verify request message.
- the verify request message may correspond to the case where there is no content for the subscribed resource in the Notify request message. Therefore, it is also possible to request verification in the form of Notify message even if the actual notification event does not occur.
- the notification recipient eg Entity 3 can return this result to the hosting entity (eg Entity 2). Even if the message type of S1708 does not necessarily transmit a response or this message does not explicitly require a response, the notification receiver (eg, Entity 3) may unconditionally return a response.
- the subscription creator (or request originator) (e.g., Entity 1) is informed in S1702 that the resulting message for the validation request of the hosting entity (e.g., entity 2) by the method 3 according to the present invention is hosted from the notification receiver (e.g., entity 3). You can specify time so that an entity (such as Entity 2) can be reached within a certain time. If not reached in time, the hosting entity (eg, Entity 2) may recognize this and inform the subscription creator (or request originator) (eg, Entity 1).
- Message transmission of the S1718 or S1722 is possible through a response message in the synchronous non-blocking mode and through a request message in the asynchronous non-blocking mode.
- the message format can be different, but the same information is delivered whether the subscription is approved or canceled.
- Method 1 and / or Method 2 prevents unauthorized hijacking of subscription-related privileges from other entities that may occur in the process of verifying only the permissions of the hosting entity (eg, Entity 2) when performing subscription verification. have.
- the attack eg, DDoS attack
- the hosting entity eg, Entity 2
- the hosting entity eg, Entity 2
- the hosting entity eg, Entity 2
- the burden of the hosting entity eg, Entity 2) performing this process every time a subscription request can be distributed to each notification receiver (eg, Entity 3).
- the right of the notification receiver eg, Entity 3) may be changed to cancel the subscription due to verification failure.
- the hosting entity may perform the verification process by always keeping the authority information of the notification receiver (eg, Entity 3) up to date through a separate process.
- the hosting entity eg, Entity 2 may receive a verification result based on the current authority information through a notification response from the notification receiver (eg, Entity 3) every time the notification message is transmitted.
- the M2M gateway, M2M server or M2M device may operate as the transmitter 10 or the receiver 20, respectively.
- the transmitter 10 and the receiver 20 are radio frequency (RF) units 13 and 23 capable of transmitting or receiving radio signals carrying information and / or data, signals, messages, and the like, and in a wireless communication system. It is operatively connected with components such as the memory (12, 22), the RF unit (13, 23) and the memory (12, 22) for storing a variety of information related to communication, by controlling the component
- the apparatus comprises processors 11 and 21, respectively, configured to control the memory 12 and 22 and / or the RF units 13 and 23 to perform at least one of the embodiments of the invention described above.
- the memories 12 and 22 may store programs for processing and control of the processors 11 and 21, and may store information input / output.
- the memories 12 and 22 may be utilized as buffers.
- the memories 12 and 22 may be used to store resources including various setting information and data.
- the processors 11 and 21 typically control the overall operation of the various modules in the transmitter or receiver. In particular, the processors 11 and 21 may perform various control functions for carrying out the present invention.
- the processors 11 and 21 may also be called controllers, microcontrollers, microprocessors, microcomputers, or the like.
- the processors 11 and 21 may be implemented by hardware or firmware, software, or a combination thereof.
- application specific integrated circuits ASICs
- DSPs digital signal processors
- DSPDs digital signal processing devices
- PLDs programmable logic devices
- FPGAs field programmable gate arrays
- the firmware or software when implementing the present invention using firmware or software, may be configured to include a module, a procedure, or a function for performing the functions or operations of the present invention, and configured to perform the present invention.
- the firmware or software may be provided in the processors 11 and 21 or stored in the memory 12 and 22 to be driven by the processors 11 and 21.
- the processor 11 of the transmission apparatus 10 is predetermined from the processor 11 or a scheduler connected to the processor 11 and has a predetermined encoding and modulation on a signal and / or data to be transmitted to the outside. After performing the transmission to the RF unit 13.
- the signal processing of the receiver 20 is the reverse of the signal processing of the transmitter 10.
- the RF unit 23 of the receiving device 20 receives a radio signal transmitted by the transmitting device 10.
- the processor 21 may decode and demodulate a radio signal received through a reception antenna to restore data originally transmitted by the transmission apparatus 10.
- the RF units 13, 23 have one or more antennas.
- the antenna transmits a signal processed by the RF units 13 and 23 to the outside under the control of the processors 11 and 21, or receives a radio signal from the outside to receive the RF unit 13. , 23).
- the transmitter and the receiver are respectively communicated through the RF unit, but it is also possible for the transmitter and the receiver to communicate through a wired network.
- the RF unit may be replaced with a network interface unit (NIU).
- NNIU network interface unit
- each component or feature is to be considered optional unless stated otherwise.
- Each component or feature may be embodied in a form that is not combined with other components or features. It is also possible to combine some of the components and / or features to form an embodiment of the invention.
- the order of the operations described in the embodiments of the present invention may be changed. Some components or features of one embodiment may be included in another embodiment or may be replaced with corresponding components or features of another embodiment. It is obvious that the claims may be combined to form an embodiment by combining claims that do not have an explicit citation relationship in the claims or as new claims by post-application correction.
- Certain operations described in this document as being performed by a base station may in some cases be performed by an upper node thereof. That is, it is obvious that various operations performed for communication with the terminal in a network including a plurality of network nodes including a base station may be performed by the base station or other network nodes other than the base station.
- a base station may be replaced by terms such as a fixed station, a Node B, an eNode B (eNB), an access point, and the like.
- the terminal may be replaced with terms such as a user equipment (UE), a mobile station (MS), a mobile subscriber station (MSS), and the like.
- Embodiments according to the present invention may be implemented by various means, for example, hardware, firmware, software, or a combination thereof.
- an embodiment of the present invention may include one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), FPGAs ( field programmable gate arrays), processors, controllers, microcontrollers, microprocessors, and the like.
- ASICs application specific integrated circuits
- DSPs digital signal processors
- DSPDs digital signal processing devices
- PLDs programmable logic devices
- FPGAs field programmable gate arrays
- processors controllers, microcontrollers, microprocessors, and the like.
- the present invention may be implemented by software code or instructions including a form of a module, procedure, function, etc. that performs the functions or operations described above.
- the software code or instructions may be stored in a computer readable medium and driven by the processor and may perform operations according to the present invention when driven by the processor.
- the computer readable medium may be located inside or outside the processor or remotely connected to the processor through a network, and may exchange data with the processor.
- the present invention can be used in communication devices such as terminals, servers, gateways, and the like.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Databases & Information Systems (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
Description
Claims (15)
- M2M(Machine-to-Machine) 디바이스에서 자원 구독(resource subscription)을 위한 메시지 처리 방법으로서,제1 디바이스로부터 구독 대상 자원에 대한 구독 요청 메시지를 수신하는 단계, 상기 구독 요청 메시지는 상기 제1 디바이스의 식별 정보와 제2 디바이스의 식별 정보를 포함하며;상기 제1 디바이스가 상기 구독 대상 자원에 대한 권한을 가지는지 여부를 확인하는 단계;상기 제1 디바이스의 식별 정보와 상기 제2 디바이스의 식별 정보를 기반으로 상기 제1 디바이스와 상기 제2 디바이스가 동일한지 여부를 판별하는 단계;상기 제1 디바이스와 상기 제2 디바이스가 서로 다른 경우, 상기 제1 디바이스의 식별 정보, 상기 M2M 디바이스의 식별 정보, 및 검증 요청을 지시하는 파라미터 정보를 포함하는 통지 메시지를 상기 제2 디바이스로 전송하는 단계; 및상기 제2 디바이스로부터 상기 통지 메시지에 대한 응답 메시지를 수신하는 단계를 포함하되,상기 제1 디바이스의 식별 정보와 상기 M2M 디바이스의 식별 정보를 기반으로 상기 제2 디바이스에 의해 상기 구독 요청에 대한 권한 확인이 수행되며,상기 응답 메시지는 상기 제2 디바이스에 의한 권한 확인의 결과를 포함하는, 방법.
- 제1항에 있어서,상기 제2 디바이스에 의한 권한 확인은 상기 M2M 디바이스가 상기 제2 디바이스로 통지 메시지를 전송할 수 있는 권한을 가지는지 여부를 확인하는 것을 포함하는, 방법.
- 제1항에 있어서,상기 제2 디바이스에 의한 권한 확인은 상기 제1 디바이스가 상기 제2 디바이스로 통지 메시지를 전송하기 위한 구독을 설정할 수 있는 권한을 가지는지 여부를 확인하는 것을 더 포함하는, 방법.
- 제1항에 있어서,상기 제2 디바이스로 상기 통지 메시지를 전송하는 단계 전에, 상기 제1 디바이스로 상기 구독 요청 메시지에 대한 임시 수락 메시지를 전송하는 단계를 더 포함하는, 방법.
- 제1항에 있어서,상기 제2 디바이스에 의한 권한 확인의 결과가 성공인지 여부를 판별하는 단계;상기 권한 확인의 결과가 성공인 경우, 상기 제1 디바이스로 구독 승인 메시지를 전송하는 단계; 및상기 권한 확인의 결과가 실패인 경우, 상기 자원 구독을 취소하는 단계를 더 포함하는, 방법.
- 제5항에 있어서,상기 권한 확인 결과가 실패인 경우, 상기 자원 구독이 취소되었음을 알리는 메시지를 상기 제1 디바이스로 전송하는 단계를 더 포함하는, 방법.
- 제1항에 있어서,상기 구독 요청 메시지는 상기 M2M 디바이스에서 구독 자원을 생성하기 위한 구독 정보를 포함하며,상기 방법은 상기 구독 정보를 임시로 저장하는 단계를 더 포함하는, 방법.
- 제1항에 있어서,상기 구독 요청 메시지는 상기 M2M 디바이스에서 구독 자원을 생성하기 위한 구독 정보를 포함하며,상기 방법은 상기 구독 정보를 기반으로 구독 자원을 생성하는 단계를 더 포함하는, 방법.
- 제8항에 있어서,상기 제1 디바이스의 식별 정보는 상기 구독 자원의 생성자 속성 정보에 저장되는, 방법.
- 제8항에 있어서,상기 통지 메시지는 상기 M2M 디바이스에서 통지 이벤트가 발생되는 경우 생성되며,상기 통지 이벤트는 상기 구독 대상 자원의 상태 변화를 포함하는, 방법.
- 제1항에 있어서,상기 통지 메시지는 상기 M2M 디바이스에서 통지 이벤트의 발생과 독립적으로 생성되는, 방법.
- 제1항에 있어서,상기 제1 디바이스의 식별 정보는 상기 구독 요청 메시지의 발신자를 지시하는 주소 정보를 포함하며,상기 제2 디바이스의 식별 정보는 상기 통지 메시지의 통지 대상을 지시하는 주소 정보를 포함하는, 방법.
- 제1항에 있어서,상기 자원은 고유한 주소를 이용하여 고유하게 어드레싱 가능한 데이터 구조를 나타내는, 방법.
- 제1항에 있어서,상기 구독 요청 메시지에서 응답 메시지 타입 정보는 블록킹 요청, 동기식 논-블록킹 요청, 비동기식 논-블록킹 요청 중 하나를 지시하는, 방법.
- M2M(Machine-to-Machine) 디바이스에 있어서, 상기 M2M 디바이스는네트워크 인터페이스 유닛(Network Interface Unit); 및상기 네트워크 인터페이스 유닛과 동작시 연결되는(operatively connected) 프로세서를 포함하며, 상기 프로세서는제1 디바이스로부터 구독 대상 자원에 대한 구독 요청 메시지를 수신하고, 상기 구독 요청 메시지는 상기 제1 디바이스의 식별 정보와 제2 디바이스의 식별 정보를 포함하며,상기 제1 디바이스가 상기 구독 대상 자원에 대한 권한을 가지는지 여부를 확인하고,상기 제1 디바이스의 식별 정보와 상기 제2 디바이스의 식별 정보를 기반으로 상기 제1 디바이스와 상기 제2 디바이스가 동일한지 여부를 판별하고,상기 제1 디바이스와 상기 제2 디바이스가 서로 다른 경우, 상기 제1 디바이스의 식별 정보, 상기 M2M 디바이스의 식별 정보, 및 검증 요청을 지시하는 파라미터 정보를 포함하는 통지 메시지를 상기 제2 디바이스로 전송하고,상기 제2 디바이스로부터 상기 통지 메시지에 대한 응답 메시지를 수신하도록 구성되며,상기 제1 디바이스의 식별 정보와 상기 M2M 디바이스의 식별 정보를 기반으로 상기 제2 디바이스에 의해 상기 구독 요청에 대한 권한 확인이 수행되며,상기 응답 메시지는 상기 제2 디바이스에 의한 권한 확인의 결과를 포함하는, M2M 디바이스.
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US15/023,193 US9883400B2 (en) | 2013-11-08 | 2014-11-06 | Method for subscription and notification in M2M communication system and device therefor |
CN201480061041.XA CN105723788A (zh) | 2013-11-08 | 2014-11-06 | 用于在m2m通信系统中进行订阅和通知的方法及其设备 |
KR1020167006721A KR20160082967A (ko) | 2013-11-08 | 2014-11-06 | M2m 통신 시스템에서 구독 및 통지를 위한 방법 및 이를 위한 장치 |
Applications Claiming Priority (14)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201361901453P | 2013-11-08 | 2013-11-08 | |
US61/901,453 | 2013-11-08 | ||
US201361910129P | 2013-11-29 | 2013-11-29 | |
US61/910,129 | 2013-11-29 | ||
US201461973790P | 2014-04-01 | 2014-04-01 | |
US61/973,790 | 2014-04-01 | ||
US201461977629P | 2014-04-10 | 2014-04-10 | |
US61/977,629 | 2014-04-10 | ||
US201461992917P | 2014-05-14 | 2014-05-14 | |
US61/992,917 | 2014-05-14 | ||
US201461994062P | 2014-05-15 | 2014-05-15 | |
US61/994,062 | 2014-05-15 | ||
US201462009929P | 2014-06-10 | 2014-06-10 | |
US62/009,929 | 2014-06-10 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2015069038A1 true WO2015069038A1 (ko) | 2015-05-14 |
Family
ID=53041737
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/KR2014/010616 WO2015069038A1 (ko) | 2013-11-08 | 2014-11-06 | M2m 통신 시스템에서 구독 및 통지를 위한 방법 및 이를 위한 장치 |
Country Status (4)
Country | Link |
---|---|
US (1) | US9883400B2 (ko) |
KR (1) | KR20160082967A (ko) |
CN (1) | CN105723788A (ko) |
WO (1) | WO2015069038A1 (ko) |
Cited By (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2016195199A1 (ko) * | 2015-06-04 | 2016-12-08 | 엘지전자 주식회사 | 무선 통신 시스템에서 폴링 채널을 통해 요청을 처리하기 위한 방법 및 이를 위한 장치 |
WO2017007239A1 (ko) * | 2015-07-09 | 2017-01-12 | 주식회사 케이티 | M2m 시스템에서 응답 정보를 수신하는 방법 및 그 장치 |
KR20170007691A (ko) * | 2015-07-09 | 2017-01-19 | 주식회사 케이티 | M2m 시스템에서 응답 정보를 수신하는 방법 및 그 장치 |
CN106656942A (zh) * | 2015-11-03 | 2017-05-10 | 电信科学技术研究院 | 角色令牌颁发方法、访问控制方法及相关设备 |
WO2017114241A1 (zh) * | 2015-12-31 | 2017-07-06 | 华为技术有限公司 | 一种获取资源的方法和装置 |
WO2017155161A1 (ko) * | 2016-03-09 | 2017-09-14 | 엘지전자 주식회사 | 무선 통신 시스템에서 요청을 리-타겟팅(re-target)하기 위한 방법 및 이를 위한 장치 |
WO2018066926A1 (ko) * | 2016-10-07 | 2018-04-12 | 주식회사 케이티 | M2m 시스템에서 요청 메시지를 전달하는 방법 및 그 장치 |
WO2018066917A1 (ko) * | 2016-10-07 | 2018-04-12 | 주식회사 케이티 | M2m 시스템에서 응답 메시지를 수신하는 방법 및 그 장치 |
KR20180038988A (ko) * | 2016-10-07 | 2018-04-17 | 주식회사 케이티 | M2m 시스템에서 요청 메시지를 전달하는 방법 및 그 장치 |
KR20180038989A (ko) * | 2016-10-07 | 2018-04-17 | 주식회사 케이티 | M2m 시스템에서 응답 메시지를 수신하는 방법 및 그 장치 |
WO2018236137A1 (ko) * | 2017-06-20 | 2018-12-27 | 주식회사 케이티 | M2m 시스템에서 요청 메시지를 처리하는 방법 및 그 장치 |
US11496552B2 (en) * | 2021-03-30 | 2022-11-08 | Dropbox, Inc. | Intent tracking for asynchronous operations |
Families Citing this family (23)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP6511520B2 (ja) * | 2014-10-28 | 2019-05-15 | コンヴィーダ ワイヤレス, エルエルシー | 下層ネットワークとのサービス層課金相関の方法および装置 |
EP3761593B1 (en) * | 2014-11-14 | 2023-02-01 | Convida Wireless, LLC | Permission based resource and service discovery |
CN107431878B (zh) * | 2015-03-30 | 2020-12-11 | 瑞典爱立信有限公司 | oneM2M环境中的M2M SP内部移动支持 |
CN107950038B (zh) * | 2015-05-20 | 2021-03-23 | 康维达无线有限责任公司 | 用于分析和群聚服务层订阅和通知以提高效率的方法和设备 |
JP6599546B2 (ja) * | 2015-08-13 | 2019-10-30 | コンヴィーダ ワイヤレス, エルエルシー | サービス層におけるアンルートリソース発見を可能にする方法 |
US10555170B2 (en) * | 2015-09-04 | 2020-02-04 | Huawei Technologies Co., Ltd. | Method and apparatus for authentication of wireless devices |
CN108353077B (zh) * | 2015-10-26 | 2021-03-30 | 三星电子株式会社 | 用于在异构系统之间的互通的方法和装置 |
WO2017087367A1 (en) * | 2015-11-16 | 2017-05-26 | Convida Wireless, Llc | Cross-resource subscription for m2m service layer |
US10129852B2 (en) * | 2016-06-01 | 2018-11-13 | Lg Electronics Inc. | Method for broadcasting to unspecified entity in wireless communication system and device for the same |
CN113159910A (zh) * | 2016-07-29 | 2021-07-23 | 京东方科技集团股份有限公司 | 进行通知的方法、装置和系统 |
KR102051839B1 (ko) | 2017-06-23 | 2020-01-08 | 삼성전자 주식회사 | M2m 시스템에서 메시지를 처리하는 방법 및 그 장치 |
WO2018236179A1 (ko) * | 2017-06-23 | 2018-12-27 | 주식회사 케이티 | M2m 시스템에서 메시지를 처리하는 방법 및 그 장치 |
CN108206856B (zh) * | 2017-09-30 | 2021-11-30 | 中兴通讯股份有限公司 | 信息反馈方法及装置 |
CN107770754A (zh) * | 2017-10-23 | 2018-03-06 | 中兴通讯股份有限公司 | 一种通知发送方法、装置和系统 |
KR102434673B1 (ko) * | 2018-12-13 | 2022-08-22 | 광동 오포 모바일 텔레커뮤니케이션즈 코포레이션 리미티드 | 구독 메시지의 처리 방법, 장치, 컴퓨터 장치 및 저장 매체 |
KR102647498B1 (ko) * | 2019-03-18 | 2024-03-15 | 주식회사 케이티 | M2m 시스템에서 통지 메시지 전송 방법 및 그 장치 |
KR102624642B1 (ko) * | 2019-03-18 | 2024-01-12 | 주식회사 케이티 | M2m 시스템에서 라이프타임 갱신 방법 및 그 장치 |
EP3972220A4 (en) * | 2019-05-13 | 2022-11-30 | Hyundai Motor Company | METHOD AND DEVICE FOR DELETING A RESOURCE IN AN M2M SYSTEM |
FR3099680B1 (fr) * | 2019-07-31 | 2021-06-25 | Renault Sas | Procédé de souscription à un géo-service dans une architecture MEC |
KR102182681B1 (ko) * | 2019-09-27 | 2020-11-24 | 한국전자기술연구원 | IoT/M2M 플랫폼에 저장된 데이터 판매 방법 |
KR20210041488A (ko) * | 2019-10-07 | 2021-04-15 | 현대자동차주식회사 | M2m 시스템에서 주기적인 통지를 송수신하는 방법 및 장치 |
KR20220007975A (ko) * | 2020-07-13 | 2022-01-20 | 한국전자기술연구원 | M2m 데이터 마켓플레이스를 이용한 m2m 데이터셋 판매 및 구매 방법 |
CN115623576A (zh) * | 2021-07-13 | 2023-01-17 | 华为技术有限公司 | 一种数据同步方法、装置及系统 |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2012068465A1 (en) * | 2010-11-19 | 2012-05-24 | Interdigital Patent Holdings, Inc. | Machine-to-machine (m2m) interface procedures for announce and de-announce of resources |
KR20120096528A (ko) * | 2009-11-23 | 2012-08-30 | 인터디지탈 패튼 홀딩스, 인크 | 기계 대 기계 통신 등록을 행하는 방법 및 장치 |
KR20130016613A (ko) * | 2011-08-08 | 2013-02-18 | 주식회사 케이티 | Ims 네트워크에서 mtc 디바이스의 접속을 제어하는 방법 및 장치 |
US20130066965A1 (en) * | 2011-09-12 | 2013-03-14 | Telefonaktiebolaget L M Ericsson (Publ) | Systems and methods for optimization of subscriptions to resource changes in machine-to-machine (m2m) systems |
KR101274966B1 (ko) * | 2011-12-07 | 2013-07-30 | 모다정보통신 주식회사 | M2m 통신에서 장치의 데이터 공유 방법 및 그 시스템 |
Family Cites Families (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101166333A (zh) * | 2006-10-18 | 2008-04-23 | 华为技术有限公司 | 多播广播业务的管理方法及系统 |
US8578153B2 (en) * | 2008-10-28 | 2013-11-05 | Telefonaktiebolaget L M Ericsson (Publ) | Method and arrangement for provisioning and managing a device |
WO2013048084A2 (ko) * | 2011-09-28 | 2013-04-04 | 주식회사 케이티 | 프로파일 관리 방법, 내장 uicc 및 내장 uicc 탑재 기기 |
US9338159B2 (en) * | 2012-03-19 | 2016-05-10 | Nokia Technologies Oy | Method and apparatus for sharing wireless network subscription services |
KR101550062B1 (ko) * | 2013-02-26 | 2015-09-04 | 주식회사 케이티 | M2m 디바이스의 제어권 공유 방법 및 이를 위한 m2m 서비스 플랫폼 |
KR101520247B1 (ko) * | 2013-02-27 | 2015-05-15 | 주식회사 케이티 | 생체 정보 관리 방법 및 시스템 |
-
2014
- 2014-11-06 CN CN201480061041.XA patent/CN105723788A/zh active Pending
- 2014-11-06 WO PCT/KR2014/010616 patent/WO2015069038A1/ko active Application Filing
- 2014-11-06 KR KR1020167006721A patent/KR20160082967A/ko not_active Application Discontinuation
- 2014-11-06 US US15/023,193 patent/US9883400B2/en active Active
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR20120096528A (ko) * | 2009-11-23 | 2012-08-30 | 인터디지탈 패튼 홀딩스, 인크 | 기계 대 기계 통신 등록을 행하는 방법 및 장치 |
WO2012068465A1 (en) * | 2010-11-19 | 2012-05-24 | Interdigital Patent Holdings, Inc. | Machine-to-machine (m2m) interface procedures for announce and de-announce of resources |
KR20130016613A (ko) * | 2011-08-08 | 2013-02-18 | 주식회사 케이티 | Ims 네트워크에서 mtc 디바이스의 접속을 제어하는 방법 및 장치 |
US20130066965A1 (en) * | 2011-09-12 | 2013-03-14 | Telefonaktiebolaget L M Ericsson (Publ) | Systems and methods for optimization of subscriptions to resource changes in machine-to-machine (m2m) systems |
KR101274966B1 (ko) * | 2011-12-07 | 2013-07-30 | 모다정보통신 주식회사 | M2m 통신에서 장치의 데이터 공유 방법 및 그 시스템 |
Cited By (22)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN107667550B (zh) * | 2015-06-04 | 2020-07-31 | Lg电子株式会社 | 无线通信系统中通过轮询信道来处理请求的方法及其设备 |
WO2016195199A1 (ko) * | 2015-06-04 | 2016-12-08 | 엘지전자 주식회사 | 무선 통신 시스템에서 폴링 채널을 통해 요청을 처리하기 위한 방법 및 이를 위한 장치 |
CN107667550A (zh) * | 2015-06-04 | 2018-02-06 | Lg电子株式会社 | 无线通信系统中通过轮询信道来处理请求的方法及其设备 |
US10560961B2 (en) | 2015-06-04 | 2020-02-11 | Lg Electronics Inc. | Method for processing request through polling channel in wireless communication system and apparatus therefor |
WO2017007239A1 (ko) * | 2015-07-09 | 2017-01-12 | 주식회사 케이티 | M2m 시스템에서 응답 정보를 수신하는 방법 및 그 장치 |
KR20170007691A (ko) * | 2015-07-09 | 2017-01-19 | 주식회사 케이티 | M2m 시스템에서 응답 정보를 수신하는 방법 및 그 장치 |
US11095747B2 (en) | 2015-07-09 | 2021-08-17 | Samsung Electronics Co., Ltd. | Method and apparatus for receiving response information in M2M system |
US20180205804A1 (en) * | 2015-07-09 | 2018-07-19 | Kt Corporation | Method and apparatus for receiving response information in m2m system |
KR101931858B1 (ko) * | 2015-07-09 | 2018-12-24 | 주식회사 케이티 | M2m 시스템에서 응답 정보를 수신하는 방법 및 그 장치 |
CN106656942A (zh) * | 2015-11-03 | 2017-05-10 | 电信科学技术研究院 | 角色令牌颁发方法、访问控制方法及相关设备 |
CN106656942B (zh) * | 2015-11-03 | 2019-12-13 | 电信科学技术研究院 | 角色令牌颁发方法、访问控制方法及相关设备 |
WO2017114241A1 (zh) * | 2015-12-31 | 2017-07-06 | 华为技术有限公司 | 一种获取资源的方法和装置 |
US11108870B2 (en) | 2015-12-31 | 2021-08-31 | Huawei Technologies Co., Ltd. | Resource acquiring method and apparatus |
WO2017155161A1 (ko) * | 2016-03-09 | 2017-09-14 | 엘지전자 주식회사 | 무선 통신 시스템에서 요청을 리-타겟팅(re-target)하기 위한 방법 및 이를 위한 장치 |
KR101960608B1 (ko) | 2016-10-07 | 2019-03-20 | 주식회사 케이티 | M2m 시스템에서 응답 메시지를 수신하는 방법 및 그 장치 |
KR20180038989A (ko) * | 2016-10-07 | 2018-04-17 | 주식회사 케이티 | M2m 시스템에서 응답 메시지를 수신하는 방법 및 그 장치 |
KR20180038988A (ko) * | 2016-10-07 | 2018-04-17 | 주식회사 케이티 | M2m 시스템에서 요청 메시지를 전달하는 방법 및 그 장치 |
WO2018066917A1 (ko) * | 2016-10-07 | 2018-04-12 | 주식회사 케이티 | M2m 시스템에서 응답 메시지를 수신하는 방법 및 그 장치 |
WO2018066926A1 (ko) * | 2016-10-07 | 2018-04-12 | 주식회사 케이티 | M2m 시스템에서 요청 메시지를 전달하는 방법 및 그 장치 |
WO2018236137A1 (ko) * | 2017-06-20 | 2018-12-27 | 주식회사 케이티 | M2m 시스템에서 요청 메시지를 처리하는 방법 및 그 장치 |
US11290860B2 (en) | 2017-06-20 | 2022-03-29 | Samsung Electronics Co., Ltd. | Method for processing request message in M2M system and device therefor |
US11496552B2 (en) * | 2021-03-30 | 2022-11-08 | Dropbox, Inc. | Intent tracking for asynchronous operations |
Also Published As
Publication number | Publication date |
---|---|
KR20160082967A (ko) | 2016-07-11 |
US20160234691A1 (en) | 2016-08-11 |
CN105723788A (zh) | 2016-06-29 |
US9883400B2 (en) | 2018-01-30 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
WO2015069038A1 (ko) | M2m 통신 시스템에서 구독 및 통지를 위한 방법 및 이를 위한 장치 | |
WO2015046960A1 (ko) | M2m 시스템에서 통지 메시지 전달 방법 및 이를 위한 장치 | |
WO2014185754A1 (ko) | M2m 통신 시스템에서 구독 및 통지를 위한 방법 및 이를 위한 장치 | |
WO2014129802A1 (ko) | M2m 서비스 설정 변경 방법 및 이를 위한 장치 | |
CN112586004B (zh) | 用于在用户设备组内使能专用通信的系统、方法和介质 | |
WO2014109597A1 (ko) | M2m(machine-to-machine)시스템에서 게이트웨이 변경 방법 및 이를 위한 장치 | |
EP3752947B1 (en) | Protecting a message transmitted between core network domains | |
WO2014200292A1 (ko) | M2m 시스템에서 위치 측정 방법 및 이를 위한 장치 | |
EP4167625A1 (en) | Communication method and apparatus | |
WO2016195199A1 (ko) | 무선 통신 시스템에서 폴링 채널을 통해 요청을 처리하기 위한 방법 및 이를 위한 장치 | |
WO2016068548A1 (ko) | 무선 통신 시스템에서 통지 메시지를 처리하기 위한 방법 및 이를 위한 장치 | |
WO2017073876A1 (ko) | 무선 통신 시스템에서 서비스 요청을 처리하기 위한 방법 및 이를 위한 장치 | |
WO2016126021A1 (ko) | 무선 통신 시스템에서 통지 수신 중단 요청을 처리하기 위한 방법 및 이를 위한 장치 | |
WO2017120746A1 (zh) | 一种网络访问权限管理方法及相关设备 | |
WO2016064235A2 (ko) | 무선 통신 시스템에서 그룹 멤버의 자식 자원을 관리하기 위한 방법 및 이를 위한 장치 | |
JP2023519631A (ja) | ネットワークスライス認証の制御方法、装置、機器及び記憶媒体 | |
JP7442690B2 (ja) | 安全な通信方法、関連する装置、およびシステム | |
WO2024144321A1 (en) | Apparatus and method for inter-plmn handover of home routed session in wireless communication system | |
WO2017082506A1 (ko) | 무선 통신 시스템에서 통지 수신 중단 요청을 처리하기 위한 방법 및 이를 위한 장치 | |
WO2020111761A1 (ko) | M2m 시스템에서 메시지 반복 전송 방법 및 장치 | |
WO2023282705A1 (ko) | 단말에 대한 네트워크 기능 개방 서비스 지원 방법 및 장치 | |
WO2018236137A1 (ko) | M2m 시스템에서 요청 메시지를 처리하는 방법 및 그 장치 | |
WO2013066131A2 (ko) | 이종 네트워크에서 개인 네트워크 사용정보에 기반한 pn 설정 방법 | |
WO2020166927A1 (ko) | 구독 및 통지를 수행하는 방법 및 장치 | |
WO2018084380A1 (ko) | 무선 통신 시스템에서 애플리케이션 장치의 상태와 그 상태를 나타내는 자원의 속성 값을 동기화하기 위한 방법 및 이를 위한 장치 |
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: 14860030 Country of ref document: EP Kind code of ref document: A1 |
|
ENP | Entry into the national phase |
Ref document number: 20167006721 Country of ref document: KR Kind code of ref document: A |
|
WWE | Wipo information: entry into national phase |
Ref document number: 15023193 Country of ref document: US |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 14860030 Country of ref document: EP Kind code of ref document: A1 |