KR20170031753A - 복수의 디바이스들 상에서 복수의 명령들의 실행을 허용하는 것에 의해 강화되는, m2m 시스템에서의 서비스 레이어와 관리 레이어 사이의 동작들 - Google Patents

Abstract

본 출원은 M2M 인터페이스를 통해 그룹-온-그룹 동작들을 수행하기 위한 컴퓨터-구현 디바이스 및 방법에 관한 것이다. 이러한 디바이스 및 방법은 URI(uniform resource indicator)에 정의되는 그룹 리소스의 명령들을 포함하는 그룹-온-그룹 동작을 착수하라는 요청을 디바이스 소유자로부터 수신하는 단계를 포함한다. 이러한 디바이스 및 방법은 이러한 요청을 처리하는 단계, 및 또한 이러한 디바이스들 상에서 명령들을 실행하라는 그룹 관리 요청 API를 관리 서버에 전송하는 단계를 포함한다. 또한, 디바이스에 의한 명령들의 실행 상태를 표시하는 응답을 관리 서버로부터 수신하는 단계가 있다. 본 출원은 또한 M2M 인터페이스를 통해 그룹-온-그룹 동작을 확립하기 위한 컴퓨터-구현 방법에 관한 것이다.

Description

복수의 디바이스들 상에서 복수의 명령들의 실행을 허용하는 것에 의해 강화되는, M2M 시스템에서의 서비스 레이어와 관리 레이어 사이의 동작들{ENHANCED OPERATIONS BETWEEN SERVICE LAYER AND MANAGEMENT LAYER IN AN M2M SYSTEM BY ALLOWING THE EXECUTION OF A PLURALITY OF COMMANDS ON A PLURALITY OF DEVICES}

<관련 출원에 대한 상호 참조>

본 출원은 2014년 7월 18일자로 출원된 미국 임시 특허 출원 제62/026,165호에 대한 우선권을 주장하며, 그 개시 내용은 전부가 본 명세서에 참조로 포함된다.

<배경기술>

디바이스 상에서 실행되는 관리 서버와 관리 클라이언트 사이에는 DM(Device Management)이 통상적으로 수행되어 왔다. 이러한 동작 모드는 개인화된 모바일 디바이스들, 예를 들어, 전화들 및 태블릿들, 또는 개별적으로 관리되는 가동 네트워크 디바이스들과 같은 디바이스들에 대한 기존 DM 프로토콜들에 어울릴 수 있다. 이와 같이, 디바이스들의 그룹에 대한 DM 프로토콜들을 관리하는데 제한된 개발 및 지원이 있어 왔다.

OMA(Open Mobile Alliance)는, OMA DM 프로토콜, OMA GwMO(Gateway Managed Object) 프로토콜 및 OMA LWM2M(Lightweight Machine-to-Machine) 프로토콜을 포함하는, 네트워크에서의 DM을 위한 다수의 프로토콜들을 개발해 왔다. 또한, BBF(Broadband Forum)는 CWMP(CPE(Customer Premised Equipment) WAN Management Protocol)를 포함한다. 이러한 프로토콜들은 네트워크에서, 모바일 디바이스들과 같은, 독립형 디바이스들을 관리하는데 사용할 수 있다. OMA GwMO 프로토콜은 게이트웨이 뒤에 있는 엔드 디바이스들의 그룹을 관리하는데 사용될 수 있다. 그러나, 이러한 프로토콜은 게이트웨이에 부가되는 디바이스들에 제한된다. OMA LWM2M은 강요된 M2M(Machine-to-Machine) 또는 IoT(Internet-of-Things) 디바이스들을 관리하는데 사용할 수 있다. BBF CWMP 프로토콜들은 디바이스들의 그룹으로의 파일 이송들을 제공하는데 LAN(Local Area Network) 내의 멀티캐스트 그룹들을 사용하는 메커니즘을 명시한다. 또한, 이러한 프로토콜들은 소프트웨어 다운로드에 주로 중점을 둔다. 별도로, BBF CWMP는 멀티캐스트가 활용될 수 있는 LAN에서의 디바이스들에 제한된다. 결론적으로, 현재의 DM 표준들에 의하면 엔드-투-엔드 아키텍처(end to end architecture)에서의 강화된 그룹 관리 동작들을 제공하는데 부족함이 있다.

구체적으로, 현재의 표준들에는, M2M 서버가 DM 서버와 어떻게 통신할 수 있는지에 대한 프로시저들이 거의 또는 전혀 없다. 이것은 통신을 위한 인터페이스들의 비-표준화에 기인한다. 현재, 인터페이스들은 각각의 서비스 제공업체에 대한 맞춤형 개발들을 요구한다. 예를 들어, 서비스 레이어가 OMA DM, OMA LWM2M(Lightweight M2M) 및 BBF CWMP 디바이스들을 지원하기 위해서는, 이러한 디바이스들 각각과 통신하기 위해 3개의 맞춤형 API 인터페이스들이 개발될 필요가 있다. 이것은 효율성을 떨어뜨리고, 상이한 시스템들 사이의 상호운용성을 또한 제한한다.

본 요약은 상세한 설명에서 이하 더 설명되는 개념들의 선택을 단순화된 형태로 소개하기 위해 제공된다. 본 요약은 청구되는 주제의 범위를 제한하려고 의도되는 것은 아니다. 전술한 필요성들은 관리 서버로의 그룹 동작들에 대한 디바이스 관리 동작들을 강화하기 위한 프로세스 및 시스템에 관한 본 출원에 의해, 대부분, 충족된다.

본 출원의 일 양상은 비-휘발성 메모리 및 프로세서를 포함하며 그룹-온-그룹 동작들을 수행하기 위한 장치에 관한 것이다. 비-휘발성 메모리는, 프로세서에 의해 실행될 때, 서버로 하여금 특정 단계들을 수행하게 하는 컴퓨터 실행가능 명령어들을 저장한다. 하나의 단계는 URI(uniform resource indicator)에 정의되는 그룹 리소스의 명령들을 포함하는 그룹-온-그룹 동작들을 착수하라는 요청을 디바이스 소유자로부터 수신하기 위한 것이다. 다음으로, 이러한 요청이 처리된다. 또한, 이러한 명령들을 실행하기 위해 디바이스 상에서 실행되는 DM 클라이언트와의 세션을 확립하라는 그룹 관리 요청 API를 DM 서버에 전송하는 단계가 있다.

본 출원의 다른 양상은 M2M 서버와 관리 서버 사이에 존재하는 M2M 인터페이스를 통해 그룹-온-그룹 동작을 확립하기 위한 컴퓨터-구현 방법에 관한 것이다. 본 방법은 디바이스들의 그룹을 관리하라는 등록 요청을 디바이스 소유자로부터 수신하는 단계를 포함한다. 본 방법은 디바이스들의 그룹에 대한 등록 통지를 수신하는 단계를 또한 포함한다. 다음으로, 예를 들어, 디바이스 그룹을 생성하라는 요청이 디바이스 소유자로부터 수신된다. 또한, 디바이스 그룹을 생성하라는 수신된 요청이 실행된다. 일 실시예에서, 본 방법은 명령 그룹을 생성하라는 요청을 수신하는 단계 및 명령 그룹을 생성하라는 수신된 요청을 처리하는 단계를 더 포함한다. 다른 실시예에 따르면, 본 방법은 디바이스 그룹을 생성하라는 그룹 관리 요청 API를 DM 서버에 전송하는 단계를 더 포함한다. 다른 실시예에서, 본 방법은 명령 그룹을 생성하라는 그룹 관리 요청 API를 DM 서버에 전송하는 단계를 더 포함한다.

본 출원의 또 다른 양상은 M2M 인터페이스를 통해 그룹-온-그룹 동작들을 수행하기 위한 컴퓨터-구현 방법에 관한 것이다. 본 방법은 URI(uniform resource indicator)에 정의되는 그룹 리소스의 명령들을 포함하는 그룹-온-그룹 동작들을 착수하라는 요청을 디바이스 소유자로부터 수신하는 단계를 포함한다. 본 방법은 이러한 요청을 처리하는 단계를 포함한다. 또한, 이러한 명령들을 실행하기 위해 디바이스 상에서 실행되는 DM 클라이언트와의 세션을 확립하라는 그룹 관리 요청 API를 DM 서버에 전송하는 단계가 있다. 또한, 디바이스에 의한 명령들의 성공적인 실행을 표시하는 응답을 DM 서버로부터 수신하는 단계가 있다.

본 발명의 상세한 설명이 더 잘 이해될 수 있도록 하기 위해, 그리고 관련분야에 대한 본 발명의 기여가 더 잘 인식될 수 있도록 하기 위해, 이와 같이, 다소 광범위하게, 본 발명의 특정 실시예들의 개요가 설명되었다.

본 출원의 더 충실한 이해를 촉진하기 위해, 유사한 엘리먼트들이 유사한 번호들로 참조되는 첨부 도면들이 이제 참조된다. 이러한 도면들은 본 출원을 제한하는 것으로 해석되어서는 안 되며 단지 예시를 위해 의도되는 것이다.
도 1a는 본 출원에 따라 하나 이상의 개시되는 실시예들이 구현될 수 있는 예시적인 M2M(machine-to-machine), IoT(Internet of Things) 또는 WoT(Web of Things) 통신 시스템의 시스템 도해를 도시한다.
도 1b는 본 출원에 따라 도 1a에 도시되는 M2M/IoT/WoT 통신 시스템 내에서 사용될 수 있는 예시적인 아키텍처의 시스템 도해를 도시한다.
도 1c는 본 출원에 따라 도 1a에 도시되는 통신 시스템 내에서 사용될 수 있는 예시적인 M2M/IoT/WoT 단말 또는 게이트웨이 디바이스의 시스템 도해를 도시한다.
도 1d는 본 출원에 따라 본 명세서에 설명되는 도 1a의 통신 시스템의 양상들 및 맥락-인식 콘텐츠 공개 및 해상도 개념들이 구현될 수 있는 예시적인 컴퓨팅 시스템의 블록도이다.
도 2a는 본 출원의 실시예에 따라 DM 서버가 디바이스들 에서 실행중인 DM 클라이언트들에 디바이스 관리 명령들을 전송하는 OMA DM 프로토콜 아키텍처를 도시한다.
도 2b는 본 출원의 실시예에 따라 서비스 레이어와 디바이스 관리 레이어 사이의 통신으로 M2M 인터페이스를 도시한다.
도 3은 본 출원의 실시예에 따라 M2M 디바이스 상의 LWM2M 서버와 LWM2M 클라이언트 사이의 인터페이스를 도시한다.
도 4는 본 출원의 실시예에 따라 CPE(Customer Premises Equipment) 디바이스를 관리하는데 ACS(Auto-Configuration Server)가 사용되는 BBF TR-069 CPE WAN 관리 프로토콜 아키텍처를 도시한다.
도 5는 본 출원의 실시예에 따라 관리 어댑터가 서비스 레이어 API를 DM 명령들로 변환하는 서비스 레이어 아키텍처를 도시한다.
도 6은 본 출원의 실시예에 따라 디바이스들의 그룹에 대한 관리 동작들의 사용 예를 도시한다.
도 7은 본 출원의 실시예에 따라 엔드-투-엔드 M2M 및 DM 통합 아키텍처를 도시한다.
도 8은 본 출원의 실시예에 따라 엔드-투-엔드 DM 동작에 대한 호출 흐름을 도시한다.
도 9는 본 출원의 실시예에 따라 oneM2M <group> 리소스들을 도시한다.
도 10은 본 출원의 실시예에 따라 그룹-온-그룹 동작들을 보여주는 호출 흐름을 도시한다.
도 11은 본 출원의 실시예에 따라 <mgmtCmd> 리소스를 포함하는 그룹-온-그룹 동작들을 도시한다.
도 12는 본 출원의 실시예에 따라 M2M 인터페이스 그룹 관리 프로시저들을 도시한다.
도 13은 본 출원의 실시예에 따라 그룹 관리 지원을 위한 OMA DM Group MO를 도시한다.
도 14는 본 출원의 실시예에 따라 DM 서버 리소스들에 대한 그룹 관리 동작들을 도시한다.
도 15는 본 출원의 실시예에 따라 그래픽 사용자 인터페이스를 도시한다.

본 명세서에서 다양한 도면들, 실시예들 및 양상들을 참조하여 예시적인 실시예들의 상세한 설명이 논의될 것이다. 이러한 설명은 가능한 구현들의 상세한 예들을 제공하지만, 상세사항들은 예시적인 것으로 의도되는 것이며 따라서 본 출원의 범위를 제한하는 것이 아니라는 점이 이해되어야야 한다.

본 명세서서 "일 실시예", "실시예", "하나 이상의 실시예들" 또는 "양상"에 대한 언급은 그 실시예와 관련하여 설명되는 특정한 특징, 구조, 또는 특성이 본 개시내용의 적어도 하나의 실시예에 포함된다는 점을 의미한다. 더욱이, 본 명세서에서 다양한 곳에서의 "실시예"라고 하는 용어가 반드시 동일한 실시예를 언급하는 것은 아니다. 즉, 일부 실시예들에 의해서는 드러나지만 다른 실시예들에 의해서는 드러나지 않을 수 있는 다양한 특징들이 설명된다.

M2M/IoT 영역에서, 벌크 디바이스 관리 동작들을 수행하는 능력은 M2M 서버를 위한 필수적인 특징일 수 있다. 따라서, 본 출원은 엔드-투-엔드 시스템에서 강화된 그룹 관리 동작들을 지원하기 위한 기존 서비스 레이어 및 관리 레이어 아키텍처에 대한 강화에 관한 것이다. 즉, M2M 애플리케이션들은 디바이스들의 그룹을 보다 효율적으로 관리하기 위한 애플리케이션/서비스 레이어에서 관리 명령들의 세트를 제공할 수 있다.

본 발명의 일 양상에 따르면, 디바이스 및 명령 그룹들을 관리할 수 있게 하는 서비스 레이어 및 관리 레이어 아키텍처들에서의 강화된 그룹 관리 프로시저들이 제안된다. 본 발명의 다른 양상에 따르면, 명령들의 세트가 디바이스들의 그룹에 적용될 수 있는 그룹-온-그룹 동작들을 수행하는 메커니즘이 설명된다. 이러한 능력은 M2M 및 IoT 시스템들에서 디바이스들의 보다 효율적인 관리를 가능하게 할 것이다. 다른 양상에 따르면, M2M 인터페이스를 통해 통신하기 위한 그룹 관리 프로시저들에 대한 새로운 메시지 포맷들이 설명된다. 이러한 새로운 메시지 포맷들은 서비스 레이어와 관리 레이어 사이의 인터페이스 표준화에 사용될 수 있다. 이것은 서비스 레이어로 상이한 디바이스 관리 프로토콜들 사이의 상호운용성을 제공할 것이다.

본 발명의 또 다른 양상에 따르면, 강화된 그룹 관리 동작들을 지원하기 위해 새로운 리소스 및 속성 실시예들이 oneM2M, OMA DM, OMA LWM2M, 및 BBF CWMP 아키텍처들에 정의된다. 예를 들어, M2M 애플리케이션들이 명령들의 그룹들을 생성하고 이러한 명령들에 대한 인수들을 제공하게 하는 새로운 oneM2M <group> 리소스 속성들이 도입된다. 또한, 그룹-온-그룹 동작들을 명시하기 위한 새로운 oneM2M <group> 어드레싱 스킴들이 설명된다. 또한, 그룹 동작들을 명시하게 하기 위해 <mgmtCmd> 리소스 속성 execTarget에 대한 강화가 설명된다. 또한, 그룹 동작들을 지원하기 위한 OMA DM, OMA LWM2M, 및 BBF CWMP 프로토콜들에 대한 새로운 그룹 리소스들이 설명된다. 또한 그룹 동작들을 지원하기 위한 OMA DM, OMA LWM2M, 및 BBF CWMP 프로토콜들 내의 그룹 처리 프로시저들의 사양이 설명된다.

다음의 두문자어들은 본 출원에서 통상적으로 사용될 것이며, 따라서 이하 표 1에서 참조용으로 제공된다 :

본 출원은 AEP들(application enablement platforms) 및 CDP들(connected device platforms) 양자 모두에 대한 플랫폼 기능성 및 지원을 커버하도록 의도된 것이다. AEP들은 애플리케이션 인에이블먼트 레이어, 및 월드 와이드 웹 및 및 인터넷을 포함하는 서비스 레이어를 포함한다. 애플리케이션 인에이블먼트 레이어는 이에 제한되는 것은 아니지만: (i) 서비스하는 API들, 규칙들/스크립팅 엔진; (ii) SDK 프로그래밍 인터페이스; 및 (iii) 기업 시스템들 통합을 포함한다. 애플리케이션 인에이블먼트 레이어는 이에 제한되는 것은 아니지만 발견, 분석, 맥락 및 이벤트들을 포함하는 부가 가치 서비스들을 또한 포함할 수 있다. 월드 와이드 웹 및 인터넷을 포함하는 서비스 레이어는, 예를 들어, 분석, 과금(billing), 원시 API들, 웹 서비스 인터페이스들, 시멘틱 데이터 모델들, 디바이스/서비스 발견, 디바이스 관리, 보안, 데이터 수집, 데이터 적응, 종합, 이벤트 관리, 맥락 관리, 최적화된 접속 및 운송, M2M 게이트웨이, 및 어드레싱 및 식별을 포함할 수 있다. CDP들은 접속 분석, 사용 분석/보고/경고들, 정책 제어, 자동화된 프로비저닝(provisioning), SIM 활성화/비활성화, 및 가입 활성화/비활성화를 포함할 수 있다.

일반적 아키텍처

도 1a는 하나 이상의 개시되는 실시예들이 구현될 수 있는 예시적인 M2M(machine-to machine), IoT(Internet of Things), 또는 WoT(Web of Things) 통신 시스템(10)의 도해이다. 일반적으로, M2M 기술들은 IoT/WoT에 대한 빌딩 블록들을 제공하고, 임의의 M2M 디바이스, 게이트웨이, 또는 서비스 플랫폼이 이러한 IoT/WoT는 물론이고 IoT/WoT 서비스 레이어 등의 컴포넌트들일 수 있다.

도 1a에 도시되는 바와 같이, M2M/IoT/WoT 통신 시스템(10)은 통신 네트워크(12)를 포함한다. 통신 네트워크(12)는 고정형 네트워크, 예를 들어, Ethernet, Fiber, ISDN, PLC 등 또는 무선 네트워크, 예를 들어, WLAN, 셀룰러 등일 수 있거나, 또는 이종 네트워크들 중 하나의 네트워크일 수 있다. 이러한 네트워크는 앞서 언급한 CAINE 네트워크를 포함할 수 있다. 예를 들어, 통신 네트워크(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), 위성 네트워크, 홈 네트워크, 또는 엔터프라이즈 네트워크와 같은 다른 네트워크들을 포함할 수 있다.

도 1a에 도시되는 바와 같이, M2M/IoT/WoT 통신 시스템(10)은 인프라구조 도메인(Infrastructure Domain) 및 필드 도메인(Field Domain)을 포함할 수 있다. 인프라구조 도메인은 엔드-투-엔드 M2M 배치의 네트워크 측을 지칭하고, 필드 도메인은 일반적으로 M2M 게이트웨이 뒤의 영역 네트워크들을 지칭한다. 필드 도메인은 CR들(Content Routers)과 같은 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), 직접 무선 링크, 및 와이어라인(wireline)을 예를 들어 포함하는 다양한 네트워크들을 통해 통신할 수 있다.

도 1b를 참조하면, 필드 도메인에 도시되는 M2M 서비스 레이어(22)는 M2M 애플리케이션(20), M2M 게이트웨이 디바이스들(14), 및 M2M 단말 디바이스들(18) 및 통신 네트워크(12)에 대한 서비스들을 제공한다. M2M 서비스 레이어(22)는 원하는 대로 임의의 수의 M2M 애플리케이션들, M2M 게이트웨이 디바이스들(14), M2M 단말 디바이스들(18) 및 통신 네트워크들(12)과 통신할 수 있다는 점이 이해될 것이다. M2M 서비스 레이어(22)는 본 출원에서의 하나 이상의 콘텐츠 서버들과 같은 하나 이상의 서버들, 컴퓨터들 등에 의해 구현될 수 있다. M2M 서비스 레이어(22)는 M2M 단말 디바이스들(18), M2M 게이트웨이 디바이스들(14) 및 M2M 애플리케이션들(20)에 적용되는 서비스 능력들을 제공한다. 이들은 라우터들을 포함할 수 있다. M2M 서비스 레이어(22)의 기능들은 다양한 방식들로 구현될 수 있다. 예를 들어, 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')는 콘텐츠 서버와 같은 하나 이상의 서버들, 컴퓨터들, 가상 머신들, 예를 들어, 클라우드/컴퓨트/스토리지 팜들 등에 의해 구현될 수 있다.

도 1b를 또한 참조하면, M2M 서비스 레이어(22 및 22')는 다양한 애플리케이션들 및 수직계열들이 영향력을 행사할 수 있는 서비스 전달 능력들의 코어 세트를 제공한다. 이러한 서비스 능력들은 M2M 애플리케이션들(20 및 20')이 디바이스들과 인터렉트하고 데이터 수집, 데이터 분석, 디바이스 관리, 보안, 과금, 서비스/디바이스 발견 등과 같은 기능들을 수행할 수 있게 한다. 실질적으로, 이러한 서비스 능력들은 애플리케이션들을 이러한 기능성들을 구현하는 부담들로부터 자유롭게 하고, 따라서 애플리케이션 개발을 간단하게 하고 마케팅에 대한 비용 및 시간을 감소시킨다. 서비스 레이어(22 및 22')는 또한 M2M 애플리케이션들(20 및 20')이 서비스 레이어(22 및 22')가 제공하는 서비스들과 관련하여 다양한 네트워크들(12 및 12')을 통해 통신할 수 있게 한다.

M2M 애플리케이션들(20 및 20')은, 이에 제한되는 것은 아니지만, 운송, 건강 및 건강관리, 접속된 홈, 에너지 관리, 자산 추적, 및 보안과 감시와 같은 다양한 산업들에서의 애플리케이션들을 포함할 수 있다. 위에 언급된 바와 같이, 시스템의 디바이스들, 게이트웨이들, 및 다른 서버들에 걸쳐 실행되는 M2M 서비스 레이어는, 예를 들어, 데이터 수집, 디바이스 관리, 보안, 과금, 위치 추적/지오펜싱(geo-fencing), 디바이스/서비스 발견, 및 레거시 시스템들 통합과 같은 기능들을 지원하고, 이러한 기능들을 서비스들로서 M2M 애플리케이션들(20, 20')에 제공한다. 더욱이, M2M 서비스 레이어는 본 출원에서 논의되고 도면들에 도시되는 바와 같이 콘텐츠 서버들, 콘텐츠 라우터들 및 콘텐츠 클라이언트들과 같은 다른 디바이스들과 인터페이스하도록 또한 구성될 수 있다.

본 출원에서 논의되는 바와 같이 콘텐츠 라우터 상의 공개된 콘텐츠에 관련된 맥락 정보를 업데이트하는 것뿐만 아니라 콘텐츠 요청을 해결하기 위한 최상의 다음 홉 라우터를 결정하는 방법이 서비스 레이어의 일부로서 구현될 수 있다. 이러한 서비스 레이어는 API들(Programming Interfaces) 및 기본 네트워킹 인터페이스들의 세트를 통해 부가 가치 서비스 능력들을 지원하는 소프트웨어 미들웨어 레이어이다. 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들의 세트의 인스턴스화(instantiation)는 상이한 타입들의 네트워크 노드들, 예를 들어, 인프라구조 노드, 미들 노드, 애플리케이션-특정 노드에서 호스팅될 수 있는 CSE(Common Services Entity)라고 지칭된다. 또한, 본 출원에서 설명되는 바와 같이 트랙을 예약하는 방법은 본 출원에 따라 트랙을 예약하는 것과 같은 서비스들을 액세스하는데 SOA(Service Oriented Architecture) 및/또는 ROA(Resource-Oriented Architecture)를 사용하는 M2M 네트워크의 일부로서 구현될 수 있다.

도 1c는 예를 들어 M2M 단말 디바이스(18) 또는 M2M 게이트웨이 디바이스(14)와 같은 예시적 M2M 디바이스(30)의 시스템 도해이다. 도 1c에 도시되는 바와 같이, M2M 디바이스(30)는 프로세서(32), 송수신기(34), 송신/수신 엘리먼트(36), 스피커/마이크로폰(38), 키패드(40), 디스플레이/터치패드/표시자(들)(42), 비-이동식 메모리(44), 이동식 메모리(46), 전원(48), GPS(global positioning system) 칩셋(50), 및 다른 주변기기들(52)을 포함할 수 있다. 예를 들어, 콘텐츠 라우터용 프로세서는 이하 더 상세히 설명되고 첨부 도면에 도시되는 바와 같이 CPM(Content Publication Manager), 블룸(Bloom) 필터 프로세서, 및/또는 CRM(Content Resolution Manager)을 포함할 수 있다. 본 출원의 설명에 따르면 M2M 단말 디바이스(18)는 콘텐츠 클라이언트일 수 있고, M2M 게이트웨이 디바이스(14)는 콘텐츠 라우터 또는 콘텐츠 서버일 수 있다. M2M 디바이스(40)는 실시예와 일관성을 유지하면서 전술한 엘리먼트들의 임의의 부분 조합을 포함할 수 있다는 점이 이해될 것이다. 이러한 디바이스는 센서형 데이터의 내장형 시맨틱스 명명(embedded semantics naming)을 위해 개시되는 시스템들 및 방법들을 사용하는 디바이스일 수 있다. M2M 디바이스(30)는 본 출원에서 설명되는 바와 같은 그리고 도면들에 도시되는 바와 같은 다른 디바이스들과 함께 사용될 수 있다.

프로세서(32)는 범용 프로세서, 특수 목적 프로세서, 종래의 프로세서, DSP(digital signal processor), 복수의 마이크로프로세서들, DSP 코어와 연관되는 하나 이상의 마이크로프로세서들, 제어기, 마이크로제어기, ASIC들(Application Specific Integrated Circuits), FPGA(Field Programmable Gate Array) 회로들, 임의의 다른 타입의 IC(integrated circuit), 상태 머신 등일 수 있다. 프로세서(32)는 신호 코딩, 데이터 처리, 전력 제어, 입력/출력 처리, 및/또는 M2M 디바이스(30)가 무선 환경에서 동작할 수 있게 하는 임의의 다른 기능성을 수행할 수 있다. 프로세서(32)는 송신/수신 엘리먼트(36)에 연결될 수 있는 송수신기(34)에 연결될 수 있다. 도 1c가 프로세서(32)와 송수신기(34)를 별도의 컴포넌트들로서 도시하지만, 프로세서(32) 및 송수신기(34)는 전자 패키지 또는 칩 내에 함께 통합될 수 있다는 점이 이해될 것이다. 프로세서(32)는 애플리케이션-레이어 프로그램들, 예를 들어, 브라우저들, 및/또는 RAN(radio access-layer) 프로그램들 및/또는 통신을 수행할 수 있다. 프로세서(32)는, 예를 들어, 액세스-레이어 및/또는 애플리케이션 레이어에서 같은, 인증, 보안 키 승낙, 및/또는 암호화 동작들과 같은 보안 동작들을 수행할 수 있다.

송신/수신 엘리먼트(36)는 신호들을 M2M 서비스 플랫폼(22)에 송신하거나, 또는 M2M 서비스 플랫폼(22)으로부터 신호들을 수신하도록 구성될 수 있다. 예를 들어, 실시예에서, 송신/수신 엘리먼트(36)는 RF 신호들을 송신 및/또는 수신하도록 구성되는 안테나일 수 있다. 송신/수신 엘리먼트(36)는 WLAN, WPAN, 셀룰러 등과 같은, 다양한 네트워크들 및 에어 인터페이스들을 지원할 수 있다. 실시예에서, 송신/수신 엘리먼트(36)는, 예를 들어 IR, UV, 또는 가시광 신호들을 송신 및/또는 수신하도록 구성되는 방출기/검출기일 수 있다. 또 다른 실시예에서, 송신/수신 엘리먼트(36)는 RF 신호 및 광 신호 양자 모두를 송신 및 수신하도록 구성될 수 있다. 송신/수신 엘리먼트(36)는 무선 또는 유선 신호들의 임의의 조합을 송신 및/또는 수신하도록 구성될 수 있다는 점이 이해될 것이다.

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

송수신기(34)는 송신/수신 엘리먼트(36)에 의해 송신될 신호들을 변조하고, 송신/수신 엘리먼트(36)에 의해 수신되는 신호들을 복조하도록 구성될 수 있다. 위에 언급된 바와 같이, M2M 디바이스(30)는 멀티-모드 능력들을 가질 수 있다. 따라서, 송수신기(34)는 M2M 디바이스(30)가 예를 들어, UTRA 및 IEEE 802.11과 같은 다수의 RAT들을 통해 통신할 수 있게 하는 다수의 송수신기들을 포함할 수 있다.

프로세서(32)는 비-이동식 메모리(44) 및/또는 이동식 메모리(46)와 같은 임의의 타입의 적합한 비-일시적 메모리로부터의 정보를 액세스하고 여기에 데이터를 저장할 수 있다. 비-이동식 메모리(44)는 RAM(random-access memory), ROM(read-only memory), 하드 디스크, 또는 임의의 다른 타입의 메모리 스토리지 디바이스를 포함할 수 있다. 본 출원에 따르면, 메모리는 이하 보다 상세히 설명되고 첨부 도면들에 도시되는 바와 같이 CRT(Content Record Table) 및/또는 CFT(Content Forwarding Table)을 포함할 수 있다. 이동식 메모리(46)는 SIM(subscriber identity module) 카드, 메모리 스틱, SD(secure digital) 메모리 카드 등을 포함할 수 있다. 다른 실시예들에서, 프로세서(32)는, 서버 또는 홈 컴퓨터와 같은, M2M 디바이스(30) 상에 물리적으로 위치되지 않은 메모리로부터의 정보를 액세스하고 여기에 데이터를 저장할 수 있다.

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

프로세서(32)는 M2M 디바이스(30)의 현재 위치에 관한 위치 정보, 예를 들어, 경도와 위도를 제공하도록 구성되는, GPS 칩셋(50)에 또한 연결될 수 있다. M2M 디바이스(30)는 실시예와 일관성을 유지하면서 임의의 적합한 위치-결정 방법에 의해 위치 정보를 취득할 수 있다는 점이 이해될 것이다.

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

도 1d는, 예를 들어 도 1a 및 도 1b의 M2M 서비스 플랫폼(22)이 구현될 수 있는 예시적인 컴퓨팅 시스템(90)의 블록도이다. 컴퓨팅 시스템(90)은 컴퓨터 또는 서버를 포함할 수 있고, 어디에서나, 소프트웨어의 형태로 있을 수 있는 컴퓨터 판독가능 명령어들에 의해, 또는 이러한 소프트웨어가 저장되거나 액세스되는 어떠한 수단에 의해 주로 제어될 수 있다. 이러한 컴퓨터 판독가능 명령어들은 컴퓨팅 시스템(90)으로 하여금 동작하게 하도록 CPU(central processing unit)(91) 내에서 실행될 수 있다. 많은 공지된 워크스테이션들, 서버들, 및 개인용 컴퓨터들에서, 중앙 처리 유닛(91)은 마이크로프로세서라 불리는 단일-칩 CPU에 의해 구현된다. 다른 머신들에서, 중앙 처리 유닛(91)은 다수의 프로세서들을 포함할 수 있다. 코프로세서(81)는 추가적인 기능들을 수행하거나 또는 CPU(91)를 보조하는, 주 CPU(91)와는 별개인, 선택적 프로세서이다. CPU(91) 및/또는 코프로세서(81)는 내장된 시맨틱 명칭들을 갖는 센서형 데이터에 대한 질의들과 같이, 내장된 시맨틱 명명을 위해 개시되는 시스템들 및 방법들에 관련되는 데이터를 수신, 생성, 및 처리할 수 있다.

동작에 있어서, 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)에 전송되는 비디오 신호를 생성하는데 요구되는 전자 컴포넌트들을 포함한다. 디스플레이(86)는 내장된 시맨틱 명칭들을 사용하여 파일들 또는 폴더들 내의 센서형 데이터를 디스플레이할 수 있다. 일 실시예에서, 디스플레이(86)는 도 15에 도시되는 바와 같은 그래픽 사용자 인터페이스를 포함할 수 있다. 여기서, GUI(1500)는 M2M 서버/게이트웨이의 <group> 리소스를 디스플레이 할 수 있다. 예를 들어, GUI(1500)는 디바이스의 그룹 상에 실행될 명령의 리스트를 보여줄 수 있다. 또한, 컴퓨팅 시스템(90)은 도 1a 및 도 1b의 네트워크(12)와 같은 외부 통신 네트워크에 컴퓨팅 시스템(90)을 접속시키는데 사용될 수 있는 네트워크 어댑터(97)를 포함할 수 있다.

본 출원에 따르면, 본 명세서에 설명되는 시스템들, 방법들 및 프로세스들 중 임의의 것 또는 전부가, 컴퓨터 판독가능 스토리지 매체에 저장되는 컴퓨터 실행가능 명령어들, 예를 들어, 프로그램 코드의 형태로 구현될 수 있으며, 이러한 명령어들은, 컴퓨터, 서버, M2M 단말 디바이스, M2M 게이트웨이 디바이스 등과 같은 머신에 의해 실행될 때, 본 명세서에 설명되는 시스템들, 방법들 및 프로세스들을 수행 및/또는 구현한다는 점이 이해된다. 구체적으로, 위에 설명된 단계들, 동작들 또는 기능들 중 임의의 것이 이러한 컴퓨터 실행가능한 명령어들의 형태로 구현될 수 있다. 컴퓨터 판독가능 스토리지 매체는 정보의 저장을 위한 임의의 방법 또는 기술로 구현되는 휘발성 및 비휘발성, 이동식, 및 비-이동식 매체를 포함하지만, 그러한 컴퓨터 판독가능 스토리지 매체는 신호들을 포함하지 않는다. 컴퓨터 판독가능 스토리지 매체는, 이에 제한되는 것은 아니지만, RAM, ROM, EEPROM, 플래시 메모리 또는 다른 메모리 기술, CD-ROM, DVD(digital versatile disks) 또는 다른 광학 디스크 스토리지, 자기 카세트들, 자기 테이프, 자기 디스크 스토리지 또는 다른 자기 스토리지 디바이스들, 또는 원하는 정보를 저장하는데 사용될 수 있는 그리고 컴퓨터에 의해 액세스될 수 있는 임의의 다른 물리적 매체를 포함한다.

디바이스 관리 아키텍처들

DM(Device Management)는 중앙에 위치되는 사이트에 있는 사용자가 원격으로 위치되는 디바이스를 구성, 모니터링, 진단, 및 다른 방식으로 관리할 수 있는 프로세스이다. 디바이스들이 본질적으로 모바일이거나 또는 그들을 액세스하기 어렵게 하는 원격 영역들에 배치될 때 이것은 특히 유용하다. 통상적으로, 중앙 사이트에 있는 DM 서버는 디바이스 상에서 실행될 명령들을 다운로드한다. 디바이스 상에서 실행중인 DM 클라이언트는 이러한 명령들을 수신하고 원하는 동작을 실행하는데 필요한 상태 변경들을 처리한다. DM 서버와 DM 클라이언트 사이의 이러한 통신 메커니즘은 정의되는 프로시저들 및 메시지 포맷들을 사용하여 구현되며, DM 프로토콜로서 알려져 있다. 공지된 DM 프로토콜들 중 2개는 OMA DM 프로토콜과 BBF CPE WAN 관리 프로토콜이다. 다른 최근의 DM 프로토콜은 OMA LWM2M 프로토콜이다.

도 2a는 DM 서버(210)가 M2M 디바이스(230)에서 실행중인 DM 클라이언트들에게 디바이스 관리 명령들을 전송하는 OMA DM 프로토콜 아키텍처(200)를 도시한다. DM 클라이언트는 DM 트리(210A)라고 지칭되는 리소스 구조 내에 MO(Managed Objects)의 세트를 유지한다. 이러한 MO들은 소프트웨어 업데이트들과 같은 디바이스 상의 특정 기능을 관리하는데 사용된다. 이러한 관리 명령들은 DM 트리의 노드들에서 동작하며, 디바이스 내의 상태 변경들을 유발할 수 있다.

도 2b는 디바이스들(230)과 통신하고 있는 DM 서버(210)를 포함하는 DM 레이어(280)에 M2M 인터페이스(270)를 통해 M2M 서비스 레이어(260)로부터 명령들을 전달하기 위한 일반적인 시스템(250)을 도시한다.

디바이스 상에서 실행중인 LWM2M 클라이언트를 LWM2M 서버가 관리하는 것과 유사한 클라이언트-서버 아키텍처를 OMA LWM2M 프로토콜이 제공한다. 도 3은 LWM2M 아키텍처(300) 및 제공되는 상이한 인터페이스들을 도시한다. 이러한 인터페이스들은 LWM2M 서버와 LWM2M 클라이언트 사이의 통신에 중점을 둔다 - LWM2M 서버가 상이한 디바이스들 상의 다수 LWM2M 클라이언트들을 관리할 수 있는 그룹 동작들을 지원하지 않는다. 동작들은 디바이스에 상주하는 오브젝트들(Objects)에 대해 수행된다.

BBF CPE WAN 관리 프로토콜

도 4는 CPE(Customer Premises Equipment) 디바이스(430)를 관리하는데 ACS(Auto-Configuration Server)(410)가 사용되는 BBF TR-069 CPE WAN 관리 프로토콜 아키텍처(400)를 도시한다. ACS는 CPE 디바이스들의 데이터 모델들에 대한 관리 동작들을 수행하는데 RPC(Remote Procedure Calls)를 사용한다. ACS는 파일 운송을 착수하는데 합류할 멀티캐스트 그룹의 상세사항들을 각각의 CPE에 제공할 것이다. 또한, 일부 RPC 호출들에서는 ACS에게 동일한 CPE로부터 다수의 파라미터 값들을 설정하거나 가져오는 능력을 허용하는 제공들이 이루어진다. 이러한 제공들은 대응하는 RPC 호출에 대해서만 가능하게 될 수 있으며 동일한 CPE에 제한된다.

서비스 레이어 아키텍처

SL(Service Layer)은 자신의 사용자들에게 다양한 서비스들을 제공하는 애플리케이션 레이어에서 동작하는 수평적 소프트웨어 플랫폼이다. 제공되는 서비스들 중 일부는 발견, 그룹 관리, 데이터 관리 및 저장소, 위치 서비스 등이다. SL에 의해 제공되는 추가 서비스는, 기존 DM 프로토콜들 및 인프라구조들을 이용하는 디바이스 관리이다. 도 5에 도시되는 바와 같이, IN/CSE/DMG 박스들인 SL(510)과 관리 서버 박스인 DM 서버(520) 사이의 통신은 SL 프리미티브(primitive) API들을 DM 명령들로 변환하는 관리 어댑터(510a)에 의해 취급된다. DMG 내에는 관리 또는 DM 서버에 인터페이스하는 관리 어댑터가 있다. oneM2M 아키텍처 내에는, OMA DM, LWM2M, 및 BBF CWMP 오브젝트들에 매핑되는 관리 타입 리소스들 <mgmtObj> 및 <mgmtCmd>가 정의된다.

하이 레벨 아키텍처

일 양상에 따라, SL과 ML 사이의 그룹 동작들에 대한 예시적인 시스템이 도 6에 도시된다. 도 6에 따르면, 이러한 시스템은 회사의 캠퍼스에 기초한다. 여기서, SL 애플리케이션(610)은 SL 서버(620)와 통신하고 있다. SL 서버(620)는 DM 또는 관리 서버(630)와 통신하고 있다. 관리 서버(630)는 DM 능력들을 갖는 복수의 M2M 디바이스들(640)과 통신하고 있다.

도 7은 oneM2M과 같은 SL 서버와 DM 아키텍처의 통합의 엔드-투-엔드 아키텍처(700)를 도시한다. M2M 프로토콜(705)은 M2M 애플리케이션(701), 예를 들어, IN-AE와 M2M 서버(702), 예를 들어 oneM2M IN-CSE 사이의 통신을 제공한다. M2M 인터페이스(710)는 M2M 서버(702)와 DM 서버(703) 사이의 통신을 제공하는 것으로 현재 정의된다. DM 프로토콜은 DM 서버(703)와 M2M 디바이스(704), 예를 들어 ASN 노드 사이의 통신을 제공한다. 각각의 ASN 노드(704)는 ASN-CSE, ASN-AE 및 DM 클라이언트 소프트웨어를 포함한다. 예를 들어, ASN-CSE(704a) 및 DM 클라이언트(704c) 내의 DMG는 서로 직접 통신할 수 있다.

도 7에서의 실시예에 대한 하이-레벨 호출 흐름들은 도 8에 도시된다. 각각의 단계들은 로마 숫자, 예를 들어, 0, 1, 2로 표기된다. 단계 0에서, IN-CSE 및 DM 서버는 비즈니스 관계를 가지며, M2M 인터페이스를 통해 서로 통신할 수 있다. 또한, 각각의 ASN1 및 ASN2는 디바이스들 상에서 실행중인 CSE, AE 및 DM 클라이언트를 갖는다. ASN1 및 ASN2의 DMG와 DM 클라이언트는 서로 통신할 수 있다.

다음으로, 디바이스 소유자는 단계 1에서 M2M 프로토콜을 통해 IN-CSE에 등록하는 것에 의해 ASN 디바이스들을 관리하도록 M2M 애플리케이션 IN-AE를 동작시킨다. 단계 2에서, 각각의 복수의 ASN 노드들은 M2M 프로토콜을 사용하여 IN-CSE에 등록한다.

IN-AE는 단계 3에 따라 복수의 ASN 노드들을 포함하는 그룹을 마련하라는 IN-CSE에 대한 요청을 착수한다. 이러한 특징을 지원하기 위한 새로운 IN-CSE <group> 속성들이 제안되며, 이하 보다 상세히 설명될 것이다. 또한, IN-CSE 내의 DMG는 이하 보다 상세히 설명되는 바와 같이 DM 서버에서의 디바이스들의 그룹을 생성하는데 새로운 M2M 인터페이스 그룹 관리 프로시저를 사용한다. 또한, DM 서버는 생성된 메시지로 IN-CSE에서의 DMG에 응답한다. IN-CSE는 그 그룹이 성공적으로 생성되었다는 점을 IN-AE에 알린다.

단계 4에서, IN-AE는 DM 명령들의 그룹을 생성하라는 IN-CSE에 대한 요청을 착수한다. 즉, 이하 보다 상세히 설명되는 바와 같이 이러한 특징을 지원하기 위해 새로운 IN-CSE 리소스들 및 속성들이 제안된다. IN-CSE 내의 DMG는 DM 서버에서의 명령들의 그룹을 생성하는데 이러한 새로운 M2M 인터페이스 그룹 관리 프로시저를 사용한다. DM 서버는 생성된 메시지로 IN-CSE에서의 DMG에 응답한다. 결국 IN-CSE는 그 그룹이 성공적으로 생성되었다는 점을 IN-AE에 응답한다.

단계 5에서, IN-AE는 그룹-온-그룹 동작들을 수행하라는 IN-CSE에 대한 요청을 착수한다. 여기거, 이러한 특징을 지원하는 새로운 IN-CSE 어드레싱 및 속성이 제안된다. IN-CSE 내의 DMG는 DM 서버에서 그룹-온-그룹 동작들을 실행하는데 새로운 M2M 인터페이스 그룹 관리 프로시저들을 사용한다. 결국, DM 서버는 수신확인 메시지로 DMG에 응답한다. 각각의 ASN 노드는 DM 명령들이 성공적으로 실행된 후 DM 서버에 응답할 것이다. DM 서버로부터 하나 이상의 응답들을 수신하면, DM 서버는 "실행 성공(execute success)" 메시지로 DMG에 응답한다. 바람직하게는, 모든 ASN 응답이 수신된 후, DM 서버가 실행 성공 메시지로 응답할 것이다. 결국, IN-CSE는 그룹-온-그룹 동작들이 성공적이었다는 점을 IN-AE에 응답한다.

도 9에 도시되는 바와 같이, <group> 리소스는 다음과 같은 자식 속성들을 포함한다: (i) common attributes; (ii) memberType; (iii) CurrentNrOfMembers; (iv) maxNrOfMembers; (v) membersList; (vi) commandsList; (vii) argumentsList; (viii) responseAggregation; (ix) responsePeriod; (x) membersAccessControlPolicyDs; (xi) memberTypeValidate; (xii) consistencyStrategy; (xiii) groupName; (xiv) <subscription>; 및 (xv) <fanOutPoint> and (xvi) commandBlocking.

그룹 관리를 위한 oneM2M 서비스 레이어 강화

다른 실시예에 따르면, oneM2M 아키텍처에 대해 2개의 그룹 관리 강화들이 이루어진다. 제1 강화는 ASN 디바이스들 그룹에에서 다수의 명령들을 수행하는 것을 허용하는 <group> 리소스에 제시된다. 이것은 그룹-온-그룹 동작들이라 한다. 일 실시예에서, 이러한 동작은 oneM2M에서 제공되는 fanOutPoint 어드레싱 메커니즘, 예를 들어, <fanOutPoint>에 대한 강화에 의해 착수될 수 있다. 제2 강화는 execTarget 속성이 그룹 ID를 명시하는 것을 허용하도록 확장되는 <mgmtCmd> 리소스에 도입된다. execTarget에 대한 이러한 추가는 그룹의 멤버들에 대한 관리 명령을 전개(fan out)한다.

아래의 표 2는 DM의 보다 진보된 사용들을 가능하게 하기 위한 기존 oneM2M <group> 리소스 및 <fanOutPoint> 어드레싱 스킴에 대한 제1 강화에 관한 것이다. 특히, 표 2는, 예를 들어, commandsList , commandBlocking , argumentsList , responseAggregation 및 responsePeriod를 포함하는 새로운 속성 추가들을 나열한다. 또한, 표 2는 oneM2M <group> 리소스를 위한 memberType 속성에 대한 변경을 포함한다. 예를 들어, commandList가 명시될 때마다, 타입은 <mgmtObj> 또는 <mgmtCmd> 등과 같은 DM 관련 리소스이어야 한다. 이러한 속성은, OMA DM, OMA LWM2M 또는 BBF CWMP 리소스들, 또는 oneM2M 리소스 또는 속성에 매핑되지 않은 속성들에 또한 관련된다. 그렇게 하는 것에 의해, 이것은 서비스 레이어 리소스들과 관리 레이어 리소스들 사이의 일-대-일 대응관계를 제공하는 것에 의해 DMG에 의한 변환의 노력들을 용이하게 할 것이다. 표 2에서 RW, RO 및 WO는 각각 Read/Write, Read Only, 및 Write Once를 나타낸다. 또한 OA는 표 2에서의 "<groupAnnc> 속성들" 아래의 Optional Announced를 나타낸다.

다른 실시예에 따르면, 위의 속성들이 일단 추가되면, membersList 내의 각각의 엔트리에 대한 명령들 또는 동작들을 명시하는 <group> 리소스가 생성된다. memberType 속성을 <mgmtObj> 또는 <mgmtCmd>로 명시하고 commandsList 속성을 명시하는 것에 의해 명령들의 그룹이 생성될 수 있다.

다른 실시예에 따르면, 다음의 OMA DM 명령들은, argumentsList에 정의되는 바와 같이, 인수들, 예를 들어, $arg#을 사용하여 애플리케이션의 소프트웨어 다운로드 및 설치 동작을 가능하게 한다:

Delete - $arg1/$arg2/name

Create - $arg1/$arg2/name

Update - $arg1/$arg2/URL

Execute - $arg1/$arg2/Install

Retrieve - $arg1/$arg2/activeStatus

이러한 예에서, 그룹의 멤버들의 URI들을 구성하는데 사용되는 2개의 인수들 - $arg1 및 $arg2를 명시하였다. 이하에 제공되는 바와 같은 표 3은 이러한 그룹의 commandsList, membersList, 및 argumentsList 속성들에 대한 엔트리들을 보여준다. argumentsList에는 "{group}"에 대한 문자열 참조가 있다. 이것은 그 인수가 다른 그룹의 멤버로부터 파생됨을 표시한다. argumentsList의 순서는 그 인수를 참조하는데 사용되는 숫자를 제공한다 - $arg1은 {group}을 참조하고 $arg2는 myApp을 참조한다. 이러한 참조들은 다음에 <group> 리소스 내의 다른 속성들에서 사용될 수 있다. CSE에서의 DMG는 팬 아웃 요청들을 생성하기 전에 치환을 수행한다.

또 다른 실시예에 따르면, 명령들의 그룹이 일단 생성되면, 그 명령을 적용하기 위한 디바이스들의 그룹이 지정될 수 있다. 디바이스 그룹은 정상적인 oneM2M <group> 프로시저에서 생성될 것이다. 그 그룹의 목적이 DM 서버를 통해 디바이스들을 관리하는 것이면, membersList URI들은 [deviceInfo] <mgmtObj> 리소스의 deviceLabel 속성을 지목한다. 이것은 그룹의 membersType이 <mgmtObj> 리소스의 것일 것을 요구한다. 일 실시예에서, 본 출원은 그룹-온-그룹 동작을 트리거하기 위해 fanOutPoint 이후 <group> 리소스를 명시하는 능력을 포함하도록 fanOutPoint 가상 리소스의 어드레싱 스킴을 확장하는 것을 제안한다. fanOutPoint를 어드레싱하는 2가지 기존 방법들은: (i) /cseBase/.../<group>/fanOutPoint; 및 (ii) /cseBase/.../<group>/fanOutPoint/<relative_URI>를 포함한다.

대안적으로, <relative_URI>는 membersList URI에 의해 제공되는 부모 리소스의 자식 리소스 또는 속성을 명시한다. 그룹-온-그룹 동작들을 가능하게 하기 위해, 본 개시내용은 제3 어드레싱 스킴: /cseBase/.../<group>/fanOutPoint/<absolute_URI>를 추가하는 것을 제안한다. 여기서 <absolute_URI>는 memberType <mgmtObj> 또는 <mgmtCmd>의 <group> 리소스를 지목한다. 더욱이, CSE는 여전히 요청을 전개할 것이지만 원래 요청의 동작을 사용하는 대신에, <absolute_URI>에 의해 지목되는 그룹에 명시되는 명령들을 사용할 것이다.

이러한 그룹-온-그룹 메커니즘 및 호출 흐름이 도 10에 도시된다. IN-AE는 memberType이 <mgmtObj>로 설정되고 표 2에 명시되는 속성들을 사용하여 /in-cse/in-ae/myCommands <group> 리소스를 생성한다. 응답들이 어떻게 처리되는지 표시하기 위해 responseAggregation이 여기서 또한 명시될 수 있다는 점을 관련분야에 숙련된 자들에게 또한 예상된다. 초기 사안으로서, 단계 0은 도 8에서 위에 설명된 바와 같이 DM 서버와 IN-CSE 사이의, 그리고 IN-AE와 IN-CSE 사이의 완료된 부트스트랩 및 등록 프로시저를 설명한다. 단계 1에서, IN-AE는 "/in-cse/in-ae/myDevices"라고 하는 <group> 리소스를 생성할 것을 요청한다. 이러한 요청에서, memberType은 <mgmtObj>로 설정된다. commandList는 Delete, Create, Update, Execute 및 Retrieve로 설정된다. memberList는 $arg1/$arg2//name, $arg1/$arg2/name, $arg1/$arg2/URL, $arg1/$arg2/Install, $arg1/$arg2/activeStatus로 설정된다. argumentsList는 $groupID, myApp로 설정된다. 단계 1a에서, IN-CSE에서의 DMG(702a)는 myCommands <group> 리소스를 생성한다. 단계 1b에서, DMG는 명령 그룹을 생성하라는 그룹 관리 요청 API를 M2M 인터페이스를 통해 DM 서버에 전송한다. 단계 1c에서, DMG는 생성된 응답을 IN-AE에 전송한다.

단계 2에서, IN-AE는 /in-cse/in-ae/myDevices라고 하는 디바이스 <group>을 생성하라는 요청을 착수한다. 이러한 그룹은 다음과 같은 속성들: memberType=<mgmtObj> 및 membersList={/in-cse/mn-cse1/node, /in-cse/mn-cse2/node, /in-cse/mn-cse3/node}을 포함한다. DMG(702a)는 단계 2a에서 myDevices <group> 리소스를 생성한다. 단계 2b에서, DMG는 디바이스 그룹을 생성하라는 그룹 관리 요청 API를 M2M 인터페이스를 통해 DM 서버에 전송한다. 단계 2c에서, DMG는 생성된 응답을 IN-AE에 전송한다. 단계들 2, 2a, 2b 및 2c는 단계들 1, 1a, 1b 및 1c의 이전에, 이후에 또는 이와 동시에 발생할 수 있다는 점이 관련분야에 숙련된 자에게 예상된다.

다음으로, 단계 3에서, IN-AE는 이미지가 저장되는 URL 및 개별 명령들에 대한 다른 값들을 포함하는 페이로드를 갖는 "/in-cse/in-ae/myCommands/fanOutPoint/in-cse/in-ae/myDevices"를 생성할 것을 DMG에게 요청한다. IN-AE는 다음 명령을 발행하여 그룹-온-그룹 동작을 트리거한다. 이러한 경우에서의 트리거는 memberType <mgmtObj>가 있는 <group> 리소스에 대한 절대 URI에 의해 제공된다. 이러한 예에서는, Create 동작만 지원된다.

op: CREATE

fr :/in-cse/in-ae

to :/in-cse/in-ae/myCommands/fanOutPoint/in-cse/in-ae/myDevices

cn: [페이로드는 이미지가 저장된 URL 및 개별 명령들에 대한 다른 값들을 포함함]

gid: [myCommands의 그룹 식별자]

다음으로, 단계 4에서, IN-CSE 내의 DMG는 이러한 요청을 그룹-온-그룹 요청으로서 처리한다. DMG는 groupMgmtReq()를 실행하기 전에 argumentsList에 의해 명시되는 치환들을 수행한다. 이러한 예에서, 인수 $arg1은 {group}으로서 명시되었으며, DMG가 치환을 수행할 때, $arg1 인수를 단계 2에서 생성되는 그룹의 각각의 멤버로 대체할 것이다. $arg2에 대해서, 이러한 치환이 비교적 간단한다: $arg2를 myApp로 대체함. 아래의 표 4는 모든 치환들이 완료된 후의 결과를 보여준다.

또한, DMG는 단계 5에서 그룹-온-그룹 동작을 실행하라는 groupMgmtReq API를 M2M 인터페이스를 통해 DM 서버에 전송한다.

DM 목적들을 위한 그룹 관리 프로시저들의 사용은 서비스 레이어 리소스에들에 또한 적용될 수 있다는 점이 관련분야에 숙련된 자에게 예상된다. 이러한 경우들에서, <group> 리소스의 memberType은 <mgmtObj> 또는 <mgmtCmd> 타입 리소스들이 아니며 그룹 멤버들에 대해 기본 CRUD 동작들이 수행할 수 있다. commandsList 및 argumentsList 속성들이 그룹-온-그룹 동작들과 더불어 사용될 수 있다.

본 출원의 또 다른 양상에서, oneM2M에서의 그룹 관리 동작들에 대한 강화는 <mgmtCmd> 타입 리소스들의 사용을 포함할 수 있다. 이러한 리소스들은 BBF CWMP(또는 TR-069) 프로토콜에서 사용되는 것들과 같은 관리 명령들을 나타내기 위해 IN-CSE의 리소스 트리에서 생성된다. <mgmtCmd> 리소스는 관리되는 엔티티에 대해 IN-AE 또는 CSE에 의해 생성된다. cmdType 및 execReqArgs 속성들은 각각 <mgmtCmd>와 관련된 명령 및 명령 인수들의 타입을 제공한다. 이러한 정보는 관리 어댑터에 의해 <mgmtCmd>를 RPC(Remote Procedure Call)로 변환하는데 사용된다. <mgmtCmd>가 일단 명시되면, AE는 원격 엔티티에 대해 표시된 관리 동작을 수행하기 위해 <mgmtCmd> 리소스를 실행할 수 있다. 이것은 페이로드없이 <mgmtCmd> 리소스의 execEnable 속성에 대한 업데이트를 수행하는 것에 의해 행해진다. 이러한 요청의 "to:" 필드는 관리 명령이 실행되는 원격 엔티티 CSE-ID를 제공한다. 호스팅 CSE가 기존 디바이스 관리 프로토콜을 사용하여 관리 명령을 수행한 후, 관리 동작을 추적하기 위해 <execInstance> 하위 리소스를 생성한다. 그러면 AE는 차후에 이러한 <execInstance> 리소스로부터 상태를 검색할 수 있다.

다른 실시예에서, 그룹 동작들을 지원하기 위해 <mgmtCmd> 리소스에 강화가 추가될 수 있다. 이러한 강화는 위에 설명된 "execTarget" 속성을 명시하는 것에 의해 제공된다. execTarget 속성은 <mgmtCmd>에 대한 타겟들을 명시함에 있어서 그 속성에 대한 유효한 값들로서 그룹 ID를 포함하도록 확장될 수 있다. execEnable에 대해 업데이트가 수행될 때, 호스트 CSE는 <group> 리소스의 membersList 속성에서 명시되는 노드들에 대한 <mgmtCmd>를 실행한다.

또 다른 실시예에서, execTarget 속성 및 <group> 리소스의 조합을 포함하는 <mgmtCmd> 그룹 동작에 대한 강화가 설명된다. AE는 <group> 리소스의 membersList에 <mgmtCmd> 리소스들의 그룹을 명시할 수 있다. execTarget 속성을 사용하여 타겟화된 노드 또는 심지어 그룹 ID에 대해 각각의 <mgmtCmd> 리소스들 내에 명시할 수도 있다. 이것은 <mgmtCmd> 리소스에 대해 위에 명시된 그룹-온-그룹 동작들을 강화하기 위한 대안적 수단이다. <group> 리소스가 명시된 후, <mgmtCmd> 리소스의 실행은 위에서 상세히 개시된 fanOutPoint 어드레싱 스킴을 사용하여 트리거된다.

도 11에 도시되는 바와 같은 예시적인 실시예에 따르면, <mgmtCmd> execTarget 속성의 사용을 수반하는 그룹-온-그룹 동작(1100)의 예가 개시되어 있다. 2개의 그룹들이 생성된다. 그룹1(1110)은 3개의 mgmtCmd 리소스들의 URI들을 포함하고, 그룹2(1120)는 2개의 디바이스 URI들을 포함한다. 각각의 <mgmtCmd> 리소스들의 execTarget 속성은 group2의 URI를 포함한다. 그룹-온-그룹 동작은 다음의 동작: Update../group1/fanOutPoint/execEnable에 의해 트리거된다. 그러면 호스트 CSE는 임의의 순서로 제한되지 않는 다음과 같이 이러한 요청을 처리한다:

group1의 membersList를 추출하는 동안, 호스트 CSE는 다음의 동작들을 실행한다:

Update../mgmtCmd1/execEnable

Update../mgmtCmd2/execEnable

Update../mgmtCmd3/execEnable

MgmtCmd1의 execTarget은 그룹2의 URI를 명시한다. 이것은 mgmtCmd1로 하여금 위에서 명시된 바와 같이 dev1 및 dev2에서 실행되게 한다. 유사하게, mgmtCmd2의 execTarget은 group2의 URI도 명시한다. 이것은 mgmtCmd2로 하여금 위에서 명시된 바와 같이 dev1 및 dev2에서 실행되게 한다. MgmtCmd3의 execTarget은 group2의 URI도 명시한다. 이것은 mgmtCmd3으로 하여금 위에 명시된 바와 같이 dev1 및 dev2에서 실행되게 한다. 특히, mgmtCmd들 1, 2 및 3 각각의 성공적 실행에 대해, 대응 디바이스에 대한 관련 <execInstance> 리소스가 생성된다. 이것은 도 11에서 3개의 mgmtCmd 리소스들 각각 하에서 execInstance1 및 execInstance2 리소스들로서 도시된다. 이러한 <execInstance> 리소스의 execTarget 속성은 <mgmtCmd>가 실행된 group2의 멤버 ID를 지목한다. 이러한 <execInstance> 리소스들은 그룹-온-그룹 요청을 처리한 호스트 CSE에 의해 생성된다.

M2M 인터페이스 그룹 관리 프로시저들

DM 그룹 관리 프로시저는 memberType <mgmtObj> 또는 <mgmtCmd>를 갖는 oneM2M <group> 리소스에서 동작이 수행될 때마다 트리거될 수 있다. 이러한 요청들은, 다음에 임의의 인수들의 치환을 수행하고 그 결과를 애플리케이션에서 위에서 설명된 바와 같이 적절한 그룹 관리 API 호출로 변환할, DMG에 의해 처리된다. 3개의 주요 그룹 동작들은 다음과 같다:

디바이스 그룹 동작들: 이러한 동작들은 DM을 수행할 디바이스들의 그룹을 사용자가 조작(CRUD)하게 한다. 이러한 타입의 그룹과 관련된 memberType은 서비스 레이어 지향 그룹 동작들과 구별하기 위해 <mgmtObj> 또는 <mgmtCmd>이다. 이것은 처리를 위해 요청이 DMG에 전달되어야 한다는 점을 CSE에게 표시할 것이다.

명령 그룹 동작들: 이러한 동작들은 디바이스 또는 디바이스들의 그룹 상에서 수행할 명령들 그룹(DM이건 아니건)을 사용자가 조작(CRUD)하게 한다. 이러한 타입의 그룹과 관련된 memberType은 <mgmtObj> 또는 <mgmtCmd>이며, commandsList 속성은 서비스 레이어 지향 그룹 동작들과 구별되도록 명시되어야 한다. 이것은 처리를 위해 요청이 DMG에 전달되어야 한다는 점을 CSE에게 표시할 것이다.

그룹-온-그룹 동작: 이러한 동작은 명령들의 시퀀스가 디바이스들의 그룹 상에서 수행되는 그룹-온-그룹 동작을 사용자가 착수하게 한다. 이러한 동작은 fanOutPoint 가상 리소스 이후 memberType <mgmtObj>의 <group> 리소스를 지목하는 절대 URI가 첨부되는 fanOutPoint에 대한 새로운 어드레싱 스킴을 사용하여 트리거된다.

도 12는 그룹 관리 프로시저들이 어떻게 동작하는지를 도시하는 예시적인 호출 흐름을 보여준다. 도 12에서의 단계들은 로마 숫자로 표시된다. 여기서, 2개의 ASN 노드들은 IN-CSE를 통해 IN-AE에 의해 관리된다.

초기 사안으로서, 위 도 8에 표시된 등록 및 부트스트랩 프로시저들이 단계 0에서 이용된다. 다음으로, 단계 1에서, IN-AE는 memberType=<mgmtObj>인 myDevices <group> 리소스를 생성할 것을 요청하고, membersList URI들은 [deviceInfo] 리소스의 deviceLabel 속성들을 지목한다. 다음으로 DMG는 필요하다면 단계 2에서 치환을 먼저 수행하는 것에 의해 이러한 요청을 처리한다. argumentsList 속성이 명시되고 인수 참조들($arg#로 표기됨)이 사용되면, DMG는 발견되는 각각의 인수 참조들에 대해 argumentsList에서의 값들을 치환한다. 다음음로 DMG는 단계 3에 따라 위에서 설명된 바와 같은 groupMgmtReq() API를 호출한다. 이러한 경우, 요청의 타입은 디바이스 그룹들에 대해 0이다. 단계 4에서, DM 서버는 성공 응답 코드로 응답한다. 단계 5에서, IN-CSE는 생성된 응답을 IN-AE에 전송한다.

다음으로, IN-AE는 memberType=<mgmtObj>인 myCmds <group> 리소스를 생성할 것을 요청하고, commandsList 속성에 명령들의 리스트를 명시한다(단계 6). DMG는 필요하다면 먼저 치환을 수행하는 것에 의해 명령 그룹 요청을 처리한다(단계 7). argumentsList 속성이 명시되고 인수 참조들($arg#로 표기됨)이 사용되면, DMG는 발견되는 각각의 인수 참조들에 대해 argumentsList에서의 값들을 치환한다. 단계 8에서, DMG는 표 5에서의 groupMgmtReq() API를 호출한다. 이러한 경우, 요청의 타입은 명령 그룹들에 대해 1이다. DM 서버는 성공 응답 코드로 응답한다(단계 9). 또한, IN-CSE는 생성된 응답을 IN-AE에 전송한다(단계 10). 단계들 6-10은 단계들 1-5 이전에, 이후에 또는 동시에 발생할 수 있다는 점이 예상된다.

다른 실시예에 따르면, IN-AE는 다음과 URI: in-cse/in-ae/myCmds/fanOutPoint/in-cse-in-ae/myDevices를 타겟으로 하는 것에 의해 그룹-온-그룹 동작을 착수한다(단계 11). 절대 URI는 in-cse/in-ae/myDevices이다. 다음으로, DMG는 필요하다면 먼저 치환을 수행하는 것에 의해 이러한 요청을 처리한다(단계 12). argumentsList 속성이 명시되고 인수 참조들($arg#로 표기됨)이 사용되면, DMG는 발견되는 각각의 인수 참조에 대해 argumentsList에서의 값들을 치환한다. 다음으로 DMG는 위에서 설명된 groupMgmtReq() API를 호출한다(단계 13). 이러한 경우에, 요청의 타입은 그룹-온-그룹 동작들에 대해 2이고, RspIndicator는 그룹 멤버들의 개별 응답을 요청하는 1로 설정된다. 단계 14에서, DM 서버는 ASN1에서 실행중인 DM 클라이언트와의 DM 세션을 확립하고, myCmds 그룹에서의 명령들을 실행한다. 다음으로, DM 서버는 성공에 대해서는 code=0로 그리고 그로부터 응답이 수신되었던 멤버를 표시하기 위해서는 GrpMember=ASN1인 응답을 전송한다(단계 15). IN-CSE는 성공 응답을 IN-AE에 전송한다(단계 16).

단계들 17-19는 단계들 14-16과 실질적으로 동일하다. 즉, DM 서버는 ASN2에서 실행중인 DM 클라이언트와의 DM 세션을 확립하고, myCmds 그룹에서의 명령들을 실행한다(단계 17). 다음으로 DM 서버는 성공에 대해서는 code=0로 그리고 그로부터 응답이 수신되었던 멤버를 표시하기 위해서는 GrpMember=ASN2인 응답을 전송한다(단계 18). 또한, IN-CSE는 성공 응답을 IN-AE에 전송한다(단계 19).

M2M 인터페이스 그룹 관리 API

또 다른 실시예에 따르면, DMG가 argumentsList에서 발견되는 치환을 일단 완료하면, 이러한 요청을 groupMgmtReq() API 호출로 변환한다. 예시적인 포맷이 표 5에 제공된다. RspIndicator는 개별 디바이스들로부터의 응답이 어떻게 처리되는지 명시할 수 있다. 이것은 처리 대기 시간들이 매우 가변적이고 요청자가 명령들 상태에 대한 실시간 업데이트들을 원하는 경우들에 유용한다. 일부 경우들에서, 디바이스들은 휴면 중일 수 있으며, 명령들이 실행될 수 있거 전에 오랜 시간이 걸릴 수 있다. 이러한 경우에 개별 응답들을 수신하는 능력은 어떤 디바이스들이 동작들을 완료했는지를 서비스 레이어가 아는데 유용하다.

DM 서버가 되돌려 전송하는 응답의 예가 표 6에 제공된다. 개별 응답들이 요구될 때(RspIndicator> 0), DM 서버는 표 6에 명시되는 바와 같이 그룹 멤버를 표시해야 한다. 이것은 요청자가 응답을 멤버에 상관시키게 한다.

관리 레이어 업데이트들

다른 실시예에서도, 관리 레이어 아키텍처들 내의 관리 레이어 업데이트들이 설명된다. 여기서, 업데이트들은 M2M 인터페이스 및 강화된 그룹 관리 프로시저들을 지원할 필요가 있다. 새로운 M2M 인터페이스 그룹 관리 프로시저들에 대한 응답 메시지 포맷들은 위에 상세히 설명된 바와 같다. 강화된 그룹 관리 프로시저들의 지원은 아래에서 보다 상세히 설명된다.

도 13은 본 개시내용에서 명시되는 강화된 그룹 관리 동작들을 지원하는데 사용될 수 있는 OMA DM 프로토콜에서의 제안된 그룹 MO의 예시적인 실시예를 도시한다. MO 내에는, 3개의 주요 내부 노드들이 정의된다: CommandGroup, DeviceGroup 및 GroupStatus. CommandGroup 노드는 명령들의 그룹을 구성하기 위해 제공되며, 1로 설정된 groupMgmtReq의 타입 파라미터에 매핑된다. 이러한 타입을 수반하는 요청은 이러한 노드에 자식 리소스들을 생성할 것이다. DeviceGroup 노드는 디바이스들을 함께 그룹화하는 기능을 제공하며, 0으로 설정된 groupMgmtReq의 타입 파라미터에 매핑된다. 디바이스들의 그룹을 생성하라는 요청이 이루어질 때, 이러한 내부 노드 아래에 자식 노드가 생성된다. 마지막으로, 그룹-온-그룹 동작들을 처리하는데 DM 서버에 의해 GroupStatus 노드가 사용된다. DM 서버는 RspIndicator 설정에 기초하는 상태를 제공하고 각각의 상태가 획득됨에 따라 그 상태를 세이브 오프(save off)하기 위해 GroupStatus에 자식 노드를 생성할 것이다. 전체 그룹 관리 요청이 서비스된 후, 자식 노드는 삭제될 것이다.

도 14는, 예를 들어, 도 12로부터의 관리 동작들의 그룹을 도시한다. 아래에 단계들이 제공된다. 단계 1(도시되지 않음)에서, IN-CSE는 IN-AE로부터의 디바이스 그룹 요청을 처리한다. 다음으로, IN-CSE 내의 DMG는 디바이스 그룹 요청이 이루어진 것을 표시하는 type=0인 groupMgmtReq를 전송한다(단계 2). 이러한 요청은 도 14에 도시되는 "2."와 "myDevices" 사이의 라인에 의해 도시되는 바와 같이 myDevices 노드 및 모든 자식 노드들을 생성한다. 예시적인 요청이 아래 표 7에 보여진다.

단계 3에서, DM 서버는 성공 응답 코드를 IN-CSE에 제공한다. 다음으로, IN-CSE는 단계 4에서 IN-AE로부터의 명령 그룹 요청을 처리한다(도시되지 않음). 그 후, IN-CSE 내의 DMG는 명령 그룹 요청이 이루어진 것을 표시하는 type=1인 groupMgmtReq를 전송한다(단계 5). 이러한 요청은 도 14에 도시되는 "5."와 "myCommands" 사이의 라인에 의해 도시되는 바와 같이 myCommands 노드 및 모든 자식 노드들을 생성한다. 예시적인 요청이 아래 표 8에 보여진다.

다음으로, DM 서버는 성공 응답 코드를 IN-CSE에 제공한다(단계 6). IN-CSE는 단계 7에서 IN-AE로부터의 그룹-온-그룹 요청을 처리한다(도시되지 않음). 이어서, IN-CSE 내의 DMG는 그룹-온-그룹 요청이 이루어졌고 개별적인 응답들은 그들이 이용가능할 때마다 요청된다는 점을 표시하는 type=2 및 RspIndicator=1인 groupMgmtReq를 전송한다(단계 8). 이러한 요청은 GrpLabels 파라미터에서 2개의 레이블을 명시한다: myCommands 및 myDevices. 그러면 DM 서버는 도 14에 도시되는 "8."과 "myGrpStat" 사이의 라인에 의해 도시되는 바와 같이 myGrpStat 노드 및 모든 자식 노드들을 생성할 것이다. myGrpStat 노드는 각각의 디바이스의 실행 상태를 추적하기 위해 ./GroupMO/GroupStatus/myGrpStatus/Devices 아래에 2개의 자식 노드들을 포함한다. 예시적인 요청이 아래 표 9에 보여진다.

또한, 명령들 cmd1 및 cmd2가 교환되는 DM 세션이 ASN1과 DM 서버 사이에 확립된다(단계 9). DM 세션이 완료될 때 그리고 실행이 성공적이면, ./GroupMO/GroupStatus/myGrpStatus/Devices/dev1/status 노드는 DM 서버에 의해 "Pass"로 설정된다.

그 후, DM 서버는 도 14에 도시되는 바와 같이 "10."으로부터의 라인에 의해 도시되는 바와 같이 ASN1이 성공적으로 완료되었음을 표시하기 위해 groupMgmtRsp() 메시지를 IN-CSE에 전송한다.

한편, 다른 DM 세션이 ASN2와 DM 서버 사이에 확립된다(단계 11). 다시 한 번, 관리 명령들이 교환된다. DM 세션이 완료될 때 그리고 실행이 성공적이면, ./GroupMO/GroupStatus/myGrpStatus/Devices/dev2/status 노드가 DM 서버에 의해 "Pass"로 설정된다.

다음으로 DM 서버는 도 14에 도시되는 바와 같이 "12."로부터의 라인에 의해 도시되는 바와 같이 ASN2가 성공적으로 완료되었음을 표시하기 위해 groupMgmtRsp() 메시지를 IN-CSE에 전송한다(단계12).

OMA LWM2M 그룹 관리 지원

심지어 다른 실시예에 따르면, 그룹 관리 지원은 LWM2M 프로토콜에 대한 표 10 및 표 11에서 발견될 수 있다. 이러한 표들의 설계는 본질적으로 평탄하도록 그리고 계층구조를 제한하도록 설계되는 LWM2M 오브젝트들의 사상을 따른다. 결과적으로, 디바이스 그룹과 명령 그룹은 오브젝트 ID = 10인 그룹 오브젝트로 조합되고, GroupStatus 오브젝트는 오브젝트 ID = 11인 그룹-온-그룹 동작들의 상태를 포함한다. 이러한 2개의 오브젝트들은 LWM2M 서버에 대해서만 이용가능할 것이며, M2M 인터페이스를 통해 그룹 통신을 지원하는데 사용된다.

위 리소스들의 생성 및 업데이트들은 본 명세서에 설명되는 OMA DM에 대한 경우의 것과 유사한 방식으로 발생한다.

BBF CWMP 그룹 관리 지원

아래의 표 12는 본 개시내용에서 제안되는 강화된 그룹 관리 프로시저들을 지원하는데 사용될 수 있는 BBF CWMP 프로파일의 예시적인 실시예를 도시한다. 이러한 프로파일은 commandgroup, devicegroup 및 groupstatus에 대해 각각 하나인 3개의 주요 섹션들로 구분된다. 이러한 프로파일은 명령들 및 디바이스들의 그룹을 관리하는 기능을 제공하기 위해 ACS에서 호스팅될 것이다. 다음으로 groupstatus 데이터 모델은 필요하다면 개별 명령들 및 디바이스들의 상태를 제공한다. 그룹-온-그룹 동작은 .group.groupstatus.{i} 엔트리들의 생성을 트리거하고, 요청이 완전히 서비스될 때까지 유지될 것이다.

위 리소스들의 생성 및 업데이트들은 위에 설명된 바와 같이 OMA DM에 대한 경우의 것과 유사한 방식으로 발생한다.

본 출원의 또 다른 양상에 따르면, 컴퓨터 판독가능 또는 실행가능 명령어들을 저장하기 위한 비-일시적 컴퓨터 판독가능 또는 실행가능 스토리지 매체가 개시된다. 이러한 매체는 도 8, 10 및 12에 따른 복수의 호출 흐름들에서 위에 설명된 바와 같은 하나 이상의 컴퓨터 실행가능 명령어들을 포함할 수 있다. 이러한 컴퓨터 실행가능 명령들은 IN-CSE, DM 서버 및 ASN 디바이스들을 포함하는 디바이스들 상에서 이용되는 위에 설명된 프로세서와 같은 프로세서에 의해 실행될 수 있다.

시스템들 및 방법들이 현재 구체적인 양상들인 것으로 고려되는 것과 관련하여 설명되었지만, 본 출원이 개시된 양상들에 제한될 필요는 없다. 청구항들의 사상 및 범주 내에 포함되는 다양한 수정들 및 유사한 배열들을 커버하도록 의도되고, 이들의 범위는 모든 그러한 수정들 및 유사한 구조들을 아우르도록 가장 넓은 해석에 따라야 한다. 본 개시내용은 이하의 청구항들의 임의의 그리고 모든 양상들을 포함한다.

Claims (20)

1. 비-휘발성 메모리 및 프로세서를 포함하며 그룹-온-그룹 동작들을 수행하기 위한 컴퓨터-구현 장치로서, 상기 비-휘발성 메모리는, 상기 프로세서에 의해 실행될 때, 상기 장치로 하여금,
   URI(uniform resource indicator)에 정의되는 그룹 리소스의 명령들을 포함하는 상기 그룹-온-그룹 동작들을 착수하라는 요청을 수신하는 단계;
   상기 요청을 처리하는 단계; 및
   디바이스들 상에서 상기 명령들을 실행하라는 그룹 관리 요청 API를 관리 서버에 전송하는 단계
   를 수행하게 하는 컴퓨터 실행가능 명령어들을 저장하는 장치.
2. 제1항에 있어서,
   상기 프로세서는 상기 디바이스에 의한 상기 명령들의 실행을 표시하는 응답을 상기 관리 서버로부터 수신하는 명령어들을 실행하는 장치.
3. 제1항에 있어서,
   디바이스 그룹을 생성하라는 그룹 관리 요청 API를 상기 관리 서버에 전송하는 단계를 더 포함하는 장치.
4. 제3항에 있어서,
   명령 그룹을 생성하라는 그룹 관리 요청 API를 상기 관리 서버에 전송하는 단계를 더 포함하는 장치.
5. 제4항에 있어서,
   상기 디바이스 및 명령 그룹들이 생성되었다는 회답을 상기 관리 서버로부터 수신하는 단계; 및
   상기 디바이스 및 명령 그룹들이 생성되었다는 회답을 디바이스 소유자에게 전송하는 단계
   를 더 포함하는 장치.
6. 제1항에 있어서,
   상기 명령 그룹은 memberType, membersList, commandsList, commandBlocking, argumentsList, responseAggregation, responsePeriod 및 이들의 조합들로부터 선택되는 그룹 리소스를 포함하는 장치.
7. 제6항에 있어서,
   상기 memberType은 <mgmtObj> 또는 <mgmtCmd>인 장치.
8. 제7항에 있어서,
   상기 <mgmtCmd>는 execTarget, execInstant 및 이들의 조합들로부터 선택되는 속성을 포함하는 장치.
9. 제1항에 있어서,
   상기 장치는 서버인 장치.
10. 비-휘발성 메모리 및 프로세서를 포함하며 M2M 인터페이스에서 그룹-온-그룹 동작들을 확립하기 위한 컴퓨터-구현 장치로서, 상기 비-휘발성 메모리는, 상기 프로세서에 의해 실행될 때, 상기 장치로 하여금,
    디바이스들의 그룹을 관리하라는 등록 요청을 수신하는 단계;
    디바이스 그룹을 생성하라는 요청을 수신하는 단계; 및
    상기 디바이스들의 그룹에 대해 상기 디바이스 그룹을 생성하라는 상기 수신된 요청을 실행하는 단계
    를 수행하게 하는 컴퓨터 실행가능 명령어들을 저장하는 장치.
11. 제10항에 있어서,
    상기 프로세서는 상기 디바이스들의 그룹으로부터 등록 통지를 수신하도록 추가로 구성되는 장치.
12. M2M 인터페이스에서 그룹-온-그룹 동작들을 확립하기 위한 컴퓨터-구현 방법으로서,
    디바이스들의 그룹을 관리하라는 등록 요청을 수신하는 단계;
    상기 디바이스들의 그룹으로부터 등록 통지를 수신하는 단계;
    디바이스 그룹을 생성하라는 요청을 수신하는 단계; 및
    상기 디바이스들의 그룹에 대해 상기 디바이스 그룹을 생성하라는 상기 수신된 요청을 실행하는 단계
    를 포함하는 방법.
13. 제12항에 있어서,
    명령 그룹을 생성하라는 요청을 수신하는 단계; 및
    상기 디바이스들의 그룹에 대해 상기 명령 그룹을 생성하라는 상기 수신된 요청을 실행하는 단계
    를 더 포함하는 방법.
14. 제12항에 있어서,
    상기 디바이스 그룹을 생성하라는 그룹 관리 요청 API를 관리 서버에 전송하는 단계; 및
    명령 그룹을 생성하라는 그룹 관리 요청 API를 관리 서버에 전송하는 단계
    를 더 포함하는 방법.
15. 제14항에 있어서,
    상기 디바이스 및 명령 그룹들이 생성되었다는 회답을 상기 관리 서버로부터 수신하는 단계; 및
    상기 디바이스 및 명령 그룹들이 생성되었다는 회답을 디바이스 소유자에게 전송하는 단계
    를 더 포함하는 방법.
16. 제12항에 있어서, 상기 명령 그룹은 memberType, membersList, commandsList, commandBlocking, argumentsList, responseAggregation, responsePeriod 및 이들의 조합들로부터 선택되는 그룹 리소스를 포함하는 방법.
17. M2M 인터페이스에서 그룹-온-그룹 동작들을 수행하기 위한 컴퓨터-구현 방법으로서,
    URI(uniform resource indicator)에 정의되는 그룹 리소스의 명령들을 포함하는 상기 그룹-온-그룹 동작들을 착수하라는 요청을 수신하는 단계;
    상기 요청을 처리하는 단계;
    디바이스들 상에서 상기 명령들을 실행하라는 그룹 관리 요청 API를 관리 서버에 전송하는 단계; 및
    상기 디바이스에 의한 명령들의 실행 상태를 표시하는 응답을 상기 관리 서버로부터 수신하는 단계
    를 포함하는 방법.
18. 제17항에 있어서,
    상기 처리 단계는 상기 그룹 리소스의 argumentList에 위치되는 인수 참조들(argument references)을 값들로 치환하는 단계를 포함하는 방법.
19. 제17항에 있어서,
    상기 URL(uniform resource locator)은 상기 요청을 전개(fan out)하기 위한 절대 URI(uniform resource identifier)를 포함하는 방법.
20. 제17항에 있어서,
    디바이스 그룹을 생성하라는 그룹 관리 요청 API를 관리 서버에 전송하는 단계; 및
    명령 그룹을 생성하라는 그룹 관리 요청 API를 관리 서버에 전송하는 단계
    를 더 포함하는 방법.

Images