KR101700197B1 - 장치 관리를 위한 노드의 주소 표현 방법 및 이를 위한 장치 - Google Patents

Abstract

본 발명은 장치 관리(device management)를 위한 특정 노드를 지정하는 URI(Uniform Resource Identifier)의 해석(resolve) 방법 및 이를 위한 장치에 관한 것으로서, 상기 URI에 포함된 MOID(Management Object Identifier)와 MO 인스턴스 정보에 따라 적어도 하나의 MO 인스턴스를 찾는 단계; 및 상기 적어도 하나의 MO 인스턴스 내에서, 상기 URI에 포함된 MO 인스턴스 루트 노드로부터 상기 특정 노드까지의 경로를 이용하여 상기 특정 노드를 찾는 단계를 포함하되, 상기 MO 인스턴스 정보가 MIID(Management Object Instance Identifier)를 포함하는 경우, 상기 적어도 하나의 MO 인스턴스를 찾는 단계는 상기 MOID와 상기 MIID를 가지는 유일한 MO 인스턴스를 찾는 것과, 상기 MOID와 상기 MIID를 가지는 MO 인스턴스가 없거나 복수로 존재하는 경우 에러를 반환하는 것을 포함하는 방법 및 이를 위한 장치에 관한 것이다.

Description

장치 관리를 위한 노드의 주소 표현 방법 및 이를 위한 장치{METHOD FOR ADDRESSING NODE ADDRESS FOR DEVICE MANAGEMENT AND APPARATUS THEREFOR}

본 발명은 장치 관리에 관한 것으로서, 구체적으로 장치 관리를 위해 사용되는 노드의 주소 표현 방법 및 이를 위한 장치에 관한 것이다.

현재의 통신 환경은 단말의 종류와 그 기능 및 응용 서비스가 폭증하면서 사업자 정책과 사용자 요구 그리고 변화하는 네트워크 환경에 맞게 단말과 응용 서비스를 설정하는 것이 점차 어려워지고 있다. 장치 관리 기술은 이러한 문제점을 해결하기 위하여 제3자가 사용자를 위해 효과적인 방법으로 그들이 사용하는 장치를 관리할 수 있도록 하는 기술이다.

장치 관리 기술은 또한 WAP(Wireless Application Protocol), 3GPP(3rd Generation Partnership Project), OSGi(Open Service Gateway Initiative), TMF(Telemanagement Forum)등이 개발한 응용 서비스에 대한 서비스 관리를 가능하게 해주며, OMA 장치 관리 기술이 이러한 필요를 충족시켜줄 수 있는 기술로 점점 자리매김 하고 있다. 또한, OMA 장치 관리 기술은 범세계적인 이동 통신 시장의 이용 사례(Use Case)와 요구 사항을 고려하여 개발되고 있으며, 특히 단말의 종류, 운영체제, 지역, 네트워크 기술에 제한되지 않은 열린 기술이기 때문에 결국 기존의 일부 특정 네트워크와 단말기에 국한된 장치 관리 기술들을 통합하거나 대체할 수 있는 기술이다.

본 발명의 목적은 장치 관리에 사용되는 노드의 주소 표현/해석 방법 및 이를 위한 장치를 제공하는 데 있다.

본 발명의 다른 목적은 동일한 관리 객체 식별자(MOID)를 가지는 관리 객체 인스턴스를 효율적으로 지정할 수 있는 주소 표현/해석 방법 및 이를 위한 장치를 제공하는 데 있다.

본 발명의 또 다른 목적은 관리 객체 인스턴스에 포함된 무명 노드(Unnamed Node)를 효율적으로 지정할 수 있는 주소 표현/해석 방법 및 이를 위한 장치를 제공하는 데 있다.

본 발명의 또 다른 목적은 하나의 노드 주소를 이용하여 복수의 노드를 지정할 수 있는 주소 표현/해석 방법 및 이를 위한 장치를 제공하는 데 있다.

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

본 발명의 일 양상으로, 디바이스에서 장치 관리(device management)를 위한 특정 노드를 지정하는 URI(Uniform Resource Identifier)의 해석(resolve) 방법이 제공되며, 상기 방법은 상기 URI에 포함된 MOID(Management Object Identifier)와 MO 인스턴스 정보에 따라 적어도 하나의 MO 인스턴스를 찾는 단계; 및 상기 적어도 하나의 MO 인스턴스 내에서, 상기 URI에 포함된 MO 인스턴스 루트 노드로부터 상기 특정 노드까지의 경로를 이용하여 상기 특정 노드를 찾는 단계를 포함하되, 상기 MO 인스턴스 정보가 MIID(Management Object Instance Identifier)를 포함하는 경우, 상기 적어도 하나의 MO 인스턴스를 찾는 단계는 상기 MOID와 상기 MIID를 가지는 유일한 MO 인스턴스를 찾는 것과, 상기 MOID와 상기 MIID를 가지는 MO 인스턴스가 없거나 복수로 존재하는 경우 에러를 반환하는 것을 포함할 수 있다.

본 발명의 다른 양상으로서, 장치 관리(device management)를 위한 특정 노드를 지정하는 URI(Uniform Resource Identifier)를 해석(resolve)하는 장치가 제공되며, 상기 장치는 메모리; 및 상기 메모리에 연결되는 프로세서를 포함하되, 상기 프로세서는 상기 URI에 포함된 MOID(Management Object Identifier)와 MO 인스턴스 정보에 따라 적어도 하나의 MO 인스턴스를 찾고, 상기 적어도 하나의 MO 인스턴스 내에서, 상기 URI에 포함된 MO 인스턴스 루트 노드로부터 상기 특정 노드까지의 경로를 이용하여 상기 특정 노드를 찾도록 구성되며, 상기 MO 인스턴스 정보가 MIID(Management Object Instance Identifier)를 포함하는 경우, 상기 적어도 하나의 MO 인스턴스를 찾는 단계는 상기 MOID와 상기 MIID를 가지는 유일한 MO 인스턴스를 찾는 것과, 상기 MOID와 상기 MIID를 가지는 MO 인스턴스가 없거나 복수로 존재하는 경우 에러를 반환하는 것을 포함할 수 있다.

바람직하게는, 상기 MO 인스턴스 정보가 제1 구획 문자, 알파벳 문자, 제2 구획 문자 문자로 구성되는 경우, 상기 URI는 적어도 하나의 노드 값 필드를 더 포함하고, 상기 적어도 하나의 노드 값 필드 각각은 상기 MO 인스턴스 정보에 의해 표현되는 위치로부터 리프 노드(leaf node)까지의 경로와 상기 리프 노드의 노드 값을 포함하며, 상기 적어도 하나의 MO 인스턴스를 찾는 것은 상기 적어도 하나의 노드 값 필드 모두에 대해 상기 리프 노드가 상기 노드 값을 가지도록 하는 유일한 MO 인스턴스를 찾는 것을 포함할 수 있다.

더욱 바람직하게는, 상기 적어도 하나의 노드 값 필드 각각은 상기 제1 구획 문자, 상기 알파벳 문자, 상기 제2 구획 문자로 구성되는 상기 MO 인스턴스 정보를 포함할 수 있다.

바람직하게는, 상기 MO 인스턴스 정보가 빈 문자열(empty string)로 구성되는 경우, 상기 적어도 하나의 MO 인스턴스를 찾는 것은 상기 디바이스에서 상기 MOID를 가지는 유일한 MO 인스턴스를 찾는 것을 포함할 수 있다.

바람직하게는, 상기 MO 인스턴스 정보가 와일드카드 문자로 구성되는 경우, 상기 적어도 하나의 MO 인스턴스를 찾는 것은 상기 디바이스에서 상기 MOID를 가지는 모든 MO 인스턴스를 찾는 것을 포함할 수 있다.

바람직하게는, 상기 MO 인스턴스 루트 노드로부터 상기 특정 노드까지의 경로가 제1 구획 문자, 알파벳 문자, 제2 구획 문자로 구성되는 노드 이름을 포함하는 경우, 상기 URI는 적어도 하나의 노드 값 필드를 더 포함하고, 상기 적어도 하나의 노드 값 필드 각각은 상기 노드 이름이 가리키는 위치로부터 리프 노드(leaf node)까지의 경로와 상기 리프 노드의 노드 값을 포함하며, 상기 특정 노드를 찾는 단계는 상기 적어도 하나의 노드 값 필드 모두에 대해 상기 리프 노드가 상기 노드 값을 가지도록 하는 유일한 노드를 찾는 것을 포함할 수 있다.

더욱 바람직하게는, 상기 적어도 하나의 노드 값 필드 각각은 상기 제1 구획 문자, 상기 알파벳 문자, 상기 제2 구획 문자로 구성되는 상기 노드 이름을 포함할 수 있다.

바람직하게는, 상기 MO 인스턴스 루트 노드로부터 상기 특정 노드까지의 경로가 와일드카드 문자로 구성되는 노드 이름을 포함하는 경우, 상기 특정 노드를 찾는 것은 상기 와일드카드 문자의 위치에 해당하는 모든 노드를 찾는 것을 포함할 수 있다.

바람직하게는, 상기 MO 인스턴스 루트 노드로부터 상기 특정 노드까지의 경로가 하나의 구획 문자로 구성되는 경우, 상기 특정 노드를 찾는 것은 상기 MO 인스턴스 루트 노드를 찾는 것을 포함할 수 있다.

본 발명에 따르면, 장치 관리에 사용되는 노드의 주소를 표현/해석할 수 있다.

또한, 본 발명에 따르면, 동일한 관리 객체 식별자(MOID)를 가지는 관리 객체 인스턴스를 효율적으로 지정할 수 있다.

또한, 본 발명에 따르면, 관리 객체 인스턴스에 포함된 무명 노드를 효율적으로 지정할 수 있다.

또한, 본 발명에 따르면, 하나의 노드 주소를 이용하여 복수의 노드를 지정할 수 있다.

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

첨부 도면은 본 발명에 관한 이해를 돕기 위해 상세한 설명의 일부로 포함되는 것으로서, 본 발명에 대한 실시예를 제공하고 상세한 설명과 함께 본 발명의 기술적 사상을 설명한다.
도 1은 DM 트리를 예시한다.
도 2와 도 3은 노드 주소를 사용하는 방법을 예시한다.
도 4는 특정 단말에서 구성될 수 있는 DM 트리의 예를 예시한다.
도 5는 가상 URI를 이용하여 DM 서버가 전송하는 명령을 예시한다.
도 6은 가상 URI를 이용한 주소 표현 방식을 예시한다.
도 7은 본 발명에 따른 인스턴스 URI를 표현하는 문법(syntax)을 예시한다.
도 8은 MO 인스턴스를 예시한다.
도 9는 본 발명에 따른 인스턴스 URI를 해석(resolve)하는 방법의 순서도를 예시한다.
도 10은 본 발명에 따른 MIID를 가져오는 방법의 순서도를 예시한다.
도 11은 본 발명에 따른 인스턴스 URI와 MOID URI를 표현하는 문법(syntax)을 예시한다.
도 12는 본 발명에 따른 MOID URI를 해석(resolve)하는 방법의 순서도를 예시한다.
도 13은 본 발명에 따른 x-name을 이용한 URI를 표현하는 문법(syntax)을 예시한다.
도 14는 본 발명에 따른 x-name을 이용한 URI를 해석(resolve)하는 방법의 순서도를 예시한다.
도 15는 본 발명에 따른 URI를 표현하는 문법(syntax)을 예시한다.
도 16은 <x> 노드를 포함하는 MO와 MO 인스턴스를 예시한다.
도 17은 본 발명이 적용될 수 있는 디바이스 및 서버를 예시한다.

본 발명은 장치 관리(Device Management)에 관한 것이다. 하지만, 본 발명은 장치 관리에만 한정되어 적용되는 것은 아니며, 본 발명의 기술적 사상이 적용될 수 있는 모든 시스템 및 방법에 적용될 수 있다. 예를 들어, 트리 구조를 이용한 데이터 구조를 가지는 모든 시스템 및 방법에 적용될 수 있다.

본 명세서에서 사용되는 기술적 용어는 단지 특정한 실시예를 설명하기 위해 사용되는 것으로, 본 발명을 한정하려는 의도가 아님을 유의해야 한다. 또한, 본 명세서에서 사용되는 기술적 용어는 본 명세서에서 특별히 다른 의미로 정의되지 않는 한, 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에 의해 일반적으로 이해되는 의미로 해석되어야 하며, 과도하게 포괄적인 의미로 해석되거나, 과도하게 축소된 의미로 해석되지 않아야 한다. 또한, 본 명세서에서 사용되는 기술적인 용어가 본 발명의 사상을 정확하게 표현하지 못하는 잘못된 기술적 용어일 때에는, 당업자가 올바르게 이해할 수 있는 기술적 용어로 대체되어 이해되어야 할 것이다. 또한, 본 발명에서 사용되는 일반적인 용어는 사전에 정의되어 있는 바에 따라, 또는 전후 문맥상에 따라 해석되어야 하며, 과도하게 축소된 의미로 해석되지 않아야 한다.

이하, 첨부된 도면을 참조하여 본 발명에 따른 바람직한 실시예를 상세히 설명한다. 도면 부호에 관계없이 동일하거나 유사한 구성 요소는 동일한 참조 번호를 부여하고 이에 대한 중복되는 설명은 생략하기로 한다. 또한, 첨부된 도면은 본 발명의 사상을 쉽게 이해할 수 있도록 하기 위한 것일 뿐 첨부된 도면에 의해 본 발명의 사상이 제한되는 것으로 해석되어서는 아니됨을 유의해야 한다. 본 발명의 사상은 첨부된 도면 외에 모든 변경, 균등물 내지 대체물에 까지도 확장되는 것으로 해석되어야 한다.

이하 도면들에서 디바이스가 도시되어 있으나, 디바이스는 휴대폰, PDA, 스마트 폰(Smart Phone), 무선 모뎀(Wireless Modem), 노트북 등과 같이 통신 기능을 갖춘 휴대용 장치 뿐만 아니라 개인용 컴퓨터(Personal Computer, PC)나 차량 탑재 장치 등과 같이 휴대 불가능한 장치일 수 있다. 또한, 본 명세서에서 디바이스는 UE(User Equipment), ME(Mobile Equipment), MS(Mobile Station), UT(User Terminal), SS(Subscriber Station), 무선 디바이스(Wireless Device), 핸드헬드 디바이스(Handheld Device), AT(Access Terminal), 단말과 등가의 의미로 사용될 수 있다.

OMA(Open Mobile Alliance) 규격에 따른 장치 관리(Device Management, DM)를 지원하는 단말은 장치 관리(DM)를 위해 필요한 데이터를 포함하는 데이터 구조(data structure)를 가질 수 있다. 예를 들어, 관리 객체(Management Object, MO)는 트리 형태의 데이터 구조를 가질 수 있다. 장치 관리(DM)를 위한 트리 구조는 관리 트리(Management Tree) 또는 장치 관리 트리(Device Management Tree)로 지칭될 수 있으며, 혹은 간략히 DM 트리라고 지칭될 수 있다. DM 트리는 DM 서버가 DM 클라이언트와 통신하는 인터페이스 역할을 할 수 있다. 또한, OMA 규격에서는 장치 관리를 위해 적어도 하나의 관리 객체(MO)를 정의하고 있으며, 장치 관리를 지원하는 단말은 특정 장치 관리 기능을 수행하기 위해 적어도 하나의 관리 객체(MO) 인스턴스를 가질 수 있다. 단말에서 관리 객체(MO) 인스턴스는 특정 데이터 구조(data structure)의 형태로 저장될 수 있다. 예를 들어, 관리 객체(MO) 인스턴스는 트리 형태의 데이터 구조를 가질 수 있으며, DM 트리의 서브트리(subtree)일 수 있다. 따라서, 단말에서 지원하는 MO 중에서 인스턴스가 생성된 MO는 DM 트리 안에서 하나의 서브트리로 저장될 수 있다.

DM 트리는 단일 구성요소(single element)로서 표현되는 노드를 적어도 하나 가질 수 있다. DM 트리의 각 노드는 데이터를 저장하지 않거나 또는 적어도 하나의 데이터를 저장할 수 있다. 각 노드에 저장되는 적어도 하나의 데이터는 노드 값(node value)이라고 지칭될 수 있다. DM 트리에서 최상위 레벨에 위치하며 부모 노드(parent node)를 가지지 않는 노드는 루트 노드(root node)라고 지칭될 수 있다. 루트 노드는 하나의 캐릭터 “.”로 표시될 수 있다. 또한, DM 트리에서 자식 노드(child node)를 가지지 못하고 노드 값을 가질 수 있는 노드는 리프 노드(leaf node)라고 지칭될 수 있다. 자식 노드를 가질 수 있지만 어떠한 노드 값도 가질 수 없는 노드는 인테리어 노드(interior node)라고 지칭될 수 있다. DM 트리의 각 노드는 URI(Uniform Resource Identifier)에 의해 표현되는 고유의 주소를 가질 수 있다.

도 1은 단말이 가질 수 있는 DM 트리를 예시한다. 도 1에서 제한적이지 않은 예로서, 단말은 장치 관리 계정 관리를 위한 DMAcc(DM Account Management Object), 펌웨어 업데이트 관리를 위한 FUMO(Firmware Update Management Object), 소프트웨어 컴포넌트 관리를 위한 SCOMO(Software Component Management Object), 장치 진단 및 모니터링 관리를 위한 DiagMon(Diagnostics and Monitoring Management Object), 장치 잠금/해제 관리를 위한 LAWMO(Lock And Wipe Management Object)와 같은 관리 객체(MO)를 지원할 수 있다. 여기서, 단말이 특정 MO를 지원한다는 것은 단말이 DM 서버로부터 특정 MO와 관련된 명령을 수신한 경우 특정 MO 규격에 맞추어 명령을 처리하고 그 결과를 DM 서버에게 돌려줄 수 있다는 것을 의미한다.

도 1을 참조하면, 레벨 3의 DM 트리가 예시되어 있다. 도 1에서 루트 노드(102)는 “.”로서 예시되어 있다. 또한, 도 1의 DM 트리는 DMAcc 인스턴스, FUMO 인스턴스, SCOMO 인스턴스, DiagMon 인스턴스를 포함할 수 있다. 또한, FUMO 인스턴스는 “PkgName”라는 노드와 “PkgVersion”이라는 노드를 포함할 수 있다. 또한, “PkgName” 노드와 “PkgVersion” 노드는 각각 “froyo”라는 노드 값을 가질 수 있다. 도 1의 DM 트리에서, “PkgName” 노드를 어드레싱하기 위해 “./FUMO/PkgName”이라는 고유의 주소가 사용될 수 있다. 이러한 고유의 주소를 이용해서 DM 서버는 단말의 DM 클라이언트로부터 해당 노드에 저장되어 있는 노드 값(예, “froyo”)을 가져올 수 있다.

단말이 특정 MO를 지원하지만 특정 MO의 인스턴스가 없는 경우, MO의 인스턴스가 DM 트리에 포함되어 있지 않을 수 있다. 이 경우, DM 서버는 특정 MO에 대한 인스턴스를 Add 명령(command)을 사용하여 DM 트리에 생성한 다음, 특정 MO와 관련된 관리 명령을 수행할 수 있다. 도 1의 예에서, 단말이 LAWMO를 지원하지만 LAWMO 인스턴스는 생성되어 있지 않다. LAWMO와 관련된 명령은 LAWMO 인스턴스를 대상으로 하기 때문에, DM 서버는 LAWMO와 관련된 명령을 단말의 DM 클라이언트에게 전달할 수 없다. 이 경우, DM 서버는 먼저 LAWMO 인스턴스를 DM 트리에 생성한 다음, LAWMO와 관련된 명령을 전송하여 LAWMO와 관련된 관리 명령을 수행할 수 있다.

OMA DM에서 사용되는 주소는 URI 형태로 표현되며, 아래와 같은 규칙이 적용된다.

■ URI는 “/”로 끝나서는 안 된다. 따라서, DM 트리에서 루트 노드의 URI는 “./”가 아닌 “.”로 표현되어야 한다.

■ URI는 “../”를 포함하지 않아야 한다. “./”는 URI의 시작에서만 사용되어야 한다.

표 1은 장치 관리 프토토콜에서 사용될 수 있는 DM 명령(command)들을 예시한다.

표 1에서 HTTP는 하이퍼텍스트 전송 프로토콜(Hypertext Transfer Protocol)을 나타낸다. 또한, DM 세션(session)은 하나 이상의 장치 관리 동작(device management operation)을 수행하기 위해 수립된(established) DM 서버와 디바이스 간의 연속적인 연결(continuous connection)을 의미할 수 있다. MOID(Management Object Identifier)는 OMA 규격에서 정의된 MO 타입을 식별하는 식별자로서, 아래에서 자세히 설명한다.

도 2는 노드 주소를 사용하는 방법을 예시한다. 구체적으로, 도 2는 DM 서버가 Get 명령과 함께 노드 주소를 DM 클라이언트로 전달하는 방법을 나타낸다. Get 명령은 하나의 URI를 파라미터로 가질 수 있다. URI가 리프 노드(leaf node)를 가리키는지 인테리어 노드(interior node)를 가리키는지에 따라 Get 명령은 다르게 처리된다. URI가 리프 노드를 가리킬 경우, DM 클라이언트는 리프 노드의 노드 값(node value)를 반환한다. DM 서버는 <Target>/<LocURI>를 통해 URI를 지정할 수 있고, DM 클라이언트는 <Item>/<Data>를 통해 해당 노드의 값을 반환할 수 있다. 도 2의 예에서 DM 서버가 “./FUMO/PkgName” 노드(도 1의 112)에 대해 Get 명령을 수행하면 DM 클라이언트는 “./FUMO/PkgName” 노드의 값 “froyo”를 DM 서버로 반환할 수 있다.

도 3은 노드 주소를 사용하는 방법을 예시한다. 만일 URI가 인테리어 노드를 가리킨다면, DM 클라이언트는 인테리어 노드가 가지는 자식 노드(child node)의 목록을 반환한다. 도 3의 예에서, DM 서버가 “./FUMO” 노드(도 1의 106)에 대해 Get 명령을 수행하면, DM 클라이언트는 “./FUMO/PkgVersion”과 “./FUMO/PkgName”를 DM 서버로 반환할 수 있다.

앞서 설명된 바와 같이, DM 프로토콜에서 MO 인스턴스는 DM 트리의 서브트리로 구성될 수 있다. 이 경우, MO 인스턴스에 대한 서브트리는 구현하기에 따라 DM 트리에서 서로 다른 노드 위치에 서로 다른 이름으로 구성될 수 있다. 따라서, 전체 DM 트리에서 MO 루트 노드는 고정된 노드 이름과 고정된 주소를 갖지 않을 수 있다. 예를 들어, 한 종류의 단말에서 FUMO의 MO 루트 노드는 “./fumo”가 될 수도 있고, 다른 종류의 단말에서는 “./mycompany/fumo”가 될 수도 있으며, 심지어는 "./scomo"라는 이름으로 지정될 수 있다. 이러한 특징으로 인해, 단말 종류마다 DM 트리를 유연하게 구성할 수 있는 반면, DM 서버의 측면에서는 MO 루트 노드 이름만을 이용하여 MO 인스턴스를 구별하지 못할 수 있다. 예를 들어, FUMO 루트 노드가 만약 “./scomo”라는 주소를 갖는 경우, DM 서버는 이 노드가 SCOMO의 루트 노드인지 FUMO의 루트 노드인지 구별할 수 없다.

이러한 문제를 해결하기 위해, DM 프로토콜에서는 각 MO 타입을 고유하게 식별하는 식별 정보를 MO마다 부여하고 있으며, 이러한 식별 정보를 MOID(Management Object Identifier)라고 지칭한다. 예를 들어, MOID는 URN(Uniform Resource Names) 형태를 가질 수 있다. MOID는 단말에 생성된 모든 MO 인스턴스에 할당되며 MO 인스턴스의 MO 타입을 구분하는 데 사용될 수 있다. 예를 들어, DM 프로토콜에서, FUMO 1.0의 MOID는 “urn:oma:mo:oma-fumo:1.0”일 수 있고, SCOMO 1.0의 MOID는 “urn:oma:mo:oma-scomo:1.0”일 수 있다. MOID는 각 MO 인스턴스의 루트 노드의 Type 속성(attribute)에 저장될 수 있다. 따라서, 노드의 Type 속성 값이 FUMO의 MOID를 가지면 FUMO 루트 노드이고, SCOMO의 MOID를 가지면 SCOMO 루트 노드이다. 또한, OMA DM에서 MO는 DDF(Device Description File)을 이용하여 기술될 수 있는데, 단말의 관리 기능을 기술하는 DDF에서는 <DFProperties>/<DFType> 요소를 이용하여 MO 루트 노드에 MOID를 할당할 수 있다. 따라서, DDF의 <DFProperties>/<DFType> 요소와 DM 트리의 Type 속성을 통해 MOID를 가지고 있는 노드는 MO의 루트 노드라고 판단할 수 있다. 따라서, 한 노드가 MO의 루트 노드인지를 판단하기 위해, 노드 이름과 주소를 이용하지 않고 노드에 할당되어 있는 MOID를 이용한다.

DM 프로토콜(예, DM 1.3)은 DM 트리 안의 특정 노드를 지칭하기 위해, 3가지 방식의 주소 표현 방식(addressing scheme)을 지원한다. 예를 들어, 이러한 주소 표현 방식(addressing scheme)은 일반적으로 URI 형태로 표현될 수 있다. DM 서버는 특정 명령을 DM 클라이언트에게 전달할 때 명령의 대상이 되는 노드 정보를 URI를 통해 전달할 수 있다. 예를 들어, DM 서버가 “Get”이라는 명령과 "./a/b/c”라는 URI를 DM 클라이언트에게 전달하면, DM 클라이언트는 URI “./a/b/c”에 의해 지칭되는 노드의 정보를 DM 서버에게 반환한다.

절대 URI 주소 표현 방식(Absolute URI Addressing Scheme)

절대(Absolute) URI는 DM 트리의 루트 노드로부터 시작하여 노드를 표현하는 주소 표현 방식이다. 절대(Absolute) URI는 DM 트리의 루트 노드를 포함하여 기술되기 때문에 DM 트리의 루트 노드를 나타내는 “.”으로 시작된다. 예를 들어 도 1의 예에서, 노드(112)를 절대 URI로 나타내면 “./FUMO/PkgName”일 수 있다.

절대 URI는 DM 트리의 루트 노드에서부터 노드의 주소를 표현하므로 DM 트리 안에서 절대 URI가 지칭하는 노드를 쉽게 알 수 있다. 하지만, MO 인스턴스는 구현에 따라 DM 트리에서 서로 다른 노드 위치에 구성될 수 있으므로 MO 인스턴스에 대한 절대 URI는 단말 종류마다 혹은 단말마다 달라질 수 있다. 예를 들어, DM 서버는 펌웨어 업데이트(Firmware Update)라는 DM 명령을 실행하기 위해 보통 EXEC 명령을 FUMO의 “Update” 노드에 전달한다. 이를 위해, EXEC 명령과 함께 FUMO의 “Update” 노드를 가리키는 URI를 단말로 전달할 수 있다. 하지만, 이 URI가 절대 URI로서 표현되는 경우, 단말마다 URI가 달라질 수 있으므로 DM 서버는 펌웨어 업데이트를 위한 URI를 단말에서 FUMO 인스턴스가 어떻게 구성되는지에 따라 서로 다르게 구성해야 한다.

이러한 문제점은 MO 인스턴스의 루트 노드 위치가 단말마다 다르게 설정될 수 있다는 점에서 기인한다. FUMO, SCOMO 등과 같은 대부분의 MO의 경우, 전체 DM 트리에서 MO 인스턴스의 루트 노드 위치가 단말마다 고정되어 있지 않다. 이러한 MO의 경우, MO 인스턴스 루트 노드는 무명 노드(unnamed node) 또는 <x> 노드로서 표현되며, DDF에 해당 노드의 이름이 기술되지 않을 수 있다. 이러한 MO의 경우, DM 트리 안에 MO 인스턴스를 생성할 때, MO 인스턴스의 위치(MO 인스턴스 루트 노드 위치)가 자유롭게 결정될 수 있다. 따라서, MO로 이루어진 DM 트리 구성을 단말의 특성을 고려해 유연하게 할 수 있게 하는 반면, DM 서버가 DM 명령을 전달하기 전에 해당 명령이 전달될 절대 URI를 먼저 알아내야 하는 문제점이 있다.

상대 URI 주소 표현 방식(Relative URI Addressing Scheme)

상대(Relative) URI는 DM 트리의 루트 노드에 대한 상대인 주소를 표현하는 주소 표현 방식이다. 상대(Relative) URI는 “.”로 시작하지 않으며, DM 트리의 루트 노드에 대한 상대적인 주소를 나타낸다. 예를 들어 도 1의 예에서, 노드(112)를 상대 URI로 나타내면 “FUMO/PkgName”일 수 있다. 절대(Absolute) URI가 DM 트리의 루트 노드를 포함하여 주소를 나타내는 반면, 상대(Relative) URI는 DM 트리의 루트 노드를 포함하지 않는다. 예를 들어, 절대 URI에서 루트 노드를 나타내는 “./”를 삭제하면 상대 URI가 된다. 따라서, 상대 URI도 절대 URI와 동일한 문제점을 가질 수 있다.

가상 URI 주소 표현 방식(Virtual URI Addressing Scheme)

절대(Absolute) URI와 상대(Relative) URI는 주소 표현 형태가 간단한 장점이 있다. 하지만, 앞서 설명된 바와 같이, DM 트리에서 MO 인스턴스가 저장되는 위치는 동일한 MO라도 단말마다 달라질 수 있다. 따라서, 동일한 MO라도 단말마다 절대(Absolute) URI 또는 상대(Relative) URI가 달라진다는 문제점이 있다. 이에 반해, 가상(Virtual) URI는 MOID를 이용하여 노드의 주소를 표현하는 방식이다. MOID는 MO 인스턴스의 루트 노드를 나타내므로 DM 트리에서 MO 인스턴스의 저장 위치가 단말에 따라 달라지더라도 MOID를 이용하여 MO 인스턴스의 루트 노드를 찾을 수 있다. 가상 URI는 두 개의 URI를 사용하여 DM 트리 안의 노드를 나타낸다.

- URI A: 특정 MO 인스턴스를 나타낸다. URI A는 특정 MO 인스턴스의 MO 루트 노드를 가리킴

- URI B: URI A가 가리키는 MO의 MO 루트 노드에 대한 상대인 URI를 나타낸다.

가상(Virtual) URI가 가리키는 노드를 알기 위해 DM 클라이언트는 가상 URI를 절대(Absolute) URI로 변환할 수 있다. 예를 들어, URI A를 절대 URI로 변환한 다음, URI B를 URI A 뒤에 덧붙이는 형태로 가상 URI를 절대 URI로 변환할 수 있다. 하지만, 변환 과정에서 동일한 MOID를 갖는 복수의 MO 인스턴스가 존재한다면, 가상(Virtual) URI는 복수의 절대(Absolute) URI로 변환될 수 있어 문제가 된다. 예를 들어, DCMO(Device Capability Management Object)의 경우, 카메라를 관리하기 위한 DCMO 인스턴스와 USB(Universal Serial Bus)를 관리하기 위한 DCMO 인스턴스가 각각 존재할 수 있다. 하지만, 이들 두 개의 DCMO 인스턴스는 동일한 MOID를 가질 수 있다. 따라서, 이들 두 개의 DCMO 인스턴스에 대하여 URI A는 동일하며 경우에 따라 URI B도 동일할 수 있다.

이러한 문제점을 해결하기 위해, DM 서버는 노드 값(Node Value)을 이용하여 가상(Virtual) URI를 유일한 절대(Absolute) URI으로 변환할 수 있다. 이는 동일한 MOID를 갖는 MO 인스턴스라고 해도 각 노드에 저장되어 있는 노드 값은 다를 수 있다는 것에 의거한 것이다. 만일 가상 URI가 유일한 절대 URI로 변환되지 않을 경우, DM 클라이언트는 가상 URI에 대한 DM 명령을 처리하지 않고 “Not Found”와 같은 에러 코드를 DM 서버로 전송할 수 있다.

URI A는 기본적으로 MOID에 기반하여 MO 인스턴스를 지칭하며, 예를 들어 “<URI>?MOID=<m-value>&<attribute>=<a-value>”의 형태로 표현된다. URI A를 구성하는 구성요소에 대한 설명은 다음과 같다.

- <URI>: 이 구성요소는 DM 클라이언트가 URI A를 절대 URI로 변경하기 위해 MO 인스턴스를 검색할 위치를 특정할 수 있게 한다. 예를 들어, <URI>가 “./mycompany” 값을 갖는 경우, DM 클라이언트는 “./mycompany” 노드와 그 서브트리에서만 MO 인스턴스를 검색한다. 예를 들어, <URI>가 “.” 값을 갖는 경우, DM 클라이언트는 전체 DM 트리를 대상으로 MO 인스턴스를 검색한다.

- MOID=<m-value>: URI A가 나타내는 MO 인스턴스를 MOID를 사용하여 지칭한다. MOID 값은 <m-value>에 기술될 수 있다. 예를 들어, FUMO 인스턴스를 가리킬 경우, <m-value>는 “urn:oma:mo:oma-scomo:1.0”를 가질 수 있다.

- <attribute>=<a-value>: 이 구성요소는 DM 서버가 노드 값을 사용하여 MO 인스턴스를 더 한정할 때 사용될 수 있다. 예를 들어, 동일한 MOID를 갖는 MO 인스턴스가 여러 개 존재할 때 사용될 수 있다. <attribute>는 MO 루트 노드에 대해 상대적인 주소를 URI 형태로 나타내고 <a-value>는 <attribute>가 가리키는 노드의 노드 값(node value)을 나타낸다. 따라서, 동일한 MOID를 갖는 MO 인스턴스가 여러 개 존재하더라도, URI A는 <attribute>에 의해 지칭되는 노드에 <a-value>에 해당하는 값이 들어 있는 MO 인스턴스만을 나타낸다. DM 서버는 복수의 “<attribute>=<a-value>”를 “&”와 같은 연산자로 구분하여 지정할 수 있다. 이 경우, URI A는 복수의 “<attribute>=<a-value>”를 모두 만족하는 MO 인스턴스만을 가리킨다.

URI B는 MO 루트 노드에 대하여 상대적인 URI를 나타내며, [x]로 시작되는 URI이다. 여기서 [x]는 MO 루트 노드를 나타내기 때문에, [x] 뒤에 오는 URI는 MO 루트 노드에 대해 상대적인 노드 주소를 가리킨다.

가상(Virtual) URI의 URI A는 <TargetParent>/<LocURI> 요소를 통해 지정되고, URI B는 <Target>/<LocURI>를 통해 지정된다. Delete 명령에서 MO 인스턴스 전체를 지우고 싶을 때, URI B는 지정되지 않을 수도 있다.

도 4는 특정 단말에서 구성될 수 있는 DM 트리의 예를 예시한다. 도 4의 예에서, DM 트리(400)의 루트 노드는 402이고, DM 트리(400)는 2개의 MO 인스턴스 A1(410), A2(430)를 포함한다. 각 MO 인스턴스 A1(410), A2(430)는 동일한 MOID “urn:oma:mo:oma_example:1.0”를 가지는 것으로 예시되어 있다.

도 4를 참조하면, DM 서버는 노드(416)에 대한 명령을 전송하기 위해 앞서 설명된 3가지 주소 표현 방식 중 하나를 이용할 수 있다. 예를 들어, 절대 URI 주소 표현 방식을 이용하면, 노드(416)는 “./Vendor/A1/E/H”에 의해 표현될 수 있다. 또한, 상대 URI 주소 표현 방식을 이용하면, 노드(416)는 “Vendor/A1/E/H”에 의해 표현될 수 있다. 하지만, 앞서 설명된 바와 같이, 단말에서 DM 트리가 어떻게 관리/구현되는지에 따라 MO 인스턴스의 위치가 달라질 수 있고 DM 서버가 모든 단말에 대한 DM 트리 구성 방식을 알 수 없으므로 문제가 될 수 있다.

또한, 예를 들어, 가상 URI 주소 표현 방식을 이용하면, 노드(416)는 URI A와 URI B에 의해 표현될 수 있다. 예를 들어, URI A는 “<URI>?MOID=<m-value>&<attribute>=<a-value>”의 형태로 표현될 수 있으므로, 노드(416)에 대한 URI A는 “./Vendor?MOID=urn:oma:mo:oma_example:1.0&F=Camera&E/G=Foo”로서 표현될 수 있다. 이 예에서, URI A의 <URI> 구성요소는 “./Vendor”를 가진다. 따라서, 단말의 DM 클라이언트는 “./Vendor”가 가리키는 노드(404) 및 그 서브트리에 있는 MO 인스턴스를 검색할 수 있다. 또한, URI A의 MOID=<m-value> 구성요소는 “MOID=urn:oma:mo:oma_example:1.0”의 값을 가진다. URI A의 <URI>는 “./Vendor”이기 때문에, DM 클라이언트는 “./Vendor”와 그 서브 트리만을 검색하여 특정 MOID를 갖는 MO 인스턴스를 찾는다. 따라서, MOID는 “urn:oma:mo:oma_example:1.0”이다. “./Vendor” 서브 트리 밑에 이러한 MOID를 갖는 MO 인스턴스는 MO 인스턴스 A1(410), A2(430)로서 2개가 존재하며, 각각 “./Vendor/A1”, “./Vendor/A2”에 위치한다. 따라서, 도 4의 예에서는 2개의 MO 인스턴스 A1(410), A2(430)가 동일한 MOID를 가지므로 MOID에 의해 유일한 MO 인스턴스가 지정될 수 없다. 이 경우, <attribute>=<a-value> 구성요소가 사용될 수 있으며, 이 예에서 URI A의 <attribute>=<a-value> 구성요소는 “F=Camera&E/G=Foo”의 값을 가진다. 이 구성요소에 의해 MO 인스턴스 루트 노드 아래의 F 노드(418)의 값이 Camera라는 값을 가지고 MO 인스턴스 루트 노드 아래의 E/G 노드(414)의 값이 Foo의 값을 가지는 MO 인스턴스 A1(410)이 지정될 수 있다.

DM 서버는 URI A를 이용하여 노드(416)를 포함하는 MO 인스턴스를 유일하게 지정하였으므로 URI B를 이용하여 MO 인스턴스 루트 노드에 대한 상대적인 주소를 가리킬 수 있다. 예를 들어, 노드(416)에 대한 가상 URI의 URI B는 “[x]/E/H”로서 표현될 수 있다. [x]는 MO 인스턴스의 루트 노드를 나타낸다.

도 5는 가상 URI를 이용하여 노드(도 4의 416)에 대해 DM 서버가 전송하는 명령을 예시한다.

앞서 설명된 바와 같이, 가상 URI의 URI A는 <TargetParent>/<LocURI> 요소를 통해 지정되므로 도 5에서 노드(도 4의 416)에 대한 가상 URI의 URI A는 “./Vendor?MOID=urn:oma:mo:oma_example:1.0&F=Camera&E/G=Foo”로서 표현될 수 있다. 또한, 가상 URI의 URI B는 <Target>/<LocURI> 요소를 통해 지정되므로 도 5에서 노드(도 4의 416)에 대한 가상 URI의 URI B는 “[x]/E/H”이다. 따라서, 이 명령을 수신한 DM 클라이언트는 URI A를 절대 URI “./Vendor/A1”으로 변환하고 URI B “[x]/E/H”에서 [x]를 제거하고 URI A에 대한 절대 URI 뒤에 붙여 “./Vendor/A1/E/H”로 변환할 수 있다. 그런 다음, DM 클라이언트는 변환된 절대 URI를 이용하여 노드(도 4의 416)를 찾고 노드(도 4의 416)에 대하여 명령을 수행할 수 있다.

가상(Virtual) URI는 절대(Absolute) URI의 문제점을 개선한 것이지만, 가상(Virtual) URI의 경우 URI 충돌(confliction)이 발생할 수 있다. URI 충돌(confliction)이란 가상 URI가 고유한 절대 URI로 변환되지 못하고, 다수의 절대 URI로 해석되는 것을 지칭한다. 가상 URI가 다수의 절대 URI로 해석 가능하면 DM 명령의 대상이 되는 노드가 불명확해져 DM 명령은 실행될 수 없다. 이런 경우, DM 서버는 절대 URI를 이용해야 한다.

예를 들어, 복수의 DM 서버가 하나의 단말을 관리하는 시나리오에서 가상 URI가 유일한 절대 URI로 변경되지 않을 수 있다. 예를 들어, DM 서버 1이 단말에서 카메라 장치를 관리하기 위해, DCMO 인스턴스를 만들어 관리하고 있다고 가정하자. 이때, DM 서버 2가 동일 단말을 대상으로 동일 카메라 장치를 관리하려는 경우, DM 서버 2는 새로운 DCMO 인스턴스를 생성해서 이 새로운 DCMO 인스턴스를 통해 카메라 장치를 관리할 수 있다. 따라서, 단말에는 동일한 기능을 수행하는 서로 다른 두 개의 DCMO 인스턴스가 존재하게 된다. 이 경우, DM 서버 1이 생성한 DCMO 인스턴스와 DM 서버 2가 생성한 DCMO 인스턴스가 동일한 MOID와 동일한 property 이름(<x>/Property에 저장)을 가질 수 있다. 따라서, DM 서버 2가 새로운 DCMO 인스턴스를 생성한 경우, DM 서버 1과 DM 서버 2 모두 가상 URI를 이용할 수 없다. 이 경우 가상 URI로는 두 개의 DCMO 인스턴스를 구분하지 못할 수 있다.

또한, 가상(Virtual) URI의 <URI> 구성요소는 절대 URI를 사용하여 기술되기 때문에, DM 서버는 DM 트리의 전체 구조를 알아야만 한다. DM 서버가 단말마다 모두 다른 DM 트리 구조를 알아야 하는 것은 부하가 될 수 있어 문제가 된다.

무명 노드 밑의 노드에 대한 주소 표현 방식의 문제

MO에서 특정 노드는 무명 노드(un-named node)로 표현될 수 있다. 무명 노드는 플레이스홀더(placeholder)로서 역할하며 무명 노드의 실제 노드 이름은 런타임에서 사용될 때 결정될 수 있다. MO에서 무명 노드의 이름은 “<”와 “>” 및 그 사이에 소문자 캐릭터(lowercase character)를 포함하여 표현될 수 있다. 예를 들어, 무명 노드는 “<x>”로서 표현될 수 있다. 편의상, 무명 노드는 <x> 노드로 지칭될 수 있다.

<x> 노드의 실제 노드 이름이 런타임시 결정되기 때문에, DM 서버는 이를 미리 알 수 없다. 따라서, DM 서버는 <x> 노드 밑의 특정 노드에 DM 명령을 전달하는 경우, DM 서버는 GET 명령을 통해 해당 MO 인스턴스 정보를 먼저 가져온 다음 <x> 노드의 실제 노드 이름을 알아내야 한다. 따라서, DM 서버는 필요한 정보만을 요청할 수 없어 비효율적일 수 있다.

도 6은 <x> 노드에 대한 주소 표현 방식을 예시한다. 도 6에서 제한적이지 않은 예로서 센서 관리를 위한 SensorMO를 중심으로 설명한다. SensorMO는 DM 서버가 센서 값을 읽어오고 설정을 변경할 수 있게 하는 MO이다. 도 6(a)는 규격에서 정의되는 센서 관리 객체(Sensor Management Object, SensorMO)를 나타내고, 도 6(b)는 MO를 이용하여 단말에서 생성되는 SensorMO 인스턴스를 나타낸다. SensorMO 인스턴스는 DM 트리 루트 노드 밑에 위치할 수도 있고, 다른 위치에 위치할 수도 있다.

도 6(a)을 참조하면, SensorMO에서 “SensorMO/<x>/SensorID” 노드(602)는 센서마다 부여되는 고유의 식별자를 가지며, 각각의 센서를 구분하는 데 사용된다. 예를 들어, “SensorMO/<x>/SensorID” 노드(602)의 노드 값은 GPS 센서의 경우 “GPS”, 근접 센서는 “Proximity”, 가속 감지 센서는 “Accelerometer”으로 설정될 수 있다. “SensorMO/<x>/Value” 노드(604)는 센서의 값을 나타내고, DM 서버는 이 노드(604)에 GET 명령을 전달해서 센서의 현재 값을 읽을 수 있다. DM 서버는 “SensorMO/<x>/Setting” 노드(606)에서 센서 설정 값을 읽어올 수 있고, 센서 설정 값을 새로운 값으로 설정할 수 있다.

도 6(b)를 참조하면, 도 6(a)의 SensorMO를 이용하여 DM 트리에서 2개의 SensorMO 인스턴스가 생성되어 있다. 첫번째 SensorMO는 GPS 센서를 위한 MO이며 <x> 노드(610)의 이름은 MO 인스턴스 생성시 1로서 설정될 수 있다. 두번째 SensorMO는 근접 센서를 위한 MO이며 <x> 노드(620)의 이름은 MO 인스턴스 생성시 2로서 설정될 수 있다. DM 서버가 근접 센서 설정을 바꾸려고 하는 경우, 근접 센서 관련 정보들이 “./SensorMO/2” 노드(620)의 서브 트리에 있다는 것을 DM 서버가 안다면, DM 서버는 바로 “./SensorMO/2/Setting” 노드(626)에 노드 값 변경 명령을 전달하여 설정 정보를 바꿀 수 있다. 이 경우 한번의 DM 명령만이 필요할 수 있다.

하지만, <x> 노드의 이름은 런타임에서 사용될 때 결정되기 때문에 DM 서버가 이 정보를 이전에 가져오지 않았다면 <x> 노드의 이름을 알 수 없다. 또한, <x> 노드의 이름을 가져온다 하더라도 <x> 노드의 이름은 단말마다 다르게 설정될 수 있으므로 모든 단말에 대한 <x> 노드의 이름을 DM 서버가 관리하기는 어려울 수 있다. 따라서, DM 서버는 근접 센서 설정 값을 바꾸기 위해 아래와 같은 방법을 사용한다.

- 단계 1: DM 서버는 SensorMO의 MO 루트 노드에 대해 GET 명령을 전송해 SensorMO 인스턴스에 대한 정보를 가져온다.

- 단계 2: DM 서버는 SensorMO 인스턴스 정보를 통해, 근접 센서의 설정 정보를 바꾸기 위해 사용해야 할 주소를 알아낸다. 도 6의 예에서, DM 서버는 근접 센서의 경우 SensorMO에서 <x> 노드에 해당하는 무명 노드(unnamed node)가 “2”라는 것을 알아낸다. 도 6의 예에서, 절대(Absolute) URI를 사용하고 SensorMO가 DM 트리 루트에 위치해 있다고 가정하면, DM 서버는 URI “./SensorMO/2/Setting”를 사용할 수 있다.

- 단계 3: DM 서버는 단계 2에서 알아낸 “./SensorMO/2/Setting” URI에 대해 노드 값을 새로운 값으로 바꾸는 DM 명령을 단말에 전송한다.

따라서, 무명 노드의 경우 DM 서버가 근접 센서 관련 정보가 “./SensorMO/2” 서브 트리 밑에 저장되어 있다는 것을 알지 못할 수 있기 때문에, DM 서버는 “./SensorMO/2/Value”에 GET 명령을 전달할 수가 없다. 따라서, “./SensorMO” 전체 서브 트리에 대해 GET 명령을 전달해야 한다. 따라서, 무명 노드에 대하여 필요한 정보만을 요청할 수 없어 비효율적이다.

복수의 노드에 대한 주소 표현 방식의 문제

기존 DM 프로토콜(예, DM 1.3)에는 복수의 노드를 하나의 URI로 가리키는 방법이 없었다. 이러한 방법의 부재는 <x> 노드와 결합되어 문제가 될 수 있다. 예를 들어, 소프트웨어 관리를 위한 SCOMO의 경우, 단말에 설치되어 있는 소프트웨어 패키지 ID는 “<x>/Inventory/Deployed/<x>/PkgID” 노드에 저장될 수 있다. 하지만, PkgID 노드 앞에 <x> 노드가 있어, 모든 설치된 소프트웨어에 대한 <x> 노드의 실제 이름을 알지 못하면 DM 서버는 각각의 PkgID 노드에 Get 명령을 보낼 수 없다. 따라서, DM 서버가 단말에 설치되어 있는 모든 소프트웨어의 패키지 ID를 가져오기 위해서 DM 서버는 “./scomo/Inventory/Deployed” 노드에 Get 명령을 보내야 한다. 이와 같이, “<x>/Inventory/Deployed"에 Get 명령을 보내면 “Deployed”노드 밑의 모든 서브트리에 포함된 데이터가 DM 서버로 전송되기 때문에, 필요한 데이터보다 많은 데이터를 전송해야 하므로 비효율적이다. 따라서, <x> 노드 밑의 특정 노드 전체를 가리킬 수 있는 주소 표현 방식(addressing scheme)이 필요하다.

이에, 본 발명에서는 상술된 주소 표현 방식들의 문제점을 해결하기 위한 새로운 주소 표현 방식(addressing scheme)을 제안한다. 구체적으로, 본 발명에서는 DM 서버가 단말의 DM 트리의 구조를 알지 않고도 노드를 지정할 수 있는 방법을 제안한다. 보다 구체적으로, 본 발명에서는 MOID와 MIID(MO Instance Identifier)에 기반한 주소 표현 방식(이하, 인스턴스 URI)과, 무명 노드(un-named node)(또는 <x> 노드)의 실제 노드 이름을 알지 않고도 <x> 노드 아래의 노드를 지칭할 수 있는 방법(이하, x-name을 이용한 URI)과, 단일 URI로 다수의 노드를 지칭할 수 있는 방법(이하, 와일드카드를 이용한 URI)을 제안한다. DM 서버는 본 발명에 따른 주소 표현 방식을 이용하여 MO 인스턴스의 특정 노드나 노드들의 집합을 지정할 수 있고 지정된 노드를 대상으로 하는 관리 명령(또는 DM 명령)을 전달할 수 있다.

이하에서 본 발명에 따른 주소 표현 방식은 일정한 규격에 따른 문법(syntax)에 의해 표현될 수 있다. 예를 들어, 일정한 규격은 RFC(Request For Comments) 3986을 포함한다. 아래에서 예시되는 문법(syntax)은 RFC 3986에서와 동일한 문법을 사용하며, “1*”는 * 다음의 표현이 한번 이상 지정될 수 있다는 것을 의미한다. “1*reserved”는 사용이 유보된(reserved) 값이 한번 이상 지정될 수 있다는 것을 의미한다. 사용이 유보된(reserved) 값은 예를 들어 “:”, “/”, “?”, “$”, “(”, “)”등과 같은 구획 문자(delimiting character)와 같이 URI 내의 다른 데이터와 구별되어 사용되는 값을 의미한다. 반면, 사용이 유보되어 있지 않은(unreserved) 값은 특정한 목적을 위해 사용이 유보된(reserved) 값을 제외한 값을 의미한다. 예를 들어, 1*(“/” node-name)는 “/”와 node-name이 지정된 차례로 한번 이상 반복될 수 있다는 것을 의미한다. node-name은 노드의 이름을 나타내고 무명 노드의 경우 노드 이름은 <x>와 같이 나타낼 수 있다.

인스턴스 URI(Instance URI)

인스턴스 URI는 MO 인스턴스 식별자를 이용한 주소 표현 방식이다. 인스턴스 URI에서 MO 인스턴스 식별자는 간략히 MIID(MO Instance Identifier)라고 지칭될 수 있다. MIID는 모든 MO 인스턴스에 할당되며 동일한 MOID를 갖는 MO 인스턴스들 간에 MO 인스턴스를 유일하게 식별하는 식별자로서 사용된다. 따라서, MIID 자체로는 단말 안의 MO 인스턴스를 유일하게 식별할 수 없으며, MOID와 MIID가 하나의 쌍으로 단말 안의 모든 MO 인스턴스를 유일하게 식별할 수 있다. MIID는 다른 단말이나 서버를 고려하여 할당될 필요가 없고 단말 안에서 동일한 MOID를 갖는 MO 인스턴스들 중에서 고유하면 된다. 따라서, 서로 다른 MOID를 갖는 MO 인스턴스 간에는 동일한 MIID가 할당될 수 있다. MIID는 DM 클라이언트가 MO 인스턴스를 생성할 때 DM 클라이언트에 의해 MO 인스턴스에 할당될 수 있다. MIID 할당시 아래의 규칙이 적용될 수 있다.

- MIID는 하나의 단말 안에서 동일한 MOID를 갖는 MO 인스턴스 중에서 각각의 MO 인스턴스를 고유하게 식별한다. MOID와 MIID 쌍은 단말 안에서 각각의 MO 인스턴스를 유일하게 식별한다. MIID는 서로 다른 MOID를 갖는 MO 인스턴스들 간에는 유일하지 않을 수 있다.

- MIID는 MO 인스턴스가 삭제될 때까지 변하지 않는다.

- 삭제된 MO 인스턴스의 MIID는 동일한 MOID를 갖는 다른 MO 인스턴스에 일정 기간 동안 재사용되어서는 안 된다. 만일 삭제된 MO 인스턴스의 MIID가 동일한 MOID를 갖는 다른 MO 인스턴스에 사용될 경우, DM 서버가 의도하지 않게 다른 MO 인스턴스를 지정할 수 있기 때문이다.

MOID와 MIID를 이용한 주소 표현 방식은 인스턴스(Instance) URI라고 지칭될 수 있다. 인스턴스 URI는 ABNF(Augmented Backus-Naur Form)을 이용하여 표현될 수 있다.

도 7은 본 발명에 따른 인스턴스 URI를 표현하는 문법(syntax)을 예시한다. 인스턴스 URI는 도 7의 문법에 따른 표현으로만 제한되는 것은 아니며, 본 발명의 틀 안에서 다른 형태로도 표현될 수 있다.

도 7을 참조하면, 인스턴스(Instance) URI에서 MOID와 MIID는 특정 MO 인스턴스를 유일하게 지정한다. path-from-moroot 컴포넌트는 지정된 MO 인스턴스 안에서 특정 노드의 주소를 지정한다. path-from-moroot 컴포넌트는 “/” 또는 1*(“/” node-name)의 형태를 가질 수 있다. path-from-moroot 컴포넌트가 “/”인 경우 MO 인스턴스 루트 노드(MO instance root node)를 지정한다. path-from-moroot 컴포넌트가 1*(“/” node-name)인 경우, path-from-moroot 컴포넌트는 MOID와 MIID가 지정하는 MO 인스턴스 안에서 MO 인스턴스 루트 노드를 제외한 다른 노드를 지정하며, MO 인스턴스 루트 노드의 자식 노드에서부터 시작하는 상대적인 경로(relative path)를 나타낸다. path-from-moroot 컴포넌트는 path-from-miroot로 지칭될 수 있다.

도 8은 MO 인스턴스를 예시한다. 도 8의 예에서, MO 인스턴스는 MOID “urn:oma:mo:oma-ex:1.0”를 가지고, MIID는 “1234”이며, MO 인스턴스 루트 노드는 “MOroot” 노드(802)라고 가정한다. 도 8의 각 노드는 인스턴스 URI를 이용하여 다음과 같이 표현될 수 있다. 본 발명에 따른 인스턴스 URI는 도 8의 예로만 제한되어 적용되는 것은 아니다.

- 인스턴스 URI “urn:oma:mo:oma-ex:1.0/1234/”는 path-from-moroot 컴포넌트가 “/”인 경우이다. 따라서, 인스턴스 URI “urn:oma:mo:oma-ex:1.0/1234/”는 MO 인스턴스의 루트 노드(802)를 지정한다.

- 인스턴스 URI “urn:oma:mo:oma-ex:1.0/1234/A/C”는 path-from-moroot 컴포넌트가 “/A/C”인 경우이다. 따라서, 인스턴스 URI “urn:oma:mo:oma-ex:1.0/1234/A/C”는 MO 인스턴스의 루트 노드(802)로부터 “/A/C”의 경로를 가지는 노드(808)를 지정한다. 도 8의 예에서“MOroot/A/C”의 주소를 가지는 노드를 지정한다.

- 인스턴스 URI “urn:oma:mo:oma-ex:1.0/1234/A/C/H”는 도 8의 MO 인스턴스에 존재하는 않는 새로운 노드를 지정한다. DM 서버는 인스턴스 URI를 사용하여 새로운 노드를 생성할 수 있다.

도 9는 본 발명에 따른 인스턴스 URI를 해석(resolve)하는 방법의 순서도를 예시한다. 본 발명에 따르면, DM 클라이언트는 인스턴스 URI를 절대(Absolute) URI와 같은 다른 형태의 URI로 변환할 필요 없이 인스턴스 URI가 지정하는 노드를 알 수 있다.

도 9를 참조하면, 902 단계에서, DM 클라이언트는 인스턴스 URI를 해석(resolve)한다. 인스턴스 URI는 DM 명령과 함께 DM 서버로부터 수신될 수 있으며 또는 DM 클라이언트 자체적으로 생성된 DM 명령에 대해서도 인스턴스 URI를 해석(resolve)할 수 있다.

904 단계에서, 인스턴스 URI로부터 MOID 컴포넌트와 MIID 컴포넌트를 가져온다(retrieve). 인스턴스 URI는 일정한 문법에 맞추어 작성되기 때문에, DM 클라이언트는 쉽게 MOID 컴포넌트와 MIID 컴포넌트를 가져올(retrieve) 수 있다.

906 단계에서, DM 클라이언트는 단말에 존재하는 MO 인스턴스를 대상으로 904 단계에서 가져온(retrieve) MOID와 MIID를 포함하는 MO 인스턴스를 찾는다. MOID와 MIID 쌍 (MOID, MIID)은 하나의 단말 안에서 고유하므로, 906 단계에서 찾아진 MO 인스턴스는 유일하며 복수일 수 없다. MO 인스턴스를 찾은 경우, 908 단계로 진행하고, 찾지 못하는 경우 912 단계로 진행한다.

906 단계에서 MO 인스턴스를 찾은 경우, 908 단계에서 path-from-moroot 컴포넌트를 해석(resolve)한다. path-from-moroot 컴포넌트가 유효한지 확인한다. 예를 들어, path-from-moroot 컴포넌트가 정해진 문법에 맞는지 확인한다. path-from-moroot 컴포넌트가 유효하다면 910 단계로 진행하고, 유효하지 않은 경우 912 단계로 진행한다.

910 단계에서, DM 클라이언트는 인스턴스 URI가 지정하는 노드를 찾는 데 성공한다. DM 클라이언트는 인스턴스 URI가 지정하는 노드를 대상으로 하는 DM 명령이 있다면 그 노드에 대해 DM 명령을 실행할 수 있다. 이때, DM 명령을 보내온 DM 서버가 해당 권한을 가지고 있는지는 별도의 문제이다.

912 단계에서, 인스턴스 URI가 유효하지 않거나 올바르지 못하므로, DM 클라이언트는 인스턴스 URI가 지정하는 노드를 찾는 데 실패한다. 만일 DM 서버가 인스턴스 URI를 보냈다면, DM 클라이언트는 에러 코드를 DM 서버로 전송한다.

도 10은 본 발명에 따라 DM 서버가 MIID를 가져오는 방법의 순서도를 예시한다. 앞서 설명한 바와 같이, MIID는 DM 클라이언트가 MO 인스턴스 생성 시 할당될 수 있다. DM 서버는 인스턴스 URI를 사용하기 위해 MO 인스턴스에 할당된 MIID를 검색할 수 있다.

1002 단계에서, DM 클라이언트는 MOID에 해당하는 MO 인스턴스 정보에 대한 요청을 DM 서버로부터 수신한다. 이 요청은 GET URI 형태로 표현될 수 있으며, GET은 DM 명령을 나타내고, URI는 GET 명령의 대상인 MOID를 갖는 MO 인스턴스를 나타낸다.

1004 단계에서, DM 클라이언트는 단말의 DM 트리 안에 있는 모든 MO 인스턴스를 대상으로 MOID를 갖는 MO 인스턴스를 찾는다. 이 경우, DM 클라이언트는 MOID를 갖는 MO 인스턴스 중 DM 서버가 읽을 수 있는 접근 권한을 가지고 있는 MO 인스턴스를 찾을 수 있다.

1006 단계에서, DM 클라이언트는 1002 단계에서 수신된 URI가 query 컴포넌트에 레벨 필드(level field)를 가지고 있는지 확인한다. URI가 query 컴포넌트에 레벨 필드(level field)를 포함하면 1010 단계로 진행하고, 포함하고 있지 않으면 1008 단계로 진행한다.

1008 단계에서, DM 클라이언트는 1004 단계에서 찾아진 MO 인스턴스 정보를 DM 서버에게 전송한다. MO 인스턴스 정보는 MIID를 포함한다.

1010 단계에서, 1002 단계에서 DM 서버가 전송한 URI에 레벨 필드를 포함하는 경우, 레벨 필드를 처리한다. 레벨 필드에 대해서는 아래에서 자세히 설명한다. 레벨 필드를 처리한 다음, DM 클라이언트는 1008 단계로 진행할 수 있다.

MOID URI

MOID URI는 인스턴스 URI를 확장한 것이다. 앞서 설명한 바와 같이, MOID는 각각의 MO에 대해 고유하게 할당되는 식별자이며, DM 트리에서 MO 타입을 구분하는 데 사용될 수 있다. 하지만, 동일한 MO에 대해 복수의 MO 인스턴스가 생성될 수 있으므로 동일한 MOID를 가지는 MO 인스턴스가 복수로 존재할 수 있다. 이 경우, DM 서버나 DM 클라이언트는 MO 인스턴스를 유일하게 구분할 수 없다. 하지만, 만일 하나의 MO 타입에 대해 MO 인스턴스가 하나만 존재할 경우(예, 단말에서 FUMO 인스턴스가 하나만 존재하는 경우), MOID는 단말 안에서 MO 인스턴스를 고유하게 지정할 수 있다. 단말에서 MO 인스턴스가 하나만 존재할 때 MOID만을 이용한 주소 표현 방식을 MOID URI라 지칭한다. MOID URI는 인스턴스 URI의 문법을 확장하여 표현될 수 있다. 본 발명에서는 인스턴스 URI와 MOID URI는 클라이언트(Client) URI(또는 ClientURI)라고 통칭될 수 있다.

도 11은 본 발명에 따른 인스턴스 URI와 MOID URI를 표현하는 문법(syntax)을 예시한다. 도 11은 인스턴스 URI의 문법을 확장한 것으로서 인스턴스 URI와 MOID URI 모두에 적용될 수 있다. 인스턴스 URI와 MOID URI는 도 11의 문법에 따른 표현으로만 제한되는 것은 아니며, 본 발명의 틀 안에서 다른 형태로도 표현될 수 있다. 도 11에서 인스턴스 URI와 MOID URI를 통틀어 클라이언트 URI라고 지칭될 수 있다.

도 11을 참조하면, mo-inst 컴포넌트에 대해 MIID가 사용되면 인스턴스 URI와 동일할 수 있다. MOID URI는 하나의 단말 안에서 동일한 MOID를 가지는 MO 인스턴스가 하나만 존재하는 경우 사용하므로 MO 인스턴스를 구분하기 위한 식별자가 필요 없을 수 있다. 따라서, MOID URI를 위한 문법(syntax)에서는 mo-inst 컴포넌트가 빈 문자열(empty string) “”로 지정될 수 있다. 따라서, MOID URI를 이용하는 경우, URI에서 MOID 다음에 “/”가 따라오고 path-from-moroot 컴포넌트가 따를 수 있다. 도 11에서도 도 7에서와 마찬가지로, path-from-moroot 컴포넌트는 “/” 또는 1*(“/” node-name)의 형태를 가질 수 있다. 따라서, MOID URI의 경우, MOID 다음에 MIID 없이 “//”가 따를 수 있다. 반면, 인스턴스 URI의 경우 MOID 다음에 MIID가 따라오므로, MOID URI와 인스턴스 URI는 쉽게 구분될 수 있다. 도 11의 URI 문법에서 mo-inst 컴포넌트에 MIID가 나오면 인스턴스 URI이고 “”가 나오면 MOID URI일 수 있다. MOID URI는 단말 안에 동일한 MOID를 가지는 MO 인스턴스가 하나만 존재할 경우 MOID 컴포넌트만으로 MO 인스턴스를 지정할 수 있다.

도 11에서, path-from-moroot 컴포넌트는 인스턴스 URI 경우와 동일하게 MO 인스턴스 안에서 MO 인스턴스 루트 노드로부터의 경로를 나타낸다. 따라서, path-from-moroot 컴포넌트는 MO 인스턴스 안에서 특정 노드를 지정한다.

도 12는 본 발명에 따라 DM 클라이언트에서 MOID URI를 해석(resolve)하는 방법의 순서도를 예시한다. DM 클라이언트는 MOID URI를 절대(Absolute) URI와 같은 다른 형태의 URI로 변경할 필요 없이 MOID URI가 지정하는 노드를 알 수 있다.

1202 단계에서, DM 클라이언트는 MOID URI를 해석하여 그 MOID URI가 지정하는 노드를 찾는 과정의 시작이다. MOID URI는 DM 서버가 DM 명령과 함께 보낸 것일 수 있으며, 혹은 DM 클라이언트 자체적으로 생성된 DM 명령을 처리하기 위한 것일 수 있다.

1204 단계에서, DM 클라이언트는 URI로부터 MOID 컴포넌트를 가져온다(retrieve). MOID URI는 정해진 문법에 맞추어 기술되기 때문에, DM 클라이언트는 MOID 컴포넌트를 쉽게 찾을 수 있다.

1206 단계에서, DM 클라이언트는 단말 안의 모든 MO 인스턴스를 대상으로 1204 단계에서 가져온(retrieve) MOID에 해당하는 MO 인스턴스를 찾는다. 이 때, MO 인스턴스를 찾는 범위는 단말 안의 모든 MO 인스턴스를 대상으로 할 수도 있고, 일부 MO 인스턴스로 한정하여 검색 범위를 좁힐 수도 있다.

1208 단계에서, DM 클라이언트는 1206 단계에서 찾은 MO 인스턴스를 대상으로 MOID URI에 nv 필드(field)가 있다면 이 nv field를 처리한다. MO 인스턴스 중에서 nv 필드를 만족하는 MO 인스턴스만이 1210 단계로 전달된다. nv 필드에 대해서는 아래에서 자세히 설명한다.

1210 단계에서, 1208 단계에서 찾은 MO 인스턴스의 개수가 하나인지 확인한다. 만약 두 개 이상이 찾아졌거나 하나도 찾지 못한 경우, 1216 단계로 진행한다. 만일 하나의 MO 인스턴스만 찾은 경우, 1212 단계로 진행한다.

1212 단계에서, path-from-moroot 컴포넌트를 해석(resolve)한다. path-from-moroot 컴포넌트가 정해진 문법에 따라 유효한지 확인한다. path-from-moroot컴포넌트가 유효하다면 1214 단계로 진행하고, 유효하지 않으면 1216 단계로 진행한다.

1214 단계에서, MOID URI가 지칭하는 노드를 성공적으로 찾은 경우이다. DM 클라이언트는 해당 노드를 대상으로 하는 DM 명령이 있다면 이를 실행할 수 있다. 이때, DM 서버가 DM 명령을 보냈다면, DM 서버가 해당 권한을 가지고 있는지는 별도의 문제이다.

1216 단계에서, MOID URI가 잘못된 경우이다. DM 서버가 MOID URI를 보낸 경우, DM 클라이언트는 에러 코드를 DM 서버로 전송한다. 이때, DM 클라이언트는 상황에 따라 추가적인 정보를 DM 서버에게 전송할 수 있다.

도 12에 예시된 MOID URI 해석 방법은 본 발명의 사상 안에서 변경될 수 있다. 예를 들어, 1206 단계와 1208 단계는 순서가 서로 바뀔 수 있다.

x-name을 이용한 URI

여러 MO는 MO 루트 노드 밑에 <x> 노드(또는 무명 노드)를 가질 수 있다. 앞서 설명한 바와 같이, <x> 노드(또는 무명 노드)는 런타임 때 실제 이름이 결정된다. 예를 들어, <x> 노드는 MO를 정의할 때 복수의 인테리어 노드(interior node) 중에서 일부 인테리어 노드의 이름을 미리 정의하지 않고 그 서브트리의 구조를 정의하는데 사용될 수 있다. 따라서, <x> 노드는 런타임에서 노드 이름을 달리하여 여러 개가 생성될 수 있다.

앞서 설명된 바와 같이, <x> 노드의 실제 노드 이름이 런타임시 결정되기 때문에, DM 서버는 이를 미리 알 수 없다. 따라서, DM 서버는 GET 명령을 통해 해당 MO 인스턴스 정보를 먼저 가져온 다음 <x> 노드의 실제 노드 이름을 알아내야 한다. 따라서, DM 서버는 필요한 정보만을 요청할 수 없어 비효율적일 수 있다. 이러한 문제를 해결하기 위해, 본 발명에서는 URI 안에서 <x> 노드를 사용하여 노드를 지정하는 방법을 제안한다.

도 13은 본 발명에 따른 x-name을 이용한 URI를 표현하는 문법(syntax)을 예시한다. 도 13은 클라이언트 URI(또는 ClientURI)의 문법을 확장한 것으로서 인스턴스 URI와 MOID URI의 적용예를 포함한다. 클라이언트 URI(또는 ClientURI)는 인스턴스 URI와 MOID URI 이외에도 본 발명에 따른 <x> 노드를 이용한 URI를 통칭할 수 있다. 클라이언트 URI(또는 ClientURI)는 도 13의 문법에 따른 표현으로만 제한되는 것은 아니며, 본 발명의 틀 안에서 다른 형태로도 변경될 수 있다.

도 13을 참조하면, mo-inst 컴포넌트는 MIID, 빈 문자열 “”, x-name 컴포넌트 중 하나를 포함할 수 있다. mo-inst 컴포넌트에 대해 MIID가 사용되면 인스턴스 URI와 동일할 수 있다. mo-inst 컴포넌트에 대해 빈 문자열 “”가 사용되면 MOID URI와 동일할 수 있다. 이외에도, 클라이언트 URI(또는 ClientURI)에서 mo-inst 컴포넌트에 대해 x-name 컴포넌트가 사용될 수 있다. x-name 컴포넌트는 3개의 문자(character)로 구성될 수 있다. 예를 들어, URI를 정의하는 RFC 3986 규격에 따라, x-name 컴포넌트는 구획 문자(delimiting character)들 “(”, “)”, ALPHA 컴포넌트로 구성될 수 있다. ALPHA 컴포넌트는 하나의 알파벳 문자(alphabet letter)를 포함하며 하나의 클라이언트 URI 내의 x-name 컴포넌트들 중에서 고유한 값으로 지정될 수 있다. 따라서, 하나의 URI 내에 복수의 x-name 컴포넌트를 포함하더라도 ALPHA 컴포넌트에 의해 고유하게 구별될 수 있다. 예를 들어, 하나의 URI 내에 2개의 무명 노드 <x>와 <y>를 지정하기 위해 x-name 컴포넌트를 포함하는 경우, x-name 컴포넌트는 각각 “(x)”와 “(y)”로 지정될 수 있다. RFC 3986 규격에 따르면, x-name 컴포넌트에 대해 “<”나 “>”를 사용하지 않도록 권유하지만 다른 예에서는 “(”와 “)” 대신에 “<”와 “>”가 사용될 수 있다.

도 13에서도 도 7 또는 도 11에서와 마찬가지로, path-from-moroot 컴포넌트는 “/” 또는 1*(“/” node-name)의 형태를 가질 수 있다. 하지만 도 7 또는 도 11의 예와 달리, node-name 컴포넌트는 일반적인 캐릭터들로 구성되는 real-name 컴포넌트 이외에 x-name 컴포넌트를 가질 수 있다. 따라서, x-name 컴포넌트는 MO 인스턴스를 지정하기 위해 사용될 수 있을 뿐만 아니라 MO 인스턴스 안의 특정 무명 노드를 지정하기 위해서도 사용될 수 있다.

x-name 컴포넌트는 다음과 같은 성질을 가질 수 있다.

- 유명 노드(named node)에 대해서는 <x> 노드가 사용될 수 없다. 유명 노드는 규격에서 MO에 대한 정의를 통해 노드 이름이 미리 정해져 있는 노드를 지칭한다. 유명 노드(named node)는 실제 노드 이름을 사용하여 지정되어야 하고, 무명 노드(un-named node)는 실제 이름 또는 <x> 노드 중 하나를 사용하여 지정될 수 있다.

- <x> 노드를 사용하는 경우 URI는 nv 필드를 포함해야만 한다. nv 필드에 대해서는 아래에서 자세히 설명한다.

URI에서 <x> 노드를 지정하기 위해 x-name을 사용하는 경우 URI가 지정하는 고유의 노드를 알 수 없으므로, URI는 추가 정보를 포함할 수 있다. 예를 들어, URI는 쿼리(Query) 컴포넌트를 포함할 수 있다. 쿼리(Query) 컴포넌트는 <x> 노드를 이용하여 URI를 표현하는 경우 x-name 컴포넌트에 대한 추가 정보를 제공할 수 있다. 예를 들어, URI 안에서 쿼리 컴포넌트는 구획 문자 “?”에 의해 path-from-moroot 컴포넌트와 구별될 수 있다. 따라서, 쿼리 컴포넌트는 구획 문자 “?” 다음부터 시작하며 URI의 끝에서 종료된다. 구획 문자 “?”는 쿼리 컴포넌트에 포함되지 않는다. 쿼리 컴포넌트는 복수의 “field=value” 형태의 시퀀스로서 구성될 수 있으며, 복수의 “field=value”는 구획 문자 “&”에 의해 구분될 수 있다.

표 2는 쿼리 컴포넌트에 포함될 수 있는 필드들을 예시한다. 표 2에 예시된 바와 같이, 쿼리 컴포넌트는 level 필드, node-value 필드, cache validator 필드를 포함할 수 있다. 표 2는 오로지 예시일 뿐이며, 쿼리 컴포넌트는 이들 중 일부 필드만을 포함하거나 추가적인 필드를 포함할 수 있다.

표 2에서 level 필드는 “lv=<n>”의 형태를 가지며 n은 양의 정수를 나타낸다. URI가 level 필드를 포함하는 경우 URI는 n 서브레벨의 자식 노드들만을 대상으로 할 수 있다. URI가 level 필드를 포함하지 않는 경우, URI는 모든 자식 노드들을 대상으로 할 수 있다. 표 2에서 cache validator 필드는 “cv=<val>”의 형태를 가지며, URI가 나타내는 노드에 대하여 신규성 정보(freshness information)를 제공한다.

또한 표 2에 예시된 바와 같이, 쿼리 컴포넌트는 RFC 3986 규격에 따라 node-value 필드를 포함할 수 있다. node-value 필드는 간략히 nv 필드라고 지칭될 수 있다. nv 필드는 “nv=<path>:<val>”의 형태를 가질 수 있다. 여기서 <path>는 URI에 사용된 특정 x-name 컴포넌트에서부터 시작하여 상대적인 주소를 나타낸다. <path>는 "(x)"와 같이 "(" ALPHA ")"의 형태로 시작될 수 있다. 여기서 ALPHA 컴포넌트는 RFC 3986에 정의된 것처럼 하나의 알파벳 문자를 지칭하며, ALPHA 컴포넌트는 클라이언트 URI에서 매칭되는 x-name 컴포넌트를 지칭하는 데 사용된다. <path>는 이렇게 매칭된 x-name 컴포넌트에서부터 시작하여 리프 노드까지의 상대 주소를 나타낸다. 하나의 x-name 컴포넌트에 대해 적어도 하나의 nv 필드가 사용될 수 있다. <val>는 <path>에 의해 지정되는 노드의 노드 값을 나타낸다. 특정 MO 인스턴스에 대해 nv 필드는 "만족되었다(satisfied)"라고 표현되는데, 이는 해당 MO 인스턴스에서 nv 필드의 <path>에 의해 지칭되는 리프 노드가 <val>에 해당하는 값을 가지는 것을 의미한다.

도 13의 예에서, x-name 컴포넌트는 3개의 문자로 “(”, “)”, ALPHA 컴포넌트에 의해 표현될 수 있다. x-name 컴포넌트 안의 ALPAH 컴포넌트는 nv 필드와 매칭되도록 사용될 수 있다. 예를 들어, mo-inst 컴포넌트 또는 path-from-moroot 컴포넌트가 x-name 컴포넌트 “(x)”를 포함하는 경우 nv 필드는“(x)”를 포함하는 <path>를 가질 수 있다. 이 경우 nv 필드는 x-name 컴포넌트와 매칭된다고 볼 수 있다. 일 예로, nv 필드는 “nv=(x)/...:...”와 같은 형태를 가질 수 있다. 만일 복수의 nv 필드가 포함되는 경우, 모든 nv 필드가 x-name 컴포넌트와 매칭되어야 한다. 따라서, DM 클라이언트는 x-name 컴포넌트의 ALPHA와 동일한 ALPHA를 갖는 nv 필드를 찾음으로써 둘 간의 매칭을 할 수 있다.

도 14는 본 발명에 따라 x-name을 이용한 URI를 해석(resolve)하는 방법의 순서도를 예시한다. <x> 노드를 나타내는 x-name 컴포넌트는 mo-inst 컴포넌트와 path-from-moroot 컴포넌트에 적용될 수 있다. 따라서, 도 14의 방법은 도 9의 908 단계에서 인스턴스 URI의 path-from-moroot 컴포넌트를 해석하는 데에도 사용될 수 있다. 또한, 도 14의 방법은 도 12의 1212 단계에서 MOID URI의 path-from-moroot 컴포넌트를 해석하는 데에도 사용될 수 있다.

1402 단계에서, DM 클라이언트는 URI를 해석(resolve)한다.

1404 단계에서, DM 클라이언트는 URI가 정해진 문법(syntax)에 맞는지 확인한다. 예를 들어, DM 클라이언트는 URI가 도 13에 예시된 문법에 맞는지 확인할 수 있다. 만약 정해진 문법에 맞으면 1406 단계로 진행하고, 맞지 않으면 1416 단계로 진행한다.

1406 단계에서, DM 클라이언트는 URI에서 실제 이름을 찾지 못한 <x> 노드를 찾는다. <x> 노드를 지정하는 x-name은 “(“로 시작되고 “)”로 끝나기 때문에 그러한 x-name 중에서 아직 해석되지 않은 x-name을 찾을 수 있다. 만약 해석되지 않은(unresolved) <x> 노드가 없다면 1414 단계로 진행하고, 해석되지 않은(unresolved) <x> 노드가 있다면 1408 단계로 진행한다.

1408 단계에서, DM 클라이언트는 <x> 노드의 실제 이름을 찾기 위해 필요한 nv 필드를 찾는다. URI에 포함된 <x> 노드의 ALPHA 컴포넌트와 동일한 ALPHA 값을 포함하는 nv 필드를 쿼리 컴포넌트에서 찾으면 된다. 만약 <x> 노드에 대응되는 nv 필드를 찾으면 1410 단계로 진행하고, 찾지 못하면 1416 단계로 진행한다.

1410 단계에서, nv 필드를 이용하여 <x> 노드의 실제 이름을 찾는다. nv 필드는 <x> 노드를 기준으로 특정 노드 경로(<path>로 지칭)와 노드 값(<val>로 지칭)을 제공한다. 따라서 nv 필드가 지정하는 노드를 찾고 그 노드에 저장된 노드 값이 nv 필드의 <val>로 지정된 노드 값과 일치하는지 확인한다. 이를 만족하는 <x> 노드의 실제 이름은 하나만 존재해야 하며, 없거나 다수가 존재하면 URI와 nv 필드는 유효하지 않다. <x> 노드의 이름이 유일하게 결정되면 1412 단계로 진행하고, 아니면 1416 단계로 진행한다.

1412 단계에서, 1410 단계에서 <x> 노드에 해당하는 실제 노드 이름이 유일하게 찾아진 경우이므로, <x> 노드의 이름이 성공적으로 해석되었다. 1406 단계로 다시 진행하여, 아직 이름이 해석되지 않은(unresolved) <x> 노드를 찾는다.

1414 단계에서, URI에 포함된 모든 <x> 노드의 이름이 성공적으로 해석되었다.

1416 단계에서, URI가 올바르지 못한 경우로, 문법에 맞지 않거나 <x> 노드의 실제 이름을 알아내지 못한 경우이다.

와일드카드를 이용한 URI

와일드카드를 이용한 URI에서는 하나의 URI로 복수의 노드를 지정하기 위해 “*”를 사용한다. “*”는 무명 노드(un-named node)(또는 <x> 노드)에 대해서만 사용될 수 있고 유명 노드(named node)에 대해서는 항상 노드의 실제 이름(real-name)이 사용되어야 한다. 와일드카드를 지정하는 캐릭터는 “*”로만 제한되는 것은 아니며 다른 캐릭터가 사용될 수 있다.

도 15는 본 발명에 따라 URI를 표현하는 문법(syntax)을 예시한다. 도 15는 인스턴스 URI, MOID URI, x-name을 이용한 URI에 따른 클라이언트 URI(또는 ClientURI)의 문법을 확장한 것으로서 와일드카드를 이용한 주소 표현 방식을 포함한다. 클라이언트 URI(또는 ClientURI)는 인스턴스 URI, MOID URI, x-name을 이용한 URI, 와일드카드를 이용한 URI를 통칭할 수 있다. 클라이언트 URI(또는 ClientURI)는 도 15의 문법에 따른 표현으로만 제한되는 것은 아니며, 본 발명의 틀 안에서 다른 형태로도 표현될 수 있다.

도 15를 참조하면, mo-inst 컴포넌트는 MIID, x-name, 빈 문자열 “”, 와일드카드 문자(예, “*”) 중 하나가 될 수 있다. 또한, node-name 컴포넌트는 실제 이름(real name)과 x-name, 와일드카드 문자(예, “*”) 중 하나가 될 수 있다. 하지만, x-name과 와일드카드 문자(예, “*”)는 무명 노드(또는 <x> 노드)에 대해서만 사용될 수 있고 유명 노드(named-node)에 대해서는 사용될 수 없다. 예를 들어, 유명 노드(named node)는 실제 노드 이름을 사용하여 지정되어야 하고, 무명 노드(un-named node)는 실제 이름, x-name, 와일드카드 문자(예, “*”) 중 하나를 사용하여 지정될 수 있다.

본 발명에서 제안된 URI를 이용한 주소 표현 방법과 URI 해석(resolve) 방법을 정리하면 다음과 같다.

본 발명에 따른 URI 주소 표현 방법

도 15를 다시 참조하면, 도 15는 본 발명에 따른 URI 주소 표현 방식(addressing scheme)을 예시한다. 앞서 언급된 바와 같이, 본 발명에 따른 URI는 인스턴스 URI, MOID URI, x-name을 이용한 URI, 와일드카드를 이용한 URI를 포함하며, 클라이언트 URI(또는 ClientURI)로서 통칭될 수 있다. 도 15에 예시된 주소 표현 방식은 RFC 3986 규격과 호환 가능한(compatible) URI 포맷이다.

도 15의 예에서, MOID 컴포넌트와 mo-inst 컴포넌트는 MO 인스턴스를 가리키고, path-from-moroot 컴포넌트는 MO 인스턴스 루트 노드로부터의 상대적 경로를 기술함으로써 MO 인스턴스 안에서의 특정 노드를 가리킨다. MOID 컴포넌트는 URI(예, ClientURI)가 가리키는 노드를 포함하는 MO 인스턴스의 MOID를 나타낸다. 따라서, MOID 컴포넌트는 URI가 가리키는 노드를 포함하는 MO 인스턴스의 타입을 나타낸다. mo-inst 컴포넌트는 ABNF 포맷을 따라 다음의 컴포넌트들 중 하나가 될 수 있다.

- MIID: URI(예, ClientURI)가 대상으로 하는 노드를 포함하는 MO 인스턴스의 식별자(MIID, MO Instance ID)를 나타낸다. MIID는 단말 안에서 동일한 MOID를 가지는 MO 인스턴스들 간에 고유한 값이어야 한다. MOID와 MIID 쌍은 단말 안에서 MO 인스턴스를 고유하게 식별할 수 있다.

- x-name: x-name 컴포넌트는 미지수처럼 실제 노드 이름이 URI에서 지정되지 않은 노드이며, 대응되는 nv 필드를 이용하여 실제 노드 이름을 알 수 있다. 따라서, URI에 사용된 x-name 컴포넌트에 대응되는 nv 필드가 동일한 URI 안에 제공되어야 한다. 이 컴포넌트는 “(x)”, “(y)”와 같이 3개의 캐릭터(character)“(”, ALPHA, “)”로서 표현된다. x-name의 ALPHA는 하나의 URI 안에서 모든 x-name 컴포넌트들 간에 고유하게 할당되어야 한다. 하지만, ALPHA는 서로 다른 URI 간에는 고유하게 할당되지 않을 수 있다. 특정 x-name 컴포넌트와 대응되는 nv 필드는 ALPHA 컴포넌트를 기준으로 찾을 수가 있다. x-name의 ALPHA 컴포넌트와 nv 필드의 ALPHA 컴포넌트가 동일한 값을 가지고 있으면 된다. 이 경우 x-name의 ALPHA 컴포넌트와 nv 필드의 ALPHA 컴포넌트는 매칭되는 것이다.

- 빈 문자열(empty string)(예, “”): mo-inst 컴포넌트는 빈 문자열 (empty string)이 될 수 있다. 빈 문자열(empty string)은 동일한 MOID를 갖는 MO 인스턴스가 단말에 하나뿐일 때 mo-inst 컴포넌트에 사용될 수 있다. 따라서, 특정 MOID를 가지고 있는 MO 인스턴스가 하나밖에 없는 경우, MIID 없이 MOID 만으로 특정 MO 인스턴스를 지정할 수 있다.

- 와일드카드(wildcard)(예, “*”): mo-inst 컴포넌트에 와일드카드가 들어가면, URI에서 명시된 MOID를 갖는 모든 MO 인스턴스를 지정한다.

도 15의 예에서, path-from-moroot 컴포넌트는 MO 인스턴스 루트 노드를 지정하는 경우 “/”일 수 있다. 혹은, MO 인스턴스 안에서 루트 노드가 아닌 특정 노드를 지정하는 경우 path-from-moroot 컴포넌트는 MO 인스턴스 루트 노드의 자식 노드로부터 시작하여 적어도 하나의 node-name 컴포넌트의 시퀀스로 구성될 수 있다. 이 경우, path-from-moroot 컴포넌트는 MO 인스턴스 루트 노드의 자식 노드로부터 특정 노드까지의 경로를 나타낸다. 적어도 하나의 node-name 컴포넌트의 시퀀스로서 구성되는 경우, node-name 컴포넌트는 예를 들어 구획문자 “/”로서 구분될 수 있다. 각 node-name 컴포넌트는 다음 컴포넌트들 중 하나로서 표현될 수 있다.

- real-name 컴포넌트: 이 컴포넌트는 실제 노드 이름을 나타낸다.

- x-name 컴포넌트: 이 컴포넌트는 무명 노드(un-named node)(또는 <x> 노드)와 같이 실제 노드 이름을 알 수 없는 경우 사용될 수 있다. x-name 컴포넌트는 미지수처럼 실제 노드 이름이 URI에서 지정되지 않은 노드이며, 대응되는 nv 필드를 이용하여 실제 노드 이름을 알 수 있다. 따라서, URI에 사용된 x-name 컴포넌트에 대응되는 nv 필드가 동일한 URI 안에 제공되어야 한다. 이 컴포넌트는 “(x)”, “(y)”와 같이 3개의 캐릭터(character) “(”, ALPHA, “)”로서 표현된다. x-name의 ALPHA는 알파벳 문자(alphabet letter)로서 하나의 URI 안에서 모든 x-name 컴포넌트들 간에 고유하게 할당되어야 한다. 하지만, ALPHA는 서로 다른 URI 간에는 고유하게 할당되지 않을 수 있다. 특정 x-name 컴포넌트와 대응되는 nv 필드는 ALPHA 컴포넌트를 기준으로 찾을 수가 있다. x-name의 ALPHA 컴포넌트와 nv 필드의 ALPHA 컴포넌트가 동일한 값을 가지고 있으면 된다.

- 와일드카드(wildcard) 문자(예, “*”): path-from-moroot 컴포넌트에 와일드카드 문자가 들어가면, 와일드카드가 명시된 위치에서 모든 노드를 지정한다.

유명 노드(Named node)는 MO의 정의에서 이름이 정해져 있는 노드를 지칭하며, 무명 노드(un-named node)는 MO의 정의에서 “<x>”와 같이 표현되어 이름이 정의되지 않고 런타임에서 노드가 생성될 때 이름이 결정되는 노드를 지칭한다. 유명 노드는 반드시 real-name 컴포넌트를 이용해서 지정되어야 하지만, 무명 노드는 real-name 컴포넌트, x-name 컴포넌트, wildcard 중 하나를 이용하여 지정될 수 있다. MO의 정의에서 무명 노드는 “<x>”와 같이 “<”와 “>”를 사용하여 표현되지만, 본 발명에 따른 URI에서는 RFC 3986 규격과 호환 가능하도록 “(”와 “)”를 사용하여 표현된다.

도 15의 예에서, query 컴포넌트는 표 2와 관련하여 설명된 바와 같이 URI에 대한 추가적인 정보를 전달하는 역할을 한다. query 컴포넌트는 “?” 다음부터 시작하여 URI의 마지막에서 끝난다. "?"는 query 컴포넌트에 포함될 수도 있고 query 컴포넌트에 포함되지 않을 수도 있다. query 컴포넌트는 “field=value”의 시퀀스로 구성되며 각 “field=value”는 “&”에 의해 구분될 수 있다.

표 2를 참조하여 설명된 바와 같이, query 컴포넌트는 nv 필드를 포함할 수 있다. nv 필드는 “nv=<path>:<val>”의 형태를 가질 수 있다. <path>는 “(”, ALPHA, “)”로 시작하며, <path>의 ALPHA 컴포넌트는 x-name 컴포넌트의 ALPHA 컴포넌트와 같이 캐릭터로서 표현된다. ALPHA 컴포넌트는 x-name 컴포넌트와 nv 필드 양쪽에 모두 사용되며 둘간의 매칭 관계를 나타내는 데 사용된다. 즉, x-name의 ALPHA 컴포넌트 값과 nv 필드의 ALPHA 컴포넌트 값이 동일하면 매칭된다. nv 필드의 <path>는 대응되는 x-name 컴포넌트로부터 시작하여 특정 리프 노드(leaf node)를 지정하는 상대적 경로를 나타낼 수 있다. 하나의 x-name 컴포넌트에 대응되는 nv 필드가 복수 존재할 수 있으므로 동일한 ALPHA 컴포넌트 값을 갖는 복수의 nv 필드가 하나의 URI에 사용될 수 있다. <val>는 <path>가 가리키는 리프 노드(leaf node)의 노드 값(node value)을 지정한다. 특정 MO 인스턴스에 대해 <path>가 가리키는 리프 노드(leaf node)가 <val>에 지정된 노드 값을 갖는 경우 nv 필드는 해당 MO 인스턴스에 대해 “만족된다(satisfied)”라고 지칭된다.

본 발명에 따른 URI 해석 방법

DM 클라이언트는 URI(예, ClientURI)를 수신하고 이를 해석(resolve)하여 URI가 지정하는 특정 노드를 찾는다. URI에 와일드카드(wildcard)가 사용되지 않으면, DM 클라이언트는 URI가 단말에서 하나의 유일한 노드를 지정되도록 해석해야 한다. 만약 와일드카드(wildcard)가 사용된 경우, 하나의 URI는 단말에서 복수의 노드를 지정하도록 해석될 수 있다. 와일드카드(wildcard)가 사용된 경우, DM 클라이언트는 URI에 의해 매칭되는 모든 노드에 대해 장치 관리 명령을 실행할 수 있고, GET 명령에 대해서는 URI에 의해 매칭되는 모든 노드의 MO 데이터의 리스트를 리턴할 수 있다.

DM 클라이언트가 URI를 해석하는 과정은 크게 두 개의 과정으로 구성될 수 있다. 첫 번째 과정(제1 과정)은 URI가 지정하는 MO 인스턴스를 찾는 과정이고, 두 번째 과정(제2 과정)은 제1 과정에서 찾아진 MO 인스턴스를 대상으로 그 안에서 URI가 지정하는 특정 노드를 찾는 과정이다.

■ 제1 과정: URI의 MOID 컴포넌트와 mo-inst 컴포넌트를 이용하여 URI가 지정하는 MO 인스턴스를 찾는다. mo-inst 컴포넌트는 MIID 컴포넌트, x-name 컴포넌트, 빈 문자열(empty string), 와일드카드(wildcard) 중 하나가 될 수 있으며, 각각은 다음와 같이 해석되어야 한다.

- MIID 컴포넌트: DM 클라이언트는 MOID 컴포넌트가 가리키는 MOID와 MIID 컴포넌트가 가리키는 MIID를 가지는 유일한 하나의 MO 인스턴스를 찾는다. 지정된 MOID와 MIID를 갖는 MO 인스턴스가 없거나 복수개가 찾아진 경우, 에러 코드가 반환된다. 유일한 하나의 MO 인스턴스가 찾아진 경우 제2 과정으로 진행한다.

- x-name 컴포넌트: mo-inst 컴포넌트가 x-name 컴포넌트를 포함하는 경우, DM 클라이언트는 지정된 MOID와 x-name 컴포넌트에 대응되는 nv 필드를 모두 만족시키는 하나의 유일한 MO 인스턴스를 찾는다. MO 인스턴스가 없거나 복수개가 찾아진 경우, 에러 코드가 반환된다. 유일한 하나의 MO 인스턴스가 찾아진 경우 제2 과정으로 진행한다.

- 빈 문자열(empty string)(예, “”): MOID 컴포넌트에 의해 지정된 MOID를 가지는 MO 인스턴스가 단말에 하나만 존재하는 경우 빈 문자열이 사용될 수 있다. 따라서, 단말에서 MOID를 가지는 MO 인스턴스가 유일하게 하나만 존재할 경우 제2 과정으로 진행한다. MO 인스턴스가 없거나 복수개가 찾아진 경우, 에러 코드가 반환된다.

- 와일드카드(wildcard)(예, “*”): 지정된 MOID를 갖는 MO 인스턴스가 하나 이상 있다면 제2 과정으로 진행한다. 이 경우, MOID를 갖는 모든 MO 인스턴스가 제2 과정에서 고려된다. 만약 지정된 MOID를 갖는 MO 인스턴스가 하나도 없다면 에러 코드가 반환된다.

■ 제2 과정: 제1 과정에서 찾아진 MO 인스턴스를 대상으로 DM 클라이언트는 URI의 path-from-moroot 컴포넌트를 해석하여 URI가 지정하는 노드를 최종적으로 찾는다. 앞서 기술한 바와 같이, path-from-moroot 컴포넌트가 “/”일 경우는 MO 인스턴스 루트 노드를 지정한다. path-from-moroot 컴포넌트가 "/"가 아닌 경우, path-from-moroot 컴포넌트는 node-name 컴포넌트의 시퀀스로서, node-name 컴포넌트는 real-name 컴포넌트, x-name 컴포넌트 또는 와일드카드(wildcard)를 포함할 수 있다. real-name 컴포넌트, x-name 컴포넌트 또는 와일드카드(wildcard) 각각은 아래와 같이 해석될 수 있다.

- real-name 컴포넌트: 본 컴포넌트는 실제 노드 이름을 지정한다.

- x-name 컴포넌트: DM 클라이언트는 대응되는 nv 필드를 사용하여 x-name 컴포넌트가 가리키는 실제 노드를 유일하게 찾는다. 대응되는 nv 필드가 복수 존재하는 경우 모든 nv 필드를 만족시키는 유일한 노드를 찾아야 한다. 유일한 노드를 찾지 못한 경우, 에러 코드가 반환될 수 있다.

- 와일드카드(wildcard)(예, “*”): 와일드카드가 사용된 위치에 존재하는 모든 노드가 지정된다.

도 16은 <x> 노드를 포함하는 MO 정의와 MO 인스턴스를 예시한다. 도 16(a)는 특정 MO 정의를 나타내고 도 16(b)는 단말에서 도 16(a)의 MO 정의에 대해 2개의 MO 인스턴스가 생성된 예를 나타낸다. 도 16(a)의 MO는 “urn:oma:mo:moid:1.0”의 MOID를 갖는다고 가정한다. 본 발명의 원리는 도 16에 예시된 특정 MO에만 제한되어 적용되는 것은 아니다.

도 16(a)를 참조하면, 특정 MO는 2개의 <x> 노드(1602, 1610)를 포함하도록 정의될 수 있다. <x> 노드(1602)는 MO 인스턴스 루트 노드이고, <x> 노드(1610)는 인테리어 노드이다. 특정 MO 정의는 <x> 노드(1602, 1610)와 유명 노드를 이용하여 MO의 구성 및 세부 정보(예, 특정 MO의 서브트리)가 정의되지만 MO 인스턴스에서는 MO 정의에 따라 <x> 노드(1602, 1610)의 이름이 결정되어 있다. 앞서 설명된 바와 같이, 절대(Absolute) URI나 가상(virtual) URI를 이용할 경우 DM 서버는 각 <x> 노드(1602, 1610)의 이름을 알지 못할 경우 <x> 노드 밑의 노드를 URI로 지정하기 위해서는 MO에 대한 정보를 먼저 알아야 한다. 따라서, 절대 URI나 가상 URI를 이용할 경우 비효율적이다.

도 16(b)를 참조하면, GPS 센서 관리를 위한 MO 인스턴스(1630)와 온도 센서 관리를 위한 MO 인스턴스(1660)가 단말에 생성될 수 있다. 이 경우 단말의 DM 트리에 동일한 MOID를 가지는 2개의 MO 인스턴스가 존재할 수 있다. MO 인스턴스(1630)가 생성될 때 MO 인스턴스(1630)의 MIID는 “left”로 설정되고 <x> 노드(1602)의 노드 이름은 “moroot1”으로 설정되고 <x> 노드(1610)에 대해서는 2개의 노드(1640, 1646)가 생성되며 노드 이름은 각각 “1”과 “2”로 설정된다고 가정한다. 또한, MO 인스턴스(1660)가 생성될 때 MO 인스턴스(1660)의 MIID는 “right”로 설정되고 <x> 노드(1602)의 노드 이름은 “moroot2”로 설정되고 <x> 노드(1610)에 대해서는 2개의 노드(1672, 1678)가 생성되며 노드 이름은 각각 “1”과 “2”로 설정된다고 가정한다. 이 경우 복수의 MO 인스턴스(1630, 1660)가 동일한 MOID “urn:oma:mo:moid:1.0”를 가지므로 MOID URI에 따른 주소 표현 방식은 적용될 수 없다.

본 발명에 따른 MIID를 이용한 주소 표현 방식을 노드(1632)에 적용하면, MOID는 “urn:oma:mo:moid:1.0”이고 MIID는 “left”이다. 또한, 노드(1632)가 MO 인스턴스 루트 노드이므로 path-from-moroot 컴포넌트는 “/”이다. 또한, URI에 x-name이 포함되어 있지 않으므로 query 컴포넌트는 필요없다. 따라서, 본 발명에 따른 인스턴스 URI를 이용하면 노드(1632)의 URI는 “urn:oma:mo:moid:1.0/left/”로 표현될 수 있다.

또한, 노드(1644)를 지정하기 위해 본 발명에 따른 x-name을 이용한 주소 표현 방식을 적용하면, MOID는 “urn:oma:mo:moid:1.0”이고 MO 인스턴스(1630)는 x-name을 이용하여 나타낼 수 있다. 이 경우, 대응되는 nv 필드가 query 컴포넌트에 포함되어야 한다. MO 인스턴스(1630)를 x-name 컴포넌트 “(x)”로 지정하면 nv 필드는 “nv=(x)/ID:GPS”로 지정될 수 있다. 또한, path-from-moroot 컴포넌트는 MO 인스턴스 루트 노드의 자식 노드인 노드(1638)로부터 노드(1644)까지의 상대적인 경로를 나타내고 그 경로에 또 다른 <x> 노드(1640)를 포함하므로, path-from-moroot 컴포넌트는 “/Data/(y)/Value”로서 표현될 수 있다. 이 경우, <x> 노드(1640)가 x-name 컴포넌트 “(y)”로 지정되었으므로 대응되는 nv 필드는 “nv=(y)/Date:12.1”로 표현될 수 있다. nv 필드는 query 컴포넌트에 포함되고 복수의 nv 필드가 포함되는 경우 각 nv 필드는 구획 문자 “&”에 의해 구분될 수 있다. 따라서, 본 발명에 따른 x-name을 이용한 노드(1644)의 URI는 “urn:oma:mo:moid:1.0/(x)/Data/(y)/Value?nv=(x)/ID:GPS&nv=(y)/Date:12.1”로서 표현될 수 있다.

이에 반해, 절대(Absolute) URI 또는 가상(Virtual) URI를 이용한 경우, 각 <x> 노드의 이름을 알아야 하는데 <x> 노드의 이름을 알기 위해서 전체 MO 인스턴스에 대한 정보 또는 전체 DM 트리에 대한 정보를 단말에게 요청하여 수신해야 한다. 따라서, 이를 위한 시그널링에서 상당한 부담이 존재하며 비효율적이다. 대조적으로, 본 발명에 따른 x-name을 이용한 주소 표현 방식을 이용할 경우, 전체 DM 트리 구조를 알 필요가 없고 <x> 노드의 이름도 알 필요가 없다.

본 발명에 따르면, 하나의 URI로 복수의 노드를 지정하는 것도 가능하다. 예를 들어, 노드(1636)와 노드(1666)를 본 발명에 따른 하나의 URI로 지정하기 위해 와일드카드가 사용될 수 있다. 이 경우, MOID는 “urn:oma:mo:moid:1.0”이고 MO 인스턴스 루트 노드(1632, 1662)가 <x> 노드이므로 와일드카드(예, “*” )를 사용할 수 있다. 그러면, 본 발명에 따른 노드(1636)와 노드(1666)를 나타내는 URI는 “urn:oma:mo:moid:1.0/*/Setting”으로 표현될 수 있다.

마찬가지로, 와일드카드를 이용하여 4개의 노드(1644, 1650, 1674, 1680)를 하나의 URI로 표현하는 것도 가능하다. MO 인스턴스 루트 노드가 <x> 노드로서 표현되고 4개의 노드(1644, 1650, 1674, 1680)의 부모 노드도 <x> 노드로서 표현되므로 하나의 URI는 “urn:oma:mo:moid:1.0/*/Data/*/Value”로서 표현될 수 있다. 따라서, 복수의 노드들을 하나의 URI를 이용하여 표현함으로써 단말에게 주어야할 명령의 개수를 줄일 수 있다. 예를 들어, 4개의 노드(1644, 1650, 1674, 1680)에 대한 값을 읽어 오기 위해 Get 명령을 이용하는 경우, 하나의 URI로 4개의 노드(1644, 1650, 1674, 1680)를 한번에 지정할 수 있으므로 Get 명령을 한번만 보내면 된다.

하지만, 절대 URI 또는 가상 URI의 경우 하나의 URI로서 하나의 노드만을 표현할 수 있으므로, 4개의 노드(1644, 1650, 1674, 1680)에 대한 값을 읽어 오기 위해 Get 명령을 4번 보내야 하므로 비효율적이다.

본 발명에 따른 주소 표현 방식들은 독자적으로만 적용되는 것은 아니고 함께 사용될 수 있다. 예를 들어, MIID와 x-name이 함께 사용될 수 있다. 예를 들어, MIID를 이미 알고 있는 경우 MO 인스턴스를 지정하기 위해 x-name을 사용하지 않고 MIID를 사용할 수 있다. 하지만, path-from-moroot 컴포넌트에 대해서는 x-name을 사용할 수 있다. 예를 들어, 노드(1674)를 지정하는 URI를 표현하기 위해 MIID와 x-name을 사용하는 경우, MO 인스턴스의 MIID가 “right”라는 것을 알고 있다고 가정한다. 이 경우, MO 인스턴스를 지정하기 위해 MOID “urn:oma:mo:moid:1.0”와 MIID “right”를 사용할 수 있다. 또한, path-from-moroot 컴포넌트는 “/Data/(x)/Value”로서 표현될 수 있다. 이 경우, <x> 노드(1670)가 x-name “(x)”로 지정되었으므로 대응되는 nv 필드는 “nv=(x)/Date:12.1”로 표현될 수 있다. 따라서, 본 발명에 따른 노드(1674)의 URI는 “urn:oma:mo:moid:1.0/right/Data/(x)/Value?nv=(x)/Date:12.1”로서 표현될 수 있다.

또한, 본 발명에 따른 MIID와 와일드카드를 이용한 주소 표현 방식도 가능하다. 예를 들어, 2개의 노드(1644, 1650)를 하나의 URI를 이용하여 지정하려는 경우, MO 인스턴스는 MOID와 MIID를 이용하여 지정하고 path-from-moroot 컴포넌트에서 와일드카드를 이용하여 2개의 노드(1644, 1650)를 표현할 수 있다. 이 경우, 본 발명에 따른 노드(1644, 1650)의 URI는 “urn:oma:mo:moid:1.0/left/Data/*/Value”로서 표현될 수 있다.

또한, 본 발명에 따른 x-name와 와일드카드 조합에 의한 주소 표현 방식도 가능하다. 예를 들어, 2개의 노드(1644, 1650)를 하나의 URI를 이용하여 지정하려는 경우, MO 인스턴스는 MOID와 x-name을 이용하여 지정하고 path-from-moroot 컴포넌트에서 와일드카드를 이용하여 2개의 노드(1644, 1650)를 표현할 수 있다. 이 경우, 본 발명에 따른 노드(1644, 1650)의 URI는 “urn:oma:mo:moid:1.0/(x)/Data/*/Value?nv=(x)/ID:GPS”로서 표현될 수 있다. 다른 예로, 2개의 노드(1644, 1674)를 하나의 URI를 이용하여 지정하려는 경우, MO 인스턴스는 MOID와 와일드카드를 이용하여 지정하고 path-from-moroot 컴포넌트에서 x-name을 이용하여 2개의 노드(1644, 1674)를 표현할 수 있다. 이 경우, 본 발명에 따른 노드(1644, 1674)의 URI는 “urn:oma:mo:moid:1.0/*/Data/(x)/Value?nv=(x)/Date:12.1”로서 표현될 수 있다.

이상 본 발명에 따른 URI 주소 표현 방식에 대한 설명에서, mo-inst 컴포넌트는 MO 인스턴스 정보로서 통칭될 수 있고, path-from-moroot 컴포넌트는 MO 인스턴스 루트 노드로부터 특정 노드까지의 경로로서 통칭될 수 있다. 이 경우, 특정 노드는 URI가 가리키는 노드를 나타낸다. 또한, 쿼리 컴포넌트는 질의 정보로서 통칭될 수 있다. 또한, 이상에서 특정하여 설명된 구획 문자들은 제한적이지 않은 예로서 다른 구획 문자들로서 대체되어 사용될 수 있다.

도 17은 본 발명이 적용될 수 있는 디바이스 및 서버를 예시한다.

도 17에 도시된 바와 같이, 본 발명이 적용될 수 있는 디바이스(1710)는 프로세서(1712)와 메모리(1714)와 송수신 모듈(1716)를 포함한다. 또한, 본 발명이 적용될 수 있는 서버(1720)는 프로세서(1722)와 메모리(1724)와 송수신 모듈(1726)를 포함한다.

메모리들(1714, 1724)은 프로세서(1712)와 연결되고 본 발명에 따른 방법들을 수행하기 위한 소프트웨어 프로그램 또는 명령어들 뿐만 아니라 프로세서(1712)의 동작과 관련한 다양한 정보를 저장할 수 있다.

프로세서들(1712, 1722)은 메모리들(1712, 1722) 및 송수신 모듈들(1716, 1726)과 연결되고 이들을 제어한다. 구체적으로 프로세서들(1712, 1722)은 각각 메모리들(1712, 1722)에 저장된 소프트웨어 프로그램 또는 명령어들을 실행함으로써 방법들을 실행한다. 그리고 프로세서들(1712, 1722)은 송수신 모듈들(1716, 1726)을 통해 전술한 신호들을 송신 및/또는 수신한다.

전술된 실시예들 및 변형예들은 다양한 수단을 통해 구현될 수 있다. 예를 들어, 본 발명의 실시예들은 하드웨어, 펌웨어(firmware), 소프트웨어 또는 그것들의 결합 등에 의해 구현될 수 있다.

하드웨어에 의한 구현의 경우, 본 발명의 실시예들에 따른 방법은 하나 또는 그 이상의 ASICs(application specific integrated circuits), DSPs(digital signal processors), DSPDs(digital signal processing devices), PLDs(programmable logic devices), FPGAs(field programmable gate arrays), 프로세서, 컨트롤러, 마이크로 컨트롤러, 마이크로 프로세서 등에 의해 구현될 수 있다.

펌웨어나 소프트웨어에 의한 구현의 경우, 본 발명의 실시예들에 따른 방법은 이상에서 설명된 기능 또는 동작들을 수행하는 모듈, 절차 또는 함수 등의 형태로 구현될 수 있다. 소프트웨어 코드는 메모리 유닛에 저장되어 프로세서에 의해 구동될 수 있다. 상기 메모리 유닛은 상기 프로세서 내부 또는 외부에 위치하여, 이미 공지된 다양한 수단에 의해 상기 프로세서와 데이터를 주고 받을 수 있다.

예를 들어, 본 발명에 따른 방법은 컴퓨터 판독가능한 저장 매체(예를 들어, 내부 메모리, 플래쉬 메모리, 하드 디스크, 기타 등등)에 저장될 수 있고, 프로세서(예를 들어, 마이크로 프로세서)에 의해서 실행될 수 있는 소프트웨어 모듈(또는 프로그램) 내에 코드들 또는 명령어들로 구현될 수 있다.

본 발명의 실시예들을 구현하는 소프트웨어 모듈은 스크립트(script), 배치(batch), 또는 다른 실행가능한 파일들을 포함할 수 있다. 소프트웨어 모듈들은 디스크 드라이브와 같은 기계 판독가능한 또는 컴퓨터 판독가능한 저장 매체 상에 저장될 수 있다. 본 발명의 실시예에 따른 소프트웨어 모듈들을 저장하는 데 사용되는 저장 디바이스들은 예를 들어 자기 플로피 디스크, 하드 디스크, 또는 CD-ROM이나 CD-R과 같은 광학 디스크일 수 있다. 본 발명의 실시예에 따른 펌웨어나 하드웨어 모듈들을 저장하는 데 사용되는 저장 디바이스는 또한 반도체 기반의 메모리를 포함할 수 있으며, 이는 영구적으로, 탈착가능하게, 또는 원격으로 마이크로프로세서/메모리 시스템에 연결될 수 있다. 따라서, 상기 모듈들은 모듈의 기능들을 수행하는 컴퓨터 시스템을 구성하기 위해 컴퓨터 시스템 메모리 내에 저장될 수 있다. 다른 새롭고 다양한 유형의 컴퓨터 판독가능한 저장매체가 본 명세서에서 논의된 모듈들을 저장하는 데 사용될 수 있다. 게다가, 당해 기술분야의 통상의 기술자들은 기능들을 모듈들로 분리하는 것이 예시를 위한 목적이라는 것을 인식할 것이다. 대체가능한 실시예들은 다중 모듈들의 기능들을 단일 모듈로 병합할 수 있고, 또는 모듈들의 기능들을 대체가능하게 성분 분리할 수 있다. 예를 들어, 서브-모듈들을 호출하기 위한 소프트웨어 모듈들은 각 서브-모듈이 그것의 기능을 수행하고 제어를 직접적으로 다른 서브-모듈로 넘겨주도록 성분 분리될 수 있다.

이상에서 설명된 실시예들은 본 발명의 구성들과 특징들이 소정 형태로 결합된 것들이다. 각 구성 또는 특징은 별도의 명시적 언급이 없는 한 선택적인 것으로 고려되어야 한다. 각 구성 또는 특징은 다른 구성이나 특징과 결합되지 않은 형태로 실시될 수 있다. 또한, 일부 구성들 및/또는 특징들을 결합하여 본 발명의 실시예를 구성하는 것도 가능하다. 본 발명의 실시예들에서 설명되는 동작들의 순서는 변경될 수 있다. 어느 실시예의 일부 구성이나 특징은 다른 실시예에 포함될 수 있고, 또는 다른 실시예의 대응하는 구성 또는 특징과 교체될 수 있다. 특허청구범위에서 명시적인 인용 관계가 있지 않은 청구항들을 결합하여 실시예를 구성하거나 출원 후의 보정에 의해 새로운 청구항으로 포함시킬 수 있음은 자명하다.

본 발명은 본 발명의 정신 및 필수적 특징을 벗어나지 않는 범위에서 다른 특정한 형태로 구체화될 수 있다. 따라서, 상기의 상세한 설명은 모든 면에서 제한적으로 해석되어서는 안되고 예시적인 것으로 고려되어야 한다. 본 발명의 범위는 첨부된 청구항의 합리적 해석에 의해 결정되어야 하고, 본 발명의 등가적 범위 내에서의 모든 변경은 본 발명의 범위에 포함된다. 또한, 특허청구범위에서 명시적인 인용 관계가 있지 않은 청구항들을 결합하여 실시예를 구성하거나 출원 후의 보정에 의해 새로운 청구항으로 포함시킬 수 있다.

본 발명은 단말 및 서버 등과 같은 장치에 사용될 수 있다.

Claims (15)

1. 디바이스에서 장치 관리(device management)를 위한 특정 노드를 지정하는 URI(Uniform Resource Identifier)의 해석(resolve) 방법에 있어서,
   상기 URI에 포함된 MOID(Management Object Identifier)와 MO 인스턴스 정보에 따라 적어도 하나의 MO 인스턴스를 찾는 단계; 및
   상기 적어도 하나의 MO 인스턴스 내에서, 상기 URI에 포함된 MO 인스턴스 루트 노드로부터 상기 특정 노드까지의 경로를 이용하여 상기 특정 노드를 찾는 단계를 포함하되,
   상기 MO 인스턴스 정보가 MIID(Management Object Instance Identifier)를 포함하는 경우, 상기 MIID는 동일한 MOID를 갖는 MO 인스턴스들 중에서 유일하며, 상기 적어도 하나의 MO 인스턴스를 찾는 단계는 상기 MOID와 상기 MIID를 가지는 유일한 MO 인스턴스를 찾는 것과, 상기 MOID와 상기 MIID를 가지는 MO 인스턴스가 없거나 복수로 존재하는 경우 에러를 반환하는 것을 포함하고,
   상기 MO 인스턴스 정보가 제1 구획 문자, 알파벳 문자, 제2 구획 문자로 구성되는 노드 이름을 포함하는 경우, 상기 알파벳 문자는 하나의 URI 내의 상기 제1 구획 문자 및 상기 제2 구획 문자를 포함하는 노드 이름들 중에서 유일하며, 상기 URI는 적어도 하나의 노드 값 필드를 더 포함하고, 상기 적어도 하나의 노드 값 필드 각각은 상기 MO 인스턴스 정보에 의해 표현되는 위치로부터 리프 노드(leaf node)까지의 경로와 상기 리프 노드의 노드 값을 포함하며, 상기 적어도 하나의 MO 인스턴스를 찾는 단계는 상기 적어도 하나의 노드 값 필드 모두에 대해 상기 리프 노드가 상기 노드 값을 가지도록 하는 유일한 MO 인스턴스를 찾는 것을 포함하는, 방법.
2. 삭제
3. 제1항에 있어서,
   상기 적어도 하나의 노드 값 필드 각각은 상기 제1 구획 문자, 상기 알파벳 문자, 상기 제2 구획 문자로 구성되는 상기 MO 인스턴스 정보를 포함하는, 방법.
4. 제1항에 있어서,
   상기 MO 인스턴스 정보가 빈 문자열(empty string)로 구성되는 경우, 상기 적어도 하나의 MO 인스턴스를 찾는 단계는 상기 디바이스에서 상기 MOID를 가지는 유일한 MO 인스턴스를 찾는 것을 포함하는, 방법.
5. 제1항에 있어서,
   상기 MO 인스턴스 정보가 와일드카드 문자로 구성되는 경우, 상기 적어도 하나의 MO 인스턴스를 찾는 단계는 상기 디바이스에서 상기 MOID를 가지는 모든 MO 인스턴스를 찾는 것을 포함하는, 방법.
6. 제1항에 있어서,
   상기 MO 인스턴스 루트 노드로부터 상기 특정 노드까지의 경로가 제1 구획 문자, 알파벳 문자, 제2 구획 문자로 구성되는 노드 이름을 포함하는 경우, 상기 URI는 적어도 하나의 노드 값 필드를 더 포함하고, 상기 적어도 하나의 노드 값 필드 각각은 상기 노드 이름이 가리키는 위치로부터 리프 노드(leaf node)까지의 경로와 상기 리프 노드의 노드 값을 포함하며, 상기 특정 노드를 찾는 단계는 상기 적어도 하나의 노드 값 필드 모두에 대해 상기 리프 노드가 상기 노드 값을 가지도록 하는 유일한 노드를 찾는 것을 포함하는, 방법.
7. 제6항에 있어서,
   상기 적어도 하나의 노드 값 필드 각각은 상기 제1 구획 문자, 상기 알파벳 문자, 상기 제2 구획 문자로 구성되는 상기 노드 이름을 포함하는, 방법.
8. 제1항에 있어서,
   상기 MO 인스턴스 루트 노드로부터 상기 특정 노드까지의 경로가 와일드카드 문자로 구성되는 노드 이름을 포함하는 경우, 상기 특정 노드를 찾는 단계는 상기 와일드카드 문자의 위치에 해당하는 모든 노드를 찾는 것을 포함하는, 방법.
9. 제1항에 있어서,
   상기 MO 인스턴스 루트 노드로부터 상기 특정 노드까지의 경로가 하나의 구획 문자로 구성되는 경우, 상기 특정 노드를 찾는 단계는 상기 MO 인스턴스 루트 노드를 찾는 것을 포함하는, 방법.
10. 장치 관리(device management)를 위한 특정 노드를 지정하는 URI(Uniform Resource Identifier)를 해석(resolve)하는 장치에 있어서, 상기 장치는
    메모리; 및 상기 메모리에 연결되는 프로세서를 포함하되, 상기 프로세서는
    상기 URI에 포함된 MOID(Management Object Identifier)와 MO 인스턴스 정보에 따라 적어도 하나의 MO 인스턴스를 찾고, 상기 적어도 하나의 MO 인스턴스 내에서, 상기 URI에 포함된 MO 인스턴스 루트 노드로부터 상기 특정 노드까지의 경로를 이용하여 상기 특정 노드를 찾도록 구성되며,
    상기 MO 인스턴스 정보가 MIID(Management Object Instance Identifier)를 포함하는 경우, 상기 MIID는 동일한 MOID를 갖는 MO 인스턴스들 중에서 유일하며, 상기 적어도 하나의 MO 인스턴스를 찾는 단계는 상기 MOID와 상기 MIID를 가지는 유일한 MO 인스턴스를 찾는 것과, 상기 MOID와 상기 MIID를 가지는 MO 인스턴스가 없거나 복수로 존재하는 경우 에러를 반환하는 것을 포함하고,
    상기 MO 인스턴스 정보가 제1 구획 문자, 알파벳 문자, 제2 구획 문자로 구성되는 노드 이름을 포함하는 경우, 상기 알파벳 문자는 하나의 URI 내의 상기 제1 구획 문자 및 상기 제2 구획 문자를 포함하는 노드 이름들 중에서 유일하며, 상기 URI는 적어도 하나의 노드 값 필드를 더 포함하고, 상기 적어도 하나의 노드 값 필드 각각은 상기 MO 인스턴스 정보에 의해 표현되는 위치로부터 리프 노드(leaf node)까지의 경로와 상기 리프 노드의 노드 값을 포함하며, 상기 적어도 하나의 MO 인스턴스를 찾는 것은 상기 적어도 하나의 노드 값 필드 모두에 대해 상기 리프 노드가 상기 노드 값을 가지도록 하는 유일한 MO 인스턴스를 찾는 것을 포함하는, 장치.
11. 삭제
12. 제10항에 있어서,
    상기 적어도 하나의 노드 값 필드 각각은 상기 제1 구획 문자, 상기 알파벳 문자, 상기 제2 구획 문자로 구성되는 상기 MO 인스턴스 정보를 포함하는, 장치.
13. 제10항에 있어서,
    상기 MO 인스턴스 루트 노드로부터 상기 특정 노드까지의 경로가 제1 구획 문자, 알파벳 문자, 제2 구획 문자로 구성되는 노드 이름을 포함하는 경우, 상기 URI는 적어도 하나의 노드 값 필드를 더 포함하고, 상기 적어도 하나의 노드 값 필드 각각은 상기 노드 이름이 가리키는 위치로부터 리프 노드(leaf node)까지의 경로와 상기 리프 노드의 노드 값을 포함하며, 상기 특정 노드를 찾는 것은 상기 적어도 하나의 노드 값 필드 모두에 대해 상기 리프 노드가 상기 노드 값을 가지도록 하는 유일한 노드를 찾는 것을 포함하는, 장치.
14. 제13항에 있어서,
    상기 적어도 하나의 노드 값 필드 각각은 상기 제1 구획 문자, 상기 알파벳 문자, 상기 제2 구획 문자로 구성되는 상기 노드 이름을 포함하는, 장치.
15. 제10항에 있어서,
    상기 MO 인스턴스 루트 노드로부터 상기 특정 노드까지의 경로가 하나의 구획 문자로 구성되는 경우, 상기 특정 노드를 찾는 것은 상기 MO 인스턴스 루트 노드를 찾는 것을 포함하는, 장치.

Images