【명세서】
【발명의 명칭】
무선 통신 시스템에서 특정 리소스에 대한 정보 갱신을 위한 방법 및 장치 【기술분야】
[1] 본 발명은 무선 통신 시스템에서 특정 리소스에 대한 정보 갱신을 위한 방 법 및 이를 위한 장치에 관한 것이다.
【배경기술】
[2] 유비쿼터스 시대에 접어들면서 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 부트스트랩 서버로부터 의 특정 리소스에 대한 정보 갱신 방법을 제시한다.
【발명의 상세한 설명】
【기술적 과제】
[3] 본 발명의 일 실시예에 따르면, M2M 서버 또는 M2M 부트스트랩 서버로부터 의 특정 리소스에 대한 정보 갱신, 즉 부분적 정보 갱신을 수행하기 위한 방안을 제안하고자 한다.
[4] 본 발명이 이루고자 하는 기술적 과제들은 이상에서 언급한 기술적 과제들 로 제한되지 않으며, 언급되지 않은 또 다른 기술적 과제들은 이하의 발명의 상세 한 설명으로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확 하게 이해될 수 있을 것이다.
【기술적 해결방법】
[5] 본 발명의 일 실시예에 따른 무선 통신 시스템에서 특정 리소스에 대한 부 트스트랩 정보를 갱신하기 위한 방법에 있어서, 상기 방법은 단말에 의해 수행되 며, 서버로부터 상기 단말의 객체 인스턴스 (object instance) 또는 객체 인스턴스 에 속하는 리소스에 대한 특정 동작 명령을 수신하는 단계; 및 상기 특정 동작 명 령이 특정 인터페이스를 통해 수신되면, 상기 특정 동작 명령에 대한 타깃이 상기 단말 내 존재하는지 여부와 관계 없이 상기 특정 동작 명령을 수행하는 단계를 포 함할 수 있다.
[6] 바람직하게는, 상기 방법은 상기 특정 동작 명령이 상기 특정 인터페이스 를 통해 수신되었는지 여부를 판단하는 단계를 더 포함할 수 있다.
[7] 바람직하게는, 상기 특정 동작 명령은 쓰기 동작 명령 또는 생성 동작 명 령 중 하나일 수 있다.
[8] 바람직하게는, 상기 특정 동작 명령이 상기 특정 인터페이스를 통해 수신 될 경우, 상기 특정 동작 명령에 대한 접근 제어를 수행하지 않을 수 있다.
[9] 바람직하게는, 상기 방법은 상기 특정 동작 명령을 전송한 서버와 특정 객 체 인스턴스에 포함된 특정 리소스에 의해 지시되는 서버가 동일한지 여부를 판단 하는 단계를 더 포함할 수 있다.
[10] 바람직하게는, 상기 특정 객체 인스턴스는 M2M 서버 보안 객체 인스턴스일 수 있다.
[11] 바람직하게는, 상기 특정 리소스는 M2M 서버의 식별자를 지시하는 리소스 와 부트스트램 서버를 지시하는 리소스를 포함할 수 있다.
[12] 바람직하게는, 상기 특정 동작 명령이 새로운 서버 계정의 추가를 위한 것 이면, 상기 방법은 M2M 서버 보안 객체 인스턴스 및 그와 연관된 M2M 서버 객체 인스턴스 생성하는 단계를 포함할 수 있다.
[13] 바람직하게는, 상기 새로운 서버 계정의 추가를 위한 특정 동작 명령이 상 기 단말에 오직 하나의 서버 계정만이 존재하는 경우 수신되면, 상기 방법은 상기 생성된 M2M서버 객체 인스턴스에 대한 각각의 접근 제어 객체 인스턴스를 생성하 는 단계를 포함할 수 있다.
[14] 바람직하게는, 상기 특정 동작 명령이 특정 M2M 서버 보안 객체 및 그와 연관된 M2M 서버 보안 객체 인스턴스 그리고 특정 M2M 서버 객체 및 그와 연관된
M2M 서버 객체 인스턴스를 지시하면, 상기 방법은 상기 특정 M2M 서버 보안 객체 인스턴스 및 상기 특정 M2M 서버 객체 인스턴스를 생성하는 단계를 포함할 수 있 다.
[15] 바람직하게는, 상기 특정 동작 명령이 상기 단말에 오직 하나의 서버 계정 만이 존재하는 경우 수신되면, 상기 방법은 상기 생성된 M2M 서버 객체 인스턴스 에 대한 각각의 접근 제어 객체 인스턴스를 생성하는 단계를 포함할 수 있다.
[16] 무선 통신 시스템에서 특정 리소스에 대한 부트스트램 정보를 갱신하도록 구성된 단말에 있어세 상기 단말은 무선 주파수 (radio frequency, RF) 유닛; 및 상기 RF 유닛을 제어하도록 구성된 프로세서를 포함하되, 상기 프로세서는 서버로 부터 상기 단말의 객체 인스턴스 (object instance) 또는 객체 인스턴스에 속하는 리소스에 대한 특정 동작 명령을 수신하고, 상기 특정 동작 명령이 특정 인터페이 스를 통해 수신되면, 상기 특정 동작 명령에 대한 타깃이 상기 단말 내 존재하는 지 여부와 관계 없이 상기 특정 동작 명령을 수행하도록 구성될 수 있다.
[17] 상기 과제 해결방법들은 본 발명의 실시예들 중 일부에 불과하며, 본 발명 의 기술적 특징들이 반영된 다양한 실시예들이 당해 기술분야의 통상적인 지식을 가진 자에 의해 이하 상술할 본 발명의 상세한 설명을 기반으로 도출되고 이해될 수 있다.
【유리한 효과】
[18] 본 발명의 일 실시예에 따르면, M2M 서버 또는 M2M 서버로부터의 특정 리 소스에 대한 갱신을 효율적으로 수행할 수 있다. 본 발명에 따른 효과는 이상에서 언급한 효과들로 제한되지 않으며, 언급되지 않은 또 다른 효과는 이하의 발명의 상세한 설명으로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
【도면의 간단한 설명】
[19] 본 발명에 관한 이해를 돕기 위해 상세한 설명의 일부로 포함되는, 첨부 도면은 본 발명에 대한 실시예를 제공하고, 상세한 설명과 함께 본 발명의 기술적 사상을 설명한다 .
[20] 도 1은 M2M 클라이언트에 저장된 데이터 (또는 자료) 구조를 도시한다.
[21] 도 2는 본 발명의 일 실시예와 관련된 리소스 모델을 도시한다.
[22] 도 3은 본 발명의 일 실시예와 관련된 인터페이스의 모델을 도시한다.
[23] 도 4는 본 발명의 일 실시예에 따른 정보 갱신 방법의 순서도를 도시한다
[24] 도 5는 본 발명의 일 실시예에 따른 정보 갱신 방법의 순서도를 도시한다
[25] 도 6은 본 발명의 일 실시예에 갱신 방법의 순서도를 도시한다
[26] 도 7은 본 발명의 일 실시예에 갱신 방법의 순서도를 도시한다 [27] 도 8은 본 발명의 일 실시예에 따른 정보 갱신 방법의 순서도를 도시한다
[28] 도 9 는 본 발명의 실시예 (들)을 구현하기 위한 장치의 블록도를 도시한다
【발명의 실시를 위한 형태】
[29] 이하, 본 발명에 따른 바람직한 실시 형태를 첨부된 도면을 참조하여 상세 하게 설명한다. 첨부된 도면과 함께 이하에 개시될 상세한 설명은 본 발명의 예시 적인 실시형태를 설명하고자 하는 것이몌 본 발명이 실시될 수 있는 유일한 실시 형태를 나타내고자 하는 것이 아니다. 이하의 상세한 설명은 본 발명의 완전한 이 해를 제공하기 위해서 구체적 세부사항을 포함한 fti다. 그러나, 당업자는 본 발명이 이러한 구체적 세부사항 없이도 실시될 수 있음을 안다.
[30] 몇몇 경우, 본 발명의 개념이 모호해지는 것을 피하기 위하여 공지의 구조 및 장치는 생략되거나, 각 구조 및 장치의 핵심기능을 중심으로 한 블록도 형식으 로 도시될 수 있다. 또한, 본 명세서 전체에서 동일한 구성요소에 대해서는 동일 한 도면 부호를 사용하여 설명한다 .
[31] 본 발명에 있어서, 기기간 통신을 위한 디바이스 즉, M2M클라이언트 또는 단말은 고정되거나 이동성을 가질 수 있으며, 기기간 통신을 위한 서버 즉, M2M 서버 또는 서버와 통신하여 사용자데이터 및 /또는 각종 제어정보를 송수신하는 각 종 기기들이 이에 속한다. 상기 M2M 클라이언트는 단말 (Terminal Equipment), MS (Mobile Station), MT(Mobile Terminal), UTCUser Terminal), SS(Subscribe Station), 무선기기 (wireless device), PDA(Personal Digital Assistant), 무선 모뎀 (wireless modem) , 휴대기기 (handheld device) 등으로 불릴 수 있다. 또한, 본 발명에 있어세 M2M 서버는 일반적으로 M2M 단말들 및 /또는 다른 M2M 서버와 통신하는 고정된 지점 (fixed station)을 말하며, M2M단말들 및 /또는 다른 M2M서 버와 통신하여 각종 데이터 및 제어정보를 교환한다.
[32] 이하에서는 본 발명과 관련된 배경기술에 대해 설명한다.
[33] 장치 관리 ( Dev i ce Management )
[34] 장치 관리 (DM; Device Management )는 다양한 관리 당국 (Management Authorities)들의 관점에서 장치 구성 및 장치들의 다른 관리된 객체를 관리하는 것을 지칭한다. 장치 관리는 장치들 내의 끊임없이 지속되는 정보의 순차적인 업 데이트들, 장치들로부터 관리 정보의 검색, 및 장치들에 의해 생성된 이벤트들과 알람들의 처리를 포함하나, 장치들 내의 초기 구성 정보를 설정하는 것에 한정되 지 않는다 (Management of the Device conf igur t ion 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 conf igurat ion information in Devices, subsequent updates of persistent information in Devices , retrieval of management information from Devices and processing events and alarms generated by Devices . )
[35] 관리 트리 (Management Tree)
[36] 관리 트리는 관리 서버가 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 트리와 상호호환 가능하게 지칭될 수 있다.
[37] M0 (관리 객체; Management Object)
[38] 관리 객체는 서로 몇몇 방식으로 관련된 노드들의 집합 (하나의 노드 단독 으로도 가능)이 될 것이 의도된 관리 트리의 서브 트리이다. 예컨대, ./Devlnfo 노드와 그 자식 노드들은 관리 객체를 형성할 수 있다. 간단한 관리 객체는 하나 의 단독 (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 ./Devlnfo Nodes form a Management Object . A simple Management Object may consist of one single Node.)
[39] DM Server (Device Management Server)
[40] DM서버 (DM Server)는 상기 DM서버에 대해 특정된 OMA 장치 관리 인에이 블러 (Enabler) 고정 적합 (static conformance) 요구사항들을 따르는 장치 관리 인 프라스트럭쳐에 있는 개념적인 소프트웨어 컴포넌트일 수 있다. 상기 DM 서버는 DM 클라이언트 -서버 프로토콜 및 DM 서버 -서버 인터페이스의 엔드—포인트로서 서 비스할 수 있다 (An abstract software component in a de loyed 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 CI ient -Server Protocols and DM Server-Server Interface) .
[41] 또한, 본 명세서에서 DM서버는 통신모들, 프로세서모들 등을 구비하는 장 치, 디바이스, 컴퓨터 둥 내에 탑재된 채로 제공될 수 있으몌 따라서 하나의 장 치로서 구현될 수 있다.
[42] DM Client (Device Management CI ient)
[43] DM 클라이언트 (DM CI ient)는 상기 DM 클라이언트에 대해 특정된 OMA 장치 관리 인에이블러 (Enabler) 고정 적합 (static conformance) 요구사항들을 따르는 장치 임플리멘테이션 (implementation)에 있는 개념적인 소프트웨어 컴포넌트일 수 있다. 상기 DM 클라이언트는 DM 클라이언트 -서버 프로토콜의 엔드 -포인트로서 서 비스할 수 있다 (An abstract software component in a Device implement at ion 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.).
[44] 또한, 본 명세서에서 DM 클라이언트는 통신모들, 프로세서모들 등을 구비 하는 상기 DM 의 대상이 되는 장치 내에 탑재된 채로 제공될 수 있으며, 따라서 하나의 장치로서 구현될 수 있다.
[45] ACKAccess Control List)
[46] ACL 은 관리 트리 내의 특정 노드에 대한 DM서버 식별자들 및 각각의 DM 서버 식별자와 연관된 접근 권한 (access right)들의 리스트를 지칭한다 (A list of identifiers and access rights associated with each identifier).
[47] 노드 (Node)
[48] 노드는 관리 트리에 있는 단독 엘리먼트이다. 관리 트리 내에서 노드는 두 종류: 인테리어 노드 및 리프 노드가 있을 수 있다. 노드의 포맷 속성은 노드가
리프 노드인지 인테리어 노드인지 여부에 관한 정보를 제공한다 (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 .).
[49] 인테리어 노드 (Interior Node)
[50] 인테리어 노드는 자식 노드를 가질 수 있는 반면, 노드에 할당된 값 즉, 노드 값 (node value)은 가질 수 없다. 인테리어 노드의 포맷 속성은 "node"이다 (A Node that may have child Nodes , but cannot store any value. The Format property of an Interior Node is node) .
[51] 리프 노드 (Leaf Node)
[52] 리프 노드는 자식 노드를 가질 수 없고 대신 노드 값을 가질 수 있다. 리 프 노드의 포맷 속성은 "node' '가 아니다 (A Node that can store a value, but cannot have child Nodes . The Format property of a Leaf Node is not node.).
[53] 따라서 모든 부모 (parent) 노드는 인테리어 노드가 되어야만 한다.
[54] 영구 노드 (Permanent Node)
[55] 영구 노드는 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 . )
[56] 동적 노드 (Dynamic Node)
[57] 동적 노드는 DDF 속성 스코프 (Scope)가 다이내믹 (Dynamic)으로 설정되있거 나, 상기 DDF 속성 스코프가 특정되지 않은 노드이다 (A Node is dynamic if the DDF property Scope is set to Dynamic, or if the Scope property is unspeci f ied) .
[58] 서버 식별자 (Sever Identifier)
[59] 서버 식별자는 DM 서버에 대한 0MA DM 내부 이름을 지칭한다. DM 서버는 0MA DM 계정을 통해 장치에 존재하는 서버 식별자와 연관된다 (The 0MA DM
internal name for a DM Server . A DM Server is associated with an existing Server Identifier in a device through OMA DM account.).
[60] ACL속성 및 ACL 값
[61] DM(device management) 프로토콜로 관리되는 모든 단말은 루트 노드 (root node)로 시작되는 하나의 DM 트리 (tree)를 갖게 되고, DM 프로토콜은 DM 트리의 각 노드를 조작함으로써 단말에 관리 명령을 수행한다. 예로, 단말에 다운로드 된 소프트웨어를 설치하기 위해서는 그 소프트웨어와 매칭되어 있는 인스틀 (install) 이라는 노드를 실행 (Exec)하면, 해당 소프트웨어를 설치할 수가 있다. 각각의 노 드는 숫자와 같은 단순한 정보를 나타낼 수도 있고, 그림 데이터나 로그 데이터처 럼 복잡한 데이터를 나타낼 수도 있다. 또한 노드는 실행, 다운로드 둥과 같이 하 나의 명령을 나타낼 수도 있다.
[62] 각각의 노드는 노드와 관련된 메타 정보를 제공해 주는 속성 (property)을 갖는다. 이 속성 중에 런타임 (runtime) 속성이 있는데, 이 속성은 노드가 DM트리 안에 생성이 되어 소멸될 때까지 사용 가능한 속성을 뜻한다. 이러한 런타임 속성 에는 ACL, Format , Name, Size, Title, TStamp, Type, VerNo가 있다.
[63] ACLCAccess 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 값을 갖도록 정의된다.
[64] ACL 은 다른 런타임 속성과 다른 독특한 성질을 갖는데, 이러한 독특한 대 표적인 성질로서 ACL 상속 (ACL inheritance)이 있다. ACL 상속은 DM 트리안의 어 떤 노드가 ACL 값을 가지고 있지 않을 때, 그 노드에 대한 ACL 값을 부모 노드의
ACL 값에서 가져오는 개념이다. 만약 부모 노드 역시 ACL 값을 가지고 있지 않다 면, 그 부모 노드의 부모 노드에서 ACL 값을 가져오게 된다. DM 프로토콜에서는 DM 트리의 최상위 노드인 루트 노드가 반드시 ACL 값을 갖도록 명시하고 있기 때 문에, ACL 값은 반드시 상속되게 된다. 이러한 ACL 상속은 개별 DM 명령별로 이루 어지지 않고, 전체 ACL 값에 대해 수행되기 때문에, ACL 값이 비어 있어야만, 부 모 노드로부터 ACL 상속이 이루어지게 된다. 즉, 어떤 노드의 ACL 값이 Add 권한 만을 명시하고 있다면, 명시되어 있지 않는 Get (가져오기) 권한 등은 상속되지 않 는다.
[65] DM 프로토콜에서는 루트 노드는 ACL 에 대한 기본 값으로 "Add=*&Get=*"을 갖게 되며, 여기서 는 와일드 카드 (wild card)로써, 임의의 DM서버를 뜻한다. DM 서버가 ACL 값을 얻기 위해서는 Get 명령을 이용하면 되며, "./NodeA/Noder?prop=ACL "에 대한 Get 명령은 ./NodeA/Nodel 의 ACL 값을 가져오 게 된다. 또한 ACL 값을 바꾸기 위해서는 교체 (Replace) 명령을 이용하면 되며, "./NodeA/Nodel?prop=ACL "에 Replace 명령올 수행하여 "Add=DMSl&Delete=DMSl&Get=DMSl"로 값을 바꾸게 되면 ACL 값이 바뀌게 된다. DM 프로토콜에서는 개별 ACL 엔트리 (acl entry)를 바꿀 수가 없고, 전체 ACL 값을 바 꿀 수 있도록 정의되어 있다. ACL 값을 얻어 오고, 수정하는 권한 역시 ACL 에 기 반하여 정의되는데, 인터리어 노드와 리프 노드에 대한 권한이 조금 다르게 정의 되어 있다.
[66] - 인테리어 노드
해당 노드에 Get 과 Replace 권한을 가지고 있다면, 해당 노 드의 ACL 값을 각각 가져오고 교체할 수 있는 권한이 있다. 또한 Replace 권한은 모든 자식 노드의 ACL 값을 교체할 수 있는 권한을 의미한다.
[67] 리프 노드
해당 노드의 부모 노드에 Replace 권한을 가지고 있다면, 그 노드의 ACL 값을 교체할 수 있는 권한이 있다. 해당 노드의 ACL 을 가져오기 위해 서는 부모 노드에 Get 권한을 가지고 있어야 한다. 마찬가지로, 해당 노드에 Replace 권한을 가지고 있다면, 그 노드의 값을 교체할 수 있는 권한을 뜻하며, ACL을 교체하기 위해서는 부모 노드에 Replace 권한을 가지고 있어야 한다.
[68] 인테리어 노드이건 리프 노드이건 상관없이 해당 노드의 ACL 값을 교체하 는 권한은 부모 노드의 ACL 값에 의해 제어될 수 있다. 인테리어 노드에 Replace 권한을 가지고 있다면, 해당 인테리어 노드는 물론, 모든 자식 노드의 ACL 값을 교체할 수 있는 권한을 뜻한다. 따라서, 루트 노드에 Replace 권한을 가지고 있다 면, DM 트리 내의 모든 노드에 어떤 권한이든지 가질 수 있다는 뜻이 된다. 하지 만 부모 노드에 Replace 권한을 갖고 있다는 것이 곧바로, 자식 노드에 Get 과 같 은 특정 권한을 내포하지는 않으며, 해당 자식 노드에 직접적으로 Get 과 같은 권 한이 명시되어 있어야만 한다. 따라서 명령 수행 전에 ACL 값을 수정해 줘야만 하 며, 수정하려는 노드로 가는 길에 있는 모든 노드에 대한 ACL 값의 수정을 통해 최종적으로 해당 자식 노드의 ACL 값을 수정하게 된다. 이는 불편하기 때문에, DM 프로토콜에서는 부모 혹은 선조 노드 (ancestor node)에 Replace 권한을 가지고 있 을 경우, 중간 노드의 ACL 값 수정 없이 바로 해당 노드의 ACL 값의 수정을 허용 하고 있다.
[69] DM 서버가 새로운 노드를 추가 (Add) 명령을 통해 생성한 경우, 생성된 노 드는 일반적으로 ACL 값을 갖지 않게 되어, 모든 권한을 부모에게서 상속받게 된 다. 하지만 생성한 노드가 인테리어 노드이고, 부모 노드에 Replace 권한을 가지 고 있지 않을 경우, 생성과 동시에 ACL 값을 설정하여 해당 노드를 관리하기 위한 층분한 권한을 갖는 것이 필요하다.
[70] ACL 값을 나타내기 위한 문법은 [DM-TND]에 정의되어 있으며, ACL 값의 한 예는 "Get=DMSl&Replace=DMSl&Delete=DMS2"를 들 수 있다. 여기서 DMS1과 DMS2는 DM Server 의 서버 식별자이며, Get, Replace, Delete는 DM 명령이다. 따라서 해 당 노드에 대해 DMS1은 Get과 Replace 명령을 수행할 수가 있고, DMS2는 Delete 명령을 수행할 수 있다. 여기서 Get=DMSl, Re lace=DMSl, Delete=DMS2 는 각각이 ACL-엔트리 (acl-entry)이며, DM 서버의 개별 명령 권한을 나타낸다. 다시말하면, ACL 값은 개별 ACL-엔트리 (acl-entry)의 집합이며, 각 노드의 ACL 값은 적어도 하 나의 ACL 엔트리를 포함할 수 있다.
[71] DDF(Device Descri tion Framework)
[72] DDF 는 특정 디바이스 타입에 대한 관리 신택스와 시멘틱을 기술하는 방법 에 관한 설명이다 (A specification for how to describe the management syntax
and semantics for a particular device type) . DDF 는 단말의 MO, 관리 기능 및 DM트리 구조에 대한 정보를 제공한다.
[73] DM 1.3 인증
[74] DM 1.3 에서는 ACL 에 기반하여 인증을 수행한다. DM 인증은 각각의 DM 명 령에 대해 별도로 이루어진다. 만약 DM 서버가 다수의 DM 명령을 전송했으면, DM 클라이언트)는 개별 명령을 수행하기 전에 인증을 수행하고, 그 결과로 허가된 DM 명령만 수행하게 된다.
[75] DM트리
[76] DM 트리는 DM 클라이언트에 의해 노출된 M0 인스턴스들의 집합을 지칭한다. DM 트리는 클라이언트와 상호작용하는 관리 서버에 의한 인터페이스로 기능하며, 예컨대 상기 관리 서버는 DM 트리로부터 특정 값들을 저장하고 검색 (retrieve)하 며, 상기 DM트리의 속성을 조작할 수 있다.
[77] 기존 서버 -클라이언트 모델에서 서버와 클라이언트 간의 통신을 수행하기 위해서는 두 엔티티 (서버 , 클라이언트) 모두 통신 수행 이전에 공유 /저장해야 하 는 정보가 존재한다. 이를 위해 DM 에서는 DM 클라이언트를 부트스트랩 (bootstrap)하여 DM 서버와의 통신에 필요한 필요한 사전 정보를 DM서버 또는 DM 부트스트램 서버가 전달한다. 즉, DM 클라이언트는 특정 DM서버와의 통신에 필요 한사전 정보를 부트스트랩 기법을 통해 전달하고, 이후 해당 DM 클라이언트와 DM 서버간의 통신이 가능하도록 한다.
[78] 실제 배치 (deployment) 상황에서 DM 클라이언트를 재 -부트스트랩 (re¬ bootstrap) 할 경우가 발생하는데 예를 들어 특정 DM서버와 특정 DM 클라이언트 간의 통신에 지속적으로 오류가 발생한 경우이다. 이러한 경우는 보안 키 (security key) 불일치 (mismatch) 또는 다른 이유 등으로 발생할 수 있다. DM 에 서는 재ᅳ부트스트랩 (re— bootstrap)에 대해 명시하고 있지는 않지만, 부트스트랩 (bootstrap)이 다시 발생하는 경우를 의미하는 경우로 판단된다. 이러한 부트스트 랩의 경우는 부트스트랩 정보 이외에도 특정 서버 관련 정보가 초기화 (예건대 ACL 안의 해당 서버의 권한 정보들)되기 때문에 재 -부트스트랩 이후에도 해당 서버에 대한 정보를 클라이언트로 전달해주는 것이 필요하다. 이에 본 발명에서는 재-부 트스트랩 시 전체 부트스트램을 모두 수행하지 않고, 특정 정보만을 제공 /갱신하
는 방법을 사용하여 다른 정보들을 유지하면서 재-부트스트램을 수행하는 방법을 제시한다 .
[79] 도 1 은 M2M 클라이언트에 저장된 데이터 (또는 자료) 구조를 도시한다. M2M클라이언트 (또는 단말)는 상기 M2M클라이언트가 구현할 수 있는 기능에 해당 하는 "객체 (Object)" 로 지칭되는 리소스 (resource)들이 그룹화된 엔티티 (들)를 가질 수 있고, 객체의 식별자는 객체 설명 (specification)에서 정의되거나, 객체 설명에서 정의되지 않은 식별자는 M2M 시스템을 이용하는 사업자 또는 제조사가 설정할 수 있다. 리소스는 실제 데이터를 저장하는 엔티티로써, 리소스는 복수 개 의 리소스 인스턴스 (instance)들을 가질 수 있다. 각 객체는 특정 동작 명령에 의 해 객체 인스턴스 (object instance)로서 생성되어 실체화 되며, M2M클라이언트는 상기 객체 인스턴스를 통해 실제 해당 리소스에 대해 접근할 수 있다.
[80] 또한, 각 리소스에는 해당 리소스가 어떤 동작 명령 (operation)을 지원하 는지를 나타내기 위한 정보가 포함되거나 첨부되며, 상기 동작 명령은 예컨대 읽 기 (Read), 쓰기 (Write), 실행 (Execute)ᅳ 쓰기 속성 (Write Attributes), 탐색 (Discover), 관찰 (Observe) 등이 있다.
[81] 도 2 는 본 발명의 일 실시예와 관련된 리소스 모델을 도시한다. 본 발명 의 일 실시예에 따른 M2M 시스템에서 사용될 리소스에 대한 접근 권한의 제어를 위해 ACLCAccess Control List)와 AT(Access Type)을 할당한다.
[82] 상기 ACL 은 특정 기능이 실체된 자원, 즉 객체 인스턴스 별로 할당되며, 상기 객체 인스턴스의 하위 리소스는 동일한 ACL 를 할당받은 것으로 간주된다. 즉, ACL은 객체 인스턴스 별로 할당되므로, 그 하위 리소스는 동일한 ACL을 갖는 것으로 약속된다.
[83] 객체 인스턴스는 리소스가 그룹화 되어있는 엔티티이고, 특정 기능을 수행 하기 위해 모인 집단이기 때문에 특정 서버에게 특정 기능에 대한 권한을 부여할 시 집단 안의 모든 리소스에 대해 동일한 권한을 부여하는 것이 타당하다. 등일한 권한을 부여하지 않을 시 하나의 기능에 대해 부분적으로만 동작을 수행할 수 있 게 되는데, 이렇게 될 시 해당 서버의 역할이 모호해지며 권한 부여에 대한 의미 가 퇴색된다. 따라서, 본 발명의 일 실시예에선 상기 언급한 것처럼 각 객체 인스 턴스 별로 ACL 을 할당함으로써, 종래에 개별 리소스 별로 저장되는 경우에 비하
여 오버헤드를 줄일 수 있으며, ACL 을 찾는데 동일한 메커니즘이 사용되기에 접 근 권한 인증 절차가 간소화될 수 있다.
[84] 참고로, 각 객체는 복수 개의 객체 인스턴스 (들)로 실체화 (instantiate)될 수 있다.
[85] 또한, 상기 AT 는 개별 리소스 별로 할당될 수 있으며, 각 개별 리소스가 지원하는 접근 방식을 정의할 수 있다. 예컨대, 접근 방식이 동작 명령 (operation)들로 정의된다면, 상기 AT 는 특정 동작 명령들, 예컨대 읽기 (Read), 쓰기 (Write), 실행 (Execute) 등으로 정의될 수 있다.
[86] 한편, 상기 ACL 과 상기 AT 는 각각 다르게 지칭될 수 있으며, 예컨대 ACL 은 접근 권한 (Access Right), AT 는 지원 가능한 동작 명령 등으로 지칭될 수 있 다.
[87] 인터페이스
[88] 본 발명의 구체적인 실시예들을 설명하기에 앞서, 특정 동작 명령들이 서 버와 클라이언트 (단말) 간에 전달되는 인터페이스에 대해 설명하도록 한다.
[89] 본 발명과 관련되어, 총 4 개의 인터페이스가 존재한다. 1) 부트스트랩, 2) 장치 (클라이언트, 디바이스) 등록, 3) 장치 관리 및 서비스 인에이블먼트, 4) 정보 보고. 상기 네 가지의 인터페이스들을 위한 동작 명령들은 상향링크 동작들 및 하향링크 동작들로 분류될 수 있다. 각각의 인터페이스의 동작 명령들이 아래 의 표에 정의된다.
[90] 【표 1】
터페이스를 위한 동작 모델을 도시한다. 부트스트랩 인터페이스를 위해, 동작 명 령들은 "부트스트랩 요청" 으로 명명된 상향링크 동작 명령 (즉 클라이언트 개시 부트스트랩)과 "쓰기" 및 "삭제" 로 명명된 하향링크 동작 명령 (즉, 서버 개시
부트스트랩)이다. 이들 동작 명령들은 하나 이상의 서버들과 등록하기 위해 클라 이언트를 위한 필요한 객체 인스턴스 (들)를 초기화하는데 사용된다. 부트스트랩은 또한 제조자 부트스트램 (factory bootstrap) 또는 스마트카드로부터의 부트스트랩 (bootstrap from smartcard) (스마트카드에 저장)을 이용하여 정의된다.
[92] 도 3 의 (b)는 "장치 (클라이언트) 등록" 인터페이스를 위한 동작 모델을 도시한다. 상기 장치 등록 인터페이스를 위해, 동작 명령들은 "등록," "업데이 트" 및 "등록-해제" 로 명명된 상향링크 동작 명령들이다. 등록" 은 서버에 클 라이언트의 정보를 등록하는데 사용되고, "업데이트" 는 주기적으로 또는 클라이 언트에 발생한 이벤트에 의해 서버에 등록된 클라이언트의 정보 또는 상태를 업데 이트하는데 사용된다. "등록-해제" 는 서버에 클라이언트의 등록을 해제하는 단 계로써 서버는 클라이언트의 정보를 삭제할 수 있다.
[93] 도 3 의 (c)는 "장치 관리 및 서비스 인에이블먼트 (device management and service enablement)" 인터페이스를 위한 동작 모델을 도시한다. 상기 장치 관리 및 서비스 인에이블먼트 인터페이스를 위해, 상기 동작 명령들은 "읽기," "생성," "삭제," "쓰기," 및 "실행" 으로 명명된 하향링크 동작 명령들이 다. 이러한 동작 명령들은 클라이언트의 리소스들, 리소스 인스턴스들, 객체들 및 객체 인스턴스들과의 상호작용을 위해 사용된다. "읽기" 동작 명령은 하나 이상 의 리소스들의 현재 값을 읽기 위해 사용되며, "쓰기" 동작 명령은 하나 이상의 리소스들의 값을 업데이트하기 위해 사용되고, "실행" 동작 명령은 리소스에 의 해 정의된 동작을 개시하기 위해 사용된다. "생성" 및 "삭제" 동작 명령들은 객체 인스턴스들을 생성 또는 삭제하기 위해 사용된다. "쓰기 속성" 은 "관찰" 동작 명령과 관련된 속성을 설정하는데 사용하며, "탐색" 은 해당 속성을 검색할 때 사용한다.
[94] 도 3 의 (d)는 "정보 보고" 인터페이스를 위한 동작 모델을 도시한다. 상기 정보 보고 인터페이스를 위해, 상기 동작 명령들은 하향링크 동작 명령들 "관찰" 또는 "취소 관찰" 및 상향링크 동작 명령 "통지 (Notify)" 를 포함한 다. 상기 정보 보고 인터페이스는 서버로 클라이언트 상의 리소스와 관련된 새로 운 값을 전송하기 위해 사용된다. "관찰" 은 서버가 자원의 자원의 변화에 관심 이 있을 경우 특정 자원올 관찰하는데 사용되며, "취소 관찰" 은 해당 관찰을 더 이상 하지 않을 때 (자원의 변화를 더 이상 알고 싶지 않을 때 ) 사용된다. "통
지" 는 "쓰기 속성" 을 통해 설정된 관찰 조건 속성이 맞을 경우 이를 서버에 알 릴 때 사용한다.
[95] 접근 제어를 위한 데이터 모델
[96] M2M 디바이스의 파싱 (parsing) 프로세스 오버헤드를 줄이고 공간 오버헤드 (space overhead)를 줄이기 위해 M2M환경에 적합한서버 식별자 (Identifier; ID) ACL (또는 접근 권한), AT (또는 지원가능한 동작 명령)로 모델링한다.
[97] - 짧은 서버 ID
ACL 에 포함되어야 하는 정보는 어떤 서버가 어떠한 동작 명령 (operation)을 명령 할 수 있는지 여부를 포함해야 한다 . 서버 ID는 통상적으로 URI로 표현되기에 환 경에 따라 URI 가상당히 길어질 수 있을 수 있다. 객체 인스턴스 별로 ACL 이 표 현이 되어야 하고 객체 인스턴스 마다 길이가 긴 서버 ID 가 중복적으로 사용되게 되기에 서버 ID 로 인해 객체 인스턴스 수에 의존하여 상당한 공간 오버해드를 초 래할 수 있다. 이에 짧고 고정된 길이 (예컨대, 2 바이트)의 짧은 서버 ID 를 ACL 에서 사용할 것을 제안한다. M2M 클라이언트는 짧은 서버 ID 와 서버 ID 간의 맵 핑 관계를 저장하고 있으며, 서버 ID 로부터 수신되는 동작 명령에 대해 짧은 서 버 ID를 찾아 이를 사용하여 ACL을 통해 인증을 수행할 수 있다.
[98] 【표 2】
[99] Access Control List (ACL) 또는 접근 권한
[100] ACL 은 각 객체 인스턴스에 할당되며 각각의 M2M 서버에 대한 접근 권한을 지정하는 ACL 엔트리 (entry)의 리스트로 구성된다. ACL 엔트리는 짧은 서버 ID 와 해당 서버의 접근 권한으로 표현될 수 있다. 짧은 서버 ID 와 접근 권한 값은 모 두 고정된 짧은 길이로 설정하여 인증 절차 시의 공간 오버헤드와 처리 효율성을 높인다. 접근 권한에서는 M2M 의 각 동작 명령에 대해 하나의 비트 값을 할당하여 특정 동작 명령에 대한 인증 절차를 수행 시 하나의 비트만을 읽으면 되도록 하여 처리 효율성을 높였다. ACL 에서 명시된 서버 이외의 타 서버에 대한 디폴트 (default) ACL 엔트리를 설정할 수 있으며, ACL 에 명시되지 않은 모든 서버에 대 한 동작 명령을 수신 시 M2M 클라이언트는 특정 짧은 서버 ID (예컨대, 0x0000)를 찾아 해당 접근 권한을 이용하여 해당 동작 명령을 인증할 수 있다.
[101] 【표 3】
ACL List of ACL entries
ACL entry Short Server ID와 access right로
구성
Access right는 다음고ᅡ 같이 구성
1st lsb(least significant bit): Read
2nd lsb: Write
3rd lsb: Execute
Other bits are reserved for future use
[102] 위의 표에서 예시된 ACL 엔트리 내 값은 일 예시이며, 다르게 설정될 수 있음은 당업자에게 자명하다.
[103] Access Type (AT) 또는 지원가능 동작 명령
[104] AT 는 리소스가 어떤 동작 명령을 지원하는지를 지정할 수 있다. ACL 엔트 리의 접근 권한과 동일한 형태로, 하나의 비트마다 하나의 동작 명령올 맵핑하였 다.
[106] 위의 표에서 예시된 Access Type 내 값은 일 예시이며, 다르게 설정될 수 있음은 당업자에게 자명하다.
[107] 이하, 본 명세서에서 사용되는 M2M 관련 동작 명령 및 객체 (인스턴스)에 대한 설명을 간략히 하도록 한다.
[108] ·읽기 (Read)
[109] "읽기" 동작 명령은 개별 리소스, 일 어레이 (array)의 리소스 인스턴스 들ᅳ 객체 인스턴스 또는 객체의 모든 객체 인스턴스들의 값에 접근 (읽기)하기 위 해 사용되며, 다음과 같은 파라미터들을 갖는다.
[110] 【표 5】
[Ill] ,탐색 (Discover)
[112] "탐색" 동작 명령은 개별 리소스, 객체 인스턴스, 객체에 설정된 속성 (파라미터, attribute, parameter)들을 탐색하기 위해 사용된다. 상기 탐색 동작 명령은 또한 특정 객체 내에서 어떤 리소스들이 구현 (implement)되었는지를 탐색 하기 위해 사용된다. 리턴되는 값들은 리소스의 속성들을 포함하는 각 리소스에
대한 어플리케이션 /링크 -포맷 CoRE 링크들 (RFC6690 의 appli cat ion/ link-format CoRE 형식을 따르는 링크들)의 리스트이다. 상기 탐색 동작 명령은 다음과 같은 파라미터들을 갖는다.
[113] 【표 6】
[114] 상기 탐색 명령의 특이한 기능으로는, 상기 파라미터들 중 객체 ID 만이 명시된 경우엔, 어떤 리소스가 구현되어 있는지가 리턴 및 객체에 설정된 관찰 (observe) 파라미터들이 리턴될 수 있고, 상기 파라미터들 중 객체 인스턴스 ID 까지만 명시된 경우 (즉, 객체 ID와 객체 인스턴스 ID가 명시됨)ᅳ 명시된 객체 인 스턴스에 설정된 관찰 파라미터들이 리턴될 수 있고, 상기 파라미터들 중 리소스 ID까지 명시된 경우 (즉, 객체 ID, 객체 인스턴스 ID, 리소스 ID가 명시됨), 명시 된 리소스에 설정된 관찰 파라미터들이 리턴될 수 있다.
[115] ·쓰기 (Write)
[116] "쓰기" 동작 명령은 리소스, 어레이 (array)의 리소스 인스턴스들, 또는 객체 인스턴스에 복수의 리소스들의 값을 변경 (쓰기)하기 위해 사용된다. 상기 쓰 기 동작 명령은 하나의 명령을 통해 동일한 객체 인스턴스 내에서 복수의 리소스 들이 변경되는 것을 허용한다. 즉, 상기 쓰기 동작 명령은 (개별 리소스 뿐만 아 니라) 일 객체 인스턴스에 대하여 접근이 가능하다. 상기 쓰기 동작 명령은 다음 과 같은 파라미터들을 갖는다.
[117] 【표 7】
[118] ,쓰기 속성 (Write Attributes)
[119] "쓰기 속성" 동작 명령은 리소스 또는 객체 인스턴스, 객체의 속성들을 변경 (쓰기)하기 위해 사용된다. 상기 쓰기 속성 동작 명령은 다음과 같은 파라미 터들을 갖는다.
[120] 【표 8】
[121] 상기 최소 주기, 최대 주기, 초과 (Greater Than) , 미만 (Less Than) 및 스 텝 (Step)은 오직 관찰 동작 명령에서 사용된다. 최대 및 /또는 최소 주기 파라미터 들은 얼마나 자주 "통지 (Notify)" 동작 명령이 관찰된 객체 인스턴스 또는 리소 스를 위해 M2M 클라이언트에 의해 전송되는지를 제어하기 위해 사용된다. 초과, 미만, 및 스텝 파라미터는 리소스 ID 가 지시된 경우에만 유효하다. 초과, 미만
및 스텝 파라미터는 리소스 타입이 수 (예컨대, 정수, 소수 (decimal))인 경우에만 지원되어야 한다.
[122] ,실행 (Execute)
[123] "실행" 동작 명령은 어떤 동작올 개시하기 위해 M2M 서버에 의해 사용되 며, 개별 리소스들에 대해서만 수행될 수 있다. M2M 클라이언트는 상기 "실행" 동작 명령이 객체 인스턴스 (들) 또는 리소스 인스턴스 (들)에 대해 수신된 경우 에 러를 리턴한다. 상기 실행 동작 명령은 다음과 같은 파라미터들을 갖는다.
[125] ·생성 (Create)
[126] "생성" 동작 명령은 M2M 클라이언트 내에 객체 인스턴스를 생성하기 위 해 M2M서버에 의해 사용된다. 상기 "생성" 동작 명령은 객체 또는 아직 인스턴 스화 (또는 실체화 (instantiate))되지 않은 객체 인스턴스 중 하나를 타깃 (target)해야 한다.
[127] M2M 서버에 의해 M2M 클라이언트에서 생성된 객체 인스턴스는 M2M 클라이 언트에 의해 지원되는 객체 타입이어야 하고 디바이스 등록 인터페이스의 "등 록" 및 "갱신" 동작 명령을 사용하여 M2M 서버로 M2M 클라이언트에 의해 통지 되는 객체 인스턴스이어야 한다.
[128] 최대 하나의 객체 인스턴스를 지원하는 객체는 상기 객체 인스턴스가 생성 되면 0의 객체 인스턴스 ID를 할당받아야 한다. "생성 " 동작 명령은 다음의 파 라미터들을 갖는다.
[129] 【표 10】
[130] ·삭제 (Delete)
[131] "삭제" 동작 명령은 M2M 클라이언트 내 객체 인스턴스를 삭제하기 위해 M2M 서버를 위해 사용된다. M2M 서버에 의해 M2M 클라이언트에서 삭제된 객체 인 스턴스는 디바이스 둥록 인터페이스의 "등록" 및 "갱신" 동작 명령을 사용하 여 M2M 서버로 M2M 클라이언트에 의해 통지되는 객체 인스턴스이어야 한다. 상기 삭제 동작 명령은 다음과 같은 파라미터들을 갖는다.
[132] 【표 11】
[133] ·관찰 (Observe)
[134] M2M서버는 M2M 클라이언트 내 특정 리소스, 객체 인스턴스 내의 리소스들, 또는 객체의 모든 객체 인스턴스들의 변경들에 대한 관찰 요청을 개시할 수 있다.
"관찰" 동작 명령을 위한 관련 파라미터들은 "쓰기 속성" 동작 명령에서 설정 된다. 상기 관찰 동작 명령은 다음의 파라미터들을 포함한다.
[135] 【표 12】
[136] ,취소 관찰 (Cancel Observe)
[137] "취소 관찰" 동작 명령은 M2M 서버로부터 M2M 클라이언트로 객체 인스턴 스 또는 리소스에 대한 관찰 관계를 종료하기 위해 전송된다. 상기 취소 관찰 동 작 명령은 다음의 파라미터들을 포함한다.
[138] 【표 13】
[139] 접근 제어 기법
[140] 이하는 M2M에서 사용되는 접근 제어 방법을 설명하도록 한다.
[141] - 접근 권한 획득
[142] M2M 클라이언트가 하나의 M2M 서버 객체 인스턴스를 가지면, M2M 클라이언 트는 상기 하나의 M2M 서버에 대한 접근 제어를 거치지 않고, 즉 접근 제어 객체
인스턴스를 확인하지 않고, 상기 M2M서버는 해당 리소스에 대한 모든 권한을 갖 는다.
[143] 만약 M2M클라이언트가 둘 이상의 M2M서버 객체 인스턴스를 가지면, 상기 M2M클라이언트는 접근하려는 객체 인스턴스 또는 리소스가 속한 객체 인스턴스에 대한 해당 서버의 ACL 을 접근 제어 객체 인스턴스 (들)에서 찾는다. 만약 해당 M2M서버 ID 에 해당하는 접근 권한이 ACL 에 존재한다면, 해당 M2M서버는 해당 접근 권한을 갖는다. 해당하는 M2M서버 ID 의 ACL 엔트리가 존재하지 않는다면, M2M클라이언트는 디폴트 서버 ID에 할당된 접근 권한이 ACL 에 존재하는지 확인 하고, 상기 디폴트 서버 ID가 존재한다면, 해당 M2M서버는 디폴트 서버 ID의 접 근 권한을 갖는다. M2M서버 ID 에 해당하는 접근 권한이 존재하지 않고 상기 디 폴트 서버 ID 의 접근 권한이 존재하지 않으면 해당 M2M 서버는 해당 리소스에 대한 접근 권한을 갖지 않는다.
[144] - 접근 제어 객체 (Access Control Object)
[145] 접근 제어 객체는 M2M 서버가 동작 명령을 수행하기 위한 접근 권한을 갖 고 있는지 여부를 체크하기 위해 사용된다. 각각의 접근 제어 객체 인스턴스는 특 정 객체 인스턴스에 대한 ACUAccess Control List)를 포함한다.
[146] 【표 14】
[147] - 인증 절차
[148] M2M 서버로부터 전달된 동작 명령에 대해 인증 절차를 통과하기 위해서는 두 가지가 만족되어야 한다. 첫째로, M2M서버가 해당 자원 (예컨대, 객체 인스턴 스, 리소스)에 대해 상기 전달된 동작 명령을 수행할 권한 (즉, 접근 권한)이 있는 지, 둘째로, 해당 자원이 상기 전달된 동작 명령을 지원하는지가 만족되어야 한다. 이처럼, 본 발명의 일 실시예에 다른 접근 권한 인증 절차는 두 개의 스텝, 즉 계 층적인 구조로 수행된다.
[149] M2M클라이언트는 해당 자원에 대해 접근 권한이 없을 경우 에러 메시지를 전송하고, 해당 자원이 상기 전달된 동작 명령을 지원하지 못할 경우에는 상기 해 당 자원에 대한 정보를 M2M서버로 전달함으로써, 어떠한 자원으로 인해 상기 전 달된 동작 명령이 수행되지 않았음을 알린다. 인증 절차는 3-레벨, 즉 리소스, 객 체 인스턴스, 객체에 대하여 조금씩 다르게 이루어진다.
[150] - 리소스에 대한 동작 명령
[151] 만약 M2M 서버가 개별 리소스에 접근하면, 즉 상기 M2M 서버가 개별 리소 스에 대한 동작 명령을 M2M 클라이언트로 전송하면, 상기 M2M 클라이언트는 위에 서 설명한 접근 권한을 획득하는 방법에 따라 상기 개별 리소스가 속하는 객체 인 스턴스에 대한 M2M서버의 접근 권한을 획득하고, 상기 접근 권한이 상기 동작 명 령을 수행하도록 승인되었는지 여부를 체크할 수 있다.
[152] 만약 상기 동작 명령이 허용되지 않으면, 상기 M2M 클라이언트는 상기 M2M 서버로 "접근 권한 허용이 거절됨" 에러 코드를 전송해야 한다.
[153] 만약 상기 동작 명령이 허용되면, M2M 클라이언트는 상기 개별 리소스가 상기 동작 명령을 지원하는지 여부를 검증할 수 있다.
[154] 만약 상기 동작 명령이 상기 개별 리소스에 의해 지원되지 않으면, 상기 M2M 클라이언트는 상기 M2M 서버로 "동작 명령이 지원되지 않음" 에러 코드를 전송해야 한다.
[155] 만약 상기 개별 리소스가 상기 동작 명령을 지원하면, 상기 M2M 클라이언 트는 상기 동작 명령을 수행할 수 있다.
[156] - 객체 인스턴스에 대한 동작 명령
[157] 만약 M2M 서버가 객체 인스턴스에 액세스하면, 즉 상기 M2M 서버가 객체 인스턴스에 대한 동작 명령을 M2M 클라이언트로 전송하면, 상기 M2M 클라이언트는 상술한 접근 권한 획득 방법에 따라 객체 인스턴스에 대한 M2M 서버의 접근 권한 을 획득하고 상기 접근 권한이 상기 동작 명령을 수행하도록 승인되었는지 여부를 체크할 수 있다.
[158] 만약 상기 동작 명령이 허용되지 않으면, 상기 M2M 클라이언트는 상기 M2M 서버로 "접근 권한 허용이 거절됨" 에러 코드를 전송해야 한다.
[159] 만약 상기 동작 명령이 허용되면, 상기 M2M 클라이언트는 상기 동작 명령 에 기반하여 다음의 절차들을 수행할 수 있다.
[160] "쓰기 (Write)" 동작 명령에 대해, 상기 M2M 클라이언트는 상기 동작 명 령에서 전달된 모든 리소스들이 "쓰기" 동작 명령을 수행하도록 허용된 경우에 만 상기 객체 인스턴스에 대한 동작 명령을 수행할 수 있다. 만약 (상기 동작 명 령에서 전달된) 어떤 리소스라도 상기 "쓰기" 동작 명령을 지원하지 않으면, 상 기 M2M 클라이언트는 상기 M2M 서버에게 "동작 명령이 지원되지 않음" 에러 코 드를 전송함으로써 상기 동작 명령을 지원하지 않은 리소스들을 알릴 수 있다.
[161] "읽기 (Read)" 동작 명령에 대해, 상기 M2M 클라이언트는 "읽기" 동작 명령을 지원하지 않는 리소스 (들)을 제외한 모든 리소스들을 읽고 (retrieve), 상 기 읽은 리소스 (들) (retrieved Resources) 정보를 상기 M2M 서버로 전송할 수 있 다.
[162] "생성 (Create)" 동작 명령에 대해, 상기 M2M 클라이언트는 오직 상기 동 작 명령에서 전달된 모든 리소스들이 "쓰기" 동작 명령을 수행하도록 허용되고 모든 필수 리소스들이 특정된 경우에만 상기 객체 인스턴스에 대한 동작 명령을 수행할 수 있다. 만약, (상기 동작 명령에 포함된) 어떤 리소스라도 상기 "쓰 기" 동작 명령을 지원하지 않으면, 상기 M2M 클라이언트는 상기 M2M 서버에게
"동작이 지원되지 않음" 에러 코드를 전송함으로써 상기 동작 명령을 지원하지 않는 리소스들을 알릴 수 있다. 만약 모든 필수 리소스들이 특정되지 않으면, 상 기 M2M 클라이언트는 상기 M2M서버로 "Bad Request" 에러 코드를 전송할 수 있 다.
[163] "삭제 (Delete)" , "관찰 (Observe)" , "쓰기 속성 (Attribute)" , 또는 "탐색 (Discover)" 동작 명령에 대해, 상기 M2M 클라이언트는 상기 동작 명령을 수행해야 한다. 즉, 상기 M2M 클라이언트는 상기 객체 인스턴스에 대한 동작 명령 이 상기 객체 인스턴스에 속한 모든 리소스에 의해 지원되는지 여부를 체크하지 않고, 상기 삭제 (Delete)" , "관찰 (Observe)" , "쓰기 속성 (Attribute)" , 또는 "탐색 (Discover)" 동작 명령을 수행해야 한다.
[164] 만약 앞서 언급한 동작 명령이 아닌 동작 명령에 대해서는, 상기 M2M 클라 이언트는 상기 동작 명령을 수행해서는 안되며 상기 M2M 서버로 "동작이 지원되 지 않음" 에러 코드를 전송해야 한다.
[165] 객체 인스턴스에 대한 동작 명령에 대해 정리하면, 상기 객체 인스턴스에 대한 해당 M2M서버의 접근 권한의 소유 여부는 상기 접근 권한 획득 방법에 의해 수행된다. 그리고 나서, 상기 객체 인스턴스에 속한 개별 리소스 (들)이 상기 동작 명령을 지원하는지 여부가 확인되몌 이 과정은 상기 동작 명령의 종류에 따라 수 행되거나 수행되지 않는다.
[166] - 객체에 대한 동작 명령
[167] 객체에 대한 동작 명령 또한 동작 명령의 종류에 따라 정의된다.
[168] M2M 서버가 "읽기" 동작 명령을 객체에 전송하면, 즉 객체에 대한 "읽 기" 동작 명령을 M2M 클라이언트로 전송하면, 상기 M2M 클라이언트는 상기 객체 에 속하는 (또는 하위의) 객체 인스턴스들 중 상기 M2M 서버가 접근 권한이 있는 객체 인스턴스 (들)의 정보를 모아 M2M 서버로 전달할 수 있다. 상기 M2M 서버가 접근 권한이 있는지 여부는 앞서 설명한 접근 권한 획득 방법에 따라 수행된다.
[169] 상기 M2M서버가 접근 권한이 있는 객체 인스턴스의 정보는 상기 M2M 클라 이언트는 상기 "읽기" 동작 명령을 지원하지 않는 리소스 (들)을 제외한 모든 리 소스들을 읽고 (retrieve) 상기 M2M 서버로 상기 읽은 리소스 (들) 정보를 의미한다.
[170] 상기 M2M 서버가 "생성 (Create)" 동작 명령을 객체에 전송하면, 즉 상기 M2M 서버가 객체에 대한 "생성" 동작 명령을 M2M 클라이언트로 전송하면, 상기
M2M 클라이언트는 앞서 설명한 접근 권한 획득 방법에 따라 상기 M2M서버가 상기 객체에 대한 접근 권한을 갖는지 여부를 확인할 수 있다.
[171] 상기 M2M 서버가 상기 객체에 대한 접근 권한이 있다면, 상기 M2M 클라이 언트는 오직 상기 동작 명령에서 전달된 모든 리소스들이 "쓰기 (Write)" 동작 명령을 수행하도록 허용되고 모든 필수 리소스들이 특정되는 경우에만 상기 동작 명령을 수행할 수 있다. 만약 (상기 동작 명령에서 전달된) 어떠한 리소스도 상기 "쓰기" 동작 명령을 지원하지 않으면, 상기 M2M 클라이언트는 상기 M2M 서버에 게 "동작 명령이 지원되지 않음" 에러 코드를 전송함으로써 상기 동작 명령을 지원하지 않는 리소스들을 알릴 수 있다. 만약 모든 필수 리소스들이 특정되지 않 으면, 상기 M2M 클라이언트는 "Bad Request" 에러 코드를 상기 M2M서버로 전송 할 수 있다. 즉 상기 M2M 클라이언트는 이 경우 상기 M2M서버에 의한 동작 명령 이 잘못되었음을 상기 M2M서버에게 알리는 것이다.
[172] "탐색 (Discover)" 동작 명령에 대해, M2M 클라이언트는 상기 동작 명령 을 수행해야 한다. 즉, "탐색" 동작 명령에 대해선, 상기 M2M 클라이언트는 상 기 M2M 서버가 상기 객체 하위의 모든 객체 인스턴스 (들)에 대한 접근 권한을 갖 는지 여부와 상기 모든 객체 인스턴스 (들)에 속한 모든 리소스 (들)이 상기 "탐 색" 동작 명령을 지원하는지 여부를 체크하지 않는다.
[173] "관찰 (Observe)" 또는 "쓰기 속성 (Write Attributes)" 동작 명령에 대 해, 상기 M2M 클라이언트는 상기 동작 명령을 수행해야 한다. 즉, "관찰" 또는 "쓰기 속성" 동작 명령에 대해선, 상기 M2M클라이언트는 상기 M2M서버가 상기 객체 하위의 모든 객체 인스턴스 (들)에 대한 접근 권한을 갖는지 여부와 상기 모 든 객체 인스턴스 (들)에 속한 모든 리소스 (들)이 상기 "관찰" 또는 "쓰기 속 성" 동작 명령을 지원하는지 여부를 체크하지 않는다.
[174] 만약 상술된 동작 명령외의 동작 명령에 대해선, 상기 M2M 클라이언트는 해당 동작 명령을 수행해서는 안되고 "동작이 지원되지 않음" 에러 코드를 상기 M2M서버로 전송할 수 있다.
[175] 객체에 대한 동작 명령에 대해 정리하면, 상기 객체에 대한 해당 M2M 서버 의 접근 권한의 소유 여부는 상기 객체에 대한 특정 동작 명령에 따라 상기 접근 권한 획득 방법에 의해 수행될 지 여부가 결정된다. 그리고 나서, 상기 객체 인스 턴스에 속한 개별 리소스 (들)이 상기 동작 명령을 지원하는지 여부가 확인되며,
이 과정은 상기 동작 명령의 종류에 따라 수행되거나 수행되지 않을 수 있다. 또 한, 객체에 대한 동작 명령의 경우 특정 동작 명령에 대해서는 접근 권한 소유 여 부와 상기 특정 동작 명령의 지원 여부에 대해 확인하지 않을 수도 있다.
[176] 재 -부트스트랩 시의 초기화
[177] 기존의 특정 M2M서버에 대한 리 -부트스트랩 (re-bootstrap)의 경우에는 문 맥 그대로 부트스트랩이 다시 발생하는 것이었다. 이렇게 종래와 같이 부트스트랩 이 다시 발생할 경우에는 기존의 M2M 서버에 대한 정보들이 모두 삭제되고 다시 M2M 서버의 계정 내용이 부트스트랩을 통해 전달되게 된다. 이렇게 할 시에 M2M 서버와 관련된 정보 예로 들어 ACL 과 같은 정보들이 같이 삭제되고, M2M 서버의 정보가 초기화되어 해당 M2M서버는 ACL 이 할당되기 이전에는 연결은 되지만 어 떠한 자원에 대해 접근을 할 수 없는 문제점이 발생한다.
[178] 재 -부트스트램 시 모든 정보 제공
[179] 재 -부트스트랩 시 부트스트랩이 다시 발생하게 된다면, 부트스트랩과 동일 한 정보가 M2M클라이언트에 제공 (provision)되어야 한다. 하지만, 재 -부트스트랩 의 경우에는 기존 부트스트랩 정보를 변경하기에 모든 부트스트랩 정보가 포함될 필요가 없다. 즉, 부분적인 정보만이 가는 것 또한 허용된다면 데이터 오버헤드 측면에서 도움이 될 것이다.
[180] 부트스트램 정보 (Boot st rap Information)
[181] 부트스트랩 정보는 M2M 부트스트랩 서버를 통해 전달되는 정보로, M2M 클 라이언트가 M2M서버 또는 M2M부트스트랩 서버와 연결 /통신하기 위해 필요한 정 보를 의미한다. 부트스트램 정보는 부트스트랩 인터페이스를 통해 전달될 수 있으 며, 부트스트램 시퀀스 이전에 이용가능하거나 상기 부트스트랩 시뭔스의 결과로 서 획득될 수 있다.
[182] 부트스트랩 정보는 M2M 서버 부트스트랩 정보 (M2M Server Bootstrap Information)와 M2M 부트스트랩 서버 부트스트랩 정보 (M2M Bootstrap Server Bootstrap Information)로 분류되며, 상기 M2M서버 부트스트랩 정보는 M2M 서버 계정과 선택적으로 추가적인 객체 인스턴스들 (예컨데, 접근 제어 (access control) 객체 인스턴스, 네트워크 연결 정보 (connectivity) 객체 인스턴스을 포함하고, 상 기 M2M부트스트랩 서버 부트스트랩 정보는 M2M부트스트랩 서버 계정을 포함한다.
[183] M2M서버 계정은 M2M서버에 연결하기 위해 필요한 정보와 서버 관련 기능 서버 관련 기능 정보가 저장될 수 있다. M2M부트스트랩 서버 계정은 M2M부트스 트랩 서버에 연결하기 위해 필요한 정보가 저장된다.
[184] M2M 클라이언트는 M2M 서버로부터의 보안 요건 (예컨대, 데이터 기밀성 (confidentiality), 데이터 무결성 (data integrity) , 소스 인증 (source authentication))이 만족된 부트스트랩 메시지 또는 부트스트랩 인터페이스를 통 해 제공되는 모든 정보를 전부 신뢰하고 받아들인다.
[185] 서버 정보
[186] M2M클라이언트와 M2M서버가 통신을 하려면 M2M서버와 통신하기 위한 기 본적인 정보들과 부가적인 정보들 (부트스트랩을 통해 전달되는 정보)이 M2M 부트 스트랩 서버를 통해 제공되어야 한다. 이러한 정보의 예로는 서버 ID, 서버 주소 (예컨대, IP, URI), 보안 자격 (security credential), 네트워크 베어러 정보 (network bearer information) , 선호되는 네트워크 베어러 정보 (preferred network bearer information), M2M서버가 생성가능한 리소스 (예컨대, 관리 객체, 객체) 등이 있다. 특정 M2M서버 (관련) 부트스트랩 정보는 상기 서버 정보를 의 미할 수 있다.
[187] 접근 제어 정보 (Access Control Information)
[188] M2M서버가 M2M클라이언트의 특정 리소스에 접근하려면 해당 리소스에 대 한 접근 권한이 있어야 한다. 부트스트랩을 통해서 이러한 접근 제어 관련된 정보 (즉, ACL(Access Control List) 또는 ACL 을 포함한 리소스)들 또한 변경 가능하 다. 해당 정보는 부트스트램을 통해 제공될 수도 있고 아닐 수도 있다.
[189] 재 -부트스트랩
[190] 재-부트스트랩은 부트스트랩을 통해 부트스트랩 정보에 기반하여 M2M 클라 이언트와 M2M서버 간의 통신 중에 문제가 발생할 경우, 또는 해당 통신으로 변경 이 불가능한 자원 (예컨대, 읽기 -전용 (read-only) 리소스)이 존재할 경우, 이를 변 경하기 위해 사용된다. 그러기에, 이전 부트스트랩을 통해 부트스트랩 정보는 이 미 M2M 클라이언트 내에 존재하는 것이다. 이럴 경우 재-부트스트랩은 기존 또는 초기 부트스트램과는 다르게 동작함으로써 효율성을 높일 수 있다.
[191] 부분 재 -부트스트랩
[192] 재 -부트스트랩 시 부트스트랩 정보의 전체 제공 (provision)을 하지 않고, 기존의 정보에 기반하여 부트스트랩 정보의 일부를 변경할 수 있도록 한다. 이렇 게 함으로써 재 -부트스트랩 시 부트스트랩 서버가 전달하는 부트스트랩 정보를 줄 일 수 있어, 네트워크의 데이터 오버헤드를 줄일 수 있다.
[193] 부분 재-부트스트랩인지 여부는 재 -부트스트랩 메시지 내의 부트스트랩 정 보 (갱신될 정보만을 포함)를 통해 결정될 수 있으며, 또는 재 -부트 스트랩의 부트 스트램 정보 중 어떤 정보를 변경할 지를 알리는 지시자를 통해 부분적으로 부트 스트램이 가능하도록 할 수 있다.
[194] 한편, 부트스트랩 서버는 논리적 엔티티로서 부트스트랩 기능만을 담당하 는 서버이며, 물리적으로는 특정 M2M서버와 동일할 수 있다.
[195] 초기화 옵션 (Initialization Option)
[196] 종래 재-부트스트랩을 할 경우, 부트스트랩이 다시 발생하였기에 M2M클라 이언트는 기존의 부트스트랩 정보에 포함된 서버 정보는 물론, M2M 서버 관련된 정보 (예컨대, ACL)를 모두 삭제하고 부트스트랩을 수행하였다. 이에, M2M서버 관 련된 정보가 M2M 클라이언트에 유지할 수 없기에 해당 정보를 M2M 부트스트랩 서 버가 백업 (back up) 등의 방법으로 따로 저장하고 부트스트램 후 따로 제공 (provision) 해야 하는 번거로움이 있었다. 이에 부트스트랩 시 초기화 옵션을 두 어 옵션이 설정되어 있을 경우에만 M2M서버 관련 정보를 삭제할 수 있도록 한다. 이렇게 할 경우 재-부트스트랩을 통해 일부 정보만을 업데이트하고 싶을 시, 초기 화하지 않음으로써 좀 더 편리하게 재-부트스트랩을 할 수 있다.
[197] 재 -부트스트랩 인식 (Re-bootstrap Recognition)
[198] M2M 클라이언트는 재 -부트스트랩 메시지 내 재-부트스트랩임을 지시하는 파라미터, 또는 이전 부트스트랩 메시지를 통해 M2M클라이언트에 저장된 정보 (예 컨대, 특정 서버의 계정 정보)에 기반하여 수신되는 메시지가 재 -부트스트랩 메시 지임을 인지할 수 있다.
[199] 부트스트램 (재-부트스트랩) 메시지 기반 정보 저장
[200] 부트스트랩 메시지에는 실제 갱신하고자 하는 정보의 위치 (또는 주소)가 포함될 수 있다. 이럴 경우 M2M클라이언트는 해당 정보를 해당 위치에 저장한다. 상기 부트스트랩 메시지에는 실제 갱신하는 정보를 유추할 수 있는 정보가 포함될
수 있다. 예를 들어, 고유하게 하나의 객체 인스턴스를 지시할 수 있는 값을 포함 시켜, M2M 클라이언트가 해당 값을 가지는 객체 인스턴스를 갱신할 수 있다.
[201] 생성가능한 객체와 같은 접근 제어 관련된 정보는 접근 제어 정보를 한 곳 으로 수집하고자 부트스트랩 메시지를 통해 전송된 정보를 변경 후 접근 제어 객 체 (인스턴스)에 저장할 수 있다.
[202] - 재 -부트스트랩 유형 #1
[203] ·전체 재 -부트스트랩
[204] 특정 M2M 서버와의 전체 재-부트스트랩이 발생한 경우, M2M 클라이언트는 해당 M2M서버의 부트스트랩 정보 모두를 변경한다. 전체 또는 부분 부트스트랩인 지 여부는 재 -부트스트랩 시의 파라미터에 따라 또는 재 -부트스트랩 메시지에 존 재하는 정보에 따라 결정된다.
[205] 전체 부트스트랩일 경우에는, M2M 서버의 부트스트랩 정보를 초기화 할지 또는 부트스트랩 정보만을 갱신할지를 선택할 수 있다. 즉, 부트스트랩 정보 초기 화 시에는 해당 M2M서버의 이전 부트스트랩 정보를 모두 삭제한다. 또한, M2M 클 라이언트에 존재하는 부트스트랩 정보에 포함되지 않은 해당 M2M 서버와 관련된 정보 (예컨대, ACL) 또한 삭제한다. 이후, 재-부트스트랩의 정보대로 다시 부트스 트랩을 수행한다. 즉, 상기 M2M 클라이언트는 상기 M2M 클라이언트에 존재하는 해 당 M2M서버의 정보를 모두 삭제하고, 마치 상기 M2M서버가 새롭게 부트스트랩을 수행한 것처럼 상기 M2M 클라이언트에서 해당 M2M 서버의 정보를 초기화 한다. 초 기화를 하지 않고 갱신올 하는 경우, 상기 M2M 클라이언트는 해당 부트스트랩 정 보만을 갱신한다 (M2M서버와 관련된 정보는 삭제되지 않고 유지된다 .).
[206] ·부분 재 -부트스트랩
[207] 특정 M2M 서버와의 부분 재-부트스트랩이 발생한 경우 M2M 클라이언트는 상기 특정 M2M 서버의 이전 부트스트랩 정보 중 일부만을 변경한다. 어떤 부분을 변경하는지는 재 -부트스트랩 시의 파라미터에 따라 또는 재-부트스트랩에 존재하 는 정보에 따라 결정된다. 즉, 부분 재-부트스트랩의 경우 전체 부트스트랩 정보 중 일부만 변경 또는 갱신이 가능하다. 또한, M2M 서버와 관련된 정보 (예컨대, ACL) 또한 삭제되지 않는다. 이렇게 함으로써, M2M 서버와 관련된 정보를 유지하 면서도 M2M서버의 특정 부트스트랩 정보만이 변경될 수 있다. 이러한 부분 재-부
트스트램의 장점으로는 M2M 서버와 관련된 부트스트랩 정보를 유지하면서도 부트 스트램을 수행할 수 있다는 점이 된다.
[208] 한편 M2M 서버 관련 부트스트랩 정보를 유지하려면, 재-부트스트랩되는 부트스트랩 정보에서 특정 정보 (예컨대 , Server URI , Short Server ID)와 같이 특 정 M2M서버를 식별할 수 있는 정보는 변경되어서는 안 된다.
[209] *재 -부트스트램 플로우
[210] 도 4 는 본 발명의 일 실시예에 따른 전체 재 -부트스트랩 절차의 플로우를 도시한다.
[211] M2M 클라이언트는 M2M 서버 부트스트랩 메시지를 수신할 수 있다 (S301). 상기 M2M 클라이언트는 상기 M2M 서버로부터 재 -부트스트랩 메시지를 수신하고, 상기 재 -부트스트랩 메시지에는 재-부트스트랩임을 알리는 정보가 포함되어 있거 나 또는 이미 존재하는 M2M 서버 계정 정보가 있다면 그를 통해 상기 M2M 클라이 언트는 재-부트스트랩임을 알 수 있다.
[212] 상기 M2M 클라이언트는 상기 재 -부트스트랩 메시지가 전체 재 -부트스트랩 메시지 또는 부분 재 -부트스트랩 메시지인지를 판단할 수 있다 (S302). 상기 M2M 클라이언트는 상기 재 -부트스트랩 메시지가 상기 M2M 서버 관련 부트스트랩 정보 전체를 변경하는 것인지 또는 부분적으로 변경하는 것인지 여부를 확인할 수 있다.
[213] 상기 M2M 클라이언트는 상기 재 -부트스트랩 메시지에 포함된 상기 M2M 클 라이언트에 존재하는 상기 M2M서버 관련 부트스트랩 정보의 일부를 갱신할 수 있 다 (S303). 상기 M2M 클라이언트는 상기 M2M서버 관련 부트스트랩 정보 중 일부를 변경할 수 있다. 변경 시, 재—부트스트랩 메시지에 포함된 정보로 바로 변경할 수 있고, 재—부트스트랩 메시지에 포함된 정보 중 파라미터를 통해 명시된 특정 정보 만을 변경할 수 있다.
[214] 상기 재-부트스트랩이 전체 부트스트랩 정보에 관한 것이면, 상기 M2M 클 라이언트는 상기 재 -부트스트랩 메시지에 포함된 상기 M2M 클라이언트에 존재하는 상기 M2M서버 관련 부트스트랩 정보를 삭제할 수 있다 (S304).
[215] 그리고나서, 상기 M2M 클라이언트는 초기화가 필요한지 여부를 확인할 수 있다 (S305). 초기화 여부는 재 -부트스트랩 정보에 파라미터로서 포함될 수 있거나, 또는 디폴트로 설정될 수도 있다.
[216] 상기 M2M 클라이언트는 상기 재 -부트스트랩 메시지에 포함되지 않은 상기 M2M 클라이언트에 존재하는 상기 M2M 서버 관련 부트스트랩 정보를 삭제할 수 있 다 (S306) .
[217] 그리고나서, 상기 M2M 클라이언트는 재 -부트스트랩 메시지에 포함된 상기 M2M서버 관련 부트스트랩 정보를 설치 (생성 또는 쓰기)할 수 있다 (S307).
[218] 한편, S304 및 S307 이 통합되어 한번에 부트스트랩 정보가 갱신될 수 있 다. 또한, 재 -부트스트랩 이후 M2M서버와의 연결이 발생할 수 있다.
[219] - 재—부트스트랩 유형 #2
[220] 도 5는 본 발명의 일 실시예에 따른 재-부트스트랩의 플로우를 도시한다.
[221] ·초기화 재 -부트스트랩
[222] 초기화 재-부트스트랩은 M2M 클라이언트가 M2M 서버와 관련된 부트스트랩 정보를 모두 삭제하고, 상기 M2M 서버의 부트스트랩 정보 (즉, 서버 계정 또는 다 른 부트스트랩 정보)를 제공 (provision)하는 것을 지칭한다.
[223] ·부트스트램 정보의 재 -부트스트랩
[224] 부트스트랩 정보의 재-부트스트랩의 경우, M2M 클라이언트는 M2M 서버의 부트스트랩 정보 (즉, 서버 계정 또는 다른 부트스트램 정보)만을 갱신할 수 있다. 상기 M2M 서버 관련 부트스트랩 정보를 유지하려면, 재-부트스트랩되는 부트스트 랩 정보에서 특정 정보 (예컨대, Server URI, Short Server ID)와 같이 특정 M2M 서버를 식별할 수 있는 정보는 변경되어서는 안 된다. 한편, 부트스트램 정보가 서버 계정에 관한 정보밖에 없을 경우, 서버 계정만이 재-부트스트랩을 통해 갱신 된다.
[225] '재 -부트스트램 플로우
[226] M2M 클라이언트는 M2M서버 관련 재-부트스트랩을 위한 부트스트랩 메시지 를 수신할 수 있다 (S401). 상기 M2M 클라이언트는 상기 M2M 서버로부터 부트스트 랩 메시지를 수신할 수 있다. 상기 부트스트랩 메시지에는 재-부트스트랩임을 알 리는 정보가 포함되어 있어 재-부트스트랩임을 지시할 수 있거나, 또는 이미 존재 하는 M2M 서버 관련 계정 정보가 있다면 상기 M2M 클라이언트는 재-부트스트랩임 을 알 수 있다.
[227] 상기 M2M 클라이언트는 상기 부트스트랩 메시지가 부트스트랩 정보의 갱신 을 위한 것인지 또는 부트스트랩 정보의 초기화를 수반하는 것인지를 결정할 수 있다 (S402).
[228] 상기 부트스트랩 메시지가 부트스트랩 정보의 갱신을' 위한 것이면, 상기 M2M 클라이언트는 상기 부트스트랩 메시지에 포함된 상기 M2M 클라이언트에 존재 하는 M2M서버 관련 부트스트램 정보를 갱신할 수 있다 (S403).
[229] 상기 M2M 클라이언트는 상기 M2M 서버 관련 부트스트랩 정보를 변경할 수 있다. 변경 시, 재 -부트스트랩 메시지에 포함된 정보로 바로 변경할 수 있고, 재- 부트스트랩 메시지에 포함된 정보 중 파라미터를 통해 명시된 특정 정보만을 변경 할 수 있다.
[230] 상기 부트스트랩 메시지가 초기화를 수반하는 재-부트스트랩을 위한 것이 면, 상기 M2M 클라이언트는 상기 부트스트랩 메시지에 포함된 상기 M2M 클라이언 트에 존재하는 M2M서버 관련 부트스트랩 정보를 삭제할 수 있다 (S404).
[231] 그리고나서, 상기 M2M 클라이언트는 상기 부트스트랩 메시지에 포함되지 않은 상기 M2M 클라이언트에 존재하는 M2M 서버 관련 부트스트랩 정보를 삭제할 수 있다 (S405).
[232] 그리고나서, 상기 M2M 클라이언트는 상기 부트스트랩 메시지에 포함된 상 기 M2M서버 관련 부트스트랩 정보를 설치할 수 있다 (S406).
[233] 한편, S404 및 S406 이 통합되어 한번에 부트스트랩 정보가 갱신될 수 있 다. 또한, 재 -부트스트랩 이후 등록이 발생할 수 있다.
[234] ᅳ 재 -부트스트램 유형 #3
[235] 도 6은 본 발명의 일 실시예에 따른 재-부트스트랩의 플로우를 도시한다.
[236] M2M 클라이언트는 M2M 서버 관련 재 -부트스트랩 메시지를 수신할 수 있다 (S501). 상기 M2M 클라이언트는 특정 M2M 서버로부터 재-부트스트랩을 위한 부트 스트랩 메시지 (이하, "재 -부트스트랩 메시지" 로 지칭될 수 있음)를 수신할 수 있다. 상기 부트스트랩 메시지에는 재-부트스트랩임을 알리는 정보가 포함되어 재 -부트스트랩임을 지시할 수 있거나, 또는 이미 존재하는 M2M서버 계정 정보가 있 다면 상기 M2M클라이언트는 재-부트스트랩임을 알 수 있다.
[237] 상기 M2M 클라이언트는 상기 재 -부트스트랩 메시지가 초기화 옵션을 갖는 지 여부를 확인할 수 있다 (S502).
[238] 만약 상기 재—부트스트랩 메시지가 초기화 옵션을 가지면, 상기 M2M 클라 이언트는 상기 재 -부트스트랩 메시지에 포함되지 않은 상기 M2M 클라이언트에 존 재하는 상기 M2M서버 관련 부트스트랩 정보 (예건대 ACL)를 삭제할 수 있다 (S503).
[239] 그리고나서, 초기화 옵션 여부와 상관 없이 상기 M2M 클라이언트는 상기 재—부트스트랩 메시지에 포함된 상기 M2M 클라이언트에 존재하는 상기 M2M 서버 관련 부트스트랩 정보를 갱신할 수 있다 (S504). 상기 M2M 클라이언트는 상기 M2M 서버의 부트스트랩 정보를 변경할 수 있다.
[240] 변경 시, 재 -부트스트랩 메시지에 포함된 정보로 바로 변경할 수 있고 재 -부트스트램 메시지에 포함된 정보 중 파라미터를 통해 명시된 특정 정보만올 변 경할 수 있다.
[241] - 재 -부트스트랩 유형 #4
[242] M2M 클라이언트 또는 서버는 부트스트램을 통해 부트스트랩 정보에 해당하 는 정보를 모두 또는 일부를 업데이트할 수 있다. 즉, M2M 부트스트랩 서버는 여 러 쓰기 동작 명령을 통해 부트스트랩 정보 모두를 제공 (provision)할 수 있고, 여러 쓰기 동작 명령 또는 하나의 쓰기 동작 명령을 통해 부트스트랩 정보 중 일 부만을 갱신할 수 있다.
[243] 종래에 부트스트랩 정보 전체를 업데이트해야 했던 이유는, 실제 부트스트 랩 정보는 정보만을 제공할 뿐, 해당 정보가 어디에 쓰여야 (where to write) 하 는지에 대한 것은 클라이언트에게 맡겼었다. 즉, 부트스트램 정보를 상기 클라이 언트에게 제공할 뿐, 상기 클라이언트가 상기 부트스트랩 정보를 어디에 기록 또 는 저장해야 하는지는 상기 M2M 서버 또는 M2M 부트스트랩 서버가 별도의 질의 (Query)를 통해 알아내야 했다.
[244] 그러나, 부트스트랩 서버가 부트스트랩 단계에서부터 재 -부트스트랩 단계 까지 부트스트랩 정보가 어디에 저장 또는 기록되는지를 결정할 수 있다면, 해당 부트스트랩 정보의 주소 (address)를 포함하여 상기 쓰기 동작 명령을 전송하면 된 다. 즉, M2M부트스트랩 서버는 해당 부트스트랩 정보가 M2M 클라이언트의 어디에 저장될 지 재 -부트스트랩 단계에서 알 수 있으면, 저장되는 해당 주소를 통해 업 데이트가 가능하다.
[245] ,갱신하는 방법
[246] M2M 시스템에서 장치 관리 및 서비스 인에이블먼트 인터페이스 (device management and service enablement interface)를 통해 M2M 서버에서 腿 클라이 언트로 특정 동작 명령 (예컨대, Create (생성) /ReacK읽기) /Write (쓰기) /Delete (삭 제) 등)을 통해 특정 리소스에 접근할 수 있었다. 또한 해당 동작 명령들은 접근 제어를 통해서 그 동작 명령을 수행할지 여부가 결정되었다. 즉, 해당 M2M서버가 특정 리소스에 대한 수정을 할 수 없는 M2M 서버이면, 접근 제어 단계에서 해당 동작 명령은 필터링되어 수행되지 않는다. 그러나, 부트스트랩을 수행하는 M2M서 버, 즉 부트스트랩 서버는 아주 특별한 엔티티 (entity)이고, 신뢰할 수 있는 엔티 티이기에, 상기 부트스트랩 서버로부터 수신되는 동작 명령은 모두 접근 제어 단 계를 거치지 않고 상기 M2M 클라이언트는 수락하게 된다.
[247] 상기 부트스트랩 서버와 M2M 클라이언트가 연결된 부트스트랩 인터페이스 를 통해 리소스를 생성하고, 읽고, 수정하고, 삭제하는 모든 것들이 가능할 수 있 거나 이들 중 몇몇만이 수행 가능할 수 있다. 하지만, 상기 부트스트램 서버와의 통신에 있어서 리소스를 생성하고 수정하는 것에 대한 제약을 줄이기 위해 하나의 동작 명령을 통해 이를 수행할 수 있다. 즉, 본 발명의 일 실시예에 따라 M2M 서 버는 하나의 동작 명령을 통해 리소스를 생성하거나 수정하는 것이 가능하다. 하 나의 동작 명령이 M2M 클라이언트에서 수신되면, 상기 M2M 클라이언트는 해당 리 소스가 존재하지 않는다면 생성을 수행하고, 상기 해당 리소스가 존재하는 리소스 라면 수정을 수행할 수 있다. 이는 리소스가 존재하는지 여부를 체크하여 동작 명 령 (operation)을 달리할 필요 없이 바로 리소스에 접근을 할 수 있기 때문에 상기 부트스트랩 서버가 리소스를 읽는 방법이 없을 경우 특히 용이하게 사용할 수 있 고, 그리고 /또는 부트스트랩 서버의 경우 매우 특별하고 신뢰할만한 엔티티이기에 불필요한 접근 제어나 제약 조건들을 고려하지 않음으로써 프로세싱 복잡도 또는 데이터 오버헤드를 감소시킬 수 있다.
[248] 다시 설명하면, 장치 관리 및 서비스 인에이블 인터페이스를 통해 상기 동 작 명령이 수신되면, 상기 M2M 클라이언트는 상기 동작 명령이 유효한지 여부를 상기 동작 명령을 수행하기 이전에 확인하게 된다. 따라서, 상기 동작 명령이 실 제 존재하지 않는 자원을 타깃하고 있는 경우, 예컨대 쓰기 (Write) 동작 명령이 특정 리소스 (예컨대, A/B/C)를 지시하고 있는 경우 상기 특정 리소스가 상기 M2M 클라이언트 내에 존재하지 않으면, 상기 동작 명령은 존재하지 않는 대상을 타깃
하므로 상기 M2M 클라이언트는 상기 동작 명령이 잘못된 대상을 지칭하고 있음을 나타내는 웅답을 상기 M2M서버로 전송하도록 설정된다.
[249] 그러나, 본 발명의 일 실시예에 따르면 부트스트랩 인터페이스를 통해 상 기 동작 명령이 수신되면 상기 동작 명령이 지시하는 대상이 존재하는지 관계 없 이 상기 M2M클라이언트는 상기 동작 명령을 수행하도록 설정된다. 즉, 다른 관점 으로 설명하면, 상기 동작 명령이 상기 장치 관리 및 서비스 인에이블 인터페이스 였다면 오류로 수행되지 않았더라도, 상기 부트스트램 인터페이스를 통해 수신된 동작 명령이라면, 상기 M2M클라이언트는 상기 오류를 실제 오류로 고려하지 않고 상기 동작 명령대로 수행하도록 설정된다.
[250] 재 -부트스트랩
[251] ,언제 재-부트스트랩이 발생하는가
[252] 재-부트스트랩은 기존 최초 부트스트랩 이후 부트스트랩 정보를 업데이트 할 필요가 있을 시, 또는 M2M클라이언트의 읽기 -전용 (Read-only) 자원 /설정의 업 데이트를 위해 수행된다.
[253] 부트스트랩
[254] ·부트스트램 동작 명령
[255] 부트스트랩에 사용되는 동작 명령 (또는 명령 또는 방법)은 일반 동작 (Lightweight M2M 에서는 Device Management and Service Enablement Interface) 에서 실제 자원을 조작하는데 쓰이는 동작 명령 (예컨대 , Cr eat e/De 1 et e/Read/Wr i t e/Wr i t e Attributes/Discover 등)과 동일할 수도 있으며, 이러한 동작 명령들 중 제한적으로 몇몇만이 사용될 수 있다 (예컨대, Write/Delete/Read).
[256] ·인증 절차
[257] 부트스트랩 메시지 또는 부트스트랩 인터페이스를 통해 전송되는 동작 명 령들은 신뢰할만한 부트스트랩 서버 (Lightweight M2M 에서는 Lightweight M2M 부 트스트랩 서버, 이하 동일)로부터 전달되었기에, 클라이언트 (Lightweight M2M 에 서는 Lightweight M2M 클라이언트, 이하 동일)는 기존 일반 동작 (Lightweight M2M 에서는 Device Management and Service Enablement Interface)에서 사용되는 인증 절차 (예컨대 접근 제어)를 수행하지 않거나 인증 절차를 이미 통과하였다고 판단
하고 해당 부트스트램 메시지 또는 부트스트램 인터페이스를 통해 전송되는 동작 명령들을 수행한다.
[258] 기존 일반 동작에서 사용되는 인증 절차에서는 자원이 지원하는 동작 명령 에 따라 명령이 수행되거나 수행되지 않을 수 있다. 즉, 특정 자원이 읽기 (Read) 동작 명령만 지원할 때 서버가 상기 특정 자원에 대한 쓰기 (Write) 동작 명령을 클라이언트로 전달하면, 상기 클라이언트는 동작 명령을 수행하지 못하고, 실패 결과를 상기 서버에 전송한다. 하지만, 부트스트램 인터페이스를 통해 전송되는 동작 명령들은 자원이 지원하는 동작 명령은 무시하고 해당 동작 명령을 수행하도 록 한다. 즉, 상기 클라이언트는 읽기 동작 명령만을 지원하는 자원에 대한 쓰기 동작 명령이 상기 서버로부터 오더라도, 해당 동작 명령을 수행하도록 설정된다. 물론 이러한 경우에 상기 자원은 부트스트램 인터페이스를 통해 읽기 또는 쓰기 동작 명령이 허용되어야 한다.
[259] ,부트스트랩 정보 초기화
[260] 클라이언트에 어떠한 부트스트랩 정보가 존재하는지 알 수 없을 때 또는 모든 자원을 초기화하고자 할 때, 부트스트랩 서버는 부트스트랩 정보의 초기화를 수행할 수 있다. 상기 부트스트램 서버는 해당 명령을 통해 클라이언트에 존재하 는 모든 자원 (또는 M2M 부트스트랩 서버 계정을 제외한 모든 정보 (except Bootstrap Server 계정), 또는 M2M 부트스트랩 서버 계정 및 M2M 서버 계정을 제 외한 모든 정보 (except Bootstrap Server 및 Server 계정), 또는 M2M 부트스트랩 서버의 보안 키를 저장하는 계정을 제외한 모든 정보 (except Bootstrap Server Credential 계정), 또는 M2M 부트스트랩 서버 및 M2M 서버의 보안 키를 저장하는 계정을 제외한 모든 정보 (except Bootstrap 및 Server Credential (보안 키 정보) 계정))들을 삭제할 수 있다. 이후, 상기 부트스트램 서버는 새로운 부트스트랩 정 보를 상기 클라이언트에 전달할 수 있다. 이러한 초기화는 클라이언트의 특정 위 치 (예컨대, " )에 삭제 (Delete) 또는 읽기 (Write) 동작 명령 (빈 값을 포함한) 을 전송함으로써 가능하다. 상기 계정은 객체 인스턴스와 동일할 수 있다.
[261] ·부트스트랩 정보 전달
[262] 부트스트랩 정보는 하나의 메시지를 통해서 전달될 수도 있으며, 또는 여 러 개의 메시지를 통해서 전달될 수 있다. 여러 개의 메시지의 경우 하나의 동작 명령과 각각 매칭되어 전달 될 수 있다.
[263] ·동작 명령 최적화
[264] 부트스트랩 서버는 부트스트랩을 위한 하나의 동작 명령을 통해 여러 개의 동작 명령 기능을 수행할 수 있다. 즉, 부트스트램 인터페이스를 통해서 존재하는 부트스트랩 정보를 알 수 없거나, 부트스트랩 서버의 편의를 위하여 하나의 쓰기
(Write) 동작 명령을 통해 생성 (Create) 또는 쓰기 (Write)를 수행할 수 있다. 클 라이언트의 특정 자원에 대한 쓰기 동작 명령을 전송하는데 있어, 해당 자원이 존 재하지 않을 경우 생성 동작 명령과 동일하게 해당 자원을 생성하고, 해당 자원이 존재할 경우에는 기존의 쓰기 동작 명령과 동일하게 자원을 업데이트하는 역할을 수행한다.
[265] 이하, 본 발명의 일 실시예에 따른 부트스트랩 인테페이스에 대하여 좀더 상세하게 설명하도록 한다.
[266] 부트스트랩 인터페이스는 M2M 클라이언트가 하나 이상의 M2M 서버들과
"등록 (Register)" 동작 명령을 수행할 수 있도록 하기 위해 상기 M2M 클라이언 트에 필수적 정보를 제공 (provision)하는데 사용된다. M2M 인에이블러 (enabler)에 의해 지원되는 네 개의 부트스트랩 모드들이 존재한다.
[267] - 공장 부트스트랩: M2M 클라이언트에 미리 부트스트랩 정보가 설정되어 ¬으
ΛΛᄆ
[268] - 스마트카드로부터의 부트스트램: M2M 클라이언트가 스마트카드로부터 부 트스트램 정보를 받아 음
[269] - 클라이언트 개시 부트스트랩: M2M 클라이언트가 M2M 부트스트랩 서버에 부트스트랩을 요청하고, M2M 부트스트랩 서버는 M2M 클라이언트의 부트스트랩 정 보를 추가 /삭제 /갱신한다.
[270] - 서버 개시 부트스트랩: M2M 부트스트랩 서버는 M2M 클라이언트의 부트스 트랩 정보를 추가 /삭제 /갱신한다.
[271] M2M 클라이언트는 상기 부트스트랩 인터페이스에서 특정된 적어도 하나의 부트스트랩 모드를 지원할 수 있다. M2M 서버는 상기 부트스트랩 인터페이스에서 특정된 모든 부트스트램 모드들을 지원할 수 있다.
[272] 부트스트랩 정보는 M2M 서버 또는 M2M 부트스트랩 서버에 접속하기 위해
M2M 클라이언트에서 설정될 필요가 있는 정보를 지칭한다. 상기 부트스트랩 정보 는 부트스트랩 시¾스를 수행하기 전에 이용가능할 수 있거나, 또는 상기 부트스
트랩 시퀀스의 결과로서 획득될 수 있다. 상기 부트스트램 정보는 두 개의 유형, 즉 M2M 서버를 위한 부트스트랩 정보 및 M2M 부트스트랩 서버를 위한 부트스트랩 정보로 구분될 수 있다.
[273] M2M 클라이언트는 부트스트랩 시뭔스 이후에 M2M 서버를 위한 부트스트랩 정보 (예컨대 M2M 서버와의 연결을 위해 필요한 정보)를 가질 수 있다. 또한, M2M 부트스트랩 서버를 위한 부트스트랩 정보 (예컨대 M2M 부트스트랩 서버와의 연결을 위해 필요한 정보)를 가질 수 있다. 상기 M2M서버를 위한 부트스트랩 정보는 M2M 서버에 등록 및 접속하기 위해 M2M 클라이언트를 위해 사용된다.
[274] M2M 서버를 위한 부트스트랩 정보는 적어도, "부트스트랩 서버" 리소스 가 "false" 로 설정된 M2M서버 보안 객체 인스턴스를 포함할 수 있다. M2M서버 를 위한 부트스트램 정보는 다른 객체 인스턴스들을 포함할 수 있다.
[275] M2M 클라이언트는 각각의 M2M 서버를 위한 부트스트랩 정보의 집합을 포함 한 둘 이상의 M2M 서버들을 사용하도록 구성될 수 있다. M2M 부트스트랩 서버를 위한 부트스트랩 정보는 M2M 서버를 위한 부트스트랩 정보를 획득하기 위해 M2M 부트스트랩 정보에 접속하기 위해 M2M 클라이언트에 의해 사용될 수 있다. 상기 M2M 부트스트램 서버를 위한 부트스트램 정보는 "부트스트램 서버" 리소스가 "true" 로 설정된 M2M서버 보안 객체 인스턴스일 수 있다.
[276] 부트스트램 정보는 다음과 같이 분류될 수 있다.
[277] 【표 15】
[278] M2M 클라이언트는 부트스트랩 인터페이스를 통해 전송된 부트스트랩 정보 를 인증 절차 (접근 제어) 없이 수락할 수 있다.
[279] 상기 부트스트랩 인터페이스는 M2M 클라이언트를 선택적으로 설정하여, 상 기 M2M클라이언트가 성공적으로 M2M서버와 등록 또는 M2M부트스트랩 서버와 연 결하도록 한다. 클라이언트 부트스트랩 동작 명령은 M2M 부트스트랩 서버의 /bs
경로로, 질의 (query) 스트링 (string) 파라미터는 M2M클라이언트 식별자 포함하여 CoAP POST요청을 전송함으로써 수행된다.
[280] 클라이언트 개시 부트스트랩에서, M2M부트스트랩 서버가 부트스트랩 요청 (Request Bootstrap) 동작 명령을 수신하면, 상기 부트스트랩 서버는 쓰기 (Write) 및 /또는 삭제 (Delete) 동작 명령을 수행할 수 있다. 서버 개시 부트스트랩에서, 부트스트랩 서버는 쓰기 (Write) 동작 명령을 수행할 수 있다. 쓰기 및 /또는 삭제 동작 명령은 객체 인스턴스 또는 리소스를 타깃할 수 있다. 상기 쓰기 및 삭제 동 작 명령은 복수 회 (multiple times) 전송될 수 있다. 오직 부트스트랩 인터페이스 에세 삭제 동작 명령은, M2M 부트스트랩 서버가 M2M 클라이언트로 쓰기 동작 명 령 (들)을 전송하기 전에 M2M클라이언트를 초기화를 위해 M2M클라이언트에서 M2M 부트스트랩 서버 계정을 제외한 존재하는 모든 객체 인스턴스들을 삭제하기 위해 7" URI 를 타깃할 수 있다. 장치 관리 및 서비스 인에이블 인터페이스에서의 쓰기 동작 명령과 달리, 상기 M2M 클라이언트는 타깃하는 객체 인스턴스 또는 리 소스의 존재와 관계없이 상기 동작 명령의 페이로드 (즉, 상기 쓰기 동작 명령으로 기록하고자 (쓰고자) 하는 특정 값)를 기록할 수 있다. 다음은 부트스트랩 인터페 이스에서의 동작 명령을 나타낸다. 상기 쓰기 동작 명령은 타 동작 명령 (예컨대, 생성)으로 대체 가능하다.
[281] 【표 16】
[282] 부트스트랩 시퀀스
[283] M2M 클라이언트는 M2M 기기를 부트스트랩을 시도하려고 할 때 아래의 부트 스트랩 시뭔스 (단계)를 따라야 한다. (The UM2M Client MUST follow the procedure specified as below when attempting to bootstrap a LWM2M Device:) [284] M2M 기기가 스마트카드가 있으면, M2M 클라이언트는 부트스트랩 정보를 스 마트카드로부터 얻으려고 시도한다. (If the LWM2M Device has Smart card, the
LWM2M Client tries to obtain Bootstrap Information from the Smartcard using the Bootstrap from Smartcard mode.)
[285] M2M 클라이언트가 스마트카드로부터 설정되지 않는다면, M2M클라이언트는 제조자 부트스트램 (factory bootstrap) 모드로 부트스트램 정보를 얻으려고 시도 해 본다. (If the LWM2M Client is not configured using the Bootstrap from Smartcard mode, the LWM2M Client tries to obtain the Bootstrap Information by using Factory Bootstrap mode.)
[286] M2M 클라이언트가 이전 단계들을 통해 M2M 서버 객체 인스턴스를 가지고 있다면, M2M 클라이언트는 해당 M2M 서버 객체 인스턴스에 해당하는 M2M 서버에 등록을 요청한다. (If the UM2M Client has any L丽 2M Server Object Instances from the previous steps, the LWM2M Client tries to register to the LWM2M Server (s) configured in the LWM2M Server Object Instance(s) . )
[287] M2M클라이언트가 모든 M2M서버에 등록을 실패할 경우 또는 클라이언트가 M2M 서버 객체 인스턴스를 가지고 있지 않을 경우, M2M 클라이언트는 서버 개시 부트스트랩을 특정 자원 (ClientHoldOffTim)이 명시한 시간만큼 기다렸다가, 서버 개시 부트스트랩이 상기 시간 동안 발생하지 않으면 M2M클라이언트는 클라이언트 개시 부트스트랩을 통해 부트스트랩 정보를 얻는 것을 시도한다. (If L丽 2M Client fails to register to all the LWM2M Servers or the Client doesn' t have any LWM2M Server Object Instances, and the LWM2M Client hasn' t received a Server Initiated Bootstrap within the CI ientHoldOf fTime, the LWM2M Client performs the Client Initiated Bootstrap. )
[288] 클라이언트 개시 부트스트랩
[289] M2M 서버 계정이 M2M 클라이언트 내에 설정되지 않거나 (존재하지 않거나) M2M서버와의 "등록" 동작 명령을 수행하기 위한 시도가 실패되는 경우가 있을 수 있다. 이러한 경우, M2M 클라이언트는 M2M 부트스트랩 서버로부터 부트스트랩 정보를 가져오기 (retrieve)하기 위해 클라이언트 -개시 부트스트랩 모드를 사용할 수 있다. 상기 클라이언트 -개시 부트스트랩 모드는 M2M부트스트랩 서버를 가리키 는 (참조하는) M2M보안서버 객체 인스턴스가 M2M클라이언트에 설정된 (존재하는) 것을 요구할 수 있다.
[290] 도 7 은 본 발명의 일 실시예에 따른 클라이언트 -개시 부트스트램 모드의 동작을 도시한다. M2M 클라이언트는 미리-제공된 (pre-provisioned) M2M 부트스트 랩 서버 URI 로 "부트스트랩 요청" 동작 명령을 전송할 수 있다 (S601). 상기 부 트스트랩을 요청하는 경우, 상기 M2M 클라이언트는 상기 M2M 부트스트램 서버로 하여금 상기 M2M 클라이언트를 위한 적절한 부트스트랩 정보를 제공하도록 하기 위해 파라미터로서 상기 M2M클라이언트의 "엔드포인트 (endpoint) 클라이언트 이 름" (M2M클라이언트 식별자)을 전송할 수 있다.
[291] 상기 M2M 부트스트랩 서버는 "쓰기" 및 /또는 "삭제" 동작 명령을 사용 하여 상기 M2M 클라이언트에 부트스트랩 정보를 설정 (configure 또는 set)할 수 있다 (S602).
[292] 상기 클라이언트 -개시 부트스트랩은 최초 부트스트랩 이후 부트스트랩 정 보를 갱신하기 위해서 상기 M2M 클라이언트의 상기 부트스트랩 정보의 몇몇 리소 스들을 설정하는데 사용될 수 있다. 이 예에서, 모든 부트스트랩 정보는 선택사항 (optional)로, 전달될 수도 있고 전달되지 않을 수도 있다.
[293] 서버 개시 부트스트랩
[294] 서버 -개시 부트스트랩은 M2M 클라이언트가 M2M 부트스트랩 서버로 부트스 트랩 요청을 전송하지 않고, M2M부트스트랩 서버가 M2M 클라이언트에 부트스트랩 정보를 설정할 수 있다. 상기 M2M 클라이언트가 상기 M2M 부트스트랩 서버로 "부 트스트랩 요청" 동작 명령을 개시하지 않기 때문에, 상기 M2M 부트스트랩 서버는 상기 M2M 클라이언트가 상기 M2M부트스트랩 서버에 의해 설정되기 전에 M2M 장치 또는 M2M 클라이언트가 부트스트랩할 준비가 되었는지 여부를 알 필요가 있다. 상 기 M2M 부트스트랩 서버가 이러한 지식을 획득하기 위한 메커니즘은 본 발명에서 다루진 않는다. 일 예로 M2M 장치가 네트워크 제공자의 네트워크에 접속하는 경우, 네트워크 제공자의 네트워크가 M2M 부트스트랩 서버에게 M2M 장치의 부트스트랩 준비여부를 알려주는 시나리오가 가능하다.
[295] 상기 M2M 부트스트랩 서버가 상기 M2M 장치가 상기 부트스트랩 정보를 수 신할 준비가 되었음을 통지받으면, 상기 M2M 부트스트램 서버는 "쓰기" 및 /또는 "삭제" 동작 명령을 사용하여 상기 부트스트랩 정보를 상기 M2M 클라이언트를 설정할 수 있다.
[296] 도 8 은 본 발명의 일 실시예에 따른 서버 -개시 부트스트랩 모드의 동작을 도시한다. M2M부트스트램 서버는 "쓰기" 및 /또는 "삭제" 동작 명령을 사용하 여 상기 M2M 클라이언트에서 상기 부트스트램 정보를 설정할 수 있다 (S701).
[297] 상기 서버 -개시 부트스트램은 최초 부트스트램 이후 부트스트랩 정보를 업 데이트하기 위해서 상기 M2M 클라이언트의 상기 부트스트랩 정보의 몇몇 리소스들 을 설정하기 위해 사용될 수 있다. 이 예에서, 모든 부트스트랩 정보는 선택사항 (optional)로, 전달될 수도 있고 전달되지 않을 수도 있다.
[298] 위와 같은 부트스트랩 모드에 따라, 재-부트스트랩도 다음과 같이 수행될 수 있다.
[299] 재 -부트스트랩 절차
[300] ,미리-설정된 재 -부트스트랩
[301] "미리-설정된 재-부트스트랩" 절차는 M2M 클라이언트에 이미 부트스트랩 정보가 저장된 경우에 수행되는 절차이다. 이 때, M2M 서버 또는 M2M 부트스트랩 서버는 상기 M2M 클라이언트로 어떤 유형 (예컨대 , 전체 또는 부분)의 재―부트스트 랩인지, 특정 유형의 재-부트스트랩인 경우 어떤 정보가 재 -부트스트랩되어야 하 는지에 대한 파라미터를 재 -부트스트랩 메시지에 포함시킬 수 있다. 상기 재 -부트 스트램 메시지는 하나의 메시지를 통해 전송될 수 있거나, 또는 여러 메시지를 통 해 전송될 수 있다.
[302] ·스마트 카드 재 -부트스트랩
[303] M2M 클라이언트가 스마트 카드로부터 재-부트스트랩을 수행하는 절차에 관 한 것이다. 이 때, M2M 서버 또는 M2M 부트스트랩 서버는 상기 M2M 클라이언트로 어떤 유형 (예컨대, 전체 또는 부분)의 재 -부트스트랩인지, 특정 유형의 재-부트스 트랩인 경우 어떤 정보가 재 -부트스트랩되어야 하는지에 대한 파라미터를 재 -부트 스트랩 메시지에 포함시킬 수 있다.
[304] ·클라이언트 개시 재 -부트스트랩
[305] M2M 클라이언트가 요청하여 재-부트스트랩을 수행하는 절차에 관한 것이다. 이 때, 상기 재 -부트스트랩 요청이 M2M 서버로부터 전송되고, 이를 통해 재 -부트 스트램을 수행할 수도 있다. M2M서버 또는 M2M부트스트랩 서버는 상기 M2M 클라 이언트로 어떤 유형 (예컨대, 전체 또는 부분)의 재 -부트스트랩인지, 특정 유형의
재-부트스트랩인 경우 어떤 정보가 재 -부트스트랩되어야 하는지에 대한 파라미터 를 재 -부트스트랩 메시지에 포함시킬 수 있다.
[306] ·서버 개시 재 -부트스트랩
[307] M2M 서버가 요청하여 재ᅳ부트스트랩을 수행하는 절차에 관한 것이다. M2M 서버 또는 M2M부트스트랩 서버는 상기 M2M클라이언트로 어떤 유형 (예컨대, 전체 또는 부분)의 재 -부트스트랩인지 특정 유형의 재-부트스트랩인 경우 어떤 정보가 재 -부트스트랩되어야 하는지에 대한 파라미터를 재 -부트스트랩 메시지에 포함시킬 수 있다.
[308] M2M서버 계정 추가
[309] M2M 서버 계정은 M2M 서버 보안 객체 인스턴스 (부트스트랩 (bootstrap) 서 버 리소스가 "false" 로 설정된)와 그와 연관된 M2M 서버 객체 인스턴로 구성된 다. 참고로, M2M 부트 스트랩 서버 계정은 부트스트램 서버 리소스가 "true" 로 설정된 M2M서버 보안 객체 인스턴스로 구성된다.
[310] 상기 M2M 서버 계정은 상기 부트스트랩 정보에 포함되며, 상기 M2M 서버 부트스트랩 정보는 M2M 클라이언트에 의해 M2M 서버를 등록하거나 접속하기 위해 사용된다.
[311] 이하는 서버 보안 객체 인스턴스와 서버 객체 인스턴스를 간략히 설명한다.
[312] M2M 서버 보안 객체 (또는 객체 인스턴스)는 특정된 M2M 서버 또는 M2M 부 트스트랩 서버에 접근하기 적절한 M2M 클라이언트의 키잉 매터리얼 (key material) 을 제공한다. 하나의 객체 인스턴스는 M2M 부트스트랩 서버를 지칭 (address)하는 것을 권장한다. 상기 M2M서버 보안 객체의 리소스들은 M2M부트스트랩 서버 또는 스마트카드로부터의 부트스트랩 인터페이스를 통해 변경될 수 있으나,다른 어떤 M2M 서버에 의해서도 접근될 수 없다.
[314] 【표 18】
[315] 다음은 M2M 서버 객체 (또는 객체 인스턴스)에 대해 설명한다. M2M 서버 객 체는 M2M 서버와 관련된 데이터를 제공한다. M2M 부트스트랩 서버는 그와 관련된 이러한 객체 인스턴스를 갖지 않는다.
[317] 【표 20】
[319] 한편, 앞서 설명한 본 발명의 일 실시예에 따른 부분적 재-부트스트랩에 있어서, 상기 재-부트스트랩을 위한 메시지 (즉, 부트스트랩의 수행을 위한 동작 명령)가 상기 부트스트랩 인터페이스를 통해 전송된 것인지 여부를 확인할 필요가 있다.
[320] 앞서 설명한 것처럼, 부트스트랩 인터페이스를 통한 특정 동작 명령은 쓰 기 (Write) 또는 생성 (Create) 동작 명령일 수 있으며, 이는 본 명세서에서는 구체 적으로 설명하진 않겠지만 실제로 CoAP PUT 또는 CoAP POST 을 통해 전달되며 이 를 통해 M2M 클라이언트는 상기 동작 명령을 어떤 M2M 서버가 전송했는지 여부를 확인할 수 있다.
[321] 또한, 상기 부트스트랩 인터페이스를 통해 상기 동작 명령이 전송 (또는 수 신)되었는지 여부는, 상기 동작 명령올 전송한 서버가 M2M 부트스트랩 서버인지 여부를 통해 확인할 수 있다. 즉, 상기 동작 명령을 전송한 M2M 서버가 M2M 부트 스트램 서버라면, 상기 동작 명령은 부트스트랩 인터페이스를 통해 전송된 것으로 판단될 수 있다.
[322] 좀더 구체적으로, 상기 M2M 클라이언트는 상기 M2M 서버 보안 객체 인스턴 스를 참조하여, 그 내에 포함된 "부트스트랩 (bootstrap) 서버" 리소스가 "true" 또는 "false" 로 설정되었는지 여부를 확인하여 상기 M2M 서버가 M2M 부트스트랩 서버인지 여부를 확인할 수 있다. M2M 클라이언트는 동작 명령을 받으 면, 동작 명령을 전송한 대상을 확인하고, 필요시 동작 명령을 복호화하는데 여기 서 사용되는 정보가 상기 "부트스트랩 서버" 리소스가 "true" 로 설정되어 있 는 M2M 서버 보안 객체 인스턴스의 정보 (예컨대 LWM2M Server URI , Public Key or Identity, Server Public Key or Identity, Secret Key 자원의 값)이면, 상기 메 시지 (또는 동작 명령)은 상기 부트스트랩 인터페이스를 통해 전송된 것이므로; 상 기 M2M 클라이언트는 상기 동작 명령에 대한 인증 절차를 수행하지 않을 뿐만 아 니라, 상기 동작 명령의 타깃, 즉 객체, 객체 인스턴스 또는 리소스가 존재하는지 여부를 고려하지 않는다.
[323] M2M서버 계정의 추가에 따른 접근 제어 관련 동작
[324] 본 발명의 또 다른 일 실시예에 따라 M2M 클라이언트에 하나의 M2M 서버 계정만이 존재하다가 또 다른 M2M서버 계정이 새롭게 추가될 경우, M2M 클라이언 트의 동작을 설명하도록 한다.
[325] 상기 M2M 클라이언트는 상기 M2M 클라이언트에 존재하는 객체 인스턴스 (객 체 ID, 객체 인스턴스 ID를 가진)들에 대한 접근 제어 객체 인스턴스를 생성하거 나 이미 상기 접근 제어 객체 인스턴스가 존재하는 경우 상기 접근 제어 객체 인 스턴스를 수정한다. M2M 클라이언트에 존재하는 각각의 객체 인스턴스에 대해 접 근 제어 객체 인스턴스 내의 객체 ID자원의 값에는 존재하는 객체 인스턴스의 객 체 ID 를 설정하고, 객체 인스턴스 ID 자원의 값에는 존재하는 객체 인스턴스의 객체 인스턴스 ID 를 설정한다. 접근 제어 객체 인스턴스 안의 ACL 자원에는 기존 존재하던 하나의 M2M 서버 (상기 M2M 서버를 지시할 수 있는 식별자)가 해당 객체 인스턴스에 대해 모든 권한을 가지도록 설정한다. 접근 제어 객체 인스턴스 내의 접근 제어 소유자에는 기존 존재하던 하나의 M2M서버 (상기 M2M 서버를 지칭할 수 있는 식별자)를 설정한다.
[326] 좀더 상세히 설명하면, M2M 클라이언트가 오직 하나의 M2M 서버 계정을 가 지고 있는 경우에 새로운 M2M서버 계정이 추가되면, 상기 M2M 클라이언트는 상기 M2M클라이언트에 있는 모든 객체 인스턴스에 대해, 좀더 바람직하게는 서버 보안 객체 인스턴스를 제외하고 모든 객체 인스턴스에 대해 접근 제어 객체 인스턴스들 을 생성하거나 수정할 수 있다. 이 경우, 다음과 같은 를 (rule)에 따라 상기 접근 제어 객체 인스턴스의 생성 또는 수정이 이루어진다.
[327] ·접근 제어 소유자는 이전에 존재하던 (계정의) M2M서버로 설정됨
[328] ·이전에 존재하던 M2M서버는 모든 접근 권한을 갖도록 설정됨
[329] 상기 롤은 경우에 따라 접근 권한을 달리하여 두 개의 접근 제어 객체 인 스턴스로 나뉘어 생성 될 수 있다. 이 경우 두 개의 접근 제어 객체 인스턴스에 명시된 접근 권한을 합하면 모든 접근 권한이 된다.
[330] 상기 모든 접근 권한은 특정 동작 명령 (예컨대 생성 (Create)를 제외되어
ΛΛ己 丁 누 ·
[331] 본 발명의 또 다른 일 실시예에 따라 Μ2Μ 클라이언트에 둘 이상의 Μ2Μ 서 버 계정이 존재할 경우, 또 다른 Μ2Μ서버 계정이 새롭게 추가될 경우, Μ2Μ 클라 이언트의 동작을 설명하도록 한다.
[332] 두 개 이상의 Μ2Μ 서버 계정이 존재할 경우, 어떤 객체 인스턴스를 특정 Μ2Μ 서버가 생성할 경우 해당 객체 인스턴스에 관련 접근 제어 객체 인스턴스를 자동으로 생성하는데, 접근 제어 객체 인스턴스에 대한 세팅은 아래와 같다.
[333] 객체 ID 와 객체 인스턴스 ID 자원은 "생성 (Create)" 동작 명령으로 인 해 생성된 객체 인스턴스의 객체 ID와 객체 인스턴스 ID를 갖는다.
[334] ACL 자원은 "생성 (Create)" 동작 명령을 수행한 M2M 서버 (상기 M2M 서버 를 지칭할 수 있는 식별자)가 설정된다.
[335] 접근 제어 소유자는 M2M 서버 (상기 M2M 서버를 지칭할 수 있는 식별자)가 설정된다.
[336] 두 개의 M2M서버 계정에서 더 추가될 경우 추가적인 프로시저는 존재하지 않는다.
[337] 좀더 상세하게는 M2M 클라이언트가 둘 이상의 M2M 서버 계정을 가지고 있 고 이 때 둘 중 하나의 M2M 서버가 특정 객체 인스턴스에 대해 "생성 (Create)" 동작 명령을 전송하면, 상기 M2M 클라이언트는 상기 생성된 객체 인스턴스에 대한 접근 제어 객체 인스턴스를 생성할 수 있다. 이 경우, 다음과 같은 를 (rule)에 따 라 상기 접근 제어 객체 인스턴스의 생성 또는 수정이 아루어진다.
[338] ·접근 제어 소유자는 상기 "생성" 동작 명령을 전송한 M2M 서버로 설정 됨
[339] ·상기 접근 제어 소유자인 M2M서버는 모든 접근 권한을 갖도록 설정됨 [340] 상기 를은 경우에 따라 접근 권한을 달리하여 두 개의 접근 제어 객체 인 스턴스로 나뉘어 생성 될 수 있다. 이 경우 두 개의 접근 제어 객체 인스턴스에 명시된 접근 권한을 합하면 모든 접근 권한이 된다.
[341] 상기 모든 접근 권한은 특정 동작 명령 (예컨대 생성 (Create)를 제외되어 있을 수 있다.
[342] 도 9 는 본 발명의 실시예 (들)을 수행하도록 구성된 장치의 블록도를 도시 한다. 전송장치 (10) 및 수신장치 (20)는 정보 및 /또는 데이터, 신호, 메시지 등을 나르는 무선 신호를 전송 또는 수신할 수 있는 R Radio Frequency) 유닛 (13 23) 과, 무선통신 시스템 내 통신과 관련된 각종 정보를 저장하는 메모리 (12 22), 상 기 RF 유닛 (13 23) 및 메모리 (12, 22)등의 구성요소와 동작적으로 연결되고, 상 기 구성요소를 제어하여 해당 장치가 전술한 본 발명의 실시예들 중 적어도 하나 를 수행하도록 메모리 (12, 22) 및 /또는 RF 유닛 (13,23)을 제어하도록 구성된 프로 세서 (11, 21)를 각각 포함한다.
[343] 메모리 (12, 22)는 프로세서 (11, 21)의 처리 및 제어를 위한 프로그램을 저 장할 수 있고, 입 /출력되는 정보를 임시 저장할 수 있다. 메모리 (12, 22)가 버퍼 로서 활용될 수 있다.
[344] 프로세서 (11ᅳ 21)는 통상적으로 전송장치 또는 수신장치 내 각종 모듈의 전반적인 동작을 제어한다. 특히 , 프로세서 (11, 21)는 본 발명을 수행하기 위한 각종 제어 기능을 수행할 수 있다. 프로세서 (11, 21)는 컨트를러 (controller), 마 이크로 컨트롤러 (microcontrol ler) , 마이크로 프로세서 (microprocessor ) , 마이크 로 컴퓨터 (microcomputer) 등으로도 불릴 수 있다. 프로세서 (11, 21)는 하드웨어 (hardware) 또는 펌웨어 (firmware) , 소프트웨어, 또는 이들의 결합에 의해 구현될 수 있다. 하드웨어를 이용하여 본 발명을 구현하는 경우에는, 본 발명을 수행하도 록 구성된 ASICs(appl icat ion specific integrated circuits) 또는 DSPs(digital signal processors) , DSPDs(digital signal processing devices) , PLDs( programmable logic devices) , FPGAs(f ield programmable gate arrays) 등이 프로세서 (11, 21)에 구비될 수 있다. 한편, 펌웨어나 소프트웨어를 이용하여 본 발명을 구현하는 경우에는 본 발명의 기능 또는 동작들을 수행하는 모들, 절차 또 는 함수 등을 포함하도록 핍웨어나 소프트웨어가 구성될 수 있으며, 본 발명을 수 행할 수 있도록 구성된 펌웨어 또는 소프트웨어는 프로세서 (11, 21) 내에 구비되 거나 메모리 (12, 22)에 저장되어 프로세서 (11, 21)에 의해 구동될 수 있다.
[345] 본 발명의 실시예들에 있어서, M2M 서버 또는 M2M 클라이언트, 또는 서버 또는 단말 등은 각각 그들이 설치되어 있거나 탑재되어 있는 장치들, 즉 전송장치 (10) 또는 수신장치 (20)로 동작할 수 있다.
[346] 이와 같은, 수신장치 또는 전송장치로 M2M 서버, M2M 클라이언트, 서버 또 는 단말 등의 구체적인 구성은, 도면과 관련하여 전술한 본 발명의 다양한 실시예 에서 설명한 사항들이 독립적으로 적용되거나 또는 둘 이상의 실시예가 동시에 적 용되도톡 구현될 수 있다.
[347] 상술한 바와 같이 개시된 본 발명의 바람직한 실시예들에 대한 상세한 설 명은 당업자가 본 발명을 구현하고 실시할 수 있도록 제공되었다. 상기에서는 본 발명의 바람직한 실시예들을 참조하여 설명하였지만, 해당 기술 분야의 숙련된 당 업자는 하기의 특허 청구의 범위에 기재된 본 발명의 사상 및 영역으로부터 벗어 나지 않는 범위 내에서 본 발명을 다양하게 수정 및 변경시킬 수 있음을 이해할
수 있을 것이다. 따라서, 본 발명은 여기에 나타난 실시형태들에 제한되려는 것이 아니라, 여기서 개시된 원리들 및 신규한 특징들과 일치하는 최광의 범위를 부여 하려는 것이다.
【산업상 이용가능성】
[348] 본 발명은 무선 이동 통신 시스템의 단말기, 기지국, 서버 또는 기타 다 른 장비에 사용될 수 있다.