KR20150079491A

KR20150079491A - 무선 통신 시스템에서 특정 리소스에 대한 접근 권한을 인증하기 위한 방법 및 장치

Info

Publication number: KR20150079491A
Application number: KR1020147022096A
Authority: KR
Inventors: 김성윤; 박승규
Original assignee: 엘지전자 주식회사
Priority date: 2012-10-30
Filing date: 2013-10-30
Publication date: 2015-07-08
Also published as: US20170215072A1; EP2819342A4; KR102245367B1; WO2014069898A1; US9654971B2; EP2819342A1; US10506432B2; CN104303454A; EP3185469A1; EP2819342B1; CN104303454B; US20150038115A1; EP3185469B1

Abstract

본 발명의 일 실시예에 따른 무선 통신 시스템에서 리소스에 대한 접근 권한을 인증하기 위한 방법에 있어서, 상기 방법은 단말에 의해 수행되며, 서버로부터 상기 단말의 특정 객체(object), 특정 객체 인스턴스(object instance) 또는 특정 객체 인스턴스에 속하는 리소스(이하, "동작 명령 대상" 이라 지칭함)에 대한 동작 명령(operation)을 수신하는 단계; 및 상기 동작 명령 대상과 연관된 접근 권한 정보에 기반하여 상기 서버에 대하여 상기 동작 명령 대상에 대한 접근 권한이 승인(grant)되었는지 여부를 체크하는 단계를 포함하되, 상기 방법은: 상기 동작 명령 대상에 대한 접근 권한이 승인되면, 상기 동작 명령및 상기 동작 명령 대상 중 적어도 하나에 기반하여 상기 동작 명령 대상에 속하는 적어도 하나의 리소스가 상기 동작 명령을 지원하는지 여부를 판단하는 단계를 더 포함하고, 상기 동작 명령 대상과 연관된 접근 권한 정보는 상기 적어도 하나의 리소스가 속하는 특정 객체 인스턴스에 대하여 특정될 수 있다.

Description

무선 통신 시스템에서 특정 리소스에 대한 접근 권한을 인증하기 위한 방법 및 장치{METHOD AND APPARATUS FOR AUTHENTICATING ACCESS AUTHORITY FOR SPECIFIC RESOURCE 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 클라이언트가 인증하기 위한 방법을 제시한다.

본 발명의 일 실시예에 따르면, M2M 서버 또는 M2M 서버로부터의 특정 동작 명령에 대한 접근 권한 인증을 수행하기 위한 방안을 제안하고자 한다.

또한, 본 발명의 다른 일 실시예에 따르면, M2M 시스템 내 단일 M2M 서버에서 다중 M2M 서버 환경으로의 전환 시에 권한 인증 절차를 지원하기 위한 방안을 제안하고자 한다.

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

바람직하게는, 상기 동작 명령 대상에 속하는 적어도 하나의 리소스가 상기 동작 명령을 지원하는지 여부를 판단하는 단계는: 상기 동작 명령 및/또는 상기 동작 명령 대상이 미리 결정된 명령 및/또는 동작 명령 대상인 경우에 수행될 수 있다.

바람직하게는, 상기 동작 명령 대상에 따라 지원가능한 동작 명령이 정의될 수 있다.

바람직하게는, 상기 수신된 동작 명령이 상기 동작 명령 대상에 대하여 지원되지 않는 경우, 상기 방법은 상기 서버로 상기 동작을 지원하지 않음을 알리기 위한 응답을 전송하는 단계를 포함할 수 있다.

바람직하게는, 상기 단말이 오직 하나의 서버 계정만을 가지고 있는 경우, 상기 서버가 상기 오직 하나의 서버이면, 상기 서버의 상기 동작 명령에 대한 접근 권한은 승인된 것으로 결정될 수 있다.

바람직하게는, 상기 서버는 모든 동작 명령에 접근 권한을 가질 수 있다.

바람직하게는, 상기 동작 명령 대상에 대한 접근 권한이 승인되지 않으면, 상기 방법은 상기 서버로 접근이 거절됨을 알리기 위한 응답을 전송하는 단계를 포함할 수 있다.

바람직하게는, 상기 동작 명령 대상에 대한 접근 권한이 승인되고, 상기 동작 명령이 미리 결정된 동작 명령(들)이고 상기 동작 명령 대상이 특정 객체 인스턴스에 대한 것이면; 상기 방법은 상기 동작 명령 대상에 속하는 적어도 하나의 리소스가 상기 동작 명령을 지원하는지 여부를 체크하지 않고, 상기 특정 객체 인스턴스에 대하여 상기 동작 명령을 수행하는 단계를 포함할 수 있다.

바람직하게는, 상기 서버에 대하여 상기 동작 명령 대상과 연관된 접근 권한 정보는 상기 특정 객체, 상기 특정 객체 인스턴스, 또는 상기 특정 객체 인스턴스에 속하는 리소스와 연관된 접근 제어 객체 인스턴스에서 획득될 수 있다.

바람직하게는, 상기 응답을 전송하는 단계는: 상기 동작 명령 대상 중 어떠한 동작 명령 대상으로 인하여 접근이 거절되었는지를 상기 서버에 알리는 단계를 포함할 수 있다.

본 발명의 다른 일 실시예에 따른 무선 통신 시스템에서 리소스에 대한 접근 권한을 생성하기 위한 방법에 있어서, 상기 방법은 단말에 의해 수행되며, 서버로부터 특정 서버의 계정을 추가하기 위한 동작 명령을 수신하는 단계; 및 상기 특정 서버의 계정을 추가하는 단계를 포함하되, 상기 방법은: 상기 특정 서버의 계정이 상기 단말이 오직 하나의 서버 계정만을 가지고 있는 경우에 추가되면, 상기 단말에 저장된 객체 인스턴스(들) 중 접근 제어 객체 인스턴스가 없는 객체에 대한 접근 제어 객체 인스턴스를 생성하는 단계를 더 포함하고, 상기 생성되는 접근 제어 객체 인스턴스의 접근 권한 제어 소유자는 상기 오직 하나의 서버 계정에 대응하는 서버일 수 있다.

바람직하게는, 상기 특정 서버의 계정은: 특정 값을 갖는 서버 보안 객체 인스턴스와 그와 연관된 서버 객체 인스턴스로 구성될 수 있다.

바람직하게는, 상기 특정 값은 상기 특정 서버가 부트스트랩 서버가 아님을 지시하는 정보일 수 있다.

바람직하게는, 상기 특정 서버의 계정은 부트스트랩 인터페이스를 통해 추가될 수 있다.

바람직하게는, 상기 오직 하나의 서버 계정에 대응하는 서버는 상기객체 인스턴스(들)에 대한 모든 권한을 가질 수 있다.

바람직하게는, 상기 접근 권한 제어 소유자는 접근 제어 객체 인스턴스를 변경할 수 있다.

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

본 발명의 일 실시예에 따르면, M2M 서버 또는 M2M 서버로부터의 특정 동작 명령에 대한 접근 권한 인증을 효율적으로 수행할 수 있다. 또한, 상기 접근 권한 인증이 계층적으로 수행됨에 따라 접근 권한 인증 절차의 신뢰도를 높일수 있다.

또한, 본 발명의 다른 일 실시예에 따르면, M2M 시스템 내 단일 M2M 서버에서 다중 M2M 서버 환경으로의 전환 시에 접근 제어 객체 인스턴스가 생성되지 않았던 객체 인스턴스를 위해 접근 제어 객체 인스턴스를 생성함으로써 접근 권한 인증 절차를 지원할 수 있다.

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

본 발명에 관한 이해를 돕기 위해 상세한 설명의 일부로 포함되는, 첨부 도면은 본 발명에 대한 실시예를 제공하고, 상세한 설명과 함께 본 발명의 기술적 사상을 설명한다.
도 1 은 M2M 클라이언트에 저장된 데이터(또는 자료) 구조를 도시한다.
도 2 는 본 발명의 일 실시예와 관련된 리소스 모델을 도시한다.
도 3 은 본 발명의 일 실시예와 관련된 인터페이스의 모델을 도시한다.
도 4 는 본 발명의 일 실시예에 따른 접근 권한 획득 방법의 순서도를 도시한다.
도 5 는 본 발명의 다른 실시예에 따른 동작 명령이 리소스에 대한 것일 경우의 인증 절차를 도시한다.
도 6 은 본 발명의 다른 실시예에 따른 객체 인스턴스에 대한 동작 명령에 대한 인증 절차를 도시한다.
도 7 은 본 발명의 실시예(들)을 구현하기 위한 장치의 블록도를 도시한다.

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

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

본 발명에 있어서, 기기간 통신을 위한 디바이스 즉, 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 클라이언트(client, 이하 DMC)는 개별 명령을 수행하기 전에 인증을 수행하고, 그 결과로 허가된 DM 명령만 수행하게 된다.

DM 트리

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

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

또한, 각 리소스에는 해당 리소스가 어떤 동작 명령(operation)을 지원하는지를 나타내기 위한 정보가 포함되거나 첨부되며, 상기 동작 명령은 예컨대 읽기(Read), 쓰기(Write), 실행(Execute), 쓰기 속성(Write Attribute), 탐색(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) (예컨대, 플래쉬에 저장) 또는 스마트카드로부터의 부트스트랩 (스마트카드에 저장)을 이용하여 정의된다.

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

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

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

이하, 본 발명의 일 실시예에 따른 부트스트랩 인테페이스에 대하여 좀더 상세하게 설명하도록 한다.

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

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

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

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

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

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

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

M2M 클라이언트는 부트스트랩 시퀀스 이후에 적어도 하나의 M2M 서버를 위한 부트스트랩 정보를 가질 수 있다. 또한, M2M 부트스트랩 서버를 위한 부트스트랩 정보를 가질 수 있다. 상기 M2M 서버를 위한 부트스트랩 정보는 M2M 서버에 등록 및 접속하기 위해 M2M 클라이언트를 위해 사용된다.

M2M 서버를 위한 부트스트랩 정보는 필수 정보인 M2M 서버 계정(Server Account)과 선택적으로 존재할 수 있는 다른 오브젝트 인스턴스(예컨데 권한 제어, 네트워크 연결 오브젝트 인스턴스)의 정보로 구성된다. M2M 서버 계정은 적어도 "부트스트랩 서버" 리소스가 "false" 로 설정된 M2M 서버 보안 객체 인스턴스와 M2M 서버 오브젝트를 포함할 수 있다.

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

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

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 내 값은 일 예시이며, 다르게 설정될 수 있음은 당업자에게 자명하다.

접근 권한 획득 방법

도 4 는 본 발명의 일 실시예에 따른 접근 권한 획득 방법의 순서도를 도시한다.

M2M 클라이언트는 ACL 을 획득할 수 있다(S301). M2M 클라이언트는 M2M 서버가 접근하려는 엔티티(객체 인스턴스 또는 리소스)가 속해있는 객체 인스턴스의 ACL 을 획득할 수 있다.

M2M 클라이언트는 서버 ID 가 맵핑된 짧은 서버 ID 를 찾을 수 있다(S302). M2M 클라이언트는 M2M 서버 ID 에 해당하는 짧은 서버 ID 를 맵핑 정보가 저장된 곳(예컨대, 계정)에서 찾을 수 있다.

한편, 상기 S301 및 S302 는 순서가 서로 바뀔 수 있다.

M2M 클라이언트는 ACL 로부터 짧은 서버 ID 를 갖는 ACL 엔트리를 가지고 있는지 판단할 수 있다(S303).

M2M 클라이언트는 S301 에서 획득한 ACL 로부터 짧은 서버 ID 가 포함되어 있는 ACL 엔트리를 찾을 수 있다. 해당 ACL 엔트리를 통해 짧은 서버 ID 에 해당하는 접근 권한을 얻어낼 수 있다.

M2M 클라이언트는 상기 ACL 엔트리로부터 상기 M2M 서버의 상기 접근하려는 엔티티로의 접근 권한을 획득할 수 있다(S304). 상기 S303 에서 상기 접근 권한을 찾은 경우, M2M 클라이언트는 해당 접근 권한을 획득할 수 있다.

M2M 클라이언트는 디폴트 ACL 엔트리를 갖는지 여부를 판단할 수 있다(S305). 상기 S303 에서 ACL 엔트리를 찾지 못했을 경우, 디폴트 ACL 엔트리가 있는지 여부를 확인할 수 있다.

상기 디폴트 ACL 엔트리가 있다면, M2M 클라이언트는 디폴트 ACL 엔트리로부터 접근 권한을 획득할 수 있다(S306).

상기 디폴트 ACL 엔트리가 없다면, 상기 M2M 클라이언트는 상기 M2M 서버의 상기 접근하려는 엔티티로의 접근 권한을 획득하는 것을 실패한다(S307). 즉, 상기 M2M 서버는 상기 접근하려는 엔티티에 접근 권한이 없다.

인증( Authorization )

본 발명의 다른 실시예에 따른 접근 권한 인증 방식은 해당 동작 명령의 대상이 리소스, 객체 인스턴스 또는 객체인지 여부에 따라 다르게 기술된다. 한편, 후술할 것처럼, 동작 명령의 대상, 즉 리소스, 객체 인스턴스 또는 객체에 따라 지원가능한 동작 명령이 다르게 정의될 수 있다.

- 리소스에 대한 동작 명령

도 5 는 본 발명의 다른 실시예에 따른 동작 명령이 리소스에 대한 것일 경우의 인증 절차를 도시한다.

M2M 서버는 리소스에 대한 동작 명령을 전송할 수 있다(S401). M2M 서버는 특정 리소스를 타깃하여 동작 명령을 M2M 클라이언트로 전송할 수 있다.

M2M 클라이언트는 상기 M2M 서버의 상기 특정 리소스의 접근 권한을 획득할 수 있다(S402). 상기 M2M 클라이언트는 위에서 설명한 접근 권한 획득 방법을 통해 상기 특정 리소스에 대한 접근 권한을 획득할 수 있다.

M2M 클라이언트는 상기 획득된 접근 권한에 의해 상기 동작 명령이 인증되는지를 판단할 수 있다(S403). M2M 클라이언트는 S402 에서 획득한 접근 권한을 이용하여 상기 동작 명령이 상기 M2M 서버에 대하여 승인되는지 여부를 확인할 수 있다. S402 에서 접근 권한의 획득이 실패하였다면, 해당 동작 명령은 수행 불가능하다.

M2M 클라이언트는 상기 리소스의 접근 유형(Access Type)을 획득할 수 있다(S404).

M2M 클라이언트는 상기 획득된 접근 유형에 의해 동작 명령이 인증되는지 여부를 판단할 수 있다(S405). M2M 클라이언트는 상기 S404 에서 획득된 접근 유형이 상기 동작 명령을 지원하는지 여부를 확인한다.

상기 획득된 접근 유형이 상기 동작 명령을 지원하면, 상기 동작 명령에 대한 인증이 성공적으로 종료된다(S406). 상기 인증이 성공할 경우, M2M 클라이언트는 해당 동작 명령을 수행하고, 그에 대한 응답이 필요할 경우 이에 대한 응답을 전송할 수 있다.

상기 획득된 접근 유형이 상기 동작 명령을 지원하지 않으면, 상기 동작 명령에 대한 인증은 실패로 종료된다(S407). 실패할 경우, 상기 M2M 클라이언트는 인증 실패 메시지를 전송할 수 있다. 이 때, 상기 M2M 클라이언트는 접근 권한에 의한 에러인지 또는 리소스의 접근 유형에 의한 에러인지를 명시할 수 있다.

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

도 6 은 본 발명의 다른 실시예에 따른 객체 인스턴스에 대한 동작 명령에 대한 인증 절차를 도시한다.

M2M 서버는 객체 인스턴스에 대한 동작 명령을 M2M 클라이언트로 전송할 수 있다(S501).

M2M 클라이언트는 상기 M2M 서버의 상기 객체 인스턴스에 대한 접근 권한을 획득할 수 있다(S502). 상기 접근 권한의 획득은 앞서 설명한 접근 권한 획득 방법에 따라 수행될 수 있다.

M2M 클라이언트는 상기 획득된 접근 권한에 의해 상기 동작 명령이 인증되는지 여부를 판단할 수 있다(S503). M2M 클라이언트는 S502 에서 획득된 접근 권한을 통해 상기 동작 명령이 지원가능한지 여부를 판단할 수 있다. S502 에서 접근 권한의 획득이 실패하였다면, 해당 동작 명령은 수행 불가능하다.

M2M 클라이언트는 객체 인스턴스에 포함된 각각의 리소스 중 상기 동작 명령의 대상인 리소스의 접근 유형을 획득할 수 있다(S504).

M2M 클라이언트는 상기 획득된 접근 유형에 의해 상기 동작 명령이 인증되는지 여부를 판단할 수 있다(S505). M2M 클라이언트는 상기 획득된 접근 유형에 기반하여 상기 객체 인스턴스 내 각 상기 동작 명령의 대상인 리소스가 상기 동작 명령을 지원하는지 여부를 확인할 수 있다.

상기 객체 인스턴스의 동작 명령의 대상인 리소스가 상기 동작 명령을 지원하면, 상기 인증 절차는 성공으로 종료된다(S506). 상기 인증 절차가 성공되면, 상기 M2M 클라이언트는 해당 리소스에 대한 동작 명령을 수행할 수 있고, 필요시에 응답을 M2M 서버로 전송할 수 있다.

그러나, 상기 객체 인스턴스의 동작 명령의 대상인 리소스가 상기 동작 명령을 지원하지 않으면, 상기 인증 절차는 실패로 종료한다(S507). 상기 인증 절차가 실패된 경우, M2M 클라이언트는 인증 실패 메시지를 M2M 서버로 전송할 수 있다. 이 때, 상기 실패가 접근 권한으로 인한 실패인지 또는 접근 유형으로 인한 실패인지를 명시할 수 있고, 에러가 발생한 해당 리소스에 관한 정보도 명시할 수 있다.

상기 S504 내지 S507 은 상기 객체 인스턴스 내 포함된 모든 리소스에 대해 수행될 수 있다. 즉, 인증이 성공된 리소스에 대한 동작 명령 수행 및/또는 응답이 수행될 수 있고, 인증이 실패된 리소스에 대한 동작 명령은 수행되지 않으며 그에 대한 실패 메시지가 보고될 수 있다.

또는, 본 발명의 다른 일 실시예로서, 상기 객체 인스턴스 내 어떤 리소스라도 상기 동작 명령을 지원하지 않으면 상기 동작 명령의 수행이 이루어지지 않을 수 있다. 또한 이 경우, 상기 객체 인스턴스 내 모든 리소스에 대한 인증 절차는 실패로 종료되며, 상기 실패 메시지가 상기 M2M 서버로 전송될 수 있다. 이 때, 상기 실패가 접근 권한으로 인한 실패인지 또는 접근 유형으로 인한 실패인지를 명시할 수 있고, 에러가 발생한 해당 리소스에 관한 정보도 명시할 수 있다.

접근 권한 제어 핸들링( Access Control Handling )

접근 권한 제어의 경우, M2M 시스템 내 하나의 M2M 서버만이 존재하거나 M2M 클라이언트에 등록된 M2M 서버가 하나라면(이하, 이를 간단히 "하나의 서버가 존재" 한다고 표현하도록 함), 상기 하나의 서버가 동작 명령에 대한 모든 접근 권한을 가지는 것이 타당하다. 이 때, 모든 접근 권한을 가지더라도, 즉 체크는 하지 않지만, M2M 클라이언트는 접근 권한 제어 객체 인스턴스를 가질 수도 있으며, 아니면, 접근 권한 제어 객체 인스턴스는 존재하지 않을 수 있다.

- 접근 제어 객체 인스턴스를 가질 경우

하나의 서버가 존재할 시, 상기 서버가 "Create" 동작 명령을 전송하거나, 부트스트랩을 통해 제공된 정보(Object Instance)에 대해 M2M 클라이언트는 모든 접근 권한을 가지도록 접근 제어 객체 인스턴스를 설정한다. 이때, 상기 M2M 클라이언트는 상기 접근 제어에 대한 소유자(상기 접근 제어를 설정할 수 있는 엔티티)를 상기 하나의 서버로 설정할 수 있다.

- 접근 제어 객체 인스턴스를 가지지 않을 경우

하나의 서버가 존재할 시, 상기 서버는 접근 제어 객체 인스턴스를 가지지 않으나, 이 때 만약에 하나의 서버가 새롭게 추가될 경우(즉, 서버 계정 관련 객체 인스턴스가 추가될 경우), M2M 클라이언트가 자동적으로 기존 하나의 서버에 대한 접근 제어 객체 인스턴스를 생성할 수 있다. 이 때, ACL 정보는 종래 존재하던 리소스에 대해 해당 서버가 모든 권한을 가지도록 설정할 수 있다. 즉, M2M 클라이언트는 상기 접근 제어 객체 인스턴스의 접근 제어 권한의 소유자를 기존의 하나의 서버로 설정할 수 있다.

- 접근 제어 선택 사항

여러 서버 존재 여부와 상관 없이 모든 M2M 서버의 접근을 허용한다. 즉, 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 서버가 동작 명령을 수행하기 위한 접근 권한을 갖고 있는지 여부를 체크하기 위해 사용된다. 각각의 접근 제어 객체 인스턴스는 M2M 클라이언트 안의 특정 객체 인스턴스에 대한 ACL(Access Control List)를 포함한다.

[표 5]

- 인증 절차

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)하고, 상기 검색된 리소스(들) 정보를 상기 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 클라이언트는 상기 "읽기" 동작 명령을 지원하지 않는 리소스(들)을 제외한 모든 리소스들을 검색하고 상기 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 서버의 접근 권한의 소유 여부는 상기 객체에 대한 특정 동작 명령에 따라 상기 접근 권한 획득 방법에 의해 수행될 지 여부가 결정된다. 그리고 나서, 상기 객체 인스턴스에 속한 개별 리소스(들)이 상기 동작 명령을 지원하는지 여부가 확인되며, 이 과정은 상기 동작 명령의 종류에 따라 수행되거나 수행되지 않을 수 있다. 또한, 객체에 대한 동작 명령의 경우 특정 동작 명령에 대해서는 접근 권한 소유 여부와 상기 특정 동작 명령의 지원 여부에 대해 확인하지 않을 수도 있다.

- 통지시 고려 사항( Notify Consideration )

만약 상기 M2M 클라이언트가 객체 인스턴스 또는 리소스를 포함하는 "통지(Notify)" 동작 명령을 상기 M2M 서버로 전송할 필요가 있으면, 상기 M2M 클라이언트는 상기 M2M 서버가 "읽기" 동작 명령에 대해 인증되었는지 여부를 체크해야 한다. 만약 상기 M2M 서버가 인증되지 않으면, 상기 M2M 클라이언트는 "통지" 동작 명령을 전송해서는 안되며, "취소 관측(Cancel Observation)" 동작 명령을 수행할 수 있다. 상기 관측 동작 명령이 객체를 타깃한 경우, 상기 M2M 클라이언트는 "취소 관측" 동작 명령을 수행하면 안되고, 상기 관측 동작 명령이 객체 인스턴스 또는 리소스를 타깃한 경우엔 상기 M2M 클라이언트는 "취소 관측" 동작 명령을 수행할 수 있다.

- 지원되는 동작(접근 유형) 고려 사항

해당 M2M 서버가 특정 동작 명령(여러 동의어 존재 가능함, 예컨대 명령(command), 로직 동작 명령(logical operation))에 대해 권한이 있다고 하여 해당 자원에 대해 상기 특정 동작 명령을 수행할 수 있는 것은 아니다. 자원에도 자원이 지원하는 동작 명령이 정의되어 있고, M2M 클라이언트는 이를 고려하여 M2M 서버가 자원에 대해 해당 동작 명령을 수행할 수 있는지 여부를 결정한다.

- 자동 구성( Auto configuration )

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

M2M 서버 계정의 추가에 따른 접근 제어 관련 동작

본 발명의 또 다른 일 실시예에 따라 M2M 클라이언트에 하나의 M2M 서버 계정만이 존재하다가 또 다른 M2M 서버 계정이 새롭게 추가될 경우, M2M 클라이언트의 동작을 설명하도록 한다.

상기 M2M 클라이언트에 존재하는 객체 인스턴스들에 대한 접근 제어 객체 인스턴스를 생성하거나 이미 상기 접근 제어 객체 인스턴스가 존재하는 경우 상기 접근 제어 객체 인스턴스를 수정한다. 접근 제어 객체 인스턴스 내의 객체 ID 자원의 값에는 존재하는 객체 인스턴스의 객체 ID 를 설정하고, 객체 인스턴스 ID 자원의 값에는 존재하는 객체 인스턴스의 객체 인스턴스 ID 를 설정한다. 접근 제어 객체 인스턴스 안의 ACL 자원에는 기존 존재하던 하나의 M2M 서버(상기 M2M 서버를 지시할 수 있는 식별자)가 해당 객체 인스턴스에 대해 모든 권한을 가지도록 설정한다. 접근 제어 객체 인스턴스 내의 접근 제어 소유자에는 기존 존재하던 하나의 M2M 서버(상기 M2M 서버를 지칭할 수 있는 식별자)를 설정한다.

좀더 상세히 설명하면, M2M 클라이언트가 오직 하나의 M2M 서버 계정을 가지고 있는 경우에 새로운 M2M 서버 계정이 추가되면, 상기 M2M 클라이언트는 상기 M2M 클라이언트에 있는 모든 객체 인스턴스에 대해, 좀더 바람직하게는 서버 보안 객체 인스턴스 및 접근 제어 객체 인스턴스를 제외하고 모든 객체 인스턴스에 대해 접근 제어 객체 인스턴스들을 생성하거나 수정할 수 있다. 이 경우, 다음과 같은 룰(rule)에 따라 상기 접근 제어 객체 인스턴스의 생성 또는 수정이 이루어진다.

·접근 제어 소유자는 이전에 존재하던 (계정의) M2M 서버로 설정됨

·이전에 존재하던 M2M 서버는 모든 접근 권한을 갖도록 설정됨

본 발명의 또 다른 일 실시예에 따라 M2M 클라이언트에 둘 이상의 M2M 서버 계정만이 존재하다가 또 다른 M2M 서버 계정이 새롭게 추가될 경우, M2M 클라이언트의 동작을 설명하도록 한다.

두 개의 M2M 서버 계정이 존재할 경우, 어떤 객체 인스턴스를 특정 M2M 서버가 생성할 경우 해당 객체 인스턴스에 관련 접근 제어 객체 인스턴스를 자동으로 생성하는데, 접근 제어 객체 인스턴스에 대한 세팅은 아래와 같다.

객체 ID 와 객체 인스턴스 ID 자원은 "생성(Create)" 동작 명령으로 인해 생성된 객체 인스턴스의 객체 ID 와 객체 인스턴스 ID 를 갖는다.

ACL 자원은 "생성(Create)" 동작 명령을 수행한 M2M 서버(상기 M2M 서버를 지칭할 수 있는 식별자)가 모든 권한을 갖도록 설정된다.

접근 제어 소유자는 M2M 서버(상기 M2M 서버를 지칭할 수 있는 식별자)가 설정된다.

두 개의 M2M 서버 계정에서 더 추가될 경우 추가적인 프로시저는 존재하지 않는다.

좀더 상세하게는, M2M 클라이언트가 둘 이상의 M2M 서버 계정을 가지고 있고 이 때 둘 중 하나의 M2M 서버가 특정 객체 인스턴스에 대해 "생성(Create)" 동작 명령을 전송하면, 상기 M2M 클라이언트는 상기 생성된 객체 인스턴스에 대한 접근 제어 객체 인스턴스를 생성할 수 있다. 이 경우, 다음과 같은 룰(rule)에 따라 상기 접근 제어 객체 인스턴스의 생성 또는 수정이 이루어진다.

·접근 제어 소유자는 상기 "생성" 동작 명령을 전송한 M2M 서버로 설정됨

·상기 M2M 서버는 모든 접근 권한을 갖도록 설정됨

M2M 서버 계정 추가

M2M 서버 계정은 M2M 서버 보안 객체 인스턴스(부트스트랩(bootstrap) 서버 리소스가 "false" 로 설정된)와 그와 연관된 M2M 서버 객체 인스턴로 구성된다. 참고로, M2M 부트 스트랩 서버 계정은 부트스트랩 서버 리소스가 "true" 로 설정된 M2M 서버 보안 객체 인스턴스로 구성된다.

상기 M2M 서버 계정은 M2M 서버 부트스트랩 정보에 포함되며, 상기 M2M 서버 부트스트랩 정보는 M2M 클라이언트가 M2M 서버에 등록하거나 접속하기 위해 사용된다.

상기 M2M 서버 부트스트랩 정보는 부트스트랩 인터페이스를 통해 상기 M2M 클라이언트로 설정되며, 부트스트랩은 공장(factory) 부트스트랩, 스마트카드에 의한 부트스트랩, 클라이언트-개시 또는 서버-개시 부트스트랩으로 분류될 수 있다.

이하는 서버 보안 객체(LWM2M Security Object) 인스턴스와 서버 객체(LWM2M Server Object) 인스턴스를 설명한다.

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

[표 6]

[표 7]

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

[표 8]

[표 9]

선택적 자원 탐색

본 발명의 또 다른 일 실시예에 따른 탐색(Discover) 기능에 대해 설명하도록 한다.

M2M 서버와 M2M 클라이언트가 특정 자원군(예컨대, M2M 에서의 객체(Object))에 대한 정보(예컨대, M2M 에서의 객체 설명(Object Specification) 또는 그에 상응하는 정보)를 공유하고 있을 경우, 해당 자원이 실제 구현 상에서 구현되었는지 여부를 확인할 수 있는 방법이 필요하다. 왜냐하면 자원군의 모든 자원이 구현되어야 되는 것은 아니고, 자원 중에 필수(mandatory) 자원이 있으며, 선택(optional) 자원이 있으므로, M2M 서버는 M2M 클라이언트에서 선택 자원들 중에 실제로 구현된 자원이 무엇인지 알 필요가 있다.

이에 M2M 서버는 M2M 클라이언트의 특정 자원군에 대해 어떤 자원(예컨대, M2M 에서는 "리소스" )들이 실제 구현되어 있는지 확인이 필요하다. 이에 따라, 상기 M2M 서버는 M2M 클라이언트의 특정 자원군을 타겟으로 하여 어떤 선택 자원이 구현되었는지 문의할 수 있으며, 상기 M2M 클라이언트는 이에 대한 답으로 실제 구현된 선택 자원에 대한 정보를 상기 M2M 서버에 전달할 수 있다.

- 선택 자원 구현 문의 요청의 타깃(Target)

·특정 자원군 또는 M2M 클라이언트가 지원하는 전체 자원군들

- 선택 자원 구현 문의 응답

·특정 자원군을 타깃할 경우 특정 자원군의 구현 자원(들) 또는 전체 자원군을 타깃할 경우 M2M 클라이언트가 지원하는 전체 자원군들 중 구현 자원군(들) 또는,

·특정 자원군을 타깃할 경우 특정 자원군의 구현 자원(들) 또는 M2M 클라이언트가 지원하는 전체 자원군들 중의 선택 자원군들 중의 구현 자원군(들) 정보

이러한 기능은 M2M 클라이언트가 지원하는 자원군 전체의 포맷(format)을 보내지 않으면서 기존에 공유된 정보와 탐색을 통해서 얻은 부분 정보를 통해 전체 포맷을 공유한 것과 같은 효과를 가지게 된다.

이하, 앞서 설명한 실시예들에서 기술한 본 명세서에서 사용되는 동작 명령 및 객체 (인스턴스)에 대한 설명을 간략히 하도록 한다.

·읽기(Read)

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

[표 10]

·탐색(Discover)

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

[표 11]

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

·쓰기(Write)

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

[표 12]

·쓰기 속성(Write Attributes)

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

[표 13]

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

·실행(Execute)

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

[표 14]

·생성 (Create)

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

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

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

[표 15]

·삭제(Delete)

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

[표 16]

·관측(Observe)

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

[표 17]

·취소 관측(Cancel Observe)

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

[표 18]

도 7 은 본 발명의 실시예(들)을 수행하도록 구성된 장치의 블록도를 도시한다. 전송장치(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

무선 통신 시스템에서 리소스에 대한 접근 권한을 인증하기 위한 방법에 있어서, 상기 방법은 단말에 의해 수행되며,
서버로부터 상기 단말의 특정 객체(object), 특정 객체 인스턴스(object instance) 또는 특정 객체 인스턴스에 속하는 리소스(이하, "동작 명령 대상" 이라 지칭함)에 대한 동작 명령(operation)을 수신하는 단계; 및
상기 동작 명령 대상과 연관된 접근 권한 정보에 기반하여 상기 서버에 대하여 상기 동작 명령 대상에 대한 접근 권한이 승인(grant)되었는지 여부를 체크하는 단계를 포함하되, 상기 방법은:
상기 동작 명령 대상에 대한 접근 권한이 승인되면, 상기 동작 명령 및 상기 동작 명령 대상 중 적어도 하나에 기반하여 상기 동작 명령 대상에 속하는 적어도 하나의 리소스가 상기 동작 명령을 지원하는지 여부를 판단하는 단계를 더 포함하고,
상기 동작 명령 대상과 연관된 접근 권한 정보는 상기 적어도 하나의 리소스가 속하는 특정 객체 인스턴스에 대하여 특정된 것을 특징으로 하는, 접근 권한 인증 방법.
제 1 항에 있어서, 상기 동작 명령 대상에 속하는 적어도 하나의 리소스가 상기 동작 명령을 지원하는지 여부를 판단하는 단계는:
상기 동작 명령 및/또는 상기 동작 명령 대상이 미리 결정된 명령 및/또는 동작 명령 대상인 경우에 수행되는 것을 특징으로 하는, 접근 권한 인증 방법.
제 1 항에 있어서, 상기 동작 명령 대상에 따라 지원가능한 동작 명령이 정의되는 것을 특징으로 하는, 접근 권한 인증 방법.
제 3 항에 있어서, 상기 수신된 동작 명령이 상기 동작 명령 대상에 대하여 지원되지 않는 경우, 상기 서버로 상기 동작을 지원하지 않음을 알리기 위한 응답을 전송하는 단계를 포함하는 것을 특징으로 하는, 접근 권한 인증 방법.
제 1 항에 있어서, 상기 단말이 오직 하나의 서버 계정만을 가지고 있는 경우,
상기 서버가 상기 오직 하나의 서버이면, 상기 서버의 상기 동작 명령에 대한 접근 권한은 승인된 것으로 결정되는 것을 특징으로 하는, 접근 권한 인증 방법.
제 5 항에 있어서, 상기 서버는 모든 동작 명령에 접근 권한을 갖는 것을 특징으로 하는, 접근 권한 인증 방법.
제 1 항에 있어서, 상기 동작 명령 대상에 대한 접근 권한이 승인되지 않으면, 상기 서버로 접근이 거절됨을 알리기 위한 응답을 전송하는 단계를 포함하는 것을 특징으로 하는, 접근 권한 인증 방법.
제 1 항에 있어서, 상기 동작 명령 대상에 대한 접근 권한이 승인되고, 상기 동작 명령이 미리 결정된 동작 명령(들)이고 상기 동작 명령 대상이 특정 객체 인스턴스에 대한 것이면;
상기 동작 명령 대상에 속하는 적어도 하나의 리소스가 상기 동작 명령을 지원하는지 여부를 체크하지 않고, 상기 특정 객체 인스턴스에 대하여 상기 동작 명령을 수행하는 단계를 포함하는 것을 특징으로 하는, 접근 권한 인증 방법.
제 1 항에 있어서, 상기 서버에 대하여 상기 동작 명령 대상과 연관된 접근 권한 정보는 상기 특정 객체, 상기 특정 객체 인스턴스, 또는 상기 특정 객체 인스턴스에 속하는 리소스와 연관된 접근 제어 객체 인스턴스에서 획득되는 것을 특징으로 하는, 접근 권한 인증 방법.
제 7 항에 있어서, 상기 응답을 전송하는 단계는:
상기 동작 명령 대상 중 어떠한 동작 명령 대상으로 인하여 접근이 거절되었는지를 상기 서버에 알리는 단계를 포함하는 것을 특징으로 하는, 접근 권한 인증 방법.
무선 통신 시스템에서 리소스에 대한 접근 권한을 생성하기 위한 방법에 있어서, 상기 방법은 단말에 의해 수행되며,
서버로부터 특정 서버의 계정을 추가하기 위한 동작 명령을 수신하는 단계; 및
상기 특정 서버의 계정을 추가하는 단계를 포함하되, 상기 방법은:
상기 특정 서버의 계정이 상기 단말이 오직 하나의 서버 계정만을 가지고 있는 경우에 추가되면, 상기 단말에 저장된 객체 인스턴스(들) 중 접근 제어 객체 인스턴스가 없는 객체에 대한 접근 제어 객체 인스턴스를 생성하는 단계를 더 포함하고,
상기 생성되는 접근 제어 객체 인스턴스의 접근 권한 제어 소유자는 상기 오직 하나의 서버 계정에 대응하는 서버인 것을 특징으로 하는, 접근 권한 생성 방법.
제 11 항에 있어서, 상기 특정 서버의 계정은:
특정 값을 갖는 서버 보안 객체 인스턴스와 그와 연관된 서버 객체 인스턴스로 구성된 것을 특징으로 하는, 접근 권한 생성 방법.
제 12 항에 있어서, 상기 특정 값은 상기 특정 서버가 부트스트랩 서버가 아님을 지시하는 정보인 것을 특징으로 하는, 접근 권한 생성 방법.
제 11 항에 있어서, 상기 특정 서버의 계정은 부트스트랩 인터페이스를 통해 추가되는 것을 특징으로 하는, 접근 권한 생성 방법.
제 11 항에 있어서, 상기 오직 하나의 서버 계정에 대응하는 서버는 상기 객체 인스턴스(들)에 대한 모든 권한을 갖는 것을 특징으로 하는, 접근 권한 생성 방법.
제 11 항에 있어서, 상기 접근 권한 제어 소유자는 접근 제어 객체 인스턴스를 변경할 수 있는 것을 특징으로 하는, 접근 권한 생성 방법.