WO2014200292A1 - M2m 시스템에서 위치 측정 방법 및 이를 위한 장치 - Google Patents

M2m 시스템에서 위치 측정 방법 및 이를 위한 장치 Download PDF

Info

Publication number
WO2014200292A1
WO2014200292A1 PCT/KR2014/005179 KR2014005179W WO2014200292A1 WO 2014200292 A1 WO2014200292 A1 WO 2014200292A1 KR 2014005179 W KR2014005179 W KR 2014005179W WO 2014200292 A1 WO2014200292 A1 WO 2014200292A1
Authority
WO
WIPO (PCT)
Prior art keywords
resource
gateway
location information
information
network
Prior art date
Application number
PCT/KR2014/005179
Other languages
English (en)
French (fr)
Inventor
안홍범
김성윤
최희동
정승명
박승규
Original Assignee
엘지전자 주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 엘지전자 주식회사 filed Critical 엘지전자 주식회사
Priority to US14/893,871 priority Critical patent/US9392571B2/en
Priority to KR1020157032916A priority patent/KR101689614B1/ko
Publication of WO2014200292A1 publication Critical patent/WO2014200292A1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W64/00—Locating users or terminals or network equipment for network management purposes, e.g. mobility management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H04W4/029—Location-based management or tracking services
    • 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]

Definitions

  • the present invention relates to a machine-to-machine (M2M) system, and more particularly to a method and apparatus for measuring the position of the M2M device in the M2M system.
  • M2M machine-to-machine
  • M2M communication refers to communication performed between a machine and a machine without human intervention, and is also referred to as machine type communication (MTC) or internet of things (IoT) communication.
  • MTC machine type communication
  • IoT internet of things
  • a terminal used for M2M communication is referred to as an M2M device, which is generally low mobility, time tolerant or delay tolerant, and small data transmission. It is used in connection with M2M server that centrally stores and manages communication information between machines.
  • M2M device when the M2M device is connected according to different communication methods, the M2M device and the M2M server are connected through the M2M gateway in a section in which the communication method is changed, thereby forming the entire M2M system.
  • services such as tracking, power metering, automatic payment system, medical service, and remote control may be provided.
  • the present invention relates to an M2M system.
  • Another object of the present invention is to provide a method and apparatus for efficiently performing a location measurement of an M2M device without location information in an M2M system.
  • Another object of the present invention is to provide a method for efficiently obtaining location information on a sharing basis in an M2M system and an apparatus therefor.
  • a method of performing a location measurement of a M2M device by a machine-to-machine gateway includes generating a request for generating a first resource indicating a location information acquisition method to a first M2M device.
  • the M2M gateway is determined as the closest device, and if the M2M gateway has network topology information and the at least one M2M device connected to the M2M gateway has location information, among the at least one M2M device
  • the device having the minimum number of hops from the first M2M device is determined as the nearest device, and the first resource may represent a data structure that can be uniquely addressed using address information.
  • an M2M gateway for performing position measurement of a machine-to-machine device (M2M)
  • the M2M gateway comprising: a network interface unit; And a processor, wherein the processor controls the network interface unit to receive a request for generation of a first resource indicating a location information acquisition scheme from a first M2M device, and wherein the generation request indicates information indicating sharing based location measurement.
  • determining the closest device from the first M2M device and setting the location information of the closest device as location information for the first M2M device, wherein the M2M gateway does not have network topology information; If at least one M2M device connected to the M2M gateway does not have location information, the M2M gateway is determined as the closest device, and the M2M gateway has network topology information and the at least one M connected to the M2M gateway.
  • the 2M device has location information, the device having the minimum number of hops from the first M2M device among the at least one M2M device is determined as the closest device, and the first resource is uniquely addressed using address information. It can represent a possible data structure.
  • the device having the latest location information may be determined as the device closest to the first M2M device.
  • setting the location information may include storing location information of a device closest to the first M2M device in a second resource for storing location information of the first M2M device.
  • the network topology information may indicate a physical connection between a list of M2M devices connected to the M2M gateway and M2M devices connected to the M2M gateway.
  • the first M2M device may be a device that does not have positioning determination capability and does not have network-based positioning capability.
  • the position can be measured efficiently in the M2M system.
  • location information can be efficiently obtained on a sharing basis in the M2M system.
  • FIG. 2 illustrates a layered structure of an M2M system.
  • FIG. 3 illustrates a functional architecture of an M2M system.
  • FIG. 5 illustrates a resource used in an M2M system.
  • FIG. 6 illustrates a resource for a particular M2M application.
  • FIG. 7 illustrates a communication flow of a typical M2M system.
  • FIG 8 illustrates an example in which different entities interoperate in an M2M system.
  • FIG. 9 illustrates the structure of an overlay network and a base network of an M2M system.
  • FIG. 10 illustrates a resource for storing a manner of obtaining location information of a target terminal according to the present invention.
  • FIG. 11 illustrates a resource for storing location information of a target terminal according to the present invention.
  • FIG. 12 illustrates a resource for storing attribute information of an M2M terminal according to the present invention.
  • FIG. 13 illustrates a network topology
  • FIG. 15 illustrates an example of an M2M gateway performing a location measurement procedure according to the present invention.
  • FIG. 16 illustrates the flow of a position measurement procedure according to the present invention.
  • FIG. 17 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 and / or the M2M gateway 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 ( It may be referred to as a wireless modem, a handheld device, a node, or 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 area network may mean a form of physical network connection, but is not limited thereto, and in other examples, the M2M area network may mean a form of logical network connection.
  • 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.
  • 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 312 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 312 may refer to the 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.
  • a node may be generally referred to as an M2M device, and ASN, ADN, MN, and IN may be referred to as an M2M device, a limited M2M device, an M2M gateway, or an M2M server, respectively.
  • case 1 illustrates communication between ADN 402 and IN 422.
  • ADN 402 may be an M2M device with limited capabilities.
  • the ADN 402 does not have a CSE or common service layer and thus can communicate with the CSE of the IN 422 through Mca.
  • the ADN 402 does not have a CSE or common service layer and thus cannot store / share data generated at the AE or application layer to other entities.
  • data generated at the AE or application layer of the ADN 402 may be stored and shared in the CSE of the IN 422.
  • Case 2 illustrates communication between ADN 404 and MN 414.
  • ADN 404 may also be an M2M device with limited capabilities.
  • ADN 404 may operate similarly to case 1 except that ADN 404 communicates with the CSE of MN 414. That is, ADN 404 may communicate with the CSE of MN 414 via Mca.
  • the ADN 404 does not have a CSE or common service layer and thus cannot store / share data generated at the AE or application layer to other entities. Accordingly, data generated at the AE or application layer of the ADN 404 may be stored and shared in the CSE of the MN 414.
  • the MN 414 may communicate with the IN 422 via the MN 412.
  • the MN 414 and the MN 412, and the MN 412 and the IN 422 may communicate through Mcc. It is also possible for the MN 414 to communicate with the IN 422 directly without passing through the MN 412.
  • Case 3 illustrates the communication between ASN 406 and MN 414.
  • the ASN 406 has a CSE or common service layer, so that the data generated at the AE or application layer of the ASN 406 may have its own CSE or common service layer. Can be stored in
  • the AE of the ASN 406 may communicate with the CSE of the MN 414 via the CSE of the ASN 406.
  • Case 4 illustrates the communication between ASN 408 and MN 414. Compared to case 3, the CSE of ASN 408 can communicate with the CSE of IN 422 directly without going through the MN.
  • the IN 422 or 424 may be located in an infrastructure domain or a network domain and may include one CSE and zero or more AEs.
  • the INs 422, 424 can communicate with each other via Mcc.
  • FIG. 5 illustrates a resource used in an M2M system.
  • an application entity a CSE, data, etc.
  • a resource refers to a uniquely addressable entity using a unique address (eg, a Universal Resource Identifier or Uniform Resource Identifier (URI)).
  • resources are represented as specific data structures, and each resource can be logically connected to each other. Resources may be managed and stored by the CSE or common service layer. Thus, the CSE or the common service layer of the M2M device, the M2M gateway, the M2M server may have these resources.
  • the AE or application layer of the M2M system may not have this resource structure.
  • Each resource has a child resource and attributes.
  • a root resource may have an attribute and a child resource.
  • resources can be represented as a tree structure.
  • the type of the root resource may be represented as ⁇ baseURI> or ⁇ CSEBase>.
  • the type of resource may be indicated by " ⁇ " and ">".
  • M2M applications can communicate based on resources whose resource types are instantiated. For example, it can be used to perform M2M services such as registering an application and reading sensor values.
  • Each resource is given unique address information (e.g. URI) when an instance of that resource type is created, and can have the same properties and child resources as the root resource.
  • Each resource is addressed using unique address information.
  • the specific resource type defines the child resources and attributes that the resource can have when instantiated. In a specific resource instantiation, a resource may have attributes and child resources defined in the resource type of the resource.
  • Child resources can have their own attributes and their own child resources.
  • child resources include remote CSE resources, application entity resources, access control resources, container resources, group resources, subscription resources, and so on.
  • the remote CSE resource contains information of other CSEs registered (connected) to the CSE.
  • the type of the remote CSE resource may be indicated as ⁇ entity> or ⁇ remoteCSE>.
  • Application entity resources of the root resource e.g. ⁇ baseURI> / ⁇ application> or ⁇ CSEBase> / ⁇ AE>
  • remote CSE resources of the root resource e.g. ⁇ baseURI> / ⁇ entity> or ⁇ CSEBase
  • ⁇ remote CSE> e.g. ⁇ remote CSE>
  • the information of the registered application entity is stored, and the information of the application entities registered in the specific remote CSE when it exists under the remote CSE resource (eg, ⁇ baseURI> / ⁇ entity> or ⁇ CSEBase> / ⁇ remote CSE>) of the root resource. Save it.
  • the type of application entity resource may be indicated as ⁇ application> or ⁇ AE>.
  • -Access Control Resource 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 the resource is changed through notification.
  • the type of the subscription resource may be indicated as ⁇ subscription>.
  • resources for a specific M2M application may be stored in an Application Resource in a resource of a CSE or a common service layer of the M2M Gateway.
  • Resources for a particular M2M application may have attributes and child resources similar to the entire resource.
  • the child resource is defined as a type (eg, denoted by “ ⁇ ”, “>”), and the actual name is given and stored when materialized.
  • FIG. 7 illustrates a communication flow of a typical M2M system.
  • the operation of the M2M system is performed based on the data exchange.
  • a specific device may transmit a corresponding command in the form of data to another device to stop the operation of another device.
  • a specific type of data structure is used to store data in the device, which is called a resource.
  • a resource refers to an entity that can be addressed or accessed using a unique address (eg, a URI) and can be represented as a specific data structure.
  • a Request and Response Scheme is used in the connection between the AE and the CSE or in the connection between the CSEs.
  • the originator may send a request message to request a resource stored in a receiver and receive a response message in response.
  • the recipient may receive a message requesting a resource from the sender and send a response message to the sender in response.
  • a request message may be abbreviated as a request and a response message may be abbreviated as a response.
  • the request message transmitted from the sender to the receiver may include the following information.
  • op the type of operation to be performed. It may be one of Create / Retrieve / Update / Delete / Notify.
  • information corresponding to an operation may be referred to as a command.
  • the response message may include the following information.
  • the response message may include at least one of the following information, or may include only the result value rs.
  • identification information (or ID) of the originator that created the request
  • rs the result of the request (e.g. Okay, Okay and Done, Okay and in progress)
  • the response message may include the following information.
  • the sender may represent the sender device (or CSE or AE therein) and the receiver may represent the receiver device (or CSE or AE therein).
  • a device (or a CSE therein) that has a resource is referred to as a hosting device (or a hosting CSE).
  • the sender can use the manner illustrated in FIG. 7 to create a resource on the receiver.
  • the sender may send a resource creation request message (eg, a CREATE request) to the receiver.
  • the resource creation request message may include the following information.
  • cn Includes attribute information of a generation target resource and may optionally include identification information (eg, name of a generation target resource) of the generation target resource.
  • the receiver checks whether the sender is authenticated. Since information on the resource to be created (eg, access rights or access control policy) is not yet known to the receiver, the receiver can determine whether to create the resource by authenticating the sender. Generation of the target resource may be allowed if the sender is authenticated.
  • the receiver verifies whether the identification information of the generation target resource already exists in the receiver's resource structure. If valid identification information is not provided (for example, when identification information of a generation target resource is duplicated), the receiver may allocate identification information of the generation target resource. Similarly, if the resource generation request message does not include identification information of the generation target resource, the receiver may allocate identification information of the generation target resource.
  • the receiver may send a response message including the following information to the sender.
  • cn URI and / or content of the created resource
  • the sender may use the scheme illustrated in FIG. 7 to retrieve information about a resource (eg, attribute information) on the recipient.
  • the sender may send a recovery request message (eg, a RETRIEVE request) to the receiver to retrieve information (eg, attribute information) about the resource on the receiver.
  • the sender may retrieve all attributes or only some of the attributes from the recipient's target resource through the recall request message.
  • the retrieval request message may include the following information.
  • the receiver When the receiver receives the recall request message from the sender, the receiver checks whether the recalled resource exists in the recall request message and verifies whether the sender has permission for retrieving the recalled resource. Check it. If the resource to be recovered does not exist or the sender does not have the proper recovery authority, the receiver can send an error through the response message. On the contrary, if the resource to be recovered exists and the sender has the right recovery right, the receiver can send a response message to the sender.
  • the response message may include the following information.
  • the sender may use the procedure illustrated in FIG. 7 to update attribute information at a particular resource on the receiver.
  • the sender may transmit an update request message (eg, an UPDATE request) to the receiver.
  • the sender may update the attribute information with a new value in a specific resource on the receiver through an update request message.
  • the update request message may include the following information.
  • the receiver When the receiver receives the update request message from the sender, it verifies that the update target resource exists by referring to the URI of the update target resource in the update request message, and whether the sender is authorized to modify the update target resource. is authorized to perform modifying the target resource). If the update target resource exists and the sender has been properly authorized, the receiver may update the update target resource with information to be updated (eg, cn). If successfully updated, the receiver can send a response message to the sender.
  • the response message may include the following information.
  • the sender can use the procedure illustrated in FIG. 7 to delete a particular resource on the receiver.
  • the sender may transmit a delete request message (eg, a DELETE request) to the receiver.
  • the deletion request message may include the following information.
  • the recipient request message is referenced in the recall request resource to verify that the deleted resource exists and whether the sender is authorized to delete the target resource. authorized to delete the target resource). If the target resource does not exist or the sender is not authorized, the receiver can send an error through the response message. On the contrary, if the target resource exists and the sender is authorized, the receiver may send a response message including the following information to the sender.
  • FIG 8 illustrates an example in which different entities interoperate in an M2M system.
  • the M2M device may include a sensor that is a physical device, and stores information obtained from the sensor in the CSE, and the AE registered in the IN may read the sensor value stored in the M2M device.
  • the AE (application1) existing on the M2M device reads the value from the sensor and stores the read value in the form of a resource (eg, ⁇ container> resource) in the CSE (dcse) registered by the sensor. To this end, the AE (application1) existing on the M2M device must first register with the CSE present in the M2M device. As illustrated in FIG. 8, when registration is completed, M2M application related information registered in the form of a dcse / applications / application1 resource is stored.
  • a resource eg, ⁇ container> resource
  • an AE application2 registered in an IN (Infrastructure Node) may access the value.
  • AE application2 must be registered in the CSE (ncse) of the M2M server to access the M2M device. This is stored in the ncse / applications / application2 resource information about the AE (application2), such as how the AE (application1) is registered in the CSE (dcse).
  • the AE (application1) may communicate directly with the intermediate CSE (ncse) and CSE (dcse) rather than directly communicating with the AE (application2).
  • CSE (ncse) and CSE (dcse) must be mutually registered.
  • CSE (dcse) registers with CSE (ncse) dcse related information (eg, Link) is stored under ncse / cses / dcse resource.
  • the AE (application2) obtains a path for accessing the information of the AE (application1) and can read the value of the sensor through the corresponding path.
  • FIG. 9 illustrates the structure of an overlay network and a physical network of an M2M system.
  • the M2M system (eg, oneM2M) is configured with an overlay network structure.
  • An overlay network conceptually means a virtual network established on a physical network. Nodes in this overlay network structure (for example, in oneM2M, ADN, ASN, MN, IN, etc. may be mapped to nodes as described above, or may be mapped to M2M devices, limited M2M devices, M2M gateways, M2M servers). It can be connected by virtual or logical links. Each link is through many physical links within an actual physical network, but does not consider the physical link for communication or actual operation.
  • the network may be physically connected by four hops in the physical network, but may be seen as connected by two hops in the overlay network.
  • Hop is a term that collectively refers to a connection between a node and a node existing in a network.
  • information representing a node and a connection between the nodes and a network structure as a list between nodes may be referred to as topology information.
  • Nodes can be created due to functional differences. For example, some devices performing special functions in the physical network may be selected as overlay nodes. Each device may be selected as a physical network node.
  • the physical network may be connected to Bluetooth, Wi-Fi, and Wide Area Network, and each network may have an M2M gateway.
  • the devices A, B, and C are physical nodes in the base (or physical) network
  • the Wi-Fi network the devices C, D, and E are physical nodes in the base (or physical) network.
  • the devices E, F, and G may be physical nodes.
  • the remaining nodes B, D, and F except each gateway may not be visible, and the gateways A, C, E, and G may be viewed as nodes.
  • the M2M common service layer may retrieve location information through a location server or store location information through an application.
  • the location server may refer to an entity that exists in a network operator network that owns a mobile communication network, provides help information necessary for calculating a location of a terminal, or directly participates in location calculation.
  • Bringing location information through an application means that nodes containing AEs, such as M2M devices (ASNs) or restrictive M2M devices (ADNs), are outside the normalization domain (for example, in addition to passing information in Mcc, Mca, Mcn Reference Points).
  • ASNs M2M devices
  • ADNs restrictive M2M devices
  • it may refer to storing its own location in a resource. For example, location information acquired internally through a GPS module may be stored in a resource.
  • the M2M device to obtain the location information is a limited M2M device with limited resources or limited ability, the following problem may occur.
  • the location server is typically a component of the core network of the telecommunications network, so if it is not an M2M device based on the telecommunications network (e.g. a device without a Universal Subscriber Identity Module (USIM)) You may not be able to connect.
  • M2M Universal Subscriber Identity Module
  • location information cannot be obtained through the application There may be a device in the M2M system that does not have the capability to obtain location information through the application.
  • bringing location information through the application refers to the AE at the node obtaining its location information through Device Capability with its logic.
  • the AE may directly control the GPS module to obtain location information, or may obtain location information through another device or a logical method.
  • the device may not be able to obtain its location information.
  • a blood pressure monitor node
  • the blood pressure device does not need to be connected to a location server separately for the purpose of cost reduction, and may not have a separate device or logical algorithm for location acquisition such as GPS.
  • the location information of the blood pressure monitor can be grasped, it can provide the scalability of the service in an emergency situation.
  • the present invention proposes a method of determining the location information of the limited M2M device when the M2M device cannot obtain the location information in the M2M system.
  • the present invention proposes a resource for storing a method of obtaining location information of a target terminal and a resource for storing location information of a target terminal.
  • the target terminal may refer to a node (or device) to obtain location information.
  • FIG. 10 illustrates a resource for storing a manner of obtaining location information of a target terminal according to the present invention.
  • a resource for storing a method of obtaining location information of a target terminal is referred to as a ⁇ locationPolicy> resource, but other names may be used.
  • the ⁇ locationPolicy> resource represents a method for obtaining and managing geographic location information of an M2M device.
  • the ⁇ locationPolicy> resource is not used to store location information, but is used as a resource that stores a manner of obtaining and managing location information.
  • the actual location information is stored in the ⁇ instance> resource, which is a child resource of the ⁇ container> resource.
  • the ⁇ container> resource may have attribute information (eg, locationID) that holds the URI of the ⁇ locationPolicy> resource as a linkage.
  • the location common service function (LOC CSF) (see FIG. 3) may obtain location information based on attributes defined under the ⁇ locationPolicy> resource and store the location information in the target ⁇ container>.
  • LOC CSF location common service function
  • Table 1 illustrates an ⁇ locationPolicy> resource related attribute.
  • R / W represents read / write permission of the property and may be one of READ / WRITE (RW), READ ONLY (RO), and WRITE ONLY (WO).
  • the number of occurrences (multiplicity) indicates the number of times a corresponding attribute can occur in a ⁇ locationPolicy> resource. Therefore, when the multiplicity is 1, the corresponding attribute is included as one mandatory in the ⁇ locationPolicy> resource, and at least one is essential when 1..n and optional when 0..1. (optional) One or less may be included, and in the case of 0..n, one or more may be optionally included.
  • Table 1 is only an example and the attributes of the ⁇ locationPolicy> resource may be configured differently from Table 1.
  • the ⁇ locationPolicy> resource may be handled using the request / response scheme described with reference to FIG. 7.
  • the AE sends a create request message to the hosting CSE, to retrieve the ⁇ locationPolicy> resource, the AE sends a recall request message to the hosting CSE and sends the ⁇ locationPolicy> resource.
  • the AE sends an update request message to the hosting CSE, and to remove the ⁇ locationPolicy> resource, the AE can send a removal request message to the hosting CSE.
  • the request message for creating a ⁇ locationPolicy> resource may include the following information.
  • fr identifier of the AE or CSE that generated the request
  • the response message to the request for creating the ⁇ locationPolicy> resource may include a representation of the generated ⁇ locationPolicy> resource, and the attribute values specified in Table 1 are set in the representation.
  • the recovery request message of the ⁇ locationPolicy> resource may include the following information.
  • fr identifier of the AE or CSE that generated the request
  • the response message to the request for retrieval of the ⁇ locationPolicy> resource may include the following information.
  • the update request message of the ⁇ locationPolicy> resource may include the following information.
  • fr identifier of the AE or CSE that generated the request
  • the response message for the update request of the ⁇ locationPolicy> resource may include the following information.
  • the deletion request message of the ⁇ locationPolicy> resource may include the following information.
  • fr identifier of the AE or CSE that generated the request
  • the response message to the deletion request of the ⁇ locationPolicy> resource may include the following information.
  • FIG. 11 illustrates a resource for storing location information of a target terminal according to the present invention.
  • the resource for storing the location information of the target terminal is referred to as a ⁇ container> resource, but other names may be used.
  • the ⁇ container> resource represents a container for a data instance. This resource can be used to share information between different entities and can be used to track data.
  • the container resource may have attribute information and child resources.
  • Table 2 illustrates the ⁇ container> resource related attributes.
  • R / W represents read / write permission of the property and can be one of READ / WRITE (RW), READ ONLY (RO), and WRITE ONLY (WO).
  • RW READ / WRITE
  • RO READ ONLY
  • WO WRITE ONLY
  • Table 2 the number of occurrences (multiplicity) indicates the number of times a corresponding attribute can occur in a ⁇ container> resource.
  • Table 2 is only an example and the attributes of the ⁇ container> resource may be configured differently from Table 2.
  • FIG. 12 illustrates a resource for storing attribute information of an M2M device according to the present invention.
  • a resource for storing attribute information of the M2M device is referred to as a ⁇ node> resource, but other names may be used.
  • the ⁇ node> resource may include specific information of an M2M device that may be used by another M2M operation.
  • the CMDH CSF may determine when to send a request message to the target CSE based on the reachability schedule of the target CSE.
  • the ⁇ node> resource contains information such as the reachability schedule, context information (e.g. memory and storage), and the network topology of devices connected to the M2M gateway if the device represented by the ⁇ node> resource is an M2M gateway. I can hold it.
  • the ⁇ node> resource includes information of a specific M2M device (or node) and may include additional information for supporting M2M operation. Node specific information such as memory and storage may be obtained by existing device management techniques (eg, Open Mobile Alliance (OMA) Device Management (DM), etc.) or other methods (eg, Java Native Interface (JNI)).
  • OMA Open Mobile Alliance
  • DM Device Management
  • JNI Java Native Interface
  • the location of the ⁇ node> resource may vary depending on the type of device.
  • a ⁇ node> resource for an M2M device ASN
  • ASN M2M device
  • ADN restrictive M2M device
  • ADN restrictive M2M device
  • MN M2M gateway
  • Table 3 illustrates the child resources that a ⁇ node> resource can have.
  • the number of occurrences indicates the number of times a corresponding resource can occur in a ⁇ node> resource.
  • Table 3 is only an example, and ⁇ node> resources may be configured differently from Table 3.
  • FIG. 13 illustrates a network topology.
  • a resource for storing network topology information is referred to as a ⁇ networkTopology> resource, but may also be referred to as another name.
  • the ⁇ networkTopology> resource is a child resource of the ⁇ node> resource and may be defined when the device having the ⁇ node> resource is an M2M gateway (MN).
  • the network topology information describes a list of M2M devices (ASN or ADN) connected to the M2M gateway (MN) and describes a physical relation or an underlying relation between nodes of the M2M area network.
  • the network topology information may include configuration information of the M2M area network that is actually physically connected. Network topology information may be referred to simply as topology information.
  • the ⁇ networkTopology> resource is used to store network topology information.
  • the overlay network may be a oneM2M network and the physical network may be a Zigbee network.
  • each ADN eg, ADN_1 to ADN_5
  • Mca reference point regardless of the configuration of the physical network. Therefore, in view of the overlay network, each ADN and MN can be regarded as being connected by one hop.
  • each ADN eg, ADN_1 to ADN_5
  • ADN_2 may be connected to the MN by two hops
  • ADN_5 may be connected to the MN by four hops.
  • the network topology information includes configuration information of a physical network and may indicate connection relationships between real nodes.
  • the ⁇ networkTopology> resource contains information describing the relationship of nodes in terms of physical networks.
  • LOC CSF Location Common Service Function
  • M2M AEs allows M2M AEs to obtain geographic location information of M2M nodes (eg, ASN, MN) for location based services. Such location information may be requested from M2M AEs present on a local node or a remote node.
  • the LOC CSF may obtain and manage geographic location information based on requests from M2M AEs present on the local node or remote node.
  • the LOC CSF may interact with at least one of a location server in an underlying network, a GPS module in an M2M device, or information for inferring a location stored in other M2M nodes.
  • the M2M AE may set a ⁇ locationPolicy> resource attribute (eg, locationSource attribute or locationUpdatePeriod attribute) stored in the CSE. Based on the defined attributes, the LOC CSF can update the location information using one of the defined interactions.
  • the LOC CSF may request M2M nodes to share / report their geographic location information or geographic location information of other M2M nodes with M2M applications. Additionally, the LOC CSF may provide a means for protecting the confidentiality of geographic location information.
  • a process of storing or changing information in a resource eg, ⁇ locationPolicy> resource
  • a resource eg, ⁇ container> resource
  • the present invention proposes a method of obtaining location information of a target terminal.
  • the present invention defines a method for obtaining location information of a target terminal through the generation of a ⁇ locationPolicy> resource, for example, and obtains the ⁇ container> resource (or ⁇ instance> resource of a child resource in a ⁇ container> resource) in the CSE It works by storing location information.
  • the AE may create a ⁇ locationPolicy> resource in the CSE to which the AE is connected.
  • the sender AE may request to create a ⁇ locationPolicy> resource that contains the relevant attributes and the address of the root (eg, ⁇ baseURI>) resource of the hosting CSE (see FIGS. 7 and 10). See description).
  • the creation request may include at least one of the attributes illustrated in Table 1.
  • the receiver may perform the following operation.
  • the resources may have a cross-reference attribute. For example, a cross-reference may be formed between a locationContainerID attribute for a ⁇ locationPolicy> resource and a locationID attribute for a ⁇ container> resource.
  • the hosting CSE performs the procedure according to the defined properties and generates the result (e.g., position fix, uncertainty, etc.). Can be stored in a ⁇ container> resource.
  • the positioning procedure may be performed only when the ⁇ container> resource in which the location information is stored is retrieved.
  • the locationSource property may be set based on the capability of the network where the caller who requested the location information and the target terminal exists. If the locationSource property is set to either network-based, device-based, or shared-based and the locationUpdatePeriod property is set to a value greater than 0, you can proceed to the next step.
  • the locationSource property can be set to one of the following:
  • the hosting CSE may translate the request received from the sender into a request to the location server according to the attributes defined in the ⁇ locationPolicy> resource (eg locationTargetID, locationServer, etc.). If one of the attributes (eg locationTargetID, locationServer, etc.) cannot be retrieved, the hosting CSE may reject the request with an error code.
  • the hosting CSE may also provide default values for other parameters of the location server request in accordance with local policy.
  • the location server can then perform a location measurement procedure on the underlying network and return the results.
  • the hosting CSE may store the returned location information in a ⁇ container> resource.
  • the mechanism used to communicate with the location server may depend on the capabilities of the underlying network and other factors.
  • the communication between the hosting CSE and the location server may follow the Open Mobile Appliance (OMA) mobile location protocol or OMA RESTful NetAPI for terminal location.
  • OMA Open Mobile Appliance
  • the hosting CSE may repeat the above procedure based on the period information (eg, locationUpdatePeriod attribute).
  • the location server may periodically notify the hosting CSE of the location information based on the period information.
  • the hosting CSE may perform a positioning procedure using a location measurement module or technology. For example, when the M2M device (ASN) has a GPS module, the ASN-CSE may obtain location information of the M2M device from the GPS module through an internal interface (eg, a system call). The hosting CSE may repeat the above procedure based on the period information (eg, locationUpdatePeriod attribute).
  • the sender is a restricted M2M device (ADN-AE)
  • the hosting CSE is an MN-CSE of the M2M gateway (MN)
  • the restricted M2M device is a resource-limited node ( resource constrained node).
  • a resource constrained node may refer to a node that does not have location determination capability (eg, GPS) and does not have network based positioning capability.
  • the hosting CSE may collect topology information of the M2M area network by using the ⁇ node> resource.
  • the hosting CSE may find the node closest to the originator among the nodes registered with the hosting CSE and having location information.
  • the nearest node may be determined by the minimum number of hops based on the collected topology information. If the hosting CSE can find the closest node, the location information of the nearest node can be stored as the location information of the caller. If the hosting CSE cannot find the nearest node, the location information of the hosting CSE may be stored as the sender's location information. In this case, the location information may be stored in the ⁇ contentInstance> resource under the ⁇ container> resource.
  • the hosting CSE can receive the response and translate it into a response message to be sent to the sender. If the location measurement procedure fails, the hosting CSE may store the statusCode based on the error code in the locationStatus attribute of the ⁇ locationPolicy> resource. If the location measurement procedure succeeds and the hosting CSE obtains the location information, the hosting CSE may store the acquired location information in the ⁇ contentInstance> resource under the ⁇ container> resource.
  • the MN (Hosting CSE) has topology information of the underlying network inside the MN, the MN knows the nodes connected to the MN and their physical relationships (or topology information). Therefore, if a restrictive M2M device (ADN) or another application has requested the creation of a ⁇ locationPolicy> resource and has set the locationSource attribute to sharing-based, then the MN is responsible for the topology information (eg , based on a ⁇ networkTopoloy> resource), may find the closest node having the location information (Closest Node), and set the location of the found node as the location of the ADN. Whether a specific node has location information may be determined by the MN based on information of resources held by the MN.
  • the closest node may be determined as the node having the minimum hop count from the originator.
  • a new node in a tree-structured network attaches to a node in an existing network, it may be desirable to attach to a stable node that is close to, or highly capable, among a plurality of nodes.
  • the new node is preferably connected to a node having a high RSS (Received Signal Strength). Therefore, network topology information may be desirable as an index indicating proximity between nodes. Therefore, it is preferable that the node having the minimum number of hops is determined as the nearest node based on the topology information of the physical network.
  • ADN_5 is physically registered as a child node of ADN_4, and ADN_5 may request location information in a share-based manner.
  • the MN may find a node having the minimum number of hops with ADN_5 based on the network topology information of the ⁇ node> resource it owns. Assuming that ADN_3 and ADN_1 are nodes having location information, ADN_3 is three hops and ADN_1 is two hops from ADN_5. Thus, the closest node in this example may be determined as ADN_1.
  • the nearest node may be impossible to find the nearest node through the minimum hop count. For example, when two or more nodes having the same minimum hop count exist, it may be a problem to determine which node among the two or more nodes is the closest node. In this case, additional conditions may be required in addition to the minimum hop condition.
  • the node that shares the location information with the node that holds the latest information based on the location information acquisition time of the location information of the terminal (the corresponding location information is assigned to a resource such as ⁇ container> in the overlay area) ( That is, the nearest node). Since the location information obtained by the sharing-based method is not the exact location information of the corresponding terminal, and the terminal sharing the location information may also have mobility, it is preferable to select a node having the latest location information.
  • ADN_5 requests the creation of a ⁇ locationPolicy> resource and sets the locationSource attribute to share based. Also, assume that ADN_1 and ADN_3 have location information.
  • ADN_1 and ADN_3 have the same number of hops from ADN_5 based on the minimum hop. Therefore, it is possible to determine the update time of the location information as an additional criterion for selecting the nearest node.
  • ADN_1 updated location information 4800 seconds ago and ADN_3 updated location information 1200 seconds ago it is assumed that ADN_3 having the latest location information may be determined as the nearest node, and location information of ADN_3 may be shared / set as location information of ADN_5.
  • the URI including the location information of the nearest node may be added as link information to the resource with the location information of the target terminal, or the location information of the nearest node may be directly added as the location information of the target terminal. Applicable Even when the location information is updated, when the M2M gateway cannot find the nearest node, the location information of the M2M gateway may be set as the location information of the target terminal.
  • the location information update may be performed using an update operation.
  • the connected terminals may have local proximity.
  • the connection range of the gateway is up to 30m
  • the terminal is basically contained within a radius of 30m from the location of the gateway. In this case, it is assumed that the gateway can calculate its location through a location server or application.
  • the location information may be provided including the above-mentioned error range, and if the error range is provided to the application in the service layer, based on the information (location information + error range)
  • the application can determine whether or not to use the information.
  • LBS Application location based service application
  • the M2M terminal does not have a location information acquisition function (location server or application based) and the M2M gateway is assumed to have a function for obtaining location information.
  • the M2M gateway and the M2M terminal are in the same area network, or that the two terminals are also in the same area network when transferring location information between the M2M terminal and the M2M terminal. .
  • Provisioning may include a method of explicitly reporting the location information of the M2M gateway and a method of providing a URI for the location information of the M2M gateway.
  • the M2M gateway may provide the terminal with location information in the form of, for example, latitude, longitude, or three-dimensional (3D) configuration.
  • location information in the form of, for example, latitude, longitude, or three-dimensional (3D) configuration.
  • 3D three-dimensional
  • Uncertainty information may correspond to coverage of an M2M gateway. For example, although the M2M terminal knows its location as the location of the M2M gateway, it can know that it is actually within (or radius) coverage of the M2M gateway using uncertainty information.
  • Valid time information Information indicating the valid time of the location. After this time, the M2M terminal should discard the location.
  • Transmission power information Transmission power information transmitted by the M2M gateway. Through that information
  • the M2M terminal may perform sophisticated calculation based on RSS (Received Signal Strength) from the M2M gateway obtained by itself.
  • RSS Received Signal Strength
  • Hop information When the area network is configured in a mesh form, it may provide topology information managed by the M2M gateway.
  • M2M gateway is mobile
  • the location of the M2M gateway may be changed, and thus a link may be formed from the location information URI of the M2M gateway to the URI of the target terminal location information resource.
  • the location of the target terminal is the same as the location of the M2M gateway.
  • the M2M terminal may delete the location information.
  • the M2M terminal may request the deletion of the ⁇ locationPolicy> resource.
  • the M2M terminal may transmit a deletion request message of a ⁇ locationPolicy> resource to the M2M gateway.
  • the receiver eg. the M2M gateway
  • the receiver may check whether the sender (eg, the terminal) has the DELETE authority for the ⁇ locationPolicy> resource. If the check is successful, the CSE can remove the resource from the repository and send the appropriate response to the sender.
  • the hosting CSE may store the URI of the resource in the ⁇ container> resource.
  • the hosting CSE may check the locationUpdatePeriod attribute, perform the procedure according to the defined attributes if the value is greater than zero and store the result in the ⁇ container> resource. However, if the locationUpdatePeriod attribute is set to 0 or not set, the hosting CSE can perform the location measurement procedure only when the ⁇ container> is later retrieved.
  • the M2M device is a device without location information and may correspond to, for example, a limited M2M device ADN.
  • the M2M gateway has a radius of 30 m.
  • the M2M gateway determines whether there is a device having location information in the area network, and since there is no device having location information, the M2M gateway determines its own location information. Can send to the device.
  • the location information may be represented by a combination of (latitude and longitude), and additionally, uncertainty attribute information may be included.
  • the actual location of the M2M gateway may be different from the location information, and this difference may be estimated through uncertainty information.
  • M2M device 1610 is an ADN and is a resource constrained node.
  • the M2M device 1610 has no location determination capability (eg, GPS) and no network-based positioning capability.
  • M2M gateway 1620 includes a hosting CSE as an MN. It is also assumed that the M2M device 1630 includes at least one ASN or ADN.
  • the M2M gateway 1620 may perform an operation of the hosting CSE described in connection with a method of providing a location information acquisition method based on a ⁇ locationPolicy> resource.
  • the M2M device 1610 may operate as the originator of the location information request.
  • the M2M gateway 1620 may perform a location acquisition procedure and acquire location information of the M2M device 1630.
  • the M2M gateway 1620 may store location information of the M2M device 1630 in a ⁇ container> resource.
  • the ⁇ container> resource may have the structure illustrated in FIG. 11 and may have the attributes illustrated in Table 2.
  • the M2M device 1610 may transmit a request for generation of a ⁇ locationPolicy> resource indicating a manner of obtaining location information to the M2M gateway 1620.
  • the generation request may include information (eg, a locationSource attribute set on a sharing basis) indicating sharing based location measurement.
  • the M2M gateway 1620 may generate a ⁇ locationPolicy> resource.
  • the ⁇ locationPolicy> resource may have the structure illustrated in FIG. 10 and may include at least one of the attributes illustrated in Table 1.
  • the M2M gateway 1620 may generate a ⁇ node> resource and its child resources.
  • the ⁇ node> resource may have a structure illustrated in FIG. 12 and may include at least one of the resources illustrated in Table 3. FIG.
  • the M2M gateway 1620 may configure network topology information.
  • the M2M gateway 1620 may obtain a list of M2M devices connected to the M2M gateway 1620 and obtain information regarding a physical connection or a base connection between M2M devices in the M2M area network.
  • the network topology information may indicate a list of M2M devices connected to the M2M gateway 1620 and a physical connection (or physical connection relationship) between the M2M devices in the M2M area network.
  • Step S1608 and / or step S1610 may be performed before step S1604.
  • the network topology information may be stored in a ⁇ node> resource generated in step S1608.
  • the M2M gateway 1620 may find the M2M device nearest to the M2M device 1610 based on the topology information and the location information.
  • the location information of the M2M gateway 1620 may be stored as the location information of the M2M device 1610. In this case, the M2M gateway 1620 may store its own location information as the location information of the M2M device 1610.
  • the M2M gateway 1620 can find a device having the minimum hop count from the M2M device 1610 among the devices having the topology information and the location information based on the topology information, the device having the minimum hop count is the closest. Can be determined by the device. In this case, the M2M gateway 1620 may store the location information of the M2M device determined as the nearest device as the location information of the M2M device 1610. In addition, when a plurality of devices having the same minimum hop number is determined, the device having the latest location information may be determined as the nearest device.
  • FIG. 16 is illustrative only, and some steps may be omitted or additional steps may be added, depending on the implementation.
  • the embodiments proposed herein may be combined to form a new embodiment, and only some components of the embodiments may be combined to form a new embodiment.
  • 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 may be configured to include a module, a procedure, or a function for performing the functions or operations of the present invention, and may be configured to perform the present invention.
  • the firmware or software may be provided in the processors 11 and 21 or stored in the memory 12 and 22 to be driven by the processors 11 and 21.
  • the processor 11 of the transmission apparatus 10 is predetermined from the processor 11 or a scheduler connected to the processor 11 and has a predetermined encoding and modulation on a signal and / or data to be transmitted to the outside. After performing the transmission to the RF unit 13.
  • the signal processing of the receiver 20 is the reverse of the signal processing of the transmitter 10.
  • the RF unit 23 of the receiving device 20 receives a radio signal transmitted by the transmitting device 10.
  • the processor 21 may decode and demodulate a radio signal received through a reception antenna to restore data originally transmitted by the transmission apparatus 10.
  • the RF units 13, 23 have one or more antennas.
  • the antenna transmits a signal processed by the RF units 13 and 23 to the outside under the control of the processors 11 and 21, or receives a radio signal from the outside to receive the RF unit 13. , 23).
  • the transmitter and the receiver are respectively communicated through the RF unit, but it is also possible for the transmitter and the receiver to communicate through a wired network.
  • the RF unit may be replaced with a network interface unit (NIU).
  • NNIU network interface unit
  • each component or feature is to be considered optional unless stated otherwise.
  • Each component or feature may be embodied in a form that is not combined with other components or features. It is also possible to combine some of the components and / or features to form an embodiment of the invention.
  • the order of the operations described in the embodiments of the present invention may be changed. Some components or features of one embodiment may be included in another embodiment or may be replaced with corresponding components or features of another embodiment. It is obvious that the claims may be combined to form an embodiment by combining claims that do not have an explicit citation relationship in the claims or as new claims by post-application correction.
  • Certain operations described in this document as being performed by a base station may in some cases be performed by an upper node thereof. That is, it is obvious that various operations performed for communication with the terminal in a network including a plurality of network nodes including a base station may be performed by the base station or other network nodes other than the base station.
  • a base station may be replaced by terms such as a fixed station, a Node B, an eNode B (eNB), an access point, and the like.
  • the terminal may be replaced with terms such as a user equipment (UE), a mobile station (MS), a mobile subscriber station (MSS), and the like.
  • Embodiments according to the present invention may be implemented by various means, for example, hardware, firmware, software, or a combination thereof.
  • an embodiment of the present invention may include one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), FPGAs ( field programmable gate arrays), processors, controllers, microcontrollers, microprocessors, and the like.
  • ASICs application specific integrated circuits
  • DSPs digital signal processors
  • DSPDs digital signal processing devices
  • PLDs programmable logic devices
  • FPGAs field programmable gate arrays
  • processors controllers, microcontrollers, microprocessors, and the like.
  • the present invention may be implemented by software code or instructions including a form of a module, procedure, function, etc. that performs the functions or operations described above.
  • the software code or instructions may be stored in a computer readable medium and driven by the processor and may perform operations according to the present invention when driven by the processor.
  • the computer readable medium may be located inside or outside the processor or remotely connected to the processor through a network, and may exchange data with the processor.
  • the present invention can be used in communication devices such as terminals, servers, gateways, and the like.

Abstract

본 발명은 M2M(Machine-to-Machine) 게이트웨이가 M2M 디바이스의 위치 측정을 수행하는 방법 및 이를 위한 장치에 관한 것으로서, 위치 정보 획득 방식을 나타내는 제1 자원의 생성 요청을 제1 M2M 디바이스로부터 수신하는 단계; 상기 생성 요청이 공유 기반 위치 측정을 지시하는 정보를 포함하는 경우, 상기 제1 M2M 디바이스로부터 가장 가까운 디바이스를 결정하는 단계; 및 상기 가장 가까운 디바이스의 위치 정보를 상기 제1 M2M 디바이스를 위한 위치 정보로서 설정하는 단계를 포함하되, 상기 M2M 게이트웨이가 네트워크 토폴로지 정보를 갖지 않거나 상기 M2M 게이트웨이에 연결된 적어도 하나의 M2M 디바이스가 위치 정보를 갖지 않는 경우, 상기 M2M 게이트웨이가 상기 가장 가까운 디바이스로서 결정되고, 상기 M2M 게이트웨이가 네트워크 토폴로지 정보를 가지고 상기 M2M 게이트웨이에 연결된 상기 적어도 하나의 M2M 디바이스가 위치 정보를 가지는 경우, 상기 적어도 하나의 M2M 디바이스 중에서 상기 제1 M2M 디바이스로부터 최소 홉 개수를 가지는 디바이스가 상기 가장 가까운 디바이스로서 결정되며, 상기 제1 자원은 주소 정보를 이용하여 고유하게 어드레싱 가능한 데이터 구조를 나타내는 방법 및 이를 위한 장치에 관한 것이다.

Description

M2M 시스템에서 위치 측정 방법 및 이를 위한 장치
본 발명은 M2M(Machine-to-Machine) 시스템에 관한 것으로서, 보다 구체적으로 M2M 시스템에서 M2M 디바이스의 위치를 측정하는 방법 및 이를 위한 장치에 관한 것이다.
근래에 들어 M2M(Machine-to-Machine) 통신에 대한 관심이 높아지고 있다. M2M 통신은 사람의 개입 없이 기계(Machine)와 기계 사이에 수행되는 통신을 의미하며, MTC(Machine Type Communication) 또는 IoT(Internet of Things) 통신으로도 지칭된다. M2M 통신에 사용되는 단말을 M2M 디바이스(M2M device)라고 지칭하는데, M2M 디바이스는 일반적으로 낮은 이동성(low mobility), 시간 내성(time tolerant) 또는 지연 내성(delay tolerant), 작은 데이터 전송(small data transmission)등과 같은 특성을 가지며, 기계 간 통신 정보를 중앙에서 저장하고 관리하는 M2M 서버와 연결되어 사용된다. 또한, M2M 디바이스가 서로 다른 통신 방식을 따라 연결되면, 통신 방식이 변경되는 구간에서 M2M 게이트웨이를 통해 M2M 디바이스와 M2M 서버가 연결되며, 이를 통해 전체 M2M 시스템이 구성된다. 해당 시스템을 기반으로 사물 추적(Tracking), 전력 계량(Metering), 자동 지불 시스템(Payment), 의료 분야 서비스, 원격 조정 등의 서비스가 제공될 수 있다.
본 발명은 M2M 시스템에 관한 것이다.
본 발명의 목적은 M2M 시스템에서 효율적으로 위치를 측정하는 방법 및 이를 위한 장치를 제공하는 데 있다.
본 발명의 다른 목적은 M2M 시스템에서 위치 정보가 없는 M2M 디바이스의 위치 측정을 효율적으로 수행하는 방법 및 이를 위한 장치를 제공하는 데 있다.
본 발명의 또 다른 목적은 M2M 시스템에서 공유 기반으로 위치 정보를 효율적으로 획득하는 방법 및 이를 위한 장치를 제공하는 데 있다.
본 발명에서 이루고자 하는 기술적 과제들은 상기 기술적 과제로 제한되지 않으며, 언급하지 않은 또 다른 기술적 과제들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
본 발명의 일 양상으로, M2M(Machine-to-Machine) 게이트웨이가 M2M 디바이스의 위치 측정을 수행하는 방법이 개시되며, 상기 방법은 위치 정보 획득 방식을 나타내는 제1 자원의 생성 요청을 제1 M2M 디바이스로부터 수신하는 단계; 상기 생성 요청이 공유 기반 위치 측정을 지시하는 정보를 포함하는 경우, 상기 제1 M2M 디바이스로부터 가장 가까운 디바이스를 결정하는 단계; 및 상기 가장 가까운 디바이스의 위치 정보를 상기 제1 M2M 디바이스를 위한 위치 정보로서 설정하는 단계를 포함하되, 상기 M2M 게이트웨이가 네트워크 토폴로지 정보를 갖지 않거나 상기 M2M 게이트웨이에 연결된 적어도 하나의 M2M 디바이스가 위치 정보를 갖지 않는 경우, 상기 M2M 게이트웨이가 상기 가장 가까운 디바이스로서 결정되고, 상기 M2M 게이트웨이가 네트워크 토폴로지 정보를 가지고 상기 M2M 게이트웨이에 연결된 상기 적어도 하나의 M2M 디바이스가 위치 정보를 가지는 경우, 상기 적어도 하나의 M2M 디바이스 중에서 상기 제1 M2M 디바이스로부터 최소 홉 개수를 가지는 디바이스가 상기 가장 가까운 디바이스로서 결정되며, 상기 제1 자원은 주소 정보를 이용하여 고유하게 어드레싱 가능한 데이터 구조를 나타낼 수 있다.
본 발명의 다른 양상으로, M2M(Machine-to-Machine) 디바이스의 위치 측정을 수행하는 M2M 게이트웨이가 개시되며, 상기 M2M 게이트웨이는 네트워크 인터페이스 유닛; 및 프로세서를 포함하되, 상기 프로세서는 상기 네트워크 인터페이스 유닛을 제어하여 위치 정보 획득 방식을 나타내는 제1 자원의 생성 요청을 제1 M2M 디바이스로부터 수신하고, 상기 생성 요청이 공유 기반 위치 측정을 지시하는 정보를 포함하는 경우, 상기 제1 M2M 디바이스로부터 가장 가까운 디바이스를 결정하고, 상기 가장 가까운 디바이스의 위치 정보를 상기 제1 M2M 디바이스를 위한 위치 정보로서 설정하도록 구성되며, 상기 M2M 게이트웨이가 네트워크 토폴로지 정보를 갖지 않거나 상기 M2M 게이트웨이에 연결된 적어도 하나의 M2M 디바이스가 위치 정보를 갖지 않는 경우, 상기 M2M 게이트웨이가 상기 가장 가까운 디바이스로서 결정되고, 상기 M2M 게이트웨이가 네트워크 토폴로지 정보를 가지고 상기 M2M 게이트웨이에 연결된 상기 적어도 하나의 M2M 디바이스가 위치 정보를 가지는 경우, 상기 적어도 하나의 M2M 디바이스 중에서 상기 제1 M2M 디바이스로부터 최소 홉 개수를 가지는 디바이스가 상기 가장 가까운 디바이스로서 결정되며, 상기 제1 자원은 주소 정보를 이용하여 고유하게 어드레싱 가능한 데이터 구조를 나타낼 수 있다.
바람직하게는, 상기 최소 홉 개수를 가지는 디바이스가 둘 이상 존재하는 경우, 가장 최신 위치 정보를 가지는 디바이스가 상기 제1 M2M 디바이스로부터 가장 가까운 디바이스로서 결정될 수 있다.
바람직하게는, 상기 위치 정보를 설정하는 것은 상기 제1 M2M 디바이스로부터 가장 가까운 디바이스의 위치 정보를 상기 제1 M2M 디바이스의 위치 정보 저장을 위한 제2 자원에 저장하는 것을 포함할 수 있다.
바람직하게는, 상기 네트워크 토폴로지 정보는 상기 M2M 게이트웨이에 연결된 M2M 디바이스들의 리스트와 상기 M2M 게이트웨이에 연결된 M2M 디바이스들 간의 물리적 연결을 나타낼 수 있다.
바람직하게는, 상기 제1 M2M 디바이스는 위치 결정 능력(positioning determination capability)을 갖지 않고 네트워크 기반의 위치 측정 능력(network-based positioning capability)을 갖지 않는 디바이스일 수 있다.
본 발명에 의하면, M2M 시스템에서 효율적으로 위치를 측정할 수 있다.
또한, 본 발명에 의하면, M2M 시스템에서 위치 정보가 없는 M2M 디바이스의 위치 측정을 효율적으로 수행할 수 있다.
또한, 본 발명에 의하면, M2M 시스템에서 공유 기반으로 위치 정보를 효율적으로 획득할 수 있다.
본 발명에서 얻을 수 있는 효과는 이상에서 언급한 효과들로 제한되지 않으며, 언급하지 않은 또 다른 효과들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
첨부 도면은 본 발명에 관한 이해를 돕기 위해 상세한 설명의 일부로 포함되며, 본 발명에 대한 실시예를 제공하고, 상세한 설명과 함께 본 발명의 기술적 사상을 설명한다.
도 1은 M2M 시스템을 예시한다.
도 2는 M2M 시스템의 계층 구조(layered structure)를 예시한다.
도 3은 M2M 시스템의 기능적 아키텍처(functional architecture)를 예시한다.
도 4는 M2M 시스템의 구성을 예시한다.
도 5는 M2M 시스템에서 사용되는 리소스(resource)를 예시한다.
도 6은 특정 M2M 애플리케이션을 위한 리소스를 예시한다.
도 7은 일반적인 M2M 시스템의 통신 흐름을 예시한다.
도 8은 M2M 시스템에서 서로 다른 엔티티들이 상호 연동하는 예를 예시한다.
도 9는 M2M 시스템의 오버레이 네트워크와 기저 네트워크의 구조를 예시한다.
도 10은 본 발명에 따른 타겟 단말의 위치 정보를 획득하는 방식을 저장하는 자원을 예시한다.
도 11은 본 발명에 따라 타겟 단말의 위치 정보를 저장하는 자원을 예시한다.
도 12는 본 발명에 따라 M2M 단말의 속성 정보를 저장하는 자원을 예시한다.
도 13은 네트워크 토폴로지를 예시한다.
도 14는 본 발명에 따른 실시예를 예시한다.
도 15는 본 발명에 따라 M2M 게이트웨이가 위치 측정 절차를 수행하는 예를 예시한다.
도 16은 본 발명에 따른 위치 측정 절차의 흐름을 예시한다.
도 17은 본 발명이 적용될 수 있는 장치의 블록도를 예시한다.
본 발명에 따른 바람직한 실시예를 첨부된 도면을 참조하여 상세하게 설명한다. 첨부된 도면과 함께 이하에 개시될 상세한 설명은 본 발명의 예시적인 실시예를 설명하고자 하는 것이며, 본 발명이 실시될 수 있는 유일한 실시예를 나타내고자 하는 것이 아니다. 이하의 상세한 설명은 본 발명의 완전한 이해를 제공하기 위해서 구체적 세부사항을 포함한다. 그러나, 본 발명이 속하는 분야에서 통상의 기술자는 본 발명이 이러한 구체적 세부사항 없이도 실시될 수 있음을 안다.
몇몇 경우, 본 발명의 개념이 모호해지는 것을 피하기 위하여 공지의 구조 및 장치는 생략되거나, 각 구조 및 장치의 핵심기능을 중심으로 한 블록도 형식으로 도시될 수 있다. 또한, 본 명세서에서 동일한 구성요소에 대해 동일한 도면 부호가 사용될 수 있다.
본 명세서에서, M2M 디바이스(M2M device)는 M2M(Machine-to-Machine) 통신을 위한 디바이스를 지칭한다. M2M 디바이스는 고정되거나 이동성을 가질 수 있으며 M2M 서버 및/또는 M2M 게이트웨이와 통신하여 사용자 데이터 및/또는 제어 정보를 송수신할 수 있다. M2M 디바이스는 단말(Terminal Equipment), MS(Mobile Station), MT(Mobile Terminal), UT(User Terminal), SS(Subscribe Station), 무선 장치(wireless device), PDA(Personal Digital Assistant), 무선 모뎀(wireless modem), 휴대 장치(handheld device), 노드(Node) 등으로 지칭될 수 있다. 본 발명에 있어서, M2M 서버는 M2M 통신을 위한 서버를 지칭하며 고정국(fixed station) 또는 이동국(mobile station)으로 구현될 수 있다. M2M 서버는 M2M 디바이스들 및/또는 다른 M2M 서버와 통신하여 데이터 및 제어 정보를 교환할 수 있다. 또한, M2M 게이트웨이는 M2M 디바이스가 연결된 네트워크와 M2M 서버가 연결된 네트워크가 서로 다른 경우, 한 네트워크에서 다른 네트워크로 들어가는 연결점 역할을 수행하는 장치를 지칭한다. 또한, M2M 게이트웨이는 M2M 디바이스로서 기능을 수행할 수 있으며, 이외에 예를 들어 M2M 게이트웨이에 연결된 M2M 디바이스를 관리하거나, 하나의 메시지를 수신하여 연결된 M2M 디바이스들에게 동일 또는 변경된 메시지를 전달하거나(message fanout), 메시지 집적(message aggregation)하는 기능을 수행할 수 있다. M2M 디바이스라는 용어는 M2M 게이트웨이와 M2M 서버를 포함하는 개념으로 사용될 수 있고, 따라서 M2M 게이트웨이와 M2M 서버는 M2M 디바이스로 지칭될 수 있다.
또한, 본 명세서에서 “엔티티(entity)”라는 용어는 M2M 디바이스, M2M 게이트웨이, M2M 서버와 같은 하드웨어를 지칭하는 데 사용될 수 있고, 또는 아래에서 설명되는 M2M 애플리케이션 계층과 M2M (공통) 서비스 계층의 소프트웨어 컴포넌트(software component)를 지칭하는 데 사용될 수 있다.
이하에서, 본 발명은 M2M 시스템을 중심으로 설명되지만 본 발명은 M2M 시스템에만 제한적으로 적용되는 것은 아니며, 예를 들어 클라이언트-서버(또는 송신자-응답자(sender-responder)) 모델에 따른 시스템에도 동일/유사하게 적용될 수 있다.
도 1은 M2M 시스템을 예시한다. 도 1은 ETSI(European Telecommunications Standards Institute) 기술 규격(Technical Specification, TS)에 따른 M2M 시스템을 예시한다.
ETSI TS M2M 기술 규격에 따른 M2M 시스템은 다양한 M2M 애플리케이션(Application)을 위한 공통 M2M 서비스 프레임워크(Service Framework)를 정의한다. M2M 애플리케이션은 e헬스(e-Health), 도시 자동화(City Automation), 커넥티드 컨슈머(Connected Consumer), 오토모티브(Automotive)와 같은 M2M 서비스 솔루션을 구현하는 소프트웨어 컴포넌트(software component)를 지칭할 수 있다. M2M 시스템에서는 이러한 다양한 M2M 애플리케이션을 구현하기 위해 공통적으로 필요한 기능들을 제공되며, 공통적으로 필요한 기능들은 M2M 서비스 또는 M2M 공통 서비스라고 지칭될 수 있다. 이러한 M2M 공통 서비스를 이용하면 각 M2M 애플리케이션마다 기본 서비스 프레임워크를 다시 구성할 필요 없이 M2M 애플리케이션이 쉽게 구현될 수 있다.
M2M 서비스는 서비스 능력(Service Capability, SC)의 집합 형태로 제공되며, M2M 애플리케이션은 오픈 인터페이스(open interface)를 통해 SC(Service Capability)의 집합 또는 SC(Service Capability)에 접근하여 SC(Service Capability)가 제공하는 M2M 서비스 또는 기능을 이용할 수 있다. SC는 M2M 서비스를 구성하는 기능 (예, 디바이스 관리, 위치, 발견, 그룹 관리, 등록, 보안 등)을 제공할 수 있고, SC 계층(Service Capabilities Layer) 또는 SC 엔티티(Service Capability Entity)는 M2M 애플리케이션이 서비스 프레임워크 상에서 제공될 때 사용할 수 있는 M2M 서비스를 위한 기능(function)들의 집합이라고 할 수 있다.
SC(Service Capability)는 xSC로 표현될 수 있다. 여기서, x는 N/G/D 중의 하나로 표현될 수 있으며, SC(Service Capability)가 네트워크(Network)(및/또는 서버), 게이트웨이(Gateway), 디바이스(Device) 중 어디에 존재하는지를 나타낸다. 예를 들어, NSC는 네트워크 및/또는 서버 상에 존재하는 SC(Service Capability)를 나타내고, GSC는 게이트웨이 상에 존재하는 SC(Service Capability)를 나타낸다.
M2M 애플리케이션은 네트워크, 게이트웨이, 또는 디바이스 상에 존재할 수 있다. 네트워크 상에 존재하거나 서버와 직접 연결되어 존재하는 M2M 애플리케이션은 M2M 네트워크 애플리케이션(M2M Network Application)라고 지칭되며 간략히 NA(Network Application)로 나타낼 수 있다. 예를 들어, NA는 서버에 직접 연결되어 구현되는 소프트웨어이며, M2M 게이트웨이 또는 M2M 디바이스와 통신하고 이들을 관리하는 역할을 수행할 수 있다. 디바이스 상에 존재하는 M2M 애플리케이션은 M2M 디바이스 애플리케이션(M2M Device Application)이라고 지칭되며 간략히 DA(Device Application)로 나타낼 수 있다. 예를 들어, DA는 M2M 디바이스에서 구동되는 소프트웨어이며, 센서 정보 등을 NA에게 전달할 수도 있다. 게이트웨이 상에 존재하는 M2M 애플리케이션은 M2M 게이트웨이 애플리케이션(Gateway Application)이라고 지칭되며 간략히 GA(Gateway Application)로 나타낼 수 있다. 예를 들어, GA는 M2M 게이트웨이를 관리하는 역할도 할 수 있고 DA에게 M2M 서비스 또는 기능(예, SCs(Service Capabilities) 또는 SC(Service Capability))를 제공할 수도 있다. M2M 애플리케이션은 애플리케이션 엔티티(AE)와 애플리케이션 계층을 통칭할 수 있다.
도 1을 참조하면, M2M 시스템 아키텍처는 네트워크 도메인과 디바이스 및 게이트웨이 도메인으로 구분될 수 있다. 네트워크 도메인은 M2M 시스템 관리를 위한 기능(function)들과 네트워크 관리를 위한 기능(function)들을 포함할 수 있다. M2M 시스템 관리를 위한 기능은 디바이스 및 게이트웨이 도메인에 존재하는 디바이스들을 관리하는 M2M 애플리케이션과 M2M SCs(Service Capabilities)에 의해 수행될 수 있고, 네트워크 관리를 위한 기능은 코어 네트워크와 액세스 네트워크에 의해 수행될 수 있다. 따라서, 도 1의 예에서, 코어 네트워크와 액세스 네트워크는 M2M 기능을 수행한다기보다는 각 엔티티들 간의 연결을 제공한다. 코어 네트워크와 액세스 네트워크를 통해 네트워크 도메인과 디바이스 및 게이트웨이 도메인에서 M2M SCs(Service Capabilities) 간에 M2M 통신이 수행될 수 있으며, 각 도메인의 M2M 애플리케이션은 각 도메인의 M2M SCs(Service Capabilities)를 통해 신호 또는 정보를 주고 받을 수 있다.
액세스 네트워크(Access Network)는 M2M 디바이스 및 게이트웨이 도메인이 코어 네트워크와 통신을 가능하게 하는 엔티티이다. 액세스 네트워크의 예로는 xDSL(Digital Subscriber Line), HFC(Hybrid Fiber Coax), 위성(satellite), GERAN, UTRAN, eUTRAN, 무선(Wireless) LAN, WiMAX 등이 있다.
코어 네트워크(Core Network)는 IP(Internet Protocol) 연결, 서비스와 네트워크 제어, 상호연결, 로밍(roaming) 등의 기능을 제공하는 엔티티이다. 코어 네트워크는 3GPP(3rd Generation Partnership Project) 코어 네트워크, ETSI TISPAN(Telecommunications and Internet converged Services and Protocols for Advanced Networking) 코어 네트워크와 3GPP2 코어 네트워크 등을 포함한다.
M2M SC(Service Capability)는 여러 M2M 네트워크 애플리케이션들에서 공유될 수 있는 M2M 공통 서비스 기능(Common Service Function, CSF)을 제공하고 M2M 서비스를 오픈 인터페이스(open interface)를 통해 노출하여 M2M 애플리케이션들이 M2M 서비스를 이용할 수 있게 한다. M2M SCL(Service Capability Layer)은 이러한 M2M SC 엔티티들 또는 M2M 공통 서비스 기능들을 포함하는 계층을 지칭할 수 있다.
M2M 애플리케이션은 서비스 로직(service logic)을 동작시키고, 오픈 인터페이스를 통해 M2M SCs(Service Capabilities)를 사용할 수 있는 엔티티이다. M2M 애플리케이션 계층은 이러한 M2M 애플리케이션 및 관련 동작 로직(operational logic)을 포함하는 계층을 지칭할 수 있다.
M2M 디바이스는 M2M SCs(Service Capabilities)를 통해 M2M 디바이스 애플리케이션을 동작시키는 엔티티이다. M2M 디바이스는 직접 네트워크 도메인의 M2M 서버와 통신할 수도 있으며, M2M 게이트웨이를 통해서 네트워크 도메인의 M2M 서버와 통신할 수도 있다. M2M 게이트웨이를 통해서 연결될 경우에는 M2M 게이트웨이는 프록시(proxy)와 같이 동작한다. M2M 디바이스는 M2M 애플리케이션 및/또는 M2M SCs(Service Capabilities)를 포함할 수 있다.
M2M 영역 네트워크(M2M area network)는 M2M 디바이스와 M2M 게이트웨이 간의 연결(connectivity)을 제공한다. 이 경우, M2M 게이트웨이와 M2M 서버 간 네트워크와 M2M 디바이스와 M2M 게이트웨이 간 네트워크가 서로 상이할 수 있다. 예를 들어, M2M 영역 네트워크는 IEEE802.15.1, 지그비(Zigbee), 블루투스(Bluetooth), IETF ROLL, ISA100.11a와 같은 PAN(Personal Area Network) 기술과 PLC(Power Line Communication), M-BUS, 무선 M-BUS, KNX와 같은 로컬 네트워크 기술을 이용하여 구현될 수 있다. 일부 예에서 M2M 영역 네트워크는 물리적 네트워크 연결의 형태를 의미할 수 있지만, 이에 제한되는 것은 아니며 다른 예에서 M2M 영역 네트워크는 논리적 네트워크 연결의 형태를 의미할 수도 있다.
M2M 게이트웨이는 M2M SCs(Service Capabilities)를 통해 M2M 애플리케이션을 관리하고 M2M 애플리케이션에 대해 서비스를 제공하는 엔티티이다. M2M 게이트웨이는 M2M 디바이스와 네트워크 도메인간의 프록시 역할을 수행하고 ETSI 비-호환(non-compliant) M2M 디바이스에도 서비스를 제공하는 역할을 수행할 수 있다. M2M 게이트웨이는 M2M 디바이스들 중 게이트웨이 기능을 갖는 엔티티를 지칭할 수 있다. M2M 게이트웨이는 M2M 애플리케이션 및/또는 M2M SCs(Service Capabilities)를 포함할 수 있다.
도 1에 예시된 M2M 시스템 아키텍처는 예시에 불과하고 각 엔티티의 명칭은 달라질 수 있다. 예를 들어, M2M SC(Service Capability)는 M2M 공통 서비스 기능(common service function, CSF)로 지칭될 수 있고, SCL(Service Capability Layer)는 공통 서비스 계층(Common Service Layer, CSL) 또는 공통 서비스 엔티티(Common Service Entity, CSE)으로 지칭될 수 있다. 또한, M2M 애플리케이션은 애플리케이션 엔티티(application entity, AE)로 지칭될 수 있고, M2M 애플리케이션 계층은 간략히 애플리케이션 계층으로 지칭될 수 있다. 마찬가지로, 각 도메인의 명칭 또한 달라질 수 있다. 예를 들어, oneM2M 시스템에서 네트워크 도메인은 인프라스트럭처 도메인(infrastructure domain)으로 지칭될 수 있고, 디바이스 및 게이트웨이 도메인은 필드 도메인(field domain)으로 지칭될 수 있다.
도 1에 예시된 바와 같이, M2M 시스템은 M2M 통신을 위해 M2M 애플리케이션 계층과 M2M SC(Service Capability) 계층을 포함하는 계층 구조로서 이해될 수 있다.
도 2는 M2M 시스템의 계층 구조(layered structure)를 예시한다.
도 2를 참조하면, M2M 시스템은 애플리케이션 계층(202), 공통 서비스 계층(204), 기저 네트워크 서비스 계층(underlying network services layer)(206)을 포함할 수 있다. 앞서 설명된 바와 같이, 애플리케이션 계층(202)은 M2M 애플리케이션 계층에 대응되고, 공통 서비스 계층(204)은 M2M SCL에 대응될 수 있다. 기저 네트워크 서비스 계층(206)은 코어 네트워크에 존재하는 장치 관리(device management), 위치 서비스(location service), 및 장치 트리거링(device triggering)과 같은 서비스들을 공통 서비스 계층(204)에 제공한다.
도 3은 M2M 시스템의 기능적 아키텍처(functional architecture)를 예시한다. 기능적인 측면에서 M2M 시스템 아키텍처는 애플리케이션 엔티티(application entity, AE)(302), 공통 서비스 엔티티(common service entity, CSE)(304), 기저(underlying) 네트워크 서비스 엔티티(network service entity, NSE)(306)를 포함할 수 있다. 각 엔티티들(302, 304, 306)은 공통 서비스 엔티티(304)가 지원하는 기준점(reference point)을 통해 통신할 수 있다. 기준점(reference point)은 각 엔티티들(302, 304, 306) 간의 통신 흐름(communication flow)를 지정하는 역할을 한다. 기준점은 Mcx로 표현될 수 있고 Mc는 “M2M communications”을 의미한다. 본 명세서에서 Mca 기준점, Mcc 기준점, Mcn 기준점은 각각 Mca, Mcc, Mcn으로 표기될 수 있다.
도 3을 참조하면, Mca 기준점(312)은 애플리케이션 엔티티(AE)(302)와 공통 서비스 엔티티(CSE)(304)의 통신 흐름을 지정한다. Mca 기준점(312)은 AE(302)가 CSE(304)에 의해 제공되는 서비스를 이용할 수 있게 하고 CSE(304)가 AE(302)와 통신할 수 있게 한다. Mca 기준점(312)은 M2M 애플리케이션 계층과 M2M 공통 서비스 계층(또는 엔티티) 간의 인터페이스를 지칭할 수 있다.
Mcc 기준점(314)은 서로 다른 공통 서비스 엔티티(CSE)(304)들 간의 통신 흐름을 지정한다. Mcc 기준점(314)은 CSE(304)가 필요한 기능들을 제공할 때 다른 CSE의 서비스를 이용할 수 있게 한다. Mcc 기준점(314)을 통해 제공되는 서비스는 CSE(304)가 지원하는 기능들에 의존적일 수 있다. Mcc 기준점(312)은 M2M 공통 서비스 계층들 간의 인터페이스를 지칭할 수 있다.
Mcn 기준점(316)은 CSE(304)와 기저 네트워크 서비스 엔티티(NSE)(306) 간의 통신 흐름을 지정한다. Mcn 기준점(316)은 CSE(304)가 요구된 기능들을 제공하기 위해 기저 NSE(306)가 제공하는 서비스를 이용할 수 있게 한다. Mcn 기준점(312)은 M2M 공통 서비스 계층과 M2M 기저 네트워크 계층 간의 인터페이스를 지칭할 수 있다.
또한, 도 3의 예에서, CSE(304)는 다양한 공통 서비스 기능(common service function, CSF)들을 제공할 수 있다. 예를 들어, CSE(304)는 애플리케이션 및 서비스 계층 관리(Application and Service Layer Management) 기능, 통신 관리 및 전달 처리(Communication Management and Delivery Handling) 기능, 데이터 관리 및 저장(Data Management and Repository) 기능, 장치 관리(Device Management) 기능, 그룹 관리(Group Management) 기능, 발견(Discovery) 기능, 위치(Location) 기능, 네트워크 서비스 노출/서비스 실행 및 트리거링(Network Service Exposure/ Service Execution and Triggering) 기능, 등록(Registration) 기능, 보안(Security) 기능, 서비스 과금 및 계산(Service Charging and Accounting) 기능, 서비스 세션 관리 기능(Service Session Management), 구독/통지(Subscription/Notification) 기능 중에서 적어도 하나를 포함할 수 있다. CSE(304)는 상기 공통 서비스 기능들의 인스턴스(instance)를 가리키며, M2M 애플리케이션들이 사용하고 공유할 수 있는 공통 서비스 기능들의 서브세트를 제공한다. 공통 서비스 기능들을 개략적으로 설명하면 다음과 같다.
- 애플리케이션 및 서비스 계층 관리(Application and Service Layer Management, ASM): AE들과 CSE들의 관리 기능을 제공한다. 예를 들어, ASM 기능은 CSE들의 기능을 설정(configure)하고 문제점을 해결(troubleshoot)하고 업그레이드(upgrade)할 뿐만 아니라 AE들의 기능을 업그레이드할 수 있다.
- 통신 관리 및 전달 처리(Communication Management and Delivery Handling, CMDH): 다른 CSE들, AE들, NSE들과의 통신을 제공한다. 예를 들어, CMDH 기능은 CSE-CSE 통신(CSE-to-CSE communication)을 위한 연결(connection)을 언제 어떻게 사용할지를 결정하고 특정 요청들이 지연 전달될 수 있도록 제어할 수 있다.
- 데이터 관리 및 저장(Data Management and Repository, DMR): M2M 애플리케이션들이 데이터를 교환, 공유할 수 있게 한다. 예를 들어, DMR 기능은 대량의 데이터를 수집(collecting)/병합(aggregating)하고 데이터를 특정 포맷으로 변환(converting)하고 저장(storing)할 수 있다.
- 장치 관리(Device Management, DMG): M2M 게이트웨이 및 M2M 디바이스 뿐만 아니라 M2M 영역 네트워크에 존재하는 디바이스들에 대한 디바이스 기능을 관리한다. 예를 들어, DMG 기능은 애플리케이션 설치 및 설정, 펌웨어(Firmware) 업데이트, 로깅(Logging), 모니터링(Monitoring), 진단(Diagnostics), 네트워크 토폴로지(Topology) 관리 등을 수행할 수 있다.
- 발견(Discovery, DIS): 주어진 범위 및 조건 내에서 요청에 따라 정보 및 리소스(resource)와 같은 정보를 검색(searching)한다.
- 그룹 관리(Group Management, GMG): 예를 들어 리소스(resource), M2M 디바이스, 또는 M2M 게이트웨이를 묶어 그룹을 생성할 수 있는데 그룹 관련 요청을 핸들링(handling)한다.
- 위치(Location, LOC): M2M 애플리케이션이 M2M 디바이스 또는 M2M 게이트웨이의 위치 정보를 획득하는 역할을 수행한다.
- 네트워크 서비스 노출/서비스 실행 및 트리거링(Network Service Exposure/ Service Execution and Triggering, NSSE): 기저 네트워크의 통신을 가능하게 하고 기저 네트워크가 제공하는 서비스 또는 기능을 사용할 수 있게 한다.
- 등록(Registration, REG): M2M 애플리케이션 또는 다른 CSE가 특정 CSE에 등록을 처리하는 역할을 수행한다. 등록은 특정 CSE의 M2M 서비스 기능을 사용하기 위해 수행된다.
- 보안(Security, SEC): 보안 키와 같은 민감한 데이터 핸들링, 보안 연관 관계(Association) 설립, 인증(Authentication), 권한 부여(Authorization), ID(Identity) 보호 등의 역할을 수행한다.
- 서비스 과금 및 계산(Service Charging and Accounting, SCA): AE 또는 CSE에 과금 기능을 제공하는 역할을 수행한다.
- 서비스 세션 관리(Service Session Management, SSM): 단대단(end-to-end) 통신을 위한 서비스 계층의 M2M 세션을 관리하는 역할을 수행한다.
- 구독/통지(Subscription/Notification, SUB): 특정 리소스(resource)에 대한 변경을 구독(Subscription)하면 해당 리소스(resource)이 변경되면 이를 통지(notification)하는 역할을 수행한다.
도 4는 M2M 시스템의 구성을 예시한다. 본 명세서에서, 노드(node)는 하나 이상의 M2M 애플리케이션을 포함하는 엔티티 또는 하나의 CSE와 0개 이상의 M2M 애플리케이션을 포함하는 엔티티를 의미한다.
애플리케이션 전용 노드(Application Dedicated Node, ADN)는 적어도 하나의 애플리케이션 엔티티(AE)를 가지지만 공통 서비스 엔티티(CSE)를 가지지 않는 노드를 지칭할 수 있다. ADN은 Mca를 통해 하나의 중간 노드(Middle Node, MN) 또는 하나의 인프라스트럭처 노드(Infrastructure Node, IN)와 통신할 수 있다. ADN은 제한된 능력을 갖는 M2M 디바이스(M2M device having a constrained capability)로 지칭될 수 있는데, 제한된 능력을 갖는 M2M 디바이스는 공통 서비스 계층(common service layer) 또는 공통 서비스 엔티티(CSE)를 포함하지 않는 M2M 디바이스를 지칭할 수 있다. 제한된 능력을 갖는 M2M 디바이스는 간략히 제한적인 M2M 디바이스(constrained M2M device)라고 지칭될 수 있다.
애플리케이션 서비스 노드(Application Service Node, ASN)는 적어도 하나의 공통 서비스 엔티티(CSE)를 가지고 적어도 하나의 M2M 애플리케이션 엔티티(AE)를 가지는 노드를 지칭할 수 있다. ASN은 Mcc를 통해 하나의 중간 노드(Middle Node) 또는 하나의 인프라스트럭처 노드(Infrastructure Node)와 통신할 수 있다. ASN은 M2M 디바이스로 지칭될 수 있다.
중간 노드(Middle Node, MN)는 하나의 공통 서비스 엔티티(CSE)와 0개 이상의 M2M 애플리케이션 엔티티(AE)를 가지는 노드를 지칭할 수 있다. MN은 Mcc를 통해 하나의 인프라스트럭처 노드(IN) 또는 다른 중간 노드(MN)와 통신할 수 있으며, 혹은 Mcc를 통해 IN/MN/ASN과 통신할 수 있으며, 혹은 Mca를 통해 ADN과 통신할 수 있다. MN은 M2M 게이트웨이로 지칭될 수 있다.
인프라스트럭처 노드(Infrastructure Node, IN)는 하나의 공통 서비스 엔티티(CSE)를 가지고 0개 이상의 애플리케이션 엔티티(AE)를 가지는 노드를 지칭할 수 있다. IN은 Mcc를 통해 적어도 하나의 중간 노드(MN)와 통신할 수 있고, 및/또는 적어도 하나의 ASN과 통신할 수 있다. 혹은 IN은 Mca를 통해 하나 이상의 ADN과 통신할 수 있다. IN은 M2M 서버로 지칭될 수 있다.
본 명세서에서 노드는 일반적으로 M2M 디바이스로 지칭될 수 있으며, ASN, ADN, MN, IN는 각각 M2M 디바이스, 제한적인 M2M 디바이스, M2M 게이트웨이, M2M 서버로 지칭될 수 있다.
도 4를 참조하면, 예 1(case 1)은 ADN(402)과 IN(422) 간의 통신을 예시한다. ADN(402)은 제한된 능력을 갖는 M2M 디바이스일 수 있다. 이 경우, ADN(402)은 CSE 또는 공통 서비스 계층을 갖지 않으므로 Mca를 통해 IN(422)의 CSE와 통신할 수 있다. 또한, 이 경우, ADN(402)은 CSE 또는 공통 서비스 계층을 갖지 않으므로 AE 또는 애플리케이션 계층에서 생성된 데이터를 다른 엔티티에 저장/공유할 수 없다. 따라서, 예 1(case 1)에서 ADN(402)의 AE 또는 애플리케이션 계층에서 생성된 데이터는 IN(422)의 CSE에 저장되어 공유될 수 있다.
예 2(case 2)는 ADN(404)과 MN(414) 간의 통신을 예시한다. ADN(404)도 제한된 능력을 갖는 M2M 디바이스일 수 있다. 따라서, ADN(404)이 MN(414)의 CSE과 통신한다는 점을 제외하고 예 1(case 1)과 유사하게 동작할 수 있다. 즉, ADN(404)은 Mca를 통해 MN(414)의 CSE와 통신할 수 있다. 또한, ADN(404)은 CSE 또는 공통 서비스 계층을 갖지 않으므로 AE 또는 애플리케이션 계층에서 생성된 데이터를 다른 엔티티에 저장/공유할 수 없다. 따라서, ADN(404)의 AE 또는 애플리케이션 계층에서 생성된 데이터는 MN(414)의 CSE에 저장되어 공유될 수 있다.
한편, 예 2(case 2)에서 MN(414)은 MN(412)을 거쳐 IN(422)과 통신할 수 있다. 이 경우 MN(414)과 MN(412), 그리고 MN(412)과 IN(422)은 Mcc를 통해 통신할 수 있다. MN(414)이 MN(412)을 거치지 않고 직접 IN(422)과 통신하는 것도 가능하다.
예 3(case 3)은 ASN(406)과 MN(414) 간의 통신을 예시한다. 예 1(case 1) 또는 예 2(case 2)와 달리, ASN(406)은 CSE 또는 공통 서비스 계층을 가지므로 ASN(406)의 AE 또는 애플리케이션 계층에서 생성된 데이터를 자신의 CSE 또는 공통 서비스 계층에 저장할 수 있다. 또한, ASN(406)의 AE는 ASN(406)의 CSE를 통해 MN(414)의 CSE와 통신할 수 있다.
예 4(case 4)는 ASN(408)과 MN(414) 간의 통신을 예시한다. 예 3(case 3)과 비교하여, ASN(408)의 CSE는 MN을 거치지 않고 직접 IN(422)의 CSE와 통신할 수 있다.
IN(422 또는 424)은 인프라스트럭처 도메인 또는 네트워크 도메인에 위치할 수 있고 하나의 CSE를 포함하고 0개 이상의 AE를 포함할 수 있다. IN들(422, 424)은 Mcc를 통해 서로 통신할 수 있다.
도 5는 M2M 시스템에서 사용되는 리소스(resource)를 예시한다.
M2M 시스템에서 애플리케이션 엔티티(AE), CSE, 데이터 등은 리소스(resource)로서 표현될 수 있다. M2M 시스템에서 리소스는 고유한 주소(예, URI(Universal Resource Identifier 또는 Uniform Resource Identifier))를 이용하여 고유하게 어드레싱 가능한 엔티티(uniquely addressable entity)를 지칭한다. M2M 시스템에서 리소스는 특정 데이터 구조로서 표현되며 각 리소스는 서로 논리적으로 연결될 수 있다. 리소스는 CSE 또는 공통 서비스 계층에 의해 관리되고 저장될 수 있다. 따라서, M2M 디바이스, M2M 게이트웨이, M2M 서버의 CSE 또는 공통 서비스 계층에서는 이러한 리소스를 가질 수 있다. 반면, M2M 시스템의 AE 또는 애플리케이션 계층에서는 이러한 리소스 구조를 가질 수 없다. 각 리소소는 자녀 리소스와 속성을 가진다. M2M 리소스에서 루트(Root) 리소스는 속성(attribute)과 자녀 리소스(child resource)를 가질 수 있다. 예를 들어, 리소스는 트리 구조로서 표현될 수 있다. 예를 들어, 루트 리소스의 타입은 <baseURI> 또는 <CSEBase>로 표시될 수 있다. 리소스의 타입은 “<”과 “>”에 의해 표시될 수 있다.
M2M 시스템에서는 다양한 리소스 타입이 정의되는데 M2M 애플리케이션들은 리소스 타입이 실체화(Instantiation)된 리소스를 기반으로 통신을 수행할 수 있다. 예를 들어, 애플리케이션을 등록하고 센서 값을 읽어 오는 등의 M2M 서비스를 수행하는 데 사용될 수 있다. 각각의 리소스는 해당 리소스 타입의 인스턴스가 생성될 때 고유한 주소 정보(예, URI)가 주어지며, 루트 리소스와 동일하게 속성 및 자녀 리소스를 가질 수 있으며 각 리소스들은 고유한 주소 정보를 이용하여 어드레싱될 수 있다. 특정 리소스 타입은 해당 리소스가 실체화(Instantiation)되었을 때 가질 수 있는 자식 리소스와 속성을 정의한다. 특정 리소스 실체화(Instantiation) 시 리소스는 해당 리소스의 리소스 타입에 정의된 속성과 자식 리소스를 가질 수 있다.
속성은 리소스 자체에 대한 정보를 저장하며 자녀 리소스를 가질 수 없다. 자녀 리소스는 자신의 속성과 자신의 자녀 리소스를 가질 수 있으며, 예를 들어 자녀 리소스에는 원격 CSE 리소스, 애플리케이션 엔티티 리소스, 접근 제어 리소스, 컨테이너 리소스, 그룹 리소스, 구독 리소스 등이 있다.
- 원격 CSE 리소스는 해당 CSE에 등록(연결)된 다른 CSE의 정보를 포함한다. 예를 들어, 원격 CSE 리소스의 타입은 <entity> 또는 <remoteCSE>으로 표시될 수 있다.
- 애플리케이션 엔티티 리소스: 루트 리소스의 애플리케이션 엔티티 리소스(예, <baseURI>/<application> 또는 <CSEBase>/<AE>) 또는 루트 리소스의 원격 CSE 리소스(예, <baseURI>/<entity> 또는 <CSEBase>/<remote CSE>) 하위에 존재하는 리소스이며, 루트 리소스의 애플리케이션 엔티티 리소스(예, <baseURI>/<application> 또는 <CSEBase>/<AE>)의 하위에 존재할 경우 해당 CSE에 등록(연결)된 애플리케이션 엔티티의 정보가 저장되며, 루트 리소스의 원격 CSE 리소스(예, <baseURI>/<entity> 또는 <CSEBase>/<remote CSE>) 하위에 존재할 경우 특정 원격 CSE에 등록된 애플리케이션 엔티티들의 정보를 저장한다. 예를 들어, 애플리케이션 엔티티 리소스의 타입은 <application> 또는 <AE>로 표시될 수 있다.
- 접근 제어 리소스: 접근 권한과 관련된 정보를 저장하는 리소스이다. 본 리소스에 포함된 접근 권한 정보를 이용하여 권한 부여(authorization)가 이루어질 수 있다. 예를 들어, 접근 제어 리소스의 타입은 <accessRight> 또는 <accessControlPolicy>으로 표시될 수 있다.
- 컨테이너 리소스: CSE 또는 AE 별로 생성되는 데이터를 저장한다. 예를 들어, 컨테이너 리소스의 타입은 <container>로 표시될 수 있다.
- 그룹 리소스: 여러 리소스를 하나로 묶어 함께 처리할 수 있도록 하는 기능을 제공한다. 예를 들어, 그룹 리소스의 타입은 <group>으로 표시될 수 있다.
- 구독 리소스: 리소스의 상태가 변경되는 것을 통지(Notification)를 통해 알려주는 기능을 수행한다. 예를 들어, 구독 리소스의 타입은 <subscription>으로 표시될 수 있다.
도 6은 특정 M2M 애플리케이션을 위한 리소스 타입를 예시한다. 앞서 설명된 바와 같이, 특정 M2M 애플리케이션을 위한 리소스는 M2M 게이트웨이의 CSE 또는 공통 서비스 계층의 리소스에서 애플리케이션 리소스(Application Resource)에 저장될 수 있다. 특정 M2M 애플리케이션을 위한 리소스는 전체 리소스와 유사하게 속성(attribute)과 자녀 리소스(child resource)를 가질 수 있다. 도 6의 예에서, 자녀 리소스는 타입(예, “<”, “>”으로 표시)으로 정의되어 있으며 실체화 시 실제 이름이 부여되고 저장된다.
도 7은 일반적인 M2M 시스템의 통신 흐름을 예시한다. 일반적으로 M2M 시스템의 동작은 데이터 교환을 기반으로 수행된다. 예를 들어, 특정 디바이스가 다른 디바이스의 동작을 멈추기 위해 해당 명령을 데이터 형태로 다른 장치에 전달할 수 있다. 디바이스 내에서 데이터를 저장하기 위해 특정 형태의 데이터 구조가 이용되는데 이를 자원(Resource, 리소스)이라고 지칭한다. 자원은 고유의 주소(예, URI)를 이용하여 어드레싱하거나 액세스할 수 있는 엔티티를 지칭하며, 특정 데이터 구조로서 표현될 수 있다.
도 7을 참조하면, AE와 CSE 간의 연결에서 또는 CSE들 간의 연결에서 요청 및 응답 방식(Request and Response Scheme)이 사용된다. 발신자(originator)는 수신자(receiver)에 저장된 자원(resource)을 요청하기 위해 요청 메시지를 전송하고 그에 대한 응답으로 응답 메시지를 수신할 수 있다. 마찬가지로, 수신자는 발신자로부터 자원을 요청하는 메시지를 수신하고 그에 대한 응답으로 응답 메시지를 발신자로 전송할 수 있다. 본 명세서에서, 요청 메시지는 요청으로 약칭될 수 있고 응답 메시지는 응답으로 약칭될 수 있다. 발신자에서 수신자로 전송되는 요청 메시지는 다음과 같은 정보를 포함할 수 있다.
- op: 실행되는 동작(Operation)의 형태. 생성(Create)/회수(Retrieve)/갱신(Update)/삭제(Delete)/통지(Notify) 중 하나일 수 있다. 본 명세서에서 동작에 해당하는 정보는 명령(command)라고 지칭될 수 있다.
- to: 목적 자원의 URI
- fr: 요청(Request)을 생성한 발신자(Originator)의 식별 정보(또는 ID)
- mi: 해당 요청(Request)에 대한 추가 정보(Meta information)
- cn: 전달되는 자원의 내용
해당 요청(Request)이 성공적으로 수행된 경우 응답(Response) 메시지는 다음과 같은 정보를 포함할 수 있다. 응답 메시지는 아래 정보 중에서 적어도 하나를 포함할 수 있으며, 또는 결과값(rs)만을 포함할 수도 있다.
- to: 요청(Request)을 생성한 발신자(Originator)의 식별 정보(또는 ID)
- fr: 요청(Request)을 수신한 수신자(receiver)의 식별 정보(또는 ID)
- mi: 요청(Request)에 대한 추가 정보(Meta information)
- rs: 요청(Request)에 대한 결과(예를 들어, Okay, Okay and Done, Okay and in progress)
- ai: 추가적인 정보
- cn: 전달되는 자원의 내용
해당 요청(Request)이 실패한 경우 응답(Response) 메시지는 다음과 같은 정보를 포함할 수 있다.
- to: 요청(Request)을 생성한 발신자(Originator)의 ID
- fr: 요청을 수신한 수신자(receiver)의 ID
- mi: 요청(Request)에 대한 추가 정보(Meta information)
- rs: 요청에 대한 결과 (예를 들어, Not Okay)
- ai: 추가적인 정보
본 명세서에서, 발신자는 발신자 디바이스(또는 그 안의 CSE 또는 AE)을 나타내고, 수신자는 수신자 디바이스(또는 그 안의 CSE 또는 AE)를 나타낼 수 있다. 또한, 자원을 가지고 있는 디바이스(또는 그 안의 CSE)를 호스팅 디바이스(또는 호스팅 CSE)라고 지칭한다.
일 예로, 발신자는 수신자 상에 자원을 생성하기 위해 도 7에 예시된 방식을 이용할 수 있다. 이 경우, 발신자는 자원 생성 요청 메시지(예, CREATE request)를 수신자로 전송할 수 있다. 자원 생성 요청 메시지는 다음과 같은 정보를 포함할 수 있다.
- op: C(Create)
- to: 생성 대상 자원의 부모의 URI
- fr: 발신자 ID
- cn: 생성 대상 자원의 속성 정보를 포함하며, 선택 사항으로(optionally) 생성 대상 자원의 식별 정보(예, 생성 대상 자원의 이름)를 포함할 수 있다.
수신자가 자원 생성 요청 메시지를 받는 경우, 수신자는 발신자가 인증되었는지를 확인한다. 생성 대상 자원에 대한 정보(예, 액세스 권한(access rights) 또는 액세스 제어 정책 (access control policy))가 아직 수신자에게 알려져 있지 않기 때문에 수신자는 발신자를 인증함으로써 자원 생성 여부를 결정할 수 있다. 발신자가 인증된 경우에 대상 자원의 생성이 허용될 수 있다. 또한, 자원 생성 요청 메시지에 생성 대상 자원의 식별 정보가 포함되는 경우, 수신자는 생성 대상 자원의 식별 정보가 수신자의 자원 구조에 이미 존재하는지 여부를 검증(verify)한다. 만일 유효한 식별 정보가 제공되지 않은 경우(예를 들어, 생성 대상 자원의 식별 정보가 중복되는 경우), 수신자는 생성 대상 자원의 식별 정보를 할당할 수 있다. 마찬가지로, 만일 자원 생성 요청 메시지가 생성 대상 자원의 식별 정보를 포함하지 않는 경우, 수신자는 생성 대상 자원의 식별 정보를 할당할 수 있다.
수신자는 생성 대상 자원을 성공적으로 생성한 경우 다음 정보를 포함하는 응답 메시지를 발신자로 전송할 수 있다.
- to : 발신자 ID
- fr : 수신자 ID
- cn : 생성된 자원의 URI 및/또는 내용(content)
다른 예로, 발신자는 수신자 상의 자원에 관한 정보(예, 속성 정보)를 회수(retrieve)하기 위해 도 7에 예시된 방식을 이용할 수 있다. 이 경우, 발신자는 수신자 상의 자원에 관한 정보(예, 속성 정보)를 회수(retrieve)하기 위해 회수 요청 메시지(예, RETRIEVE request)를 수신자로 전송할 수 있다. 발신자는 회수 요청 메시지를 통해 수신자의 대상 자원에서 모든 속성을 회수하거나 일부 속성만을 회수할 수 있다. 회수 요청 메시지는 다음과 같은 정보를 포함할 수 있다.
- op: R(Retrieve)
- to: 회수 대상 자원의 URI
- fr: 발신자 ID
수신자는 발신자로부터 회수 요청 메시지를 수신하면, 회수 요청 메시지에서 회수 대상 자원의 URI를 참조하여 회수 대상 자원이 존재하는지 검증하고 발신자가 회수 대상 자원에 대해 회수 권한(permission for retrieving)을 가지는지 여부를 확인한다. 만일 회수 대상 자원이 존재하지 않거나 발신자가 정당한 회수 권한을 가지지 않는 경우 수신자는 응답메시지를 통해 오류(error)를 전송할 수 있다. 반대로, 회수 대상 자원이 존재하고 발신자가 정당한 회수 권한을 가지는 경우 수신자는 응답 메시지를 발신자로 전송할 수 있다. 응답 메시지는 다음과 같은 정보를 포함할 수 있다.
- to : 발신자 ID
- fr : 수신자 ID
- cn : 회수 대상 자원의 내용(content)
또 다른 예로, 발신자는 수신자 상의 특정 자원에서 속성 정보를 갱신(update)하기 위해 도 7에 예시된 절차를 이용할 수 있다. 이 경우, 발신자는 갱신 요청 메시지(예, UPDATE request)를 수신자로 전송할 수 있다. 발신자는 갱신 요청 메시지를 통해 수신자 상의 특정 자원에서 속성 정보를 새로운 값으로 갱신할 수 있다. 갱신 요청 메시지는 다음과 같은 정보를 포함할 수 있다.
- op: U(Update)
- to: 갱신 대상 자원의 URI
- fr: 발신자 ID
- cn : 갱신 대상 자원에서 갱신될 정보
수신자는 발신자로부터 갱신 요청 메시지를 수신하면, 갱신 요청 메시지에서 갱신 대상 자원의 URI를 참조하여 갱신 대상 자원이 존재하는지 검증하고 발신자가 갱신 대상 자원을 수정하는 것에 대해 권한 부여가 되었는지 여부(whether the originator is authorized to perform modifying the target resource)를 확인한다. 만일 갱신 대상 자원이 존재하고 발신자가 정당한 권한 부여가 된 경우 수신자는 갱신 대상 자원을 갱신될 정보(예, cn)로 갱신할 수 있다. 성공적으로 갱신된 경우 수신자는 응답 메시지를 발신자로 전송할 수 있다. 응답 메시지는 다음과 같은 정보를 포함할 수 있다.
- to : 발신자 ID
- fr : 수신자 ID
- cn : 동작 결과
또 다른 예로, 발신자는 수신자 상에서 특정 자원을 삭제(delete)하기 위해 도 7에 예시된 절차를 이용할 수 있다. 이 경우, 발신자는 삭제 요청 메시지(예, DELETE request)를 수신자로 전송할 수 있다. 삭제 요청 메시지는 다음과 같은 정보를 포함할 수 있다.
- op: D(Delete)
- to: 삭제 대상 자원의 URI
- fr: 발신자 ID
수신자는 발신자로부터 삭제 요청 메시지를 수신하면, 회수 요청 메시지에서 삭제 대상 자원의 URI를 참조하여 삭제 대상 자원이 존재하는지 검증하고 발신자가 대상 자원을 삭제하는 것에 대해 권한 부여가 되었는지 여부(whether the originator is authorized to delete the target resource)를 확인한다. 만일 대상 자원이 존재하지 않거나 발신자가 권한 부여가 되지 않은 경우 수신자는 응답메시지를 통해 오류(error)를 전송할 수 있다. 반대로, 대상 자원이 존재하고 발신자가 권한 부여가 된 경우 수신자는 다음과 같은 정보를 포함하는 응답 메시지를 발신자로 전송할 수 있다.
- to : 발신자 ID
- fr : 수신자 ID
- cn : 동작 결과
도 8은 M2M 시스템에서 서로 다른 엔티티들이 상호 연동하는 예를 예시한다.
도 8을 참조하면, M2M 서버에 등록된 AE(application2)가 M2M 디바이스(M2M Device)내 등록된 AE(Application1)과 연동하는 예가 도시되어 있다. 예를 들어, M2M 디바이스는 물리적인 장치인 센서를 포함할 수 있으며, 센서로부터 획득한 정보를 CSE에 저장하고, IN에 등록된 AE는 M2M 디바이스에 저장된 상기 센서 값을 읽어올 수 있다.
M2M 디바이스 상에 존재하는 AE(application1)는 센서에서 값을 읽어 읽은 값을 자신이 등록한 CSE(dcse)에 자원 형태(예, <container> 자원)로 저장한다. 이를 위해, M2M 디바이스 상에 존재하는 AE(application1)는 M2M 디바이스에 존재하는 CSE에 먼저 등록해야 한다. 도 8에 예시된 바와 같이, 등록이 완료되면, dcse/applications/application1 자원의 형태로 등록된 M2M 애플리케이션 관련 정보가 저장된다. 예를 들어, M2M 디바이스의 센서 값이 AE(application1)에 의해 dcse/applications/application1 리소스 하위의 Container 자원에 저장되면, IN(Infrastructure Node)에 등록된 AE(application2)가 해당 값에 접근할 수 있다. 또한, AE(application2)가 M2M 디바이스에 접근하기 위해서는 M2M 서버의 CSE(ncse)에 등록되어야 한다. 이는 AE(application1)가 CSE(dcse)에 등록하는 방법과 같이 ncse/applications/application2 자원에 AE(application2)에 대한 정보가 저장된다. 또한, AE(application1)는 AE(application2)와 직접 통신하는 것이 아니라 중간의 CSE(ncse)와 CSE(dcse)를 통해 통신할 수 있다. 이를 위해, CSE(ncse)와 CSE(dcse)는 상호 등록되어야 한다. CSE(dcse)가 CSE(ncse)에 등록하면, ncse/cses/dcse 자원 하위에 dcse 관련 정보(예, Link)가 저장된다. 이를 통해 AE(application2)는 AE(application1)의 정보에 접근할 수 있는 경로를 얻게 되어 해당 경로를 통해 센서의 값을 읽을 수 있다.
도 9는 M2M 시스템의 오버레이 네트워크와 물리 네트워크의 구조를 예시한다.
M2M 시스템(예, oneM2M)은 오버레이 네트워크(Overlay Network) 구조로 구성된다. 오버레이 네트워크는 개념적으로 물리 네트워크 위에 성립되는 가상의 네트워크를 의미한다. 이 오버레이 네트워크 구조 내의 노드(예를 들어 oneM2M 에서는 상술한 바와 같이 ADN, ASN, MN, IN 등이 노드로 매핑되거나, M2M 디바이스, 제한적인 M2M 디바이스, M2M 게이트웨이, M2M 서버와 매핑 될 수 있다)는 가상, 논리 링크로 연결될 수 있다. 각 링크는 실제 물리 네트워크 안에서 많은 물리적 링크를 통하지만, 통신이나 실제 동작을 위해서는 물리적 링크를 고려하지는 않는다.
예를 들어, 도 9(a)을 참조하면, 물리 네트워크에서는 물리적으로 4 개의 홉(Hop)으로 연결된 네트워크이지만, 오버레이 네트워크에서는 2 개의 홉(Hop)으로 연결된 것과 같이 보일 수 있다. 홉(Hop)은 네트워크에 존재하는 노드(Node)와 노드(Node) 사이의 연결을 통칭하는 용어이다. 또한, 노드들 간의 리스트로서 노드와 노드 간의 연결 및 네트워크 구조를 나타내는 정보를 토폴로지(topology) 정보라고 지칭할 수 있다.
실제 물리 네트워크 노드와 오버레이 네트워크의 노드(즉, 오버레이 노드)가 동일하지 않을 수 있는 이유는 다음과 같다.
1. 기능적인 차이로 인해 노드가 생성될 수 있다. 예를 들어, 물리 네트워크에서 특별한 기능을 수행하는 일부 디바이스가 오버레이 노드로 선정될 수 있다. 각각의 디바이스는 물리 네트워크 노드로 선정될 수 있다.
2. 연결된 네트워크의 차이로 상위 노드의 차이가 있을 수 있다. 예를 들어, 도 9(b)를 참조하면, 물리 네트워크가 블루투스(Bluetooth), 와이파이(Wi-Fi), WAN(Wide Area Network)으로 연결될 수 있고 각각의 네트워크마다 M2M 게이트웨이(Gateway)가 존재할 수 있다. 예를 들어, 블루투스 네트워크의 경우 기저(또는 물리) 네트워크에서는 디바이스(A, B, C)가 물리적 노드이고, 와이파이 네트워크의 경우 기저(또는 물리) 네트워크에서는 디바이스(C, D, E)가 물리적 노드이고, WAN의 경우 기저(또는 물리) 네트워크에서는 디바이스(E, F, G)가 물리적 노드일 수 있다. 하지만, 오버레이 네트워크에서는 각 게이트웨이를 제외한 나머지 노드(B, D, F)는 보이지 않을 수 있고 게이트웨이(A, C, E, G)가 노드로 보여질 수 있다.
한편, M2M 공통 서비스 계층은 위치 서버를 통해서 위치 정보를 가져오거나, 애플리케이션을 통해서 위치 정보를 가져와 저장할 수 있다. 위치 서버는 이동통신망을 소유한 네트워크 사업자 네트워크 내에 존재하여 단말의 위치 계산을 위해 필요한 도움 정보를 제공하거나, 위치 계산에 직접 참여하는 개체(entity)를 지칭할 수 있다. 위치 정보를 애플리케이션을 통해 가져온다는 것은 M2M 디바이스(ASN)이나 제한적인 M2M 디바이스(ADN)과 같은 AE를 포함한 노드가 표준화 영역 밖의 방식(예를 들어, Mcc, Mca, Mcn Reference Point 내 정보 전달 외의 방식)으로 자신의 위치를 획득한 경우에 자신의 위치를 자원에 저장하는 것을 지칭할 수 있다. 예를 들어, GPS 모듈을 통해 내부적으로 획득한 위치 정보를 자원에 저장할 수 있다.
위치 정보를 획득하려는 M2M 디바이스가 자원의 제약이 있거나 제한된 능력을 갖는 제한적인 M2M 디바이스인 경우 다음과 같은 문제가 발생할 수 있다.
- 위치 서버와 연결이 없는 경우: 일반적으로 위치 서버는 이통망의 코어 네트워크의 일부 컴포넌트이므로, 이통망 기반의 M2M 디바이스가 아닌 경우(예, USIM(Universal Subscriber Identity Module)이 없는 디바이스) 위치 서버와 연결되지 못할 수 있다.
- 애플리케이션을 통해 위치 정보를 획득할 수 없는 경우: M2M 시스템 내에서 애플리케이션을 통해 위치 정보를 획득할 수 있는 능력(Capability)을 갖지 못하는 디바이스가 존재할 수 있다. 위에 언급한 바와 같이, 애플리케이션을 통해 위치 정보를 가지고 온다는 것은 노드에 있는 AE가 자신의 로직(Logic)을 가지고 디바이스 능력(Device Capability)을 통해 위치 정보를 획득하는 것을 지칭한다. 예를 들어, AE가 GPS 모듈을 직접 제어하여 위치 정보를 획득하는 방식이나, 별도의 다른 장치나 논리적인 방식을 통해 위치 정보를 획득하는 것을 지칭할 수 있다.
따라서, 특정 디바이스가 위치 서버와 연결될 수 없고 애플리케이션을 통해 위치 정보를 획득할 수 없는 경우 해당 디바이스는 자신의 위치 정보를 획득하지 못할 수 있다. 예를 들어, 헬스 케어(Health Care) 서비스를 위한 혈압기(노드)가 있다고 가정하자. 이때, 해당 혈압기는 비용 절감의 목적으로 별도로 위치 서버와 연결될 필요가 없고, GPS와 같은 위치 획득을 위한 별도의 장치나 논리적 알고리즘을 갖지 못할 수 있다. 하지만, 혈압기의 위치 정보를 파악할 수 있다면, 응급상황과 같은 상황에서 서비스의 확장성을 제공할 수 있다.
이에 본 발명에서는 M2M 시스템에서 M2M 디바이스가 위치 정보를 획득할 수 없는 경우 제한적인 M2M 디바이스의 위치 정보를 결정하는 방법을 제안한다.
먼저 M2M 시스템에서 위치 정보 획득을 위한 자원 구조를 제안한다. 본 발명에서는 타겟 단말의 위치 정보를 획득하는 방식을 저장하는 자원과 타겟 단말의 위치 정보가 저장되는 자원을 제안한다. 타겟 단말은 위치 정보를 획득하려는 노드(또는 디바이스)를 지칭할 수 있다.
도 10은 본 발명에 따른 타겟 단말의 위치 정보를 획득하는 방식을 저장하는 자원을 예시한다. 본 명세서에서 타겟 단말의 위치 정보를 획득하는 방식을 저장하는 자원은 <locationPolicy> 자원으로 지칭되지만, 이 외에도 다른 이름이 사용될 수 있다.
<locationPolicy> 자원은 M2M 디바이스의 지리적 위치 정보(geographical location information)를 획득하고 관리하기 위한 방식을 나타낸다. <locationPolicy> 자원은 위치 정보를 저장하는 역할을 하는 것이 아니라, 위치 정보를 획득하고 관리하는 방식을 저장하는 자원으로 사용된다. 실제 위치 정보는 <container> 자원의 자식 자원인 <instance> 자원에 저장된다. <container> 자원은 <locationPolicy> 자원의 URI를 링크(linkage)로서 보유하는 속성 정보(예, locationID)를 가질 수 있다. 위치 공통 서비스 기능(LOC CSF)(도 3 참조)은 <locationPolicy> 자원 아래에 정의된 속성들을 기반으로 위치 정보를 획득하고 타겟 <container>에 위치 정보를 저장할 수 있다.
표 1은 <locationPolicy> 자원 관련 속성(attribute)을 예시한다. 표 1에서 R/W는 해당 속성의 읽기(read)/쓰기(write) 허용여부(permission)을 나타내며, READ/WRITE(RW), READ ONLY(RO), WRITE ONLY(WO) 중 하나일 수 있다. 또한, 표 1에서 발생횟수(multiplicity)는 해당 속성이 <locationPolicy> 자원에서 발생가능한 횟수를 나타낸다. 따라서, 발생횟수(multiplicity)가 1인 경우 해당 속성은 <locationPolicy> 자원에 필수적(mandatory)으로 하나가 포함되고, 1..n인 경우 필수적으로 하나 이상이 포함되고, 0..1인 경우 선택적(optional)으로 하나 이하가 포함되고, 0..n인 경우 선택적으로 하나 이상이 포함될 수 있다. 표 1은 오로지 예시일 뿐이며 <locationPolicy> 자원의 속성은 표 1과 다르게 구성될 수 있다.
표 1
Figure PCTKR2014005179-appb-T000001
<locationPolicy> 자원은 도 7을 참조하여 설명된 요청/응답 방식을 이용하여 핸들링될 수 있다. 따라서, <locationPolicy> 자원을 호스팅 CSE에 생성하기 위해 AE는 생성 요청 메시지를 호스팅 CSE로 전송하고, <locationPolicy> 자원을 회수하기 위해 AE는 회수 요청 메시지를 호스팅 CSE로 전송하고, <locationPolicy> 자원을 업데이트하기 위해 AE는 갱신 요청 메시지를 호스팅 CSE로 전송하고, <locationPolicy> 자원을 제거하기 위해 AE는 제거 요청 메시지를 호스팅 CSE로 전송할 수 있다.
<locationPolicy> 자원의 생성 요청 메시지는 다음 정보를 포함할 수 있다.
- op: C 또는 CREATE
- fr: 요청을 생성한 AE 또는 CSE의 식별자
- to: <CSEBase> 자원의 URI
- cn: <locationPolicy> 자원의 표현(representation)
<locationPolicy> 자원의 생성 요청에 대한 응답 메시지는 생성된 <locationPolicy> 자원의 표현(representation)을 포함할 수 있으며, 해당 표현에는 표 1에 명시된 속성 값들이 설정된다.
<locationPolicy> 자원의 회수 요청 메시지는 다음 정보를 포함할 수 있다.
- op: R 또는 RETRIEVE
- fr: 요청을 생성한 AE 또는 CSE의 식별자
- to: <locationPolicy> 자원의 URI
<locationPolicy> 자원의 회수 요청에 대한 응답 메시지는 다음 정보를 포함할 수 있다.
- to : 발신자 ID
- fr : 수신자 ID
- cn : <locationPolicy> 자원의 내용(content)
<locationPolicy> 자원의 갱신 요청 메시지는 다음 정보를 포함할 수 있다.
- op: U 또는 UPDATE
- fr: 요청을 생성한 AE 또는 CSE의 식별자
- to: 타겟 <locationPolicy> 자원의 URI
- cn : 갱신될 속성 정보
<locationPolicy> 자원의 갱신 요청에 대한 응답 메시지는 다음 정보를 포함할 수 있다.
- to : 발신자 ID
- fr : 수신자 ID
- cn : 동작 결과
<locationPolicy> 자원의 삭제 요청 메시지는 다음 정보를 포함할 수 있다.
- op: D 또는 DELETE
- fr: 요청을 생성한 AE 또는 CSE의 식별자
- to: 타겟 <locationPolicy> 자원의 URI
<locationPolicy> 자원의 삭제 요청에 대한 응답 메시지는 다음 정보를 포함할 수 있다.
- to : 발신자 ID
- fr : 수신자 ID
- cn : 동작 결과
도 11은 본 발명에 따라 타겟 단말의 위치 정보를 저장하는 자원을 예시한다. 본 명세서에서 타겟 단말의 위치 정보를 저장하는 자원은 <container> 자원으로 지칭되지만, 이 외에도 다른 이름이 사용될 수 있다.
<container> 자원은 데이터 인스턴스를 위한 컨테이너를 나타낸다. 이 자원은 서로 다른 엔티티들 간에 정보를 공유하는 데 이용될 수 있으며, 데이터를 추적(track)하는 데 이용될 수 잇다. 컨테이너 자원은 속성 정보와 자식 자원을 가질 수 있다.
표 2는 <container> 자원 관련 속성(attribute)을 예시한다. 표 2에서 R/W는 해당 속성의 읽기(read)/쓰기(write) 허용여부(permission)을 나타내며, READ/WRITE(RW), READ ONLY(RO), WRITE ONLY(WO) 중 하나일 수 있다. 또한, 표 2에서 발생횟수(multiplicity)는 해당 속성이 <container> 자원에서 발생가능한 횟수를 나타낸다. 표 2는 오로지 예시일 뿐이며 <container> 자원의 속성은 표 2와 다르게 구성될 수 있다.
표 2
Figure PCTKR2014005179-appb-T000002
도 12는 본 발명에 따라 M2M 디바이스의 속성 정보를 저장하는 자원을 예시한다. 본 명세서에서 M2M 디바이스의 속성 정보를 저장하는 자원은 <node> 자원으로 지칭되지만, 이 외에도 다른 이름이 사용될 수 있다.
<node> 자원은 다른 M2M 동작에 의해 이용될 수 있는 M2M 디바이스의 특정 정보를 포함할 수 있다. 예를 들어, CMDH CSF는 타겟 CSE의 도달가능성 스케줄(reachability schedule)을 기반으로 언제 타겟 CSE로 요청 메시지를 보낼지를 결정할 수 있다. <node> 자원은 도달가능성 스케줄, 컨텍스트 정보(예, 메모리 및 저장부(storage)), 및 <node> 자원으로 표현되는 디바이스가 M2M 게이트웨이인 경우, M2M 게이트웨이에 연결된 장치들의 네트워크 토폴로지와 같은 정보를 보유할 수 있다. <node> 자원은 특정 M2M 디바이스(또는 노드)의 정보를 포함하며 M2M 동작을 지원하기 위한 추가 정보를 포함할 수 있다. 메모리 및 저장부와 같은 노드 특정 정보는 기존 장치 관리 기술(예, OMA(Open Mobile Alliance) DM(Device Management) 등)이나 다른 방법(예, JNI(Java Native Interface))에 의해 획득될 수 있다.
<node> 자원의 위치는 디바이스의 타입에 따라 달라질 수 있다. 예를 들어, M2M 디바이스(ASN)를 위한 <node> 자원은 로컬 CSE의 루트(예, <baseURI>) 아래에 위치할 수 있다. 또한, 예를 들어, 제한적인 M2M 디바이스(ADN)을 위한 <node> 자원은 호스팅 CSE의 <Application> 자원 아래에 위치할 수 있다. 또한, 예를 들어, M2M 게이트웨이(MN)을 위한 <node> 자원은 로컬 CSE의 루트(예, <baseURI>) 아래에 위치할 수 있다.
표 3은 <node> 자원이 가질 수 있는 자식 자원들을 예시한다. 표 3에서 발생횟수(multiplicity)는 해당 자원이 <node> 자원에서 발생가능한 횟수를 나타낸다. 표 3은 오로지 예시일 뿐이며 <node> 자원은 표 3과 다르게 구성될 수 있다.
표 3
Figure PCTKR2014005179-appb-T000003
도 13은 네트워크 토폴로지를 예시한다. 본 명세서에서 네트워크 토폴로지 정보를 저장하기 위한 자원은 <networkTopology> 자원으로 지칭되지만, 다른 이름으로 지칭될 수도 있다.
<networkTopology> 자원은 <node> 자원의 자식 자원이며 <node> 자원을 가지는 장치가 M2M 게이트웨이(MN)일 때 정의될 수 있다. 네트워크 토폴로지 정보는 M2M 게이트웨이(MN)에 연결된 M2M 디바이스(ASN or ADN)들의 리스트를 기술하며 M2M 영역 네트워크의 노드들 간에 물리적 관계(physical relation) 또는 기저 관계(underlying relation)를 기술한다. 네트워크 토폴로지 정보는 실제 물리적으로 연결된 M2M 영역 네트워크의 구성 정보를 포함할 수 있다. 네트워크 토폴로지 정보는 간략히 토폴로지 정보라고 지칭될 수 있다. <networkTopology> 자원은 네트워크 토폴로지 정보를 저장하는 데 사용된다.
도 13을 참조하면, 오버레이 네트워크와 물리 네트워크 측면에서 노드들 간의 관계(relation)가 예시되어 있다. 예를 들어, 오버레이 네트워크는 oneM2M 네트워크일 수 있고, 물리 네트워크는 지그비(Zigbee) 네트워크일 수 있다. 오버레이 네트워크 측면에서 보면, 각 ADN(예, ADN_1 내지 ADN_5)은 물리 네트워크의 구성과 관계없이 Mca 기준점을 통해 MN과 연결된다. 따라서, 오버레이 네트워크 측면에서 각 ADN과 MN은 하나의 홉(hop)으로 연결된 것으로 볼 수 있다. 반면, 물리 네트워크 측면에서 보면, 각 ADN(예, ADN_1 내지 ADN_5)은 메쉬(mesh) 형태로 연결된다. 따라서, 물리 네트워크 측면에서 ADN_2는 MN과 2개의 홉으로 연결될 수 있고, ADN_5는 MN과 4개의 홉으로 연결된 것으로 볼 수 있다. 네트워크 토폴로지 정보는 물리 네트워크의 구성 정보를 포함하며 실제 노드들의 연결 관계를 나타낼 수 있다. 따라서, <networkTopology> 자원은 물리 네트워크 측면에서 노드들의 관계를 기술하는 정보를 포함한다.
이하, M2M 시스템에서 M2M 단말의 위치 정보 획득 및 관리 방식에 대해 설명한다.
위치 공통 서비스 기능(LOC CSF)은 위치 기반 서비스를 위해 M2M AE들이 M2M 노드들(예, ASN, MN)의 지리적 위치 정보를 획득할 수 있게 한다. 이러한 위치 정보는 로컬 노드(local node) 또는 리모트 노드(remote node) 상에 존재하는 M2M AE들로부터 요청될 수 있다. LOC CSF는 로컬 노드 또는 리모트 노드 상에 존재하는 M2M AE들로부터의 요청을 기반으로 지리적 위치 정보를 획득하고 관리할 수 있다. LOC CSF는 기저 네트워크(underlying network)의 위치 서버, M2M 디바이스에서의 GPS 모듈, 또는 다른 M2M 노드들에 저장된 위치를 유추(infer)하기 위한 정보 중에서 적어도 하나와 상호 작용할 수 있다.
위치 정보를 업데이트하기 위해, M2M AE는 CSE에 저장되는 <locationPolicy> 자원 속성(예, locationSource 속성 또는 locationUpdatePeriod 속성)을 설정할 수 있다. 정의된 속성을 기반으로, LOC CSF는 정의된 상호 작용 중에서 하나를 이용하여 위치 정보를 업데이트할 수 있다. LOC CSF는 M2M 노드들에게 자신의 지리적 위치 정보 또는 다른 M2M 노드들의 지리적 위치 정보를 M2M 애플리케이션들과 공유/보고하도록 요청할 수 있다. 추가적으로 LOC CSF는 지리적 위치 정보의 기밀성(confidentiality)을 보호하기 위한 수단을 제공할 수 있다.
본 발명에서는 단말의 위치 정보를 획득하는 방식을 저장하는 자원(예, <locationPolicy> 자원)과 타겟 단말의 위치 정보를 저장하는 자원(예, <container> 자원)에 정보를 저장 또는 변경하는 과정을 통해 타겟 단말의 위치 정보를 획득하는 방식을 제안한다. 본 발명은 예를 들어 <locationPolicy> 자원의 생성을 통해 타겟 단말의 위치 정보 획득 방법을 정의하고 이를 기반으로 CSE에서 <container> 자원(또는 <container> 자원에 자식 자원의 <instance> 자원)에 획득한 위치 정보를 저장하는 방식으로 동작한다.
<locationPolicy> 자원 기반으로 위치 정보 획득 방식을 제공하는 방안
AE가 타겟 단말의 위치 정보를 획득하고 싶은 경우에는 AE가 연결되어 있는 CSE에 <locationPolicy> 자원을 생성할 수 있다. <locationPolicy> 자원을 생성하기 위해 발신자 AE는 관련 속성들과 호스팅 CSE의 루트(예, <baseURI>) 자원의 주소를 포함하는 <locationPolicy> 자원을 생성할 것을 요청할 수 있다(도 7 및 도 10 관련 설명 참조). 또한, 예를 들어, 생성 요청은 표 1에 예시된 속성들 중에서 적어도 하나를 포함할 수 있다.
수신자(예, 호스팅 CSE)는 생성 요청을 수신하면 다음과 같은 동작을 수행할 수 있다.
- 발신자(AE)가 생성 절차를 요청할 권한을 가지는지 여부를 검사할 수 있다(Check whether the Originator is authorized to request the procedure).
- <locationPolicy> 자원에 대해 제공된 속성들이 위치 정보를 획득하고 관리하기에 유효한 요청을 나타내는지 여부를 검사할 수 있다(Check whether the provided attributes of the <locationPolicy> resource represent a valid request for obtaining and managing location information).
- 상기 절차를 성공적으로 검사한 경우, 요청된 <locationPolicy> 자원을 생성하고 자동으로 실제 위치 정보가 저장되는 <container>와 그것의 자식 <instance> 자원들을 생성할 수 있다(Upon successful validation of the above procedures, create the requested <locationPolicy> resource and automatically creates <container> and its child <instance> resources where the actual location information is stored). 상기 자원들은 상호 참조 속성(cross-reference attribute)을 가질 수 있는데, 예를 들어 <locationPolicy> 자원을 위한 locationContainerID 속성과 <container> 자원을 위한 locationID 속성 간에 상호 참조가 형성될 수 있다.
- locationUpdatePeriod 속성을 검사할 수 있다(Check the locationUpdatePeriod attribute). 예를 들어, locationUpdatePeriod 속성의 값이 0보다 크도록 설정되면, 호스팅 CSE는 정의된 속성들에 따라 절차를 수행하고 그 결과(예, 위치 측정(position fix), 불확실성(uncertainty) 등)를 생성된 <container> 자원에 저장할 수 있다. 하지만, locationUpdatePeriod 속성의 값이 0으로 설정되는 경우, 위치 측정 절차(positioning procedure)는 위치 정보가 저장된 <container> 자원이 회수(retrieve)될 때에만 수행될 수 있다.
- locationSource 속성을 검사할 수 있다. locationSource 속성에 따라 위치 측정 절차가 달리 수행될 수 있다. locationSource 속성은 타겟 단말과 위치 정보를 요청한 발신자가 존재하는 네트워크의 능력을 기반으로 설정될 수 있다. locationSource 속성이 네트워크 기반, 디바이스 기반, 공유 기반 중에서 어느 하나로 설정되고 locationUpdatePeriod 속성이 0보다 큰 값으로 설정된 경우 다음 단계로 진행할 수 있다.
locationSource 속성은 다음 중 하나로 설정될 수 있다.
■ 네트워크 기반(network based): 호스팅 CSE는 <locationPolicy> 자원에 정의된 속성들(예, locationTargetID, locationServer 등)에 따라 발신자로부터 수신된 요청을 위치 서버로의 요청으로 변환할 수 있다. 만일 속성들(예, locationTargetID, locationServer 등) 중 하나가 회수될 수 없는 경우 호스팅 CSE는 에러 코드로 요청을 거절할 수 있다. 또한, 호스팅 CSE는 로컬 정책에 따라 위치 서버 요청의 다른 파라미터들에 대해 디폴트 값을 제공할 수 있다. 그런 다음, 위치 서버는 기저 네트워크에서 위치 측정 절차를 수행하고 그 결과를 반환할 수 있다. 호스팅 CSE는 반환된 위치 정보를 <container> 자원에 저장할 수 있다. 위치 서버와의 통신에 이용되는 메카니즘은 기저 네트워크의 능력 및 다른 인자(factor)들에 의존할 수 있다. 예를 들어, 호스팅 CSE와 위치 서버 간의 통신은 OMA(Open Mobile Appliance) 모바일 위치 프로토콜(mobile location protocol) 또는 단말 위치를 위한 OMA RESTful NetAPI를 따를 수 있다. 또한, 호스팅 CSE는 주기 정보(예, locationUpdatePeriod 속성)를 기반으로 상기 절차를 반복할 수 있다. 혹은, 주기 정보를 기반으로 위치 서버가 호스팅 CSE에게 위치 정보를 주기적으로 통지할 수 있다.
■ 디바이스 기반(device based): 이 경우는 발신자가 ASN-AE이고 상기 M2M 디바이스(ASN)이 위치 결정 능력(location determination capability)(예, GPS)을 가지는 경우에 적용될 수 있다. 호스팅 CSE는 위치 측정 모듈 또는 기술을 이용하여 위치 측정 절차(positioning procedure)를 수행할 수 있다. 예를 들어, M2M 디바이스(ASN)이 GPS 모듈을 가지는 경우, ASN-CSE는 내부 인터페이스(예, 시스템 호출)를 통해 GPS 모듈로부터 M2M 디바이스의 위치 정보를 획득할 수 있다. 호스팅 CSE는 주기 정보(예, locationUpdatePeriod 속성)를 기반으로 상기 절차를 반복할 수 있다.
■ 공유 기반(sharing based): 이 경우는 발신자가 제한적인 M2M 디바이스(ADN-AE)이고 호스팅 CSE가 M2M 게이트웨이(MN)의 MN-CSE이고 상기 제한적인 M2M 디바이스(ADN)이 자원 제한적인 노드(resource constrained node)인 경우에 적용될 수 있다. 자원 제한적인 노드는 위치 결정 능력(예, GPS)을 가지지 못하고 네트워크 기반 위치 측정 능력을 가지지 못하는 노드를 지칭할 수 있다. 호스팅 CSE가 생성 요청을 수신했을 때, 호스팅 CSE는 <node> 자원을 이용하여 M2M 영역 네트워크의 토폴로지 정보를 수집할 수 있다. 또한, 호스팅 CSE는 호스팅 CSE에 등록되고 위치 정보를 가지는 노드 중에서 발신자로부터 가장 가까운 노드를 찾을 수 있다. 가장 가까운 노드는 수집된 토폴로지 정보를 기반으로 최소 홉 개수에 의해 결정될 수 있다. 호스팅 CSE가 가장 가까운 노드(closest node)를 찾을 수 있는 경우, 가장 가까운 노드의 위치 정보가 발신자의 위치 정보로서 저장될 수 있다. 만일 호스팅 CSE가 가장 가까운 노드를 찾을 수 없는 경우, 호스팅 CSE의 위치 정보가 발신자의 위치 정보로서 저장될 수 있다. 이 경우, 위치 정보는 <container> 자원 아래에 <contentInstance> 자원에 저장될 수 있다.
- 호스팅 CSE는 응답을 수신하고 이를 발신자로 보낼 응답 메시지로 변환할 수 있다. 위치 측정 절차가 실패한 경우 호스팅 CSE는 <locationPolicy> 자원의 locationStatus 속성에 있는 에러 코드를 기반으로 statusCode를 저장할 수 있다. 위치 측정 절차가 성공하여 호스팅 CSE가 위치 정보를 획득한 경우, 호스팅 CSE는 <container> 자원 아래에 <contentInstance> 자원에 획득한 위치 정보를 저장할 수 있다.
이하에서는, 공유 기반 방식에 따라 M2M 영역 네트워크(게이트웨이에 연결된 실제 기저 네트워크)의 네트워크 토폴로지 정보를 기반으로 단말의 위치를 더욱 정교하게 판단하는 방법을 설명한다.
MN(호스팅 CSE)가 MN 내부의 기저 네트워크의 토폴로지 정보를 가지고 있는 경우 MN은 MN에 연결된 노드들과 그들의 물리적 관계(또는 토폴로지 정보)를 알고 있다. 따라서, 제한적인 M2M 디바이스(ADN) 또는 다른 애플리케이션이 <locationPolicy> 자원의 생성을 요청하고 locationSource 속성을 공유 기반(Sharing-based)으로 설정하였다면, MN은 이 요청에 따라 MN이 가지고 있는 토폴로지 정보(예, <networkTopoloy> 자원)를 기반으로 위치 정보를 가지고 있는 가장 가까운 노드(Closest Node)를 찾고, 찾아진 노드의 위치를 요청한 상기 ADN의 위치로 설정할 수 있다. 어느 특정 노드가 위치 정보를 가지고 있는지 여부는 MN이 보유한 자원의 정보를 기반으로 MN이 판단할 수 있다.
공유 기반 방식에서, 가장 가까운 노드(Closest Node)는 발신자로부터 최소 홉 개수를 가지는 노드로 결정될 수 있다. 트리 구조의 네트워크에서 신규 노드가 기존 네트워크에 있는 노드에 연결(attach)할 때 다수의 노드 중에서 근접하거나 능력(Capability)이 높은 안정적인 노드에 붙는 것이 바람직할 수 있다. 예를 들어, 신규 노드는 RSS(Received Signal Strength)가 높은 노드에 연결되는 것이 바람직하다. 따라서, 네트워크 토폴로지 정보는 노드간의 근접성을 나타내는 지표로 바람직할 수 있다. 따라서, 물리 네트워크의 토폴로지 정보를 기반으로 최소 홉 개수를 가지는 노드가 가장 가까운 노드로 결정되는 것이 바람직하다.
도 13의 예를 다시 참조하면, ADN_5는 물리적으로 ADN_4의 자식 노드로서 등록되며, ADN_5가 공유 기반 방식으로 위치 정보를 요청할 수 있다. 이 경우, MN은 자신이 보유하고 있는 <node> 자원의 네트워크 토폴로지 정보를 기반으로 ADN_5와 최소 홉 개수를 가지는 노드를 찾을 수 있다. ADN_3과 ADN_1이 위치 정보를 가지는 노드라고 가정하면, ADN_5로부터 ADN_3는 3홉, ADN_1은 2홉이다. 따라서, 이 예에서 가장 가까운 노드는 ADN_1로 결정될 수 있다.
최소 홉 개수를 통해 가장 가까운 노드를 찾는 것이 불가능할 수도 있다. 예를 들어, 최소 홉 개수가 동일한 둘 이상의 노드가 존재하는 경우 둘 이상의 노드 중에서 어느 노드를 가장 가까운 노드로 결정해야할지 문제될 수 있다. 이 경우 최소 홉 조건 외에 추가적인 조건이 필요할 수 있다. 본 발명에서는 해당 단말의 위치 정보(해당 위치 정보는 오버레이 영역에서 <container>와 같은 자원에 할당되어 있음)가 가지는 위치 정보 획득 시간을 기준으로 최신 정보를 보유하는 노드를 위치 정보를 공유하는 노드(즉, 가장 가까운 노드)로 선정하도록 한다. 공유 기반 방식으로 획득한 위치 정보는 해당 단말의 정확한 위치 정보가 아니고 위치 정보를 공유하는 단말 역시 이동성을 가질 수 있으므로 최신 위치 정보를 가지는 노드를 선정하는 것이 바람직하다.
도 14는 본 발명에 따른 실시예를 예시한다. 도 14의 예에서 ADN_5가 <locationPolicy> 자원 생성을 요청하며 locationSource 속성을 공유 기반으로 설정했다고 가정한다. 또한, ADN_1과 ADN_3이 위치 정보를 가진다고 가정한다.
도 14를 참조하면, 최소 홉 기준으로 ADN_1과 ADN_3는 ADN_5로부터 동일한 홉 개수를 가진다. 따라서, 가장 가까운 노드를 선정하기 위한 추가적인 기준으로서 위치 정보의 갱신 시점을 판단할 수 있다. 도 14의 예에서, ADN_1은 4800 초 전에 위치 정보를 갱신하였고 ADN_3는 1200 초 전에 위치 정보를 갱신하였다고 가정한다. 따라서, 최신 위치 정보를 가지는 ADN_3가 가장 가까운 노드로 결정될 수 있으며, ADN_3의 위치 정보가 ADN_5의 위치 정보로 공유/설정될 수 있다.
가장 가까운 노드가 결정된 경우, 가장 가까운 노드의 위치 정보를 포함하는 URI를 타겟 단말의 위치 정보가 있는 자원에 링크 정보로서 추가할 수 있거나, 상기 가장 가까운 노드의 위치 정보를 직접 타겟 단말의 위치 정보로 적용할 수 있다. 이와 같이 위치 정보를 업데이트할 때에도 M2M 게이트웨이가 가장 가까운 노드를 찾을 수 없는 경우에는 M2M 게이트웨이의 위치 정보를 타겟 단말의 위치 정보로 설정할 수 있다. 위치 정보 업데이트는 업데이트 동작을 이용하여 수행될 수 있다.
일반적으로 M2M 게이트웨이는 한계 연결 범위를 가지기 때문에 연결되어 있는 단말은 지역적으로 근접성을 가질 수 있다. 예를 들어, 게이트웨이의 연결 범위가 최대 30m 라고 하면, 단말은 기본적으로 게이트웨이의 위치로부터 반경 30m 내부에 포함될 수 밖에 없다. 이 경우, 게이트웨이는 자신의 위치를 위치 서버 또는 애플리케이션을 통해 계산할 수 있다고 가정한다.
게이트웨이의 위치를 단말이 공유해서 사용한다면 상기 언급한 오차 범위를 포함하여 위치 정보를 제공할 수 있으며, 해당 오차 범위를 서비스 계층에서 애플리케이션에 제공한다면, 해당 정보(위치 정보 + 오차 범위)를 기반으로 애플리케이션이 해당 정보를 사용할 것인지 아닌지를 판단할 수 있다. 이는 일반적으로 위치 기반 서비스 어플리케이션(LBS Application)에서 요구하는 위치 정보의 정확도가 서로 다르기 때문에 해당 기능 제공이 가능할 수 있다.
이하에서는 M2M 게이트웨이의 위치를 공유하는 방식을 기술한다. M2M 단말이 위치 정보 획득 기능이 없는 경우 (위치 서버 또는 Application 기반)와 M2M 게이트웨이는 위치 정보 획득하는 기능을 보유하고 있다고 가정한다. 또한, 본 발명에서는 M2M 게이트웨이와 M2M 단말이 서로 같은 영역 네트워크(Area Network)에 있다고 가정하고, 또는 M2M 단말과 M2M 단말간의 위치 정보 전달 시 2 개의 단말도 같은 영역 네트워크(Area Network)에 있다고 가정한다.
1) M2M 게이트웨이가 고정형(Stationary)인 경우
이 경우 M2M 게이트웨이의 위치가 변하지 않기 때문에 M2M 게이트웨이의 위치를 프로비저닝(provision)한다. 프로비저닝(provision)하는 방식은 M2M 게이트웨이의 위치 정보를 명시적으로 보고(explicitly reporting)하는 방식과 M2M 게이트웨이의 위치 정보에 대한 URI를 제공하는 방식을 포함할 수 있다.
명시적 보고 방식의 경우, M2M 게이트웨이는 단말에게 예를 들어 위도(latitude)와 경도(longitude), 또는 3차원(3D) 구성과 같은 형태로 위치 정보를 제공할 수 있다. 또한, 위치 정보와 함께 다음과 같은 부가 속성(Attribute)이 함께 제공될 수 있다.
- 불확실성(Uncertainty): 불확실성(Uncertainty) 정보는 M2M 게이트웨이의 커버리지(Coverage)에 해당할 수 있다. 예를 들어, M2M 단말은 자신의 위치를 M2M 게이트웨이의 위치로 알고 있지만, 불확실성(Uncertainty) 정보를 이용하여 실제로는 M2M 게이트웨이의 커버리지(Coverage) 내(또는 반경) 안에 있다는 것을 알 수 있다.
- 유효 시간 정보: 해당 위치가 유효한(valid) 시간을 지시하는 정보. 해당 시간 이후 M2M 단말은 위치를 파기해야 한다.
- 전송 전력 정보: M2M 게이트웨이가 전송하는 전송 전력 정보. 해당 정보를 통해
M2M 단말은 자체적으로 획득한 M2M 게이트웨이로부터의 RSS(Received Signal Strength)를 기반으로 정교한 계산을 수행할 수 있다.
- 홉 정보: 영역 네트워크가 메쉬(mesh) 형태로 구성된 경우 M2M 게이트웨이가 관리하고 있는 토폴로지 정보를 제공할 수 있다.
2) M2M 게이트웨이가 이동형인 경우
M2M 게이트웨이가 이동형인 경우에는 M2M 게이트웨이의 위치가 바뀔 수 있으므로, M2M 게이트웨이의 위치 정보 URI를 타겟 단말 위치 정보 자원의 URI로 링크를 형성할 수 있다. 이 경우, 상기 타겟 단말의 위치는 M2M 게이트웨이의 위치와 동일하게 된다. 추가적으로 M2M 단말이 해당 M2M 게이트웨이와 연결이 끊어지면, M2M 단말은 해당 위치 정보를 삭제할 수 있다.
예를 들어, <locationPolicy> 자원의 locationSource 속성이 ‘sharing-based’로 설정되고 AE가 MN-CSE와 연결이 끊어지면, M2M 단말은 <locationPolicy> 자원의 삭제를 요청할 수 있다. 이 경우, M2M 단말은 M2M 게이트웨이로 <locationPolicy> 자원의 삭제 요청 메시지를 전송할 수 있다.
수신자(예, M2M 게이트웨이)는 상기 요청 메시지를 수신하는 경우, 발신자(예, 단말)가 <locationPolicy> 자원에 대해 DELETE 권한을 가지는지 여부를 검사할 수 있다. 검사가 성공적인 경우, CSE는 저장소(repository)로부터 자원을 제거하고 적절한 응답을 발신자에게 보낼 수 있다.
가장 가까운 노드 또는 게이트웨이(MN)의 위치 정보가 <container> 자원에 이미 저장되어 있기 때문에, 호스팅 CSE는 자원의 URI를 <container> 자원에 저장할 수 있다.
호스팅 CSE는 locationUpdatePeriod 속성을 검사하여 그 값이 0보단 큰 경우에 정의된 속성들에 따라 절차를 수행하고 그 결과를 <container> 자원에 저장할 수 있다. 하지만, locationUpdatePeriod 속성이 0으로 설정되거나 설정되지 않은 경우, 호스팅 CSE는 <container>가 나중에 회수될 때에만 위치 측정 절차를 수행할 수 있다.
도 15는 본 발명에 따라 M2M 게이트웨이가 위치 측정 절차를 수행하는 예를 예시한다. 도 15의 예에서 M2M 디바이스는 위치 정보가 없는 디바이스이고, 예를 들어 제한적인 M2M 디바이스(ADN)에 해당할 수 있다. 도 15의 예에서, M2M 영역 네트워크에 위치 정보를 가지는 디바이스는 없다고 가정한다. 또한, 도 15의 예에서, M2M 게이트웨이는 반경 30m의 커버리지를 갖는다고 가정한다.
도 15(a)를 참조하면, M2M 디바이스가 M2M 게이트웨이에게 위치 정보를 요청하는 경우, M2M 게이트웨이는 영역 네트워크 내에 위치 정보를 가지는 디바이스가 있는지 판별하고 위치 정보를 가지는 디바이스가 없으므로 자신의 위치 정보를 M2M 디바이스로 전송할 수 있다. 이 경우, 위치 정보는 (위도, 경도)의 조합으로 표시될 수 있으며, 부가적으로 불확실성 속성 정보가 포함될 수 있다. 도 15의 예에서, M2M 게이트웨이의 위치 정보는 (300, 400)으로 표시될 수 있고 커버리지가 30m이므로 위치 정보는 Position = (300, 400), uncertainty = 30으로 설정되어 M2M 디바이스로 전송될 수 있다.
도 15(b)를 참조하면, M2M 디바이스는 Position = (300, 400), uncertainty = 30으로 설정된 위치 정보를 수신한 후, 자신이 M2M 게이트웨이의 위치에 있다고 결정할 수 있다. 하지만, M2M 게이트웨이의 실제 위치는 위치 정보와 차이가 있을 수 있으며, 이러한 차이는 불확실성 정보(uncertainty)를 통해 추정할 수 있다.
도 16은 본 발명에 따른 위치 측정 절차의 흐름을 예시한다. 도 16의 예에서, M2M 디바이스(1610)는 ADN이고 자원 제한적인 노드(resource constrained node)라고 가정한다. 따라서, M2M 디바이스(1610)는 위치 결정 능력(예, GPS)을 갖지 않고 네트워크 기반의 위치 측정 능력(network-based positioning capability)을 갖지 않는다고 가정한다. M2M 게이트웨이(1620)는 MN으로서 호스팅 CSE를 포함한다고 가정한다. 또한, M2M 디바이스(1630)는 적어도 하나의 ASN 또는 ADN을 포함한다고 가정한다.
도 16을 참조하면, M2M 게이트웨이(1620)는 <locationPolicy> 자원 기반으로 위치 정보 획득 방식을 제공하는 방안과 관련하여 설명된 호스팅 CSE의 동작을 수행할 수 있다. M2M 디바이스(1610)는 위치 정보 요청의 발신자로서 동작할 수 있다.
S1602 단계에서, M2M 게이트웨이(1620)는 위치 획득 절차를 수행하고 M2M 디바이스(1630)의 위치 정보를 획득할 수 있다. M2M 게이트웨이(1620)는 M2M 디바이스(1630)의 위치 정보를 <container> 자원에 저장할 수 있다. <container> 자원은 도 11에 예시된 구조를 가질 수 있고 표 2에 예시된 속성을 가질 수 있다.
S1604 단계에서, M2M 디바이스(1610)는 위치 정보를 획득하는 방식을 나타내는 <locationPolicy> 자원의 생성 요청을 M2M 게이트웨이(1620)로 전송할 수 있다. 상기 생성 요청은 공유 기반 위치 측정을 지시하는 정보(예, 공유 기반으로 설정된 locationSource 속성)을 포함할 수 있다.
S1606 단계에서, M2M 게이트웨이(1620)는 <locationPolicy> 자원을 생성할 수 있다. <locationPolicy> 자원은 도 10에 예시된 구조를 가질 수 있고 표 1에 예시된 속성들 중 적어도 하나를 포함할 수 있다.
S1608 단계에서, M2M 게이트웨이(1620)는 <node> 자원과 그 자식 자원을 생성할 수 있다. <node> 자원은 도 12에 예시된 구조를 가질 수 있고 표 3에 예시된 자원들 중 적어도 하나를 포함할 수 있다.
S1610 단계에서, M2M 게이트웨이(1620)는 네트워크 토폴로지 정보를 구성할 수 있다. M2M 게이트웨이(1620)는 M2M 게이트웨이(1620)에 연결된 M2M 디바이스들의 리스트를 획득하고 M2M 영역 네트워크에서 M2M 디바이스들 간의 물리적 연결 또는 기저 연결에 관한 정보를 획득할 수 있다. 네트워크 토폴로지 정보는 M2M 게이트웨이(1620)에 연결된 M2M 디바이스들의 리스트와 M2M 영역 네트워크에서 M2M 디바이스들 간의 물리적 연결(또는 물리적 연결 관계)을 나타낼 수 있다. S1608 단계 및/또는 S1610 단계는 S1604 단계 전에 수행될 수도 있다. 네트워크 토폴로지 정보는 S1608 단계에서 생성된 <node> 자원에 저장될 수 있다.
S1612 단계에서, M2M 게이트웨이(1620)는 토폴로지 정보와 위치 정보를 기반으로 M2M 디바이스(1610)로부터 가장 가까운 M2M 디바이스를 찾을 수 있다.
만일 M2M 게이트웨이(1620)가 토폴로지 정보를 가지지 않거나 가장 가까운 M2M 디바이스를 찾을 수 없는 경우, M2M 게이트웨이(1620)의 위치 정보가 M2M 디바이스(1610)의 위치 정보로서 저장될 수 있다. 이 경우, M2M 게이트웨이(1620)는 자신의 위치 정보를 M2M 디바이스(1610)의 위치 정보로 저장할 수 있다.
반면, M2M 게이트웨이(1620)가 토폴로지 정보를 가지고 토폴로지 정보를 기반으로 위치 정보를 가지는 디바이스 중에서 M2M 디바이스(1610)로부터 최소 홉 개수를 가지는 디바이스를 찾을 수 있는 경우, 최소 홉 개수를 가지는 디바이스가 가장 가까운 디바이스로 결정될 수 있다. 이 경우, M2M 게이트웨이(1620)는 가장 가까운 디바이스로 결정된 M2M 디바이스의 위치 정보를 M2M 디바이스(1610)의 위치 정보로 저장할 수 있다. 또한, 동일한 최소 홉 개수를 가지는 복수의 디바이스가 결정된 경우 최신 위치 정보를 가지는 디바이스가 가장 가까운 디바이스로 결정될 수 있다.
도 16의 예는 오로지 예시적인 것이며, 구현예에 따라 일부 단계는 생략될 수 있고 또는 추가적인 단계가 부가될 수 있다. 또한, 본 명세서에서 제안된 실시예들은 결합되어 새로운 실시예를 형성할 수 있고 실시예들 중에서 일부 구성만이 결합되어 새로운 실시예를 형성할 수 있다.
도 17은 본 발명이 적용될 수 있는 장치의 블록도를 예시한다. 본 발명에 있어서, M2M 게이트웨이, M2M 서버 또는 M2M 디바이스는 각각 전송장치(10) 또는 수신장치(20)로 동작할 수 있다.
전송장치(10)와 수신장치(20)는 정보 및/또는 데이터, 신호, 메시지 등을 나르는 무선 신호를 전송 또는 수신할 수 있는 RF(Radio Frequency) 유닛(13, 23)과, 무선통신 시스템 내 통신과 관련된 각종 정보를 저장하는 메모리(12, 22), 상기 RF 유닛(13, 23) 및 메모리(12, 22)등의 구성요소와 동작시 연결(operatively connected)되고, 상기 구성요소를 제어하여 해당 장치가 전술한 본 발명의 실시예들 중 적어도 하나를 수행하도록 메모리(12, 22) 및/또는 RF 유닛(13,23)을 제어하도록 구성된 프로세서(11, 21)를 각각 포함한다.
메모리(12, 22)는 프로세서(11, 21)의 처리 및 제어를 위한 프로그램을 저장할 수 있고, 입/출력되는 정보를 저장할 수 있다. 메모리(12, 22)가 버퍼로서 활용될 수 있다. 또한, 메모리(12, 22)는 각종 설정 정보와 데이터를 포함하는 리소스를 저장하는 데 사용될 수 있다.
프로세서(11, 21)는 통상적으로 전송장치 또는 수신장치 내 각종 모듈의 전반적인 동작을 제어한다. 특히, 프로세서(11, 21)는 본 발명을 수행하기 위한 각종 제어 기능을 수행할 수 있다. 프로세서(11, 21)는 컨트롤러(controller), 마이크로 컨트롤러(microcontroller), 마이크로 프로세서(microprocessor), 마이크로 컴퓨터(microcomputer) 등으로도 불릴 수 있다. 프로세서(11, 21)는 하드웨어(hardware) 또는 펌웨어(firmware), 소프트웨어, 또는 이들의 결합에 의해 구현될 수 있다. 하드웨어를 이용하여 본 발명을 구현하는 경우에는, 본 발명을 수행하도록 구성된 ASICs(application specific integrated circuits) 또는 DSPs(digital signal processors), DSPDs(digital signal processing devices), PLDs(programmable logic devices), FPGAs(field programmable gate arrays) 등이 프로세서(11, 21)에 구비될 수 있다. 한편, 펌웨어나 소프트웨어를 이용하여 본 발명을 구현하는 경우에는 본 발명의 기능 또는 동작들을 수행하는 모듈, 절차 또는 함수 등을 포함하도록 펌웨어나 소프트웨어가 구성될 수 있으며, 본 발명을 수행할 수 있도록 구성된 펌웨어 또는 소프트웨어는 프로세서(11, 21) 내에 구비되거나 메모리(12, 22)에 저장되어 프로세서(11, 21)에 의해 구동될 수 있다.
전송장치(10)의 프로세서(11)는 상기 프로세서(11) 또는 상기 프로세서(11)와 연결된 스케줄러로부터 스케줄링되어 외부로 전송될 신호 및/또는 데이터에 대하여 소정의 부호화(coding) 및 변조(modulation)를 수행한 후 RF 유닛(13)에 전송한다. 수신장치(20)의 신호 처리 과정은 전송장치(10)의 신호 처리 과정의 역으로 구성된다. 프로세서(21)의 제어 하에, 수신장치(20)의 RF 유닛(23)은 전송장치(10)에 의해 전송된 무선 신호를 수신한다. 상기 프로세서(21)는 수신 안테나를 통하여 수신된 무선 신호에 대한 복호(decoding) 및 복조(demodulation)를 수행하여, 전송장치(10)가 본래 전송하고자 했던 데이터를 복원할 수 있다.
RF 유닛(13, 23)은 하나 이상의 안테나를 구비한다. 안테나는, 프로세서(11, 21)의 제어 하에 본 발명의 일 실시예에 따라, RF 유닛(13, 23)에 의해 처리된 신호를 외부로 전송하거나, 외부로부터 무선 신호를 수신하여 RF 유닛(13, 23)으로 전달하는 기능을 수행한다. 도 14에서 송신장치와 수신장치가 각각 RF 유닛을 통해 통신하는 것으로 도시되어 있지만 송신장치와 수신장치가 유선 네트워크를 통해 통신하는 것도 가능하다. 이 경우, RF 유닛은 네트워크 인터페이스 유닛(network interface unit, NIU)으로 대체될 수 있다.
이상에서 설명된 실시예들은 본 발명의 구성요소들과 특징들이 소정 형태로 결합된 것들이다. 각 구성요소 또는 특징은 별도의 명시적 언급이 없는 한 선택적인 것으로 고려되어야 한다. 각 구성요소 또는 특징은 다른 구성요소나 특징과 결합되지 않은 형태로 실시될 수 있다. 또한, 일부 구성요소들 및/또는 특징들을 결합하여 본 발명의 실시예를 구성하는 것도 가능하다. 본 발명의 실시예들에서 설명되는 동작들의 순서는 변경될 수 있다. 어느 실시예의 일부 구성이나 특징은 다른 실시예에 포함될 수 있고, 또는 다른 실시예의 대응하는 구성 또는 특징과 교체될 수 있다. 특허청구범위에서 명시적인 인용 관계가 있지 않은 청구항들을 결합하여 실시예를 구성하거나 출원 후의 보정에 의해 새로운 청구항으로 포함시킬 수 있음은 자명하다.
본 문서에서 기지국에 의해 수행된다고 설명된 특정 동작은 경우에 따라서는 그 상위 노드(upper node)에 의해 수행될 수 있다. 즉, 기지국을 포함하는 복수의 네트워크 노드들(network nodes)로 이루어지는 네트워크에서 단말과의 통신을 위해 수행되는 다양한 동작들은 기지국 또는 기지국 이외의 다른 네트워크 노드들에 의해 수행될 수 있음은 자명하다. 기지국은 고정국(fixed station), Node B, eNode B(eNB), 액세스 포인트(access point) 등의 용어에 의해 대체될 수 있다. 또한, 단말은 UE(User Equipment), MS(Mobile Station), MSS(Mobile Subscriber Station) 등의 용어로 대체될 수 있다.
본 발명에 따른 실시예는 다양한 수단, 예를 들어, 하드웨어, 펌웨어(firmware), 소프트웨어 또는 그것들의 결합 등에 의해 구현될 수 있다. 하드웨어에 의한 구현의 경우, 본 발명의 일 실시예는 하나 또는 그 이상의 ASICs(application specific integrated circuits), DSPs(digital signal processors), DSPDs(digital signal processing devices), PLDs(programmable logic devices), FPGAs(field programmable gate arrays), 프로세서, 콘트롤러, 마이크로 콘트롤러, 마이크로 프로세서 등에 의해 구현될 수 있다.
펌웨어나 소프트웨어에 의한 구현의 경우, 본 발명은 이상에서 설명된 기능 또는 동작들을 수행하는 모듈, 절차, 함수 등의 형태를 포함하는 소프트웨어 코드 또는 명령어(instruction)로 구현될 수 있다. 소프트웨어 코드 또는 명령어는 컴퓨터 판독가능한 매체에 저장되어 프로세서에 의해 구동될 수 있으며 프로세서에 의해 구동될 때 본 발명에 따른 동작들을 수행할 수 있다. 상기 컴퓨터 판독가능한 매체는 상기 프로세서 내부 또는 외부에 위치하거나 원격으로 네트워크를 통해 상기 프로세서와 연결될 수 있으며, 상기 프로세서와 데이터를 주고 받을 수 있다.
본 발명은 본 발명의 특징을 벗어나지 않는 범위에서 다른 특정한 형태로 구체화될 수 있음은 당업자에게 자명하다. 따라서, 상기의 상세한 설명은 모든 면에서 제한적으로 해석되어서는 아니되고 예시적인 것으로 고려되어야 한다. 본 발명의 범위는 첨부된 청구항의 합리적 해석에 의해 결정되어야 하고, 본 발명의 등가적 범위 내에서의 모든 변경은 본 발명의 범위에 포함된다.
본 발명은 단말, 서버, 게이트웨이 등과 같은 통신 장치에 사용될 수 있다.

Claims (10)

  1. M2M(Machine-to-Machine) 게이트웨이가 M2M 디바이스의 위치 측정을 수행하는 방법으로서,
    위치 정보를 획득하는 방식을 나타내는 제1 자원의 생성 요청을 제1 M2M 디바이스로부터 수신하는 단계;
    상기 생성 요청이 공유 기반 위치 측정을 지시하는 정보를 포함하는 경우, 상기 제1 M2M 디바이스로부터 가장 가까운 디바이스를 결정하는 단계; 및
    상기 가장 가까운 디바이스의 위치 정보를 상기 제1 M2M 디바이스를 위한 위치 정보로서 설정하는 단계를 포함하되,
    상기 M2M 게이트웨이가 네트워크 토폴로지 정보를 갖지 않거나 상기 M2M 게이트웨이에 연결된 적어도 하나의 M2M 디바이스가 위치 정보를 갖지 않는 경우, 상기 M2M 게이트웨이가 상기 가장 가까운 디바이스로서 결정되고,
    상기 M2M 게이트웨이가 네트워크 토폴로지 정보를 가지고 상기 M2M 게이트웨이에 연결된 상기 적어도 하나의 M2M 디바이스가 위치 정보를 가지는 경우, 상기 적어도 하나의 M2M 디바이스 중에서 상기 제1 M2M 디바이스로부터 최소 홉 개수를 가지는 디바이스가 상기 가장 가까운 디바이스로서 결정되며,
    상기 제1 자원은 주소 정보를 이용하여 고유하게 어드레싱 가능한 데이터 구조를 나타내는, 방법.
  2. 제1항에 있어서,
    상기 최소 홉 개수를 가지는 디바이스가 둘 이상 존재하는 경우, 가장 최신 위치 정보를 가지는 디바이스가 상기 제1 M2M 디바이스로부터 가장 가까운 디바이스로서 결정되는, 방법.
  3. 제1항에 있어서,
    상기 위치 정보를 설정하는 단계는 상기 제1 M2M 디바이스로부터 가장 가까운 디바이스의 위치 정보를 상기 제1 M2M 디바이스의 위치 정보 저장을 위한 제2 자원에 저장하는 것을 포함하는, 방법.
  4. 제1항에 있어서,
    상기 네트워크 토폴로지 정보는 상기 M2M 게이트웨이에 연결된 M2M 디바이스들의 리스트와 상기 M2M 게이트웨이에 연결된 M2M 디바이스들 간의 물리적 연결을 나타내는, 방법.
  5. 제1항에 있어서,
    상기 제1 M2M 디바이스는 위치 결정 능력(positioning determination capability)을 갖지 않고 네트워크 기반의 위치 측정 능력(network-based positioning capability)을 갖지 않는 디바이스인, 방법.
  6. M2M(Machine-to-Machine) 디바이스의 위치 측정을 수행하는 M2M 게이트웨이에 있어서,
    네트워크 인터페이스 유닛; 및
    프로세서를 포함하되, 상기 프로세서는
    상기 네트워크 인터페이스 유닛을 제어하여 위치 정보 획득 방식을 나타내는 제1 자원의 생성 요청을 제1 M2M 디바이스로부터 수신하고,
    상기 생성 요청이 공유 기반 위치 측정을 지시하는 정보를 포함하는 경우, 상기 제1 M2M 디바이스로부터 가장 가까운 디바이스를 결정하고,
    상기 가장 가까운 디바이스의 위치 정보를 상기 제1 M2M 디바이스를 위한 위치 정보로서 설정하도록 구성되며,
    상기 M2M 게이트웨이가 네트워크 토폴로지 정보를 갖지 않거나 상기 M2M 게이트웨이에 연결된 적어도 하나의 M2M 디바이스가 위치 정보를 갖지 않는 경우, 상기 M2M 게이트웨이가 상기 가장 가까운 디바이스로서 결정되고,
    상기 M2M 게이트웨이가 네트워크 토폴로지 정보를 가지고 상기 M2M 게이트웨이에 연결된 상기 적어도 하나의 M2M 디바이스가 위치 정보를 가지는 경우, 상기 적어도 하나의 M2M 디바이스 중에서 상기 제1 M2M 디바이스로부터 최소 홉 개수를 가지는 디바이스가 상기 가장 가까운 디바이스로서 결정되며,
    상기 제1 자원은 주소 정보를 이용하여 고유하게 어드레싱 가능한 데이터 구조를 나타내는, M2M 게이트웨이.
  7. 제6항에 있어서,
    상기 최소 홉 개수를 가지는 디바이스가 둘 이상 존재하는 경우, 가장 최신 위치 정보를 가지는 디바이스가 상기 제1 M2M 디바이스로부터 가장 가까운 디바이스로서 결정되는, M2M 게이트웨이.
  8. 제6항에 있어서,
    상기 위치 정보를 설정하는 것은 상기 제1 M2M 디바이스로부터 가장 가까운 디바이스의 위치 정보를 상기 제1 M2M 디바이스의 위치 정보 저장을 위한 제2 자원에 저장하는 것을 포함하는, M2M 게이트웨이.
  9. 제6항에 있어서,
    상기 네트워크 토폴로지 정보는 상기 M2M 게이트웨이에 연결된 M2M 디바이스들의 리스트와 상기 M2M 게이트웨이에 연결된 M2M 디바이스들 간의 물리적 연결을 나타내는, M2M 게이트웨이.
  10. 제6항에 있어서,
    상기 제1 M2M 디바이스는 위치 결정 능력(positioning determination capability)을 갖지 않고 네트워크 기반의 위치 측정 능력(network-based positioning capability)을 갖지 않는 디바이스인, M2M 게이트웨이.
PCT/KR2014/005179 2013-06-12 2014-06-12 M2m 시스템에서 위치 측정 방법 및 이를 위한 장치 WO2014200292A1 (ko)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US14/893,871 US9392571B2 (en) 2013-06-12 2014-06-12 Method for measuring position in M2M system and apparatus therefor
KR1020157032916A KR101689614B1 (ko) 2013-06-12 2014-06-12 M2m 시스템에서 위치 측정 방법 및 이를 위한 장치

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US201361833937P 2013-06-12 2013-06-12
US61/833,937 2013-06-12
US201361900406P 2013-11-06 2013-11-06
US61/900,406 2013-11-06
US201461926399P 2014-01-13 2014-01-13
US61/926,399 2014-01-13

Publications (1)

Publication Number Publication Date
WO2014200292A1 true WO2014200292A1 (ko) 2014-12-18

Family

ID=52022506

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2014/005179 WO2014200292A1 (ko) 2013-06-12 2014-06-12 M2m 시스템에서 위치 측정 방법 및 이를 위한 장치

Country Status (3)

Country Link
US (1) US9392571B2 (ko)
KR (1) KR101689614B1 (ko)
WO (1) WO2014200292A1 (ko)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016144085A1 (ko) * 2015-03-09 2016-09-15 엘지전자 주식회사 무선랜 시스템에서 nan 단말의 위치 측위 방법 및 이를 이용한 기기
CN106211037A (zh) * 2016-06-30 2016-12-07 海尔优家智能科技（北京）有限公司 删除资源、更新宣告资源标识属性的方法及cse设备
WO2017175954A1 (ko) * 2016-04-05 2017-10-12 엘지전자 주식회사 무선 통신 시스템에서 다중 자원에 대한 구독을 처리하기 위한 방법 및 이를 위한 장치

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3062231A4 (en) * 2013-10-23 2017-07-26 Nec Corporation Communication system, shared service control unit, data transmission method, and non-transitory computer-readable medium
CN104618312B (zh) * 2013-11-04 2019-03-29 中兴通讯股份有限公司 一种m2m应用的远程注册方法、装置和系统
CN104796922B (zh) * 2014-01-22 2019-07-09 中兴通讯股份有限公司 Cse的触发管理方法及装置、cse、承载网网元
JPWO2015119003A1 (ja) * 2014-02-04 2017-03-23 株式会社Ｎｔｔドコモ サービス制御システム、ユーザ装置、及びサービス制御方法
CN105100002B (zh) * 2014-05-05 2019-05-07 中兴通讯股份有限公司 属性的操作方法及装置
CN113691949A (zh) * 2014-10-28 2021-11-23 康维达无线有限责任公司 用于与底层网络的服务层计费关联的方法和设备
WO2016114842A1 (en) * 2014-10-31 2016-07-21 Convida Wireless, Llc End-to-end service layer authentication
KR20210131436A (ko) * 2014-11-14 2021-11-02 콘비다 와이어리스, 엘엘씨 허가 기반 리소스 및 서비스 발견
WO2016100631A1 (en) * 2014-12-17 2016-06-23 Convida Wireless, Llc Methods for enabling delay-awareness in the constrained application protocol (coap)
EP3272094B1 (en) 2015-03-16 2021-06-23 Convida Wireless, LLC End-to-end authentication at the service layer using public keying mechanisms
CN106302840A (zh) * 2015-05-15 2017-01-04 中兴通讯股份有限公司 位置数据处理方法、装置及系统
WO2017195964A1 (ko) * 2016-05-11 2017-11-16 엘지전자 주식회사 무선 통신 시스템에서 콜렉션 패턴을 적용한 어드레싱 방법 및 이를 위한 장치
US10270815B1 (en) * 2016-06-07 2019-04-23 Amazon Technologies, Inc. Enabling communications between a controlling device and a network-controlled device via a network-connected device service over a mobile communications network
CN107484211B (zh) * 2016-06-08 2020-06-26 华为技术有限公司 切换接入点的方法及装置
CN109819006B (zh) * 2017-11-22 2022-08-09 京东方科技集团股份有限公司 对目标资源进行操作的方法、节点设备和终端装置
CN112602339A (zh) * 2018-07-03 2021-04-02 瑞典爱立信有限公司 用于处置定位信息的第一节点、通信装置以及由其执行的方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20010048746A1 (en) * 2000-05-25 2001-12-06 U. S. Philips Corporation Method of estimating the location of a device
KR20080034152A (ko) * 2005-07-07 2008-04-18 퀄컴 인코포레이티드 무선 원거리 네트워크, 무선 근거리 네트워크, 및 무선사설 네트워크에서 위치 결정 및 위치-기반 서비스를 위한방법 및 장치
US20090160711A1 (en) * 2007-12-24 2009-06-25 Chand Mehta Methods, systems and apparatus for integrated wireless device location determination
KR101026286B1 (ko) * 2002-07-15 2011-03-31 콸콤 인코포레이티드 제 2 이동 장치로부터의 정보를 사용하여 제 1 이동장치의 위치를 결정하는 방법 및 장치
KR101062635B1 (ko) * 2006-04-26 2011-09-06 퀄컴 인코포레이티드 무선 위치 측정 장치 및 방법

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008040083A1 (en) * 2006-10-05 2008-04-10 Waratek Pty Limited Adding one or more computers to a multiple computer system
US20100137021A1 (en) * 2008-11-28 2010-06-03 Eric Sharret System, Method and Devices for Communications via a Mesh Network
US8903930B2 (en) * 2010-04-07 2014-12-02 Lg Electronics Inc. Group-based M2M communication method
CN102142980B (zh) * 2010-10-27 2014-05-07 华为技术有限公司 远程管理传感网络拓扑的方法及网关
KR20120047683A (ko) * 2010-11-04 2012-05-14 삼성전자주식회사 기기간통신 시스템에서 위치정보를 지원하기 위한 방법 및 장치
CN102130773B (zh) * 2011-02-25 2012-12-19 华为技术有限公司 群组通信的方法和用于群组通信的装置
CN102137105B (zh) * 2011-03-11 2012-11-07 华为技术有限公司 机器通信的私密性保护方法、系统和机器通信业务管理实体及相关设备
KR101533864B1 (ko) * 2011-05-13 2015-07-03 주식회사 케이티 Ｍ2ｍ 통신에서 네트워크를 선택하는 방법 및 장치

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20010048746A1 (en) * 2000-05-25 2001-12-06 U. S. Philips Corporation Method of estimating the location of a device
KR101026286B1 (ko) * 2002-07-15 2011-03-31 콸콤 인코포레이티드 제 2 이동 장치로부터의 정보를 사용하여 제 1 이동장치의 위치를 결정하는 방법 및 장치
KR20080034152A (ko) * 2005-07-07 2008-04-18 퀄컴 인코포레이티드 무선 원거리 네트워크, 무선 근거리 네트워크, 및 무선사설 네트워크에서 위치 결정 및 위치-기반 서비스를 위한방법 및 장치
KR101062635B1 (ko) * 2006-04-26 2011-09-06 퀄컴 인코포레이티드 무선 위치 측정 장치 및 방법
US20090160711A1 (en) * 2007-12-24 2009-06-25 Chand Mehta Methods, systems and apparatus for integrated wireless device location determination

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016144085A1 (ko) * 2015-03-09 2016-09-15 엘지전자 주식회사 무선랜 시스템에서 nan 단말의 위치 측위 방법 및 이를 이용한 기기
US9949070B2 (en) 2015-03-09 2018-04-17 Lg Electronics Inc. Method for positioning NAN terminal in wireless LAN system, and device using same
WO2017175954A1 (ko) * 2016-04-05 2017-10-12 엘지전자 주식회사 무선 통신 시스템에서 다중 자원에 대한 구독을 처리하기 위한 방법 및 이를 위한 장치
CN106211037A (zh) * 2016-06-30 2016-12-07 海尔优家智能科技（北京）有限公司 删除资源、更新宣告资源标识属性的方法及cse设备
CN106211037B (zh) * 2016-06-30 2019-06-04 海尔优家智能科技（北京）有限公司 删除资源、更新宣告资源标识属性的方法及cse设备

Also Published As

Publication number Publication date
KR20160018489A (ko) 2016-02-17
US9392571B2 (en) 2016-07-12
US20160112981A1 (en) 2016-04-21
KR101689614B1 (ko) 2016-12-26

Similar Documents

Publication Publication Date Title
WO2014200292A1 (ko) M2m 시스템에서 위치 측정 방법 및 이를 위한 장치
WO2014185754A1 (ko) M2m 통신 시스템에서 구독 및 통지를 위한 방법 및 이를 위한 장치
WO2015046961A1 (ko) M2m 시스템에서 통지 메시지 전달 방법 및 이를 위한 장치
WO2014129802A1 (ko) M2m 서비스 설정 변경 방법 및 이를 위한 장치
WO2020197288A1 (ko) Edge computing 서비스를 이용하기 위하여 단말에 연결성을 제공하는 방법 및 장치
WO2020036401A1 (ko) 무선 통신 시스템에서 네트워크에 등록하기 위한 장치 및 방법
WO2020204474A1 (ko) 무선 통신 시스템에서 에지 컴퓨팅 서비스를 제공하기 위한 장치 및 방법
WO2018199649A1 (en) Method and apparatus for registration type addition for service negotiation
WO2015069038A1 (ko) M2m 통신 시스템에서 구독 및 통지를 위한 방법 및 이를 위한 장치
WO2021157963A1 (en) Method and apparatus for providing edge computing services
WO2016167536A1 (en) Method and apparatus for managing a profile of a terminal in a wireless communication system
WO2017052136A1 (ko) 이동 통신 시스템에서 프로파일 다운로드 방법 및 장치
WO2021054747A1 (ko) 무선 통신 시스템에서 psa-upf 재배치를 위한 장치 및 방법
WO2021049782A1 (en) Method and apparatus for providing policy of user equipment in wireless communication system
WO2021091232A1 (ko) 이동통신 시스템에서 어플리케이션 서버의 정보 제공 장치 및 방법
WO2020231120A1 (ko) 에지 컴퓨팅 서비스에서 단말의 식별자 관리 방법 및 장치
WO2014109597A1 (ko) M2m(machine-to-machine)시스템에서 게이트웨이 변경 방법 및 이를 위한 장치
EP3284274A1 (en) Method and apparatus for managing a profile of a terminal in a wireless communication system
WO2021091307A1 (ko) 무선 통신 시스템에서 mbs 서비스 제공에 대한 mbs 서비스 세션의 설정을 위한 장치 및 방법
EP3574693A1 (en) Method and apparatus for registration type addition for service negotiation
WO2021167277A1 (ko) 에지 컴퓨팅 시스템에서 무선 통신 네트워크 타입에 따른 서비스 제공 장치 및 방법
WO2021141440A1 (ko) 무선 통신 시스템에서 엣지 컴퓨팅 서비스를 지원하기 위한 장치 및 방법
WO2016195199A1 (ko) 무선 통신 시스템에서 폴링 채널을 통해 요청을 처리하기 위한 방법 및 이를 위한 장치
WO2021141291A1 (ko) 무선 통신 시스템에서 네트워크 트래픽을 수집하는 방법 및 장치
WO2016013846A1 (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: 14811448

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 20157032916

Country of ref document: KR

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 14893871

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: 14811448

Country of ref document: EP

Kind code of ref document: A1