KR101950122B1

KR101950122B1 - 경량 기기 간 프로토콜을 디바이스 관리 프로토콜과 상호연동하기

Info

Publication number: KR101950122B1
Application number: KR1020177005041A
Authority: KR
Inventors: 촹 리; 충강 왕; 데일 엔. 시드; 샤밈 아크바 라만; 쉬 리
Original assignee: 콘비다 와이어리스, 엘엘씨
Priority date: 2014-07-22
Filing date: 2015-07-22
Publication date: 2019-05-22
Also published as: US20170215023A1; WO2016014662A1; EP3172859A1; EP3172859B1; US10009707B2; JP6434611B2; CN107211232B; KR20170033424A; CN107211232A; JP2017525293A

Abstract

상호연동 LWM2M 및 OMA DM 프로토콜들이 기술된다. 새로운 DDF MO는 DM 서버들 및 게이트웨이들에게 LWM2M 오브젝트 정의들을 추가하는 것을 가능하게 한다. 이 MO는 DM 서버/게이트웨이가 LWM2M 오브젝트 정의들과 같은, 새로 정의된 MO들을 받아들이도록 허용한다. 새로운 절차들이 새롭게 생성된 DDF MO에 DDF 문서들을 등록하기 위해 정의된다. LWM2M 서버가 DM 게이트웨이에 종단 디바이스를 등록하도록 허용하기 위해 새로운 등록 인터페이스가 GwMO 프로토콜에 추가된다. 프로토콜 번역 메커니즘은 OMA DM 및/또는 GwMO 대 LWM2M과 같이, 비-RESTful 프로토콜 대 RESTful 프로토콜들 간의 갭을 메운다.

Description

경량 기기 간 프로토콜을 디바이스 관리 프로토콜과 상호연동하기{INTERWORKING LIGHT WEIGHT MACHINE-TO-MACHINE PROTOCOL WITH DEVICE MANAGEMENT PROTOCOL}

[관련 출원에 대한 상호 참조]

본 출원은 2014년 7월 22일에 출원된 미국 임시 특허 출원 번호 62/027,395의 혜택을 주장하는데, 이것의 개시내용은 본 명세서에 그 전체가 제시된 것처럼 참조에 의해 이로써 통합된다.

OMA(Open Mobile Alliance)는, OMA DM(Device management) 프로토콜, OMA GwMO(Gateway Managed Object) 프로토콜, 및 OMA LWM2M(Lightweight Machine-to-Machine) 프로토콜을 포함하여, 네트워크에서 디바이스 관리를 위한 수많은 프로토콜을 개발했다. OMA DM 프로토콜은 네트워크에서, 모바일 디바이스와 같은 독립형 디바이스들을 관리하는데 사용될 수 있다. OMA GwMO 프로토콜은 게이트웨이 배후에 있는 종단 디바이스들을 관리하는데 사용될 수 있으며, OMA LWM2M은 제약된 M2M(Machine-to-Machine) 또는 IoT(Internet-of-Things) 디바이스들을 관리하기 위해 이용될 수 있다.

OMA DM 프로토콜의 일반적 아키텍처가 도 1에 도시된다. DM 서버(102)(때때로 관리 서버로서 또한 지칭됨)는 DM 클라이언트들을 관리하기 위해 (디바이스 또는 게이트웨이(104)와 같은) 디바이스들 또는 게이트웨이들상에서 실행되는 DM 클라이언트들에게 커맨드들을 보내는 마스터 엔티티이다. DM 클라이언트는 DM 서버(102)와의 통신을 제공하기 위해 디바이스들 또는 게이트웨이들상에서 구동되는 엔티티이다. 이것은 또한 관리 클라이언트로서 지칭된다. DM 세션은 DM 서버와 DM 클라이언트 사이에 생성되는 OMA DM 프로토콜 관리 세션이다. DM 커맨드들은 2개의 엔티티 사이에서 이 세션 내에서 보내진다.

커맨드들은 디바이스들상의 MO들(Managed Objects)로 논리적으로 함께 그룹화되는 노드들상에서 동작한다. MO는 집합적으로 소프트웨어 다운로드(SCOMO) 또는 디바이스 정보(DevInfo MO)와 같은 몇몇 관리 동작을 제공하는 DM 노드들의 모음이다. MO들은 도1에서 (106)으로 보여지는 DM 트리 또는 관리 트리로 불리는 계층적 트리 구조로 조직화된다. 예시적 DM 트리가 도 2에 도해된다.

DM 노드는 MO 또는 DM 트리 내에서의 단일 성분이다. 이것은 내측 노드 또는 리프 노드일 수 있다. 내측 노드들은 자식 노드들을 가지고 있다; 리프 노드들은 자식 노드들을 가지지 않고 그리고 몇몇 값을 포함할 것이거나 또는 Execute 커맨드들에 의해 작동될 수 있다.

OMA DM 프로토콜에서, 각각의 MO는 OMA DDF(Device Description Framework)에 의해 기술된다. 이 DDF는 MO 내에 포함된 모든 노드들을 완전히 기술하기 위해 DM 서버에 의해 판독되는 XML(Extensible Markup Language) 문서이고, 이것은 각각의 노드상에서 어떤 작용들이 수행될 수 있는지를 기술한다. DDF에서 발견되는 성분들은 노드 명칭들, 노드 속성들, 및 리프 노드들과 연관되는 값들이다. 노드 속성들은 DFProperties(Description Framework Properties)를 포함한다. 이러한 DFProperties는 각각의 노드에 관한 메타데이터를 포함한다. DFProperties는 MO의 특정 동안 정의되는 속성들이고, 예들은 AccessType, DefaultValue, Description, DFFormat, Occurrence, Scope, DFTitle, DFType, 및 CaseSense를 포함한다. 게다가, RTProperties(Run Time Properties)는 실행 시간에서 발생되고, ACL(Access control List), 포맷, 명칭, 사이즈, 제목, 타임스탬프, 타입, 및 버전 번호와 같은 속성들을 포함한다.

도 3은 DDF 문서의 단순한 예를 보여준다. DFProperties의 세부 사항들은 간략화를 위해 의도적으로 탈락되었다는 것을 유의하라. 이 예에서, DDF는 URI "Vendor/ISP/GWInfo"를 가진 내측 노드를 기술하고 또한 "GWName"으로 명명된 자식 노드를 갖는데, 이것은 값 "gw.yyy.se"를 포함한다. "Vendor", "ISP", 및 "GWInfo"는 내측 노드의 명칭인 반면, "GWName"은 리프 노드의 명칭이다. DDF 파일들은 관리 오브젝트의 포맷 및 각각의 노드가 취할 수 있는 가능한 값들을 보여준다. 클라이언트 및/또는 서버는 값들을 각각의 노드에 할당하는 데에 책임이 있다. DDF 파일들은 대응하는 MO의 종단 대 종단 지원을 가능하게 하기 위해 DM 서버 및 DM 클라이언트에게 공급된다. 전형적으로, 이것은 DM 프로토콜의 정상 동작들로부터의 대역을 벗어나 행해진다.

도 4는 GwMO 프로토콜의 아키텍처를 도해한다. GwMO 프로토콜은 DM 서버(406)에 의해 직접적으로 도달되지 못할 수 있는 종단 디바이스들에게 디바이스 관리 기능성들을 확장하는 것을 돕는 중간 OMA DM 게이트웨이(402)를 정의한다. 종단 디바이스들(404a, 404b 및 404c)과 같은 종단 디바이스들은 OMA DM 게이트웨이(402)에게 통신하고, 이것은 이후 DM 서버(406)에게 새로운 종단 디바이스들에 대해 경보한다. 디바이스 관리 커맨드들이 DM 서버(406)로부터 OMA DM 게이트웨이(402)에게 보내지고, 이것은 이후 몇 가지 상이한 동작 모드 중 하나에 따라 커맨드들을 종단 디바이스들에게 분배한다. 세가지 모드는 다음과 같이 정의된다: 투명, 프록시, 및 적응 모드들. 투명 및 프록시 모드들의 양쪽에서, 종단 디바이스들이 원시 OMA DM 커맨드를 이해하는 반면에, 적응 모드는 OMA DM 프로토콜로부터 비-OMA DM 프로토콜로의 번역을 요구한다.

GwMO 컴포넌트(도시 생략)가 OMA DM 게이트웨이(402)의 동작에 핵심 구실을 한다. 이 엔티티는 게이트웨이 배후의 종단 디바이스들을 관리하기 위해 5개의 MO를 제공한다: Device Inventory, Gateway Config, Fanout, Image Inventory, 및 End Device Trigger. 이러한 MO들의 기능성은 OMA DM 프로토콜과 같은 메시지 포맷들을 재사용하고, 그래서 이것은 OMA DM 시스템과 끊김 없이 기능하도록 설계된다. GwMO 컴포넌트의 정의는 OMA가, 그 중 몇몇은 기존의 OMA DM 디바이스들보다 더 제약될 수 있는 비-OMA DM 디바이스들을 지원하도록 그 도달 범위를 확장하는 것을 허용한다.

LWM2M 프로토콜은 M2M 통신 네트워크들에서 M2M 디바이스들을 관리하기 위한 수단으로서 M2M 통신 네트워크들의 증가하는 인기를 감당하기 위해 개발되었다. LWM2M은 OMA DM과 동일한 클라이언트-서버 아키텍처를 기반으로 하지만, M2M 통신 네트워크들에서 발견되는 것들과 같은, 더 제약된 디바이스들에 더 적용 가능한 더 단순하고 더 납작한(flatter) 리소스 트리를 가진 상이한 통신 프로토콜을 사용한다. 특히, LWM2M은 CoAP(Constrained Application Protocol)를 이용하고 이것의 리소스 트리는 더 적은 레벨들의 계층 구조들을 가진 납작한 구조로 조직되는 기초 리소스들을 가진 Objects로서 정의된다. LWM2M에서의 Objects 및 리소스들의 정의는 OMA DM 프로토콜에서의 MO들 및 노드들의 것과 유사하다. 도5는 LWM2M 아키텍처를 도해한다. 도면에 도시된 바와 같이, LWM2M 서버(502)는 OMA LWM2M 프로토콜의 마스터 엔티티이다. 이것은 디바이스 관리 및 정보 보고 능력들을 제공하기 위해 LWM2M 클라이언트들(예를 들어, LWM2M 클라이언트(504))과 통신한다. LWM2M 클라이언트들은 디바이스 관리 및 정보 보고 능력들을 LWM2M 서버들에게 제공하는 M2M 또는 IoT 시스템들 내에서의 M2M 디바이스(506)와 같은, 제약된 디바이스들상에서 실행된다.

디바이스 관리를 지원할 뿐만 아니라, LWM2M 프로토콜은 또한 제약된 디바이스들에 의해 제공되는 서비스 가능화를 지원한다. 제약된 디바이스가 주로 그것의 특정한 애플리케이션을 위한 데이터 측정들을 제공하기 때문에, 정보 보고는 프로토콜에서 특정되는 주요 서비스 가능화 중 하나이다. 이와 같이, Objects의 설계는 디바이스 관리 및 정보 보고를 지원할 리소스들을 제공하는 데에 초점이 맞추어져 있다.

본 명세서에 개시되는 실시예들은 더해진 기능성을 제공하는 기존의 OMA DM 및 GwMO 프로토콜들에 대한 향상을 제공하는 한편으로, 또한 LWM2M과 상호연동(interworking)하는 것을 가능하게 한다. 본 출원의 하나의 양태에 따르면, 새로운 DDF MO가 생성되어 LWM2M 오브젝트 정의들을 DM 서버들 및 게이트웨이들에 더하는 것을 가능하게 한다. 이 MO는 DM 서버/게이트웨이로 하여금 LWM2M Object 정의들과 같은, 새로 정의된 MO들을 받아들이게 할 수 있다. 또 다른 양태에 있어서, 새로운 절차들이 DDF 문서들을 새롭게 생성된 DDF MO에 등록하기 위해 정의된다. 또 다른 양태는 LWM2M 서버로 하여금 DM 게이트웨이에 종단 디바이스들을 등록할 수 있게 하기 위해 GwMO 프로토콜에 새로운 등록 인터페이스를 추가하는 것을 수반한다. 또 다른 양태는 OMA DM 및/또는 GwMO 대 LWM2M와 같은, 비 RESTful 대 RESTful 프로토콜 간의 간격을 메우기 위한 프로토콜 번역 메커니즘들을 도입한다.

이 요약은 아래의 상세한 설명에서 더 설명되는 개념들의 발췌를 간단한 형태로 소개하기 위해 제공된다. 이 요약은 청구된 주제의 핵심 특징들 또는 본질적 특징들을 식별하기 위해 의도된 것이 아니며, 청구된 주제의 범위를 한정하는 데 이용되도록 의도된 것도 아니다. 또한, 청구된 주제는 본 개시 내용의 어떠한 부분에서든 언급된 임의의 또는 모든 단점들을 해결하는 제한 사항들에만 한정되지는 않는다.

유사한 도면 부호들이 그 전체에 걸쳐 동일한 요소들을 나타내는 첨부된 도면과 연계하여, 예를 드는 식으로 주어지는 이하의 상세한 설명으로부터 보다 상세한 이해를 가질 수 있다. 도면에서:
도 1은 OMA DM 프로토콜의 일반적 아키텍처를 도해하는 블럭도이다.
도 2는 OMA DM 프로토콜 DM 트리의 예를 보여준다.
도 3은 OMA DM DDF 문서의 단순한 예를 보여준다.
도 4는 OMA GwMO 프로토콜의 아키텍처를 도해한다.
도 5는 OMA LWM2M 프로토콜의 아키텍처를 도해한다.
도 6은 일 실시예에 따라, 또한 설명된 본 출원의 다양한 양태를 가진 및 LWM2M 시스템의 오버레이를 가진 OMA GwMO 아키텍처의 일 실시예의 블럭도이다.
도 7은 그것에 관한 일 실시예에 따라서, 새로운 DDF MO의 노드들을 도해하는 도면이다.
도 8은 본 명세서에서 기술되는 DDF MO Registration 절차에 의해 DM 서버 내에서 트리거링될 수 있는 처리 단계들의 일 실시예를 설명하는 흐름도이다.
도 9는 새로운 DDF를 DDF MO와 등록하기 위한 방법의 일 실시예를 설명하는 호출 흐름이다.
도 10a는 DDF 파일이 메시지에 내장되는 등록 DDF 경보 메시지의 한 예를 보여준다.
도 10b는 DDF 파일의 로케이션이 URI에 의해 특정되는 등록 DDF 경보 메시지의 또 다른 예를 보여준다.
도 11은 새로운 GwMO Device Registration 절차의 일 실시예를 설명하는 호출 흐름이다.
도 12는 Device Inventory MO의 - OMA GwMO 프로토콜 사양에서 기술된 대로임 - 그러나 새로운 노드 - 지원MO -와 그것의 자식 노드들의 추가에 의한 구조의 일 실시예를 도해하는 도면이다.
도 13a는 Device Registration 메시지의 한 예를 보여준다.
도 13b는 등록 해제 메시지의 한 예를 보여준다.
도 14는 두 개의 Add 및 하나의 Delete 커맨드들을 포함하는 Sequence 커맨드의 예를 보여준다.
도 15a 및 15b는 그것에 관한 일 실시예에 따라서, 프로토콜 번역기에 의해 실행될 수 있는 프로토콜 번역의 한 예를 설명하는 호출 흐름을 함께 포함한다.
도 16은 OMA GwMO 적응 동작 모드의 이용을 통해서 LWM2M 시스템과 OMA DM 시스템 사이의 상호연동을 제공하는 시스템의 실시예를 보여준다.
도 17a, 17b 및 17c는 일 실시예에 따라서, 도16의 시스템의 동작을 도해하는 호출 흐름을 포함한다.
도 18은 그것에 관한 일 실시예에 따라서 표시될 수 있는 그래픽 사용자 인터페이스의 한 예를 보여준다.
도 19a는 하나 이상의 개시된 실시예들이 구현될 수 있는 예시적인 M2M, IoT, 또는 WoT(Web of Things) 통신 시스템의 도면이다.
도 19b는 도 19a의 시스템의 추가적 세부 사항들을 도해하는 도면이다.
도 19c는 다양한 실시예에서 사용될 수 있는 종단 디바이스의 예시적 아키텍처를 도해하는 도면이다.
도 19d는 본 명세서에 예시되고 기술된 논리 엔티티들 중 임의의 것을 구현하는데 사용될 수 있는 컴퓨터 시스템 또는 서버의 블럭도이다.

앞에서 기술된 OMA 프로토콜들의 개발은 OMA가 최근에 부상하는 기술을 다룸에 따른 점진적 진화를 반영한다. OMA LWM2M 프로토콜은 M2M, IoT 및 WoT(Web of Things) 디바이스들에 대한 관심이 증가함에 따라 더 제약된 디바이스들에 대한 관리를 제공하고자 시도한다.

LWM2M 프로토콜은 앞서의 OMA DM 및 GwMO프로토콜들의 것들과 다르다. 이것은 더 납작하고 더 단순한 리소스 트리를 가진 제약된 디바이스들에 대해 더 도움이 되는 통신 프로토콜을 사용한다. 데이터 타입들은 단순화되고, 페이로드들은 더 효율적이다. 그 결과, LWM2M 프로토콜은 현재적으로 OMA DM 및 GwMO의 것과 호환적이 아니다.

게다가, OMA DM 프로토콜은 새로운 디바이스 MO들의 추가를 동적으로 지원하기 위한 메커니즘을 결여한다. DDF 문서는 모든 노드들 및 MO 내의 이들의 연관된 기능성을 완전히 정의하고 또한 이들의 제각기 관리 트리들을 구축하기 위해 DM 서버들, DM 게이트웨이들 및 DM 클라이언트들에 의해 이용된다. DM 서버가 그에 대해 어떤 DDF 파일도 가지지 않은 MO를 클라이언트가 포함한다면, DM 서버는 이 MO를 인식할 수 없다. 그러한 메커니즘의 생략은 LWM2M Object 정의들을 OMA DM에 추가하는 능력을 막고 또한 LWM2M을 OMA DM에 상호 연동시키는 것을 더 어렵게 만든다.

게다가, OMA GwMO 프로토콜은 디바이스들이 DM 게이트웨이에 동적으로 등록하기 위한 능력을 결여한다. GwMO는 자신이 게이트웨이 배후에서 관리하는 디바이스들을 추적하기 위한 Device Inventory MO를 가지고 있지만, 이것은 디바이스들이 그것에게 등록하는 데에 이용할 수 있는 인터페이스를 정의하지 않는다. M2M/IoT 디바이스는 플러그 앤 플레이 방식으로 추가될 수 없다 - 먼저 GwMO 내에 공급될 필요가 있다. 최종 사용자들이 게이트웨이와 통신하기 위해 디바이스들를 설치하고 있는 배치 시나리오에서, 플러그 앤 플레이 특징의 결여는 바람직하지 않다.

최종적으로, 프로토콜 번역 메커니즘들은 OMA DM와 OMA LWM2M 프로토콜들 사이의 간격을 메우는 데에 필요하다. 이러한 프로토콜들은 막대한 정도로 상이한 메시징 요건들을 가지고 있고 또한 상이한 시장 부문들에 대해 설계되었다. 커맨드 구조 및 사용이 상이하고 기초적 전송 계층 프로토콜도 상이하다. 이러한 차이들은 가능한 한 끊김 없이 시스템들을 상호 운영하기 위해서 몇몇 잘 정의된 번역 메커니즘들을 요구한다.

앞서 언급한 단점들을 해결하고자, 본 출원은 OMA LWM2M 시스템들이 OMA DM 및 GwMO 시스템들과 상호 운영하도록 허용하는 상호연동 메커니즘(interworking mechanism)들을 기술한다.

본 명세서에 개시된 제1 양태에 따르면, 새로운 DDF(Device Description Framework) MO(Managed Object)가 DM 서버 및 DM 게이트웨이가 LWM2M Objects를 인식하기를 허용하도록 정의된다. 이 MO는 DM 서버/게이트웨이가 LWM2M Object 정의들과 같은 새로 정의된 MO들을 수용하는 것을 허용할 것이다.

본 명세서에 개시된 제2 양태에 따르면, 새로운 DDF Registration 절차들은 새로 정의된 DDF들의 추가 또는 갱신을 동적으로 지원하도록 정의된다. 일단 LWM2M Object가 DDF 포맷으로 변환되면, 결과적 문서는 이후 DM 서버 또는 DM 게이트웨이에 등록될 수 있다. 이 특징은 DM 서버들 및 DM 게이트웨이들이 LWM2M Objects를 DM MO들로서 인식하는 것을 허용한다.

본 명세서에 개시된 제3 양태에 따르면, 새로운 GwMO Registration 절차는 디바이스가 LWM2M 서버를 통하여 DM 게이트웨이에 그 자체를 등록하는 것을 허용하기 위해 정의된다. 새로운 등록 과정은 DM 게이트웨이에 디바이스를 등록하기 위해 LWM2M 디바이스 "등록(register)" 동작을 확장한다. LWM2M 서버가 "등록" 동작을 완료한 후, 이것은 새로운 Registration 절차의 일부로서 DM 게이트웨이에게 자신이 디바이스에 관해 가진 정보를 보낸다. DM 게이트웨이는 다음 차례로 디바이스에 관한 정보에 의해 Device Inventory MO를 갱신한다. 이 특징은 M2M/IoT 디바이스들이 OMA DM 시스템 내로 동적으로 "플러그 앤 플레이"하는 것을 허용한다.

본 명세서에 개시된 제4 양태에 따르면, 프로토콜 번역 메커니즘들은 OMA DM 프로토콜에 LWM2M을 상호 연동하는 것을 지원하도록 정의된다. OMA DM이 RESTful 프로토콜이 아닌 반면, LWM2M은 RESTful이다 - 일부 번역들이 LWM2M을 DM에 연동시키기 위해 요구된다. 게다가, 일부 DM 커맨드들은 커맨드를 처리하기 위해서 상태 정보가 유지될 것을 요구한다 - 이러한 커맨드들은 RESTful 커맨드들로 번역될 필요가 있고 상태 정보는 번역에 도움을 주기 위해 상호연동 기능에 의해 유지된다.

도 6은 또한 설명된 본 출원의 다양한 양태에 의한 그리고 LWM2M 시스템의 오버레이를 가진 OMA GwMO 아키텍처의 일 실시예의 블럭도이다. 도면에 나타낸 바와 같이, 이 실시예에서, OMA DM 서버(601)는 OMA DM 게이트웨이(602)와 통신한다. OMA DM 게이트웨이(602)는 그것의 투명 모드를 통해 몇몇 종단 디바이스들(예를 들어, 모바일 디바이스(604))과 통신할 수 있고, 그것의 프록시 모드를 통해 다른 종단 디바이스들(예를 들어, 컴퓨터(606))과 통신할 수 있다. 게다가, OMA DM 게이트웨이(602)는 그것의 적응 모드를 통해 OMA LWM2M 서버(608)와 통신할 수 있다. LWM2M 서버(608)는 M2M 디바이스들(610a, 610b 및 610c)와 같은, 수많은 전형적으로 제약된 디바이스와 통신하고 또한 이들을 관리한다.

도 6은 본 명세서에서 기술되는 메커니즘들 및 절차들이 예시된 아키텍처상에 오버레이될 수 있는 방법을 추가로 예시한다. 예를 들어, 새롭게 정의된 DDF MO(612)가 OMA DM 서버(601) 및 OMA DM 게이트웨이(602) 양쪽에 저장될 수 있다. 본 명세서에서 기술되는 DDF MO Registration 절차(614)의 양태들은 OMA DM 서버(601)와 OMA DM 게이트웨이(602) 사이에서뿐만 아니라 OMA DM 게이트웨이(602)와 OMA LWM2M 서버(608) 사이에서 수행될 수 있다. 프로토콜 번역 기능/엔티티(616) 및 GwMO Device Registration 절차(620)는 OMA LWM2M 서버(608)와 OMA-DM 게이트웨이(602) 사이에서 수행될 수 있다.

다양한 실시예들에서, LWM2M 서버(608) 및 DM 게이트웨이(602)는 공동으로 자리잡을 수 있거나 또는 이들은 별도로 자리잡을 수 있다. 프로토콜 번역 기능/엔티티(616)는 별개의 엔티티일 수 있거나 또는 이것은 DM 게이트웨이(602) 또는 LWM2M 서버(608)의 일부일 수 있다.

본 명세서에서 기술되는 메커니즘들 및 절차들의 이점은 이들이 M2M 서비스 계층 아키텍처들과의 디바이스 관리 운영들의 수렴을 심화시킨다는 것이다. 작금에, ETSI M2M 및 oneM2M과 같은 아키텍처들은 디바이스 관리를 수행하기 위한 수단으로서 OMA DM를 이미 특정하고 있다. 그러나, 현재 OMA DM 및 GwMO 프로토콜들 내에서의 M2M/IoT 디바이스들의 관리는 완전히 특정되지 않았다. 본 개시 내용에 제시되는 LWM2M 프로토콜 및 메커니즘들 및 절차들의 도입에 의해, M2M/IoT의 관리는 서비스 계층 아키텍처에 의해 완전히 실현될 수 있다. 배치들은 그리고 나서, 예를 들어 DM 서버(601)가 M2M 서버의 일부이고 또한 DM 게이트웨이(602)가 M2M 게이트웨이의 일부인 경우에 이런 향상들의 이점을 취할 수 있다.

종단 디바이스들(604, 606, 또는 610a-c)과 같은 종단 디바이스는, 예를 들어 머신들, 센서들, 가전 기기들, 또는 그와 유사한 것, 이동국, 고정 또는 이동 가입자 유닛, 페이저, PDA(Personal Digital Assistant), 컴퓨터, 이동 전화 또는 스마트폰을 포함하는, M2M 또는 MTC 디바이스와 같은, 무선 네트워크에서 통신할 수 있는 임의의 무선 디바이스, 또는 유선 또는 무선 환경에서 동작할 수 있는 임의의 다른 유형의 디바이스를 포함할 수 있다. 종단 디바이스의 예시적 아키텍처는 도 19c와 관련하여 아래에 기술된다. 본 출원에서, 종단 디바이스들(604, 606 및 610a-c)과 같은 종단 디바이스들은 또한 OMA DM 클라이언트들로서 지칭될 수 있다.

일 실시예에서, OMA DM 서버(601), OMA DM 게이트웨이(602), 프로토콜 번역기(616) 및 OMA LWM2M 서버(608)는 컴퓨팅 시스템 또는 서버의 메모리에 저장되고 또한 해당 컴퓨팅 시스템 또는 서버의 프로세서에 의해 실행되는 컴퓨터-실행가능 명령어들의 형태로 구체화될 수 있는 논리 엔티티들(예를 들어, 소프트웨어)이다. 이러한 논리 엔티티들이 그 상에 구현될 수 있는 예시적 컴퓨팅 시스템 또는 서버는 도19d와 관련하여 아래 기술된다. 다른 실시예들에서, 이러한 엔티티들은 전적으로 하드웨어로 또는 하드웨어 및 소프트웨어의 임의의 조합으로 구현될 수 있다. OMA DM 서버(601), OMA DM 게이트웨이(602), 프로토콜 번역기(616) 및 OMA LWM2M 서버(608)와 같이 도6에 설명된 다양한 네트워크 엔티티들은 도면에서 별개의 컴퓨터 시스템들 또는 서버들로서 예시되지만, 이들 중 임의의 두 개 이상이 단일 컴퓨팅 시스템 또는 서버에서 별개의 논리 엔티티들로서 구체화될 수도 있다는 것이 이해된다.

더욱이, 본 명세서에서 기술되는 DDF MO Registration 절차(614), 프로토콜 번역 기능(616), 및 GwMO Device Registration 절차(620)을 구현하거나 수행하는 OMA DM 서버(601), OMA DM 게이트웨이(602), 및 OMA LWM2M 서버(608)의 기능성이 제각기 서버들(601, 602, 또는 608) 중 어느 한 서버의 또는 다른 컴퓨터 시스템 또는 서버(도시 생략)의 프로세서상에서 실행되는 컴퓨터 판독 가능 명령어들(예로, 소프트웨어)의 형태로, 또는 하드웨어 및 소프트웨어의 어떤 조합으로 구현될 수 있다는 것이 이해된다.

DDF MO (Device Description Framework Managed Object)

OMA DM 프로토콜에서, OMA DDF(Device Description Framework)는 모든 노드들, 이들의 연관된 속성들, 및 관리 오브젝트 내에서의 이들의 값들을 정의한다. 또한 OMA DM 프로토콜에서, DM 서버, DM 게이트웨이들, 및 DM 클라이언트들은 OMA DM 관리 트리의 자신들의 제각기 버전들을 구축하기 위해 DDF에서의 정보를 이용할 수 있다. 전형적으로, DDF 문서들은 대역 외로 이러한 엔티티들에게 제공되고, 이 제공은 실제 동작들 전에 발생한다. 새로 정의된 DDF를 가진 디바이스가 DM 서버의 동작들을 중단시키지 않고서 DM 서버에게 알리고 또한 그 DDF 문서를 업로드하기 위한 메커니즘이 본 명세서에 개시된다.

구체적으로, 새로운 DDF MO(612)가 DM 서버에서의(예를 들어, DM 서버(601)) 그리고 또한 DM 게이트웨이(예를 들어, DM 게이트웨이(602))에서의 사용을 위해 본 명세서에 개시된다. DM 서버에서의 새로운 DDF MO의 사용에 대한 이하의 어떠한 논의도 DM 게이트웨이에서 사용하는 데에 동등하게 적용 가능하고, 그 역으로도 된다는 것이 이해된다.

본 실시예에서, 새로 정의된 DDF MO(612)는 다른 MO들과 동일한 DM 트리에 상주할 수 있고 또한 DM 서버에 의해 지원되는 모든 MO들의 DDF들의 복사본을 유지할 것이다. 다양한 실시예들에서, MO들은 DM 서버에서의 인터페이스 내에서, 웹 서비스 API 인터페이스를 통하여, 또는 DM 클라이언트에 의해 실행되는 새로운 DDF Registration 절차를 통하여 DM 서버에 등록될 수 있다 - 이 모든 방법들은 아래에 추가로 기술된다.

새로운 DDF MO(612)를 위한 구조의 일 실시예가 도 7에 도시된다. 이 실시예에서, 구조는 DM 서버가 MO의 다중 버전을 지원하도록 허용한다. 또한 이 실시예에서, DDF MO는 기동 시의 DM 트리의 DM 서버의 버전에 DDF MO의 구조를 구축하기 위해 DM 서버에 사전 제공될 수 있다. 일 실시예에서, DDF MO는 DM 트리의 루트 노드에 상주할 수 있는데, 그러나 다른 실시예들에서는 이것은 바라는 대로 또 다른 로케이션에 상주할 수 있다.

도 7의 DDF MO의 각각의 노드에 대한 설명이 OMA DM 전문용어를 이용하여 아래 설명된다. 열거되는 모든 URI들은 ./DDFMO URI, 즉, DDF MO에 대한 베이스 URI에 관한 것이다. 이하의 기술에서, “상태”는 노드가 요구될지 또는 선택적인지를 표시하고, "트리 발생"은 얼마나 많은 노드 인스턴스들이 DDF MO에 등장할 수 있는지를 표시하고, "포맷"은 노드에 대한 데이터 포맷을 표시하고, 및 "액세스 유형"은 Get, Add, Copy, 및 Delete와 같이, 노드상에서 실행될 수 있는 동작들을 표시한다.

URI: ./< MoName >

이 플레이스홀더 노드는 그 DDF가 자식 노드들에서 참조되는 MO의 명칭을 포함한다. 예들로는 SCOMO, FUMO, DevInfo, 기타 등등이 있다.

URI: ./< MoName >/< MoVer >

이 플레이스홀더 노드는 그 DDF가 자식 노드들에서 참조되는 MO의 버전을 포함한다. 이 노드의 존재는 DM 서버가 동일 MO의 상이한 버전들, 예를 들어, 버전들 1.0 및 1.1을 지원하도록 허용한다.

URI: ./< MoName >/< MoVer >/ ObjectID

이 리프 노드는 DM 서버가 MO를 식별하기 위해 사용할 수 있는 Object ID를 포함한다. 양호하게는, 이것은 DM 트리 내에서의 고유하게 특정된 ID 이다.

URI: ./< MoName >/< MoVer >/ DdfName

이 리프 노드는 DDF의 명칭을 포함한다.

URI: ./< MoName >/< MoVer >/Description

이 리프 노드는 조상 노드들에서 참조되는 MO 버전의 기술을 포함한다.

URI: ./< MoName >/< MoVer >/Status

이 리프 노드는 노드의 동작의 상태를 포함한다. 조상 노드(<MoVersion>)가 생성될 때, DM 서버는 자동적으로 디폴트 값(0)에 이 노드를 설정한다. 그리고 나서, DM 서버는 클라이언트에 의해 실행되는 동작들에 적절히 의존하여 이 노드를 설정할 것이다. 일 실시예에서, 허용가능 값들은 다음과 같다:

0 - 어떤 DDF도 존재하지 않음 (디폴트): 이것은 어떤 DDF도 존재하지 않음을 특정하는 디폴트 상태이다.

1 - 업로드됨: 이 상태는 DDF가 DM 서버/게이트웨이에 업로드 되었다는 것을 특정한다.

2 - 활성화됨: 이 상태는 MO가 사용을 위해 이용가능하다는 것을 특정한다 - DM 서버/게이트웨이는 업로드된 DDF가 적절히 포맷팅된 것을 입증하였다.

3 - 에러: DDF가 기형이라면, DM 서버는 DDF가 처리될 수 없다는 것을 표시하기 위해 상태 필드를 에러에 설정한다.

4 - 활성화 해제됨: 이 상태를 이전에 활성화된 MO가 이제 활성화 해제된 것을 특정한다. 이 상태에 있을 때, 어떤 새로운 MO도 생성될 수 없으나 기존 MO는 존재할 수 있다. 이 상태는 구 버전의 기능성을 보존하면서 MO의 더 새로운 버전들로 업그레이드하는 데에 사용된다.

URI: ./< MoName >/< MoVer >/ ProtocolName

이 리프 노드는 기초 DDF의 프로토콜 명칭을 포함하고 또한 어느 GwMO 모드를 이용할지를 결정하기 위해 DM 서버/게이트웨이에 의해 이용된다. 허용가능한 값들은 다음과 같다:

0 - OMA DM (디폴트)

1 - OMA LW2MW

URI: ./< MoName >/< MoVer >/ DdfFile

이 리프 노드는 DM 서버에 국지적으로 저장되는 DDF의 실제 파일을 포함한다. 이 노드는 ./<MoName>/<MoVersion>/DdfUri 노드의 것과 상호 배타적이다. 하나만이 한번에 활성이어야 한다.

URI: ./< MoName >/< MoVer >/ DdfUri

이 리프 노드는 DDF 파일이 저장되는 곳의 URI를 포함한다.

URI: ./< MoName >/< MoVer >/Operations

이 내측 노드는 DDF MO에 의해 지원되는 모든 작용들을 위한 부모 노드이다.

URI: ./< MoName >/< MoVer >/Operations/Upload

이 리프 노드는 DDF 파일을 업로드하기 위한 Execute 커맨드를 위한 타깃 노드이다. 상태는 일단 실행 커맨드가 완료되면 DM 서버에 의해 Upload에 설정된다.

URI: ./< MoName >/< MoVer >/Operations/ UploadActivate

이 선택적인 리프 노드는 Execute 커맨드가 DDF 파일을 업로드하고 또한 일단 업로드가 완료되면 그것의 동작들을 활성화하기 위한 타깃 노드이다. 상태는 일단 실행 커맨드가 완료되면 DM 서버에 의해 Activate에 설정된다.

URI: ./< MoName >/< MoVer >/Operations/Activate

이 리프 노드는 Execute 커맨드가 이것이 이미 업로드된 후에 참조된 DDF 파일을 활성화하기 위한 타깃 노드이다. 상태는 일단 실행 커맨드가 완료되면 DM 서버에 의해 Activate에 설정된다.

URI: ./< MoName >/< MoVer >/Operations/ DeActivate

이 리프 노드는 Execute 커맨드가 이것이 동작에 들어간 이후에 참조된 MO를 활성화 해제하기 위한 타깃 노드이다. MO가 활성화 해제될 때, DM 서버는 DDF를 기반으로 한 새로운 MO의 생성을 허용하지 않을 것이지만, 기존의 MO가 동작하는 것을 허용할 것이다. 이 특징은 구 버전들과의 호환성을 유지하면서 MO 버전들을 업그레이드하기 위해 사용된다. 상태는 일단 실행 커맨드가 완료되면 DM 서버에 의해 DeActivate에 설정된다.

URI: ./< MoName >/< MoVer >/Operations/ Ext

이 내측 노드는 DDF MO에게 벤더 특정적인 또는 미래의 OMA DM 확장들을 제공한다.

URI: ./< MoName >/< MoVer >/ Ext

URI: ./< MoName >/ Ext

URI: ./ Ext

DDF MO Registration 절차(614)

일 실시예에 따라서, 일단 DM 서버가 실행되고 있고 또한 앞서 기술된 DDF MO의 노드들이 생성되었다면, 새로운 MO가 추가될 수 있거나 또는 기존 MO가 DM 서버에 자신의 DDF 파일을 등록함으로써 동적으로 갱신될 수 있다. 새로운 MO의 DDF를 등록하기 위한 다중 실시예가 본 명세서에서 기술된다.

제1 실시예에 있어서, 새로운 MO의 DDF 또는 기존 MO에의 갱신를 위한 DDF가 DM 서버 관리자 또는 인증된 사용자에 의해, 예를 들어 DM 서버의 관리 사용자 인터페이스를 이용을 통해 DM 서버에 국지적으로 등록될 수 있다. 이 제1 실시예의 Registration 절차는 현재 MO들이 공급되는 방법과 유사하지만, MO들이 DM 서버의 정상 동작들 동안 동적으로 공급될 수 있다는 점에서 다르다. DM 서버에의 사용자 인터페이스를 이용함을 통해, DM 서버 관리자 또는 심지어 인증된 사용자는 DDF 파일을 DM 서버에 업로드할 수 있다. 이것은 DM 서버가 디바이스드에게 및 그들로부터 진행중인 DM 커맨드들을 처리하고 있음에 따라 행해질 수 있다. 일단 DDF 문서가 업로드된다면, DDF는 활성화될 수 있고 또한 동일 사용자 인터페이스를 통하여 사용 상태에 놓일 수 있다. 활성화 과정 동안, DDF 체커는 이것이 유효한 신택스를 가졌다는 것, 즉 이것이 OMA DM 프로토콜에 의해 특정되는 DDF 파일의 요건들을 준수한다는 것을 보장하기 위하여 새롭게 업로드된 파일에 대하여 실행될 수 있다. DDF 체커가 DDF 문서를 검증한다면, DM 서버는 DDF MO(앞서 기술됨)에서의 새로운 MO를 위한 상태 노드를 Activate에 설정한다; DDF 체크가 DDF 문서에서 에러들을 발견한다면, DM 서버는 상태 노드를 Error에 설정한다.

도 8은 본 명세서에서 기술되는 DDF MO Registration 절차에 의해 DM 서버 내에서 트리거링될 수 있는 처리 단계들의 일 실시예를 설명하는 흐름도이다. 일단 XML 포맷의 DDF 파일이 업로드되었다면, DDF 문서는 단계 802에서 XML 문서를 파싱하기 위해 DDF 판독기에 의해 읽힌다. 그리고 나서, 단계 804에서, DDF를 검증할지에 대한 판정이 이뤄질 수 있다. 그렇지 않다면, 제어는 단계 808로 넘겨지고, 여기서 DDF 문서는, 처리를 위해, (이하에서 "DM 엔진"으로서 지칭되는) OMA DM 프로토콜 기능성 를 구현하는 DM 서버의 소프트웨어 컴포넌트에게 넘겨진다. 검증이 수행될 것이라면, 제어는 단계 806으로 넘겨지며, 여기서 DDF 체커는 적절한 DDF 규칙들/신택스들이 새로운 DDF 파일을 DM 엔진에게 보내기 전에 충족되는지를 검증할 수 있다. 예를 들어, DDF 체커는 그 신택스 및 포맷이 OMA DM 프로토콜 사양의 요건들을 준수하는 것을 보장하기 위해 DDF 문서를 분석할 수 있다. 에러들이 DDF 파일의 포맷에서 검출된다면, 제어는 단계 814로 넘겨지는데, 여기서 DM 서버의 DM 엔진은 ./DDFMO/<MOName>/<MOVer>/Status 노드를 생성하고, 값을 Error 상태에 설정한다. 어떤 에러들도 단계 806에서 검출되지 않고 DDF 파일이 검증되면, 제어는 단계 808로 넘어가고, DDF 파일은 DM 엔진에게 넘겨진다.

단계 810에서, DM 엔진은 새로운 DDF 파일에 의해 표현되는 MO에 대해 도7에 도시되는 대응 DDF MO 노드들을 생성하도록 이후 진행할 것이다. 즉, DM 엔진은 메모리에 각각의 그런 노드들을 구현하는 데이터 구조를 생성할 것이다. 노드들이 생성된 후에, 단계 812에서, DM 엔진은 ./DDFMO/<MOName>/<MOVer>/Status 노드를 Activate 상태에 설정한다.

제2 실시예에 있어서, 새롭거나 갱신된 MO의 DDF는 DM 서버에 의해 제공되는 웹 서비스 API(application programming interface)의 이용을 통해서 DM 서버에 등록될 수 있다. 이 실시예는 비-OMA DM 엔티티들이 더 끊김 없는 상호연동을 제공하기 위해 DM 서버에게 그들의 리소스 트리를 전달하게 허용한다. 이 메커니즘을 이용할 수 있는 비-OMA DM 엔티티의 한 예는 LWM2M 서버이다. 각각의 LWM2M 오브젝트는 DDF 파일로 변환되고 웹 서비스 API를 통하여 DM 서버에 업로드될 수 있다. DDF가 업로드된 후에, 도8의 단계는 상술한 바와 같이 수행된다.

제3 실시예에 있어서, 새롭거나 갱신된 MO의 DDF는 새로운 Registration 절차를 이용하여 DM 프로토콜을 통해 DM 클라이언트 또는 DM 게이트웨이로부터 동적으로 DM 서버에 등록될 수 있다. 이 실시예는 새로운 Register DDF Alert 메시지의 생성에 의해 구현될 수 있다. 현재적으로, DM 클라이언트들은 Alert Code 1201을 가진 Alert 메시지를 이용하여 DM 서버에의 DM 세션을 생성할 수 있다. 이것은 DM 서버와의 DM 세션을 확립하기 위해 "클라이언트 개시된 관리 세션(Client-Initiated Management Session)" 요청을 나타낸다. 이 제3 실시예에서, DM 클라이언트가 업로드할 새로운 DDF 파일을 가지고 있는 것을 나타내는데 사용될 수 있는 추가적 경보 코드가 추가된다. 일 실시예에서, 새로운 Alert 메시지는 다음과 같은 데이터를 포함할 수 있다:

< Meta >/<Type> 성분: 경보 내용들의 미디어 유형을 포함한다. 예시적 값은 " urn:oma:at:oma-ddfmo:registerddf:1.0"일 수 있다.

< Meta >/<Format> 성분: 경보의 포맷을 포함한다. 이 값은 <Source>/<LocURI> 또는 <Item>/<Data> 성분이 제각기 특정되는 지에 의존하여 "chr" 또는 "xml" 일 수 있다.

<Source>/< LocURI > 성분: DDF 파일이 DM 서버에 의해 검색될 수 있는 URI를 포함한다. 일 실시예에서, 이 성분은 <Item>/<Data> 성분과 상호 배타적이다. 어느 하나가 존재하면, 다른 것은 존재하지 않아야 한다.

<Target>/< LocURI > 성분: DDF 파일이 저장되어야 하는 목적지 DM 트리의 타깃 URI를 포함한다.

<Item>/<Data> 성분: <Data></Data> 태그들 내에서 xml 포맷으로 DDF 파일의 내용을 포함한다. 언급된 것처럼, 앞서 언급한 일 실시예에서, 이 성분은 <Source>/<LocURI> 성분과 상호 배타적이다. 어느 하나가 존재하면, 다른 것은 존재하지 않아야 한다.

도 8에 설명된 단계들을 수행하는 DM 서버는, 도 19d에 예시된 컴퓨터 시스템(이하에 기술됨)과 같은 컴퓨터 시스템 또는 네트워크 노드의 메모리에 저장되는 또는 이것의 프로세서상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능 명령어들)의 형태로 구현될 수 있는 논리 엔티티이라는 것이 이해된다. 그리고 도 8에 예시된 방법은 DM 서버의 메모리에 저장되는 소프트웨어(즉, 컴퓨터 실행가능 명령어들)의 형태로 구현될 수 있는데, 이 컴퓨터 실행가능 명령어들은, DM 서버의 프로세서에 의해 실행될 때, 도8에 예시된 단계들을 수행한다. 도 8에 예시된 어떠한 송신 및 수신 단계들도 그 프로세서와 프로세서가 실행하는 컴퓨터 실행가능 명령어들(예로, 소프트웨어)의 제어 하에서 DM 서버의 통신 회로 (예를 들어, 도19d의 회로 97)에 의해 실행될 수 있다는 것이 또한 이해된다.

도 9는 새로운 DDF를 DDF MO에 등록하기 위한 이 제3 실시예의 한 예를 설명하는 호출 흐름이다. 이 예에서, 단계들은 DM 게이트웨이/클라이언트(902) 및 DM 서버(904)에 의해 실행된다. DM 클라이언트는 또한 이 도 9에 요약되는 것과 동일한 방식으로 DM 게이트웨이 또는 DM 서버에의 DDF MO Registration 절차를 수행할 수 있다는 것을 유의하라.

도면에 나타낸 바와 같이, 단계 1에서, DM 게이트웨이는 새로운 DDF 문서를 획득한다. 단계 2에서, DM 게이트웨이는 DM 서버와의 DM 세션을 개시한다. 게다가, 이것은 Register DDF Alert 메시지 및 DDF MO의 UploadActivate 노드상의 Execute 커맨드를 보낸다. 이 실시예에서, DDF 파일의 로케이션에 대한 URI가, DDF 파일 자체의 텍스트를 포함하는 경보 메시지 대신에, Register DDF Alert 메시지에 제공된다는 것이 가정된다.

단계 3에서, DM 서버는 Register DDF Alert 메시지를 수신하고 제공된 URI로부터 DDF 문서를 페치한다. DM 서버는 이후 DDF 체커를 이용하여 DDF 문서를 검증할 수 있다. 검증이 성공적이면, DM 서버는 ./<MoName>/<MoVersion>/Status 노드를 Activate에 설정할 수 있다. 그리고 나서, 단계 4 에서, DM 서버는 Execute 커맨드의 상태를, Registration 절차가 완료된 것의 확인을 위한 Alert와 함께 DM 게이트웨이에게 보낼 수 있다. 단계 5에서, DM 게이트웨이는 등록이 완료된 상태를 보낼 수 있다. 단계 6에서, DM 서버는 클라이언트 상태를 확인응답할 수 있고 DM 세션을 폐쇄할 수 있다.

도 10a는 DDF 파일이 메시지에 내장되는 Register DDF Alert 메시지의 한 예를 보여준다. 도10b는 DDF 파일의 로케이션이 URI에 의해 지정되는 Register DDF Alert 메시지의 또 다른 예를 보여준다.

GwMO Device Registration 절차(620)

OMA GwMO 프로토콜 사양은 DM 게이트웨이가 접속된 종단 디바이스들의 리스트를 게이트웨이에 유지하기 위한 방식을 제공하는 Device Inventory MO를 정의한다. 그러나, 종단 디바이스가 DM 게이트웨이에 등록하는 방법에 대해서는 특정된 어떤 메커니즘도 없다. 본 출원의 또 다른 양태로서, 본 명세서에 개시되는 것은 LWM2M 서버가 종단 디바이스들을 DM 게이트웨이에게 등록하고 또한 DM 게이트웨이에게 디바이스가 지원하는 MO들의 리스트를 제공할 수 있는 새로운 Device Registration 절차(620)이다. 일 실시예에서, 이 Device Registration 절차는 CoAP 리소스 디렉토리(RD), ETSI M2M 서버, 또는 oneM2M CSE(Common Services Entity)와 같은 임의의 비-OMA DM 서버에 적용될 수 있다. 게다가, LWM2M 서버는 DM 게이트웨이 대신에 DM 서버에 직접적으로 통신할 수 있고 또한 동일 기능성들을 DM 게이트웨이로서 제공할 수 있다.

도 11은 새로운 GwMO Device Registration 절차(620)의 일 실시예를 설명하는 호출 흐름이다. 도 11에 설명된 것과 같이, 과정에 수반되는 엔티티들은 LWM2M 클라이언트(906), LWM2M 서버(608), 프로토콜 번역기(616), 및 DM 게이트웨이(602)이다. LWM2M 클라이언트, LWM2M 서버, 및 DM 게이트웨이 엔티티들은 제각기 OMA LWM2M 및 OMA DM 프로토콜 사양에 제시되는 방식으로 구현될 수 있지만, 본 명세서에서 기술되는 새로운 GwMO Device Registration 절차를 구현하기 위해서 필요에 수정될 수 있다. 프로토콜 번역기(616)는 이하에 더욱 상세히 기술되는 새로운 논리 엔티티이다. 도11에서, 프로토콜 번역기(616)는 별개의 엔티티로서 보여진다. 그러나, 다른 실시예들에서, 프로토콜 번역기(616)는 LWM2M 서버(608) 또는 DM 게이트웨이(602)의 일부로서 통합될 수 있다.

도 11을 참조하면, 단계 1에서, LWM2M 클라이언트 (디바이스)(906)는 LWM2M 서버(608)에 등록하고 또한 디바이스가 지원하는 LWM2M 오브젝트들의 리스트를 제공한다. 이 등록 단계는 기존의 OMA LWM2M 프로토콜 사양에 따라서 수행된다.

단계 2b에서, LWM2M 서버는 생성된 메시지로 디바이스에게 응답하고, 단계 2a에서 프로토콜 번역기에게 디바이스에 관한 정보 및 이것의 지원받는 오브젝트들을 포워딩한다. 다른 실시예들에서, LWM2M 서버는 또한 이 단계 동안 DDF 문서들을 제공할 수 있다. 만약 그렇게 하면, 아래 기술된 단계들 6-9는 생략될 수 있다.

단계 3에서, 프로토콜 번역기는 이것 수신하는 정보를 이용하여 Device Registration 요청을 생성한다. 프로토콜 번역기가 디바이스에 의해 지원되는 LWM2M 오브젝트들의 DDF 문서들을 공급받는 다른 실시예들에서, 이것은 또한 Device Registration 요청과 함께 이들을 보낼 수 있다. 다시금, 이것은 아래 기술된 단계들 6-9를 실행하기 위한 필요를 제거할 것이다.

단계 4에서, 프로토콜 번역기는 Device Registration 요청을 DM 게이트웨이에게 보낸다.

단계 5에서, DM 게이트웨이는 자신이 그 DDF MO에서 디바이스에 의해 지원되는 LWM2M 오브젝트들에 대해 MO들을 찾을 수 없다는 것을 발견할 것이다. DDF 문서들이 제공되었다면, 제어는 직접적으로 단계 10으로 넘어갈 것인데, 여기서 DDF 문서가 그에 대해 제공되었던 각각의 새로운 LWM2M 오브젝트에 대해 - 이것은 DM 게이트웨이에 의해 새로운 MO로서 취급될 것임 - DM 게이트웨이는 DDF 문서 및 해당 새로운 LWM2M 오브젝트(즉, 새로운 MO)에 대한 기타 정보를 저장하기 위해 그 DDF MO에 한 세트의 노드들을 생성할 것이다. 이 방식으로, 새로운 오브젝트들 (MO들)은 DM 게이트웨이의 DM 트리에 등록되고 이것에 추가된다. 그러나, DDF 문서들이 Device Registration 요청을 공급받지 못했다면, 제어는 단계 6으로 진행한다.

단계 6에서, DM 게이트웨이는 DDF 문서들에 대한 요청을 프로토콜 번역기에게 보낸다. 단계 7에서, 프로토콜 번역기는 요청을 LWM2M 서버에게 포워딩한다. 단계 8에서, LWM2M 서버는 LWM2M 클라이언트 디바이스의 오브젝트들(즉, MO들)에 대한 DDF 문서들 또는 그런 DDF 문서들에 대한 URI들을 반송함으로써 응답한다.

단계 9에서, 프로토콜 번역기는 Register DDF Alert 메시지를 DM 게이트웨이에게 보낸다. 단계 10에서, DM 게이트웨이는 상술한 바와 같이 그 DDF MO를 갱신하고 등록 과정을 완료한다. 이것은 또한 그 Device Inventory MO를 갱신한다. 단계 11에서, DM 게이트웨이는 LWM2M 서버에게 프로토콜 번역기를 통해 Device Registration 완료 메시지를 보낸다.

도 12는 - OMA GwMO 프로토콜 사양에서 기술된 바와 같이 - Device Inventory MO의 구조이지만 새로운 노드 - SupportedMO(820) 및 그것의 자식 노드들(822, 824)- 를 가진 구조의 일 실시예를 도해하는 도면이다. 이러한 새로운 노드들은 OMA DM 프로토콜 사양의 리스트 MO들의 것과 유사한 방식으로 특정 디바이스가 지원하는 MO(예를 들어, LWM2M 오브젝트)룰 추적하는 데에 사용될 수 있다. Device Inventory MO 내의 SupportedMO 노드(820)의 포함은 적절한 DDF 문서들이 DM 게이트웨이의 DDF MO에 존재하는 것을 보장한다. 문서들이 존재하지 않으면, DM 게이트웨이는 앞서 기술된 Device Registration 절차 동안 LWM2M 서버 또는 프로토콜 번역기가 DDF 문서들을 제공하도록 경보할 수 있다. 일 실시예에서, 노드들은 LWM2M 서버가 DDF MO에서의 DDF 엔트리들을 업로드하고 활성화한 후에 DM 게이트웨이에 의해 파퓰레이팅된다.

이하에 일 실시예에 따라서 새로운 노드들 및 이들의 DFProperties에 대한 기술들이 있다

URI: ./<x>/Inventory/Records/<x>*/SupportedMO

이 내측 노드(820)는 디바이스가 지원하는 모든 MO들의 리스팅에 대한 부모 노드이다.

URI: ./<x>/Inventory/Records/<x>*/SupportedMO/<x>*

이 플레이스홀더 노드(822)는 디바이스가 지원하는 MO들의 명칭을 제공한다.

URI: ./<x>/Inventory/Records/<x>*/SupportedMO/<x>*/MoVerRef

이 리프 노드(824)의 값은 디바이스가 지원하는 DDF의 버전을 가리키는 DM 트리 내에서의 URI의 노드 명칭을 제공한다. 값은 DDF MO에서의 등록된 DDF 파일의 것, 예를 들어 ./DDFMO/<MoName>/<MoVersion>과 매칭되어야만 한다. 그렇지 않다면, DM 게이트웨이는 Device Registration 절차 동안 DDF 문서를 LWM2M 서버 또는 프로토콜 번역기에게 요청할 필요가 있다.

일 실시예에서, 도 11에 설명된 Device Registration 절차는 Register 커맨드로서 본 명세서에서 지칭되는 새로운 DM 커맨드에 의해 구현될 수 있다. 실시예에서, Register 커맨드는 OMA 디바이스 관리 표현 프로토콜, 버전 1.2.1의 Atomic 및 Sequence 커맨드들 양쪽의 속성 요건들을 조합하는데, 이는 DM 게이트웨이가 Register 커맨드 내의 모든 종속적 커맨드들을, 이들이 특정되는 시퀀스로 및 전부 아니면 전무 방식으로 처리하도록 요구 받는다는 것을 의미한다. 이러한 요건들은 디바이스들에 관한 모든 정보가 올바르게 DM 게이트웨이에 입력되는 것을 보장하는 데에 중요할 수 있다. 양호하게는, 수반되는 디바이스들은, 그것이 팩토리 부트스트랩되든 또는 동적으로 부트스트랩되든 간에, DM 게이트웨이와 적절하게 통신하기 위한 자격을 제공받았다.

일 실시예에서, 다음과 같은 정보가 Register 커맨드에 특정될 수 있다:

1. Device Inventory 레코드가 생성되는 타깃 경로, 예를 들어. ./<x>/inventory/Records/<x>이고, 여기서 <x>는 특정된다. 일 실시예에서, 이 아이템은 등록 메시지에서 요구된다.

2. 디바이스 ID 필드 - 일 실시예에서, 이 필드는 디바이스가 DevInfo MO에서 찾아지는 devID를 가지면 특정되어야 한다. 디바이스가 그러한 노드를 가지고 있지 않다면, Register메시지는 이 필드를 포함하지 않을 수 있다 - DM 게이트웨이는 이 필드가 특정되지 않을 때 값을 할당할 수 있다. 도 12의 Device Inventory MO의 DeviceID 노드는, 이것이 Device Registration 절차의 일부로서 제공된다면, 이 값으로 파퓰레이팅된다.

3. 디바이스 유형 필드 - DevDetail MO의 DevType 노드에서 찾아지는 디바이스 유형을 특정한다. 일 실시예에서, 비-OMA DM 디바이스들에 대해, "M2M Device"와 같은 값이 특정될 수 있다. 일 실시예에서, 이 아이템은 등록 메시지에서 요구된다. 도 12의 Device Inventory MO의 DevType 노드는, 이것이 Device Registration 절차의 일부로서 제공된다면 이 값으로 파퓰레이팅된다.

4. 동작 모드 - 디바이스는 자신이 어느 GwMO 동작 모드에서 작동할 수 있는지에 대한 지식을 공급받으면, 이것은 이 필드에 대한 값을 특정할 수 있다. 디바이스가 비-OMA DM 준수성이라면, 일 실시예에서, 이 필드는 4에 설정될 수 있는데, 이는 적응 모드가 사용되는 것을 특정한다. 도 12의 디바이스 인벤토리 MO의 Mode 노드는, 이것이 Device Registration 절차의 일부로서 제공된다면, 이 값으로 파퓰레이팅될 것이다.

Register 커맨드를 수신할 시에, DM 게이트웨이는 Device Registration 메시지의 종속적 Add 커맨드들(예를 들어, 도13a의 예시적인 종속적 Add 커맨드들)에서 찾아지는 특정된 노드들을 생성할 수 있고, 성공적이면 이것은 네트워크 접속성 노드들 LANRef(826), 어드레스 유형(828), 및 Device Inventory MO의 어드레스(830). 이 정보는 DM 게이트웨이에게 알려진다. 즉, DM 게이트웨이는 디바이스들이 연결할 수 있는 다양한 네트워크 접속들(와이파이, 블루투스, 기타 등등)을 (잠재적으로) 제공한다. 이러한 접속 옵션들은 이것이 전개될 때 DM 게이트웨이에 의해 알려진다. Device Inventory MO 트리 (도12를 참조)의 ./<x>/Inventory/LAN 노드 하에서 하나의 엔트리가 각각의 접속성 옵션에 대해 존재한다.

도 13a는 Device Registration 메시지의 한 예를 보여준다. 디바이스 등록 절차 동안, LWM2M 서버 또는 프로토콜 번역기는 지원된 MO가 DM 게이트웨이의 DDF MO에서 찾아지지 않으면 DDF MO Registration 절차를 이용하여 DDF들을 업로드할 수 있다. 일단 Device Registration 절차가 완료되면, DM 게이트웨이는 Device Attach Alert를 DM서버에게 보내어 이것에게 새로운 디바이스가 DM 게이트웨이에 등록하였고 이것이 이제 관리될 수 있다는 것을 알린다.

디바이스가 LWM2M 서버로부터 그 자신을 등록 해제할 때, Device De-Registration 절차는 DM 게이트웨이에게 디바이스가 더 이상 이용가능하지 않다는 것을 알리기 위해 실행될 수 있다. 동일한 Register 커맨드가 보내질 수 있는데, 그러나 Add 커맨드들 대신에 내부의 Delete 커맨드와 함께 그렇게 된다. 이것은 초기 Device Registration 절차에 의해 생성된 레코드 엔트리를 삭제한다. DM 게이트웨이는 다음 차례로 특정된 노드들을 Device Inventory MO로부터 제거할 수 있고 또한 디바이스가 DM 서버에게 Device Detach Alert를 보내어 서버에게 디바이스가 더 이상 관리 받도록 이용가능하지 않다는 것을 알려준다. 등록 해제 메시지의 한 예는 도13b에 도시된다.

프로토콜 번역 상호연동

본 명세서에 개시되는 프로토콜 번역 기능은 OMA DM 프로토콜을 LWM2M 프로토콜로 번역하는데 사용될 수 있고 그 반대로도 된다. 다양한 실시예들에서, 이것은 다음 세 가지 방식 중 하나로 구현될 수 있다: 1) LWM2M 서버 내에서 내부적으로, 2) LWM2M 서버로부터 모든 메시지들을 수신하는 별개의 엔티티에서 외부적으로, 또는 3) DM 게이트웨이의 컴포넌트로서. 제1 구현의 경우에, DM 클라이언트는 LWM2M 서버에 통합될 수 있고 이것은 앞서 설명한 DDF MO Registration 및 Device Registration을 위한 새로운 등록 절차를 지원하도록 갱신될 수 있다. 제2 구현에서, LWM2M 서버는 외부 프로토콜 번역 상호연동 엔티티에게 모든 메시지들을 보낼 수 있고 해당 엔티티가 이 섹션에서 제안된 번역을 수행하게 한다. 제3 구현에 대해, DM 게이트웨이는 LWM2M 메시지들을 수신하는 것을 지원할 수 있고, 또한 DDF MO Registration 및 Device Registration을 위한 새로운 등록 절차들을 지원하도록 갱신될 수 있다.

표 1은 본 명세서에 개시된 프로토콜 번역기의 일 실시예(예를 들어, 도 11에 예시된 프로토콜 번역기)에 따라, OMA DM 커맨드들과 LWM2M 동작들 간의 그리고 LWM2M 동작들로부터 OMA DM 커맨드들로의 프로토콜 번역을 기술한다. 이 번역은 요청자가 누구인지에 의존하여 프로토콜 번역기에 의해 실행될 수 있다. 표 1에서 주목한 대로, 프로토콜 번역기가 Atomic 및 Sequence DM 커맨드들의 번역을 취급하는 방식은 아래에 더 충분하게 기술된다.

추가적 배경으로써, OMA DM 프로토콜은 HTTP/TCP 위에서 동작하고, 따라서 서버와 클라이언트 사이의 세션 지향 통신을 유지하기 위해 TCP 프로토콜에 의존한다. 반면에, OMA LWM2M은 CoAP/UDP 위에서 동작하고, 그 결과 수신인들로부터 확인응답들을 받기 위해 CoAP의 확인 가능한 재전송 메커니즘들을 활용할 필요가 있다. 이는 Atomic 및 Sequence DM 커맨드들을 서비스하는 것에 매우 중요한데, 여기서 한 그룹의 DM 커맨드들이 함께 처리되도록 특정된다.

일찍이 언급된 바와 같이, DM 세션이 OMA DM 프로토콜의 DM 서버와 DM 클라이언트 사이에 생성되어 2개의 엔티티 사이에서 DM 커맨드를 전송한다. 이 관리 세션은 TCP 프로토콜의 맥락 내에서 생성되는데, 이 프로토콜은 2개의 엔드포인트 사이의 신뢰성 있고 정렬된 통신들을 제공하는 접속-지향 프로토콜이다. OMA LWM2M은, 제약된 디바이스들에 적합한 낮은 오버헤드 및 감소된 대기 시간들을 제공하는 무접속 프로토콜인, UDP라고 불리는 더 경량의 전송 계층 프로토콜을 사용한다. 그 결과, 접속-지향 프로토콜과 무접속 프로토콜 간의 갭을 메우기 위한 메커니즘, 및 그 역으로 하는 것이 LWM2M과 OMA DM을 상호연동시킬 때 필요하다.

OMA DM 프로토콜에서, 커맨드들은 단일 커맨드로서 또는 Atomic 또는 Sequence 커맨드 내에 함께 그룹화되어 전송될 수 있다. 각각의 커맨드는 자신을 다른 커맨드들로부터 구분하기 위해 연관된 커맨드 ID(CmdID)를 가지고 있다. 일 실시예에서, 이 CmdID는 단일 커맨드가 보내질 때 OMA DM으로부터 LWM2M로의 번역을 위한 CoAP 토큰으로서 이용될 수 있다. Atomic 및 Sequence 커맨드에 대해, 커맨드들의 그룹을 위한 CmdID 또는 그룹 내의 각각의 커맨드를 위한 별개의 CmdID가 있을 수 있다. 도14는 두 개의 Add 및 하나의 Delete 커맨드들을 포함하는 Sequence 커맨드의 예를 보여준다. Sequence 커맨드는 CmdID를 가지고 있고 Add 및 Delete 커맨드들 각각은 그 자신의 CmdID를 가지고 있다. Atomic 커맨드의 구조는 다중 CmdID를 가진 Sequence 커맨드의 것과 유사하다. 이런 경우들에서, 일 실시예에서, 또한 Atomic 또는 Sequence 커맨드들 내의 커맨드들의 CmdID들은 CoAP 메시지 ID들에 매핑될 수 있는 한편, Atomic 또는 Sequence 커맨드의 CmdID는 토큰에 매핑될 수 있다.

CmdID들을 CoAP 토큰들 및 메시지 ID들에 매핑할 뿐만 아니라, 본 출원의 프로토콜 번역기는 Atomic 커맨드 및 Sequence 커맨드 양쪽의 요건들을 책임진다. Atomic 커맨드들에 대해, 요건은 모든 종속적 커맨드들이 세트로서 실행되고 한 단위로서 성공하거나 실패하는 것이다. 이 요건이 충족되지 않으면, 실행되었던 모든 종속적 커맨드들은 자신들의 이전 상태로 롤백(roll back)할 필요가 있다. 그 결과, 본 명세서에 개시되는 프로토콜 번역 기능은 모든 종속적 커맨드들의 실행 전후에 영향을 받은 노드들의 상태를 추적한다. 임의의 종속적 커맨드가 Atomic 커맨드 내에서 실패하면, 프로토콜 번역기는 모든 이전에 실행된 종속적 커맨드들을 원상태로 돌려야만 한다. 결과적으로, 일 실시예에서, 프로토콜 번역기는 먼저 노드의 상태를 검색하고, 종속적 커맨드를 실행하기 전에 이것을 저장한다.

Sequence 커맨드는 또한 함께 커맨드들을 그룹화하기 위한 능력을 제공하지만 이것은 유일한 요건이 커맨드들이 특정된 순서로 실행된다는 것이라는 점에서 다르다. Atomic 커맨드 내의 종속적 커맨드들은 순서대로 실행된다고 보장되지 않는다. 이 경우에, 일 실시예에서, 프로토콜 번역기는 종속적 커맨드들의 실행 시퀀스를 추적한다.

LWM2M 서버가 DM 서버를 위해 디바이스들로부터 수집되는 데이터를 갖는 Information Reporting 경우들에 대해, LWM2M 서버는 디바이스로부터 DM 게이트웨이에게 수집된 데이터로 LWM2M 오브젝트의 URI를 타깃으로 하는 Generic Alert를 보낼 수 있고, 이것은 이후 메시지를 DM 서버에게 중계할 것이다. 대안적으로, 다른 실시예에서, Alert 노드는 LWM2M 오브젝트의 DDF 파일에 추가될 수 있는데, 그 상에서 LWM2M 서버가 이후 보통의 OMA DM 커맨드들을 실행할 수 있다.

도 15a 및 도 15b는, DM 게이트웨이(602)와 연관되는 제1 텍스트 박스(850)에 도시되는 DM Sequence 커맨드에 대해 본 명세서에서 개시되는 프로토콜 번역기(616)에 의해 수행될 수 있는 프로토콜 번역의 일례를 예시하는 호출 흐름을 함께 포함한다. 이 예에서, 프로토콜 번역기(616) 및 LWM2M 서버(608)가 도면에서 두 개의 별개의 엔티티로서 도시된 것을 유의하라. 그러나, 다른 실시예들에서, 이들은 하나의 엔티티로서 공존할 수 있다.

종속적 커맨드들 Get, Replace, 및 Execute는 프로토콜 번역기에 의해 순서대로 처리되고, 제각기 Read, Write, 및 Execute 동작들로 번역된다. 도시된 대로, LWM2M 동작들에 대해 사용되는 토큰은 모두 개별 종속적 커맨드들이 아니라 Sequence 커맨드의 CmdID에 포인팅한다. 도시된 URI들은 OMA의 LWM2M 기술 사양, 후보 버전 1.0에 따라 프리픽스 “/3”을 가진 LWM2M 디바이스 오브젝트에 대응한다. 번역의 상세 사항들은 다음과 같다.

Sequence CmdID는 프로토콜 번역기와 LWM2M 서버(608) 사이에 이용되는 CoAP 토큰에 매핑된다. 이것은 또한 LWM2M 서버(608)와 LWM2M 클라이언트(906) 사이에 이용된다.

Get /3/0 종속적 커맨드는 Read /3/0 동작에 매핑되는데, 이것은 디바이스상의 /Device/Manufacturer (/3/0) 리소스의 판독을 수행한다.

값 "Open Mobile Alliance"는 /3/0 리소스에 대해 리턴된다.

Replace /3/1 종속적 커맨드는 Write /3/1 동작에 매핑되는데, 이것은 디바이스상에서 /Device/Model Number (/3/1) 리소스에의 기입을 수행한다.

값 "Lightweight M2M Client"는 /3/1 리소스에 기입된다.

Execute /3/4 종속적 커맨드는 Execute /3/4 동작에 매핑되고, 이것은 디바이스의 재부팅을 수행한다.

디바이스가 Execute 동작에 대한 "2.04 Changed" 응답을 리턴한 후에, 프로토콜 번역기는 DM 게이트웨이에 대한 Status 응답을 처리한다.

각각의 DM 커맨드에의 상태가 먼저 주어지고, Get 동작에의 결과가 DM 게이트웨이에 응답하여 이어진다.

GwMO를 이용하여 OMA DM에게 OMA LWM2M을 상호연동함

M2M/IoT 디바이스들의 증가하는 시장으로 인해, 그들을 관리하기 위한 메커니즘을 갖는 것은, 디바이스들이 빌딩들, 교량들, 교통 신호등, 기타 등등과 같은 접근이 어려운 장소들에 전형적으로 배치됨에 따라 점점 더 중요해지고 있다. OMA DM 서비스 제공자들은 DM 서버와 DM 게이트웨이의 백본 기반구조를 제공하고 또한 자신들의 서비스들을 M2M/IoT 서비스 제공자들에게 제공할 수 있고, 이들은 이후 M2M 디바이스들을 제공하고 작동시킨다.

도 16은 동작의 OMA GwMO 적응 모드를 이용을 통하여 LWM2M 시스템과 OMA DM 시스템 사이의 상호연동을 제공하는 시스템(700)의 실시예를 보여준다. 이 실시예에서, LWM2M 시스템은, LWM2M 오브젝트들(714), LWM2M 클라이언트(706)를 포함하는 LWM2M 디바이스(712), 및 LWM2M 서버(708)을 포함한다. OMA DM 시스템은 GwMO 컴포넌트(DM 게이트웨이)(702) 및 DM 서버(704)를 포함한다. 다른 실시예들에서 상술한 바와 같이, DM 게이트웨이(702)와 DM 서버(704) 양자는 새로운 MO들을 등록하기를 허용하기 위해 그 DM 트리의 일부로서 DDF MO - 즉, 본 명세서에서 기술되는 DDF MO(612)-를 호스팅한다. LWM2M 오브젝트들(714)은 앞서 설명한 제안된 DDF MO Registration 절차의 실시예들 중 하나를 이용하여 DDF 포맷으로 변환되고 또한 DM 게이트웨이(702)에게 제공된다. DDF 포맷으로의 LWM2M 오브젝트들의 변환은, 예를 들어 표준 기구에 의해 또는 벤더에 의해 대역 외로 행해질 수 있다. 그러한 변환을 수행하기 위한 한 가지 방식은 LWM2M 오브젝트들을, 1 대 1로 OMA DM MO들에게 매핑하고 데이터 타입 변환들을 해결하는 것이다.

DM 게이트웨이(702)는 다음 차례로 위에서 기술된 새로운 DDF MO Registration 절차(614)를 이용하여 DM 서버(704)에게 LWM2M 오브젝트들(714)을 기술하는 새로운 DDF들을 통지할 것이다. 이러한 절차들은 DM 게이트웨이(702) 및 DM 서버(704)의 양쪽이 그들의 제각기 DM 트리들 내의 LWM2M 오브젝트를 인식하고 또한 이들에 대한 작용들을 지원하도록 허용한다.

일단 LWM2M 오브젝트들(714)이 DDF MO에 추가된다면, LWM2M 서버(708)는 위에서 기술된 새로운 GwMO Device Registration 절차(620)를 이용하여 그것의 데이터베이스에서의 디바이스 정보를 DM 게이트웨이(702)에게 제공할 수 있다. DM 게이트웨이(702)는 이후 경보 OMA GwMO 프로토콜 사양의 Device attach Alert메시지를 이용하여 DM 서버(704)에게 새로운 디바이스들을 경보할 것이다. 이 시점에서, DM 서버(704)는 디바이스들에 관한 모든 정보를 가질 수 있고 OMA DM 프로토콜을 이용하여 디바이스 관리를 수행할 수 있다. Information Reporting 경우들에 대해, 디바이스는 그 측정을 LWM2M 서버(708)에게 보고할 것이고, 이것은 이후 프로토콜 번역기(616)를 통하여 DM 게이트웨이(702)에게 메시지를 포워딩한다. DM 게이트웨이(702)는 OMA DM 프로토콜의 Generic Alert 메시지에서의 디바이스 측정을 DM 서버(704)에게 보낼 수 있다.

도 17a, 17b 및 17c는 도16에 설명된 실시예에 따라서, 더 상세하게 앞서의 프로세스를 설명하는 호출 흐름을 포함한다. 도 17a에 도시된 바와 같이, 단계들 1-2에서, 디바이스(712)상에서 실행되는 LWM2M 클라이언트(706)는 OMA LWM2M 프로토콜 사양에 따라 LWM2M 서버(708)에 등록한다. 단계들 3-6에서, 앞에서 더 상세하게 기술된 새로운 GwMO Device Registration 절차(620)가 수행된다. 단계들 7-8에서, 앞에서 더 상세하게 기술된 새로운 DDF MO Registration 절차(614)가 수행된다. 단계들 9-10에서, DM 게이트웨이(702)는 Device Attach Alert를 DM 서버(704)에게 보낸다.

도 17b를 이제 참조하면, 단계 11-19에서, DM 서버(704)는 Get DevInfo 요청을 수행한다. 단계들 11 및 18은 OMA DM 프로토콜에 따라서 수행되고, 단계들 14-15는 LWM2M 프로토콜에 따라서 수행되고, 및 나머지 단계들은 본 명세서에서 기술되는 상호연동 절차들에 따라서 수행된다.

마지막으로, 도 17c를 참조하면, 단계들 20-24에서, LWM2M 클라이언트(706)는 센서 측정들을 가진 Notify 메시지를 DM 서버(704)에게 보낸다. 단계 20은 LWM2M 프로토콜에 따라서 수행되고, 단계 21-22는 본 명세서에 개시된 상호연동 절차들에 따라서 수행되고, 및 단계 23은 OMA DM 프로토콜에 따라서 수행된다.

앞에서 언급하고 또한 하기에서 기술되는 대로, 도 9, 11, 15a-b 및 17a-c에 설명된 단계를 수행하는 엔티티들은 도19d(아래 기술됨)에 설명된 컴퓨터 시스템과 같은, 네트워크에 접속되는 컴퓨터 시스템 또는 서버의 메모리에 저장되고 또한 이것의 프로세서상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능 명령어들)의 형태로 구현될 수 있다. 더욱이, 도 9, 11, 15a-b 및 17a-c에 설명된 방법(들)은 제각기 엔티티들의 메모리에 저장되는 소프트웨어(즉, 컴퓨터 실행가능 명령어들)의 형태로 구현될 수 있는데, 이 컴퓨터 실행가능 명령어들은 엔티티의 프로세서(예를 들어, 도 19d의 프로세서(91))에 의해 실행될 때 도 9, 11, 15a-b 및 17a-c에 설명된 제각기 단계들을 실행한다. 이러한 도면들에 설명되는 임의의 송신 및 수신 단계들은 엔티티의 프로세서와 이것이 실행하는 컴퓨터 실행가능 명령어들(예를 들어, 소프트웨어)의 제어 하에 제각기 엔티티의 통신 회로(예를 들어, 도19d의 회로 (97))에 의해 실행될 수 있다는 것이 또한 이해된다.

예시적 그래픽 사용자 인터페이스

도 18은, 일 실시예에 따라서, 도6의 DM 서버(601) 또는 DM 게이트웨이(602) 또는 도16의 DM 게이트웨이(702) 또는 DM 서버(704)와 같은, DM 서버 또는 DM 게이트웨이에 의해 표시될 수 있는 그래픽 사용자 인터페이스(950)의 한 예를 보여준다. 그래픽 사용자 인터페이스(950)는, 아래 기술된 것처럼 DM 서버 또는 DM 게이트웨이를 구현하는데 사용될 수 있는 도 19d의 컴퓨터 시스템의 디스플레이(86)와 같은, DM 서버 또는 DM 게이트웨이의 디스플레이상에 표시될 수 있다.

도면에 나타낸 바와 같이, 그래픽 사용자 인터페이스(950)는 사용자(예를 들어, 네트워크 관리자)에게 DM 프로토콜로의 LWM2M 프로토콜의 통합을 표시하는데 사용될 수 있다. 도시된 실시예에서, 그래픽 사용자 인터페이스는 서버/게이트웨이에 의해 지원되는 Management Objects(MO)의 리스트를 표시하는 제1 윈도(952)를 포함할 수 있는 데, 이 리스트는 앞에서 기술된 방법들에 따라서, OMA DM MO들뿐만 아니라 LWM2M Objects 양쪽을 포함할 수 있다. 서버/게이트웨이에 의해 관리되는 디바이스들은 인터페이스(950)의 윈도(954)에 표시될 수 있다. 또한 이 실시예에서, 또 다른 윈도(956)가 (윈도(954)에서의 리스트에서 선택된) 선택된 디바이스들에 대한 리소스 트리를 표시할 수 있고, 이 디바이스는 본 명세서에 개시된 원리에 따라서 LWM2M 디바이스를 포함할 수 있다.

예시적 M2M / IoT / WoT 시스템

도 19a는 하나 이상의 개시된 실시예가 구현될 수 있는, M2M, IoT 또는 WoT(Web of things) 통신 시스템(10)의 도면이다. 일반적으로, M2M 기술들은 IoT/WoT을 위한 빌딩 블럭들을 제공하고, 임의의 M2M 디바이스, 게이트웨이 또는 서비스 플랫폼은 IoT/WoT의 컴포넌트는 물론이고 IoT/WoT 서비스 계층, 기타 등등일 수 있다.

도 19a에 보여진 바와 같이, M2M/IoT/WoT 통신 시스템(10)은 통신 네트워크(12)를 포함한다. 통신 네트워크(12)는 고정형 네트워크(예를 들어, 이더넷, 파이버, ISDN, PLC, 또는 이와 유사한 것) 또는 무선 네트워크(예를 들어, WLAN, 셀 방식, 또는 이와 유사한 것) 또는 이종 네트워크들의 네트워크일 수 있다. 예를 들어, 통신 네트워크(12)는 음성, 데이터, 비디오, 메시징, 브로드캐스트, 또는 다른 유사한 것과 같은 콘텐츠를 다중 사용자에게 제공하는 다중 액세스 네트워크로 구성될 수 있다. 예를 들어, 통신 네트워크(12)는 CDMA(code division multiple access), TDMA(time division multiple access), FDMA(frequency division multiple access), OFDMA(orthogonal FDMA), SC-FDMA(single-carrier FDMA), 및 다른 유사한 것과 같은 하나 이상의 채널 액세스 방법을 채택할 수 있다. 또한, 통신 네트워크(12)는 예를 들어 코어 네트워크, 인터넷, 센서 네트워크, 산업용 제어 네트워크, 개인 영역 네트워크, 융합 개인 네트워크(fused personal network), 위성 네트워크, 홈 네트워크, 또는 엔터프라이즈 네트워크와 같은 다른 네트워크들을 포함할 수 있다.

도 19a에 도시된 바와 같이, M2M/IoT/WoT 통신 시스템(10)은 인프라스트럭처 도메인 및 필드 도메인을 포함할 수 있다. 인프라스트럭처 도메인은 종단 대 종단 M2M 전개의 네트워크 측을 지칭하고, 필드 도메인은 보통은 M2M 게이트웨이의 배후에 있는 영역 네트워크들을 지칭한다. 예를 들어, 필드 도메인은 M2M 게이트웨이들(14) 및 단말 디바이스들(18)을 포함한다. 임의의 수의 M2M 게이트웨이 디바이스들(14)과 M2M 단말 디바이스들(18)이 원하는 바에 따라 M2M/IoT/WoT 통신 시스템(10)에 포함될 수 있다는 점을 알 것이다. M2M 게이트웨이 디바이스들(14) 및 M2M 단말 디바이스들(18) 각각은 통신 네트워크(12) 또는 직접 무선 링크를 통해 신호들을 송신 및 수신하도록 구성된다. M2M 게이트웨이 디바이스(14)는 무선 M2M 디바이스들(예컨대, 셀 방식 및 비-셀 방식)뿐만 아니라 고정형 네트워크 M2M 디바이스들(예컨대, PLC)도 통신 네트워크(12) 또는 직접 라디오 링크와 같은 운영자 네트워크들을 통해서도 통신하도록 한다. 예를 들어, M2M 디바이스들(18)은 통신 네트워크(12) 또는 직접 무선 링크를 통해 데이터를 수집할 수 있고, M2M 애플리케이션(20) 또는 M2M 디바이스들(18)에게 데이터를 보낼 수 있다. M2M 디바이스들(18)은 또한 M2M 애플리케이션(20) 또는 M2M 디바이스(18)로부터 데이터를 수신할 수 있다. 또한, 데이터 및 신호들은 아래 기술되는 것처럼 M2M 서비스 계층(22)을 통해 M2M 애플리케이션(20)에 송신될 수 있고 및 그로부터 수신될 수 있다. M2M 디바이스들(18) 및 게이트웨이들(14)은, 예를 들어, 셀 방식, WLAN, WPAN(예를 들어, 지그비(Zigbee), 6LoWPAN, 블루투스(Bluetooth)), 직접 무선 링크, 및 유선을 포함하는 다양한 네트워크들을 통해 통신할 수 있다.

도 19b를 참조하면, 필드 도메인에서의 예시된 M2M 서비스 계층(22)은 M2M 애플리케이션(20), M2M 게이트웨이 디바이스들(14), 및 M2M 단말 디바이스들(18) 및 통신 네트워크(12)에 대한 서비스들을 제공한다. M2M 서비스 계층(22)은 원하는 대로 M2M(20), M2M 게이트웨이 디바이스들(14), M2M 단말기 디바이스들(18), 및 통신 네트워크들(12) 중 임의의 수의 것들과 통신할 수 있음이 이해될 것이다. M2M 서비스 계층(22)은 하나 이상의 서버, 컴퓨터들 또는 도19d에 설명되고 아래 기술되는 컴퓨터 시스템과 같은 그와 유사한 것에 의해 구현될 수 있다. M2M 서비스 계층(22)은 M2M 단말 디바이스들(18), M2M 게이트웨이 디바이스들(14) 및 M2M 애플리케이션들(20)에 적용되는 서비스 능력들을 제공한다. M2M 서비스 계층(22)의 기능들은, 예를 들어, 웹 서버로서, 셀 방식 코어 네트워크에서, 클라우드에서, 또는 그와 유사한 것에서 다양한 방식으로 구현될 수 있다.

예시된 M2M 서비스 계층(22)과 유사하게, 인프라스트럭처 도메인에 M2M 서비스 계층(22')이 있다. M2M 서비스 계층(22')은 인프라스트럭처 도메인에서 M2M 애플리케이션(20') 및 기초 통신 네트워크(12')를 위한 서비스들을 제공한다. M2M 서비스 계층(22')은 또한 필드 도메인에서 M2M 게이트웨이 디바이스들(14) 및 M2M 단말 디바이스들(18)에 대한 서비스들을 제공한다. M2M 서비스 계층(22')은 M2M 애플리케이션들, M2M 게이트웨이 디바이스들 및 M2M 단말 디바이스들 중 임의 수의 것들과 통신할 수 있다는 것을 이해할 것이다. M2M 서비스 계층(22')은 상이한 서비스 제공자에 의해 서비스 계층과 상호 작용할 수 있다. M2M 서비스 계층(22')은 하나 이상의 서버, 컴퓨터들, 또는 가상 머신들(예를 들어, 클라우드/컴퓨트/스토리지 팜들, 기타 등등) 또는 이와 유사한 것에 의해 구현될 수 있다.

여전히 도 19b를 참조하면, M2M 서비스 계층(22 및 22')은 다양한 애플리케이션들 및 버티컬들이 레버리지할 수 있는 서비스 전달 능력들의 핵심 세트를 제공한다. 이들 서비스 능력들은 M2M 애플리케이션들(20, 20')이 디바이스들과 상호작용하고 또한 데이터 수집, 데이터 분석, 디바이스 관리, 보안, 과금, 서비스/디바이스 발견 등과 같은 기능을 수행하는 것을 가능하게 한다. 본질적으로, 이러한 서비스 능력들은 이러한 기능성들을 구현해야 하는 애플리케이션들의 부담을 없애고, 따라서 애플리케이션 개발을 간단화하고 마케팅하기 위한 비용 및 시간을 줄인다. 서비스 계층(22 및 22')은 또한 M2M 애플리케이션들(20 및 20')이 서비스 계층(22 및 22')이 제공하는 서비스들과 관련하여 (네트워크(12)와 같은) 다양한 네트워크들을 통해 통신하는 것을 가능하게 한다.

일반적으로, 서비스 계층들(22 및 22')은 API들 및 기본 네트워킹 인터페이스들의 세트를 통해 부가가치 서비스 능력들을 지원하는 소프트웨어 미들웨어 계층을 정의한다. ETSI M2M과 oneM2M 아키텍처들 양쪽 모두는 서비스 계층을 정의한다. ETSI M2M의 서비스 계층은 SCL(Service Capability Layer)이라고 지칭된다. SCL은 M2M 디바이스(여기서 이것은 DSCL(Device SCL)이라고 지칭됨), 게이트웨이(여기서 이것은 GSCL(gateway SCL)이라고 지칭됨) 및/또는 네트워크 노드(여기서 이것은 NSCL(network SCL)이라고 지칭됨) 내에 구현될 수 있다. oneM2M 서비스 계층은 한 세트의 상용 서비스 기능들(CSF들: Common Service Functions)(즉, 서비스 능력들)을 지원한다. CSF들 중의 한 세트의 하나 이상의 특정 타입의 인스턴스 생성은 상이한 타입들의 네트워크 노드들(예를 들어, 인프라스트럭처 노드, 미들 노드, 애플리케이션 특정적 노드)상에서 호스팅될 수 있는 CSE(Common Services Entity)로서 지칭될 수 있다.

M2M 애플리케이션들(20 및 20')은, 예컨대 제한 없이, 수송, 건강 및 건강관리, 접속된 홈, 에너지 관리, 자산 추적, 및 보안과 감시 등과 같은 다양한 산업들에서의 응용들을 포함할 수 있다. 앞서 언급한 바와 같이, 시스템의 디바이스들, 게이트웨이들, 및 다른 서버들에 걸쳐 실행되는 M2M 서비스 계층은, 예를 들어, 데이터 수집, 디바이스 관리, 보안, 과금, 위치 추적 트래킹/지오펜싱(tracking/geofencing), 디바이스/서비스 발견, 및 레거시 시스템들 통합과 같은 기능들을 지원하고, 이러한 기능들을 서비스들로서 M2M 애플리케이션들(20 및 20')에 제공한다.

새로운 DDF MO(612), DDF MO Registration 절차(614), GwMO Device Registration 절차(620), 및 프로토콜 번역 기능(616)이, 예를 들어 ETSI M2M 또는 oneM2M 아키텍처들에 의해 정의되는 서비스 계층들을 포함하여, 도 19b에 도시되는 서비스 계층들(22 및 22')과 같은, 서비스 계층에 대한 디바이스 관리 솔루션의 일부로서 활용될 수 있다. 그러한 서비스 계층은, 서비스 계층이 자신이 관리하기를 원하는 M2M 디바이스들에 대해 알 것이므로, DDF 들록 및 GwMO 디바이스 등록 절차들(614, 620)을 개시할 수 있다. 본 명세서에서 기술되는 절차들 및 기능은 DM 서버(위에서 기술된 절차들을 수행하기 위해 수정됨)가 M2M 서버의 일부이고 또한 DM 게이트웨이 (위에서 기술된 절차들을 수행하기 위해 수정됨)가 M2M 게이트웨이의 일부인 전개들에서 도움을 준다.

도 19c는 도 6의 종단 디바이스들(604, 606 또는 610a-c)과 같은 예시적 종단 디바이스(30), 도 16의 LWM2M 디바이스(712), 및 도 19a 및 19b의 M2M 디바이스들(18) 및 게이트웨이들(14)의 도면이다. 앞서 언급한 대로, 종단 디바이스는, 예를 들어 머신들, 센서들, 기기들, 또는 그와 유사한 것, 이동국, 고정 또는 이동 가입자 유닛, 페이저, PDA(Personal Digital Assistant), 컴퓨터, 이동 전화 또는 스마트폰, 또는 유선 또는 무선 환경에서 동작할 수 있는 임의의 다른 유형의 디바이스를 포함하는, M2M 디바이스, MTC 디바이스, 또는 LWM2M 디바이스와 같이, 무선 네트워크에서 통신할 수 있는 임의의 디바이스를 포함할 수 있다. 도 19c에 도시된 바와 같이, 종단 디바이스(30)는 프로세서(32), 송수신기(34), 송신/수신 요소(36), 스피커/마이크로폰(38), 키패드(40), 디스플레이/터치패드(42), 비이동식 메모리(44), 이동식 메모리(46), 전원(48), GPS(global positioning system) 칩셋(50), 및 다른 주변 기기들(52)을 포함할 수 있다. 종단 디바이스(30)는 실시예와 부합하도록 남아 있으면서 전술한 요소들의 임의의 하위 조합을 포함할 수 있다는 것을 알 것이다.

프로세서(32)는 범용 프로세서, 특수 목적 프로세서, 종래의 프로세서, 디지털 신호 프로세서(DSP), 복수의 마이크로프로세서, DSP 코어와 연관되는 하나 이상의 마이크로프로세서, 제어기, 마이크로컨트롤러, ASIC(Application Specific Integrated Circuit)들, FPGA(Field Programmable Gate Array) 회로들, 임의의 다른 유형의 집적 회로(IC), 상태 머신, 및 다른 유사한 것일 수 있다. 프로세서(32)는 신호 코딩, 데이터 처리, 전력 제어, 입/출력 처리, 및/또는 종단 디바이스(30)가 무선 환경에서 동작할 수 있게 하는 임의의 다른 기능성을 수행할 수 있다. 프로세서(32)는 송신/수신 요소(36)에 결합될 수 있는 송수신기(34)에 결합될 수 있다. 도 19c가 프로세서(32)와 송수신기(34)를 별도의 컴포넌트들로서 묘사하고 있지만, 프로세서(32)와 송수신기(34)는 전자 패키지 또는 칩에 함께 통합될 수 있다는 것을 알 것이다. 프로세서(32)는 애플리케이션 계층 프로그램들, 예를 들어, 브라우저들, 및/또는 RAN(radio access-layer) 프로그램들 및/또는 통신을 수행할 수 있다. 프로세서(32)는 예를 들어, 액세스 계층 및/또는 애플리케이션 계층에서 그런 것처럼, 인증, 보안 키 일치, 및/또는 암호화 연산들과 같은 보안 동작들을 수행할 수 있다. 프로세서(32)는 디바이스(30)상에서 DM 클라이언트 또는 LWM2M 클라이언트의 기능성을 구현하는 컴퓨터 실행가능 명령어들을 실행할 수 있다.

송신/수신 요소(36)는 또 다른 피어(peer)에게 신호들을 송신하거나 그로부터 신호들을 수신하도록 구성될 수 있다. 예를 들어, 실시예에서, 송신/수신 요소(36)는 RF 신호들을 송신하고 및/또는 수신하도록 구성되는 안테나일 수 있다. 송신/수신 요소(36)는 WLAN, WPAN, 셀 방식, 및 기타 유사한 것과 같은, 다양한 네트워크들 및 에어 인터페이스들을 지원할 수 있다. 실시예에서, 송신/수신 요소(36)는, 예를 들어 IR, UV, 또는 가시광 신호들을 송신 및/또는 수신하도록 구성되는 방출기/검출기일 수 있다. 또 다른 실시예에서, 송신/수신 요소(36)는 RF 신호 및 광 신호 양쪽 모두를 송신 및 수신하도록 구성될 수 있다. 송신/수신 요소(36)는 무선 또는 유선 신호들의 임의의 조합을 송신 및/또는 수신하도록 구성될 수 있다는 것을 알 것이다.

또한, 송신/수신 요소(36)가 단일 요소로서 도 19c에 도시되지만, 종단 디바이스(30)는 임의의 수의 송신/수신 요소들(36)을 포함할 수 있다. 보다 구체적으로, 종단 디바이스(30)는 MIMO 기술을 채택할 수 있다. 따라서, 실시예에서, 종단 디바이스(30)는 무선 신호들을 송신 및 수신하기 위한 2개 이상의 송신/수신 요소(36), 예를 들어, 다중 안테나를 포함할 수 있다.

송수신기(34)는 송신/수신 요소(36)에 의해 송신될 신호들을 변조하고, 송신/수신 요소(36)에 의해 수신되는 신호들을 복조하도록 구성될 수 있다. 전술한 바와 같이, 종단 디바이스(30)는 다중 모드 능력을 가질 수 있다. 따라서, 송수신기(34)는, 종단 디바이스(30)가, 예를 들어, UTRA 및 IEEE 802.11 또는 802.15와 같은 다중 RAT를 통해 통신할 수 있게 하기 위한 다중 송수신기를 포함할 수 있다.

프로세서(32)는 비이동식 메모리(44) 및/또는 이동식 메모리(46)와 같은 임의의 유형의 적합한 메모리로부터 정보에 액세스하거나 거기에 데이터를 저장할 수 있다. 비이동식 메모리(44)는 RAM(random-access memory), ROM(read-only memory), 하드 디스크, 또는 임의의 다른 유형의 메모리 저장 디바이스를 포함할 수 있다. 이동식 메모리(46)는 SIM(subscriber identity module) 카드, 메모리 스틱, SD(secure digital) 메모리 카드, 및 다른 유사한 것을 포함할 수 있다. 기타 실시예들에서, 프로세서(32)는 서버 또는 가정용 컴퓨터상에서와 같이, 종단 디바이스(30)상에 물리적으로 자리잡지 않은 메모리로부터 정보에 액세스할 수 있고, 거기에 데이터를 저장할 수 있다.

프로세서(32)는 전력원(48)으로부터 전력을 수신할 수 있고, 종단 디바이스(30)의 다른 컴포넌트들에게 전력을 분배하고 및/또는 제어하도록 구성될 수 있다. 전력원(48)은 종단 디바이스(30)에 전력을 공급하기 위한 임의의 적합한 디바이스일 수 있다. 예를 들어, 전력원(48)은 하나 이상의 건전지 배터리(예를 들어, 니켈-카드뮴(NiCd), 니켈-아연(NiZn), 니켈 금속 수소화물(NiMH), 리튬-이온(Li-ion), 기타 등등), 태양 전지들, 연료 전지들, 및 다른 유사한 것을 포함할 수 있다.

프로세서(32)는 또한 GPS 칩셋(50)에 결합될 수 있으며, 이것은 종단 디바이스(30)의 현재 로케이션에 관한 로케이션 정보, 예를 들어 경도 및 위도를 제공하도록 구성된다. 종단 디바이스(30)는 실시예에 부합하게 남아 있으면서, 임의의 적합한 로케이션-결정 방법에 의해 로케이션 정보를 취득할 수 있다는 점을 알 것이다.

프로세서(32)는 다른 주변기기들(52)에 추가로 결합될 수 있는데, 이러한 주변기기들은, 추가적인 특징들, 기능성, 및/또는 유선 또는 무선 접속성을 제공하는 하나 이상의 소프트웨어 및/또는 하드웨어 모듈들을 포함할 수 있다. 예를 들어, 주변기기들(52)은 가속도계, e-컴퍼스, 위성 송수신기, 센서, (사진 또는 비디오를 위한) 디지털 카메라, USB(universal serial bus) 포트, 진동 디바이스, 텔레비전 송수신기, 핸즈프리 헤드셋, 블루투스® 모듈, FM(frequency modulated) 라디오 유닛, 디지털 뮤직 플레이어, 미디어 플레이어, 비디오 게임 플레이어 모듈, 인터넷 브라우저, 및 기타 유사한 것을 포함할 수 있다.

도 19d는, 예를 들어, DM 서버, DM 게이트웨이, LWM2M 서버, 프로토콜 번역기, M2M 디바이스, M2M 게이트웨이, M2M 서비스 계층 또는 그와 유사한 것을 포함하여, 도 6, 9, 11, 15a-b, 16, 17a-c에 설명된 논리 엔티티들, 또는 도 19a-b의 것 중 임의의 것을 구현하는데 사용될 수 있는 컴퓨터 시스템 또는 서버(90)의 블럭도이다. 도 19d의 컴퓨터 시스템 또는 서버(90)는, 그러한 소프웨어가 어디에 저장되고 또는 어떤 수단에 의해 액세스되든지 간에, 소프트웨어 형태일 수 있는 컴퓨터 판독가능 명령어들에 의해, 주로 제어될 수 있다. 이러한 컴퓨터 판독가능 명령어들은, CPU(91)와 같은 프로세서 내에서 실행되어, 컴퓨터 시스템(90)으로 하여금 작업을 수행하게 할 수 있다. 많은 공지된 워크스테이션, 서버, 및 개인용 컴퓨터에서, CPU(91)는 마이크로프로세서로 불리는 단일-칩 CPU에 의해 구현된다. 다른 머신들에서, CPU(91)는 다중 프로세서를 포함할 수 있다. 보조 프로세서(81)는 추가적인 기능들을 수행하거나 CPU(91)를 보조하는, 주 CPU(91)와는 별개인 선택적 프로세서이다. CPU(91) 및/또는 보조프로세서(81)는, P2P 통신과 연계하여 데이터를 수신, 생성, 및 처리할 수 있다.

동작에 있어서, CPU(91)는 명령어들을 페치, 디코딩, 및 실행하고, 컴퓨터의 주 데이터 전송 경로인 시스템 버스(80)를 통해 다른 리소스들로 및 이로부터 정보를 전송한다. 이러한 시스템 버스는 종단 디바이스(90) 내의 컴포넌트들을 연결하고 데이터 교환을 위한 매체를 정의한다. 시스템 버스(80)는 전형적으로 데이터를 송신하기 위한 데이터 라인, 어드레스들을 송신하기 위한 어드레스 라인, 및 인터럽트들을 송신하기 위한 및 시스템 버스를 동작시키기 위한 제어 라인들을 포함한다. 이러한 시스템 버스(80)의 예는 PCI(Peripheral Component Interconnect) 버스이다.

시스템 버스(80)에 결합되는 메모리 디바이스들은 RAM(random access memory)(82) 및 ROM(read only memory)(93)을 포함한다. 이러한 메모리들은 정보의 저장 및 검색을 허용하는 회로를 포함한다. ROM들(93)은 일반적으로 쉽게 수정될 수 없는 저장된 데이터를 포함한다. RAM(82)에 저장되는 데이터는 CPU(91) 또는 다른 하드웨어 디바이스들에 의해 판독 또는 변경될 수 있다. RAM(82) 및/또는 ROM(93)에의 액세스는 메모리 제어기(92)에 의해 제어될 수 있다. 메모리 제어기(92)는 명령어들이 실행됨에 따라 가상 어드레스들을 물리 주소들로 번역하는 어드레스 번역 기능을 제공할 수 있다. 메모리 제어기(92)는 또한 시스템 내의 프로세스들을 분리하고 시스템 프로세스들을 사용자 프로세스들과 분리하는 메모리 보호 기능을 제공할 수 있다. 따라서, 제1 모드에서 실행하는 프로그램은 그 자신의 프로세스 가상 어드레스 공간에 의해 매핑되는 메모리에만 액세스할 수 있고; 그 프로그램은 프로세스들 간에 메모리 공유가 설정되지 않았다면 또 다른 프로세스의 가상 주소 공간 내의 메모리에 액세스할 수 없다.

또한, 컴퓨팅 시스템 또는 서버(90)는 CPU(91)로부터 프린터(94), 키보드(84), 마우스(95), 및 디스크 드라이브(85)와 같은 주변기기들로 명령어들을 전달할 책임이 있는 주변기기 제어기(83)를 포함할 수 있다.

디스플레이 제어기(96)에 의해 제어되는 디스플레이(86)는 컴퓨터 시스템 또는 서버(90)에 의해 발생되는 디스플레이 비주얼 출력을 표시하는 데에 이용된다. 이러한 비주얼 출력은 텍스트, 그래픽, 애니메이션 그래픽, 및 비디오를 포함할 수 있다. 디스플레이(86)는 CRT 기반 비디오 디스플레이, LCD 기반 평판 디스플레이, 가스 플라즈마 기반 평판 디스플레이, 또는 터치 패널로 구현될 수 있다. 디스플레이 제어기(96)는 디스플레이(86)에게 보내지는 비디오 신호를 발생하기 위하여 요구되는 전자 컴포넌트들을 포함한다. 또한, 컴퓨터 시스템 또는 서버(90)는 외부 통신 네트워크에 컴퓨터 시스템 또는 서버(90)를 접속하는데 사용될 수 있는 네트워크 어댑터(97)를 포함할 수 있다.

DDF MO Registration 절차(614), GwMO Device Registration 절차(620), 및 프로토콜 번역 기능(616)을 포함하여, 본 명세서에서 기술되는 시스템들, 방법들 및 프로세서들 중 임의의 것 또는 모든 것은 컴퓨터 판독가능 저장 매체상에 저장되는 컴퓨터 실행가능 명령어들, 예를 들어, 프로그램 코드의 형태로 구체화될 수 있는데, 이 명령어들은 컴퓨터, 서버, 종단 디바이스, 프로세서, 또는 그와 유사한 것과 같은 머신에 의해 실행될 때 본 명세서에서 기술되는 시스템들, 방법들, 및 프로세스들을 수행하고 및/또는 구현한다는 것이 이해된다. 구체적으로는, 본 명세서에서 설명된 단계들, 동작들 또는 기능들 중 임의의 것은 이러한 컴퓨터 실행가능 명령어의 형태로 구현될 수 있다. 컴퓨터 판독가능 저장 매체는 정보의 저장을 위한 임의의 방법 또는 기술로 구현되는 휘발성 및 비휘발성, 이동식 및 비이동식 매체를 포함하지만, 그러한 컴퓨터 판독가능 저장 매체는 신호들을 포함하지는 않는다. 컴퓨터 판독가능 저장 매체는, 다음의 것들로 한정되는 것은 아니지만, RAM, ROM, EEPROM, 플래시 메모리 또는 다른 메모리 기술, CD-ROM, DVD(digital versatile disks) 또는 다른 광학 디스크 스토리지, 자기 카세트, 자기 테이프, 자기 디스크 스토리지, 또는 다른 자기 저장 디바이스, 또는 원하는 정보를 저장하는데 사용될 수 있고 또한 컴퓨터에 의해 액세스될 수 있는 임의의 다른 물리적인 매체를 포함한다.

Claims

프로세서 및 메모리를 포함하는 디바이스 관리 서버로서, 상기 메모리는 컴퓨터 실행가능 명령어를 저장하고, 상기 컴퓨터 실행가능 명령어는, 상기 프로세서에 의해 실행될 때, 상기 디바이스 관리 서버로 하여금:
상기 디바이스 관리 서버의 메모리에, 상기 디바이스 관리 서버에 의해 지원되는 복수의 다른 관리된 오브젝트 각각에 대해, 해당 다른 관리된 오브젝트에 대한 디바이스 기술 프레임워크 문서의 복사본을 저장하는 디바이스 기술 프레임워크 관리된 오브젝트를 유지하고;
새로운 관리된 오브젝트를 상기 디바이스 관리 서버에 등록하라는 요청을 수신하고- 상기 요청은 상기 새로운 관리된 오브젝트에 대한 디바이스 기술 프레임워크 문서를 포함함-; 및
상기 요청에 응답하여, 상기 디바이스 관리 서버에 의해 유지되는 상기 디바이스 기술 프레임워크 관리된 오브젝트에 상기 새로운 관리된 오브젝트에 대한 상기 디바이스 기술 프레임워크 문서를 추가하도록 야기하는
디바이스 관리 서버.
제1항에 있어서, 상기 컴퓨터 실행가능 명령어들은 상기 디바이스 관리 서버로 하여금, 상기 새로운 관리된 오브젝트의 상기 디바이스 기술 프레임워크 문서를 상기 디바이스 기술 프레임워크 관리된 오브젝트에 추가하기 전에 상기 새로운 관리된 오브젝트의 상기 디바이스 기술 프레임워크 문서의 포맷을 검증하도록 야기하는
디바이스 관리 서버.
제1항에 있어서, 상기 디바이스 기술 프레임워크 관리된 오브젝트는, 상기 디바이스 관리 서버에 의해 지원되는 상기 다른 관리된 오브젝트들 각각에 대해, 상기 다른 관리된 오브젝트에 관한 정보를 포함하는 한 세트의 노드들을 포함하고, 상기 노드들 중 하나는 해당 다른 관리된 오브젝트에 대한 상기 디바이스 기술 프레임워크 문서의 복사본을 홀드(hold)하는
디바이스 관리 서버.
제1항에 있어서, 상기 디바이스 기술 프레임워크 관리된 오브젝트에 상기 새로운 관리된 오브젝트에 대한 상기 디바이스 기술 프레임워크 문서를 추가하는 것은:
상기 새로운 관리된 오브젝트에 대한 상기 디바이스 기술 프레임워크 관리된 오브젝트에 한 세트의 노드들을 생성하는 것; 및
상기 세트 중 하나의 노드에 상기 새로운 관리된 오브젝트에 대한 상기 디바이스 기술 프레임워크 문서의 복사본을 저장하는 것을 포함하는
디바이스 관리 서버.
제1항에 있어서, 상기 디바이스 기술 프레임워크 관리된 오브젝트에서의 각각의 다른 관리된 오브젝트에 대한 한 세트의 노드들은:
상기 다른 관리된 오브젝트의 명칭을 포함하는 노드;
상기 다른 관리된 오브젝트의 버전의 표시를 포함하는 노드;
상기 다른 관리된 오브젝트를 식별하는데 사용될 수 있는 오브젝트 ID(identifier)를 포함하는 노드;
상기 다른 관리된 오브젝트에 대한 상기 디바이스 기술 프레임워크 문서의 명칭을 포함하는 노드;
상기 다른 관리된 오브젝트에 대한 상기 디바이스 기술 프레임워크 문서와 연관되는 url(uniform resource locator)를 포함하는 노드;
상기 다른 관리된 오브젝트의 상태의 표시를 포함하는 노드; 및
상기 다른 관리된 오브젝트상에서 실행될 수 있는 동작들을 표현하는 복수의 노드 - 상기 동작들은 업로드, 업로드 활성화, 활성화, 및 활성화 해제 동작 중 하나 이상을 포함함-
중 하나 이상을 추가로 포함하는
디바이스 관리 서버.
프로세서 및 메모리를 포함하는 게이트웨이 디바이스 관리 서버로서, 상기 메모리는 컴퓨터 실행가능 명령어를 저장하고, 상기 컴퓨터 실행가능 명령어는, 상기 프로세서에 의해 실행될 때, 상기 디바이스 관리 서버로 하여금:
상기 게이트웨이 디바이스 관리 서버의 메모리에, 상기 게이트웨이 디바이스 관리 서버에 의해 지원되는 복수의 다른 관리된 오브젝트 각각에 대해, 해당 다른 관리된 오브젝트에 대한 디바이스 기술 프레임워크 문서의 복사본을 저장하는 디바이스 기술 프레임워크 관리된 오브젝트를 유지하고;
새로운 관리된 오브젝트를 상기 게이트웨이 디바이스 관리 서버에 등록하라는 요청을 수신하고- 상기 새로운 관리된 오브젝트는 LWM2M(lightweight machine-to-machine) 프로토콜에 따라서 동작하는 서버에 의해 지원되는 오브젝트를 표현함 -;
상기 LWM2M 서버에 의해 지원되는 상기 LWM2M 오브젝트를 표현하는 디바이스 기술 프레임워크 문서를 수신하고; 및
상기 요청에 응답하여, 상기 게이트웨이 디바이스 관리 서버에 의해 유지되는 상기 디바이스 기술 프레임워크 관리된 오브젝트에 상기 LWM2M 서버에 의해 지원되는 상기 LWM2M 오브젝트에 대한 상기 디바이스 기술 프레임워크 문서를 추가하도록 야기하는
게이트웨이 디바이스 관리 서버.
제6항에 있어서, 상기 컴퓨터 실행가능 명령어들은 상기 게이트웨이 디바이스 관리 서버로 하여금:
상기 LWM2M 서버로부터 상기 LWM2M 오브젝트에 대한 상기 디바이스 기술 프레임워크 문서를 요청하는 요청을 상기 LWM2M 서버에게 송신하고; 및
상기 요청에 응답하여 상기 LWM2M 오브젝트에 대한 상기 디바이스 기술 프레임워크 문서를 수신하도록 추가로 야기하는
게이트웨이 디바이스 관리 서버.
제6항에 있어서, 상기 컴퓨터 실행가능 명령어들은 상기 게이트웨이 디바이스 관리 서버로 하여금:
상기 LWM2M 서버로부터, 상기 LWM2M 서버에 의해 지원되는 LWM2M 오브젝트를 등록하라는 요청을 수신하고 - 상기 요청은 상기 LWM2M 프로토콜에 따라서 형성됨-; 및
상기 LWM2M 서버로부터 수신된 요청을, 상기 게이트웨이 디바이스 관리 서버에 상기 새로운 관리된 오브젝트를 등록하라는 상기 요청이 되게 번역하도록 추가로 야기하는
게이트웨이 디바이스 관리 서버.
제6항에 있어서, 상기 컴퓨터 실행가능 명령어들은 상기 게이트웨이 디바이스 관리 서버로 하여금 상기 LWM2M 서버에 의해 지원되는 상기 LWM2M 오브젝트를 표현하는 상기 디바이스 기술 프레임워크 문서를 DM(device management) 서버에게 제공하여 그에 등록하기 위해 상기 DM 서버에게 Register DDF Alert 메시지를 보내도록 추가로 야기하는
게이트웨이 디바이스 관리 서버.
프로세서 및 메모리를 포함하는 DM(device management) 서버로서, 상기 메모리는 컴퓨터 실행가능 명령어를 저장하고, 상기 컴퓨터 실행가능 명령어는, 상기 프로세서에 의해 실행될 때, 상기 DM 서버로 하여금:
상기 DM 서버의 메모리에, 상기 DM 서버에 의해 지원되는 복수의 다른 관리된 오브젝트 각각에 대해, 해당 다른 관리된 오브젝트에 대한 디바이스 기술 프레임워크 문서의 복사본을 저장하는 디바이스 기술 프레임워크 관리된 오브젝트를 유지하고;
새로운 관리된 오브젝트를 상기 DM 서버에 등록하라는 요청을 수신하고 - 상기 새로운 관리된 오브젝트는 LWM2M 프로토콜에 따라서 동작하는 서버에 의해 지원되는 오브젝트를 표현함 -;
상기 LWM2M 서버에 의해 지원되는 상기 LWM2M 오브젝트를 표현하는 디바이스 기술 프레임워크 문서를 수신하고; 및
상기 요청에 응답하여, 상기 DM 서버에 의해 유지되는 상기 디바이스 기술 프레임워크 관리된 오브젝트에 상기 LWM2M 서버에 의해 지원되는 상기 LWM2M 오브젝트에 대한 상기 디바이스 기술 프레임워크 문서를 추가하도록 야기하는
DM 서버.
제10항에 있어서, 상기 컴퓨터 실행가능 명령어들은 상기 DM 서버로 하여금:
상기 LWM2M 서버로부터 상기 LWM2M 오브젝트에 대한 상기 디바이스 기술 프레임워크 문서를 요청하는 요청을 상기 LWM2M 서버에게 송신하고; 및
상기 요청에 응답하여 상기 LWM2M 오브젝트에 대한 상기 디바이스 기술 프레임워크 문서를 수신하도록 추가로 야기하는
DM 서버.
제10항에 있어서, 상기 컴퓨터 실행가능 명령어들은 상기 DM 서버로 하여금:
상기 LWM2M 서버로부터, 상기 LWM2M 서버에 의해 지원되는 LWM2M 오브젝트를 등록하라는 요청을 수신하고 - 상기 요청은 상기 LWM2M 프로토콜에 따라서 형성됨-; 및
상기 LWM2M 서버로부터 수신되는 요청을, 상기 DM 서버에 상기 새로운 관리된 오브젝트를 등록하라는 상기 요청이 되도록 번역하게 추가로 야기하는
DM 서버.
삭제
삭제
삭제
네트워크에 접속되는 디바이스 관리 서버에서의 방법으로서:
상기 디바이스 관리 서버의 메모리에, 상기 디바이스 관리 서버에 의해 지원되는 복수의 다른 관리된 오브젝트 각각에 대해, 해당 다른 관리된 오브젝트에 대한 디바이스 기술 프레임워크 문서의 복사본을 저장하는 디바이스 기술 프레임워크 관리된 오브젝트를 유지하는 단계;
새로운 관리된 오브젝트를 상기 디바이스 관리 서버에 등록하라는 요청을 수신하는 단계 - 상기 요청은 상기 새로운 관리된 오브젝트에 대한 디바이스 기술 프레임워크 문서를 포함함-; 및
상기 요청에 응답하여, 상기 디바이스 관리 서버에 의해 유지되는 상기 디바이스 기술 프레임워크 관리된 오브젝트에 상기 새로운 관리된 오브젝트에 대한 상기 디바이스 기술 프레임워크 문서를 추가하는 단계
를 포함하는 방법.
제16항에 있어서, 상기 새로운 관리된 오브젝트의 상기 디바이스 기술 프레임워크 문서를 상기 디바이스 기술 프레임워크 관리된 오브젝트에 추가하기 전에, 상기 새로운 관리된 오브젝트의 상기 디바이스 기술 프레임워크 문서의 포맷을 검증하는 단계
를 추가로 포함하는 방법.
제16항에 있어서, 상기 디바이스 기술 프레임워크 관리된 오브젝트는, 상기 디바이스 관리 서버에 의해 지원되는 상기 다른 관리된 오브젝트들 각각에 대해, 상기 다른 관리된 오브젝트에 대한 정보를 포함하는 한 세트의 노드들을 포함하고, 상기 노드들 중 하나는 해당 다른 관리된 오브젝트에 대한 상기 디바이스 기술 프레임워크 문서의 복사본을 홀드하는
방법.
제16항에 있어서, 상기 디바이스 기술 프레임워크 관리된 오브젝트에 상기 새로운 관리된 오브젝트에 대한 상기 디바이스 기술 프레임워크 문서를 추가하는 단계는:
상기 새로운 관리된 오브젝트에 대한 상기 디바이스 기술 프레임워크 관리된 오브젝트에 한 세트의 노드를 생성하는 단계; 및
상기 세트 중 하나의 노드에 상기 새로운 관리된 오브젝트에 대한 상기 디바이스 기술 프레임워크 문서의 복사본을 저장하는 단계를 포함하는
방법.
네트워크에 접속되는 게이트웨이 디바이스 관리 서버에서의 방법으로서:
상기 게이트웨이 디바이스 관리 서버의 메모리에, 상기 게이트 웨이 디바이스 관리 서버에 의해 지원되는 복수의 다른 관리된 오브젝트 각각에 대해, 해당 다른 관리된 오브젝트에 대한 디바이스 기술 프레임워크 문서의 복사본을 저장하는 디바이스 기술 프레임워크 관리된 오브젝트를 유지하는 단계;
새로운 관리된 오브젝트를 상기 게이트웨이 디바이스 관리 서버에 등록하라는 요청을 수신하는 단계 - 상기 새로운 관리된 오브젝트는 LWM2M(lightweight machine-to-machine) 프로토콜에 따라서 동작하는 서버에 의해 지원되는 오브젝트를 표현함 -;
상기 LWM2M 서버에 의해 지원되는 상기 LWM2M 오브젝트를 표현하는 디바이스 기술 프레임워크 문서를 수신하는 단계; 및
상기 요청에 응답하여, 상기 게이트웨이 디바이스 관리 서버에 의해 유지되는 상기 디바이스 기술 프레임워크 관리된 오브젝트에 상기 LWM2M 서버에 의해 지원되는 상기 LWM2M 오브젝트에 대한 상기 디바이스 기술 프레임워크 문서를 추가하는 단계
를 포함하는 방법.
제20항에 있어서,
상기 LWM2M 서버로부터 상기 LWM2M 오브젝트에 대한 상기 디바이스 기술 프레임워크 문서를 요청하는 요청을 상기 LWM2M 서버에게 송신하는 단계; 및
상기 요청에 응답하여 상기 LWM2M 오브젝트에 대한 상기 디바이스 기술 프레임워크 문서를 수신하는 단계
를 추가로 포함하는 방법.
제20항에 있어서,
상기 LWM2M 서버로부터, 상기 LWM2M 서버에 의해 지원되는 LWM2M 오브젝트를 등록하라는 요청을 수신하는 단계 - 상기 요청은 상기 LWM2M 프로토콜에 따라서 형성됨-; 및
상기 LWM2M 서버로부터 수신되는 상기 요청을, 상기 게이트웨이 디바이스 관리 서버에 상기 새로운 관리된 오브젝트를 등록하라는 상기 요청이 되도록 번역하는 단계
를 추가로 포함하는 방법.
제20항에 있어서, 상기 LWM2M 서버에 의해 지원되는 상기 LWM2M 오브젝트를 표현하는 상기 디바이스 기술 프레임워크 문서를 DM 서버에게 제공하여 그에 등록하기 위해 DM 서버에게 Register DDF Alert 메시지를 보내는 단계
를 추가로 포함하는 방법.
네트워크에 접속되는 DM 서버에서의 방법으로서:
상기 DM 서버의 메모리에, 상기 DM 서버에 의해 지원되는 복수의 다른 관리된 오브젝트 각각에 대해, 해당 다른 관리된 오브젝트에 대한 디바이스 기술 프레임워크 문서의 복사본을 저장하는 디바이스 기술 프레임워크 관리된 오브젝트를 유지하는 단계;
새로운 관리된 오브젝트를 상기 DM 서버에 등록하라는 요청을 수신하는 단계 - 상기 새로운 관리된 오브젝트는 LWM2M 프로토콜에 따라서 동작하는 서버에 의해 지원되는 오브젝트를 표현함 -;
상기 LWM2M 서버에 의해 지원되는 상기 LWM2M 오브젝트를 표현하는 디바이스 기술 프레임워크 문서를 수신하는 단계; 및
상기 요청에 응답하여, 상기 DM 서버에 의해 유지되는 상기 디바이스 기술 프레임워크 관리된 오브젝트에 상기 LWM2M 서버에 의해 지원되는 상기 LWM2M 오브젝트에 대한 상기 디바이스 기술 프레임워크 문서를 추가하는 단계
를 포함하는 방법.
제24항에 있어서,
상기 LWM2M 서버로부터 상기 LWM2M 오브젝트에 대한 상기 디바이스 기술 프레임워크 문서를 요청하는 요청을 상기 LWM2M 서버에게 송신하는 단계; 및
상기 요청에 응답하여 상기 LWM2M 오브젝트에 대한 상기 디바이스 기술 프레임워크 문서를 수신하는 단계
를 추가로 포함하는 방법.
제24항에 있어서, 컴퓨터 실행가능 명령어들은 상기 DM 서버로 하여금:
상기 LWM2M 서버로부터, 상기 LWM2M 서버에 의해 지원되는 LWM2M 오브젝트를 등록하라는 요청을 수신하고 - 상기 요청은 상기 LWM2M 프로토콜에 따라서 형성됨-; 및
상기 LWM2M 서버로부터 수신되는 상기 요청을 상기 DM 서버에 상기 새로운 관리된 오브젝트를 등록하라는 상기 요청이 되도록 번역하도록 추가로 야기하는
방법.