KR102145741B1

KR102145741B1 - 무선 통신 시스템에서 접근 제어를 위한 방법 및 장치

Info

Publication number: KR102145741B1
Application number: KR1020157015601A
Authority: KR
Inventors: 김성윤; 박승규
Original assignee: 엘지전자 주식회사
Priority date: 2013-01-18
Filing date: 2014-01-15
Publication date: 2020-08-19
Also published as: US9900727B2; WO2014112781A1; EP2950497A1; JP2016507823A; JP6055111B2; EP2950497A4; CN104937895A; KR20150107720A; CN104937895B; EP2950497B1; US20150358824A1

Abstract

본 발명의 일 실시예에 따른 무선 통신 시스템에서 서버 계정 삭제에 따른 상기 서버와 연관된 특정 객체 인스턴스의 처리 방법에 있어서, 상기 방법은 상기 단말에 의해 수행되며, 제 1 서버로부터 특정 서버의 계정을 삭제하기 위한 동작 명령을 수신하는 단계; 및 상기 특정 객체 인스턴스가 상기 특정 서버만이 접근할 수 있는 객체 인스턴스이면, 상기 특정 객체 인스턴스 및 그와 연관된 접근 제어 객체 인스턴스를 삭제하는 단계를 포함하고, 상기 특정 객체 인스턴스가 상기 특정 서버를 포함한 복수의 서버들이 접근할 수 있는 객체 인스턴스이면, 상기 특정 객체 인스턴스와 연관된 접근 제어 객체 인스턴스 내에서 상기 특정 서버의 접근 권한 정보를 삭제하는 단계; 및 상기 특정 서버가 상기 접근 제어 객체 인스턴스의 유일한 접근 제어 소유자이면, 상기 특정 서버를 제외한 상기 복수의 서버들 중 각각이 갖는 접근 권한에 부여된 값의 합이 가장 큰 서버를 상기 접근 제어 소유자로 변경하는 단계를 포함할 수 있다.

Description

무선 통신 시스템에서 접근 제어를 위한 방법 및 장치{METHOD AND APPARATUS FOR CONTROLLING ACCESS IN WIRELESS COMMUNICATION SYSTEM}

본 발명은 무선 통신 시스템에서 접근 제어를 위한 방법 및 이를 위한 장치에 관한 것이다.

유비쿼터스 시대에 접어들면서 M2M(Machine to Machine) 통신 기술이 각광받고 있다. M2M 기술은 e-Health, smart grid, smart home 등의 여러 응용 분야에 사용될 수 있다. 이러한 응용 분야에서는 다양한 하드웨어 제원을 가진 M2M 기기들이 다루어지다 보니, M2M 기기 모두를 포용할 수 있는 프로토콜이 필요하다. 이에 자원 제약적인 M2M 기기에 맞는 어플리케이션 계층(application layer) 프로토콜 개발이 필요하게 되었고, 이러한 프로토콜은 자원 제약적인 M2M 기기에 적용 가능하기에 타 제원을 가진 M2M 기기에는 충분히 적용이 가능하다.

한편, M2M 기기에도 접근 제어를 위한 기술이 요구되며, 특히 M2M 클라이언트에 등록된 M2M 서버 계정이 삭제되는 경우에 그에 대한 처리와 삭제될 M2M 서버와 연관된 리소스에 대한 처리가 필요하다. 상기 M2M 서버 계정 삭제에 따라 특정 리소스가 접근 권한이 존재하지 않는 리소스가 될 수 있고, 또는 M2M 클라이언트 내 리소스의 접근 권한을 관리하는 M2M 서버가 없어지는 상황이 발생할 수 있어 이에 대한 솔루션이 필요하다.

본 발명은 접근 제어를 위한 방안을 제안하고자 한다.

좀더 구체적으로는, 본 발명의 일 실시예는 특정 서버 계정의 삭제되는 경우에 그와 관련된 리소스들에 대한 처리 방안을 제안하고자 한다.

또한, 본 발명은 통지에 대한 인증 방안을 제안하고자 한다.

또한, 본 발명은 단말의 접속 모드 설정을 위한 방안을 제안하고자 한다.

본 발명이 이루고자 하는 기술적 과제들은 이상에서 언급한 기술적 과제들로 제한되지 않으며, 언급되지 않은 또 다른 기술적 과제들은 이하의 발명의 상세한 설명으로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.

바람직하게는, 상기 값의 합이 가장 큰 서버가 둘 이상이면, 상기 방법은 상기 둘 이상의 서버 중 하나를 선택하고, 상기 선택된 서버를 상기 접근 제어 소유자로 변경하는 단계를 포함할 수 있다.

바람직하게는, 상기 특정 서버의 계정을 삭제하기 위한 동작 명령은 부트스트랩 인터페이스를 통해 수신될 수 있다.

바람직하게는, 상기 제 1 서버는 부트스트랩 서버일 수 있다.

바람직하게는, 제 2 서버에 의한 상기 접근 제어 객체 인스턴스의 접근 제어 소유자에 대하여 관찰 동작이 설정되어 있으면, 상기 방법은 상기 접근 제어 소유자가 변경 시에 상기 제 2 서버로 상기 변경에 대한 통지를 전송하는 단계를 더 포함할 수 있다.

바람직하게는, 상기 특정 서버가 전송한 관찰 동작 명령을 통해 저장한 관찰 동작 명령 관련 설정 정보를 삭제하는 단계를 더 포함할 수 있다.

바람직하게는, 상기 특정 서버의 계정은 상기 특정 서버의 짧은 서버 ID 및 상기 특정 서버와의 통신을 위한 보안 키를 포함할 수 있다.

본 발명의 다른 일 실시예에 따른 무선 통신 시스템에서 서버 계정 삭제에 따른 상기 서버와 연관된 특정 객체 인스턴스의 처리하도록 구성된 단말로서, 무선 주파수(radio frequency; RF) 유닛; 및 상기 RF 유닛을 제어하도록 구성된 프로세서를 포함하되, 상기 프로세서는 제 1 서버로부터 특정 서버의 계정을 삭제하기 위한 동작 명령을 수신하고, 상기 특정 객체 인스턴스가 상기 특정 서버만이 접근할 수 있는 객체 인스턴스이면, 상기 특정 객체 인스턴스 및 그와 연관된 접근 제어 객체 인스턴스를 삭제하며, 상기 특정 객체 인스턴스가 상기 특정 서버를 포함한 복수의 서버들이 접근할 수 있는 객체 인스턴스이면, 상기 특정 객체 인스턴스와 연관된 접근 제어 객체 인스턴스 내에서 상기 특정 서버의 접근 권한 정보를 삭제하며, 상기 특정 서버가 상기 접근 제어 객체 인스턴스의 유일한 접근 제어 소유자이면, 상기 특정 서버를 제외한 상기 복수의 서버들 중 각각이 갖는 접근 권한에 부여된 값의 합이 가장 큰 서버를 상기 접근 제어 소유자로 변경하도록 구성될 수 있다.

바람직하게는, 상기 값의 합이 가장 큰 서버가 둘 이상이면, 상기 프로세서는 상기 둘 이상의 서버 중 하나를 선택하고, 상기 선택된 서버를 상기 접근 제어 소유자로 변경하도록 구성될 수 있다.

바람직하게는, 제 2 서버에 의한 상기 접근 제어 객체 인스턴스의 접근 제어 소유자에 대하여 관찰 동작이 설정되어 있으면, 상기 프로세서는 상기 접근 제어 소유자의 변경 시에 상기 제 2 서버로 상기 변경에 대한 통지를 전송하도록 구성될 수 있다.

바람직하게는, 상기 프로세서는 상기 특정 서버가 전송한 관찰 동작 명령을 통해 저장한 관찰 동작 명령 관련 설정 정보를 삭제하도록 구성될 수 있다.

상기 과제 해결방법들은 본 발명의 실시예들 중 일부에 불과하며, 본 발명의 기술적 특징들이 반영된 다양한 실시예들이 당해 기술분야의 통상적인 지식을 가진 자에 의해 이하 상술할 본 발명의 상세한 설명을 기반으로 도출되고 이해될 수 있다.

본 발명의 일 실시예에 따르면, 리소스의 효율적인 관리를 도모할 수 있다.

또한, 본 발명의 일 실시예에 따르면 관찰에 대응하여 효율적인 통지를 가능하게 할 수 있다.

또한, 본 발명의 일 실시예에 따르면 단말의 전력을 효율적으로 관리할 수 있다.

본 발명에 따른 효과는 이상에서 언급한 효과들로 제한되지 않으며, 언급되지 않은 또 다른 효과는 이하의 발명의 상세한 설명으로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.

본 발명에 관한 이해를 돕기 위해 상세한 설명의 일부로 포함되는, 첨부 도면은 본 발명에 대한 실시예를 제공하고, 상세한 설명과 함께 본 발명의 기술적 사상을 설명한다.
도 1 은 M2M 클라이언트에 저장된 데이터(또는 자료) 구조를 도시한다.
도 2 는 본 발명의 일 실시예와 관련된 리소스 모델을 도시한다.
도 3 은 본 발명의 일 실시예와 관련된 인터페이스의 모델을 도시한다.
도 4 는 본 발명의 일 실시예에 따른 부트스트랩 동작을 도시한다.
도 5 는 본 발명의 일 실시예에 따른 부트스트랩 동작을 도시한다.
도 6 은 본 발명의 일 실시예에 따른 관찰 등록 동작을 도시한다.
도 7 은 본 발명의 일 실시예에 따른 관찰에 따른 보고(통지) 동작을 도시한다.
도 8 은 본 발명의 일 실시예에 따른 관찰 등록 및 그에 따른 보고의 동작예를 도시한다.
도 9 는 본 발명의 일 실시예에 따른 접근 권한 소유자 변경 설정 동작을 도시한다.
도 10 은 본 발명의 실시예(들)을 구현하기 위한 장치의 블록도를 도시한다.

이하, 본 발명에 따른 바람직한 실시 형태를 첨부된 도면을 참조하여 상세하게 설명한다. 첨부된 도면과 함께 이하에 개시될 상세한 설명은 본 발명의 예시적인 실시형태를 설명하고자 하는 것이며, 본 발명이 실시될 수 있는 유일한 실시 형태를 나타내고자 하는 것이 아니다. 이하의 상세한 설명은 본 발명의 완전한 이해를 제공하기 위해서 구체적 세부사항을 포함한다. 그러나, 당업자는 본 발명이 이러한 구체적 세부사항 없이도 실시될 수 있음을 안다.

몇몇 경우, 본 발명의 개념이 모호해지는 것을 피하기 위하여 공지의 구조 및 장치는 생략되거나, 각 구조 및 장치의 핵심기능을 중심으로 한 블록도 형식으로 도시될 수 있다. 또한, 본 명세서 전체에서 동일한 구성요소에 대해서는 동일한 도면 부호를 사용하여 설명한다.

본 발명에 있어서, 기기간 통신을 위한 디바이스 즉, M2M 클라이언트 또는 단말은 고정되거나 이동성을 가질 수 있으며, 기기간 통신을 위한 서버 즉, M2M 서버 또는 서버와 통신하여 사용자데이터 및/또는 각종 제어정보를 송수신하는 각종 기기들이 이에 속한다. 상기 M2M 클라이언트는 단말(Terminal Equipment), MS(Mobile Station), MT(Mobile Terminal), UT(User Terminal), SS(Subscribe Station), 무선기기(wireless device), PDA(Personal Digital Assistant), 무선 모뎀(wireless modem), 휴대기기(handheld device) 등으로 불릴 수 있다. 또한, 본 발명에 있어서, M2M 서버는 일반적으로 M2M 단말들 및/또는 다른 M2M 서버와 통신하는 고정된 지점(fixed station)을 말하며, 간단히 서버로 지칭될 수 있으며, M2M 단말들 및/또는 다른 M2M 서버와 통신하여 각종 데이터 및 제어정보를 교환한다.

이하에서는 본 발명과 관련된 배경기술에 대해 설명한다.

장치 관리(Device Management)

장치 관리(DM; Device Management)는 다양한 관리 당국(Management Authorities)들의 관점에서 장치 구성 및 장치들의 다른 관리된 객체를 관리하는 것을 지칭한다. 장치 관리는 장치들 내의 끊임없이 지속되는 정보의 순차적인 업데이트들, 장치들로부터 관리 정보의 검색, 및 장치들에 의해 생성된 이벤트들과 알람들의 처리를 포함하나, 장치들 내의 초기 구성 정보를 설정하는 것에 한정되지 않는다(Management of the Device configuration and other managed objects of Devices from the point of view of the various Management Authorities. Device Management includes, but is not restricted to setting initial configuration information in Devices, subsequent updates of persistent information in Devices, retrieval of management information from Devices and processing events and alarms generated by Devices.)

관리 트리(Management Tree)

관리 트리는 관리 서버가 DM 클라이언트와 상호작용, 예컨대 관리 트리에 값들을 저장하거나 관리 트리로부터 값들을 검색함으로써 그리고 관리 트리의 속성들을 조작함으로써, 하기 위한 인터페이스이고, 예컨대 관리 트리의 한 속성으로 ACL(access control list)가 있다. (The interface by which the management server interacts with the client, e.g. by storing and retrieving values from it and by manipulating the properties of it, for example the access control lists.) 본 명세서에서는, 관리 트리는 장치 관리 트리 또는 DM 트리와 상호호환 가능하게 지칭될 수 있다.

MO(관리 객체; Management Object)

관리 객체는 서로 몇몇 방식으로 관련된 노드들의 집합(하나의 노드 단독으로도 가능)이 될 것이 의도된 관리 트리의 서브 트리이다. 예컨대, ./DevInfo 노드와 그 자식 노드들은 관리 객체를 형성할 수 있다. 간단한 관리 객체는 하나의 단독(single) 노드로 구성될 수 있다(A Management Object is a subtree of the Management Tree which is intended to be a (possibly singleton) collection of Nodes which are related in some way. For example, the ./DevInfo Nodes form a Management Object. A simple Management Object may consist of one single Node.)

DM Server (Device Management Server)

DM 서버 (DM Server)는 상기 DM 서버에 대해 특정된 OMA 장치 관리 인에이블러(Enabler) 고정 적합(static conformance) 요구사항들을 따르는 장치 관리 인프라스트럭쳐에 있는 개념적인 소프트웨어 컴포넌트일 수 있다. 상기 DM 서버는 DM 클라이언트-서버 프로토콜 및 DM 서버-서버 인터페이스의 엔드-포인트로서 서비스할 수 있다(An abstract software component in a deployed Device Management infrastructure that conforms to the OMA Device Management Enabler static conformance requirements specified for DM Servers. It serves as an end-point of the DM Client-Server Protocols and DM Server-Server Interface).

또한, 본 명세서에서 DM 서버는 통신모듈, 프로세서모듈 등을 구비하는 장치, 디바이스, 컴퓨터 등 내에 탑재된 채로 제공될 수 있으며, 따라서 하나의 장치로서 구현될 수 있다.

DM Client (Device Management Client)

DM 클라이언트(DM Client)는 상기 DM 클라이언트에 대해 특정된 OMA 장치 관리 인에이블러(Enabler) 고정 적합(static conformance) 요구사항들을 따르는 장치 임플리멘테이션(implementation)에 있는 개념적인 소프트웨어 컴포넌트일 수 있다. 상기 DM 클라이언트는 DM 클라이언트-서버 프로토콜의 엔드-포인트로서 서비스할 수 있다(An abstract software component in a Device implementation that conforms to the OMA Device Management Enabler static conformance requirements specified for DM Clients. It serves as an end-point of the DM Client-Server Protocols.).

또한, 본 명세서에서 DM 클라이언트는 통신모듈, 프로세서모듈 등을 구비하는 상기 DM 의 대상이 되는 장치 내에 탑재된 채로 제공될 수 있으며, 따라서 하나의 장치로서 구현될 수 있다.

ACL(Access Control List)

ACL 은 관리 트리 내의 특정 노드에 대한 DM 서버 식별자들 및 각각의 DM 서버 식별자와 연관된 접근 권한(access right)들의 리스트를 지칭한다(A list of identifiers and access rights associated with each identifier).

노드(Node)

노드는 관리 트리에 있는 단독 엘리먼트이다. 관리 트리 내에서 노드는 두 종류: 인테리어 노드 및 리프 노드가 있을 수 있다. 노드의 포맷 속성은 노드가 리프 노드인지 인테리어 노드인지 여부에 관한 정보를 제공한다(A Node is a single element in a Management Tree. There can be two kinds of Nodes in a Management Tree: Interior Nodes and Leaf Nodes. The Format property of a Node provides information about whether a Node is a leaf or an Interior Node.).

인테리어 노드(Interior Node)

인테리어 노드는 자식 노드를 가질 수 있는 반면, 노드에 할당된 값 즉, 노드 값(node value)은 가질 수 없다. 인테리어 노드의 포맷 속성은 "node"이다(A Node that may have child Nodes, but cannot store any value. The Format property of an Interior Node is node).

리프 노드(Leaf Node)

리프 노드는 자식 노드를 가질 수 없고 대신 노드 값을 가질 수 있다. 리프 노드의 포맷 속성은 "node"가 아니다(A Node that can store a value, but cannot have child Nodes. The Format property of a Leaf Node is not node.).

따라서 모든 부모(parent) 노드는 인테리어 노드가 되어야만 한다.

영구 노드(Permanent Node)

영구 노드는 DDF 속성 스코프가 퍼머넌트(Permanent)로 설정되있는 노드이다. 노드가 영구 노드가 아니면, 동적 노드에 해당한다. 영구 노드는 서버에 의해 동적으로 생성되거나 삭제될 수 없다(A Node is permanent if the DDF property Scope is set to Permanent. If a Node is not permanent, it is dynamic. A permanent Node can never be deleted by the server.)

동적 노드(Dynamic Node)

동적 노드는 DDF 속성 스코프(Scope)가 다이내믹(Dynamic)으로 설정되있거나, 상기 DDF 속성 스코프가 특정되지 않은 노드이다(A Node is dynamic if the DDF property Scope is set to Dynamic, or if the Scope property is unspecified).

서버 식별자(Sever Identifier)

서버 식별자는 DM 서버에 대한 OMA DM 내부 이름을 지칭한다. DM 서버는 OMA DM 계정을 통해 장치에 존재하는 서버 식별자와 연관된다(The OMA DM internal name for a DM Server. A DM Server is associated with an existing Server Identifier in a device through OMA DM account.).

ACL 속성 및 ACL 값

DM(device management) 프로토콜로 관리되는 모든 단말은 루트 노드(root node)로 시작되는 하나의 DM 트리(tree)를 갖게 되고, DM 프로토콜은 DM 트리의 각 노드를 조작함으로써 단말에 관리 명령을 수행한다. 예로, 단말에 다운로드 된 소프트웨어를 설치하기 위해서는 그 소프트웨어와 매칭되어 있는 인스톨(install)이라는 노드를 실행(Exec)하면, 해당 소프트웨어를 설치할 수가 있다. 각각의 노드는 숫자와 같은 단순한 정보를 나타낼 수도 있고, 그림 데이터나 로그 데이터처럼 복잡한 데이터를 나타낼 수도 있다. 또한 노드는 실행, 다운로드 등과 같이 하나의 명령을 나타낼 수도 있다.

각각의 노드는 노드와 관련된 메타 정보를 제공해 주는 속성(property)을 갖는다. 이 속성 중에 런타임(runtime) 속성이 있는데, 이 속성은 노드가 DM 트리안에 생성이 되어 소멸될 때까지 사용 가능한 속성을 뜻한다. 이러한 런타임 속성에는 ACL, Format, Name, Size, Title, TStamp, Type, VerNo 가 있다.

ACL(Access Control List)는 DM 1.3 프로토콜에서는 단말과 서버가 모두 구현해야 하는 필수 기능이다. ACL 은 특정 DM 서버가 특정 노드에 수행 가능한 DM 명령(command)들을 명시하며, 명시되지 않는 DM 명령은 수행될 수 없다. 다시 말하면, ACL 은 특정 DM 서버가 특정 노드에 대해 허용된 권한을 의미한다. DM 프로토콜에서 ACL 은 DM 서버의 서버 식별자에 부여되며, URI, IP 주소, DM 서버 자격(certificate)에 부여되지 않는다. 이 서버 식별자는 DM 프로토콜에서 DM 서버를 인증하는 식별자로써 사용된다. 또한, 이러한 ACL 은 ACL 속성(property)과 상기 ACL 속성에 부여된 ACL 값으로 제공될 수 있다. 한편, 본 명세서에서 ACL 값은 ACL 정보(ACL information) 또는 ACL 에 관한 정보로 상호호환 가능하게 지칭될 수 있다. DM 1.3 프로토콜에서는 모든 노드가 ACL 속성을 갖도록 정의되었으며, ACL 속성을 갖는 모든 노드는 비어있는(empty) ACL 값 또는 비어있지 않은(non-empty) ACL 값을 갖도록 정의된다.

ACL 은 다른 런타임 속성과 다른 독특한 성질을 갖는데, 이러한 독특한 대표적인 성질로서 ACL 상속(ACL inheritance)이 있다. ACL 상속은 DM 트리안의 어떤 노드가 ACL 값을 가지고 있지 않을 때, 그 노드에 대한 ACL 값을 부모 노드의 ACL 값에서 가져오는 개념이다. 만약 부모 노드 역시 ACL 값을 가지고 있지 않다면, 그 부모 노드의 부모 노드에서 ACL 값을 가져오게 된다. DM 프로토콜에서는 DM 트리의 최상위 노드인 루트 노드가 반드시 ACL 값을 갖도록 명시하고 있기 때문에, ACL 값은 반드시 상속되게 된다. 이러한 ACL 상속은 개별 DM 명령별로 이루어지지 않고, 전체 ACL 값에 대해 수행되기 때문에, ACL 값이 비어 있어야만, 부모 노드로부터 ACL 상속이 이루어지게 된다. 즉, 어떤 노드의 ACL 값이 Add 권한만을 명시하고 있다면, 명시되어 있지 않는 Get(가져오기) 권한 등은 상속되지 않는다.

DM 프로토콜에서는 루트 노드는 ACL 에 대한 기본 값으로 "Add=*＆Get=*"을 갖게 되며, 여기서 "*"는 와일드 카드(wild card)로써, 임의의 DM 서버를 뜻한다. DM 서버가 ACL 값을 얻기 위해서는 Get 명령을 이용하면 되며, "./NodeA/Node1?prop=ACL"에 대한 Get 명령은 ./NodeA/Node1 의 ACL 값을 가져오게 된다. 또한 ACL 값을 바꾸기 위해서는 교체(Replace) 명령을 이용하면 되며, "./NodeA/Node1?prop=ACL"에 Replace 명령을 수행하여 "Add=DMS1＆Delete=DMS1＆Get=DMS1"로 값을 바꾸게 되면 ACL 값이 바뀌게 된다. DM 프로토콜에서는 개별 ACL 엔트리(acl entry)를 바꿀 수가 없고, 전체 ACL 값을 바꿀 수 있도록 정의되어 있다. ACL 값을 얻어 오고, 수정하는 권한 역시 ACL 에 기반하여 정의되는데, 인터리어 노드와 리프 노드에 대한 권한이 조금 다르게 정의되어 있다.

- 인테리어 노드

해당 노드에 Get 과 Replace 권한을 가지고 있다면, 해당 노드의 ACL 값을 각각 가져오고 교체할 수 있는 권한이 있다. 또한 Replace 권한은 모든 자식 노드의 ACL 값을 교체할 수 있는 권한을 의미한다.

- 리프 노드

해당 노드의 부모 노드에 Replace 권한을 가지고 있다면, 그 노드의 ACL 값을 교체할 수 있는 권한이 있다. 해당 노드의 ACL 을 가져오기 위해서는 부모 노드에 Get 권한을 가지고 있어야 한다. 마찬가지로, 해당 노드에 Replace 권한을 가지고 있다면, 그 노드의 값을 교체할 수 있는 권한을 뜻하며, ACL 을 교체하기 위해서는 부모 노드에 Replace 권한을 가지고 있어야 한다.

인테리어 노드이건 리프 노드이건 상관없이 해당 노드의 ACL 값을 교체하는 권한은 부모 노드의 ACL 값에 의해 제어될 수 있다. 인테리어 노드에 Replace 권한을 가지고 있다면, 해당 인테리어 노드는 물론, 모든 자식 노드의 ACL 값을 교체할 수 있는 권한을 뜻한다. 따라서, 루트 노드에 Replace 권한을 가지고 있다면, DM 트리 내의 모든 노드에 어떤 권한이든지 가질 수 있다는 뜻이 된다. 하지만 부모 노드에 Replace 권한을 갖고 있다는 것이 곧바로, 자식 노드에 Get 과 같은 특정 권한을 내포하지는 않으며, 해당 자식 노드에 직접적으로 Get 과 같은 권한이 명시되어 있어야만 한다. 따라서 명령 수행 전에 ACL 값을 수정해 줘야만 하며, 수정하려는 노드로 가는 길에 있는 모든 노드에 대한 ACL 값의 수정을 통해 최종적으로 해당 자식 노드의 ACL 값을 수정하게 된다. 이는 불편하기 때문에, DM 프로토콜에서는 부모 혹은 선조 노드(ancestor node)에 Replace 권한을 가지고 있을 경우, 중간 노드의 ACL 값 수정 없이 바로 해당 노드의 ACL 값의 수정을 허용하고 있다.

DM 서버가 새로운 노드를 추가(Add) 명령을 통해 생성한 경우, 생성된 노드는 일반적으로 ACL 값을 갖지 않게 되어, 모든 권한을 부모에게서 상속받게 된다. 하지만 생성한 노드가 인테리어 노드이고, 부모 노드에 Replace 권한을 가지고 있지 않을 경우, 생성과 동시에 ACL 값을 설정하여 해당 노드를 관리하기 위한 충분한 권한을 갖는 것이 필요하다.

ACL 값을 나타내기 위한 문법은 [DM-TND]에 정의되어 있으며, ACL 값의 한 예는 "Get=DMS1＆Replace=DMS1＆Delete=DMS2"를 들 수 있다. 여기서 DMS1 과 DMS2 는 DM Server 의 서버 식별자이며, Get, Replace, Delete 는 DM 명령이다. 따라서 해당 노드에 대해 DMS1 은 Get 과 Replace 명령을 수행할 수가 있고, DMS2 는 Delete 명령을 수행할 수 있다. 여기서 Get=DMS1, Replace=DMS1, Delete=DMS2 는 각각이 ACL-엔트리(acl-entry)이며, DM 서버의 개별 명령 권한을 나타낸다. 다시말하면, ACL 값은 개별 ACL-엔트리(acl-entry)의 집합이며, 각 노드의 ACL 값은 적어도 하나의 ACL 엔트리를 포함할 수 있다.

DDF(Device Description Framework)

DDF 는 특정 디바이스 타입에 대한 관리 신택스와 시멘틱을 기술하는 방법에 관한 설명이다(A specification for how to describe the management syntax and semantics for a particular device type). DDF 는 단말의 MO, 관리 기능 및 DM 트리 구조에 대한 정보를 제공한다.

DM 1.3 인증

DM 1.3 에서는 ACL 에 기반하여 인증을 수행한다. DM 인증은 각각의 DM 명령에 대해 별도로 이루어진다. 만약 DM 서버가 다수의 DM 명령을 전송했으면, DM 클라이언트)는 개별 명령을 수행하기 전에 인증을 수행하고, 그 결과로 허가된 DM 명령만 수행하게 된다.

DM 트리

DM 트리는 DM 클라이언트에 의해 노출된 MO 인스턴스들의 집합을 지칭한다. DM 트리는 클라이언트와 상호작용하는 관리 서버에 의한 인터페이스로 기능하며, 예컨대 상기 관리 서버는 DM 트리로부터 특정 값들을 저장하고 검색(retrieve)하며, 상기 DM 트리의 속성을 조작할 수 있다.

다중 서버 환경에서는 하나의 단말에 접속하여 단말 관리 또는 단말이 제공하는 서비스를 사용하는 서버가 다 수가 될 수 있다. 단말이 제공하는 서비스는 자원의 형태, 자원군의 형태로 제공될 수 있다. 즉, 단말이 특정 서비스를 서버에게 제공함은, 단말이 특정 자원(군)을 서버에 노출하며, 서버가 상기 자원을 조작함으로써 특정 서비스가 수행될 수 있다.

자원(군)은 해당 자원(군)의 접근 권한을 관리하는 접근 권한 관리자인 서버가 존재하는데, 해당 자원의 접근 권한 관리자가 유일하고 해당 자원을 접근할 수 있는 타 서버가 있는 환경에서 해당 자원 관리자의 서버 계정이 삭제되는 경우가 발생할 수 있다. 이 경우 해당 자원의 접근 권한 관리자가 삭제되었기에 어떠한 서버도 해당 자원의 접근 권한 관리를 수행하지 못하게 되며, 이로 인해 어떠한 서버도 해당 자원에 어떤 서버가 어떠한 접근(예컨대 서버가 해당 자원의 특정 명령에 대해 권한을 가지는 것)을 할 수 있는지에 대해 설정/해지가 불가능하게 된다. 이에 본 발명에서는 접근 권한 관리자인 서버의 계정이 삭제될지라도 지속적으로 해당 자원에 대한 접근 권한 관리를 위해 해당 자원을 접근할 수 있는 타 서버(들) 중 타 서버(들)의 접근 권한에 기반하여 접근 권한 관리자 서버를 설정하는 방법을 제시한다.

도 1 은 M2M 클라이언트에 저장된 데이터(또는 자료) 구조를 도시한다. M2M 클라이언트(또는 단말)는 상기 M2M 클라이언트가 구현할 수 있는 기능에 해당하는 "객체(Object)" 로 지칭되는 리소스(resource)들이 그룹화된 엔티티(들)를 가질 수 있고, 객체의 식별자는 객체 설명(specification)에서 정의되거나, 객체 설명에서 정의되지 않은 식별자는 M2M 시스템을 이용하는 사업자 또는 제조사가 설정할 수 있다. 리소스는 실제 데이터를 저장하는 엔티티로써, 리소스는 복수 개의 리소스 인스턴스(instance)들을 가질 수 있다. 각 객체는 특정 동작 명령에 의해 객체 인스턴스(object instance)로서 생성되어 실체화 되며, M2M 클라이언트는 상기 객체 인스턴스를 통해 실제 해당 리소스에 대해 접근할 수 있다.

"객체" 는 특정 기능 (functionality) 또는 목적을 위해 사용될 리소스들의 그룹에 대한 정의이며, "객체 인스턴스" 는 상기 객체가 단말에 실체화(instantiation, creation)된 리소스 그룹으로, 객체의 기능을 사용하려면 객체 인스턴스가 반드시 생성되어야 한다.

상세하게는, "객체" 는 실체화될 리소스 그룹의 탬플릿(template), 청사진(blue print)과 같은 개념으로 실체화될 리소스 그룹이 어떠한 리소스(들)을 가질 수 있으며, 리소스(들)이 어떠한 속성(예컨대 리소스의 식별자, 이름, 지원되는 동작 명령, 범위, 단위, 설명)들을 가지는지, 특정 동작 명령에 대해 어떠한 동작을 하는지에 대해서 정의한다. "객체 인스턴스" 는 객체의 정의를 따라 단말에 존재하는 또는 실체화된 리소스 그룹으로 해당 리소스 그룹의 리소스는 리소스에 해당하는 값을 가질 수 있다.

이하 명세서에서, 별도의 언급이 없다면, "객체" 는 "지원되는 리소스(들)의 그룹" 또는 "리소스 그룹 정의" 와 상호 교환가능(interchangeably)하게 사용될 수 있으며, 그리고 "객체 인스턴스" 는 "실체화된 리소스(들)의 그룹" 또는 "리소스 그룹" 으로 상호 교환가능(interchangeably)하게 지칭될 수 있다.

또한, 각 리소스에는 해당 리소스가 어떤 동작 명령(operation)을 지원하는지를 나타내기 위한 정보가 포함되거나 첨부되며, 상기 동작 명령은 예컨대 읽기(Read), 쓰기(Write), 실행(Execute), 쓰기 속성(Write Attributes), 탐색(Discover), 관찰(Observe) 등이 있다.

도 2 는 본 발명의 일 실시예와 관련된 리소스 모델을 도시한다. 본 발명의 일 실시예에 따른 M2M 시스템에서 사용될 리소스에 대한 접근 권한의 제어를 위해 ACL(Access Control List)와 AT(Access Type)을 할당한다.

상기 ACL 은 특정 기능이 실체된 자원, 즉 객체 인스턴스 별로 할당되며, 상기 객체 인스턴스의 하위 리소스는 동일한 ACL 를 할당받은 것으로 간주된다. 즉, ACL 은 객체 인스턴스 별로 할당되므로, 그 하위 리소스는 동일한 ACL 을 갖는 것으로 약속된다.

객체 인스턴스는 리소스가 그룹화 되어있는 엔티티이고, 특정 기능을 수행하기 위해 모인 집단이기 때문에 특정 서버에게 특정 기능에 대한 권한을 부여할 시 집단 안의 모든 리소스에 대해 동일한 권한을 부여하는 것이 타당하다. 동일한 권한을 부여하지 않을 시 하나의 기능에 대해 부분적으로만 동작을 수행할 수 있게 되는데, 이렇게 될 시 해당 서버의 역할이 모호해지며 권한 부여에 대한 의미가 퇴색된다. 따라서, 본 발명의 일 실시예에선 상기 언급한 것처럼 각 객체 인스턴스 별로 ACL 을 할당함으로써, 종래에 개별 리소스 별로 저장되는 경우에 비하여 오버헤드를 줄일 수 있으며, ACL 을 찾는데 동일한 메커니즘이 사용되기에 접근 권한 인증 절차가 간소화될 수 있다.

참고로, 각 객체는 복수 개의 객체 인스턴스(들)로 실체화(instantiate)될 수 있다.

또한, 상기 AT 는 개별 리소스 별로 할당될 수 있으며, 각 개별 리소스가 지원하는 접근 방식을 정의할 수 있다. 예컨대, 접근 방식이 동작 명령(operation)들로 정의된다면, 상기 AT 는 특정 동작 명령들, 예컨대 읽기(Read), 쓰기(Write), 실행(Execute) 등으로 정의될 수 있다.

한편, 상기 ACL 과 상기 AT 는 각각 다르게 지칭될 수 있으며, 예컨대 ACL 은 접근 권한(Access Right), AT 는 지원 가능한 동작 명령 등으로 지칭될 수 있다.

인터페이스

본 발명의 구체적인 실시예들을 설명하기에 앞서, 특정 동작 명령들이 서버와 클라이언트(단말) 간에 전달되는 인터페이스에 대해 설명하도록 한다.

본 발명과 관련되어, 총 4 개의 인터페이스가 존재한다. 1) 부트스트랩(Bootstrap), 2) 장치(클라이언트, 디바이스) 등록(Device(Client) Registration), 3) 장치 관리 및 서비스 인에이블먼트(Device Management and Service Enablement), 4) 정보 보고(Information Reporting). 상기 네 가지의 인터페이스들을 위한 동작 명령들은 상향링크 동작들 및 하향링크 동작들로 분류될 수 있다. 각각의 인터페이스의 동작 명령들이 아래의 표에 정의된다.

[표 1]

도 3 은 네 가지의 인터페이스들을 도시한다. 도 3 의 (a)는 부트스트랩 인터페이스를 위한 동작 모델을 도시한다. 부트스트랩 인터페이스를 위해, 동작 명령들은 "부트스트랩 요청" 으로 명명된 상향링크 동작 명령(즉, 클라이언트 개시 부트스트랩)과 "쓰기" 및 "삭제" 로 명명된 하향링크 동작 명령(즉, 서버 개시 부트스트랩)이다. 이들 동작 명령들은 하나 이상의 서버들과 등록하기 위해 클라이언트를 위한 필요한 객체 인스턴스(들)를 초기화하는데 사용된다. 부트스트랩은 또한 제조자 부트스트랩(factory bootstrap) 또는 스마트카드로부터의 부트스트랩(bootstrap from smartcard) (스마트카드에 저장)을 이용하여 정의된다.

도 3 의 (b)는 "장치(클라이언트) 등록" 인터페이스를 위한 동작 모델을 도시한다. 상기 장치 등록 인터페이스를 위해, 동작 명령들은 "등록" "업데이트" 및 "등록-해제" 로 명명된 상향링크 동작 명령들이다. 등록" 은 서버에 클라이언트의 정보를 등록하는데 사용되고, "업데이트" 는 주기적으로 또는 클라이언트에 발생한 이벤트에 의해 서버에 등록된 클라이언트의 정보 또는 상태를 업데이트하는데 사용된다. "등록-해제" 는 서버에 클라이언트의 등록을 해제하는 단계로써 서버는 클라이언트의 정보를 삭제할 수 있다.

도 3 의 (c)는 "장치 관리 및 서비스 인에이블먼트(device management and service enablement)" 인터페이스를 위한 동작 모델을 도시한다. 상기 장치 관리 및 서비스 인에이블먼트 인터페이스를 위해, 상기 동작 명령들은 "읽기" "생성" , "삭제" , "쓰기" , "실행" , "쓰기 속성" , 및 "탐색" 으로 명명된 하향링크 동작 명령들이다. 이러한 동작 명령들은 클라이언트의 리소스들, 리소스 인스턴스들, 객체들 및 객체 인스턴스들과의 상호작용을 위해 사용된다. "읽기" 동작 명령은 하나 이상의 리소스들의 현재 값을 읽기 위해 사용되며, "쓰기" 동작 명령은 하나 이상의 리소스들의 값을 업데이트하기 위해 사용되고, "실행" 동작 명령은 리소스에 의해 정의된 동작을 개시하기 위해 사용된다. "생성" 및 "삭제" 동작 명령들은 객체 인스턴스들을 생성 또는 삭제하기 위해 사용된다. "쓰기 속성" 은 "관찰" 동작 명령과 관련된 속성을 설정하는데 사용하며, "탐색" 은 해당 속성을 검색할 때 사용한다.

도 3 의 (d)는 "정보 보고" 인터페이스를 위한 동작 모델을 도시한다. 상기 정보 보고 인터페이스를 위해, 상기 동작 명령들은 하향링크 동작 명령들 "관찰" 또는 "취소 관찰" 및 상향링크 동작 명령 "통지(Notify)" 를 포함한다. 상기 정보 보고 인터페이스는 서버로 클라이언트 상의 리소스와 관련된 새로운 값을 전송하기 위해 사용된다. "관찰" 은 서버가 자원의 자원의 변화에 관심이 있을 경우 특정 자원을 관찰하는데 사용되며, "취소 관찰" 은 해당 관찰을 더 이상 하지 않을 때(자원의 변화를 더 이상 알고 싶지 않을 때) 사용된다. "통지" 는 "쓰기 속성" 을 통해 설정된 관찰 조건 속성이 맞을 경우 이를 서버에 알릴 때 사용한다.

접근 제어를 위한 데이터 모델

M2M 디바이스의 파싱(parsing) 프로세스 오버헤드를 줄이고 공간 오버헤드(space overhead)를 줄이기 위해 M2M 환경에 적합한 서버 식별자(Identifier; ID), ACL(또는 접근 권한), AT(또는 지원가능한 동작 명령)로 모델링한다.

- 짧은 서버 ID

ACL 에 포함되어야 하는 정보는 어떤 서버가 어떠한 동작 명령(operation)을 명령할 수 있는지 여부를 포함해야 한다. 서버 ID 는 통상적으로 URI 로 표현되기에 환경에 따라 URI 가 상당히 길어질 수 있을 수 있다. 객체 인스턴스 별로 ACL 이 표현이 되어야 하고 객체 인스턴스 마다 길이가 긴 서버 ID 가 중복적으로 사용되게 되기에 서버 ID 로 인해 객체 인스턴스 수에 의존하여 상당한 공간 오버헤드를 초래할 수 있다. 이에 짧고 고정된 길이(예컨대, 2 바이트)의 짧은 서버 ID 를 ACL 에서 사용할 것을 제안한다. M2M 클라이언트는 짧은 서버 ID 와 서버 ID 간의 맵핑 관계를 저장하고 있으며, 서버 ID 로부터 수신되는 동작 명령에 대해 짧은 서버 ID 를 찾아 이를 사용하여 ACL 을 통해 인증을 수행할 수 있다.

[표 2]

Access Control List (ACL) 또는 접근 권한

ACL 은 각 객체 인스턴스에 할당되며 각각의 M2M 서버에 대한 접근 권한을 지정하는 ACL 엔트리(entry)의 리스트로 구성된다. ACL 엔트리는 짧은 서버 ID 와 해당 서버의 접근 권한으로 표현될 수 있다. 짧은 서버 ID 와 접근 권한 값은 모두 고정된 짧은 길이로 설정하여 인증 절차 시의 공간 오버헤드와 처리 효율성을 높인다. 접근 권한에서는 M2M 의 각 동작 명령에 대해 하나의 비트 값을 할당하여 특정 동작 명령에 대한 인증 절차를 수행 시 하나의 비트만을 읽으면 되도록 하여 처리 효율성을 높였다. ACL 에서 명시된 서버 이외의 타 서버에 대한 디폴트(default) ACL 엔트리를 설정할 수 있으며, ACL 에 명시되지 않은 모든 서버에 대한 동작 명령을 수신 시 M2M 클라이언트는 특정 짧은 서버 ID(예컨대, 0x0000)를 찾아 해당 접근 권한을 이용하여 해당 동작 명령을 인증할 수 있다.

[표 3]

위의 표에서 예시된 ACL 엔트리 내 값은 일 예시이며, 다르게 설정될 수 있음은 당업자에게 자명하다.

Access Type (AT) 또는 지원가능 동작 명령

AT 는 리소스가 어떤 동작 명령을 지원하는지를 지정할 수 있다. ACL 엔트리의 접근 권한과 동일한 형태로, 하나의 비트마다 하나의 동작 명령을 맵핑하였다.

[표 4]

위의 표에서 예시된 Access Type 내 값은 일 예시이며, 다르게 설정될 수 있음은 당업자에게 자명하다.

이하, 본 명세서에서 사용되는 M2M 관련 동작 명령 및 객체 (인스턴스)에 대한 설명을 간략히 하도록 한다.

- 1. "장치(클라이언트) 등록" 인터페이스를 위한 동작

·등록(Register)

등록은 M2M 클라이언트가 "등록" 동작 명령을 M2M 서버로 전송하는 경우에 수행된다. M2M 장치가 켜지고(turned on) 부트스트랩 절차가 완료되면, M2M 클라이언트는 자신이 가지고 있는 서버 객체 인스턴스에 해당하는 M2M 서버 각각(즉, 상기 M2M 클라이언트가 등록된 각 서버)에 "등록" 동작 명령을 수행해야 한다. 아래의 표는 "등록" 동작 명령을 위해 사용되는 파라미터들을 설명한다.

[표 5]

·업데이트(Update)

주기적으로 또는 M2M 클라이언트 내 특정 이벤트들에 기반하여 또는 M2M 서버에 의해 개시되어, M2M 클라이언트는 M2M 서버로 "업데이트" 동작 명령을 전송함으로써 M2M 서버와 자신의 등록 정보를 업데이트할 수 있다. "업데이트" 동작 명령은 M2M 서버로 전송된 마지막 등록 파라미터들과 비교하여 변경된 아래의 표에 열거된 파라미터들만을 포함 가능하다.

만약 M2M 클라이언트가 M2M 서버와의 통신을 위한 UDP 바인딩 및 M2M 클라이언트의 IP 어드레스 또는 포트 변경들을 이용하는 경우, 상기 M2M 클라이언트는 M2M 서버로 "업데이트" 동작 명령을 전송해야 한다.

[표 6]

상기 "업데이트" 동작 명령은 M2M 서버 객체의 "등록 업데이트 트리거(Registration Update Trigger)" 리소스에 대한 "실행" 동작 명령을 통해 M2M 서버에 의해 개시될 수 있다.

·등록-해제(De-register)

M2M 클라이언트가 M2M 서버에게 더 이상 이용가능하지 않다고 판단하면(예컨대, M2M 장치 공장 리셋(factory reset)), M2M 클라이언트는 M2M 서버에게 "등록-해제" 동작 명령을 전송해야 한다. 이 동작 명령을 수신하면, M2M 서버는 상기 M2M 서버로부터 상기 M2M 클라이언트에 대한 등록 정보를 제거해야 한다.

- 2. "장치 관리 및 서비스 인에이블먼트(device management and service enablement)" 인터페이스를 위한 동작

·읽기(Read)

"읽기" 동작 명령은 개별 리소스, 어레이(array)의 리소스 인스턴스들, 객체 인스턴스 또는 객체의 모든 객체 인스턴스들의 값에 접근(읽기)하기 위해 사용되며, 다음과 같은 파라미터들을 갖는다.

[표 7]

·탐색(Discover)

"탐색" 동작 명령은 개별 리소스, 객체 인스턴스, 객체에 설정된 속성(파라미터, attribute, parameter)들을 탐색하기 위해 사용된다. 상기 탐색 동작 명령은 또한 특정 객체 내에서 어떤 리소스들이 구현(implement)되었는지를 탐색하기 위해 사용된다. 리턴되는 값들은 리소스의 속성들을 포함하는 각 리소스에 대한 어플리케이션/링크-포맷 CoRE 링크들(RFC6690 의 application/link-format CoRE 형식을 따르는 링크들)의 리스트이다. 상기 탐색 동작 명령은 다음과 같은 파라미터들을 갖는다.

[표 8]

상기 탐색 명령의 특이한 기능으로는, 상기 파라미터들 중 객체 ID 만이 명시된 경우엔, 어떤 리소스가 구현되어 있는지가 리턴 및 객체에 설정된 관찰(observe) 파라미터들이 리턴될 수 있고, 상기 파라미터들 중 객체 인스턴스 ID 까지만 명시된 경우(즉, 객체 ID 와 객체 인스턴스 ID 가 명시됨), 명시된 객체 인스턴스에 설정된 관찰 파라미터들이 리턴될 수 있고, 상기 파라미터들 중 리소스 ID 까지 명시된 경우(즉, 객체 ID, 객체 인스턴스 ID, 리소스 ID 가 명시됨), 명시된 리소스에 설정된 관찰 파라미터들이 리턴될 수 있다.

·쓰기(Write)

"쓰기" 동작 명령은 리소스, 어레이(array)의 리소스 인스턴스들, 또는 객체 인스턴스에 복수의 리소스들의 값을 변경(쓰기)하기 위해 사용된다. 상기 쓰기 동작 명령은 하나의 명령을 통해 동일한 객체 인스턴스 내에서 복수의 리소스들이 변경되는 것을 허용한다. 즉, 상기 쓰기 동작 명령은 (개별 리소스 뿐만 아니라) 하나의 객체 인스턴스에 대하여 접근이 가능하다. 상기 쓰기 동작 명령은 다음과 같은 파라미터들을 갖는다.

[표 9]

·쓰기 속성(Write Attributes)

"쓰기 속성" 동작 명령은 리소스 또는 객체 인스턴스, 객체의 속성들을 변경(쓰기)하기 위해 사용된다. 상기 쓰기 속성 동작 명령은 다음과 같은 파라미터들을 갖는다.

[표 10]

상기 최소 주기, 최대 주기, 초과(Greater Than), 미만(Less Than) 및 스텝(Step)은 오직 관찰 동작 명령에서 사용된다. 최대 및/또는 최소 주기 파라미터들은 얼마나 자주 "통지(Notify)" 동작 명령이 관찰된 객체 인스턴스 또는 리소스를 위해 M2M 클라이언트에 의해 전송되는지를 제어하기 위해 사용된다. 초과, 미만, 및 스텝 파라미터는 리소스 ID 가 지시된 경우에만 유효하다. 초과, 미만, 및 스텝 파라미터는 리소스 타입이 수(예컨대, 정수, 소수(decimal))인 경우에만 지원되어야 한다.

·실행(Execute)

"실행" 동작 명령은 어떤 동작을 개시하기 위해 M2M 서버에 의해 사용되며, 개별 리소스들에 대해서만 수행될 수 있다. M2M 클라이언트는 상기 "실행" 동작 명령이 객체 인스턴스(들) 또는 리소스 인스턴스(들)에 대해 수신된 경우 에러를 리턴한다. 상기 실행 동작 명령은 다음과 같은 파라미터들을 갖는다.

[표 11]

·생성(Create)

"생성" 동작 명령은 M2M 클라이언트 내에 객체 인스턴스를 생성하기 위해 M2M 서버에 의해 사용된다. 상기 "생성" 동작 명령은 객체 또는 아직 인스턴스화 (또는 실체화(instantiate))되지 않은 객체 인스턴스 중 하나를 타깃(target)해야 한다.

M2M 서버에 의해 M2M 클라이언트에서 생성된 객체 인스턴스는 M2M 클라이언트에 의해 지원되는 객체 타입이어야 하고 디바이스 등록 인터페이스의 "등록" 및 "갱신" 동작 명령을 사용하여 M2M 서버로 M2M 클라이언트에 의해 통지된 객체 타입이어야 한다.

최대 하나의 객체 인스턴스를 지원하는 객체는 상기 객체 인스턴스가 생성되면 0 의 객체 인스턴스 ID 를 할당받아야 한다. "생성" 동작 명령은 다음의 파라미터들을 갖는다.

[표 12]

·삭제(Delete)

"삭제" 동작 명령은 M2M 클라이언트 내 객체 인스턴스를 삭제하기 위해 M2M 서버를 위해 사용된다. M2M 서버에 의해 M2M 클라이언트에서 삭제된 객체 인스턴스는 디바이스 등록 인터페이스의 "등록" 및 "갱신" 동작 명령을 사용하여 M2M 서버로 M2M 클라이언트에 의해 통지된 객체 인스턴스이어야 한다. 상기 삭제 동작 명령은 다음과 같은 파라미터들을 갖는다.

[표 13]

- 3. "정보 보고" 인터페이스를 위한 동작

·관찰(Observe)

M2M 서버는 M2M 클라이언트 내 특정 리소스, 객체 인스턴스 내의 리소스들, 또는 객체의 모든 객체 인스턴스들의 변경들에 대한 관찰 요청을 개시할 수 있다. "관찰" 동작 명령을 위한 관련 파라미터들은 "쓰기 속성" 동작 명령에서 설정된다. 상기 관찰 동작 명령은 다음의 파라미터들을 포함한다.

[표 14]

·통지(Notify)

"통지" 동작 명령은 M2M 클라이언트로부터 M2M 서버로 객체 인스턴스 또는 리소스에 대한 유효한 관찰 동안에 전송된다. 이 동작 명령은 상기 객체 인스턴스 또는 리소스의 새로운 값을 포함한다. 상기 "통지" 동작 명령은 "관찰" 동작 명령을 위한 "쓰기 속성(Write Attribute)" 동작 명령에 의해 설정되는 모든 조건들(즉, Minimum Period, Maximum Period, Greater Than, Less Than, Step) 만족되면 전송되어야 한다. 상기 통지 동작 명령은 다음의 파라미터를 포함한다.

[표 15]

·취소 관찰(Cancel Observe)

"취소 관찰" 동작 명령은 M2M 서버로부터 M2M 클라이언트로 객체 인스턴스 또는 리소스에 대한 관찰 관계를 종료하기 위해 전송된다. 상기 취소 관찰 동작 명령은 다음의 파라미터들을 포함한다.

[표 16]

접근 제어 기법

이하는 M2M 에서 사용되는 접근 제어 방법을 설명하도록 한다.

- 접근 권한 획득

M2M 클라이언트가 하나의 M2M 서버 객체 인스턴스를 가지면, M2M 클라이언트는 상기 하나의 M2M 서버에 대한 접근 제어를 거치지 않고, 즉 접근 제어 객체 인스턴스를 확인하지 않고, 상기 M2M 서버는 해당 리소스에 대한 모든 권한을 갖는다.

만약 M2M 클라이언트가 둘 이상의 M2M 서버 객체 인스턴스를 가지면, 상기 M2M 클라이언트는 접근하려는 객체 인스턴스 또는 리소스가 속한 객체 인스턴스에 대한 해당 서버의 ACL 을 접근 제어 객체 인스턴스(들)에서 찾는다. 만약 해당 M2M 서버 ID 에 해당하는 접근 권한이 ACL 에 존재한다면, 해당 M2M 서버는 해당 접근 권한을 갖는다. 해당하는 M2M 서버 ID 의 ACL 엔트리가 존재하지 않는다면, M2M 클라이언트는 디폴트 서버 ID 에 할당된 접근 권한이 ACL 에 존재하는지 확인하고, 상기 디폴트 서버 ID 가 존재한다면, 해당 M2M 서버는 디폴트 서버 ID 의 접근 권한을 갖는다. M2M 서버 ID 에 해당하는 접근 권한이 존재하지 않고 상기 디폴트 서버 ID 의 접근 권한이 존재하지 않으면, 해당 M2M 서버는 해당 리소스에 대한 접근 권한을 갖지 않는다.

- 접근 제어 객체 (Access Control Object)

접근 제어 객체는 M2M 서버가 동작 명령을 수행하기 위한 접근 권한을 갖고 있는지 여부를 체크하기 위해 사용된다. 각각의 접근 제어 객체 인스턴스는 특정 객체 인스턴스에 대한 ACL(Access Control List)를 포함한다.

[표 17]

- 인증 절차

M2M 서버로부터 전달된 동작 명령에 대해 인증 절차를 통과하기 위해서는 두 가지가 만족되어야 한다. 첫째로, M2M 서버가 해당 자원(예컨대, 객체 인스턴스, 리소스)에 대해 상기 전달된 동작 명령을 수행할 권한(즉, 접근 권한)이 있는지, 둘째로, 해당 자원이 상기 전달된 동작 명령을 지원하는지가 만족되어야 한다. 이처럼, 본 발명의 일 실시예에 다른 접근 권한 인증 절차는 두 개의 스텝, 즉 계층적인 구조로 수행된다.

M2M 클라이언트는 해당 자원에 대해 접근 권한이 없을 경우 에러 메시지를 전송하고, 해당 자원이 상기 전달된 동작 명령을 지원하지 못할 경우에는 상기 해당 자원에 대한 정보를 M2M 서버로 전달함으로써, 어떠한 자원으로 인해 상기 전달된 동작 명령이 수행되지 않았음을 알린다. 인증 절차는 3-레벨, 즉 리소스, 객체 인스턴스, 객체에 대하여 조금씩 다르게 이루어진다.

- 리소스에 대한 동작 명령

만약 M2M 서버가 개별 리소스에 접근하면, 즉 상기 M2M 서버가 개별 리소스에 대한 동작 명령을 M2M 클라이언트로 전송하면, 상기 M2M 클라이언트는 위에서 설명한 접근 권한을 획득하는 방법에 따라 상기 개별 리소스가 속하는 객체 인스턴스에 대한 M2M 서버의 접근 권한을 획득하고, 상기 접근 권한이 상기 동작 명령을 수행하도록 승인되었는지 여부를 체크할 수 있다.

만약 상기 동작 명령이 허용되지 않으면, 상기 M2M 클라이언트는 상기 M2M 서버로 "접근 권한 허용이 거절됨" 에러 코드를 전송해야 한다.

만약 상기 동작 명령이 허용되면, M2M 클라이언트는 상기 개별 리소스가 상기 동작 명령을 지원하는지 여부를 검증할 수 있다.

만약 상기 동작 명령이 상기 개별 리소스에 의해 지원되지 않으면, 상기 M2M 클라이언트는 상기 M2M 서버로 "동작 명령이 지원되지 않음" 에러 코드를 전송해야 한다.

만약 상기 개별 리소스가 상기 동작 명령을 지원하면, 상기 M2M 클라이언트는 상기 동작 명령을 수행할 수 있다.

- 객체 인스턴스에 대한 동작 명령

만약 M2M 서버가 객체 인스턴스에 액세스하면, 즉 상기 M2M 서버가 객체 인스턴스에 대한 동작 명령을 M2M 클라이언트로 전송하면, 상기 M2M 클라이언트는 상술한 접근 권한 획득 방법에 따라 객체 인스턴스에 대한 M2M 서버의 접근 권한을 획득하고 상기 접근 권한이 상기 동작 명령을 수행하도록 승인되었는지 여부를 체크할 수 있다.

만약 상기 동작 명령이 허용되면, 상기 M2M 클라이언트는 상기 동작 명령에 기반하여 다음의 절차들을 수행할 수 있다.

"쓰기(Write)" 동작 명령에 대해, 상기 M2M 클라이언트는 상기 동작 명령에서 전달된 모든 리소스들이 "쓰기" 동작 명령을 수행하도록 허용된 경우에만 상기 객체 인스턴스에 대한 동작 명령을 수행할 수 있다. 만약 (상기 동작 명령에서 전달된) 어떤 리소스라도 상기 "쓰기" 동작 명령을 지원하지 않으면, 상기 M2M 클라이언트는 상기 M2M 서버에게 "동작 명령이 지원되지 않음" 에러 코드를 전송함으로써 상기 동작 명령을 지원하지 않은 리소스들을 알릴 수 있다.

"읽기(Read)" 동작 명령에 대해, 상기 M2M 클라이언트는 "읽기" 동작 명령을 지원하지 않는 리소스(들)을 제외한 모든 리소스들을 읽고(retrieve), 상기 읽은 리소스(들)(retrieved Resources) 정보를 상기 M2M 서버로 전송할 수 있다.

"생성(Create)" 동작 명령에 대해, 상기 M2M 클라이언트는 오직 상기 동작 명령에서 전달된 모든 리소스들이 "쓰기" 동작 명령을 수행하도록 허용되고 모든 필수 리소스들이 특정된 경우에만 상기 객체 인스턴스에 대한 동작 명령을 수행할 수 있다. 만약, (상기 동작 명령에 포함된) 어떤 리소스라도 상기 "쓰기" 동작 명령을 지원하지 않으면, 상기 M2M 클라이언트는 상기 M2M 서버에게 "동작이 지원되지 않음" 에러 코드를 전송함으로써 상기 동작 명령을 지원하지 않는 리소스들을 알릴 수 있다. 만약 모든 필수 리소스들이 특정되지 않으면, 상기 M2M 클라이언트는 상기 M2M 서버로 "Bad Request" 에러 코드를 전송할 수 있다.

"삭제(Delete)" , "관찰(Observe)" , "쓰기 속성(Attribute)" , 또는 "탐색(Discover)" 동작 명령에 대해, 상기 M2M 클라이언트는 상기 동작 명령을 수행해야 한다. 즉, 상기 M2M 클라이언트는 상기 객체 인스턴스에 대한 동작 명령이 상기 객체 인스턴스에 속한 모든 리소스에 의해 지원되는지 여부를 체크하지 않고, 상기 삭제(Delete)" , "관찰(Observe)" , "쓰기 속성(Attribute)" , 또는 "탐색(Discover)" 동작 명령을 수행해야 한다.

만약 앞서 언급한 동작 명령이 아닌 동작 명령에 대해서는, 상기 M2M 클라이언트는 상기 동작 명령을 수행해서는 안되며 상기 M2M 서버로 "동작이 지원되지 않음" 에러 코드를 전송해야 한다.

객체 인스턴스에 대한 동작 명령에 대해 정리하면, 상기 객체 인스턴스에 대한 해당 M2M 서버의 접근 권한의 소유 여부는 상기 접근 권한 획득 방법에 의해 수행된다. 그리고 나서, 상기 객체 인스턴스에 속한 개별 리소스(들)이 상기 동작 명령을 지원하는지 여부가 확인되며, 이 과정은 상기 동작 명령의 종류에 따라 수행되거나 수행되지 않는다.

- 객체에 대한 동작 명령

객체에 대한 동작 명령 또한 동작 명령의 종류에 따라 정의된다.

M2M 서버가 "읽기" 동작 명령을 객체에 전송하면, 즉 객체에 대한 "읽기" 동작 명령을 M2M 클라이언트로 전송하면, 상기 M2M 클라이언트는 상기 객체에 속하는 (또는 하위의) 객체 인스턴스들 중 상기 M2M 서버가 접근 권한이 있는 객체 인스턴스(들)의 정보를 모아 M2M 서버로 전달할 수 있다. 상기 M2M 서버가 접근 권한이 있는지 여부는 앞서 설명한 접근 권한 획득 방법에 따라 수행된다.

상기 M2M 서버가 접근 권한이 있는 객체 인스턴스의 정보는 상기 M2M 클라이언트는 상기 "읽기" 동작 명령을 지원하지 않는 리소스(들)을 제외한 모든 리소스들을 읽고(retrieve) 상기 M2M 서버로 상기 읽은 리소스(들) 정보를 의미한다.

상기 M2M 서버가 "생성(Create)" 동작 명령을 객체에 전송하면, 즉 상기 M2M 서버가 객체에 대한 "생성" 동작 명령을 M2M 클라이언트로 전송하면, 상기 M2M 클라이언트는 앞서 설명한 접근 권한 획득 방법에 따라 상기 M2M 서버가 상기 객체에 대한 접근 권한을 갖는지 여부를 확인할 수 있다.

상기 M2M 서버가 상기 객체에 대한 접근 권한이 있다면, 상기 M2M 클라이언트는 오직 상기 동작 명령에서 전달된 모든 리소스들이 "쓰기(Write)" 동작 명령을 수행하도록 허용되고 모든 필수 리소스들이 특정되는 경우에만 상기 동작 명령을 수행할 수 있다. 만약 (상기 동작 명령에서 전달된) 어떠한 리소스도 상기 "쓰기" 동작 명령을 지원하지 않으면, 상기 M2M 클라이언트는 상기 M2M 서버에게 "동작 명령이 지원되지 않음" 에러 코드를 전송함으로써 상기 동작 명령을 지원하지 않는 리소스들을 알릴 수 있다. 만약 모든 필수 리소스들이 동작 명령에 포함되어 있지 않으면, 상기 M2M 클라이언트는 "Bad Request" 에러 코드를 상기 M2M 서버로 전송할 수 있다. 즉, 상기 M2M 클라이언트는 이 경우 상기 M2M 서버에 의한 동작 명령이 잘못되었음을 상기 M2M 서버에게 알리는 것이다.

"탐색(Discover)" 동작 명령에 대해, M2M 클라이언트는 상기 동작 명령을 수행해야 한다. 즉, "탐색" 동작 명령에 대해선, 상기 M2M 클라이언트는 상기 M2M 서버가 상기 객체 하위의 모든 객체 인스턴스(들)에 대한 접근 권한을 갖는지 여부와 상기 모든 객체 인스턴스(들)에 속한 모든 리소스(들)이 상기 "탐색" 동작 명령을 지원하는지 여부를 체크하지 않는다.

"관찰(Observe)" 또는 "쓰기 속성(Write Attributes)" 동작 명령에 대해, 상기 M2M 클라이언트는 상기 동작 명령을 수행해야 한다. 즉, "관찰" 또는 "쓰기 속성" 동작 명령에 대해선, 상기 M2M 클라이언트는 상기 M2M 서버가 상기 객체 하위의 모든 객체 인스턴스(들)에 대한 접근 권한을 갖는지 여부와 상기 모든 객체 인스턴스(들)에 속한 모든 리소스(들)이 상기 "관찰" 또는 "쓰기 속성" 동작 명령을 지원하는지 여부를 체크하지 않는다.

만약 상술된 동작 명령외의 동작 명령에 대해선, 상기 M2M 클라이언트는 해당 동작 명령을 수행해서는 안되고 "동작이 지원되지 않음" 에러 코드를 상기 M2M 서버로 전송할 수 있다.

객체에 대한 동작 명령에 대해 정리하면, 상기 객체에 대한 해당 M2M 서버의 접근 권한의 소유 여부는 상기 객체에 대한 특정 동작 명령에 따라 상기 접근 권한 획득 방법에 의해 수행될 지 여부가 결정된다. 그리고 나서, 상기 객체 인스턴스에 속한 개별 리소스(들)이 상기 동작 명령을 지원하는지 여부가 확인되며, 이 과정은 상기 동작 명령의 종류에 따라 수행되거나 수행되지 않을 수 있다. 또한, 객체에 대한 동작 명령의 경우 특정 동작 명령에 대해서는 접근 권한 소유 여부와 상기 특정 동작 명령의 지원 여부에 대해 확인하지 않을 수도 있다.

이하는 서버 보안 객체(또는 객체 인스턴스)와 서버 객체 인스턴스(또는 객체 인스턴스), 그리고 펌웨어 업데이트 객체(또는 객체 인스턴스)를 간략히 설명한다.

M2M 서버 보안 객체(또는 객체 인스턴스)는 특정된 M2M 서버 또는 M2M 부트스트랩 서버에 접근하기 적절한 M2M 클라이언트의 키잉 매터리얼(key material)을 제공한다. 하나의 객체 인스턴스는 M2M 부트스트랩 서버를 지칭(address)하는 것을 권장한다. 상기 M2M 서버 보안 객체의 리소스들은 M2M 부트스트랩 서버 또는 스마트카드로부터의 부트스트랩 인터페이스를 통해 변경될 수 있으나, 다른 어떤 M2M 서버에 의해서도 접근될 수 없다.

[표 18]

[표 19]

다음은 M2M 서버 객체(또는 객체 인스턴스)에 대해 설명한다. M2M 서버 객체는 M2M 서버와 관련된 데이터를 제공한다. M2M 부트스트랩 서버는 그와 관련된 이러한 객체 인스턴스를 갖지 않는다.

[표 20]

[표 21]

본 발명은 M2M 클라이언트에서 M2M 서버의 계정이 삭제될 경우에 발생할 수 있는 비효율성을 해결하는 것에 기인한다. M2M 서버의 계정이 삭제될 경우, 해당 M2M 서버가 특정 리소스에 가진 접근 권한 또한 삭제되게 되는데, 삭제될 접근 권한이 리소스를 지속적으로 관리하는데 어려움을 초래할 수 있다. 또한, 접근 권한 삭제만이 이루어지게 되면 접근 권한이 존재하지 않는 리소스가 M2M 클라이언트에 남게 되는데, 이렇게 되면 해당 리소스는 아무도 접근할 수 없는 엔티티가 된다. M2M 클라이언트에 이벤트가 발생할 경우 이를 알리는 설정(configuration)이 설정되어 있을 수 있는데, 해당 설정 또한 해지를 함으로써 M2M 서버의 계정이 삭제될 시의 효율적인 자원 관리 메커니즘을 소개한다.

접근 권한 소유자(Access Right Owner)

접근 권한 소유자는 특정 리소스의 ACL 을 변경할 수 있는 엔티티이다. 상기 접근 권한 소유자는 특정 접근 권한을 가지고 있을 수도 있으며 (예컨대, delegation access right), 특정 필드에 따로 저장(예컨대, Access Control Owner field, self-permission field)되어 해당 ACL 을 관리할 수 있다. 표 17 에 나타낸 것처럼, 상기 접근 권한 소유자는 하나 또는 여럿일 수 있다.

한편, M2M 서버 계정의 삭제는 위에서 설명한 부트스트랩 인터페이스를 통해 M2M 부트스트랩 서버에 의해 가능하다. 따라서, 상기 M2M 서버 계정의 삭제는 상기 M2M 부트스트랩 서버와 대상 M2M 클라이언트 사이에서 특정 동작 명령의 송수신을 통해 이루어진다. 이에 대한 참조 설명을 하도록 한다.

부트스트랩 인터페이스는 M2M 클라이언트가 하나 이상의 M2M 서버들과 "등록(Register)" 동작 명령을 수행할 수 있도록 하기 위해 상기 M2M 클라이언트에 필수적 정보를 제공(provision)하는데 사용된다. M2M 인에이블러(enabler)에 의해 지원되는 네 개의 부트스트랩 모드들이 존재한다.

- 공장 부트스트랩: M2M 클라이언트에 미리 부트스트랩 정보가 설정되어 있음

- 스마트카드로부터의 부트스트랩: M2M 클라이언트가 스마트카드로부터 부트스트랩 정보를 받아 옴

- 클라이언트 개시 부트스트랩: M2M 클라이언트가 M2M 부트스트랩 서버에 부트스트랩을 요청하고, M2M 부트스트랩 서버는 M2M 클라이언트의 부트스트랩 정보를 추가/삭제/갱신한다.

- 서버 개시 부트스트랩: M2M 부트스트랩 서버는 M2M 클라이언트의 부트스트랩 정보를 추가/삭제/갱신한다.

M2M 클라이언트는 상기 부트스트랩 인터페이스에서 특정된 적어도 하나의 부트스트랩 모드를 지원할 수 있다. M2M 서버는 상기 부트스트랩 인터페이스에서 특정된 모든 부트스트랩 모드들을 지원할 수 있다.

부트스트랩 정보는 M2M 서버 또는 M2M 부트스트랩 서버에 접속하기 위해 M2M 클라이언트에서 설정될 필요가 있는 정보를 지칭한다. 상기 부트스트랩 정보는 부트스트랩 시퀀스를 수행하기 전에 이용가능할 수 있거나, 또는 상기 부트스트랩 시퀀스의 결과로서 획득될 수 있다. 상기 부트스트랩 정보는 두 개의 유형, 즉 M2M 서버를 위한 부트스트랩 정보 및 M2M 부트스트랩 서버를 위한 부트스트랩 정보로 구분될 수 있다.

M2M 클라이언트는 부트스트랩 시퀀스 이후에 M2M 서버를 위한 부트스트랩 정보(예컨대 M2M 서버와의 연결을 위해 필요한 정보)를 가질 수 있다. 또한, M2M 부트스트랩 서버를 위한 부트스트랩 정보(예컨대 M2M 부트스트랩 서버와의 연결을 위해 필요한 정보)를 가질 수 있다. 상기 M2M 서버를 위한 부트스트랩 정보는 M2M 서버에 등록 및 접속하기 위해 M2M 클라이언트를 위해 사용된다.

M2M 서버를 위한 부트스트랩 정보는 적어도, "부트스트랩 서버" 리소스가 "false" 로 설정된 M2M 서버 보안 객체 인스턴스를 포함할 수 있다. M2M 서버를 위한 부트스트랩 정보는 다른 객체 인스턴스들을 포함할 수 있다.

M2M 클라이언트는 각각의 M2M 서버를 위한 부트스트랩 정보의 집합을 포함한 둘 이상의 M2M 서버들을 사용하도록 구성될 수 있다. M2M 부트스트랩 서버를 위한 부트스트랩 정보는 M2M 서버를 위한 부트스트랩 정보를 획득하기 위해 M2M 부트스트랩 정보에 접속하기 위해 M2M 클라이언트에 의해 사용될 수 있다. 상기 M2M 부트스트랩 서버를 위한 부트스트랩 정보는 "부트스트랩 서버" 리소스가 "true" 로 설정된 M2M 서버 보안 객체 인스턴스일 수 있다.

부트스트랩 정보는 다음과 같이 분류될 수 있다.

[표 22]

M2M 클라이언트는 부트스트랩 인터페이스를 통해 전송된 부트스트랩 정보를 인증 절차(접근 제어) 없이 수락할 수 있다.

상기 부트스트랩 인터페이스는 M2M 클라이언트를 선택적으로 설정하여, 상기 M2M 클라이언트가 성공적으로 M2M 서버와 등록 또는 M2M 부트스트랩 서버와 연결하도록 한다. 클라이언트 부트스트랩 동작 명령은 M2M 부트스트랩 서버의 /bs 경로로, 질의(query) 스트링(string) 파라미터는 M2M 클라이언트 식별자 포함하여 CoAP POST 요청을 전송함으로써 수행된다.

클라이언트 개시 부트스트랩에서, M2M 부트스트랩 서버가 부트스트랩 요청(Request Bootstrap) 동작 명령을 수신하면, 상기 부트스트랩 서버는 쓰기(Write) 및/또는 삭제(Delete) 동작 명령을 수행할 수 있다. 서버 개시 부트스트랩에서, 부트스트랩 서버는 쓰기(Write) 동작 명령을 수행할 수 있다. 쓰기 및/또는 삭제 동작 명령은 객체 인스턴스 또는 리소스를 타깃할 수 있다. 상기 쓰기 및 삭제 동작 명령은 복수 회(multiple times) 전송될 수 있다. 오직 부트스트랩 인터페이스에서, 삭제 동작 명령은, M2M 부트스트랩 서버가 M2M 클라이언트로 쓰기 동작 명령(들)을 전송하기 전에 M2M 클라이언트를 초기화를 위해 M2M 클라이언트에서 M2M 부트스트랩 서버 계정을 제외한 존재하는 모든 객체 인스턴스들을 삭제하기 위해 "/" URI 를 타깃할 수 있다. 장치 관리 및 서비스 인에이블 인터페이스에서의 쓰기 동작 명령과 달리, 상기 M2M 클라이언트는 타깃하는 객체 인스턴스 또는 리소스의 존재와 관계없이 상기 동작 명령의 페이로드(즉, 상기 쓰기 동작 명령으로 기록하고자(쓰고자) 하는 특정 값)를 기록할 수 있다. 다음은 부트스트랩 인터페이스에서의 동작 명령을 나타낸다. 상기 쓰기 동작 명령은 타 동작 명령(예컨대, 생성)으로 대체 가능하다.

[표 23]

부트스트랩 시퀀스

M2M 클라이언트는 M2M 기기를 부트스트랩을 시도하려고 할 때 아래의 부트스트랩 시퀀스(단계)를 따라야 한다. (The LWM2M Client MUST follow the procedure specified as below when attempting to bootstrap a LWM2M Device:)

M2M 기기가 스마트카드가 있으면, M2M 클라이언트는 부트스트랩 정보를 스마트카드로부터 얻으려고 시도한다. (If the LWM2M Device has Smartcard, the LWM2M Client tries to obtain Bootstrap Information from the Smartcard using the Bootstrap from Smartcard mode.)

M2M 클라이언트가 스마트카드로부터 설정되지 않는다면, M2M 클라이언트는 제조자 부트스트랩(factory bootstrap) 모드로 부트스트랩 정보를 얻으려고 시도해 본다. (If the LWM2M Client is not configured using the Bootstrap from Smartcard mode, the LWM2M Client tries to obtain the Bootstrap Information by using Factory Bootstrap mode.)

M2M 클라이언트가 이전 단계들을 통해 M2M 서버 객체 인스턴스를 가지고 있다면, M2M 클라이언트는 해당 M2M 서버 객체 인스턴스에 해당하는 M2M 서버에 등록을 요청한다. (If the LWM2M Client has any LWM2M Server Object Instances from the previous steps, the LWM2M Client tries to register to the LWM2M Server(s) configured in the LWM2M Server Object Instance(s).)

M2M 클라이언트가 모든 M2M 서버에 등록을 실패할 경우 또는 클라이언트가 M2M 서버 객체 인스턴스를 가지고 있지 않을 경우, M2M 클라이언트는 서버 개시 부트스트랩을 특정 자원(ClientHoldOffTim)이 명시한 시간만큼 기다렸다가, 서버 개시 부트스트랩이 상기 시간 동안 발생하지 않으면 M2M 클라이언트는 클라이언트 개시 부트스트랩을 통해 부트스트랩 정보를 얻는 것을 시도한다. (If LWM2M Client fails to register to all the LWM2M Servers or the Client doesn' t have any LWM2M Server Object Instances, and the LWM2M Client hasn' t received a Server Initiated Bootstrap within the ClientHoldOffTime, the LWM2M Client performs the Client Initiated Bootstrap.)

클라이언트 개시 부트스트랩

M2M 서버 계정이 M2M 클라이언트 내에 설정되지 않거나(존재하지 않거나) M2M 서버와의 "등록" 동작 명령을 수행하기 위한 시도가 실패되는 경우가 있을 수 있다. 이러한 경우, M2M 클라이언트는 M2M 부트스트랩 서버로부터 부트스트랩 정보를 가져오기(retrieve)하기 위해 클라이언트-개시 부트스트랩 모드를 사용할 수 있다. 상기 클라이언트-개시 부트스트랩 모드는 M2M 부트스트랩 서버를 가리키는(참조하는) M2M 보안 서버 객체 인스턴스가 M2M 클라이언트에 설정된(존재하는) 것을 요구할 수 있다.

도 4 는본 발명의 일 실시예에 따른 클라이언트-개시 부트스트랩 모드의 동작을 도시한다. M2M 클라이언트는 미리-제공된(pre-provisioned) M2M 부트스트랩 서버 URI 로 "부트스트랩 요청" 동작 명령을 전송할 수 있다(S410). 상기 부트스트랩을 요청하는 경우, 상기 M2M 클라이언트는 상기 M2M 부트스트랩 서버로 하여금 상기 M2M 클라이언트를 위한 적절한 부트스트랩 정보를 제공하도록 하기 위해 파라미터로서 상기 M2M 클라이언트의 "엔드포인트(endpoint) 클라이언트 이름" (M2M 클라이언트 식별자)을 전송할 수 있다.

상기 M2M 부트스트랩 서버는 "쓰기" 및/또는 "삭제" 동작 명령을 사용하여 상기 M2M 클라이언트에 부트스트랩 정보를 설정(configure 또는 set)할 수 있다(S420).

상기 클라이언트-개시 부트스트랩은 최초 부트스트랩 이후 부트스트랩 정보를 갱신하기 위해서 상기 M2M 클라이언트의 상기 부트스트랩 정보의 몇몇 리소스들을 설정하는데 사용될 수 있다. 이 예에서, 모든 부트스트랩 정보는 선택사항(optional)로, 전달될 수도 있고 전달되지 않을 수도 있다.

서버 개시 부트스트랩

서버-개시 부트스트랩은 M2M 클라이언트가 M2M 부트스트랩 서버로 부트스트랩 요청을 전송하지 않고, M2M 부트스트랩 서버가 M2M 클라이언트에 부트스트랩 정보를 설정할 수 있다. 상기 M2M 클라이언트가 상기 M2M 부트스트랩 서버로 "부트스트랩 요청" 동작 명령을 개시하지 않기 때문에, 상기 M2M 부트스트랩 서버는 상기 M2M 클라이언트가 상기 M2M 부트스트랩 서버에 의해 설정되기 전에 M2M 장치 또는 M2M 클라이언트가 부트스트랩할 준비가 되었는지 여부를 알 필요가 있다. 상기 M2M 부트스트랩 서버가 이러한 지식을 획득하기 위한 메커니즘은 본 발명에서 다루진 않는다. 일 예로 M2M 장치가 네트워크 제공자의 네트워크에 접속하는 경우, 네트워크 제공자의 네트워크가 M2M 부트스트랩 서버에게 M2M 장치의 부트스트랩 준비여부를 알려주는 시나리오가 가능하다.

상기 M2M 부트스트랩 서버가 상기 M2M 장치가 상기 부트스트랩 정보를 수신할 준비가 되었음을 통지받으면, 상기 M2M 부트스트랩 서버는 "쓰기" 및/또는 "삭제" 동작 명령을 사용하여 상기 부트스트랩 정보를 상기 M2M 클라이언트를 설정할 수 있다.

도 5 는 본 발명의 일 실시예에 따른 서버-개시 부트스트랩 모드의 동작을 도시한다. M2M 부트스트랩 서버는 "쓰기" 및/또는 "삭제" 동작 명령을 사용하여 상기 M2M 클라이언트에서 상기 부트스트랩 정보를 설정할 수 있다(S510).

상기 서버-개시 부트스트랩은 최초 부트스트랩 이후 부트스트랩 정보를 업데이트하기 위해서 상기 M2M 클라이언트의 상기 부트스트랩 정보의 몇몇 리소스들을 설정하기 위해 사용될 수 있다. 이 예에서, 모든 부트스트랩 정보는 선택사항(optional)로, 전달될 수도 있고 전달되지 않을 수도 있다.

부트스트랩 정보(Bootstrap Information)

부트스트랩 정보는 M2M 부트스트랩 서버를 통해 전달되는 정보로, M2M 클라이언트가 M2M 서버 또는 M2M 부트스트랩 서버와 연결/통신하기 위해 필요한 정보를 의미한다. 부트스트랩 정보는 부트스트랩 인터페이스를 통해 전달될 수 있으며, 부트스트랩 시퀀스 이전에 이용가능하거나 상기 부트스트랩 시퀀스의 결과로서 획득될 수 있다.

부트스트랩 정보는 M2M 서버 부트스트랩 정보(M2M Server Bootstrap Information)와 M2M 부트스트랩 서버 부트스트랩 정보(M2M Bootstrap Server Bootstrap Information)로 분류되며, 상기 M2M 서버 부트스트랩 정보는 M2M 서버 계정과 선택적으로 추가적인 객체 인스턴스들(예컨데, 접근 제어(access control) 객체 인스턴스, 네트워크 연결 정보(connectivity) 객체 인스턴스을 포함하고, 상기 M2M 부트스트랩 서버 부트스트랩 정보는 M2M 부트스트랩 서버 계정을 포함한다.

M2M 서버 계정은 M2M 서버에 연결하기 위해 필요한 정보와 서버 관련 기능, 서버 관련 기능 정보가 저장될 수 있다. M2M 부트스트랩 서버 계정은 M2M 부트스트랩 서버에 연결하기 위해 필요한 정보가 저장된다.

M2M 클라이언트는 M2M 서버로부터의 보안 요건(예컨대, 데이터 기밀성(confidentiality), 데이터 무결성(data integrity), 소스 인증(source authentication))이 만족된 부트스트랩 메시지 또는 부트스트랩 인터페이스를 통해 제공되는 모든 정보를 전부 신뢰하고 받아들인다.

서버 정보

M2M 클라이언트와 M2M 서버가 통신을 하려면 M2M 서버와 통신하기 위한 기본적인 정보들과 부가적인 정보들(부트스트랩을 통해 전달되는 정보)이 M2M 부트스트랩 서버를 통해 제공되어야 한다. 이러한 정보의 예로는 서버 ID, 서버 주소(예컨대, IP, URI), 보안 자격(security credential), 네트워크 베어러 정보(network bearer information), 선호되는 네트워크 베어러 정보(preferred network bearer information), M2M 서버가 생성가능한 리소스(예컨대, 관리 객체, 객체) 등이 있다. 특정 M2M 서버 (관련) 부트스트랩 정보는 상기 서버 정보를 의미할 수 있다.

접근 제어 정보(Access Control Information)

M2M 서버가 M2M 클라이언트의 특정 리소스에 접근하려면 해당 리소스에 대한 접근 권한이 있어야 한다. 부트스트랩을 통해서 이러한 접근 제어 관련된 정보(즉, ACL(Access Control List) 또는 ACL 을 포함한 리소스)들 또한 변경 가능하다. 해당 정보는 부트스트랩을 통해 제공될 수도 있고 아닐 수도 있다.

서버 계정 삭제를 위한 접근 권한 설정(Access Right Configuration for the Server Account Deletion)

M2M 서버 계정이 삭제될 경우, 해당 M2M 클라이언트의 ACL 로부터 해당 M2M 서버의 접근 권한 또한 삭제되어야 한다. 이 때, 해당 M2M 서버가 특정 자원(예컨대, 객체)의 유일한 접근 권한 소유자인 경우 앞서 설명한 것처럼 몇몇 문제점이 존재한다. 따라서, 상기 M2M 클라이언트의 ACL 에 삭제될 M2M 서버 이외 타 M2M 서버에 대한 접근 권한이 존재할 경우 다음과 같은 프로시저가 가능하다.

A) 서버 계정 삭제의 차단

M2M 서버 계정이 삭제될 시, 해당 삭제 요청이 되지 않도록 막을 수 있다. 이를 위해, 상기 삭제 요청을 수신한 M2M 클라이언트는 해당 M2M 서버가 유일한 접근 권한 소유자라는 메시지와 함께 에러 응답을 보낼 수도 있다. 이럴 경우 삭제를 요청한 M2M 서버(즉, 부트스트랩 M2M 서버)는 접근 권한 소유자를 다른 M2M 서버로 변경 또는 해당 접근 권한(ACL)을 삭제 후 다시 상기 M2M 서버의 계정 삭제를 요청하여 상기 M2M 클라이언트는 해당 M2M 서버 계정을 삭제할 수 있다.

B) 접근 권한 소유자 변경 (Access Right Owner Change)

M2M 서버 계정이 삭제될 시, M2M 클라이언트는 자체적으로 접근 권한 소유자를 변경할 수 있다. 변경하는 방법은,

B-1)일반적으로 ACL 중 가장 높은 접근 권한을 갖는 M2M 서버를 새로운 접근 권한 소유자로 설정한다. "가장 높은" 접근 권한의 의미는 각종 접근 권한 중 해당 리소스 또는 그와 관련된 다른 리소스에 대한 영향을 미치는 범위가 가장 넓은 접근 권한을 의미하며, 예컨대 "읽기" 에 대한 접근 권한보다 "쓰기" 에 대한 접근 권한이 좀더 높은 접근 권한이다.

이 때, 각 동작 명령에 대한 접근 권한마다 특정 값을 부여하여 해당 값의 합(sum)이 가장 높은 M2M 서버를 새로운 접근 권한 소유자로 변경할 수 있다. 예컨대, 예를 들어 M2M 서버 1 은 쓰기, 읽기에 대한 접근 권한을 갖고, M2M 서버 2 는 쓰기, 실행에 대한 접근 권한을 갖는 경우 M2M 서버 1 이 새로운 접근 권한 소유자가 된다(명령마다 부여된 값- 쓰기: 4, 읽기: 2, 실행: 1).

아울러, 상기 각 동작 명령에 대한 접근 권한에 부여되는 값은 일 예이며, 모든 동작 명령에 대한 접근 권한에 동일한 값(예컨대, 1)을 부여할 수 있다. 이는 곧 가장 많은 종류의 동작 명령에 대한 접근 권한을 갖는 M2M 서버가 새로운 접근 권한 소유자로 지정될 수 있음을 의미한다.

B-2) 모든 M2M 서버를 접근 권한 소유자로 지정한다. 이 때, 해당 M2M 클라이언트에 등록된 모든 M2M 서버에게 접근 권한 소유자를 부여할 수도 있으며, 또는 해당 리소스에 대해 접근 권한이 있는 M2M 서버에게만 접근 권한 소유자를 부여할 수 있다. 예를 들어, ACL 에 명시되지 않은 서버들을 위한 디폴트(default) ACL 엔트리만 남아있을 경우 이러한 방법은 유용하다.

B-3) 접근 권한 객체 인스턴스 내 첫 번째 M2M 서버에게 접근 권한 소유자를 부여한다.

B-4) 접근 권한 소유자를 빈 채로 남겨두며, 해당 리소스에 처음 접근하는 M2M 서버에게 접근 권한 소유자를 부여한다.

C) 리소스 삭제(Resource Deletion)

접근 권한 소유자인 M2M 서버의 계정이 삭제될 시, 상기 M2M 서버가 접근 권한 소유자로 지정되어 있는 리소스(들)(예컨대, 특정 접근 제어 객체 인스턴스)가 삭제될 수 있다. 즉, 리소스(들)의 주인 역할을 하는 M2M 서버가 삭제됨으로, 해당 리소스까지 삭제를 하는 것이다. 이 때, 상기 리소스(들)과 연계된 특정 리소스와 상기 특정 리소스의 접근 권한 값 또한 삭제한다.

D) 새로운 접근 권한 소유자의 지정

삭제되는 M2M 서버가 자신이 접근 권한 소유자인 리소스에 대해 권한 위임을 부탁하는 명령을 전송할 수 있다. 즉, 서버 계정 삭제를 위한 동작 명령이 오기 이전에 특정 M2M 서버(해당 접근 권한을 위임해 주고자 하는 M2M 서버)가 설정되어 있어, 삭제된 M2M 서버가 접근 권한 소유자였던 리소스들의 접근 권한 소유자로써 상기 특정 M2M 서버를 추가하는 것이다.

또는, 서버 계정 삭제를 위한 동작 명령 내에 해당 서버 계정의 삭제 이후의 접근 권한 소유자(즉, 다른 M2M 서버의 ID 등)를 포함시켜, 상기 서버의 계정이 삭제될 시 삭제된 서버가 접근 권한 소유자인 리소스(들)에 대해 상기 삭제를 위한 동작 명령 안에 포함되어 있는 서버가 새로운 접근 권한 소유자가 되도록 지정될 수 있다.

리소스 삭제(Resource Deletion)

특정 M2M 서버의 계정이 삭제될 시, 상기 특정 M2M 서버를 ACL 로부터 삭제하게 되는데, 특정 리소스(예컨대, 객체)에 대해 상기 삭제될 M2M 서버가 접근 권한 소유자이며, ACL 에 존재하는 유일한 서버일 경우에는 ACL 이 포함된 접근 제어 객체 인스턴스는 물론, 해당 접근 제어 객체 인스턴스와 연계된 특정 객체 인스턴스 또한 삭제될 수 있다.

특정 M2M 서버의 계정이 삭제되면, 클라이언트는 상기 특정 M2M 서버가 이전에 특정 이벤트에 대한 보고를 위해 설정된 값을 해지할 수 있다.

또한, 위에 설명한 접근 권한 설정, 리소스 삭제, 보고 해지 등과 같은 작업은 서버에게 알릴 수 있다.

관찰을 위한 접근 제어 (Access Control for Observation)

M2M 서버는 M2M 클라이언트에 특정 리소스 또는 리소스 그룹(예컨대, 객체 인스턴스)의 변화에 대해 보고를 받기 원할 수 있다. 이러한 보고를 위해 앞서 설명한 "관찰" 기능을 통해 해당 리소스 또는 리소스 그룹의 변화를 확인할 수 있다. 그러나, 상기 "관찰" 기능을 등록함에 있어 아무런 제약이 없기에 해당 리소스에 대해 읽은( "읽기" 동작 명령에 의한) 것과 동일한 효과를 낼 수 있기 때문에, 상기 "읽기" 동작 명령에 대한 접근 권한이 없는 M2M 서버가 해당 리소스의 값을 읽을 수 있다.

이러한 점을 방지하기 위해 관찰 기능을 등록 시, 그에 따른 보고 시 접근 제어 기법을 소개한다.

이러한 기법은 다른 동작 명령에도 적용이 가능한데, 즉 동일한 효과(또는 결과)를 내는 동작 명령들의 경우, 두 동작 명령에 대한 접근 권한을 따로 두지 않고, 하나의 접근 권한을 통해 접근 제어를 수행할 수 있다. 다음은 그에 대한 일 예를 나타낸다.

[표 24]

- 관찰 등록(Observation Registration)

도 6 는 본 발명의 일 실시예에 따른 관찰 등록의 순서도를 도시한다.

서버(100)는 클라이언트(200)로 특정 리소스에 대한 관찰 등록을 요청할 수 있다(S610). 이에, 상기 클라이언트는 해당 리소스에 대해 M2M 서버가 해당 리소스를 읽을 수 있는 권한(예컨대, "읽기" 동작 명령에 대한 접근 권한)이 있는지 확인할 수 있다(S620). 상기 권한이 있다면, 상기 클라이언트는 해당 서버 ID 와 해당 리소스를 저장하고(S630-1), 상기 관찰 등록이 성공적으로 처리되었음을 상기 서버로 응답할 수 있다(S640). 그 후, 해당 리소스가 변경될 경우 보고 프로세스로 넘어간다.

그러나, 상기 권한이 없다면 등록은 이루어지지 않으며, 상기 클라이언트는 상기 관찰 등록이 실패되었음을 상기 서버로 응답할 수 있다(S630-2).

인증을 수행하는 범위를 벗어나는 리소스들에 대해서도 관찰을 수행할 수 있는데, 예컨대 M2M 서버의 관찰 동작 명령이 객체 ID 만을 타깃하는 경우에, 상기 객체 ID 가 지시하는 객체와 연관된 객체 인스턴스가 복수 개 존재하고 상기 M2M 서버는 적어도 하나의 객체 인스턴스에 대한 "읽기" 권한이 없을 수 있다. 이때는 두 가지의 방법이 존재한다.

1. 관찰 등록 시에는 인증을 수행하지 않고 무조건 수락하도록 설정될 수 있다. 이 경우, 객체 인스턴스들 중에서 인증(해당 M2M 서버가 읽기 권한이 있는지)이 성공된 객체 인스턴스들에 대해서만 보고가 수행될 수 있다. 또는, 인증이 성공된 객체 인스턴스들을 개별적으로 취급하여 각각의 인증이 성공된 객체 인스턴스들 중 하나의 객체 인스턴스에 변경이 발생 시 해당 M2M 서버가 변경이 발생한 객체 인스턴스에 대해 인증이 성공시(즉, 해당 서버가 해당 객체 인스턴스에 대해 "읽기" 권한이 존재할 시) 하나의 객체 인스턴스(즉, 개별 객체 인스턴스)에 대한 보고를 수행할 수 있다.

2. 관찰 등록 시에 모든 객체 인스턴스마다 인증을 수행하고, 인증이 성공된 객체 인스턴스들에 대해서만 관찰을 수행할 수 있다. 이 경우 관찰 보고시에는 등록 시에 인증이 성공된 객체 인스턴스들 전체에 대해 인증(해당 M2M 서버가 읽기 동작 명령에 대한 접근 권한이 있는지 여부로 판단)이 성공해야만이 보고될 수 있으며, 또는 등록 시에 인증이 성공된 객체 인스턴스들 중에서 보고 시에 인증(해당 M2M 서버가 읽기 동작 명령에 대한 접근 권한이 있는지 여부로 판단)이 성공된 객체 인스턴스들만에 대해서 보고가 수행될 수 있다. 또는, 등록 시에 인증이 성공된 객체 인스턴스들을 개별적으로 취급하여 각각의 성공된 객체 인스턴스에 변경이 발생 시 해당 M2M 서버가 변경이 발생한 객체 인스턴스에 대해 인증(해당 M2M 서버가 읽기 동작 명령에 대한 접근 권한이 있는지 여부로 판단) 성공시 보고가 수행될 수 있다.

- 관찰 등록 보고(Observation Reporting)

도 7 은 본 발명의 일 실시예에 따른 관찰 보고의 순서도를 도시한다.

관찰 기능에 대한 등록을 할 시점과 보고를 할 시점 사이에 M2M 서버의 접근 권한의 변경이 있을 수 있다. 따라서, 상기 관찰 기능에 대한 보고를 할 시점에도(즉, 관찰 보고에 대상의 리소스에 대한 변경 발생시에) M2M 클라이언트는 M2M 서버가 해당 리소스에 "읽기" 접근 권한을 갖고 있는지 여부를 확인할 수 있다(S720). 상기 "읽기" 접근 권한을 갖고 있다면, 상기 M2M 클라이언트는 해당 리소스에 대한 보고(통지)를 수행할 수 있다(S730-1). 상기 "읽기" 접근 권한이 없으면, 상기 M2M 클라이언트는 자체적으로 관찰 취소하고(아울러, 해당 관찰 기능 설정을 삭제할 수 있음) 이를 M2M 서버에게 알릴 수 있다(S730-2).

한편, 상기 관찰에 대한 보고는 앞서 설명한 정보 보고 인터페이스를 통한 통지(Notify) 동작 명령에 수행될 수 있으며, 이에 대해 예를 들어 좀더 자세히 설명하도록 한다.

도 8 은 본 발명의 일 실시예에 따른 관찰 및 그에 따른 통지에 관한 순서도를 도시한다.

M2M 서버는 M2M 클라이언트 내에서 비주기적으로 갱신되는 온도에 대하여 관찰을 요청한다.

좀더 상세히는, 상기 M2M 서버는 상기 온도와 관련된 리소스에 대하여 최소 주기 = 10 초 그리고 최대 주기 =60 초가 설정된 관찰을 요청할 수 있다. 이는 앞서 설명한 것처럼, "장치 관리 및 서비스 인에이블먼트 인터페이스" 를 통한 "쓰기 속성" 동작 명령과 "정보 보고 인터페이스" 를 통한 "관찰" 동작 명령을 통해 수행될 수 있다. 구체적으로, 상기 "통지" 의 구체적인 설정 값을 위한 파라미터 설정(즉, 최소 주기 및 최대 주기)은 "쓰기 속성" 동작 명령을 통해 수행되며(S810), 이에 대한 응답으로, M2M 클라이언트는 상기 "쓰기 속성" 동작 명령에 대한 결과(예컨대, 성공)을 응답할 수 있다(S820).

그리고나서, 상기 M2M 서버는 상기 M2M 클라이언트로 상기 온도와 관련된 리소스에 대한 관찰을 요청할 수 있다(S830). 이에 대한 응답으로, M2M 클라이언트는 상기 "관찰" 동작 명령에 대한 결과(예컨대, 성공)을 응답할 수 있다(S840).

상기 M2M 클라이언트는 상기 M2M 서버로 "통지" 를 전송하기 전에, 그 전에 상기 리소스의 값이 변경되었더라도 적어도 10 초를 기다릴 것이고, 10 초 경과 후 상기 M2M 서버로 상기 리소스에 대한 값을 통지할 수 있다(S850).

또한, 상기 통지가 있고 나서 40 초 이후에 상기 리소스의 값이 변경되면, 상기 M2M 클라이언트는 상기 M2M 서버로 상기 리소스에 대한 값을 통지할 수 있다(S860).

또한, 그 이후 상기 리소스의 값이 변경되지 않았더라도 60 초가 경과하기 전에, 상기 M2M 클라이언트는 상기 "통지" 를 전송해야한다(S870).

즉, 상기 통지에 대한 설정(즉, 최소 주기 및 최대 주기)에 따라, 상기 통지가 이루어지는 시점이 제한되며, 좀더 상세히는 상기 최소 주기 이후에 그리고 상기 최대 주기 이전에 1 회는 반드시 통지가 있게 된다.

상기 설정에 따라, 상기 "통지" 는 상기 리소스에 변경이 발생하면 10 내지 60 초 내에 임의의 시점에서 전송될 수 있다.

아울러, 상기 관찰에 대한 취소가 가능하다. 이는 앞서 설명한 "관찰 취소" 동작 명령에 의해 가능하다.

"관찰 취소" 동작 명령은 M2M 서버로부터 M2M 클라이언트로 객체 인스턴스 또는 리소스에 대한 관찰 관계를 종료하기 위해 전송된다. 상기 동작 명령은 M2M 레이어에서 어떠한 파라미터를 포함하지 않는다. 상기 "관찰 취소" 동작 명령은 "통지" 동작 명령의 응답으로 사용되어야 한다.

이는 관찰 취소를 위해 M2M 서버를 위한 두 가지 방법을 가능하게 한다.

- "관찰 취소" 동작 명령 전송

이 옵션의 제한은 만약 M2M 서버가 상기 M2M 서버가 더 이상 관심이 없는 "통지" 동작을 수신하면, 상기 M2M 서버는 상기 "통지" 동작에 응답으로 "관찰 취소" 를 전송할 수 있다.

- 취소 파라미터를 포함한 "쓰기 속성" 동작 명령 전송

이 옵션은 제한이 없다. 만약 M2M 서버가 M2M 클라이언트 내 특정 URI 로 취소 파라미터를 포함한 "쓰기 속성" 동작 명령을 전송하면, 상기 M2M 클라이언트는 특정된 URI 를 위한 관찰을 스스로 취소할 수 있다.

접속 모드(Connection Mode) 설정

M2M 서버는 접속 모드를 설정할 수 있다. 이러한 설정은 디바이스의 슬립(Sleep)을 길게 가져가 배터리의 전력 소모를 줄이고자 하는 의도를 포함하며, 설정에 따라 더 안정적인 통신을 유지하고자 할 때 사용 가능하다.

- 상시 온라인(Always Online)

M2M 서버는 설정을 통해 M2M 클라이언트의 상태를 지속적으로 온라인으로 유지할 수 있다. 이러한 상태는 M2M 서버가 언제든지 필요 시 명령(관리 또는 동작 명령)을 M2M 클라이언트에게 가능하게 한다.

- 이벤트 기반 온라인(Event Driven Online)

M2M 서버는 설정을 통해 M2M 클라이언트가 이벤트를 통해 온라인 상태가 되게 할 수 있다. 이러한 경우 이벤트 발생 시 M2M 클라이언트는 자신이 온라인임을 알리는 메시지를 전송하고, 특정 시간 동안 M2M 서버의 명령(관리 또는 동작 명령)을 기다리거나 또는 명령을 기다리는 동안 M2M 서버에서 특정 명령을 지속적으로 전송할 경우, 마지막 명령을 기점으로 특정 시간을 기다릴 수 있다.

- 주기적 온라인(Periodic Online)

M2M 서버는 설정을 통해 M2M 클라이언트가 주기적으로 온라인 상태를 유지하도록 할 수 있다. M2M 서버에 의해 또는 미리 설정된 주기가 설정되어 있고, 해당 주기가 되었을 시 M2M 클라이언트는 M2M 서버에 자신이 온라인 상태임을 알리는 메시지를 전송하여 특정 시간 동안 M2M 서버의 명령(관리 또는 동작 명령)을 기다리거나 또는 명령을 기다리는 동안 상기 M2M 서버에서 특정 명령을 지속적으로 전송할 경우, 마지막 명령을 기점으로 특정 시간을 기다릴 수 있다. 해당 주기는 M2M 클라이언트에 발생되는 이벤트와는 별개로 발생되며, 해당 주기가 되었을 시 오프라인일 때 모아둔 보고 정보들을 M2M 서버에 전송할 수 있다.

또는, M2M 서버는 M2M 클라이언트가 온라인이 되는 시점을 결정할 수 있다. 예를 들어, 매일 오후 3 시 5 분이라고 설정되어 있다면, 해당 시간에 M2M 클라이언트는 갱신 메시지를 전송하여, M2M 서버가 특정 동작 명령을 수행할 수 있도록 한다. 해당 설정에는 타임아웃(Timeout) 이 존재할 수 있는데, 상기 타임아웃이 존재할 경우, 해당 시간까지 M2M 클라이언트는 M2M 서버와 온라인 상태를 유지한다.

- 모드 변경 고려(Mode Change Considerations)

이벤트 기반 온라인 또는 주기적 온라인의 경우, M2M 서버는 M2M 클라이언트와의 안정적인 통신이 불가능하다. 지속적인 통신이 필요한 경우(예컨대, 펌웨어 업데이트 등), M2M 서버는 해당 M2M 클라이언트가 임시적으로 온라인 상태일 시 상시 온라인 모드로의 변경 명령을 전송하고, 지속적 통신이 종료될 경우 다시 모드 변경을 통해 기존의 모드로 변경 또는 다른 모드로 변경하도록 할 수 있다. 또는, 상시 온라인 모드가 지속되게끔 할 수도 있다.

- 이벤트 레벨 고려(Event Level Considerations)

이벤트에는 레벨이 존재할 수 있는데, 레벨은 크게 슬립 모드(또는 연결 해제 상태)에서 온라인 모드로 변경이 필요한지 여부에 따라 2 개로 나눌 수 있다.

온라인 모드로 변경이 필요한 정도의 이벤트일 경우에는 해당 시점에 바로 M2M 클라이언트는 온라인 상태가 되어 보고를 수행하며, 온라인 모드로 변경이 필요한 정도의 이벤트가 아닐 경우, 타 이유로 인해 온라인 상태가 되는 시점에 해당 이벤트를 보고할 수 있다.

도 9 는 본 발명의 일 실시예에 따른 동작의 순서도를 도시한다.

단말은 제 1 서버로부터 특정 서버의 계정을 삭제하기 위한 동작 명령(예컨대, "삭제" 동작 명령)을 수신할 수 있다(S910). 본 발명에서 서버의 계정(또는 서버 계정)은 객체 인스턴스의 이름들에 제한되지 않으며, 특정 서버에 관한 정보의 집합을 의미한다. 좀더 구체적으로, 상기 서버의 계정(또는 서버 계정)은 위에서 설명한 서버 객체 (인스턴스) 및 보안 객체 (인스턴스)를 포함하는 포괄적인 개념이며, 추가적으로 상기 보안 객체 (인스턴스)에서 "부트스트랩 서버" 리소스가 false 인 것을 의미한다.

상기 삭제하기 위한 동작 명령은 부트스트랩 인터페이스를 통해 수신될 수 있으며, 또한 이에 따라 상기 제 1 서버는 부트스트랩 서버일 수 있다.

상기 단말은 상기 특정 서버와 연관된 객체 인스턴스 중에 상기 특정 서버만이 접근할 수 있는 객체 인스턴스가 있는지 여부를 판단할 수 있다(S920).

상기 특정 서버와 연관된 객체 인스턴스 중에 상기 특정 서버만이 접근할 수 있는 객체 인스턴스(들)가 있으면, 상기 단말은 그 객체 인스턴스(들)와 그와 연관된 접근 객체 인스턴스(들)를 삭제할 수 있다(S930). 즉, 상기 단말은 상기 특정 서버의 접근 권한 정보를 삭제할 수 있다. 이는 해당 객체 인스턴스가 다른 서버와 어떠한 연관도 없으므로, 해당 객체 인스턴스 및 그와 연관된 접근 객체 인스턴스는 상기 특정 서버의 계정이 삭제되면 어떠한 서버에 의해서도 접근이 가능하지 않으므로 삭제하는 것이 리소스 활용 및 관리 관점에서 바람직하기 때문이다.

한편, 상기 특정 서버와 연관된 객체 인스턴스 중에 상기 특정 서버를 포함한 복수의 서버들이 접근할 수 있는 객체 인스턴스(들)가 있으면, 상기 단말은 그 객체 인스턴스(들)와 연관된 접근 객체 인스턴스(들) 내에서 상기 특정 서버와 관련된 리소스, 예컨대 앞서 설명한 접근 제어 객체 인스턴스의 ACL 엔트리를 삭제할 수 있다(S931). 이는 S930 과 달리, 다른 서버가 상기 객체 인스턴스에 접근할 수 있으므로 상기 특정 서버와 관련된 리소스만을 삭제함이 바람직하기 때문이다.

아울러, 상기 단말은 상기 특정 서버가 상기 접근 제어 객체 인스턴스의 접근 제어 소유자인지 여부를 판단할 수 있다(S932).

상기 특정 서버가 상기 접근 제어 객체 인스턴스의 접근 제어 소유자이면, 상기 단말은 다음과 같은 방식을 사용하여 상기 접근 제어 객체 인스턴스를 위한 새로운 접근 제어 소유자를 설정할 수 있다(S933). 이는 해당 접근 제어 객체 인스턴스에 대한 관리자(즉, 접근 제어 소유자)의 부재로 인한 리소스 관리의 불편함 그리고 해당 리소스의 활용 제약을 해소/방지하기 위함이다.

상기 접근 제어 객체 인스턴스에서 지정된(또는 허용된) 각각의 접근 권한 별로 특정 값이 부여된다. 예컨대, "쓰기" 동작 명령에 대한 접근 권한에는 "1" 이, "읽기" 동작 명령에 대한 접근 권한에는 "2" 가 부여될 수 있다. 상기 단말은 각 서버에 대한 상기 값들의 합을 계산하고, 합이 가장 큰 서버를 새로운 접근 제어 소유자로 설정할 수 있다. 만약, 합이 동일한 서버가 둘 이상이면, 상기 단말은 그 중 하나를 선택하여 새로운 접근 제어 소유자로 설정할 수 있다.

상기 특정 서버가 상기 접근 제어 객체 인스턴스의 접근 제어 소유자가 아니면, S933 은 수행되지 않는다.

그리고나서, 단말은 자신이 가지고 있는 모든 객체 인스턴스에 대해 상기 특정 서버가 접근 권한을 갖고 있는지 여부를 확인할 수 있다(S940). 즉, 어떤 동작 명령(들)에 대해 접근 권한이 있는지를 확인할 수 있다. 만약 상기 특정 서버가 어떤 동작 명령(들)에 대한 접근 권한이 있는 객체 인스턴스가 존재한다면, 상기 단말은 S920 으로 돌아가 본 발명의 동작을 반복할 수 있다. 즉, 상기 특정 서버가 접근 권한을 갖고 있는 동작 명령들이 명시된 리소스가 존재하지 않을 때까지 본 발명의 동작이 수행될 수 있다.

상기 특정 서버가 접근 권한을 가지고 있는 동작 명령이 하나도 존재하지 않은 것으로 판단되면, 상기 단말은 상기 특정 서버에 의해 설정된 관찰 동작 설정을 취소할 수 있다(S950). 즉, 상기 단말은 상기 특정 서버가 전송한 관찰 동작 명령을 통해 저장한 설정 정보를 삭제할 수 있다.

그리고나서, 상기 단말은 상기 특정 서버의 계정을 완전히 삭제할 수 있고(S960), 즉 상기 특정 서버의 계정 삭제의 요청은 S910 에서 수신되었지만, 실질적으로 본 단계에서 상기 특정 서버의 계정이 삭제된다. 이는 상기 삭제 명령을 먼저 처리하게 되면 서버 계정 내의 짧은 서버 ID 등의 정보가 삭제되어 접근 제어 객체 인스턴스에서 상기 서버의 짧은 서버 ID 에 기반하여 ACL 엔트리를 삭제해야 하는데 이미 삭제되어 찾을 수 없기 때문에 마지막에 삭제하는 것이다. 또한, 상기 단말은 상기 특정 서버에 대한 "등록 해제(De-register)" 동작명령을 전송할 수 있다(S970).

도 9 와 관련하여 설명한 실시예는 앞서 도 1 내지 도 8 을 참조하여 설명한 내용을 참조할 수 있으며, 이에 따라 당업자는 도 1 내지 도 8 과 관련된 설명(특히, 표들에 기반한)을 참조하여 도 9 와 관련된 실시예를 더 구체적으로 한정할 수도 있을 것이다.

또한, 상기 단말은 도 9 에 도시된 단계 중 일부만을 선택하여 수행할 수 있다.

도 10 은 본 발명의 실시예(들)을 수행하도록 구성된 장치의 블록도를 도시한다. 전송장치(10) 및 수신장치(20)는 정보 및/또는 데이터, 신호, 메시지 등을 나르는 무선 신호를 전송 또는 수신할 수 있는 RF(Radio Frequency) 유닛(13, 23)과, 무선통신 시스템 내 통신과 관련된 각종 정보를 저장하는 메모리(12, 22), 상기 RF 유닛(13, 23) 및 메모리(12, 22)등의 구성요소와 동작적으로 연결되고, 상기 구성요소를 제어하여 해당 장치가 전술한 본 발명의 실시예들 중 적어도 하나를 수행하도록 메모리(12, 22) 및/또는 RF 유닛(13,23)을 제어하도록 구성된 프로세서(11, 21)를 각각 포함한다.

메모리(12, 22)는 프로세서(11, 21)의 처리 및 제어를 위한 프로그램을 저장할 수 있고, 입/출력되는 정보를 임시 저장할 수 있다. 메모리(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)에 의해 구동될 수 있다.

본 발명의 실시예들에 있어서, M2M 서버 또는 M2M 클라이언트, 또는 서버 또는 단말 등은 각각 그들이 설치되어 있거나 탑재되어 있는 장치들, 즉 전송장치(10) 또는 수신장치(20)로 동작할 수 있다.

이와 같은, 수신장치 또는 전송장치로 M2M 서버, M2M 클라이언트, 서버 또는 단말 등의 구체적인 구성은, 도면과 관련하여 전술한 본 발명의 다양한 실시예에서 설명한 사항들이 독립적으로 적용되거나 또는 둘 이상의 실시예가 동시에 적용되도록 구현될 수 있다.

상술한 바와 같이 개시된 본 발명의 바람직한 실시예들에 대한 상세한 설명은 당업자가 본 발명을 구현하고 실시할 수 있도록 제공되었다. 상기에서는 본 발명의 바람직한 실시예들을 참조하여 설명하였지만, 해당 기술 분야의 숙련된 당업자는 하기의 특허 청구의 범위에 기재된 본 발명의 사상 및 영역으로부터 벗어나지 않는 범위 내에서 본 발명을 다양하게 수정 및 변경시킬 수 있음을 이해할 수 있을 것이다. 따라서, 본 발명은 여기에 나타난 실시형태들에 제한되려는 것이 아니라, 여기서 개시된 원리들 및 신규한 특징들과 일치하는 최광의 범위를 부여하려는 것이다.

본 발명은 무선 이동 통신 시스템의 단말기, 기지국, 서버 또는 기타 다른 장비에 사용될 수 있다.

Claims

무선 통신 시스템에서 서버 계정 삭제에 따른 특정 객체 인스턴스의 처리 방법에 있어서, 상기 방법은 단말에 의해 수행되며,
제 1 서버로부터 특정 서버의 계정을 삭제하기 위한 동작 명령을 수신하는 단계;
상기 특정 객체 인스턴스가 상기 특정 서버만이 접근할 수 있는 객체 인스턴스이면, 상기 특정 객체 인스턴스 및 그와 연관된 접근 제어 객체 인스턴스를 삭제하는 단계;
상기 특정 객체 인스턴스가 상기 특정 서버를 포함한 복수의 서버들이 접근할 수 있는 객체 인스턴스이면, 상기 특정 객체 인스턴스와 연관된 접근 제어 객체 인스턴스 내에서 상기 특정 서버의 접근 권한 정보를 삭제하는 단계; 및
상기 특정 서버가 상기 접근 제어 객체 인스턴스의 유일한 접근 제어 소유자이면, 상기 특정 서버를 제외한 상기 복수의 서버들 중 각각이 갖는 접근 권한에 부여된 값의 합이 가장 큰 서버를 상기 접근 제어 소유자로 변경하는 단계를 포함하는, 방법.
제 1 항에 있어서, 상기 변경하는 단계는,
상기 값의 합이 가장 큰 서버가 둘 이상이면, 상기 둘 이상의 서버 중 하나를 선택하고, 상기 선택된 서버를 상기 접근 제어 소유자로 변경하는 단계를 포함하는, 방법.
제 1 항에 있어서, 상기 특정 서버의 계정을 삭제하기 위한 동작 명령은 부트스트랩 인터페이스를 통해 수신되는, 방법.
제 1 항에 있어서, 상기 제 1 서버는 부트스트랩 서버인, 방법.
제 1 항에 있어서, 제 2 서버에 의한 상기 접근 제어 객체 인스턴스의 접근 제어 소유자에 대하여 관찰 동작이 설정되어 있으면, 상기 접근 제어 소유자가 변경 시에 상기 제 2 서버로 상기 변경에 대한 통지를 전송하는 단계를 더 포함하는, 방법.
제 1 항에 있어서, 상기 특정 서버가 전송한 관찰 동작 명령을 통해 저장한 관찰 동작 명령 관련 설정 정보를 삭제하는 단계를 더 포함하는, 방법.
제 1 항에 있어서, 상기 특정 서버의 계정은 상기 특정 서버의 짧은 서버 ID 및 상기 특정 서버와의 통신을 위한 보안 키를 포함하는, 방법.
무선 통신 시스템에서 서버 계정 삭제에 따른 특정 객체 인스턴스의 처리하도록 구성된 단말로서,
무선 주파수(radio frequency; RF) 유닛; 및
상기 RF 유닛을 제어하도록 구성된 프로세서를 포함하되,
상기 프로세서는 제 1 서버로부터 특정 서버의 계정을 삭제하기 위한 동작 명령을 수신하고,
상기 특정 객체 인스턴스가 상기 특정 서버만이 접근할 수 있는 객체 인스턴스이면, 상기 특정 객체 인스턴스 및 그와 연관된 접근 제어 객체 인스턴스를 삭제하며,
상기 특정 객체 인스턴스가 상기 특정 서버를 포함한 복수의 서버들이 접근할 수 있는 객체 인스턴스이면, 상기 특정 객체 인스턴스와 연관된 접근 제어 객체 인스턴스 내에서 상기 특정 서버의 접근 권한 정보를 삭제하며,
상기 특정 서버가 상기 접근 제어 객체 인스턴스의 유일한 접근 제어 소유자이면, 상기 특정 서버를 제외한 상기 복수의 서버들 중 각각이 갖는 접근 권한에 부여된 값의 합이 가장 큰 서버를 상기 접근 제어 소유자로 변경하도록 구성되는, 단말.
제 8 항에 있어서, 상기 프로세서는,
상기 값의 합이 가장 큰 서버가 둘 이상이면, 상기 둘 이상의 서버 중 하나를 선택하고, 상기 선택된 서버를 상기 접근 제어 소유자로 변경하도록 구성되는, 단말.
제 8 항에 있어서, 상기 특정 서버의 계정을 삭제하기 위한 동작 명령은 부트스트랩 인터페이스를 통해 수신되는, 단말.
제 8 항에 있어서, 상기 제 1 서버는 부트스트랩 서버인, 단말.
제 8 항에 있어서, 제 2 서버에 의한 상기 접근 제어 객체 인스턴스의 접근 제어 소유자에 대하여 관찰 동작이 설정되어 있으면, 상기 프로세서는 상기 접근 제어 소유자의 변경 시에 상기 제 2 서버로 상기 변경에 대한 통지를 전송하도록 구성되는, 단말.
제 8 항에 있어서, 상기 프로세서는 상기 특정 서버가 전송한 관찰 동작 명령을 통해 저장한 관찰 동작 명령 관련 설정 정보를 삭제하도록 구성되는, 단말.
제 8 항에 있어서, 상기 특정 서버의 계정은 상기 특정 서버의 짧은 서버 ID 및 상기 특정 서버와의 통신을 위한 보안 키를 포함하는, 단말.