KR102104899B1

KR102104899B1 - 무선 통신 시스템에서 접근 권한 인증을 위한 방법 및 장치

Info

Publication number: KR102104899B1
Application number: KR1020157012921A
Authority: KR
Inventors: 김성윤; 박승규
Original assignee: 엘지전자 주식회사
Priority date: 2012-12-05
Filing date: 2013-12-05
Publication date: 2020-05-29
Also published as: JP5981662B2; US20150296470A1; CN104838618A; US10257800B2; JP2016505942A; WO2014088339A1; EP2930879B1; US9615346B2; CN104838618B; KR20150092108A; US20150350904A1; EP2930879A1; KR20150093663A; WO2014088340A1; EP2930879A4

Abstract

본 발명의 일 실시예에 따른 무선 통신 시스템에서 특정 동작 명령에 대한 권한 인증을 위한 방법에 있어서, 상기 방법은 상기 단말에 의해 수행되며, 제 1 서버로부터 특정 리소스 그룹에 대한 생성 동작 명령의 권한을 인증하는데 사용되는 접근 제어를 위한 리소스 그룹을 생성하기 위한 동작 명령을 수신하는 단계; 상기 접근 제어를 위한 리소스 그룹을 생성하는 단계; 제 2 서버로부터 상기 특정 리소스 그룹을 생성하기 위한 동작 명령을 수신하는 단계; 및 상기 생성된 접근 제어를 위한 리소스 그룹에 기반하여 상기 특정 리소스 그룹을 생성하기 위한 동작 명령을 인증하는 단계를 포함할 수 있다.

Description

무선 통신 시스템에서 접근 권한 인증을 위한 방법 및 장치{METHOD AND APPARATUS FOR AUTHENTICATING ACCESS AUTHORIZATION 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 서버(들)로 특정 기능 또는 특정 리소스에 대한 업데이트, 또는 상기 업데이트를 통해 변경된 정보를 통지하기 위한 방안을 제안하고자 한다.

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

본 발명의 일 실시예에 따른 무선 통신 시스템에서 특정 동작 명령에 대한 권한 인증을 위한 방법에 있어서, 상기 방법은 상기 단말에 의해 수행되며,제 1 서버로부터 특정 리소스 그룹에 대한 생성 동작 명령의 권한을 인증하는데 사용되는 접근 제어를 위한 리소스 그룹을 생성하기 위한 동작 명령을 수신하는 단계; 상기 접근 제어를 위한 리소스 그룹을 생성하는 단계; 제 2 서버로부터 상기 특정 리소스 그룹을 생성하기 위한 동작 명령을 수신하는 단계; 및 상기 생성된 접근 제어를 위한 리소스 그룹에 기반하여 상기 특정 리소스 그룹을 생성하기 위한 동작 명령을 인증하는 단계를 포함할 수 있다.

바람직하게는, 상기 접근 제어를 위한 리소스 그룹은: 상기 특정 리소스 그룹을 지시하는 ID(Identifier) 및 특정 서버의 상기 생성 동작 명령이 허용됨을 지시하는 접근 제어 리스트(Access Control List; ACL) 리소스를 포함할 수 있다.

바람직하게는, 상기 ACL 리소스의 비트들 중 네 번째 최하위 비트가 1 로 설정될 수 있다.

바람직하게는, 상기 접근 제어를 위한 리소스 그룹을 생성하기 위한 동작 명령은 부트스트랩 인터페이스를 통해 수신될 수 있다.

바람직하게는, 상기 특정 리소스 그룹을 생성하기 위한 동작 명령은 장치 관리 및 서비스 인에이블먼트(device management and service enablement) 인터페이스를 통해 수신될 수 있다.

바람직하게는, 상기 특정 리소스 그룹이 생성되면, 상기 방법은 상기 특정 리소스 그룹에 대한 동작 명령(들)의 권한을 인증하는데 사용되는 접근 제어를 위한 리소스 그룹을 생성하는 단계를 포함하고, 상기 생성 동작 명령은 상기 동작 명령(들)에서 제외될 수 있다.

본 발명의 다른 일 실시예에 따른 무선 통신 시스템에서 특정 동작 명령에 대한 권한 인증을 위한 방법에 있어서, 상기 방법은 상기 단말에 의해 수행되며, 서버로부터 특정 동작 명령을 수신하는 단계; 상기 특정 동작 명령이 특정 리소스 그룹을 생성하기 위한 동작 명령이면, 상기 특정 리소스 그룹에 대한 생성 동작 명령의 권한을 인증하는데 사용되는 접근 제어를 위한 리소스 그룹(이하, "제 1 접근 제어 리소스 그룹" )에 기반하여 상기 특정 동작 명령을 인증하는 단계; 및 상기 특정 동작 명령이 특정 리소스 그룹을 생성하기 위한 동작 명령이 아니면, 상기 특정 리소스 그룹에 대한 생성 동작 명령외의 다른 동작 명령(들)의 권한을 인증하는데 사용되는 접근 제어를 위한 리소스 그룹(이하, "제 2 접근 제어 리소스 그룹" )에 기반하여 상기 특정 동작 명령을 인증하는 단계를 포함할 수 있다.

바람직하게는, 상기 제 1 접근 제어 리소스 그룹은: 상기 특정 리소스 그룹을 지시하는 ID(Identifier) 및 특정 서버의 상기 생성 동작 명령이 허용됨을 지시하는 접근 제어 리스트(Access Control List; ACL) 리소스를 포함할 수 있다.

바람직하게는, 상기 제 1 접근 제어 리소스 그룹은 부트스트랩 인터페이스를 통해 수신되는 생성하기 위한 동작 명령에 의해 생성될 수 있다.

바람직하게는, 상기 특정 명령은 장치 관리 및 서비스 인에이블먼트(device management and service enablement) 인터페이스를 통해 수신될 수 있다.

본 발명의 다른 일 실시예에 따른 무선 통신 시스템에서 특정 동작 명령에 대한 권한 인증을 위한 단말에 있어서, 무선 주파수(radio frequency; RF) 유닛; 및 상기 RF 유닛을 제어하도록 구성된 프로세서를 포함하되, 상기 프로세서는 제 1 서버로부터 특정 리소스 그룹에 대한 생성 동작 명령의 권한을 인증하는데 사용되는 접근 제어를 위한 리소스 그룹을 생성하기 위한 동작 명령을 수신하고, 상기 접근 제어를 위한 리소스 그룹을 생성하고, 제 2 서버로부터 상기 특정 리소스 그룹을 생성하기 위한 동작 명령을 수신하며, 그리고 상기 생성된 접근 제어를 위한 리소스 그룹에 기반하여 상기 특정 리소스 그룹을 생성하기 위한 동작 명령을 인증하도록 구성될 수 있다.

본 발명의 다른 일 실시예에 따른 무선 통신 시스템에서 특정 동작 명령에 대한 권한 인증을 위한 단말에 있어서, 무선 주파수(radio frequency; RF) 유닛; 및 상기 RF 유닛을 제어하도록 구성된 프로세서를 포함하되, 상기 프로세서는 서버로부터 특정 동작 명령을 수신하고, 상기 특정 동작 명령이 특정 리소스 그룹을 생성하기 위한 동작 명령이면, 상기 특정 리소스 그룹에 대한 생성 동작 명령의 권한을 인증하는데 사용되는 접근 제어를 위한 리소스 그룹(이하, "제 1 접근 제어 리소스 그룹" )에 기반하여 상기 특정 동작 명령을 인증하도록 구성되고, 그리고 상기 특정 동작 명령이 특정 리소스 그룹을 생성하기 위한 동작 명령이 아니면, 상기 특정 리소스 그룹에 대한 생성 동작 명령외의 다른 동작 명령(들)의 권한을 인증하는데 사용되는 접근 제어를 위한 리소스 그룹(이하, "제 2 접근 제어 리소스 그룹" )에 기반하여 상기 특정 동작 명령을 인증하도록 구성될 수 있다.

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

본 발명의 일 실시예에 따르면, M2M 서버(들)로 M2M 클라이언트/장치의 특정 기능 또는 리소스에 대한 업데이트 관련 정보를 통지할 수 있고, 이를 통해 상기 업데이트를 개시한 M2M 서버뿐만 아니라 다른 M2M 서버(들)가 상기 M2M 클라이언트/장치의 특정 기능 또는 리소스에 대한 업데이트를 알 수 있도록 하고 더 나아가 상기 업데이트를 통해 변경된 특정 기능 또는 리소스를 이용할 수 있게 한다.

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

본 발명에 관한 이해를 돕기 위해 상세한 설명의 일부로 포함되는, 첨부 도면은 본 발명에 대한 실시예를 제공하고, 상세한 설명과 함께 본 발명의 기술적 사상을 설명한다.
도 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).

서버 식별자(Server 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 트리의 속성을 조작할 수 있다.

기존 서버-클라이언트 모델에서 서버와 클라이언트 간의 통신을 수행하기 위해서는 두 엔티티(서버, 클라이언트) 모두 통신 수행 이전에 공유/저장해야 하는 정보가 존재한다. 이를 위해 DM 에서는 DM 클라이언트를 부트스트랩(bootstrap)하여 DM 서버와의 통신에 필요한 필요한 사전 정보를 DM 서버 또는 DM 부트스트랩 서버가 전달한다. 즉, DM 클라이언트는 특정 DM 서버와의 통신에 필요한 사전 정보를 부트스트랩 기법을 통해 전달하고, 이후 해당 DM 클라이언트와 DM 서버간의 통신이 가능하도록 한다.

실제 배치(deployment) 상황에서 DM 클라이언트를 재-부트스트랩(re-bootstrap)할 경우가 발생하는데, 예를 들어 특정 DM 서버와 특정 DM 클라이언트 간의 통신에 지속적으로 오류가 발생한 경우이다. 이러한 경우는 보안 키(security key) 불일치(mismatch) 또는 다른 이유 등으로 발생할 수 있다. DM 에서는 재-부트스트랩(re-bootstrap)에 대해 명시하고 있지는 않지만, 부트스트랩(bootstrap)이 다시 발생하는 경우를 의미하는 경우로 판단된다. 이러한 부트스트랩의 경우는 부트스트랩 정보 이외에도 특정 서버 관련 정보가 초기화(예건대 ACL 안의 해당 서버의 권한 정보들)되기 때문에 재-부트스트랩 이후에도 해당 서버에 대한 정보를 클라이언트로 전달해주는 것이 필요하다. 이에 본 발명에서는 재-부트스트랩 시 전체 부트스트랩을 모두 수행하지 않고, 특정 정보만을 제공/갱신하는 방법을 사용하여 다른 정보들을 유지하면서 재-부트스트랩을 수행하는 방법을 제시한다.

도 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) 부트스트랩, 2) 장치(클라이언트, 디바이스) 등록, 3) 장치 관리 및 서비스 인에이블먼트, 4) 정보 보고. 상기 네 가지의 인터페이스들을 위한 동작 명령들은 상향링크 동작들 및 하향링크 동작들로 분류될 수 있다. 각각의 인터페이스의 동작 명령들이 아래의 표에 정의된다.

[표 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 관련 동작 명령 및 객체 (인스턴스)에 대한 설명을 간략히 하도록 한다.

·등록(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 장치 공작 리셋), M2M 클라이언트는 M2M 서버에게 "등록-해제" 동작 명령을 전송해야 한다. 이 동작 명령을 수신하면, M2M 서버는 상기 M2M 서버로부터 상기 M2M 클라이언트에 대한 등록 정보를 제거해야 한다.

·읽기(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]

·관찰(Observe)

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

[표 14]

·취소 관찰(Cancel Observe)

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

[표 15]

접근 제어 기법

이하는 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)를 포함한다.

[표 16]

- 인증 절차

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 클라이언트는 펌웨어 또는 소프트웨어의 변경(예컨대, 업데이트, 설치, 제거 등)으로 인한 자신의 변경된 정보를 자신이 등록된 또는 연결(connection)이 있는 하나 이상의 M2M 서버에 통지할 수 있다. 도 4 는 본 발명의 일 실시예에 따른 이러한 동작을 도시한다.

도 4 를 참조하면, 서버 1 은 클라이언트로 펌웨어 또는 소프트웨어의 변경을 지시할 수 있다. 이는 앞서 설명한 "실행" 동작 명령을 전송함으로써 수행되며, 예컨대 펌웨어 또는 소프트웨어 관련 객체 인스턴스의 특정 리소스(예컨대, 업데이트 리소스)의 실행을 상기 클라이언트에게 요청함으로써 수행될 수 있다. 아울러, 상기 동작 명령에 대한 인증 절차 역시 앞서 설명한 바대로 이루어지나, 본 실시예에서는 설명의 간략함을 위해 그에 대한 구체적인 설명은 생략하도록 한다.

상기 "실행" 동작 명령에 대한 인증 절차가 완료되면, 상기 클라이언트는 상기 "실행" 동작 명령을 수행하며, 이로 인해 펌웨어 또는 소프트웨어가 변경될 수 있다. 상기 클라이언트는 상기 펌웨어 또는 소프트웨어가 변경되었다면 이에 대한 정보를 앞서 설명한 장치 등록 인터페이스에서 업데이트 동작 명령 또는 등록 동작 명령을 사용하여 각 M2M 서버에게 통지할 수 있다. 아래에서는 이러한 통지와 관련하여 좀더 구체적으로 설명하도록 한다.

·통지 대상

상기 통지의 대상은 상기 M2M 클라이언트와 현재 접속 또는 세션을 맺고 있는 M2M 서버, 또는 상기 M2M 클라이언트 내 M2M 서버 계정에 저장된 모든 M2M 서버일 수 있다. 현재 접속 또는 세션을 맺고 있지 않은 M2M 서버에게 전송할 경우, 현재 접속 또는 세션을 맺고 있지 않은 M2M 서버라도 상기 통지를 통해 상기 M2M 클라이언트의 펌웨어 또는 소프트웨어 변경으로 인해 M2M 클라이언트가 지원하는 기능이 변경되었음을 인식할 수 있게끔 하고, 이를 통해 상기 M2M 서버가 상기 변경된 기능을 사용할 수 있도록 한다.

또는, 상기 통지의 대상은 미리 각 M2M 클라이언트 별로 특정되어 있고, 각 M2M 클라이언트는 특정된 통지의 대상에게 상기 통지를 전달할 수 있다. 상기 통지 대상은 M2M 서버로 한정되지 않으며, M2M 클라이언트가 통지 대상의 연결 관련 정보(예컨대 식별자, 주소)를 가지고 있어 연결을 맺을 수 있는 다른 엔티티(예컨대, 어플리케이션)가 될 수도 있다.

또는, 상기 M2M 클라이언트가 등록된 M2M 서버에게 업데이트 동작 명령 또는 등록 동작 명령을 전송하여 상기 통지를 전달할 수 있다.

·통지 지시자

상기 통지의 전달 또는 전송은 상기 통지를 위한 지시자(이하, 통지 지시자)가 설정되어 있는 경우에만 수행되는 방안을 고려할 수 있다. 이 경우엔, 상기 통지 지시자의 값이 상기 통지를 활성화를 나타내는 경우에만, 상기 통지가 수행되며 그렇지 않은 경우에는 상기 통지는 이루어지지 않을 수 있다. 상기 통지 지시자는 상기 펌웨어 또는 소프트웨어 관련 업데이트 객체에 존재하는 업데이트 또는 등록 지시자 리소스의 값일 수 있다.

또는, 펌웨어 또는 소프트웨어 변경이 되었을 때, 1) M2M 클라이언트에서 지원하는 기능이 변경되었을 때, 2) M2M 클라이언트가 변경된 기능이 중요하다고 판단할 때, 또는 3) M2M 서버가 미리 설정해놓은 기준을 만족할 때, 상기 변경에 대한 통지가 이루어질 수 있다.

다시 설명하면, M2M 클라이언트는 상기 통지 지시자가 특정 값으로 설정되어 있고 펌웨어 또는 소프트웨어의 변경으로 지원하는 기능이 변경(즉, 지원하는 객체의 변경)되면, 상기 업데이트 또는 등록 동작 명령을 해당 M2M 서버에게 전송할 수 있다.

상기 통지 지시자는 M2M 서버가 설정하며, 상기 설정은 앞서 설명한 "쓰기" 동작 명령을 통해 상기 통지 지시자에 해당하는 특정 리소스에 특정 값을 기록함으로써 수행될 수 있다. M2M 클라이언트는 그 설정된 값을 읽어들여(예컨대, "읽기" 동작 명령을 통해) 그에 따라 수행한다. 상기 통지 지시자의 값이 설정되어 있지 않을 수 있고, 이 경우에는 디폴트(default) 값이 존재하며, 따라서 상기 M2M 클라이언트는 상기 디폴트 값으로 상기 통지 지시자를 인식한다.

·통지 시간

상기 통지를 전달 또는 전송함에 있어서, M2M 클라이언트는 펌웨어 또는 소프트웨어의 변경 즉시 또는 가능한 빨리 상기 통지를 전송할 수 있다.

아울러, 상기 M2M 클라이언트는 업데이트 동작 명령을 주기적으로 M2M 서버로 전송하는데, 상기 업데이트 동작 명령을 전송할 주기가 아님에도 상기 펌웨어 또는 소프트웨어의 변경을 통지하기 위해 상기 업데이트 동작 명령 또는 상기 등록 동작 명령을 M2M 서버로 전송할 수 있다.

또는, 상기 통지를 위한 시간이 미리 설정되어 있거나 상기 펌웨어 또는 상기 소프트웨어를 업데이트하기 위한 동작 명령에 포함되어 있을 수 있고, 따라서 상기 M2M 클라이언트는 해당 시간에 상기 통지를 전송할 수 있다. 또는, 상기 M2M 클라이언트는 특정 시간 내에 임의로 선택한 시점에서 상기 통지를 전송할 수 있다.

·통지 내용

-제 1 안

M2M 클라이언트는 펌웨어 또는 소프트웨어 변경을 통해 지윈되는 또는 사용가능한 기능들 또는 객체(또는 객체 인스턴스)(이하, 간략히 "기능(functionality)" 이라 지칭함)들을 M2M 서버(들)에게 알릴 수 있다. 상기 지원되는 또는 사용가능한 기능은 상기 M2M 클라이언트에서 지원되거나 사용가능한 모든 기능을 포함할 수 있고, 또는 상기 변경을 통해 새롭게 지원되거나 사용가능한 기능만을 포함할 수 있다. 즉, 상기 M2M 클라이언트는 자신이 지원하는 기능들의 리스트 및/또는 상기 변경을 통해 새롭게 지원하거나 사용가능한 기능의 리스트를 상기 업데이트/등록 동작 명령을 통해 상기 M2M 서버(들)에 알릴 수 있다.

-제 2 안

M2M 클라이언트는 펌웨어 또는 소프트웨어의 변경 사실만을 M2M 서버로 알릴 수 있다. 그리고나서, 상기 M2M 서버는 상기 M2M 클라이언트가 어떠한 기능을 지원하거나 사용가능한지를 읽어들여(retrieve) 그에 대한 정보를 획득할 수 있다. 다시 말하면, 상기 M2M 서버는 상기 M2M 클라이언트가 지원하는 또는 사용가능한 기능의 리스트를 읽어들일 수 있다. 한편, 접근 제어를 통해 상기 통지를 받은 모든 M2M 서버가 상기 리스트를 읽어들일 수 있고, 몇몇 M2M 서버만이 상기 리스트를 읽어들일 수 있다.

기능 삭제

펌웨어 변경 또는 소프트웨어 변경을 통해 특정 기능이 추가될 수도 있지만 삭제될 수도 있다. 기능이 삭제 될 경우 관련 자료 구조는 삭제된다. 이는 펌웨어 변경 또는 소프트웨어 변경을 통한 통지를 받은 M2M 서버가 삭제된 기능 관련 자료 구조를 삭제할 수도 있고, M2M 클라이언트 자체적으로 삭제된 기능 관련 자료구조를 삭제할 수 있다. 이 때, 해당 자료구조의 연관 자료 구조 또한 삭제한다. 예컨대 M2M 클라이언트는 삭제된 기능(객체)에 대해 관련 객체 인스턴스를 삭제하고, 객체와 연관된 접근 제어 객체 인스턴스를 삭제한다.

M2M 서버에 의해 사용가능한 기능들

M2M 서버가 특정 M2M 클라이언트에서 사용가능한 기능들이 미리 설정되어 있을 수 있다. 이러한 경우에는 M2M 서버가 사용가능한 기능과 M2M 클라이언트가 지원하는 기능을 비교하여 서로 간의 교집합을 통해 실제 사용가능한 기능이 도출될 수 있다. M2M 서버가 상기 교집합 이외의 기능에 대해 접근할 경우 에러가 발생한다.

M2M 클라이언트의 M2M 서버 계정에 M2M 서버가 생성할 수 있는 객체(creatable Object)가 설정되어 있을 수 있다. 이렇게 M2M 서버가 생성할 수 있는 객체와 M2M 클라이언트의 지원 오브젝트의 리스트 간의 비교(교집합)을 통해 M2M 서버가 해당 M2M 클라이언트에 생성 가능한 객체의 리스트가 도출된다. 리스트에 명시되지 않은 객체를 생성하려고 할 시에는 에러가 발생하고, 리스트에 명시된 객체는 M2M 서버가 생성할 수 있다.

또한, M2M 서버 계정에 M2M 서버가 생성할 수 있는 객체에 와일드 카드(wildcard)를 넣을 수 있는데, 이 의미는 M2M 서버가 M2M 클라이언트의 모든 객체를 생성할 수 있는 권한이 있음을 의미한다. 이러한 기능의 장점은 기존에는 새로 추가되는 기능(Object)에 대해서 권한을 가지게 되려면 항상 새로 추가되는 기능에 대해 ACL 을 변경해야 하는 설정(configuration)이 필요하고, 또한 해당 기능을 생성하는 권한을 가지려면 부트스트랩이 필요한 번거로움이 존재하였다. 하지만 와일드 카드를 삽입하면 미래에 사용될 기능에 대해서도 생성할 수 있는 권한이 부여된다. 이러한 기능은 최고의 권한을 가진 M2M 서버가 존재할 경우 사용이 용이하다.

이용가능한 기능 구독(subscription)

M2M 서버는 M2M 클라이언트에서 가능한 기능이 변경됨을 알기 위해 구독(subscription)을 설정할 수 있다. 즉, M2M 클라이언트에서 가능한 기능이 변경되었을 시 이를 구독한 M2M 서버들이 해당 변경된 결과를 얻을 수 있다. 구독은 M2M 서버에서 가능한 기능 변경 알림을 얻고 싶을 때 사용하기에 구독한 M2M 서버들만이 해당 결과 값을 얻을 수 있다. 해당 구독 시 필터가 존재할 수 있으며, 상기 필터는 특정 기능 또는 특정 기능 분류, 기능 식별자 범위에 해당하는 기능이 추가/변경되었을 시 알리게 하는 기능을 제공할 수 있다. 구독의 타겟은 특정 URI(URL)로 설정할 수 있다. 이를 통해, 펌웨어 또는 소프트웨어 업데이트(예컨대, 애플리케이션 업데이트)를 통해 변경되는 기능들에 대해 서버는 인지할 수 있다. 한편, 구독없이, 새 기능이 발견되면 연결된(등록된) 모든 서버에게 기능들을 전송할 수 있다.

또한, 특정 시간이 미리 설정되어 있거나 상기 특정 시간이 구독 요청 메시지에 포함되어 있으면, M2M 클라이언트는 해당 시간에 M2M 서버로 상기 변경되는 기능 알림을 전송할 수 있다. 또는, M2M 클라이언트가 상기 특정 시간 내 임의로 선택된 시점에서 상기 기능 알림을 전송할 수 있다.

도 5 는 본 발명의 일 실시예에 따른 구독 관련 절차를 도시한다.

엔티티 1 은 엔티티 2 의 지원되는 리소스 또는 리소스 그룹 (이하 도 5 와 관련된 설명에서 간략히 "지원되는 리소스" 라 지칭함)가 변경되는 것을 확인하기 위해 엔티티 2 에 대해 구독(subscription)을 수행할 수 있다(S51). 이 때, 상기 구독은 디폴트(default)로 전체 또는 특정 리소스에 대하여 설정될 수 있다. 한편, 도 5 와 관련될 설명에서, 상기 "지원되는 리소스" 는 다른 용어들로 표현될 수 있다. 예컨대, 상기 "지원되는 리소스" 는 지원되는 리소스 또는 지원되는 리소스 그룹뿐만 아니라 지원되는 리소스 유형(resource type) 또는 지원되는 속성(attribute) 등 리소스 또는 리소스 그룹의 정의, 기능 변경과 관련된 모든 정보를 의미하는 용어로 대체될 수 있다.

또한, 엔티티 1 은 상기 변경의 통지를 위한 구독에 특정 조건을 설정할 수 있다(S52). 즉, 상기 설정된 특정 조건을 만족하는 경우에만, 상기 변경에 대한 통지가 이루어질 수 있다. 상기 특정 조건을 설정하는 것을 필터링 또는 필터를 설정한다고 표현할 수 있다.

한편, 상기 S52 는 상기 S51 보다 먼저 수행되거나 동시에 수행될 수 있다. 또한, 상기 S51 및 S52 의 구독 및 필터링의 설정은 상기 "지원되는 리소스" 와 연관된 특정 리소스를 생성하여 특정 값을 기록(생성)하거나 상기 특정 리소스의 값을 변경함으로써 수행될 수 있다.

엔티티 2 의 상기 구독이 설정된 "지원되는 리소스" 가 변경되었다고 가정한다(S53). 엔티티 2 는 상기 S52 에서 설정된 특정 조건이 만족되는지 여부를 확인할 수 있다(S54). 상기 특정 조건이 만족되면, 엔티티 2 는 상기 "지원되는 리소스" 가 변경되었음을 엔티티 1 로 통지할 수 있다(S55).

도 5 와 관련된 본 발명의 다른 일 실시예는 상기 "지원되는 리소스" 대신 엔티티 2 의 특정 기능 또는 성능(capability)(이하, 간략히 "기능" 이라 함)에 대하여 수행될 수 있다. 이러한 경우, 단말에 실체화된 리소스의 변경 구독을 위한 메시지와 상기 "기능" 의 변경 구독을 위한 메시지는 형태가 서로 다를 수 있다. 엔티티 2 는 상기 메시지(들)가 타깃하는 대상이 같다하더라도 두 개의 메시지를 구별할 수 있다. 상기 구별은 예컨대 쿼리 스트링(query string)을 통해 가능하다.

또한, 상기 "기능" 에 대해서는 특정 동작 명령(예컨대, 생성, 읽기, 업데이트, 삭제 등)을 수행하지 못하거나 몇몇 만이 수행가능할 수 있으며, 상기 "기능" 에 대한 특정 동작 명령은 단말에 실체화된 리소스에 대한 동작 명령과 다른 방식으로 수행된다. 따라서, 바람직하게는 상기 구독이 상기 리소스에 대한 것인지 "기능" 에 대한 것인지를 지시하기 위한 정보(예컨대, 지시자)가 상기 메시지(들)에 포함될 수 있다.

좀더 구체적으로, 상기 "기능" 에 대한 변경 구독을 위한 메시지는 리소스 타입 이름 또는 리소스 타입을 식별할 수 있는 식별자가 포함되며, 속성에 대한 변경 구독을 하는 경우엔 상기 메시지에는 속성 이름이 포함될 수 있다.

상기 리소스 의 변경 구독을 위한 메시지에는 리소스 타입 이름 또는 리소스 타입을 식별할 수 있는 식별자가 포함되지 않을 수 있다.

예를 들어, 엔티티 1 이 "읽기(retrieve)" 동작 명령을 엔티티 2 의 리소스 타입을 타깃하여 전송할 경우, 엔티티 2 는 리소스 타입이 지원될 시 리소스 타입이 지원됨을 또는 리소스 타입이 지원하는 기능의 리스트를 엔티티 1 로 응답 메시지를 통해 전송하며, 해당 리소스 타입이 지원되지 않을 시 지원되지 않음(존재하지 않음)을 응답 메시지를 통해 엔티티 1 로 전달할 수 있다. 또한, 엔티티 1 이 "읽기" 동작 명령을 엔티티 2 의 리소스 타입을 타깃하여 전송할 경우, 엔티티 2 는 속성이 지원될 경우 속성이 지원됨을 엔티티 1 로 응답 메시지를 통해 전송하며, 해당 속성 지원되지 않을 시 지원되지 않음(존재하지 않음)을 엔티티 1 로 응답 메시지를 통해 전달할 수 있다.

해당 리소스 타입에 대한 "읽기" 동작 명령에는 리소스 타입 이름 또는 리소스 타입을 식별할 수 있는 식별자가 포함될 수 있다.

"읽기" 동작 명령이 리소스 타입이 실체화된 리소스에 대해 전송될 경우, 해당 리소스, 속성의 실제 값들이 응답 메시지로 전송될 수 있다. 해당 "읽기" 동작 명령에는 리소스 타입 이름 또는 리소스 타입을 식별할 수 있는 식별자가 포함되지 않을 수 있다. 다른 동작 명령들은 리소스 타입에 대해 사용되지 못할 수 있다.

"기능"

상기 "기능" 은 리소스 타입 또는 속성의 지원 여부로 표현될 수 있다. 즉, 엔티티가 어떠한 기능을 제공한다는 의미는 특정한 리소스 타입 또는 속성을 지원함을 의미할 수 있고, 엔티티에 리소스 타입 또는 속성으로 타 엔티티에게 노출되지 않는 기능은 지원되지 않음을 의미한다. 즉, 엔티티 1 이 엔티티 2 의 해당 리소스 타입 또는 속성에 동작 명령을 전송 시 해당 동작 명령에 대한 응답으로 해당 리소스 타입 또는 속성이 지원되지 않거나(not supported), 존재하지 않는다는(not found) 내용이 포함(예컨대, 응답 코드에 포함됨)되면 해당 리소스 타입 또는 속성은 해당 엔티티 2 에 지원되지 않으며, 해당 리소스 타입 또는 속성이 제공하는 기능 또한 지원되지 않음을 의미한다. 상기 응답에 상기 내용 이외의 타 내용(예컨대 지원(supported)함, 존재(exist)함 또는 해당 기능 관련 정보)이 포함되면 해당 리소스 타입 또는 속성이 엔티티 2 에서 지원되며, 엔티티 2 는 해당 리소스 타입 또는 속성이 제공하는 기능을 가지고 있음을 의미한다.

리소스 타입은 용어 그대로 리소스의 타입으로, 타입 마다 (하위, child) 특정 리소스 타입 또는 속성 군의 집합을 가지고 있다. 리소스 타입은 템플릿(template)또는 틀의 개념으로, 해당 리소스 타입에 속하는 리소스 타입 또는 속성 군은 값을 가질 수 없고, 리소스 타입이 "생성" 동작 명령으로 실체화되어야 해당 리소스 타입이 실체화된 리소스 또는 속성 군은 값을 가질 수 있고, 해당 리소스 또는 속성 군 또는 각각의 리소스 또는 속성에 대해 동작 명령(즉, 읽기, 업데이트, 삭제 등)이 수행될 수 있다.

리소스 타입은 (자손) 리소스 타입과 속성들로 이루어 질 수 있고, 동작 명령 수행은 리소스 타입, 자손 리소스 타입, 속성 마다 미리 설정되어 있다.

상기 도 5 와 관련된 설명에서, 엔티티 1 은 AE 또는 CSE 이고, 엔티티 2 는 CSE 이며, 엔티티 1 과 엔티티 2 는 서로 다른 엔티티이다. 이하, AE 와 CSE 에 대해 구체적으로 설명하도록 한다.

Application Entity (AE): AE 는 단-대-단 M2M 솔루션들을 위한 어플리케이션 로직을 제공한다. AE 의 예로는 물류 추적 어플리케이션, 원격 혈당 모니터링 어플리케이션, 원격 파워 미터 어플리케이션 등이 있다. (Application Entity provides Application logic for the end-to-end M2M solutions. Examples of the Application Entities can be fleet tracking application, remote blood sugar monitoring application, or remote power metering and controlling application.)

Common Services Entity (CSE): CSE 는 서비스 기능들의 집합으로 이루어져 있으며, 이러한 서비스 기능들은 M2M 환경에서 공통적으로 사용되는 기능들이며, oneM2M 에서 명시한 기능들이다. 이러한 서비스 기능들은 Mca, Mcc 레퍼런스 포인트(인터페이스)를 통해 다른 entity 들에게 노출되게 된다. (A Common Services Entity comprises the set of "service functions" that are common to the M2M environments and specified by oneM2M. Such service functions are exposed to other entities through Reference Points Mca and Mcc. Reference point Mcn is used for accessing Underlying Network Service Entities.)

Node: oneM2M 의 Node 는 기능적인 엔티티로써 최소 하나의 CSE 그리고/또는 AE 를 가져야 한다. Node 는 M2M 디바이스, 게이트웨이, 서버에 포함될 수 있다.(A oneM2M Node is a functional entity that shall contain at least one oneM2M Common Services Entity and/or one oneM2M Application Entity. A oneM2M Node may be contained in a physical object e.g., M2M Device, Gateway or Server Infrastructure.)

AE 와 CSE 는 논리적으로 Node(예컨대, application service node, application dedicated node, middle node, infrastructure node)에 존재하며, 물리적으로는 M2M 장치, M2M 게이트웨이, M2M 서버 즉 M2M 관련 장치에 존재할 수 있다, 아울러, 이러한 측면에서 AE 와 CSE 는 M2M 장치, M2M 게이트웨이 또는 M2M 서버(인프라스트럭처)로 지칭가능하다.

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

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

[표 17]

[표 18]

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

[표 19]

[표 20]

다음은 펌웨어 업데이트 객체(또는 객체 인스턴스)를 설명한다. 상기 펌웨어 업데이트 객체는 M2M 클라이언트에 업데이트될 펌웨어의 관리를 가능하게 한다. 상기 펌웨어 업데이트 객체는 펌웨어 패키지 설치, 펌웨어 업데이트, 및 펌웨어 업데이트 이후의 동작을 수행하는 것을 정의한다.

[표 21]

[표 22]

도 6 은 본 발명의 일 실시예에 따른 펌웨어 업데이트의 결과를 통지하는 절차를 도시한다. 본 실시예를 설명함에 있어서, 앞서 설명한 내용을 참조하도록 한다.

M2M 서버(이하, "서버" 라 지칭함)는 상기 통지를 지시하기 위한 지시자의 설정을 M2M 클라이언트(이하, "단말" 이라 지칭함)에게 요청할 수 있다(S61). 상기 통지를 지시하기 위한 지시자는 즉각적인 비주기적인 통지를 위한 것이며, 앞서 설명한 것처럼 상기 지시자가 상기 비주기적인 통지를 위한 특정 값을 갖도록 설정되지 않으면, 주기적인 통지를 통해 상기 업데이트의 결과(예컨대, 변경된 객체, 지원하는 리소스 그룹, 또는 기능 등)가 전달될 수 있다.

좀더 상세히 설명하면, 상기 지시자는 상기 단말 내의 특정 실체화된 리소스 그룹(즉, 객체 인스턴스) 내 특정 리소스일 수 있으며, 예를 들어 위에서 설명한 펌웨어 업데이트 객체 인스턴스의 "Update Supported Objects" 리소스일 수 있다. 상기 "Update Supported Objects" 리소스의 값을 true 로 설정함으로써, 상기 비주기적인 통지를 상기 단말에게 요청할 수 있다.

아울러 상기 "Update Supported Objects" 리소스의 값을 특정 값으로 설정의 요청은 상기 서버가 앞서 언급한 상기 리소스를 타깃으로 "쓰기" 동작 명령을 상기 단말로 전송함으로써 수행될 수 있다. 상기 "쓰기" 동작 명령에는 새롭게 기록할 값(즉, 페이로드)(예컨대, true)이 포함된다.

상기 요청을 수신하면, 상기 단말은 상기 요청에 대한 인증 절차 및 그 결과에 따른 동작을 수행할 수 있다(S62).

상기 인증 절차는 앞서 설명한 계층적 인증 절차가 되며, 좀더 상세하게는 접근 제어 객체 인스턴스를 통한 상기 서버의 상기 리소스에 대한 접근 권한의 인증과 상기 리소스가 상기 "쓰기" 동작 명령을 지원하는지 여부가 판단될 수 있다. 상기 인증 절차에 대한 설명은 앞서 설명한 내용을 참조하여 수행되는 것으로 가정한다.

만약 상기 서버가 상기 리소스에 대한 접근 권한이 있고, 상기 리소스가 상기 "쓰기" 동작 명령을 지원하는 것으로 판단되면, 상기 단말은 상기 리소스에 상기 새롭게 기록할 값(즉, true)를 기록할 수 있다. 그렇지 않다면, 상기 단말은 상기 서버로 상기 인증 절차가 실패되었음을 알리는 에러 코드를 전송할 수 있다.

이하, 상기 인증 절차가 성공적으로 완료되어, 상기 "Update Supported Objects" 리소스의 값이 true 로 설정되어 있다고 가정한다.

그 이후, 상기 서버는 상기 단말로 펌웨어의 업데이트를 요청할 수 있다(S63). 예컨대, 상기 단말에 설치된 펌웨어의 새로운 버전이 배포(설치)된 경우일 수 있다. 상기 요청은 상기 펌웨어 업데이트 객체 인스턴스 내 특정 리소스에 대한 "실행" 동작 명령을 통해 이루어질 수 있으며, 예컨대 상기 특정 리소스는 "Update" 리소스이다. 상기 "Update" 리소스에 대한 실행 동작 명령은 "Package" 리소스의 패키지 또는 "Package URI" 에서 다운로드한 펌웨어 패키지(이미지)를 이용하여 단말의 펌웨어 업데이트를 수행하도록 설정되어 있다.

한편, 이 경우에도 상기 "실행" 동작 명령에 대한 인증 절차 및 그 결과에 따른 동작 수행, 즉 펌웨어 업데이트(S64)가 필요하며, 이에 대한 설명은 앞선 설명을 참조하고, 본 실시예에선 설명을 생략하도록 한다. 이하, 상기 S54 의 인증 절차도 성공적으로 완료되었다고 가정한다.

그리고나서, 상기 단말은 상기 펌웨어 업데이트가 완료되고 나면, 특정 조건이 만족되는지 여부를 판단할 수 있다(S65). 좀더 상세하게는, 상기 특정 조건은 i)상기 펌웨어 업데이트에 의해 상기 단말이 지원하는 객체, 존재하는 객체 인스턴스, 지원하는 리소스 그룹, 실체화된 리소스 그룹 또는 기능이 변경되었는지 그리고 ii) 상기 지시자가 true 값으로 설정되어 있는지를 포함할 수 있다.

상기 특정 조건이 모두 만족되면, 상기 단말은 상기 서버로 상기 펌웨어 업데이트로 인해 변경된 자신이 지원하는 객체 또는 사용가능한 객체 인스턴스의 리스트를 통보할 수 있다(S66). 상기 단말이 지원하는 객체 또는 사용가능한 객체 인스턴스의 리스트는 상기 펌웨어 업데이트 통해 변경된 객체/객체 인스턴스(들)뿐만 아니라 변경되지 않은 객체/객체 인스턴스(들)를 포함한다. 즉, 상기 펌웨어 업데이트 이후에 상기 단말이 지원하는 객체 또는 사용가능한 객체 인스턴스(들) 모두를 포함한다. 이는 변경된 객체/객체 인스턴스(들)만을 통보한 경우에 발생할 수 있는 문제점을 보완하기 위함이다. 이에 대해선 별도로 후술하도록 한다.

한편, 상기 통보는 가능한 빨리 전달되는 것이 바람직하다. 상기 통보는 앞서 설명한 "업데이트" 동작 명령(또는 메시지) 또는 "등록" 동작 명령(또는 메시지)를 사용하여 수행될 수 있다.

만약 상기 특정 조건 중 하나라도 만족되지 않으면, 상기 단말은 주기적으로 전송되는 업데이트 동작 명령을 통해 다음의 주기적 업데이트 동작 명령 전송 시점에 자신이 지원하는 객체 또는 사용가능한 객체 인스턴스의 리스트를 상기 서버로 전달할 수 있다(S66-1).

통보되는 정보 = 객체/객체 인스턴스(들)의 리스트

위의 S66 에서 상기 서버로 전달되는 정보는 상기 펌웨어 업데이트로 인해 변경된 지원되는 객체 또는 객체 인스턴스(들)(즉, 지원되는 리소스 그룹(들) 또는 실체화된 리소스 그룹(들))뿐만 아니라 변경되지 않은 객체 또는 객체 인스턴스(들)(즉, 지원되는 리소스 그룹(들) 또는 실체화된 리소스 그룹(들))을 포함한다 하였다. 다음의 시나리오는, 상기와 같이 펌웨어 업데이트 이후에 단말이 지원하는 객체 및 이용가능한 객체 인스턴스 모두에 대한 정보(리스트)를 서버 측으로 통보하는 것이 필요한 이유를 설명한다. 여기서 상기 이용가능한 객체 인스턴스는 단말에 존재하는 객체 인스턴스(들) 중 해당 서버에게 노출(expose) 가능한 객체 인스턴스를 의미할 수 있다 (예컨대 해당 서버가 접근하지 못하는(해당 서버에게 노출되지 못하는) 서버 보안 객체 인스턴스를 제외한 모든 객체 인스턴스).

표 6 과 관련한 "업데이트" 동작 명령(또는 메시지)를 통해, 단말은 서버로 주기적으로 등록 정보에 대한 업데이트를 수행한다. 상기 등록 정보에는 표 6 에 도시된 것처럼 "Objects and Object Instances" 가 포함되어 있고, 이는 상기 단말이 지원하는 객체 및 사용가능한 객체 인스턴스(들)의 리스트에 해당한다. 따라서, 주기적으로 상기 단말은 상기 리스트를 "업데이트" 동작 명령을 통해 상기 서버로 전송하기 때문에, 상기 서버는 적어도 주기적으로 상기 단말의 상기 리스트를 알 수 있다. 따라서, 미리 설정된 주기 사이에 적어도 2 회의 펌웨어 업데이트가 발생하는 경우에 대해서 설명하도록 한다. 한편, 미리 설정된 주기 사이에 1 회의 펌웨어 업데이트가 있고, 그 펌웨어 업데이트에 대해서 변경된 정보만을 통보하더라도, 서버(들)은 가장 최근의 주기적인 통보를 통해 획득한 상기 단말의 상기 리스트와 상기 변경된 정보를 합쳐서 현재 상기 단말이 지원하는 객체 및 사용가능한 객체 인스턴스(들)을 알 수 있다.

도 7 은 펌웨어 업데이트 시에 변경된 정보만을 통보한 경우의 문제점을 도시한다. 도 7 은 도 6 의 일부만을 선택하여 간략히 도시한 것으로, 실제로는 도 6 에서 설명된 몇 가지 절차(예컨대, 인증 절차)가 더 필요하다. 또한, 도 7 은 도 6 과 달리, 단말의 통보시에 펌웨어 업데이트로 인해 변경된 지원 객체 및 사용가능한 객체 인스턴스(들)만을 서버로 전송함을 가정한다.

단말은 주기적인 통보 n 을 서버로 전송한다(S71). 상기 주기적인 통보 n 에는 상기 단말이 지원하는 객체 및 사용가능한 객체 인스턴스(들)를 포함할 수 있다. 그리고나서, 상기 단말은 펌웨어 업데이트를 수행할 수 있다(S72). 하지만, 도 6 과 관련된 설명을 참조하여 설명하면, 상기 통보를 위한 지시자가 false 로 설정되어 있어 상기 단말은 상기 서버로 통보를 하지 않는다.

그 이후, 상기 단말은 또 다른 펌웨어 업데이트를 수행할 수 있다(S73). 이 때, 상기 통보를 위한 지시자가 true 로 설정되어 있기에, 상기 단말은 상기 서버로 상기 펌웨어 업데이트로 인해 변경된 정보만을 통보할 수 있다(S74). 즉, 주기적 통보 사이에, 상기 서버는 상기 S73 의 펌웨어 업데이트로 변경된 정보만을 획득하며, 상기 S62 의 펌웨어 업데이트로 변경된 정보는 획득할 수 있다. 따라서, 기간 A 동안 상기 서버는 상기 단말이 지원하는 객체 또는 사용가능한 객체 인스턴스의 정확한 정보를 알 수 없고, 따라서 그로 비롯된 기능을 이용/지원할 수 없다.

그 이후에, 상기 단말은 주기적인 통보 n+1 을 서버로 전송(S75)하며, 이를 통해 상기 서버는 상기 단말이 지원하는 모든 객체 및 사용가능한 모든 객체 인스턴스(들)의 리스트를 획득할 수 있다.

한편, 펌웨어 업데이트로 인한 통보가 S72 의 펌웨어 업데이트와 관련하여 이루어진다 해도 동일한 문제가 발생한다(즉, S74 가 S72 및 S73 사이에 수행). 이때는 오히려 상기 기간 A 의 시간 길이가 더 늘어나게 된다.

따라서, 도 6 과 관련하여 설명한 것처럼, 펌웨어 업데이트로 인한 통보더라도, 상기 업데이트로 인해 변경된 정보 뿐만이 아니라 모든 정보를 전송하게 함으로써, 상기 단말이 등록된 서버(들)이 상기 단말이 지원/사용가능한 기능을 모두 사용할 수 있게 할 수 있다.

한편, 앞서 설명한 실시예들에서 "펌웨어" 만을 지칭하여 설명하였으나, "펌웨어" 는 "소프트웨어," "프로그램," "어플리케이션" 등을 모두 포함하는 포괄적인 의미로 사용되었으므로, 본 발명의 범위가 상기 "펌웨어" 에 대해서만 한정되는 것은 아니다.

접근 제어 객체 인스턴스 유형

본 발명의 다른 일 실시예에 따라 두 가지 유형의 접근 제어 객체 인스턴스를 제안하도록 한다. "생성" 동작 명령은 그에 따라 특정 객체 인스턴스가 생성되면, 상기 "생성" 동작 명령을 전송한 M2M 서버는 상기 생성된 특정 객체 인스턴스에 대한 모든 권한을 갖게 된다. 이와 같이, 상기 "생성" 동작 명령은 상대적으로 큰 권한을 부여할 수 있기에, 상기 "생성" 동작 명령을 위한 전용 접근 제어 객체 인스턴스(이하, "제 1 타입 객체 인스턴스" )를 제안하도록 한다.

상기 제 1 타입 객체 인스턴스는 특정 객체 인스턴스의 "생성" 동작 명령에 대한 접근 권한을 인증하기 위해 사용될 수 있다. 일반적인 접근 제어 객체 인스턴스(표 16)를 참조하면, 상기 제 1 타입 객체 인스턴스는 일반적인 접근 제어 객체 인스턴스의 리소스들 중에서 Object ID 와 ACL 리소스 만이 설정되고, 나머지 리소스는 설정되지 않을 수 있다. 또는, 상기 제 1 타입 객체 인스턴스는 일반적인 접근 제어 객체 인스턴스의 리소스들 중에서 Object ID 와 ACL 리소스 만이 설정되고, 나머지 리소스들은 임의의 값으로 설정될 수 있다. ACL 리소스에는 M2M 서버와 생성 가능여부가 명시되어 있어, 상기 M2M 서버가 상기 Object ID 에 해당하는 객체의 객체 인스턴스를 생성할 수 있는지를 M2M 클라이언트가 판단할 수 있다.

상기 제 1 타입 객체 인스턴스에 의해 지시되는 값들에 의해, 상기 "생성" 동작 명령에 대한 접근 권한 인증이 수행될 수 있다. 당연히, 상기 제 1 타입 객체 인스턴스의 리소스 및 리소스의 값이 지시하는 M2M 서버만이 상기 리소스의 값이 지시하는 특정 객체의 객체 인스턴스에 대해서 상기 "생성" 동작 명령에 대한 접근 권한을 가질 수 있다.

아울러, 상기 제 1 타입 객체 인스턴스는 "생성" 동작 명령만을 위한 것이므로, 다른 동작 명령에 대해서는 이용되지 않는다. 또한, 상기 제 1 타입 객체 인스턴스는 부트스트랩 인터페이스를 통해서만 설정, 생성 또는 관리될 수 있다.

한편, 제 2 타입 객체 인스턴스도 제안된다. 상기 제 2 타입 객체 인스턴스는 상기 "생성" 동작 명령 외의 동작 명령의 접근 권한 인증을 위한 것으로서, 이는 표 16 에 도시된 일반적인 접근 제어 객체 인스턴스와 동일(즉, Object ID, Object Instance ID, ACL, Access Control Owner 가 설정)하나, "생성" 동작 명령을 지원하지 않을 뿐이다. 따라서, 상기 제 2 타입 객체 인스턴스는 접근 제어 소유자에 의해 관리되며, "생성" 동작 명령에 대해서는 사용되지 않는다.

도 8 은 본 발명의 다른 일 실시예에 따른 접근 제어를 위한 객체 인스턴스의 생성 및 그를 이용한 인증 절차를 도시한다.

M2M 부트스트랩 서버(이하, 부트스트랩 서버)는 M2M 클라이언트(이하, 단말)로 제 1 타입 객체 인스턴스 생성을 위한 동작 명령을 전송할 수 있다(S81). 상기 부트스트랩 서버는 부트스트랩 인터페이스를 통해 상기 단말로 특정 동작 명령을 전송할 수 있다. 예컨대, 상기 제 1 타입 객체 인스턴스의 생성을 위한 동작 명령은 "쓰기" (또는 "생성" ) 동작 명령일 수 있으며, 상기 단말은 상기 부트스트랩 인터페이스를 통한 상기 "쓰기" 동작 명령의 대상이 상기 단말 내 존재하지 않는 객체 인스턴스 또는 리소스라도(동작 명령의 대상인 객체 인스턴스 또는 리소스의 존재 여부와 상관없이) 상기 "쓰기" 동작 명령의 페이로드를 상기 단말 안에 기록해야 한다. 즉, 상기 단말은 상기 1 타입 객체 인스턴스를 생성할 수 있다(S82). 한편, 상기 제 1 타입 객체 인스턴스는 "생성(Create)" 동작 명령에 관한 것으로서, 상기 부트스트랩 인터페이스를 통해서, 즉 상기 부트스트랩 서버만이 생성할 수 있고 관리할 수 있다. 이는, 상기 "생성" 동작 명령을 전송한 M2M 서버는 상기 "생성" 동작 명령에 의해 생성된 객체 인스턴스에 대한 모든 접근 권한을 갖기 때문에, 그에 대한 관리하기 때문에 상기 부트스트랩 인터페이스만을 통해 생성이 가능하도록 제한된다. 여기서 M2M 부트스트랩 서버를 통한 전송으로 한정되지 않으며, 부트스트랩 인터페이스를 사용하는 스마트카드로부터의 부트스트랩, 제조자 부트스트랩이 사용될 수 있다.

상기 단말은 상기 "쓰기" 동작 명령에 대한 수행 결과를 상기 부트스트랩 서버로 전송할 수 있다(S83).

그리고나서, 특정 M2M 서버(이하, 서버)가 상기 단말로 특정 객체 인스턴스의 생성을 위한 동작 명령을 전송할 수 있다(S84). 상기 특정 객체 인스턴스의 생성을 위한 동작 명령은 "생성" 동작 명령일 수 있으며, 이에 대한 인증 절차가 앞서 설명된 "접근 제어 기법" 과 같이 수행되어야 한다. 또한, 상기 "생성" 동작 명령은 "장치 관리 및 서비스 인에이블먼트(device management and service enablement)" 인터페이스를 통해 수신된다. 본 실시예에서는 상기 인증 절차를 구체적으로 설명하지 않고 앞서 설명된 내용을 참조하도록 한다.

상기 단말은 상기 제 1 타입 객체 인스턴스에 기반하여 상기 "생성" 동작 명령에 대해 인증을 수행하며(S85), 상기 인증이 성공적으로 종료되면 상기 서버로 그에 대한 결과를 전송하고(S86-1), 그렇지 않으면 상기 서버로 그에 대한 결과를 전송할 수 있다(S86-2). 상기 인증이 성공적이라면, 상기 단말은 상기 특정 객체 인스턴스를 생성하고; 그렇지 않으면 상기 특정 객체 인스턴스는 생성되지 않는다.

도 9 는 본 발명의 다른 일 실시예에 따른 접근 제어를 위한 객체 인스턴스의 생성 및 그를 이용한 인증 절차를 도시한다.

단말은 서버로부터 특정 동작 명령을 수신할 수 있다(S91). 상기 특정 동작 명령은 "장치 관리 및 서비스 인에이블먼트(device management and service enablement)" 인터페이스를 통해 수신될 수 있다. 또한, 상기 특정 동작 명령은 "읽기," "생성," "삭제," "쓰기," 및 "실행" 중 하나일 수 있다.

앞서 설명한 것처럼, 두 가지 유형의 접근 제어 객체 인스턴스가 존재하면, 상기 특정 동작 명령이 어떤 동작 명령인지에 따라 상기 특정 동작 명령의 인증을 위해 사용되는 접근 제어 객체 인스턴스가 달라진다.

따라서, 상기 단말은 사기 수신된 특정 동작 명령이 "생성" 동작 명령인지 여부를 판단할 수 있다(S92).

상기 특정 동작 명령이 "생성" 동작 명령이면, 상기 단말은 상기 생성 동작 명령의 접근 권한을 인증하기 위한 접근 제어 객체 인스턴스를 사용할 수 있다(S93-1). 만약, 상기 생성 동작 명령의 접근 권한을 인증하기 위한 접근 제어 객체 인스턴스가 존재하지 않는다면, 즉 아직 생성되지 않은 상태라면, 상기 인증은 실패로 끝나게 된다.

상기 특정 동작 명령이 "생성" 동작 명령이 아니면, 상기 단말은 상기 특정 동작 명령의 접근 권한을 인증하기 위한 접근 제어 객체 인스턴스를 사용할 수 있다(S93-2).

상기 S93-1 또는 상기 S83-2 각각 이후에, 상기 단말은 상기 인증의 결과를 상기 서버로 전송할 수 있다.

앞서 설명한 실시 예에서 부트스트랩 인터페이스를 통해 전달되는 동작 명령이라고 명시하고 있지만 여기에 국한되지 않으며, 부트스트랩 메시지, 부트스트랩 인스트럭션(instruction) 등 단말의 설정을 위해 부트스트랩 서버, 스마트카드로부터 전달되는 관련 명령 또는 정보, 또는 부트스트랩을 위해 특정 영역(예컨대 플래쉬 메모리, Secured Environment, TPM(Trusted Platform Module))에 저장되어 있는 관련 명령 또는 정보 모두 포괄할 수 있다.

본 실시 예에서 부트스트랩 서버 용어는 부트스트랩을 위한 특정 저장 영역(예컨대 플래쉬 메모리, Secured Environment, TPM(Trusted Platform Module)), M2M 서비스 부트스트랩 Function(M2M service bootstrap function) 등 상기 단말의 기본정보(예컨대 보안 키, 단말/어플리케이션 식별자, 주소, 타 엔티티와 연결/등록 위한 정보)를 전달 또는 저장하는 역할을 수행하는 다른 용어로 대체될 수 있다.

도 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

무선 통신 시스템에서 동작 명령에 대한 권한 인증을 위한 방법에 있어서, 상기 방법은 단말에 의해 수행되며,
서버로부터 부트스트랩 인터페이스를 통해 타깃(target) 리소스 그룹을 위한 제 1 접근 제어 리소스 그룹을 생성하기 위한 제 1 동작 명령을 수신하는 단계;
상기 제 1 동작 명령에 기반하여 상기 제 1 접근 제어 리소스 그룹을 생성하는 단계;
상기 서버로부터 제 2 동작 명령을 수신하는 단계;
상기 제 2 동작 명령이 상기 타깃 리소스 그룹을 생성하기 위한 동작 명령이면, 상기 타깃 리소스 그룹에 대해 설정된 상기 제 1 접근 제어 리소스 그룹에 기반하여 상기 제 2 동작 명령을 인증하는 단계; 및
상기 제 1 접근 제어 리소스 그룹은 상기 타깃 리소스 그룹을 생성하기 위한 상기 동작 명령의 권한을 인증하는데 사용되고,
상기 제 2 동작 명령이 상기 타깃 리소스 그룹을 생성하기 위한 동작 명령이 아니면, 상기 타깃 리소스 그룹에 대해 설정된 제 2 접근 제어 리소스 그룹에 기반하여 상기 제 2 동작 명령을 인증하는 단계를 포함하고,
상기 제 2 접근 제어 리소스 그룹은 상기 타깃 리소스 그룹을 생성하기 위한 동작 명령이 아닌, 적어도 하나의 동작 명령의 권한을 인증하는데 사용되고,
상기 제 1 접근 제어 리소스 그룹은 상기 타깃 리소스 그룹을 생성하기 위한 동작 명령을 지시하는 접근 제어 리스트(Access Control List; ACL) 및 상기 제1 접근 제어 리소스 그룹이 부트스트랩 절차 중에 생성됨을 지시하는 접근 제어 소유자 리소스를 포함하는 것을 특징으로 하는, 권한 인증 방법.
제 1 항에 있어서, 상기 제 1 접근 제어 리소스 그룹은:
상기 타깃 리소스 그룹을 지시하는 ID(Identifier)를 포함하는 것을 특징으로 하는, 권한 인증 방법.
제 2 항에 있어서, 상기 ACL 리소스의 비트들 중 네 번째 최하위 비트가 1 로 설정되는 것을 특징으로 하는, 권한 인증 방법.
제 1 항에 있어서,
상기 타깃 리소스 그룹을 위한 상기 제 2 접근 제어 리소스 그룹을 생성하는 단계를 더 포함하는 것을 특징으로 하는, 권한 인증 방법.
제 1 항에 있어서, 상기 제 2 동작 명령은 장치 관리 및 서비스 인에이블먼트(device management and service enablement) 인터페이스를 통해 수신되는 것을 특징으로 하는, 권한 인증 방법.
삭제
제 1 항에 있어서, 상기 타깃 리소스 그룹이 생성되면, 상기 제 2 접근 제어 리소스 그룹을 생성하는 단계를 더 포함하는 것을 특징으로 하는, 권한 인증 방법.
무선 통신 시스템에서 동작 명령에 대한 권한 인증을 위한 단말에 있어서,
송수신기; 및
상기 송수신기를 제어하도록 구성된 프로세서를 포함하되,
상기 프로세서는:
서버로부터 부트스트랩 인터페이스를 통해 타깃(target) 리소스 그룹을 위한 제 1 접근 제어 리소스 그룹을 생성하기 위한 제 1 동작 명령을 수신하고,
상기 제 1 동작 명령에 기반하여 상기 제 1 접근 제어 리소스 그룹을 생성하고,
상기 서버로부터 제 2 동작 명령을 수신하고,
상기 제 2 동작 명령이 상기 타깃 리소스 그룹을 생성하기 위한 동작 명령이면, 상기 타깃 리소스 그룹에 대해 설정된 상기 제 1 접근 제어 리소스 그룹에 기반하여 상기 제 2 동작 명령을 인증하고, 그리고
상기 제 1 접근 제어 리소스 그룹은 상기 타깃 리소스 그룹을 생성하기 위한 상기 동작 명령의 권한을 인증하는데 사용되고,
상기 제 2 동작 명령이 상기 타깃 리소스 그룹을 생성하기 위한 동작 명령이 아니면, 상기 타깃 리소스 그룹에 대해 설정된 제 2 접근 제어 리소스 그룹에 기반하여 상기 제 2 동작 명령을 인증하고,
상기 제 2 접근 제어 리소스 그룹은 상기 타깃 리소스 그룹을 생성하기 위한 동작 명령이 아닌, 적어도 하나의 동작 명령의 권한을 인증하는데 사용되고,
상기 제 1 접근 제어 리소스 그룹은 상기 타깃 리소스 그룹을 생성하기 위한 동작 명령을 지시하는 접근 제어 리스트(Access Control List; ACL) 및 상기 제1 접근 제어 리소스 그룹이 부트스트랩 절차 중에 생성됨을 지시하는 접근 제어 소유자 리소스를 포함하는 것을 특징으로 하는, 단말.
제8항에 있어서, 상기 프로세서는 상기 타깃 리소스 그룹을 위한 상기 제 2 접근 제어 리소스 그룹을 생성하는 것을 특징으로 하는, 단말.
삭제
삭제
삭제
삭제
삭제