KR20190065372A - 일반적 상호연동 및 확장성을 위한 서비스 계층 리소스 관리 - Google Patents

Abstract

서비스 계층 상호연동 및 리소스 확장성을 지원하기 위해, 경량의 동적 메커니즘들이 제공된다. 예를 들어, 본 명세서에 개시된 하나의 메커니즘은 제3자 기술 리소스들을 표현하기 위해 서비스 계층 리소스들의 커스텀 속성들을 지정하는 것을 허용하는 새로운 서비스 계층(SL) 리소스 정의 등록 절차를 정의하는 것을 포함한다. 본 명세서에 개시된 제2 메커니즘은 서비스 계층 리소스들을 제3자 데이터 모델들에 맵핑하고 새로운 상호연동된 리타겟팅 표시자를 서비스 계층에 제공하기 위해 새로운 SL 데이터 모델 맵핑 등록 절차를 정의하는 것을 포함한다. 또한, 본 명세서에 개시된 제3 메커니즘은 데이터 모델 맵핑에 의해 제공되는 상호연동된 리타겟팅 표시자에 기초하여 요청들을 상호연동된 리소스들에 지능적으로 리타겟팅하기 위해 SL 일반적 상호연동 절차를 정의하는 것을 포함한다.

Description

일반적 상호연동 및 확장성을 위한 서비스 계층 리소스 관리

관련 출원들에 대한 상호 참조

본 출원은 2016년 10월 7일자로 출원된 미국 특허 가출원 제62/405,534호의 혜택을 주장하며, 그 개시내용은 전체가 참조에 의해 본 명세서에 통합된다.

oneM2M과 같은 현재의 서비스 계층 상호연동 아키텍처들은 제3자 기술들로부터의 노드들 또는 디바이스들을 상호연동시키기 위한 다양한 접근방식들을 제공한다. 이들은 1) 서비스 계층 리소스들에 대한 제3자 기술 리소스들(예컨대 LWM2M 객체들을 위한 것)의 표준 맵핑, 2) 비-oneM2M 데이터 모델들이 oneM2M 리소스들 내에 캡슐화되는 투명한 상호연동, 3) 맵핑된 인터페이스가 oneM2M 리소스로서 노출되고, 리소스가 액세스될 때 요청이 리타겟팅되는 리타겟팅 상호연동, 및 4) 비-oneM2M 데이터 모델 상호연동의 시맨틱의 완전한 맵핑을 포함한다. 각각의 접근방식은 그 자체의 한계를 갖는다. 표준 맵핑 접근방식에 대해, 제3자 기술 리소스들은 표준화 동안 서비스 계층 리소스들에 맵핑된다. 이러한 맵핑 프로세스는 유지관리가 어렵고, 경량 머신-대-머신(Lightweight Machine-to-Machine)(LWM2M) 객체들의 경우, 그것은 불완전하거나 혼란스럽거나 완전히 부족하다. 투명한 상호연동의 방법 및 리타겟팅 상호연동의 방법 둘 다는 상호연동되는 디바이스의 데이터 모델들을 완전히 숨기고, 이는 그러한 리소스들의 사용을 관심 도메인 내의 애플리케이션들로 제한한다. 비-oneM2M 데이터 모델 상호연동의 시멘틱들의 완전한 맵핑은 리소스들의 일대일 맵핑을 제공하지만, 다수의 상이한 유형의 디바이스들이 존재할 때는 잘 확장되지 않는다.

서비스 계층 상호연동이 보편적이고 효율적이게 작동하도록 하기 위해, 상호연동된 디바이스들의 데이터 모델들은 모든 애플리케이션들에 노출되어야 하고, 상호연동되는 디바이스들의 데이터 모델들의 맵핑들 및 리소스 정의들을 추가 또는 업데이트하기 위한 동적인 메커니즘이 존재해야 한다. 이러한 능력들은 서비스 계층 아키텍처들이 다양한 수직적 마켓들을 단일의 수평 플랫폼으로 합칠 수 있게 할 것이다. 추가로, 새로운 리소스 유형들은 확장성을 위해 서비스 계층에 추가될 수 있다. 본 명세서에서는, 서비스 계층 상호연동 및 리소스 확장성을 지원하기 위한 경량의 동적 메커니즘들이 개시된다.

예를 들어, 본 명세서에 개시된 하나의 메커니즘은 제3자 기술 리소스들을 표현하기 위해 서비스 계층 리소스들의 커스텀 속성들을 지정하는 것을 허용하는 새로운 서비스 계층(SL) 리소스 정의 등록 절차를 정의하는 것을 포함한다. 새로운 기능성의 일부로서, 리소스 정의들을 관리하기 위해 추가의 절차들이 도입된다.

본 명세서에 개시된 제2 메커니즘은 서비스 계층 리소스들을 제3자 데이터 모델들에 맵핑하고 새로운 상호연동되는 리타겟팅 표시자를 서비스 계층에 제공하기 위해 새로운 SL 데이터 모델 맵핑 등록 절차를 정의하는 것을 포함한다. 리소스 정의들을 관리하기 위해 사용되는 동일한 절차들은 또한 데이터 모델 맵핑들을 관리하기 위해 이용될 수 있다.

또한, 본 명세서에 개시되는 제3 메커니즘은 데이터 모델 맵핑에 의해 제공되는 리타겟팅 표시자에 기초하여 요청들을 상호연동되는 리소스들에 지능적으로 리타겟팅하기 위해 SL 일반적 상호연동 절차를 정의하는 것을 포함한다.

본 개요는 아래에서 상세한 설명에 더 설명되는 단순화된 형태의 개념들의 선택을 소개하기 위해 제공된다. 본 개요는 청구된 주제의 핵심적인 특징들 또는 필수적인 특징들을 식별하도록 의도되지 않으며, 청구된 주제의 범위를 제한하는 데 사용되도록 의도되지도 않는다. 또한, 청구된 주제는 본 개시내용의 임의의 부분에서 언급된 임의의 또는 모든 단점을 해결하는 제한들에 한정되지 않는다.

첨부 도면들과 함께 예로서 주어진 이하의 설명으로부터 보다 더 구체적인 이해가 이루어질 수 있다.
도 1은 예시적인 oneM2M 서비스 계층 아키텍처를 도시한다.
도 2는 예시적인 oneM2M 리소스를 도시한다.
도 3은 예시적인 oneM2M XML 스키마 정의(XSD) 문서를 도시한다.
도 4는 예시적인 oneM2M 상호연동 아키텍처를 도시한다.
도 5는 예시적인 경량 M2M(LWM2M) 아키텍처를 도시한다.
도 6은 oneM2M과 같은 서비스 계층 표준들에 의해 정의된 대로의 일반적 상호연동을 수반하는 예시적인 사용 사례를 도시한다.
도 7은 4개의 oneM2M mgmtObj 리소스들에 맵핑되는 LWM2M 디바이스 객체를 도시한다.
도 8은 서비스 계층 일반적 상호연동을 위한 예시적인 단-대-단 절차를 도시한다.
도 9는 예시적인 서비스 계층 리소스 정의 문서 등록 절차를 도시한다.
도 10은 예시적인 단순화된 서비스 계층 리소스 정의 발견 절차를 도시한다.
도 11은 예시적인 서비스 계층 리소스 정의 활성화 절차를 도시한다.
도 12는 예시적인 서비스 계층 리소스 정의 비활성화 절차를 도시한다.
도 13은 예시적인 서비스 계층 데이터 모델 맵핑 문서 등록 절차를 도시한다.
도 14는 예시적인 일반적 서비스 계층 상호연동 절차를 도시한다.
도 15는 새로운 oneM2M 공통 서비스 기능(CSF)를 생성하는 것은 물론, 기존 CSF를 업데이트하는 것의 예를 도시한다.
도 16은 예시적인 oneM2M 리소스 정의 문서를 도시한다.
도 17은 상호연동 프록시 엔티티(IPE)를 위한 예시적인 oneM2M 데이터 모델 맵핑 문서를 도시한다.
도 18은 서비스 계층을 위한 예시적인 oneM2M 데이터 모델 맵핑 문서를 도시한다.
도 19는 oneM2M CSE가 새로운 특수화된 <mgmtObj> 리소스들을 지원하기 위한 예시적인 절차를 도시한다.
도 20은 예시적인 일반적 상호연동 절차를 도시한다.
도 21은 <flexContainer> 작동 예를 도시한다.
도 22는 2개의 벤더를 수반하는 상호연동 예를 도시한다.
도 23은 복수의 LWM2M 서버를 수반하는 지능적 리타겟팅을 도시한다.
도 24는 예시적인 사용자 인터페이스를 도시한다.
도 25a는 하나 이상의 개시된 실시예가 구현될 수 있는 예시적인 머신-대-머신(M2M), 사물 인터넷(IoT), 또는 사물 웹(WoT) 통신 시스템의 시스템도이다.
도 25b는 도 25a에 도시된 M2M/IoT/WoT 통신 시스템 내에서 사용될 수 있는 예시적인 아키텍처의 시스템도이다.
도 25c는 도 25a 및 도 25b에 도시된 통신 시스템 내에서 사용될 수 있는 M2M/IoT/WoT 디바이스, 게이트웨이, 또는 서버와 같은 예시적인 통신 네트워크 장치의 시스템도이다.
도 25d는 도 25a 및 도 25b의 통신 시스템의 노드가 구현될 수 있는 예시적인 컴퓨팅 시스템의 블록도이다.

용어들 및 정의들

본 섹션은 청구된 주제의 범위를 제한하기 위해 사용되도록 의도되지 않으며, 또한 이하에 논의된 용어들 중 임의의 것의 범위를 제공된 정의들로 제한하기 위해 사용되도록 의도되지도 않는다.

상호연동은 제2 기술의 도메인 내에서의 외부 기술의 작동들을 지칭한다. 예를 들어, LWM2M은 oneM2M 내로 상호연동될 수 있다. 전형적으로, 상호연동은 2개의 기술 사이의 소정 형태의 프로토콜 변환 및 데이터 모델 맵핑을 수반한다.

LWM2M은 SL 아키텍처와 상호연동되는 제3자 기술로 고려된다. 그것은 본질적으로 제한된 처리(CPU, MCU) 및 저장(RAM, ROM) 능력들로 전형적으로 제약되는 디바이스들의 디바이스 관리 및 서비스 인에이블먼트에서 사용되도록 정의되는 경량 클라이언트-서버 프로토콜이다.

SL 리소스의 이름은 이름 resourceName으로 표현될 수 있다. 이러한 규약은 oneM2M에서 사용되는 규약과 동일하다.

리소스 활성화는 리소스 정의가 서비스 계층에 의해 사용되도록 이용가능해지는 SL 프로세스이다. 프로세스는 요청자를 인증하는 것, 리소스/리소스 유형에 대한 스키마 문서를 생성하기 위해 리소스 정의 문서로부터 정보를 추출하는 것, 발견 목적들을 위한 지원된 리소스 유형 속성들을 업데이트하는 것 등을 포함할 수 있다.

리소스 비활성화는 SL 리포지토리로부터 스키마 문서를 제거하기 위한 SL 프로세스이고, 따라서 제거된 스키마에 기초한 장래의 리소스들은 생성될 수 없다. 이 프로세스는 리소스 유형이 더 이상 사용되지 않고 철수된(retired) 경우에만 수행된다.

리소스 정의는 서비스 계층 리소스 유형을 상세하게 설명하는 문서이다. 문서는 리소스 유형, 특수화된 리소스 유형(specialized resource type)이 존재하는 경우 그것의 이름(예를 들어, oneM2M에서, 배터리는 mgmtObj 리소스 유형의 특수화임), 버전 번호, 리소스 트리 내에서 리소스 인스턴스들에서 생성될 수 있는 곳, 리소스 인스턴스의 속성들, 활성화 절차들 등과 같은 정보를 포함한다.

리소스 인스턴스는 리소스 유형에 대응하는 서비스 계층 리소스 트리 내의 엔트리이다. 인스턴스의 속성들은 그것이 생성된 목적에 관련된 데이터를 포함할 것이다.

리소스 유형은 애플리케이션, 컨테이너, 또는 가입 리소스를 위한 것과 같이, 리소스를 위한 목적을 나타낸다.

리타겟팅은 하나의 SL 엔티티 A(예를 들어, 서버)에서의 SL 리소스 또는 속성에 대한 요청이, 요청된 정보가 존재하는 다른 엔티티 B(예를 들어, 디바이스)에 재지향되는 프로세스이다. 이 경우, 엔티티 A에서의 SL은 요청자와 다른 엔티티 B(예를 들어, 디바이스) 사이의 전송 메커니즘의 역할을 한다.

리소스 스키마는 리소스 유형의 내용들을 지정하기 위한 템플릿이다. XML 스키마 정의(XSD)는 확장가능한 마크업 언어(XML) 포맷으로 된 리소스 스키마 문서의 예이다.

XSD는 문서 내에 나타날 수 있는 요소들 및 속성들, 자식 요소들의 수와 순서, 연관된 데이터 유형들, 및 가능하게는 요소들/속성들을 위한 디폴트 또는 고정 값들을 보여줌으로써 XML 문서의 구조를 기술한다. oneM2M에서, 각각의 리소스 유형은 리소스가 어떻게 구성되어야 하는지, 및 리소스 내에 어떤 정보가 포함되는지를 보여주는 대응하는 XSD를 갖는다.

M2M / IoT 서비스 계층

M2M/IoT 서비스 계층(SL)은 구체적으로 M2M/IoT 디바이스들 및 애플리케이션들을 위한 부가 가치 서비스들을 제공하는 것을 목표로 하는 기술이다. oneM2M과 같은 글로벌 표준 기구는 TS-0001 oneM2M 기능적 아키텍처의 V-2.10.0에 설명된 것과 같이, M2M/IoT 디바이스들 및 애플리케이션들을 인터넷/웹, 셀룰러, 엔터프라이즈, 및 홈 네트워크에의 배치에 통합하는 것에 연관된 난제들을 해결하기 위해 M2M/IoT SL들을 개발하고 있다. oneM2M SL 아키텍처의 예가 도 1에 도시되어 있고, 이는 공통 서비스 엔티티(Common Services Entity)(CSE)에 연관된 다양한 참조 포인트들을 도시한다. Mca 인터페이스는 애플리케이션 엔티티들(AE)에 대한 서비스 계층 액세스를 제공하는 한편, Mcc 및 Mcc' 참조 포인트들은 CSE 대 CSE 통신을 허용한다. 마지막으로, Mcn 인터페이스는 기저 네트워크 기술에 대한 액세스를 제공한다.

oneM2M 아키텍처는 또한 도 1에 도시된 바와 같이, 비-oneM2M 기술들과 상호연동하기 위한 능력들을 제공한다. 이러한 상호연동된 디바이스들은 비-oneM2M 디바이스 노드들(NoDN)이라고도 지칭되며, 아키텍처 내에 그것들을 포함하는 것은, oneM2M이 자신이 모든 수직적 마켓들과 상호운영될 수 있는 수평적 플랫폼이라고 진정으로 주장할 수 있는 하나의 핵심적인 이유이다.

M2M/IoT SL은 애플리케이션들 및 디바이스들에 M2M/IoT 지향 능력들의 모음에 대한 액세스를 제공할 수 있다. 이러한 능력들의 몇몇 예들은 보안, 요금청구, 데이터 관리, 디바이스 관리, 발견, 프로비저닝, 및 접속성 관리를 포함한다. 이러한 능력들은 M2M/IoT SL에 의해 지원되는 메시지 포맷들, 리소스 구조들, 및 리소스 표현들을 사용하는 애플리케이션 프로그래밍 인터페이스(Application Programming Interfaces)(API)를 통해 애플리케이션들에게 이용가능해질 수 있다.

서비스 계층 리소스 관리

리소스 지향 서비스 계층 아키텍처들에서, 리소스 관리는 애플리케이션들 및 디바이스들이 서로 통신하기 위한 수단을 제공한다. oneM2M에서, 리소스는 엔티티들 사이에서 데이터 교환을 제공하기 위해 속성들 및 자식 리소스들을 갖는다. 예를 들어, 도 2는 타원형이 속성들을 나타내고 직사각형(예를 들어, <subscription>)이 자식 리소스를 나타내는 예시적인 oneM2M 리소스를 도시한다. 속성들은 대응하는 리소스(예를 들어, memAvailable 및 memTotal)의 데이터 모델을 지정할 수 있고, 리소스의 mgmtDefinition 및 description 속성들과 같은 추가 정보를 제공하는 메타데이터도 포함할 수 있다. 리소스들은 표준에 의해 지정된 속성들 및 자식 리소스들을 정의했을 수 있다. 이와 같이, 표준은 어떤 리소스들 및 속성들인지, 지원되는 데이터 유형들, 리소스 트리 내에서 특정한 리소스가 어디에 속하는지, 특정 리소스들 또는 속성들의 다중도, 리소스 유형을 설명하는 스키마 문서, 리소스의 생성 동안 수행되는 XSD 검증 등을 정의했다. 집합적으로, 액세스를 관리하기 위해 이용되는 절차들 및 리소스의 시맨틱들은 리소스 관리라고 지칭된다.

정의된 속성들을 갖는 대다수의 oneM2M 리소스들과 달리, 리소스 속성들이 커스텀화될 수 있는 2개의 oneM2M 리소스 유형: <mgmtObj> 및 <flexContainer> 리소스가 존재한다. <mgmtObj> 및 <flexContainer> 리소스는 대응하는 일반적 리소스들의 특수화를 정의하는 것을 허용한다. 즉, 이러한 리소스들은 다른 oneM2M 리소스들 내에서 찾아지지 않는 특수화된 기능성에 대한 <mgmtObj> 또는 <flexContainer> 리소스의 커스텀 속성들을 정의하는 것을 허용한다. <mgmtObj> 리소스들은 TS-0004 서비스 계층 코어 프로토콜 V-2.5.0 및 TS-0006 관리 인에이블먼트(Management Enablement)(BBF) V-1.1.4에서 논의된 기저 기술들에 대한 표준화된 맵핑들을 요구할 수 있다. <flexContainer> 리소스들은 리소스의 스키마에 대한 링크 또는 유니폼 리소스 표시자(Uniform Resource Indicator)(URI)가 서비스 계층에 제공되는 containerDefinition 속성을 포함한다. 그러나, 서비스 계층이 속성으로 무엇을 행하는지를 설명하기 위한 절차는 현재 정의되어 있지 않다.

각각의 리소스 정의에 연관된 것은, 부모 리소스가 가질 수 있는 속성들 및 자식 리소스(들)를 설명하는 XML 스키마 정의(XML Schema Definition)(XSD) 문서이다. 추가로, XSD 문서는 속성들 및 자식 리소스들이 나타나야 하는 순서, 각각의 다중도는 물론, 연관된 데이터 유형을 지정한다. XSD로부터의 이러한 "규칙들"은 리소스 생성 시에 검증된다. [memory] 특수화된 <mgmtObj> 리소스에 대한 oneM2M XSD 문서의 예는 도 3에 도시된다. XSD 문서는 [memory] 리소스가 2개의 리소스 특정 속성: "memAvailable" 및 "memTotal"은 물론, 리소스가 안내될 수 있는지 여부의 표시를 갖는다는 것을 보여준다. 추가로, 모든 속성들의 순서 및 각각의 속성마다의 다중도, 그것이 필수적인지 아니면 임의적인지, 및 연관된 데이터 유형은 모두 XSD 문서에 의해 제공된다. 결과적으로, XSD 문서는 SL이 리소스를 관리하고, 리소스에 액세스하는 데에 관심이 있는 애플리케이션들에 그것을 노출하기 위해 필요로 하는 정보를 정의한다.

서비스 계층 상호연동

SL 상호연동은 SL 아키텍처가 모든 수직적 마켓들을 위한 수평적 플랫폼이 될 수 있도록 하는 핵심적인 컴포넌트이다. oneM2M 내에서의 예시적인 상호연동 구성들이 도 4에 도시되어 있다. 비-oneM2M 엔티티들이 상호연동될 때, 비-oneM2M과 oneM2M 프로토콜 사이의 변환을 위해 상호연동 프록시 엔티티(Interworking Proxy Entity)(IPE)가 요구된다. 변환의 컴포넌트는 oneM2M 리소스들을 비-oneM2M 데이터 모델들에 맵핑하거나 그 반대로 맵핑하는 것을 수반한다. IPE는 전형적으로 Mca 인터페이스를 사용하여 CSE에 인터페이스하는 oneM2M AE로서 실현된다. Mca 인터페이스에 더하여, IPE는 상호연동된 엔티티와 그것의 네이티브 프로토콜을 통해 통신하는 비-oneM2M 인터페이스를 갖는다.

oneM2M 상호연동의 3가지 형태가 TS-0001에 의해 지정된다. 이것들은 비-oneM2M 데이터 모델의 시맨틱을 Mca에 완전히 맵핑하는 상호연동, Mca를 통한 인코딩된 비-oneM2M 데이터 및 커맨드들의 투명한 전송을 위해 컨테이너들을 사용하는 상호연동, 및 AE 또는 CSE 리소스들을 통한 리타겟팅 메커니즘을 사용하는 상호연동을 포함한다.

비-oneM2M 데이터 모델 상호연동의 시맨틱의 완전한 맵핑은 상호연동되는 디바이스의 리소스들을 적절한 oneM2M 리소스들 및 속성들에 일대일로 맵핑하기 위해 IPE 또는 AE를 참여시킨다. 예를 들어, 온도, 습도 및 광 센서들을 갖는 디바이스에 대해, IPE 또는 AE는 개별 센서를 각각 표현하기 위해 3개의 oneM2M 리소스를 생성할 것이다. 이는 완전한 맵핑으로 고려된다. 결과적으로, 상호연동을 위한 디바이스들을 지원하기 위해, IPE/AE의 설계 동안 수동 프로세스가 수행된다. 이 프로세스는 서비스 계층에 상호연동되는 각각의 새로운 디바이스에 대해 요구된다.

투명한 상호연동은 비-oneM2M 데이터 모델들을 oneM2M 컨테이너 리소스들 내에 캡슐화하고, AE들에게 데이터를 인코딩 및 디코딩할 것을 요구하는 것을 수반한다. oneM2M 리소스들 내에서의 정보의 이러한 터널링은 비효율적이며, AE들에 대한 복잡성을 가중시킨다. 결과적으로, 기저 데이터 모델 및 프로토콜에 대한 요구되는 지식을 가진 AE들만이 컨테이너 리소스들 내에 캡슐화된 데이터를 사용할 수 있다.

한편, 리타겟팅 상호연동은 서비스 계층이 제공하는 대부분의 기능성들을 완전히 우회한다. 이러한 형태의 상호연동에서, AE 또는 CSE는 oneM2M 리소스들의 맵핑된 인터페이스를 제공하고, 리소스가 액세스될 때, 동작은 IPE에 리타겟팅될 것이다. 이 경우, 데이터 모델의 콘텐츠에 대한 통찰은 제공되지 않는다.

위에 논의된 3가지 형태의 상호연동에 추가하여, 제4 형태의 상호연동은 oneM2M 사양 TS-0001, TS-0004, 및 TS-0006의 디바이스 관리 섹션들에 설명되어 있다. 디바이스 관리에 대해, <mgmtObj> 리소스들은 기저 디바이스 관리(DM) 기술의 데이터 모델들을 표현하는 표준화된 oneM2M 리소스들이며, AE들은 디바이스들을 관리하기 위해 이러한 <mgmtObj> 리소스들에 액세스한다.

OMA LWM2M

경량 M2M(Lightweight M2M)(LWM2M) 프로토콜은 제약된 디바이스들에 더 적용가능한 단순하고 평면적인 리소스 구조를 특징으로 하는 클라이언트-서버 아키텍처에 기초한다. LWM2M 프로토콜에 관한 추가 정보는 OMA(Open Mobile Alliance) 경량 머신 대 머신 기술 사양 버전 1.0에서 찾을 수 있다. 리소스 트리는 적은 레벨들의 계층구조들을 갖는 평면적인 구조로 조직화되는 기저 리소스들을 갖는 LWM2M 객체들로서 정의된다. LWM2M 내의 객체들 및 리소스들의 정의는 oneM2M 아키텍처 내의 리소스들 및 속성들의 정의에 각각 맵핑된다. 예시적인 LWM2M 아키텍처는 도 5에 도시된다.　　

디바이스 관리를 지원하는 것에 더하여, LWM2M 프로토콜은 제약된 디바이스들에 의해 제공되는 서비스 인에이블먼트를 또한 지원한다. 제약된 디바이스들은 대개 특정 애플리케이션들에 대한 데이터 측정치들을 제공하므로, 정보 보고는 프로토콜에 지정된 주요 서비스 인에이블먼트이다. 이와 같이, 객체들의 설계는 디바이스 관리 및 정보 보고를 지원할 리소스들을 제공하는 것에 중점을 둔다.

기존 서비스 계층 표준들을 사용하는 예시적인 배치 시나리오

도 6은 서비스 계층(예를 들어, oneM2M 서버)이 LWM2M 상호연동을 지원하는 예시적인 서비스 계층 배치 시나리오를 도시한다. 배치 시에, 서비스 계층은 TS-0001, TS-0005 관리 인에이블먼트(OMA) V-1.4.1, 및 OMA LWM2M 기술 사양에 지정된 LWM2M 객체들을 지원한다. 도 6에 도시된 바와 같이, 고객 1은 OMA LWM2M 기술 사양에 정의된 LWM2M 객체들을 지원하는 디바이스 1을 처음에 배치하고, 앱 1은 디바이스 1을 관리하기 위해 사용된다. 소정 시간 후에, 디바이스 1은 TS-0001 또는 TS-0005에 정의되지 않은 록와이프(LockWipe) 및 접속성 관리(Connectivity Management) 객체와 같은 몇몇 확장된 LWM2M 객체들로 업데이트된다. 새로운 LWM2M 객체들은 원래 TS-0001 및 TS-0005에서 지정되지 않았으므로, 서비스 계층에 의해 지원되지 않는다. 또한, 고객 1은 TS-0005 또는 OMA LWM2M 기술 사양에 정의되지 않은 몇몇 벤더 특정 LWM2M 객체들을 포함하는 디바이스 2를 배치한다. 다시 한번, 서비스 계층은 이러한 새로운 객체들을 지원할 수 없다.　

다른 경우에서, 고객 2는 2가지 상이한 기술, 예를 들어 oneM2M과 OIC(Open Internet Consortium)로부터의 디바이스들을 관리하고 있기 때문에 자신의 동작들을 통합하기를 원한다. 고객 2는 이미 앱 2를 사용하여 자신의 서비스 계층 디바이스들을 관리하고 있고, 자신의 OIC 디바이스들을 서비스 계층으로 마이그레이션하려고 한다. 이러한 방식에서, 고객 2는 앱 2만을 사용하여 자신의 디바이스들 전부를 관리할 수 있을 것이다. 위에 설명된 LWM2M 시나리오와 마찬가지로, 이 OIC 디바이스는 지원되지 않으므로, 고객 2는 서비스 계층을 사용하여 디바이스 3를 관리할 수 없다.

위에 설명된 시나리오는 일반적 상호연동이 oneM2M과 같은 서비스 계층 표준들에 의해 정의되는 방식의 갭을 보여준다. 현재, oneM2M은 예를 들어 LWM2M(TS-0014 TWM2M 상호연동 V-0.13.0에서 설명됨), AllJoyn(TS-0021 oneM2M 및 AllJoyn 상호연동 V-0.3.0에서 설명됨), 및 OIC(TS-0024 OIC 상호연동 V-0.4.0에서 설명됨)와 같은 상호연동 기술들의 데이터 모델들에 대한 리소스 맵핑들을 추상적인 방식으로 정의한다. 이러한 맵핑들은 불완전하거나 혼란스럽거나 완전히 부족하다. 예를 들어, LWM2M의 경우, 데이터 모델들 사이에는 일대일 맵핑이 존재하지 않는다. 추가로, LWM2M 펌웨어 업데이트 객체는 자신의 모든 리소스를 oneM2M [firmware] 속성들에 맵핑시키지 않는다. 도 7에 도시된 바와 같이, LWM2M 디바이스 객체는 4개의 상이한 oneM2M <mgmtObj>에 맵핑된다. 마지막으로, LWM2M 접속성 모니터링 및 접속성 상태 객체들은 oneM2M 리소스들에 맵핑되지도 않는다.

2개의 다른 oneM2M 상호연동 접근방식은 상호연동 디바이스들의 데이터 모델들을 서비스 계층으로부터 완전히 숨긴다. 이러한 경우들에서, 상호연동된 리소스들은 "콘텐츠 공유 리소스들" 내에 캡슐화되고, 이는 CSE, AE 또는 컨테이너 리소스들로서 표현될 수 있다. 투명한 상호연동에서, 비-oneM2M 데이터 모델은 컨테이너 리소스 내에 캡슐화되고, 이것은 애플리케이션들에게 데이터를 인코딩 및 디코딩할 것을 요구한다. 인코딩 및 디코딩 요건들로 인해, oneM2M 애플리케이션들은 oneM2M 프로토콜들은 물론, 상호연동된 기술의 프로토콜을 이해할 필요가 있다. 마찬가지로, 리타겟팅 상호연동은 서비스 계층이 제공하는 대부분의 기능성을 완전히 우회한다. 이러한 형태의 상호연동에서, CSE 또는 AE 리소스는 전형적으로 상호연동된 엔티티를 표현하기 위해 생성되며, 리소스에 대한 요청들은 IPE에 리타겟팅된다. 상호연동된 데이터 모델을 서비스 계층으로부터 숨김으로써, 이러한 2가지 접근방식은 상호연동을 관심 도메인 내의 애플리케이션들로 제한한다.

비-oneM2M 데이터 모델 상호연동의 시맨틱의 전체 맵핑에서, 상호연동된 데이터 모델과 oneM2M 리소스들의 일대일 맵핑이 제공된다. 그러나, 이러한 완전한 맵핑이 행해지는 프로세스는 본질적으로 수동이며, IPE/AE 설계 동안 수행된다. 이 방법은 다수의 상이한 유형의 디바이스가 존재하는 경우에는 잘 확장되지 않는다. 각의 디바이스는 IPE/AE 설계에 대한 자기 자신의 맵핑들 및 업데이트들을 요구한다.

마지막으로, 도 6에 도시된 예는 oneM2M과 같은 수평적 서비스 계층 플랫폼의 중요한 특징에 대한 지원, 즉 벤터 특정 데이터 모델들을 효율적이고 동적으로 지원할 수 있는 능력이 부족하다는 점을 강조한다. oneM2M 표준은 상호연동을 지원하기 위해 커스텀화될 수 있는 리소스들, 예를 들어, <mgmtObj> 및 <flexContainer> 리소스를 이미 제공하고 있다. 그러나, 현재 oneM2M은 리소스 속성들을 동적으로 커스텀화하는 능력을 활용하는 절차를 갖지 않는다. 이러한 벤더 특정 리소스들은 동일한 수직적 마켓들로부터의 벤더들이 그들의 제품 제공을 차별화하고 그들의 플랫폼의 부가가치를 보여주는 데에 매우 중요하다. 상이한 수직적 마켓들로부터의 벤더들을 포함하도록 확장되면, 그러한 동적 상호연동 메커니즘들의 혜택들이 확대된다.

서비스 계층 아키텍처들 내에서의 일반적 상호연동

서비스 계층 상호연동이 보편적이고 효율적으로 작동하기 위해, 상호연동되는 디바이스들의 데이터 모델들은 모든 애플리케이션들에 노출되어야 하며, 상호연동되는 디바이스들의 데이터 모델들에 대한 리소스 정의들 및 맵핑들을 추가하거나 업데이트하는 동적 메커니즘이 존재해야 한다. 이러한 능력들은 서비스 계층 아키텍처들이 다양한 수직적 마켓들을 단일의 수평적 플랫폼으로 통합하는 것을 가능하게 할 것이다. 추가로, 확장성을 위해 새로운 리소스 유형들이 서비스 계층에 추가될 수 있다. 본 명세서에서는 서비스 계층 상호연동 및 리소스 확장성을 지원하기 위한 경량의 동적 메커니즘들이 개시된다.

예를 들어, 도 8은 서비스 계층 아키텍처들 내에서의 일반적 상호연동을 가능하게 하는 예시적인 엔드-투-엔드 절차의 하이레벨 개요를 도시한다. 도 8은 도 4에 도시된 상호연동 아키텍처의 하나의 실현이다. 본 명세서에서 논의된 바와 같이, 제3자 데이터 모델들의 일대일 맵핑은 상호연동의 일부로서 서비스 계층 리소스들에 제공될 수 있다. 또한, 서비스 계층은 새로운 리소스 유형들, 또는 기존 리소스 유형들의 조합들을 지원하도록 구성될 수 있다. 그러나, 새로운 리소스 유형들은 서비스 계층에 의해 지원되는 동작들로 제한된다. 새로운 리소스 유형들에 대해 새로운 기능성들 또는 서비스들이 요구되는 경우, 새로운 리소스 유형들을 지원하기 위해 그러한 기능성들 또는 서비스들을 가능하게 하는 대안적인 수단이 인에이블되어야 한다.

본 명세서에 개시된 일 양태에 따르면, 리소스 정의 문서는 리소스 유형이 표준 사양에서 정의되는 방법과 유사한 리소스 유형을 설명한다. 예를 들어, oneM2M <AE>는 TS-0001에서 설명되는데, 여기에서는 AE의 속성들과 자식 리소스들, 그것이 어떤 공통 속성들을 갖는지, 그것이 리소스 트리 내의 어디에 존재하는지, 그것의 속성들의 다중도, 및 대응하는 데이터 유형들을 갖는 자식 리소스들 등이 나열된다. 추가로, 이하가 지정될 수 있는 프로토콜 바인딩들이 TS-0004에서 제공된다: 데이터 유형들 및 XSD 또는 스키마 파일들, 사용된 약식 이름들, 프리미티브 속성들의 임의성(optionality), 리소스에 대한 액세스의 절차들 등. 이러한 정보 전부는, 서비스 계층이 리소스 정의를 활성화하여 그것을 사용가능하게 하는 방법에 대한 추가의 지침들을 또한 포함하는 리소스 정의 문서에 포함되어 있다.

본 명세서에 개시된 다른 양태에 따르면, 데이터 모델 맵핑 문서는 제3자 리소스들과 서비스 계층 리소스 속성들의 일대일 맵핑을 제공하기 위해 사용될 수 있다. 결과적으로, 그것은 리소스 특정 속성들을 설명하는 스키마 파일의 부분들과 유사하다. 이 문서는 LWM2M을 위한 TS-0005에서 제공되는 것들과 같은 제3자 리소스들에 대한 서비스 계층 리소스 속성들의 맵핑들을 제공한다. 이 정보는 프로토콜 변환 동안 사용된다. 추가로, 데이터 모델 맵핑 문서는 메시징 트래픽을 최소화하기 위해 리트리브 요청들을 언제 리타겟팅할지에 관해 서비스 계층에게 지시하는 각각의 리소스 속성에 대한 리타겟팅 표시자를 포함한다.

도 8의 예에 도시된 바와 같이, IPE는 상호연동되는 디바이스에 대한 새로운 리소스 정의로 먼저 프로비저닝된다. 다음으로, 이러한 리소스 정의는 서비스 계층에 등록되고, 이는 새로운 리소스의 관리를 서비스 계층의 동작에 추가한다. 다음으로, 상호연동된 디바이스의 데이터 모델이 SL 리소스 속성들에 맵핑되는 데이터 모델 맵핑이 IPE에 대해 프로비저닝된다. 이 데이터 모델 맵핑은 또한 서비스 계층에 등록되어, 상호연동되는 리소스들에 대한 메시징들을 최적화하기 위한 리타겟팅 표시자들을 제공한다. 다음으로, 상호연동되는 디바이스는 IPE에 등록 또는 프로비저닝되며, IPE는 결국 디바이스를 서비스 계층에 등록한다. 예를 들어, LWM2M 디바이스는 IPE의 일부인 LWM2M 서버에 등록하고, 다음으로 IPE는 디바이스를 서비스 계층에 등록할 것이다.

초기 단계로서, 도 8에 도시되지는 않았지만, IPE 및 서비스 계층은 예를 들어 SL 등록 및 액세스 제어 프로비저닝을 포함시킴으로써 안전하게 서로 통신하도록 프로비저닝된다. 도 8은 IPE가 리소스 정의 및 데이터 모델 맵핑 문서들 둘 다를 서비스 계층에 등록하는 것을 도시한다. 마찬가지로, 관리 SL 애플리케이션 또는 서버 관리자도 IPE를 대신하여 서비스 계층에 이러한 문서들을 등록할 수 있다. IPE, 관리 SL 애플리케이션, 및 서비스 계층 관리자라는 용어는 상호교환되어 사용될 수 있다.

모든 등록 절차가 완료되고 나면(예를 들어, 단계 1 내지 5가 완료된 후), 애플리케이션은 새로운 상호연동되는 디바이스 리소스를 찾기 위해, 서비스 계층의 리소스 발견 절차를 사용할 수 있다. 다음으로, 애플리케이션은 상호연동되는 리소스를 타겟팅하는 요청을 하고, 서비스 계층은 일반적 상호연동 절차를 개시할지 여부를 결정하기 위해, 상호연동되는 리타겟팅 표시자의 기준을 평가한다. 개시되는 경우, 서비스 계층은 애플리케이션의 요청을 IPE에 리타겟팅하고, IPE는 SL 프로토콜로부터 네이티브 상호연동되는 디바이스의 프로토콜로의 일반적 상호연동 맵핑을 수행한다. 요청된 데이터가 본질적으로 정적인 경우, 일부 SL 요청들은 IPE에 리타겟팅되지 않을 수 있음에 유의해야 한다. 그러나, 적어도 하나의 리타겟팅된 요청은 정적 데이터를 리트리브하도록 요구된다. 상호연동되는 디바이스로부터 반환된 응답은 IPE로부터 서비스 계층으로, 그리고 마지막으로 애플리케이션으로 중계된다. 서비스 계층은 리타겟팅 표시자에 의존하여 응답을 캐시할 수 있다.

SL 리소스 정의 문서 등록 절차

본 명세서에 개시된 제1 양태에 따르면, 서비스 계층에서 상호연동을 가능하게 하기 전에, 상호연동되는 디바이스 리소스들로부터 SL 리소스들 및 속성들로의 일대일 맵핑을 제공하도록 리소스 정의가 정의된다. 리소스 정의는 본질적으로 리소스 유형, 특수화된 리소스 유형이 존재한다면 그것에 주어진 이름, 리소스 유형에 대한 속성들 및 자식 리소스들, 리소스의 생성을 검증하기 위해 사용할 리소스를 설명하는 스키마 문서, 및 리소스를 관리하기 위한 다른 정보 및 절차들이 정의되는 표준화 동안 수행되는 동일한 작업을 반영한다. 리소스 정의를 위해 요구되는 정보는 문서에 캡처되고, 다음으로 그것은 본 출원의 사상들을 이용한 서비스 계층 내로의 등록을 위해 IPE, 관리 애플리케이션 또는 서버 관리자에 프로비저닝된다.

일대일 맵핑은 두 단계, 즉 디바이스에 액세스하고/하거나 디바이스를 관리하기 위해 요구되는 네이티브 데이터 모델을 식별하는 단계, 및 디바이스의 네이티브 데이터 모델을 서비스 계층 리소스들 및 속성들에 맵핑하는 단계로 구성된다. 맵핑의 결과는 SL 리소스 정의 문서 및 데이터 모델 맵핑 문서 둘 다를 생성할 것이다. 리소스 정의 문서는 새로운 리소스들 또는 리소스 유형들을 정의하기 위해, 즉 새로운 커스텀 리소스들 또는 커스텀 리소스 유형들을 정의하기 위해 SL에 제공되는 한편, 데이터 모델 맵핑 문서는 상호연동을 위해 SL에 제공된다. SL 내에서, 데이터 모델 맵핑 문서는 서비스 계층이 리소스에 대한 요청을 언제 리타겟팅해야하는지를 알려주는 리타겟팅 표시자들을 제공한다. IPE는 프로토콜 변환 및 리타겟팅 둘 다를 위해 데이터 모델 맵핑 문서를 사용한다. 프로토콜 변환은 상호연동된 디바이스가 이해하는 새로운 메시지를 생성하는 것을 수반할 수 있다. 리타겟팅은 상호연동된 디바이스와 통신하는 IPE가 서비스 계층에 반환할 응답을 얻는 것을 수반할 수 있다.

리소스 정의들 및 데이터 모델 맵핑들이 완료되면, 서비스 계층에 대응하는 등록들을 개시하기 위해 문서들은 IPE에 프로비저닝된다. IPE는 먼저 리소스 정의를 서비스 계층에 등록할 것이다. 이 등록은 SL에게 SL 리소스의 새로운 인스턴스를 생성할 것을 요청하는 것이 아니라 새로운 리소스 정의를 등록하고 있으므로, 현재의 SL 등록과 다르다. 결과적으로, 등록 요청의 타겟 URI는 가상 리소스에 대한 것이고, 이는 리소스 정의가 등록되고 있음을 SL에게 알린다.

정상 SL 리소스를 대신하여 가상 리소스를 타겟팅하는 것의 목적은, 등록 동작이 정상 동작 모드를 벗어나며 리소스 트리 내에 리소스 인스턴스가 생성되고 있지 않다는 것을 서비스 계층에게 알려주는 것이다. 그러나, 서비스 계층이 지원하는 모든 리소스 정의들을 호스팅하기 위해, 리소스 트리에 새로운 서비스 계층 리소스가 생성될 수도 있다. 이 경우, 등록 요청의 타겟 URI는 새로운 SL 리소스를 타겟팅할 것이다. 예를 들어, 모든 리소스 정의를 저장하기 위해, 새로운 "resourceDefinitions" 리소스가 SL 리소스 트리 내에 생성될 수 있다. 타겟 URI는 예를 들어 "/ resourceDefinitions" 또는 "/< SL _ name >/ resourceDefinitions"의 형태일 수 있다. 이 경우, 리소스 정의는 가상 리소스 접근방식을 사용하는 리소스 정의는 갖지 않을 2개의 추가 속성: 활성화(activate) 및 비활성화(deactivate)를 포함해야 한다. 이러한 속성들은 아래에 설명되는 바와 같은 리소스 정의의 사용을 가능하게 하기 위해 이용될 것이다.

서비스 계층은 수 개의 방식으로 리소스 정의 등록을 관리할 수 있다. 서비스 계층은 내부 리포지토리에 리소스 정의를 저장할 수 있으며, 여기서 그것은 리소스를 타겟팅하는 추가의 요청들을 검증하기 위해 사용될 수 있다. 이는 서비스 계층 서버 내의 소정의 위치 내에 파일을 저장하는 것으로서 실현될 수 있다. 대안적으로, 서비스 계층은 정상 리소스 발견을 통해 리소스 정의를 서비스 계층의 등록자들에게 노출시키기 위해, 리소스 트리 내에 리소스를 생성할 수 있다. 이것이 현재 서비스 계층 리소스들이 처리되는 방법이다. 추가로, 더 투명하고 유연하며 기능적인 동작들을 제공하기 위해, 2가지 대안이 함께 결합될 수 있다.

도 9는 아래에 논의되는 바와 같이, IPE가 서비스 계층에 대해 행하는 예시적인 리소스 정의 등록 절차를 도시한다.

단계 1에서, IPE가 상호연동되는 디바이스의 리소스 정의 문서로 프로비닝된 후, 그것은 서비스 계층에 문서를 등록한다. 등록 요청에서, IPE는 등록이 리소스 정의를 위한 것임을 나타내기 위해, 가상 리소스를 타겟팅한다. 가상 리소스에 대한 예시적인 URI는 /< SL _ name >/ resourceDefinitions의 형식일 수 있다. 상호연동된 디바이스에 대한 리소스 정의 문서가 요청 내에 포함된다. 이 문서는 서비스 계층이 리소스를 관리하고 리소스 발견을 위해 그것을 노출시키기 위해 필요로 하는 정보를 포함할 것이다. 표 1은 리소스 정의 문서를 구성하는 상이한 컴포넌트들을 보여준다. 제공되는 정보는 서비스 계층이 활성화 후의 사용을 위해 리소스 정의 문서로부터 oneM2M XSD 문서를 추출하는 것을 가능하게 할 것이다. 대안적으로, 서비스 계층이 리소스 정의 문서를 리트리브할 수 있는 URI가 등록 요청 내에 제공될 수 있다.

리소스 정의들을 서비스 계층에 명시적으로 등록하는 것에 대한 대안으로서, 리소스 정의 등록은 스키마 문서에 대해 URI를 제공하는 속성을 갖는 리소스의 생성을 암시적으로 트리거될 수 있다. 이 경우, 서비스 계층은 스키마 문서를 등록하는 것, 및 단계 2에서 정의를 또한 활성화하는 것 둘 다를 위해 요청을 처리할 것이다. 이 대안은 스키마 파일의 위치를 지정하기 위한 속성을 포함하는 기존 서비스 계층 리소스들로 제한되며, 서비스 계층 내에 새로운 리소스 유형을 생성하기 위해서는 사용될 수 없다.

단계 2에서, 서비스 계층은 IPE 의해 제공된 리소스 정의를 평가하여, 그것이 표 1에 지정된 요구되는 컴포넌트들 전부와 각각의 컴포넌트 내의 요구되는 정보 전부를 포함하는지를 검증한다. 정보 요건들은 구현 특정적이라는 점에 유의해야 한다. 이것은 제공된 활성화 기준의 콘텐츠에 대해 특히 중요하다. 단계 1에서 URI가 제공된 경우, 서비스 계층은 리소스 정의들을 평가하기 전에 문서를 먼저 다운로드한다. 리소스 정의가 유효하고 수락가능한 것으로 결정한 후, 서비스 계층은 리소스 정의를 활성화하는 데에 사용하기 위해, 문서를 그것의 리소스 정의 리포지토리에 추가한다.

이 절차가 스키마 문서에 대한 URI를 포함하는 서비스 계층 리소스의 생성에 의해 트리거되면, 서비스 계층은 리트리브된 스키마 문서를 활성화하기 위한 추가 처리를 수행한다. 추가 처리는 구현 의존적이며, 스키마 문서가 잘 형성되고 있는지를 검증하는 것, 스키마 문서를 서비스 계층의 로컬 리포지토리에 저장하고, 스키마 문서를 리소스 발견에 이용가능하게 만드는 것 등을 포함할 수 있다.

단계 3에서, 서비스 계층은 IPE에 적절한 응답을 송신한다. 생성이 성공적이었던 경우, 서비스 계층은 리소스 정의를 리트리브하는 데에 사용하기 위한 URI를 제공할 수 있다. URI는 단계 1로부터의 가상 URI 접두사, 리소스 정의들에 대해 서비스 계층에 의해 프로비저닝된 리소스 이름 또는 다른 식별자, 및 리소스 정의의 버전으로 구성될 수 있다. 절차가 스키마 문서에 대한 URI를 포함하는 리소스의 생성에 의해 트리거된 경우, 서비스 계층은 스키마 문서에 액세스하기 위해 URI와 함께 정상 생성 응답을 반환한다.

도 9에 지정된 절차는 IPE가 리소스 정의 등록 요청을 행하는 것을 도시한다. 대안적으로, 이러한 요청은 관리 서비스 계층 애플리케이션에 의해 이루어질 수 있다. 이 관리 애플리케이션은 서비스 계층의 동작들을 관리하기 위해 사용할 수 있으며, 서버의 동작을 변경하기 위한 특수 액세스 권한들을 가질 수 있다. 애플리케이션은 서비스 제공자 또는 서비스 계층 소유자에 의해 제어될 수 있다. 세번째 대안은 서비스 계층 관리자가 리소스 정의 등록을 수행하는 것이다. 이 기능성은 서비스 계층 동작 내에 구축될 수 있으며, 웹 인터페이스, 커맨드 라인 인터페이스, 또는 소정의 다른 메커니즘을 통해 실현될 수 있다.

도 9에 지정된 절차는 서비스 계층 배치 시에 존재하지 않았던 새로운 리소스 유형들을 정의하기 위해 사용될 수 있다는 점에 유의해야 한다. 예를 들어, 서비스 계층은 리소스 정의들의 릴리스 1에 기초하여 배치된다. 배치 후, 새로운 리소스 유형이 릴리스 2에서 생성된다. 이 섹션에서 개략적으로 설명된 절차들을 사용하여, 서비스 계층은 새로운 리소스 유형들을 지원하기 위해 업데이트될 수 있다. 또한, 절차는 동일한 리소스 유형의 다양한 버전들을 지원하는 것을 허용할 수 있다. 이는 서비스 계층이 동일한 리소스의 다른 버전들을 사용하여 레거시 디바이스와 새로운 디바이스 둘 다에서 동작하는 것을 가능하게 한다.

SL 리소스 정의 관리 절차

리소스 정의가 등록되고 나면, 서비스 계층은 발견, 리트리브, 업데이트, 제거, 활성화, 및 비활성화를 위한 절차들을 통해 정의가 관리될 수 있는 능력을 제공한다. 리소스 정의의 관리는 정의들에 액세스하는 절차가 어떻게 수행되는지를 결정한다는 점에 유의해야 한다. 서비스 계층이 리소스 정의를 리소스 트리의 리소스로서 노출하는 경우, 정상 SL 요청들(발견, 리트리브, 업데이트, 및 삭제)은 리소스 정의들에 액세스하기 위해 사용될 것이다. 그러나, 서비스 계층이 리소스 정의들을 파일에 저장하고 그것들을 내부 리포지토리에 저장하는 경우, 리소스 정의들에 액세스하기 위해 이하의 절차들이 정의된다.

리소스 정의들의 관리는 두 세트의 리포지토리를 포함하는데, 하나는 리소스 정의 문서들을 위한 것이고, 다른 하나는 스키마 문서들을 위한 것이다. 리소스 정의 문서는 아래에 설명되는 활성화 절차 동안 대응하는 스키마 문서들을 생성하기 위해 서비스 계층에 의해 사용된다. 결과적으로, 문서들은 별개의 리포지토리들에 저장된다. 리소스 정의 리포지토리는 엄격한 인가 프로세스를 통해 액세스를 허가받은 IPE들, 관리 애플리케이션들, 또는 서비스 계층 관리자들에게만 액세스가능해질 수 있다. 이 리포지토리는 서비스 계층이 지원하는 모든 리소스들의 리소스 정의들을 표시하기 위해 사용될 수 있으며, 정상 서비스 계층 동작들 동안에는 액세스되지 않는다. 스키마 문서 리포지토리는 리소스들의 생성 요청들을 검증하는 것과 같은 정상 동작 동안 이용되므로, 서비스 계층 자체 및 그것의 관리자들만으로 제약될 수 있다. 이러한 제약은 IPE들과 같은 외부 엔티티들이 가능하게는 서비스 계층의 동작을 방해하는 것을 방지하기 위해 부과될 수 있다. 결과적으로, IPE들 및 관리 애플리케이션들은 스키마 리포지토리에 대한 판독 액세스만을 가질 수 있다.

이러한 관리 절차들은 서버 관리자와 같은 인가된 엔티티들이 서비스 계층과 상호작용하여 새로운 리소스 유형들을 생성할뿐만 아니라 기존 리소스 유형들에 기초하여 새로운 리소스 유형들을 정의하는 것을 허용한다. 관리자들은 리트리브된 리소스 유형에 기초하여 새로운 리소스 유형들을 생성하기 위해 이러한 인터페이스를 사용하여 기존 리소스 유형들을 발견하고 리트리브할 수 있다. 서비스 계층들은 또한 리소스 정의 문서들을 다른 서비스 계층들과 교환하여 그들의 동작들을 업데이트하기 위해 이러한 인터페이스를 사용할 수 있다. 추가로, 표준화를 통해 리소스 유형에 대한 변경들이 이루어져야 하는 경우, 동일한 리소스 유형의 새로운 버전들이 생성될 수 있다. 마지막으로, 인가된 벤더들은 그들 자신의 특정 리소스를 정의할 수 있고, 그들의 리소스들을 등록하여 그들의 제품 제공을 차별화하기 위해 인터페이스들을 사용할 수 있다.

리소스 정의 발견

기존 SL 리소스 발견과 마찬가지로, 서비스 계층에 의해 어떤 리소스 정의들이 지원되는지를 찾기 위해 리소스 정의 발견이 수행된다. 리소스 정의 등록을 위해 사용된 동일한 타겟 URI가 리소스 정의 발견에 사용될 수 있다. 서비스 계층 리소스 발견 절차의 단순화된 버전은 이러한 리소스 정의들을 발견하기 위해 사용될 수 있다. 기존 SL 발견과 이러한 단순화된 발견 사이의 차이는 타겟 URI가 가상 리소스이고 필터 기준이 발견 기준으로 대체된다는 것이다. 이러한 발견 요청은 리소스 정의들에 초점이 맞춰지므로, 더 복잡한 필터 기준을 사용할 필요가 없다. created before(이전에 생성), modified since(이후에 수정), size above(초과 크기), limit(제한), semanticsFilter(시맨틱 필터) 등과 같은 속성들은 리소스 정의 발견 요청에 적용되지 않을 수 있다. 도 10은 아래에 논의되는 바와 같은 예시적인 단순화된 발견 절차를 도시한다.

단계 1에서, 애플리케이션 또는 IPE는 리소스 정의를 등록할 때 사용되는 URI와 같은 SL 리소스를 타겟팅하는 리트리브 동작을 수행한다. 요청은 특정 리소스 정의에 대한 검색을 좁히기 위한 발견 기준을 포함할 수 있다. 발견 기준은 키-값 쌍들의 목록으로 이루어질 수 있다. 기준의 몇몇 예들이 표 2에 보여진다.

단계 2에서, 서비스 계층은 요청을 수신하고, 발견 기준을 식별하고, 요구되는 리소스 정의들을 찾기 위해 그것의 내부 리포지토리를 검색한다. 하나보다 많은 리소스 정의가 찾아지는 경우, 서비스 계층은 리소스 정의 이름들의 목록을 컴파일할 수 있다.

단계 3에서, 서비스 계층은 발견 기준에 매칭하는 리소스 정의 이름들 및 연관된 버전들의 목록을 적절한 응답 코드와 함께 반환한다. 리소스 정의 이름들은 버전 번호는 물론, 동일한 리소스 정의들의 복수의 여러 버전을 포함할 수 있다는 점에 유의해야 한다. 임의로, 반환된 목록은 리소스 정의 문서들 및/또는 스키마 문서들의 URI들을 포함할 수 있고, 그에 의해, IPE는 정의 또는 스키마 문서들의 콘텐츠를 리트리브할 수 있다.

리소스 정의 리트리브

리소스 정의의 이름 또는 URI가 발견되고 나면, 애플리케이션 또는 IPE는 요구되는 정의의 콘텐츠를 리트리브할 수 있다. 요청은 리소스의 SL 리트리브 요청의 것과 유사하며, 차이점은 가상 URI와 리소스 정의 이름의 연쇄인 요청의 URI, 및 서비스 계층이 그것의 내부 리포지토리로부터 리소스 정의를 페치한다는 사실이다. 리트리브 요청에 대한 응답은 리소스 정의, 및 정의가 활성화되었는지 여부에 대한 표시자를 포함할 것이다. 스키마 문서에 URI를 제공하는 리소스의 생성으로 인해 리소스 정의 등록이 자동으로 트리거된 경우, 스키마 문서에 액세스하기 위한 URI는 생성 요청에 대한 응답으로, 또는 위에서 설명된 리소스 정의 발견 절차를 통해 제공된다.

리소스 정의 업데이트

리소스 정의들이 내부 리포지토리에 의해 관리되는 경우, 정의를 업데이트하기 위한 제한된 규정(limited provision)이 있는데, 왜냐하면 그것이 파일 내에 보유되기 때문이다. 업데이트가 리소스 정의 문서 내에 이미 존재하는 것의 값들을 변경하는 것을 수반하는 경우, 부분적 업데이트들이 허용된다. 업데이트 요청은 변경될 필요가 있는 값(들)을 제공한다. 그러나, 업데이트가 파일에 콘텐츠를 추가 또는 삭제하는 것을 수반하는 경우, 애플리케이션 또는 IPE는 도 9에 의해 지정된 생성 요청을 사용하여 전체 정의 파일을 업데이트할 필요가 있을 것이다. 이것은 서비스 계층이 파일을 구문분석하고, 파일을 업데이트할 위치를 찾고, 새로운 콘텐츠를 파일에 추가할 것을 요구하지 않음으로써, 정의 파일들의 관리의 단순화를 야기한다.

리소스 정의 제거

리소스 정의는 활성화되기 전에 또는 비활성화된 후에 제거될 수 있다. 이 절차는 삭제되는 것이 리소스 트리 내의 리소스 인스턴스가 아닌 리소스 정의 파일이라는 점을 제외하면 리소스의 SL 삭제와 유사하다. 리소스 정의가 활성화된 경우, 그것은 리포지토리로부터 제거될 수 없다는 점에 유의해야 한다. 이는 리소스 정의에 기초하는 리소스가 여전히 사용 중인 동안 그 정의의 삭제를 방지한다. 리소스 정의가 활성화되어 있지만 사용 중인 리소스가 존재하지 않는 경우, 리소스 정의 파일이 삭제되는 것을 허용할지는 서비스 계층에 달려 있다.

리소스 정의 활성화

리소스 정의가 등록되고 나면, 리소스 정의는 서비스 계층에 의한 사용을 위해 활성화되어야 한다. 활성화 프로세스는 리소스 정의가 서비스 계층에 의해 사용될 수 있기 전에 다양한 검사들 및 절차들을 트리거하기 위해 사용될 수 있다. 트리거될 수 있는 것의 예들은 이하를 포함할 수 있다: 1) 요청자가 리소스 정의를 활성화할 수 있음을 보장하기 위한, 서비스 계층의 소유자 또는 서비스 제공자에 의한 인가 검사, 2) 리소스 정의 문서로부터의 도 3에 설명된 것과 유사한 스키마 문서의 추출, 3) 추출된 스키마 문서가 잘 형성되는지를 검증, 및 4) 스키마 문서를 서비스 계층 스키마 리포지토리에 저장하고 리소스 발견 메커니즘들에 대한 업데이트들을 포함하여 서비스 계층 동작들에 통합. 이러한 활성화 프로세스에 대한 다른 잠재적인 사용이 존재하며, 위에서 언급된 사용들은 활성화 프로세스의 일부로서 함께 결합될 수 있다. 활성화가 완료되고 나면, 서비스 계층은 자기 자신의 리소스 트리 내의 리소스들을 생성하기 위해, 추출된 스키마 문서를 사용할 수 있다.

활성화의 프로세스는 예를 들어 새로운 리소스 유형들의 생성 요청들 또는 기존 리소스 유형들의 수정, 및 스키마 및 데이터베이스 리포지토리들에 대한 변경들(리소스 인스턴스를 생성하기 위한 것임)을 검증하는 것에 의해 서비스 계층의 거동을 변경하기 때문에 중요하다. 추가로, 활성화가 올바르게 수행되지 않으면 서비스 계층에서 원하지 않는 거동들을 야기할 수 있기 때문에, 표준 액세스 제어 검사 외에 인가 검사들이 더 수반될 수 있다. 도 11은 이하에 논의되는 바와 같이, 활성화 프로세스로부터 야기되는 몇몇 가능한 액션들을 도시한다.

단계 1에서, 애플리케이션 또는 IPE는 가상 리소스의 URI를 타겟팅하는 생성 요청, 리소스 정의 이름 및 그것의 버전, 및 URI의 끝에 있는 "/activate"를 송신한다. 대안적으로, 리소스 정의가 SL 리소스 트리 내에서 생성된 경우, "activate" 속성이 타겟팅될 수 있다. 요청은 서비스 계층 내에서 활성화 절차를 트리거한다. 리소스 정의 파일은 활성화를 위한 기준을 제공한다. 다음으로, 어떠한 액션들이 취해질지를 결정하기 위해, 이러한 기준이 서비스 계층에 의해 판독된다. 액션들 중 일부는 미리 수행된 다른 액션들에 의존할 수 있다. 예를 들어, 스키마 문서가 잘 형성되는지를 검증하기 전에, 리소스 정의 문서로부터 스키마 문서를 추출하는 것이 수행되어야 한다. 결과적으로, 리소스 정의 문서의 활성화 기준 섹션의 콘텐츠는 리소스 정의 등록이 수락되기 전에 엄격한 지침 및 검증을 가져야한다.

단계 2에서, 서비스 계층은 애플리케이션 또는 IPE가 리소스 정의를 활성화할 수 있는지 검사하기 위하여, 임의로 인가 서버에 요청을 송신할 수 있다. 서비스 계층의 크기와 복잡성에 의존하여, 이 요청은 제3자 또는 서비스 제공자의 인가 서버에 송신될 수 있다. 대안적으로, 그것은 소정의 정책 또는 구성 파라미터에 기초하여 서비스 계층 내에서 평가될 수 있다. 이러한 인가 검사는 또한 스키마 문서에 URI를 제공하는 리소스 인스턴스의 생성에 의해 활성화 절차가 트리거될 때 수행할 수 있으며, 요구되는 인가 검사들을 지정하기 위해 새로운 인가 파라미터들이 추가될 수 있다.

단계 3에서, 인가 서버는 적절한 메시지로 응답한다. 응답이 애플리케이션 또는 IPE이 인가받지 못했음을 나타낸다면, 서비스 계층은 활성화 프로세스를 중지하고 단계 7에서 이에 따라 응답할 것이다.

단계 4에서, 애플리케이션 또는 IPE가 인가되는 경우, 서비스 계층은 서버의 동작들에 대한 리소스 정의를 통합한다. 이는 리소스 정의 문서로부터 스키마 파일을 추출하고 결과 파일이 잘 형성됨을 검증하는 것을 수반할 수 있다. 대안적으로, 유효 리소스 정의 파일들의 데이터베이스는 새로운 리소스 정의를 포함하도록 업데이트될 수 있다. 추가로, 발견 목적을 위해 새로운 리소스 유형을 노출시키기 위해 업데이트들이 이루어질 수 있다.

단계 5에서, 서비스 계층이 스키마 문서가 잘 형성된 것을 검증하고 나면, 다음으로, 장래의 사용을 위해 자신의 내부 리포지토리에 문서를 저장할 수 있다. 예를 들어, 서비스 계층은 스키마 문서가 XML 1.0 사양의 정의된 구문 규칙들에 부합하는 것을 검증할 수 있는데, 그 사양은 XML 문서가 잘 형성되기 위해 특정 물리적 및 논리적 구조들을 충족시켜야 함을 지정한다.

단계 6에서, 상태는 서비스 계층 동작에의 스키마 문서의 통합 시에 반환된다.

단계 7에서, 서비스 계층은 활성화 요청에 대한 적절한 응답을 반환한다. 활성화 프로세스들/절차들 중 임의의 것이 실패하는 경우, 응답은 애플리케이션/IPE가 실패한 부분(들)을 디버그하는 데 도움을 주기 위해, 어느 프로세스들/절차들이 실패했는지를 나타낼 수 있다.

리소스 정의 비활성화

리소스 정의 비활성화는 활성화보다 간단한데, 왜냐하면 프로세스가 서비스 계층에게 타겟팅된 정의를 이용하는 리소스가 리소스 트리 내에 존재하지 않음을 보장할 것만을 요구하기 때문이다. 이것은 서비스 계층이 리소스 정의를 타겟팅하는 임의의 장래의 요청들을 검증할 필요가 있는 경우, 정의가 이용가능할 것을 보장하기 위한 것이다. 서비스 계층 리소스 트리 내의 어떤 리소스도 정의를 사용하지 않으면, SL은 리소스 정의를 비활성화할 수 있다. 도 12는 이하에 논의되는 바와 같이, 비활성화 프로세스로부터 야기된 몇몇의 가능한 액션을 도시한다.

단계 1에서, 애플리케이션 또는 IPE는 그 유형의 SL 내에 존재하는 임의의 리소스 인스턴스들의 부재로 인해 리소스 정의가 더 이상 필요하지 않음을 결정한다. 리소스 정의를 타겟팅하는 요청은 그것의 버전과 함께, 그리고 타겟 URI의 끝에 "/deactivate"를 첨부하여 서비스 계층에 송신된다. 대안적으로, 리소스 정의가 SL 리소스 트리 내에서 생성된 경우, "deactivate" 속성이 타겟팅될 수 있다.

단계 2에서, 서비스 계층은 리소스 정의를 사용하는 기존의 리소스 인스턴스가 없을 것을 보장하기 위해 자기 자신의 리소스 트리를 검사한다. 리소스 정의를 사용하는 계류 중인 리소스 인스턴스들이 존재하는 경우, 비활성화 요청이 거절된다. 사용 중인 리소스 인스턴스가 없는 경우, 서비스 계층은 리소스 정의를 삭제한다.

단계 3에서, 서비스 계층은 자신의 내부 리포지토리로부터 스키마 문서를 제거할 수 있고, 리소스 유형을 발견되는 것으로부터 제거한다.

단계 4에서, 스키마 문서의 제거를 위해 상태가 반환된다.

단계 5에서, 서비스 계층은 비활성화 요청에 대한 적절한 응답 코드를 반환한다.

SL 데이터 모델 맵핑 문서 등록 절차

리소스 정의가 활성화된 후, 다음으로, IPE, 관리 애플리케이션 또는 서버 관리자는 데이터 모델 맵핑 문서를 서비스 계층에 등록할 수 있다. 데이터 모델 맵핑 문서는 서비스 계층이 상호연동된 서비스 계층 리소스들에 요청들을 어떻게 리타겟팅해야하는지를 설명하는 리타겟팅 표시자들을 제공한다. 데이터 모델 맵핑들이 또한 프로토콜 변환에서 사용된다. 리소스 정의가 먼저 활성화되었고, 따라서 서비스 계층이 이 등록 요청에서 제공된 데이터 모델 맵핑들을 리소스 정의로부터의 생성된 스키마 파일에 대해 처리할 수 있게 하는 것이 중요하다. 데이터 모델 맵핑 문서는 생성된 스키마 문서에서 제공된 리소스 특정 속성들의 전체 목록을 포함해야 한다. 추가로, 문서는 각각의 SL 리소스 특정 속성에 대한 상호연동된 데이터 모델의 연관된 URI들을 포함할 것이다. 데이터 모델 맵핑들의 일부 예들(리타겟팅 표시자 없음)은 LWM2M 을 위한 TS-0005에서 찾아질 수 있다. 데이터 모델 맵핑 문서는 서비스 계층 리소스 특정 속성들과 상호연동된 데이터 모델 리소스 URI들 사이에 일대일 대응을 제공한다.

IPE는 리소스 정의 문서 내의 것들과 동일한 리소스 특정 속성 목록을 포함하는 데이터 모델 맵핑 문서로 프로비저닝된다. 새로운 파라미터들이 데이터 모델 맵핑 문서에 추가되는 동안, 리소스 특정 속성들의 이름들만이 유지된다. 새로운 파라미터들 중 일부는 연관된 데이터 유형들 및 리타겟팅 표시자와 함께 상호연동된 데이터 모델의 리소스 URI를 포함한다. IPE의 추가 특징들을 설명하기 위해 다른 파라미터들이 포함될 수 있다. 리소스 URI는 프로토콜 변환 동안 서비스 계층 리소스 속성들로부터 제3자 리소스들로 또는 그 반대로 맵핑하기 위해 사용되는 한편, 리타겟팅 표시자 파라미터는 아래에서 더 상세히 설명될 것이다.

IPE가 데이터 맵핑 문서로 프로비저닝되고 나면, 그것은 서비스 계층에의 가입에 사용할 복사본을 더 생성하기 위해 문서를 처리할 수 있다. 이는 IPE의 능력들에 기초하여 아래에 설명된 바와 같은 리타겟팅 표시자(또는 다른 파라미터들)를 변경하는 것을 수반할 수 있다. 그러한 경우, IPE에 의해 사용되는 데이터 모델 맵핑 문서는 서비스 계층에 등록되는 문서와 다를 것이다.

리소스 정의 및 데이터 모델 맵핑 문서들의 콘텐츠는 하나의 문서로 함께 결합될 수 있다는 점에 유의해야 한다. 이러한 시나리오에서, 위에 설명된 절차들이 여전히 적용되지만, 이제는 리소스 정의 및 데이터 모델 맵핑 정보 둘 다를 포함하는 복합 문서에 적용될 것이다. 결과적으로, 리소스 정의 등록 및 관리를 위한 절차들은 데이터 모델 맵핑 등록 및 관리의 절차들과 결합된다. 리소스 정의 문서는 데이터 모델 맵핑 정보도 물론 포함할 것이고, 서비스 계층은 새로운 정보를 스키마 문서에 저장할 수 있거나, 그것들을 2개의 문서로 분리할 수 있다. 데이터 모델 맵핑 정보는 새로운 서비스 계층 리소스 유형들 또는 수정된 리소스 유형 리소스 정의들이 등록되고 상호연동이 요구되지 않은 경우를 지원하기 위해 임의로 만들어질 수 있다.

도 13은 아래에 논의되는 바와 같이, 서비스 계층에 대한 데이터 모델 맵핑 문서의 예시적인 등록 절차를 도시한다.

단계 1에서, IPE는 등록이 리소스 맵핑을 위한 것인지를 나타내기 위해 가상 리소스 "/resourceMappings"을 타겟팅하는 생성 요청을 송신한다. 완전한 리소스 맵핑 문서가 메시지의 페이로드에 추가된다.

단계 2에서, 서비스 계층은 요청에 의해 제공되는 맵핑 문서 내의 리소스 속성 이름들 및 연관된 데이터 유형들이 대응하는 스키마 문서 내의 것들과 매칭하는 것을 검증한다. 이러한 검사는 모든 리소스 특정 속성들이 일부 상호연동된 데이터 모델 리소스에 맵핑될 것을 보장한다. 또한, 맵핑 관리는 배후에서 이루어지며, 리소스 트리 내에는 서비스 계층 리소스들이 생성되지 않는다는 점에 유의해야 한다. 대신, 맵핑들은 장래의 상호연동 요청을 리타겟팅할 때 서비스 계층에 의한 사용을 위해 파일에 저장된다.

단계 3에서, 생성이 성공적이었던 경우, 서비스 계층은 리소스 맵핑 문서의 위치 및 연관된 버전 번호와 함께 적절한 응답을 반환한다.

데이터 모델 맵핑들의 관리 절차들은 타겟 URI에서의 변경을 제외하고는 위에서 설명된 것과 같은 리소스 정의들에 대한 것들을 따른다. "/resourceDefinitions"을 사용하는 것을 대신하여, 타겟 URI는 대신 "/resourceMappings"일 것이다. 데이터 모델 맵핑을 위한 발견 기준은 리소스 정의들에 대해 사용되는 것들의 서브세트이다. 마지막으로, 데이터 모델 맵핑들은 리소스 정의들과 함께 작용할 때 활성화 또는 비활성화될 필요가 없다. 리소스 정의 문서 및 데이터 모델 맵핑 문서가 결합된 경우, 복합 문서에 대해 단 하나의 관리 절차 세트만이 필요하다.

상호연동 리타겟팅 표시자들

상호연동되는 리소스들의 URI들을 제공하는 것에 더하여, 데이터 모델 맵핑은 각각의 맵핑된 리소스에 대한 리타겟팅 표시자를 또한 포함할 수 있다. 이 표시자는 IPE와 서비스 계층 둘 다에게, 각각의 맵핑에 대해 제공되는 리타겟팅 표시자들에 기초하여 리트리브 요청을 언제 리타겟팅할지에 관한 지침을 제공할 수 있다. 생성, 업데이트, 및 삭제 요청들에 대해, 그것들은 상호연동되는 디바이스 상의 리소스와 SL 리소스 사이의 동기화를 보장하기 위해 항상 리타겟팅된다. 표 3은 일 실시예에 따른 리타겟팅 표시자들의 예를 도시한다. 다른 실시예들에서, 더 많거나 적은 리타겟팅 표시자들이 지원될 수 있다. 이러한 리타겟팅 표시자들의 사용은 서비스 계층이 본질적으로 정적 또는 반-정적인 데이터에 대한 불필요한 리트리브 요청들을 수행하는 것으로부터 벗어나는 데에 도움을 줄 수 있다.

표 3에 제공된 리타겟팅 표시자들은 서비스 계층에서 호스팅된 상호연동된 리소스들을 관리하기 위해 IPE에 의해 사용될 수 있다. 서비스 계층에 등록된 맵핑 문서는 2개의 표시자: 일회성 리타겟팅(one-time retarget)과 항상 리타겟팅(always retarget)만을 포함할 수 있다. 리타겟팅 표시자들 2 및 3에 대해, IPE의 능력은 표시자들이 2 또는 3으로부터 1 또는 0으로 독립적으로 변경되는지를 결정할 것이다. IPE가 상호연동되는 디바이스를 관리하는 제3자 서버와 통합되는 경우, IPE는 리타겟팅 표시자 2를 갖는 속성이 언제 변경되는지를 알 수 있고, SL 리소스에 대응하는 업데이트를 행할 수 있다. 마찬가지로 IPE가 주기적 리프레쉬를 지원하는 경우, 그것은 SL 리소스 내에 업데이트된 리타겟팅 표시자 3을 갖는 속성을 유지할 수 있다. 두 경우 모두에서, IPE는 신선도(freshness)를 보장하기 위해 서비스 계층 내의 리소스 속성들을 동적으로 업데이트하고 있고, 데이터 모델 맵핑 문서에서 이러한 속성들을 일회성 리타겟팅으로 구성하고 있다. IPE가 두 가지 능력 중 하나만을 지원하는 경우, 그 능력에 연관된 속성들만이 일회성 리타겟팅으로 구성될 것이다. IPE에 의해 지원되지 않는 특징들을 요구하는 리타겟팅 표시자를 갖는 속성들은 항상 리타겟팅으로 구성될 것이다.

리타겟팅 표시자는 특정 리소스 유형에 적용되는 데이터 모델 맵핑 문서의 일부로서 제공된다. 이는 동일한 리소스 유형을 사용하는 모든 디바이스들에 대해 일관된 리타겟팅 표시자들을 보장할 것이다. 그러나, 리타겟팅 표시자는 각각의 리소스 인스턴스에 기초하여 더 일반적인 방식으로 사용하기 위해 확장될 수 있다. 이는 리소스 인스턴스 레벨에서 더 세분화된(granular) 리타겟팅 제어를 제공한다. 각각의 리소스 인스턴스 및 대응하는 상호연동되는 리소스는 리소스 유형에 독립하여 자기 자신의 리타겟팅 표시자를 가질 수 있다. 예를 들어, 2개의 센서는 상이한 애플리케이션들을 제외하고는 온도 판독값들을 제공하기 위해 동일한 리소스 유형을 사용할 수 있다. 가정에 위치된 하나의 센서는 30분마다 온도 판독값을 필요로 한다. 제2 온도 센서는 매 분마다 판독값들을 요구하는 화학 처리 실험실에 위치되어 있다. 연관된 온도 리소스 인스턴스가 생성될 때, 각각은 "주기적 리타겟팅"을 위해 구성될 것이지만, 상이한 주기들이 지정될 것이다.

리타겟팅 표시자가 상호연동에 사용하기 위해 제안되어 있긴 하지만, 개념들은 기존의 서비스 계층 리타겟팅에도 적용될 수 있다. 예를 들어, 언제 리타겟팅할지에 관하여 서비스 계층에게 지시하기 위해, 표 3에 설명된 것과 같은 새로운 리타겟팅 표시자 속성들이 안내된 리소스들에 추가될 수 있다.

서비스 계층 일반적 상호연동 절차

본 명세서에 개시된 제3 양태에 따라, 리소스 정의 및 리소스 맵핑 문서들 둘 다가 등록된 후, SL 애플리케이션들은 상호연동된 리소스들이 생성된 후 그것들에 대한 요청을 할 수 있다. SL 애플리케이션들은 리소스 발견을 사용하여 다른 SL 리소스들과 마찬가지로 상호연동되는 리소스들을 찾을 수 있다. 발견 후에, 애플리케이션들은 상호연동되는 리소스 상에서 RESTful 동작들을 수행할 수 있고, 다른 SL 리소스들과 마찬가지로 응답들을 얻을 수 있다. 상호연동된 리소스를 타겟팅하는 요청이 이루어질 때, 서비스 계층과 IPE 사이에 일반적 SL 상호연동 절차가 트리거될 수 있다. 이하에서 더 논의되는 이러한 절차는 도 14의 예에 개략적으로 도시되어 있다.

도 14를 참조하면, 단계 0에서, 상호연동 시스템 구성되고 작동된다. 이것은 리소스 정의 및 데이터 모델 맵핑 등록, IPE 및 애플리케이션의 SL 등록, IPE에 대한 IW 디바이스 등록, IPE가 서비스 계층 상에서 상호연동되는 리소스들 및 연관된 가입을 생성하는 것, 및 상이한 관여자들 사이의 통신을 가능하게 하는 데에 필요한 모든 다른 구성들을 포함한다.

단계 1에서, 애플리케이션은 서비스 계층 리소스 발견을 수행하고, 그것이 찾고 있는 상호연동되는 리소스를 찾는다.

단계 2에서, 서비스 계층 내의 상호연동되는 리소스를 타겟팅하는 요청이 행해진다.

단계 3에서, 서비스 계층은 타겟팅된 상호연동된 리소스의 리타겟팅 표시자를 평가하고, 데이터 모델 맵핑 문서를 사용하여 IPE에 요청을 리타겟팅할지 여부에 대한 결정을 한다. 일회성 리타겟팅 속성들의 리트리브 요청들에 대해, SL은 이전의 리타켓팅 요청으로부터 존재하는 경우에 캐싱되었을 수 있는 단계 9의 속성의 값을 반환한다. 캐시 값이 찾아지지 않는 경우, 상호연동된 디바이스로부터의 값을 페치하기 위해 리타겟팅 요청이 이루어진다. 모든 다른 요청들에 대해, 서비스 계층은 요청을 리타겟팅하고 IPE에 송신할 통지 메시지를 생성한다.

단계 4에서, 요청된 리소스에 대해 IPE에 통지가 송신된다.

단계 5에서, IPE는 통지 메시지로부터 타겟팅된 리소스들을 추출하고, 서비스 계층 리소스를 상호연동된 리소스로 변환하기 위해 데이터 모델 맵핑 문서를 사용한다. 추가로, IPE는 데이터 모델 맵핑 문서로부터 획득된 상호연동된 리소스 URI를 타겟팅하는 새로운 요청 메시지를 생성하기 위해 프로토콜 변환을 수행한다.

단계 6에서, IPE는 상호연동되는 디바이스에 디바이스의 기술(예를 들어, LWM2M, OIC 등)과 호환되는 포맷으로 메시지를 송신하고, 디바이스는 IPE에 적절한 응답을 반환한다. IPE가 디바이스를 관리하는 제3자 서버와 통합되지 않은 경우, 이 단계는 다단계의 프로세스일 수 있다. IPE와 제3자 서버 사이는 물론, 제3자 서버와 디바이스 사이에도 메시지 교환들이 존재할 것이다. IPE는 응답을 수신한 후, 서비스 계층에 대한 새로운 응답 메시지를 생성하기 위해, 역방향 프로토콜 변환 및 데이터 모델 맵핑을 수행할 것이다.

단계 7에서, IPE는 서비스 계층에 적절한 응답을 송신한다.

단계 8에서, 서비스 계층은 상호연동된 리소스 속성마다 대응하는 값을 캐싱 할 것인지에 관해 리타겟팅 표시자에 기초하여 결정한다. 표시자가 일회성 리타겟팅으로서 설정되면, 서비스 계층은 장래의 사용을 위해 응답에 정보를 저장할 것이다. 정보가 이미 페치되어 있고 서비스 계층은 저장된 정보를 반환할 수 있으므로, 다른 애플리케이션, 또는 심지어는 동일한 애플리케이션이 서비스 계층 내에 저장된 정보에 대한 후속 리트리브를 수행하는 경우, 리타겟팅은 필요하지 않다.

단계 9에서, 적절한 응답이 요청 애플리케이션에 반환된다.

예시적인 oneM2M 실시예들

도 15는 새로운 oneM2M 공통 서비스 기능(CSF)이 생성되고 기존 CSF들이 업데이트되는 예시적인 실시예를 도시한다. 새로운 리소스 관리 CSF는 리소스 정의 및 리소스 맵핑 등록들 둘 다를 처리할 수 있고, 새로운 상호연동 CSF는 상호연동된 리소스의 리타겟팅 기준을 평가하기 위해 사용될 수 있다. 대안적으로, 리소스 관리 CSF를 대신하여 새로운 리소스 유형들을 생성하는 것을 허용하기 위해 데이터 관리 및 리포지토리가 업데이트될 수 있다.

CSF 변경들에 더하여, 새로운 oneM2M 리소스들 및/또는 리소스 속성들은 서비스 계층에 추가될 수 있다. 표 4는 서비스 계층에 추가될 수 있는 예시적인 새로운 "리소스들"을 보여준다.

예시적인 oneM2M 리소스 정의 문서

도 16에는 oneM2M 내에서 사용될 수 있는 리소스 정의 문서의 예가 도시된다. 이 문서는 리소스 정의 문서의 5개의 주요 섹션, 즉 리소스 정의 정보, 서비스 계층 리소스 속성들, 리소스 특정 속성들, 상호연동되는 리소스의 자식 리소스들, 및 활성화 기준을 보여준다. 리소스 특정 속성들 내에서, dmServerInfoAnnc 요소 태그는 도면 내에서 전체 문서에 맞게 한 줄로 압축되어 있다는 점에 유의해야 한다.

구체적으로, 도 16에 도시된 문서는 LWM2M 서버 정보 객체에 대한 예시적인 리소스 정의를 도시한다. 최상위에는, 리소스들을 이름과 유형에 의해 식별하고 버전 번호, 약식 이름, 리소스 레이블, 및 리소스 트리 내에서 리소스가 존재하는 장소와 같은 리소스에 관한 메타데이터를 제공하기 위해, 다양한 리소스 정보가 제공된다. 리소스 속성들, 리소스 특정 속성들, 및 자식 리소스들 섹션은 oneM2M XSD 파일에 들어가는 콘텐츠를 포함한다. 마지막으로, 활성화 기준 섹션은 리소스의 사용을 가능하게 하기 위해 정의 문서를 활성화하는 방법에 관하여 서비스 계층에게 지시를 제공한다.

리소스 정의 문서는 상호연동 지원의 일부로서 사용되지만, 그것은 정상 서비스 계층 동작들에서 기존 유형들에 기초하여 새로운 리소스 유형들 또는 리소스들을 등록하기 위해서도 사용할 수 있다. 예를 들어, 특정 리소스 유형의 버전 1.0으로 배치되는 서비스 계층은 위에 제시된 사상들을 사용하여 장래에 동일한 리소스의 버전 1.1을 지원하도록 업그레이드될 수 있다. 또한, 리소스는 데이터 모델 맵핑 문서를 필요로 하지 않는 서비스 계층 전용 리소스일 수 있다. 이것이 리소스 정의 문서와 데이터 모델 맵핑 문서가 별도로 등록되고, 리소스 정의만이 활성화될 필요가 있는 이유이다. 동일한 리소스의 상이한 버전들을 지원하는 것에 더하여, 서비스 계층은 홈 오토메이션의 로컬화된 서비스 계층 배치의 경우에서와 같이, 서비스 계층 소유자에 의해 생성된 커스텀 리소스들을 또한 지원할 수 있다.

예시적인 oneM2M 데이터 모델 맵핑 문서

데이터 모델 맵핑 문서는 리소스 정의 문서의 리소스 특정 속성들 섹션 내의 정보를 추출하고, name 파라미터를 유지하고, 각각의 리소스 특정 속성에 대한 targetURI 및 retargetLevel 파라미터들을 추가함으로써 생성된다. 도 17은 XML 포맷의 LWM2M 서버 정보 객체에 대한 데이터 모델 맵핑 문서의 예를 도시한다. 일반 텍스트, JSON, CoRE 링크 포맷 등과 같은 다른 포맷들도 사용할 수 있다. 도 16의 리소스 정의 문서의 리소스 특정 속성들 섹션과 도 17의 데이터 모델 맵핑 문서는 유사하다는 점에 유의해야 한다(예를 들어, 그것들 둘 다가 동일한 리소스 특정 속성들을 포함함).

도 17에 도시된 예시적인 데이터 모델 맵핑 문서는 프로토콜 변환 동안 IPE에 의해 사용된다. 이 문서는 표 3에 의해 지정된 모든 리타겟팅 표시자를 사용한다. 앞에서 언급된 바와 같이, 서비스 계층에 등록되는 데이터 모델 맵핑 문서는 2개의 표시자: 일회성 리타겟팅 및 항상 리타겟팅만을 포함할 것이다. 결과적으로, IPE는 서비스 계층에 등록하는 데 사용할 새로운 데이터 모델 맵핑 문서를 생성한다. 이러한 새로운 문서는 IPE의 능력에 기초하여 리타겟팅 표시자들 2 및 3을 0 또는 1로 변경할 것이다. 이 경우에서의 예는 IPE와 제3자 서버를 별개의 엔티티들로서 가지며, IPE는 주기적 리타겟팅만을 지원한다.

도 18은 IPE가 서비스 계층에 등록하는 예시적인 데이터 모델 맵핑 문서를 도시한다. IPE는 주기적인 리타겟팅을 지원하기 때문에, lifetime 속성의 리타겟팅 레벨은 0(일회성 리타겟팅)으로 설정된다. IPE는 이 능력을 지원하며, 이 리소스 속성을 동적으로 업데이트할 것이고, 따라서 서비스 계층은 항상 최신 값을 가질 것이다. 리타겟팅 표시자 2(변경 시에 리타겟팅)를 갖는 도 17의 다른 속성들에 대해, IPE는 이 특징을 지원하지 않는다. 따라서, 그러한 값들은 1(항상 리타겟팅)로 설정된다.

예시적인 호출 흐름들

위에서 논의된 바와 같이, 상이한 수직적 마켓들 또는 심지어는 동일한 수직적 마켓의 벤더들로부터의, 그리고 상이한 시스템들로부터의 리소스들을 상호연동시키기 위한 동적 리소스 관리를 지원하기 위한 유연성을 제공함으로써, 서비스 계층 배치들에 엄청난 가치가 부가될 수 있다. 추가로, 기존 서비스 계층 리소스들(예를 들어, <mgmtObj> 및 <flexContainer>)은 서비스 계층 서비스 제공자 또는 소유자에 대해 커스텀화될 수 있다. 이러한 다수의 이점들은 아래에 논의된 oneM2M <mgmtObj> 및 <flexContainer> 상호연동 예, 다수의 벤더 상호연동 예들, 및 LWM2M 상호연동 예에서 설명된다.

oneM2M < mgmtObj > XSD 활성화 예

oneM2M의 <mgmtObj> 리소스는 objectAttribute 속성을 통해 디바이스 관리(예를 들어, LWM2M)에서 사용할 특수화된 리소스들을 생성하는 능력을 제공한다. 이것은 기저 디바이스 관리 기술의 데이터 모델 리소스들에 직접 맵핑하기 위해 사용될 수 있는 커스텀화가능한 속성이다. mgmtDefinition 및 objectIDs 속성들은 <mgmtObj> 리소스가 어떤 유형의 특수화 객체에 대해 커스텀화되는지를 정의한다. 현재, 이러한 속성들은 표준화 프로세스 내에서 정의되고, 따라서 새로운 특수화를 동적으로 정의하기 위한 유연성을 제공하지 않는다.

위에서 제시된 사상들을 사용하여, 현재의 oneM2M <mgmtObj> 리소스는 새로운 특수화 리소스들을 동적으로 지원하기 위해 업데이트될 수 있다. 표 5는 새로운 특수화 리소스들을 동적으로 정의하는 것을 지원하기 위해, <mgmtObj> 리소스에 대한 리소스 특정 속성들은 물론, objectIDs 속성에 대한 제안된 변경을 보여준다. 변경은 LWM2M 객체 정의에 대응하는 특수화된 <mgmtObj> 리소스의 XSD에 대한 URN 또는 URI를 제공하도록 objectIDs 속성을 수정하기 위해 <mgmtObj> 리소스의 정의에 대해 부연한다. objectIDs는 특수화된 <mgmtObj> 리소스의 생성 동안 지정될 수 있다. objectIDs 속성 내에서 URI를 지정하는 옵션은 CSE가 CSE의 초기 배치 시에는 이용불가능했던 새로운 LWM2M 객체들을 지원하는 것을 허용한다. 이는 특히 벤더 특정 LWM2M 객체들의 경우 특히 그렇다. URI는 CSE에 의한 사용을 위해 새로운 특수화된 <mgmtObj> 리소스의 XSD가 발견될 수 있고 리트리브될 수 있는 위치를 가리킬 것이다.

도 19는 oneM2M 호스팅 CSE가 objectIDs 속성을 사용하여 새로운 특수화된 <mgmtObj> 리소스를 생성하기 위해 실행하는 업데이트된 절차를 보여준다.

단계 001에서, 발원자는 필수적 파라미터들을 송신하고, 특수화된 <mgmtObj> 리소스의 CREATE 동작을 위해 요청 메시지 내에 임의적 파라미터들을 송신할 수 있다. 특수화된 <mgmtObj> 리소스는 기저 LWM2M 객체의 전체 맵핑을 포함하며, objectIDs 속성 내에 새로운 특수화된 리소스에 대한 XSD의 URI를 포함한다.

단계 002에서, 수신자는:

발원자가 요청을 수행하기 위한 적절한 권한들을 갖는지를 검사하고;

Content 파라미터 내의 resourceName 속성에 의해 제안된 대로의 생성된 리소스에 대한 이름이 타겟팅된 리소스의 자식 리소스들 사이에 이미 존재하지 않는다는 것을 확인한다.

단계 003에서, 수신자는 특수화된 <mgmtObj> 리소스가 CSEBase의 supportedResourceType 속성에서 찾아지는지를 검사한다. supportedResourceType 속성 내에서 특수화된 <mgmtObj> 리소스가 찾아지는 경우에는 단계 8로 가고; 그렇지 않으면 단계 4로 간다.

단계 004에서, 수신자는 objectIDs 속성의 콘텐츠를 추출하고, XSD 리포지토리로부터 XSD를 리트리브한다.

단계 005에서, XSD 리포지토리는 특수화된 <mgmtObj> 리소스에 대한 XSD를 반환한다.

단계 006에서, 수신자는 수신된 XSD가 잘 형성되는 것을 검사하고, 그렇다면, 수신자의 로컬 XSD 리포지토리에 XSD를 저장한다.

단계 007에서, 수신자는 특수화된 <mgmtObj>의 이름으로 supportedResourceType 속성을 업데이트한다.

단계 008에서, 수신자는 CREATE 요청의 처리를 완료한다. 이것은 다음을 포함할 수 있다:

생성될 리소스에 리소스 ID를 할당하는 것; 및

리소스의 필수적 RO(판독 전용) 모드 속성들을 위한 값들을 할당하고, 리소스 유형 정의에 의해 허용되는 경우 및 발원자 자체에 의해 제공되지 않는 경우 다른 필수적 속성들에 대해 제공된 값들을 오버라이드하는 것.

수신자는 이하의 공통 속성들에 값을 할당한다:

parentID;

creationTime;

expirationTime: 발원자에 의해 제공되지 않는 경우, 수신자는 (수신자 정책들의 제약 내에서) 가능한 최대 값을 할당한다. 정책 또는 가입 제약들로 인해, 발원자에 의해 제공된 값이 지원될 수 없는 경우, 수신자는 새로운 값을 할당할 것이다;

lastModifiedTime: creationTime과 동일하다;

수신자 정책들의 제약 내에서의 임의의 다른 RO 속성들.

수신자는 creator 속성이 요청의 Content 파라미터 내에 포함되는지를 검사한다. 포함되는 경우, creator 속성은 요청의 Content 파라미터 내에 값을 갖지 않을 수 있다. 한편, creator 속성이 요청의 Content 파라미터 내에 포함되지 않는 경우, 수신자는 생성될 리소스에 creator 속성을 포함하지 않을 수 있다.

생성 요청의 성공적인 검증 시, 수신자는 요청된 리소스를 생성한다;

수신자는 생성된 자식 리소스가 그것의 부모 리소스의 속성(들)에서의 변경들을 초래하는지를 검사한다. 그렇다면, 부모 리소스의 속성(들)이 업데이트된다.

단계 009에서, 수신자는 필수적 파라미터들로 응답하고, CREATE 동작에 대한 응답 메시지 내에 임의적 파라미터들을 송신할 수 있다.

일반적 예외들:

발원자는 수신자 상에서 리소스를 생성할 권한들을 갖지 않을 수 있다. 그러한 경우, 수신자는 에러로 응답할 수 있다.

지정된 이름(제공되는 경우)을 갖는 리소스가 수신자에 이미 존재한다. 그러한 경우, 수신자는 에러로 응답할 수 있다.

Content 내의 제공된 정보가 수신자에 의해 수락되지 않는다(예를 들어, 필수적 파라미터 누락). 그러한 경우에서, 수신자는 에러로 응답할 수 있다.

oneM2M LWM2M 상호연동 예

도 20은 LWM2M 서버 정보 객체 리소스의 defMinPeriod 속성의 리트리브에 적용되는, 도 14에 지정된 예시적인 일반적인 상호연동 절차를 도시한다. 도 16은 CSE가 LWM2M 서버 정보 리소스를 인식하고, 그것이 생성 및 액세스되는 것을 허용하기 위한 리소스 정의를 제공한다. 한편, 도 18은 LWM2M 서버 정보 리소스의 속성들에 대한 리타겟팅 표시자들은 물론, 프로토콜 변환에 사용되는 데이터 모델 맵핑 정보를 제공한다. 도 14의 데이터 모델 맵핑 및 프로토콜 변환 양태들을 강조표시하기 위해, 관련 정보만이 호출 흐름 내에 포함됨에 유의해야 한다.

단계 0에서, 상호연동 시스템이 구성되고 작동된다. 이것은 LWM2M 서버 정보 객체에 대한 리소스 정의 및 데이터 모델 맵핑 등록, LWM2M 서버/IPE에 대한 LWM2M 디바이스 등록, CSE에 대한 LWM2M 디바이스의 IPE에 의한 등록 및 LWM2M 서버 정보 리소스(lwm2m1)의 생성 및 연관 가입, 및 상이한 관여자들 사이의 통신들을 가능하게 하는 데 필요한 다른 모든 구성들을 포함한다.

단계 1에서, AE는 LWM2M 서버 정보 리소스 lwm2m1의 defMinPeriod 속성의 리트리브를 수행한다.

단계 2에서, CSE는 도 18에 도시된 바와 같은 defMinPeriod 속성에 대해 제공된 리타겟팅 표시자를 검사한다. 리타겟팅 표시자가 1(항상 리타겟팅)로 설정되므로, CSE는 요청을 리타겟팅하기 위한 결정을 한다.

단계 3에서, CSE는 생성된 가입에 기초하여 IPE에 메시지를 송신한다. 대안적으로, CSE는 또한 메시지를 리타겟팅하기 위해 LWM2M 디바이스에 연관된 AE 리소스의 pointOfAccess 속성을 사용하거나, CSE가 IPE에게 리타겟팅 요청을 통지하는 다른 메커니즘을 사용할 수 있다.

단계 4에서, 메시지를 수신하면, IPE는 oneM2M 프로토콜로부터의 LWM2M 프로토콜로의 요청의 프로토콜 변환을 수행한다. 프로토콜 변환의 일부로서, 데이터 모델 맵핑이 활용되는 새로운 LWM2M 메시지가 생성된다. defMinPeriod 속성은 도 18에 도시된 맵핑들에 기초하여 LWM2M URI "/1/0/2"로 변환된다. 이러한 경우, "0"은 lwm2m1 리소스에 연관된 인스턴스 번호이다. 이 번호는 lwm2m1 리소스가 생성될 때 IPE에 의해 제공되었다.

단계 5에서, 다음으로, IPE/LWM2M 서버는 새롭게 생성된 메시지를 LWM2M 디바이스에 송신한다. 메시지 "Get /1/0/2"는 defMinPeriod 값을 리트리브하라는 LWM2M 요청이다.

단계 6에서, LWM2M 디바이스는 적절한 값: 86400을 갖는 "2.05 Content" 응답 코드를 반환한다.

단계 7에서, IPE는 LWM2M 응답을 oneM2M 응답 포맷으로 변환한 후, CSE에 동일한 값을 반환한다.

단계 8에서, CSE는 값이 장래의 사용을 위해 캐싱되어야 하는지를 결정하기 위해 defMinPeriod를 위한 리타겟팅 표시자를 사용한다. 이 경우, 표시자가 항상 리타겟팅으로 설정되므로, 캐싱은 필요하지 않다.

단계 9에서, CSE는 값 86400과 함께 AE에 적절한 응답을 반환한다.

oneM2M < flexContainer > XSD 활성화 예

oneM2M <flexContainer> 리소스는 containerDefinition 속성을 통해 베이스 <flexContainer> 리소스로부터 도출된 새로운 리소스의 콘텐츠를 설명하기 위해 XSD 파일의 위치를 지정하는 능력을 제공한다. 그러나, oneM2M 사양 TS-0001은 CSE가 이러한 요청을 어떻게 처리하는지를 지정하지 않고, <flexContainer> 리소스를 사용하는 특수화들의 목록을 식별했다. 도 21은 <flexContainer> 리소스에 기초하여 새로운 리소스 정의들을 등록하고 활성화하는 능력을 제공하기 위해 <flexContainer> 리소스의 생성이 어떻게 통합되는지의 예를 제공한다. 이러한 새로운 리소스들은 여전히 <flexContainer> 리소스 유형으로 분류될 것이다. 따라서, 리소스 정의는 필요하지 않다.

단계 1에서, AE는 <flexContainer> 리소스를 생성하고, XSD 파일의 위치의 URI를 갖는 containerDefinition 속성을 지정한다.

단계 2에서, CSE는 AE가 <flexContainer> 리소스를 생성할 수 있음을 보장하기 위해 액세스 제어 정책(ACP) 검사를 수행한다. 추가로, CSE는 또한 AE가 CSE의 로컬 리포지토리에 존재하지 않는 경우 XSD 파일을 등록하고 활성화할 수 있는 것을 확인하기 위해 인가 검사를 수행할 수 있다.

단계 3에서, ACP 검사가 성공적이었던 경우, CSE는 모든 요구되는 정보가 요청 내에 존재하는 것을 확인하기 위해 요청을 검증한다. 이러한 검증의 일부로서, CSE는 containerDefinition 속성이 존재하는 것을 검사한다.

단계 4에서, 단계 3으로부터의 검증 요청 및 단계 2로부터의 인가 검사가 성공적인 경우, CSE는 그것의 로컬 리포지토리 내에 요청의 페이로드에 제공된 <flexContainer> 리소스와 매칭하는 XSD 파일이 존재하는지를 검사한다.

단계 5에서, 단계 4로부터 매칭이 찾아지지 않으면, CSE는 containerDefinition 속성으로부터 URI를 추출하고, XSD 리포지토리로부터 XSD 파일을 페치한다.

단계 6에서, CSE는 XSD 파일을 수신한다.

단계 7에서, 활성화 절차의 일부로서, CSE는 XSD 파일이 잘 형성되는 것을 검사한다.

단계 8에서, CSE는 XSD 파일이 잘 형성된 경우 장래의 사용을 위해 그것의 로컬 리포지토리에 XSD 파일을 저장한다.

단계 9에서, CSE는 또한 CSE 베이스 리소스에서의 supportedResourceType 속성을 업데이트한다.

단계 10에서, CSE는 요청된 리소스를 XSD에 대해 검증한다.

단계 11에서, 이전의 검사들 모두가 성공한 경우, CSE는 <flexContainer> 리소스를 생성한다.

단계 12에서, CSE는 이러한 절차에서의 검사들의 상태에 의존하여 적절한 응답을 송신한다.

다수의 벤더 상호연동 예

도 22는 아래에 논의되는 바와 같이, CSE에 자신의 디바이스들을 상호연동시킨 2개의 벤더의 예를 도시한다. 그와 같이 하는 데에 있어서, 각각의 벤더는 자신의 서비스들을 공통 서비스 계층 플랫폼에 제공하고, 그들의 제품 제공의 차별화를 제공할 수 있다. 다음으로, AE는 각각의 벤더의 데이터 모델을 이해할 필요 없이, 그러한 리소스들을 발견하고 그에 액세스하여 벤더들 각각으로부터 서비스들을 획득할 수 있다.

단계 0에서, 모든 CSE 등록들(IPE들 및 AE)이 완료되고 성공적인 채로, 상호연동 시스템이 구성되고 작동된다. 벤더들 A 및 B는 리소스 정의 및 데이터 모델 맵핑 등록 절차들을 사용하여 그들의 리소스들을 CSE에 상호연동시켰다. AE는 벤더들 둘 다의 리소스들을 발견했고, 그것들에 액세스하려고 한다.

단계 1에서, AE는 벤더 A 리소스에 대한 요청을 수행한다.

단계 2에서, CSE는 리타겟팅 표시자들을 검사하고, 벤더 A/IPE에 요청을 리타겟팅하기 위한 결정을 한다.

단계 3에서, CSE는 벤더 A/IPE에게 리타겟팅된 요청을 송신하고, 응답을 수신한다.

단계 4에서, CSE는 벤더 A의 리소스로부터의 데이터와 함께 AE에게 응답을 반환한다.

단계 5-8에서, 벤더 B의 리소스에 대해 단계 1 내지 4를 반복한다.

도 22에 도시된 예는 도 6에 제시된 예와 매우 유사하며, 주된 차이점은 후자는 상이한 시스템들 사이의 상호연동을 수반하는 반면, 전자는 상이한 분야들, 또는 심지어는 동일한 분야의 벤더들을 수반할 수 있다는 점이다. 각각의 경우에서, 애플리케이션들은 네이티브 서비스 계층 절차들을 사용하여 이러한 다양한 리소스들에 심리스하게(seamlessly) 액세스할 수 있다.

지능적인 리타겟팅 상호연동 예

다른 예에서, LWM2M 아키텍처는 복수의 LWM2M 서버가 동일한 LWM2M 클라이언트 또는 디바이스를 관리하는 것을 허용한다. 상호연동 시나리오에서, 동일한 디바이스를 관리하는 2개의 LWM2M 서버가 존재할 수 있는데, 하나는 전통적인 LWM2M 서버이고 다른 하나는 IPE와 통합된 LWM2M 서버이다. 도 23은 아래에 논의된 바와 같이, LWM2M 서버 1이 전통적인 서버이고, LWM2M 서버 2가 상호연동 서버인 그러한 예시적인 시나리오를 도시한다. 이 예에서, LWM2M 서버 둘 다가 LWM2M 디바이스를 능동적으로 관리하고 있다. LWM2M 서버 2/IPE는 펌웨어 업데이트 객체의 펌웨어 버전 리소스에 대해 "업데이트 시 변경"의 리타겟팅 표시자를 구성했다. 결과적으로, LWM2M 서버 2는 FW 업데이트의 통지들을 얻기 위한 관측 요청을 했다.

단계 0에서, 모든 CSE 등록이 완료되고 성공적인 채로 상호연동 시스템이 구성되고 작동된다. LWM2M 디바이스는 전통적인 LWM2M 서버 1 및 상호연동된 LWM2M 서버 2에 의해 관리되고 있다. IPE와 통합된 LWM2M 서버 2는 LWM2M 디바이스의 펌웨어 버전 리소스에 대한 관측을 갖고, 펌웨어 업데이트가 수행되고 성공적인 때를 알게 된다. 결과적으로, IPE는 CSE 상에서 업데이트된 펌웨어 버전 속성을 유지하는 것을 지원하고, 일회성 리타겟팅에 대한 연관된 데이터 모델 맵핑을 구성한다.

단계 1에서, LWM2M 서버 1은 LWM2M 디바이스 상에서 펌웨어 업데이트를 수행하고 성공적인 응답을 수신한다.

단계 2에서, LWM2M 디바이스는 새로운 펌웨어 버전과 함께 LWM2M 서버 2에 통지를 송신한다.

단계 3에서, IPE는 리타겟팅 표시자에 기초하여, CSE 상의 펌웨어 버전을 업데이트하기 위한 결정을 한다.

단계 4에서, IPE는 새로운 버전 번호로 CSE 상의 펌웨어 버전 속성을 업데이트한다.

사용자 인터페이스

도 24는 서비스 계층이 서버 내에 등록된 리소스 정의들을 디스플레이하는 예시적인 사용자 인터페이스를 도시한다. 대안적으로, 이것은 리소스 정의들을 발견하고 LWM2M:1 정의 문서를 리트리브한 후 SL 애플리케이션에 의해 디스플레이될 수 있다. 사용자 인터페이스는 정의 이름 및 버전 번호를 갖는 리소스 정의들의 목록을 상호연동되는 표준의 로고와 함께 윈도우의 좌측 구획에 보여준다. 도 24는 사용자가 강조표시된 LWM2M:1 리소스 정의를 선택하는 것을 보여준다. 윈도우의 우측 구획에는 LWM2M:1에 대한 리소스 정의의 콘텐츠가 보여진다. 유사한 디스플레이가 데이터 모델 맵핑 문서들을 보여주기 위해 사용될 수 있다.

예시적인 환경

도 9-14 및 도 19-23의 단계들은, 통신 네트워크 내의 논리적 엔티티들을 표현할 수 있고, 아래에 더 완전하게 설명되는 도 25c 또는 도 25d에 도시된 일반적 아키텍처들 중 하나를 포함할 수 있는 그러한 네트워크의 장치의 메모리 내에 저장되고 그것의 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있는, 그러한 도면들 내에 도시된 각각의 엔티티들에 의해 수행될 수 있음을 이해해야 한다. 즉, 도 9-14 및 도 19-23에 도시된 동작(들)은 예를 들어 도 25c 또는 도 25d에 도시된 아키텍처들 중 하나를 갖는 장치와 같은 네트워크 장치의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있고, 그러한 컴퓨터 실행가능한 명령어들은 장치의 프로세서에 의해 실행될 때 도면에 도시된 단계들을 수행한다. 또한, 도 9-14 및 도 19-23에 도시된 임의의 전송 및 수신 단계들은 장치의 프로세서 및 그것이 실행하는 컴퓨터 실행가능한 명령어들(예를 들어, 소프트웨어)의 제어 하에서 장치의 통신 회로[예를 들어, 각각 도 25c 및 도 25d의 회로(34 또는 97)]에 의해 수행될 수 있음이 이해된다.

도 25a는 하나 이상의 개시된 실시예가 구현될 수 있는 예시적인 머신-대-머신(M2M), 사물 인터넷(IoT), 또는 사물 웹(WoT) 통신 시스템(10)의 도면이다. 일반적으로, M2M 기술들은 IoT/WoT를 위한 구축 블록들을 제공하며, 임의의 M2M 디바이스, M2M 게이트웨이, M2M 서버, 또는 M2M 서비스 플랫폼은 IoT/WoT의 컴포넌트 또는 장치는 물론 IoT/WoT 서비스 계층 등일 수 있다. 도 1, 4-15, 및 19-23 중 임의의 것에 도시된 엔티티들 중 임의의 것은 도 25a-25d에 도시된 것들과 같은 통신 시스템의 네트워크 장치를 포함할 수 있다.

서비스 계층은 네트워크 서비스 아키텍처 내의 기능 계층일 수 있다. 서비스 계층들은 전형적으로 HTTP, CoAP 또는 MQTT와 같은 애플리케이션 프로토콜 계층 위에 놓이며, 클라이언트 애플리케이션들에 부가가치 서비스들을 제공한다. 서비스 계층은 또한 예를 들어 제어 계층 및 전송/액세스 계층과 같은 하위 리소스 계층에서 코어 네트워크들에 대한 인터페이스를 제공한다. 서비스 계층은 서비스 정의, 서비스 런타임 활성화(service runtime enablement), 정책 관리, 액세스 제어, 및 서비스 클러스터링을 포함하는 복수의 카테고리의 (서비스) 능력들 또는 기능성들을 지원한다. 최근, 예를 들어 oneM2M과 같은 몇몇 산업 표준 기구는 M2M 유형의 디바이스들 및 애플리케이션들을 인터넷/웹, 셀룰러, 엔터프라이즈, 및 홈 네트워크와 같은 배치에 통합하는 것에 연관된 난제들을 해결하기 위해 M2M 서비스 계층들을 개발해왔다. M2M 서비스 계층은 애플리케이션들 및/또는 다양한 디바이스들에, CSE 또는 SCL이라고 지칭될 수 있는 서비스 계층에 의해 지원되는 위에서 언급된 능력들 또는 기능성들의 모음 또는 그것들의 세트에 대한 액세스를 제공할 수 있다. 몇 가지 예는 다양한 애플리케이션들에 의해 공통적으로 사용될 수 있는 보안, 요금청구, 데이터 관리, 디바이스 관리, 발견, 프로비저닝 및 접속성 관리를 포함하지만 이에 제한되지는 않는다. 이러한 능력들 또는 기능성들은 M2M 서비스 계층에 의해 정의된 메시지 포맷들, 리소스 구조들 및 리소스 표현들을 활용하는 API들을 통해 그러한 다양한 애플리케이션에게 이용가능하게 된다. CSE 또는 SCL은 하드웨어 및/또는 소프트웨어에 의해 구현될 수 있으며, 다양한 애플리케이션들 및/또는 디바이스들이 그러한 능력들 또는 기능성들을 사용하도록, 그것들에 노출되는 (서비스) 능력들 또는 기능성들을 제공하는 기능적 엔티티이다(즉, 그러한 기능적 엔티티들 사이의 기능적 인터페이스들).

도 25a에 도시된 바와 같이, M2M/IoT/WoT 통신 시스템(10)은 통신 네트워크(12)를 포함한다. 통신 네트워크(12)는 고정 네트워크(예를 들어, 이더넷, 광섬유, ISDN, PLC 등), 또는 무선 네트워크(예를 들어, WLAN, 셀룰러 등), 또는 이종 네트워크들의 네트워크일 수 있다. 예를 들어, 통신 네트워크(12)는 음성, 데이터, 비디오, 메시징, 방송 등과 같은 콘텐츠를 다수의 사용자에게 제공하는 복수의 액세스 네트워크로 구성될 수 있다. 예를 들어, 통신 네트워크(12)는 코드 분할 다중 액세스(CDMA), 시분할 다중 액세스(TDMA), 주파수 분할 다중 액세스(FDMA), 직교 FDMA(OFDMA), 싱글 캐리어 FDMA(SC-FDMA) 등과 같은 하나 이상의 채널 액세스 방법을 이용할 수 있다. 또한, 통신 네트워크(12)는 예를 들어 코어 네트워크, 인터넷, 센서 네트워크, 산업 제어 네트워크, 개인 영역 네트워크, 융합된 개인 네트워크, 위성 네트워크, 홈 네트워크, 또는 기업 네트워크와 같은 다른 네트워크들을 포함할 수 있다.

도 25a에 도시된 바와 같이, 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(예를 들어, 지그비, 6L0WPAN, 블루투스), 직접 무선 링크 및 유선을 포함하는 다양한 네트워크들을 통해 통신할 수 있다. 예시적인 M2M 디바이스들은 태블릿, 스마트 폰, 의료 디바이스, 온도 및 날씨 모니터, 커넥티드 카, 스마트 미터, 게임 콘솔, 개인용 정보 단말, 헬스 및 피트니스 모니터, 조명, 서모스탯, 가전 제품, 차고 문 및 다른 액추에이터 기반 디바이스, 보안 장치 및 스마트 콘센트를 포함하지만, 그에 제한되지 않는다.

도 25b를 참조하면, 필드 도메인 내의 도시된 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 애플리케이션(20') 및 기저 통신 네트워크(12)에 대한 서비스들을 제공한다. M2M 서비스 계층(22')은 또한 필드 도메인에서 M2M 게이트웨이들(14) 및 M2M 디바이스들(18)에 대한 서비스들을 제공한다. M2M 서비스 계층(22')은 임의의 수의 M2M 애플리케이션, M2M 게이트웨이 및 M2M 디바이스와 통신할 수 있음을 이해할 것이다. M2M 서비스 계층(22')은 다른 서비스 제공자에 의해 서비스 계층과 상호작용할 수 있다. M2M 서비스 계층(22')은 서버들, 컴퓨터들, 디바이스들, 가상 머신들(예를 들어, 클라우드 컴퓨팅/스토리지 팜 등) 등을 포함할 수 있는 네트워크의 하나 이상의 네트워크 장치에 의해 구현될 수 있다.

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

M2M 애플리케이션들(20 및 20')은 운송, 헬스 및 웰니스, 커넥티드 홈, 에너지 관리, 자산 추적, 및 보안 및 감시와 같은, 그러나 그에 제한되지는 않는 다양한 산업 분야의 애플리케이션들을 포함할 수 있다. 위에서 언급된 바와 같이, 시스템의 디바이스들, 게이트웨이들, 서버들, 및 다른 네트워크 장치들에 걸쳐 운영되는 M2M 서비스 계층은, 예를 들어 데이터 수집, 디바이스 관리, 보안, 청구, 위치 추적/지오펜싱(geofencing), 디바이스/서비스 발견, 및 레거시 시스템 통합과 같은 기능들을 지원하고, 이러한 기능들을 M2M 애플리케이션들(20 및 20')에 대한 서비스들로서 제공한다.

일반적으로, 도 25b에 도시된 서비스 계층들(22 및 22')과 같은 서비스 계층은 애플리케이션 프로그래밍 인터페이스들(API) 및 기저 네트워킹 인터페이스들의 세트를 통해 부가가치 서비스 능력들을 지원하는 소프트웨어 미들웨어 계층을 정의한다. ETSI M2M 및 oneM2M 아키텍처 둘 다는 서비스 계층을 정의한다. ETSI M2M의 서비스 계층은 서비스 능력 계층(SCL)이라고 지칭된다. SCL은 ETSI M2M 아키텍처의 다양한 상이한 노드들에서 구현될 수 있다. 예를 들어, 서비스 계층의 인스턴스는 M2M 디바이스[디바이스 SCL(DSCL)이라고 지칭됨], 게이트웨이[게이트웨이 SCL(GSCL)이라고 지칭됨], 및/또는 네트워크 노드[네트워크 SCL(NSCL)이라고 지칭됨] 내에서 구현될 수 있다. oneM2M 서비스 계층은 공통 서비스 기능들(CSF)(즉, 서비스 능력들)의 세트를 지원한다. 하나 이상의 특정 유형의 CSF들의 세트의 인스턴스화는 상이한 유형들의 네트워크 노드들(예를 들어, 기반구조 노드, 중간 노드, 애플리케이션-특정 노드)에서 호스팅될 수 있는 공통 서비스 엔티티(CSE)로 지칭된다. 3세대 파트너쉽 프로젝트(3GPP)는 또한 머신 유형 통신(MTC)을 위한 아키텍처를 정의했다. 그러한 아키텍처에서, 서비스 계층, 및 그것이 제공하는 서비스 능력들은 서비스 능력 서버(SCS)의 일부로서 구현된다. ETSI M2M 아키텍처의 DSCL, GSCL 또는 NSCL에서 구현되는지, 3GPP MTC 아키텍처의 서비스 능력 서버(SCS)에서 구현되는지, oneM2M 아키텍처의 CSF 또는 CSE에서 구현되는지, 또는 네트워크의 소정의 다른 노드에서 구현되는지에 무관하게, 서비스 계층의 인스턴스는 서버들, 컴퓨터들, 및 다른 컴퓨팅 디바이스들 또는 노드들을 포함하는 네트워크 내의 하나 이상의 독립형 노드 상에서, 또는 하나 이상의 기존 노드의 일부로서 실행되는 논리적 엔티티(예를 들어, 소프트웨어, 컴퓨터 실행가능 명령어들 등)로서 구현될 수 있다. 예로서, 서비스 계층 또는 그 컴포넌트의 인스턴스는 이하에 설명되는 도 25c 또는 도 25d에 도시된 일반적인 아키텍처를 갖는 네트워크 장치(예를 들어, 서버, 컴퓨터, 게이트웨이, 디바이스 등)에서 실행되는 소프트웨어의 형태로 구현될 수 있다.

또한, 본 명세서에 설명된 방법들 및 기능성들은 서비스들에 액세스하기 위해 서비스 지향 아키텍처(SOA) 및/또는 리소스 지향 아키텍처(ROA)를 사용하는 M2M 네트워크의 일부로서 구현될 수 있다.

도 25c는 도 25a 및 도 25b에 도시된 것과 같은 M2M 네트워크 내에서 M2M 서버, 게이트웨이, 디바이스, 또는 다른 네트워크 장치로서 동작할 수 있는, 도 1, 4-15, 및 19-23에 도시된 엔티티들 중 하나와 같은 네트워크의 장치의 예시적인 하드웨어/소프트웨어 아키텍처의 블록도이다. 도 25d에 도시된 바와 같이, 네트워크 장치(30)는 프로세서(32), 고정식 메모리(44), 이동식 메모리(46), 스피커/마이크로폰(38), 키패드(40), 디스플레이, 터치패드, 및/또는 표시자들(42), 전원(48), 전지구적 측위 시스템(global positioning system)(GPS) 칩셋(50), 및 다른 주변장치들(52)을 포함할 수 있다. 네트워크 장치(30)는 또한 송수신기(34) 및 송신/수신 요소(36)와 같은 통신 회로를 포함할 수 있다. 네트워크 장치(30)는 실시예와의 일관성을 유지하면서, 상술한 요소들의 임의의 서브컴비네이션(sub-combination)을 포함할 수 있다는 것을 알아야 한다. 이 네트워크 장치는 도 9-14 및 19-23에 관련하여 도시되고 설명된 방법들과 같이, 본 명세서에 설명된 메시지 템플릿 관리 능력들 및 방법들을 구현하는 장치일 수 있다.

프로세서(32)는 범용 프로세서, 특수 목적 프로세서, 종래의 프로세서, 디지털 신호 프로세서(DSP), 복수의 마이크로프로세서, DSP 코어에 연관된 하나 이상의 마이크로프로세서, 제어기, 응용 특정 집적 회로들(ASICs: Application Specific Integrated Circuits), 필드 프로그래머빌 게이트 어레이(FPGA: Field Programmable Gate Array) 회로, 임의의 다른 유형의 집적 회로(IC), 상태 머신(state machine) 등일 수 있다. 일반적으로, 프로세서(32)는 네트워크 장치의 다양한 요구된 기능들을 수행하기 위해 네트워크 장치의 메모리[예를 들어, 메모리(44) 및/또는 메모리(46)]에 저장된 컴퓨터 실행가능한 명령어들을 실행할 수 있다. 예를 들어, 프로세서(32)는 네트워크 장치(30)가 무선 또는 유선 환경에서 동작할 수 있게 하는 신호 코딩, 데이터 처리, 전력 제어, 입력/출력 처리, 및/또는 임의의 다른 기능성을 수행할 수 있다. 프로세서(32)는 애플리케이션 계층 프로그램들(예를 들어, 브라우저들) 및/또는 무선 액세스 계층(RAN: radio access-layer) 프로그램 및/또는 다른 통신 프로그램을 실행할 수 있다. 또한, 프로세서(32)는 예를 들어 액세스 계층 및/또는 애플리케이션 계층에서와 같이, 인증, 보안 키 협의, 및/또는 암호 연산들과 같은 보안 동작들을 수행할 수 있다.

도 25c에 도시된 바와 같이, 프로세서(32)는 자신의 통신 회로[예컨대, 송수신기(34) 및 송신/수신 요소(36)]에 연결된다. 프로세서(32)는 컴퓨터 실행가능한 명령어들의 실행을 통해, 네트워크 장치(30)가 자신이 접속된 네트워크를 통해 다른 노드들과 통신하게 하기 위해 통신 회로를 제어할 수 있다. 구체적으로, 프로세서(32)는 본 명세서(예를 들어, 도 9-14 및 24-26) 및 청구항들에 설명된 송신 및 수신 단계들을 수행하기 위해 통신 회로를 제어할 수 있다. 도 25c는 프로세서(32) 및 송수신기(34)를 별개의 컴포넌트들로서 도시하지만, 프로세서(32) 및 송수신기(34)는 전자 패키지 또는 칩 내에 함께 통합될 수 있음을 알 것이다.

송신/수신 요소(36)는 M2M 서버, 게이트웨이, 디바이스 등을 포함하는 다른 네트워크 장치들에 신호들을 송신하거나 그로부터 신호들을 수신하도록 구성될 수 있다. 예를 들어, 실시예에서, 송신/수신 요소(36)는 RF 신호들을 송신 및/또는 수신하도록 구성된 안테나일 수 있다. 송신/수신 요소(36)는 WLAN, WPAN, 셀룰러 등과 같은 다양한 네트워크들 및 에어 인터페이스들을 지원할 수 있다. 실시예에서, 송신/수신 요소(36)는 예를 들어 IR, UV, 또는 가시광 신호들을 송신 및/또는 수신하도록 구성된 방출기/검출기일 수 있다. 또 다른 실시예에서, 송신/수신 요소(36)는 RF 신호 및 광 신호 둘 다를 송신 및 수신하도록 구성될 수 있다. 송신/수신 요소(36)는 무선 또는 유선 신호의 임의의 조합을 송신 및/또는 수신하도록 구성될 수 있음을 알 것이다.

추가로, 송신/수신 요소(36)가 도 25c에 단일 요소로서 도시되어 있지만, 네트워크 장치(30)는 임의의 수의 송신/수신 요소(36)를 포함할 수 있다. 더 구체적으로, 네트워크 장치(30)는 MIMO 기술을 사용할 수 있다. 따라서, 실시예에서, 네트워크 장치(30)는 무선 신호들을 송신 및 수신하기 위한 2 이상의 송신/수신 요소(36)(예를 들어, 다중 안테나)를 포함할 수 있다.

송수신기(34)는 송신/수신 요소(36)에 의해 전송될 신호들을 변조하고 송신/수신 요소(36)에 의해 수신된 신호들을 복조하도록 구성될 수 있다. 위에서 언급된 바와 같이, 네트워크 장치(30)는 다중 모드 능력들을 제공한다. 따라서, 송수신기(34)는 네트워크 장치(30)가 예를 들어 UTRA 및 IEEE 802.11과 같은 복수의 RAT를 통해 통신할 수 있게 하는 복수의 송수신기를 포함할 수 있다.

프로세서(32)는 고정식 메모리(44) 및/또는 이동식 메모리(46)와 같은 임의의 유형의 적절한 메모리로부터 정보에 액세스하고 그러한 메모리에 데이터를 저장할 수 있다. 예를 들어, 프로세서(32)는 위에서 설명된 바와 같이 세션 컨텍스트를 그것의 메모리 내에 저장할 수 있다. 고정식 메모리(44)는 랜덤 액세스 메모리(RAM: random-access memory), 판독 전용 메모리(ROM: read-only memory), 하드 디스크, 또는 임의의 다른 유형의 메모리 저장 디바이스를 포함할 수 있다. 이동식 메모리(46)는 가입자 신원 모듈(SIM) 카드, 메모리 스틱, 보안 디지털(SD) 메모리 카드 등을 포함할 수 있다. 다른 실시예들에서, 프로세서(32)는 서버 또는 홈 컴퓨터와 같이 네트워크 장치(30) 상에 물리적으로 위치하지 않는 메모리로부터 정보에 액세스하고 그러한 메모리에 데이터를 저장할 수 있다. 프로세서(32)는 특히 네트워크 장치와 통신하는 기저 네트워크들, 애플리케이션들, 또는 다른 서비스들에서, 장치의 상태를 반영하거나 장치를 구성하기 위해 디스플레이 또는 표시자들(42) 상의 조명 패턴들, 이미지들, 또는 색상들을 제어하도록 구성될 수 있다. 일 실시예에서, 디스플레이/표시자들(42)은 도 24에 도시되고 본 명세서에 설명된 그래픽 사용자 인터페이스를 제시할 수 있다.

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

프로세서(32)는 또한 네트워크 장치(30)의 현재 위치에 관한 위치 정보(예를 들어, 경도 및 위도)를 제공하도록 구성된 GPS 칩셋(50)에 연결될 수 있다. 네트워크 장치(30)는 실시예와의 일관성을 유지하면서, 임의의 적절한 위치 결정 방법을 통해 위치 정보를 취득할 수 있다.

프로세서(32)는 추가 특징들, 기능성, 및/또는 유선 또는 무선 접속성을 제공하는 하나 이상의 소프트웨어 및/또는 하드웨어 모듈을 포함할 수 있는 다른 주변장치들(52)에 더 연결될 수 있다. 예를 들어, 주변장치들(52)은 가속도계, 생체 인식(예를 들어, 지문) 센서, 전자 나침반, 위성 송수신기, 센서, 디지털 카메라(사진 또는 비디오를 위한 것), 범용 직렬 버스(USB) 포트 또는 다른 상호접속 인터페이스들, 진동 디바이스, 텔레비젼 송수신기, 핸즈프리 헤드셋, 블루투스(Bluetooth®) 모듈, 주파수 변조(FM) 무선 유닛, 디지털 뮤직 플레이어, 미디어 플레이어, 비디오 게임 플레이어 모듈, 인터넷 브라우저 등과 같은 다양한 센서들을 포함할 수 있다.

네트워크 장치(30)는 센서, 소비자 전자 장치, 스마트 시계 또는 스마트 의류와 같은 웨어러블 디바이스, 의료 또는 e-헬스 디바이스, 로봇, 산업 장비, 드론, 자동차, 트럭, 기차 또는 비행기와 같은 운송수단과 같은 다른 장치들 또는 디바이스들 내에서 구현될 수 있다. 네트워크 장치(30)는 주변장치들(52) 중 하나를 포함할 수 있는 상호접속 인터페이스와 같은 하나 이상의 상호접속 인터페이스를 통해 그러한 장치들 또는 디바이스들의 다른 컴포넌트들, 모듈들, 또는 시스템들에 접속할 수 있다.

도 25d는 도 25a 및 도 25b에 도시된 것과 같은 M2M 네트워크 내에서 M2M 서버, 게이트웨이, 디바이스 또는 다른 네트워크 장치로서 동작할 수 있는, 도 1, 4-15, 및 19-23에 도시되고 본 명세서에 설명된 엔티티들과 같은 네트워크의 하나 이상의 네트워크 장치를 구현하기 위해 또한 이용될 수 있는 예시적인 컴퓨팅 시스템(90)의 블록도이다.

컴퓨팅 시스템(90)은 컴퓨터 또는 서버를 포함할 수 있고, 소프트웨어가 저장 또는 액세스되는 모든 장소에서, 또는 소프트웨어가 저장 또는 액세스되는 모든 수단에 의해, 그러한 소프트웨어 형태로 되어 있을 수 있는 컴퓨터 판독가능한 명령어들에 의해 주로 제어될 수 있다. 그러한 컴퓨터 판독가능한 명령어들은 컴퓨팅 시스템(90)이 작업을 수행하도록 하기 위해, 중앙 처리 장치(CPU)(91)와 같은 프로세서 내에서 실행될 수 있다. 다수의 공지된 워크스테이션, 서버, 및 개인용 컴퓨터에서, 중앙 처리 장치(91)는 마이크로프로세서라고 지칭되는 단일 칩 CPU에 의해 구현된다. 다른 머신들에서, 중앙 처리 유닛(91)은 다수의 프로세서를 포함할 수 있다. 코프로세서(81)는 추가의 기능들을 수행하거나 CPU(91)를 보조하는, 메인 CPU(91)와 구별되는 임의적 프로세서이다. CPU(91) 및/또는 코프로세서(81)는 세션 자격증명들을 수신하는 것, 또는 세션 자격증명들에 기초하여 인증하는 것과 같은 E2E M2M 서비스 계층 세션들에 대해 개시된 시스템들 및 방법들에 관련된 데이터를 수신하고 발생하고 처리할 수 있다.

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

시스템 버스(80)에 연결된 메모리들은 랜덤 액세스 메모리(RAM)(82) 및 판독 전용 메모리(ROM)(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)는 CPU(91)에 의해 실행되는 컴퓨터 실행가능한 명령어들과 함께, 도 25 및 그것의 첨부 설명에 도시되고 설명된 그래픽 사용자 인터페이스를 생성하고 동작할 수 있다.

또한, 컴퓨팅 시스템(90)은 컴퓨팅 시스템(90)이 네트워크의 다른 장치들과 통신할 수 있게 하기 위해 컴퓨팅 시스템(90)을 도 25a-25d의 네트워크(12)와 같은 외부 통신 네트워크에 접속하는 데 사용될 수 있는, 예를 들어 네트워크 어댑터(97)와 같은 통신 회로를 포함할 수 있다. 통신 회로는 단독으로, 또는 CPU(91)와 함께, 본 명세서(예를 들어, 도 9-14 및 19-23) 및 청구항에 설명된 전송 및 수신 단계들을 수행하기 위해 이용될 수 있다.

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

이러한 서술된 설명은 예들을 사용하여 최선의 모드를 포함하는 본 발명을 개시하고, 또한 본 기술분야의 통상의 기술자가 임의의 디바이스들 또는 시스템들을 제작 및 사용하고 임의의 통합된 방법들을 수행하는 것을 포함하여 본 발명을 실시할 수 있게 한다. 본 발명의 특허가능한 범위는 청구항들에 의해 정의되며, 본 기술분야의 통상의 기술자에게 떠오를 수 있는 다른 예들을 포함할 수 있다. 그러한 다른 예들은 그것들이 청구항들의 문자 언어와 다른 요소들을 갖는 경우 또는 청구항들의 문자 언어와 사소한 차이를 갖는 등가의 요소들을 포함하는 경우, 청구항들의 범위 내에 있는 것으로 의도된다.

Claims (20)

1. 프로세서, 메모리, 및 통신 회로를 포함하는 장치로서,
   상기 장치는 자신의 통신 회로를 통해 네트워크에 접속되고, 상기 장치는 상기 장치의 메모리 내에 저장된 컴퓨터 실행가능한 명령어들을 더 포함하며, 상기 컴퓨터 실행가능한 명령어들은 상기 장치의 상기 프로세서에 의해 실행될 때, 상기 장치로 하여금:
   서비스 계층에서, 새로운 리소스 또는 리소스 유형 중 적어도 하나를 정의하는 정보를 등록하라는 요청을 수신하는 단계;
   상기 정보를 상기 서비스 계층의 동작들에 통합하는 단계; 및
   상기 네트워크 상에서 통신하는 다른 네트워크 장치들에 의한 발견을 위해 상기 정보를 노출시키는 단계
   를 포함하는 동작들을 수행하게 하는, 장치.
2. 제1항에 있어서, 상기 정보는 리소스 정의 문서를 포함하는, 장치.
3. 제2항에 있어서, 상기 리소스 정의 문서는 리소스 정의에 관한 정보, 상속된 리소스 속성들(inherited resource attributes), 리소스 특정 속성들, 자식 리소스 속성들, 또는 활성화 기준들 중 적어도 하나를 포함하는, 장치.
4. 제1항에 있어서, 상기 서비스 계층에서 상기 정보를 관리하는 단계를 더 포함하는, 장치.
5. 제4항에 있어서, 상기 정보를 관리하는 단계는 상기 서비스 계층에서의 상기 정보의 리트리브(retrieval), 업데이트, 제거, 활성화, 및 비활성화 중 적어도 하나를 포함하는, 장치.
6. 제5항에 있어서, 상기 정보를 활성화하는 것은 요청자가 상기 정보의 활성화를 요청하도록 인가되는 것을 보장하기 위해 상기 서비스 계층에서 인가 검사(authorization check)를 트리거하는, 장치.
7. 제1항에 있어서, 상기 서비스 계층에서의 상기 정보의 평가에 기초하여 응답을 생성하는 단계를 더 포함하는, 장치.
8. 제1항에 있어서, 상기 서비스 계층에서 상기 정보를 수신하는 것은 상기 서비스 계층 내의 가상 또는 물리적 리소스에서 상기 정보를 수신하는 것을 포함하는, 장치.
9. 제1항에 있어서, 상기 서비스 계층에서 상기 정보를 수신하는 것은 상기 서비스 계층에서 제1 유니폼 리소스 표시자(Uniform Resource Indicator)(URI)를 수신하는 것을 포함하는, 장치.
10. 제9항에 있어서, 상기 제1 URI를 통해 상기 서비스 계층에서 상기 정보를 다운로드하는 단계를 더 포함하는, 장치.
11. 제1항에 있어서, 상기 정보에 기초하여 상기 서비스 계층에서 대응하는 스키마 문서들을 생성하는 단계를 더 포함하는, 장치.
12. 제11항에 있어서, 상기 스키마 문서들은 상기 서비스 계층 및 서비스 계층 관리자들에 의해서만 액세스될 수 있는 리포지토리 내에 저장되는, 장치.
13. 제1항에 있어서,
    데이터를 등록하라는 요청을 수신하는 단계 - 상기 데이터는 제3자 디바이스에 연관된 리소스와 상기 서비스 계층에 연관된 리소스 또는 리소스 유형의 일대일 맵핑을 제공하고, 상기 제3자 디바이스에 연관된 리소스는 상기 서비스 계층에 연관된 리소스들이 정의되는 프로토콜과는 상이한 프로토콜에 따라 정의됨 - ; 및
    상기 데이터를 상기 서비스 계층에 등록하는 단계
    를 더 포함하는, 장치.
14. 프로세서, 메모리, 및 통신 회로를 포함하는 장치로서,
    상기 장치는 자신의 통신 회로를 통해 네트워크에 접속되고, 상기 장치는 상기 장치의 메모리 내에 저장된 컴퓨터 실행가능한 명령어들을 더 포함하며, 상기 컴퓨터 실행가능한 명령어들은 상기 장치의 상기 프로세서에 의해 실행될 때, 상기 장치로 하여금:
    상기 네트워크의 서비스 계층에서, 상기 서비스 계층에 연관된 리소스를 리트리브하라는 요청을 수신하는 단계;
    상기 리소스에 액세스하기 위해 상호연동이 요구되는 것을 결정하는 단계; 및
    상기 서비스 계층에서, 요청된 서비스 계층 리소스를 제3자 디바이스에 연관된 리소스에 맵핑하는 데이터에 액세스하는 단계 - 상기 제3자 디바이스에 연관된 리소스는 상기 서비스 계층에 연관된 리소스들이 정의되는 프로토콜과는 상이한 프로토콜에 따라 정의됨 -
    를 포함하는 동작들을 수행하게 하는, 장치.
15. 제14항에 있어서, 상기 요청된 서비스 계층 리소스를 제3자 디바이스에 연관된 리소스에 맵핑하는 데이터는 복수의 상이한 표시자 중 하나를 포함하는, 장치.
16. 제15항에 있어서, 상기 복수의 표시자 각각은 상기 서비스 계층이 리소스를 리트리브하라는 요청을 리타겟팅할 수 있는 방식을 나타내는, 장치.
17. 제16항에 있어서, 상기 요청에 응답하는 캐싱된 데이터가 요청된 리소스에 대해 이용가능한지를 평가하고, 그렇지 않은 경우, 수신된 요청을 액세스된 데이터 내의 표시자에 따라 리타겟팅하는 단계를 더 포함하는, 장치.
18. 제17항에 있어서, 상기 복수의 표시자는:
    서비스 계층이 단 일회만 리소스를 리트리브하고 장래의 사용을 위해 그것을 저장해야 함을 나타내는 제1 표시자;
    상기 리소스를 리트리브하라는 요청이 수신될 때마다 서비스 계층이 리소스를 리트리브해야 함을 나타내는 제2 표시자;
    서비스 계층이 이벤트의 발생 시 리소스를 리트리브해야 함을 나타내는 제3 표시자; 및
    서비스 계층이 리소스를 주기적으로 리트리브해야 함을 나타내는 제4 표시자
    를 포함하는, 장치.
19. 제17항에 있어서, 요청된 리소스에 대한 데이터를 갖는 응답을 수신하고, 장래의 사용을 위해 상기 데이터를 저장하는 단계를 더 포함하는, 장치.
20. 제17항에 있어서, 상기 데이터는 데이터 모델 맵핑 문서를 포함하고, 상기 데이터 모델 맵핑 문서는 상기 서비스 계층에 등록되는, 장치.

Images