KR20200047720A

KR20200047720A - 통신 네트워크에서의 서비스 계층 메시지 템플릿들

Info

Publication number: KR20200047720A
Application number: KR1020207010888A
Authority: KR
Inventors: 총강 왕; 취앙 리; 쉬 루; 데일 엔. 시드; 마이클 에프. 스타시닉
Original assignee: 콘비다 와이어리스, 엘엘씨
Priority date: 2017-09-15
Filing date: 2018-09-14
Publication date: 2020-05-07
Anticipated expiration: 2038-09-14
Also published as: CN111095904B; EP4401433A3; CN111095904A; WO2019055760A1; US20230262141A1; EP3682619B1; JP7246379B2; CN116506502A; US20220286525A1; JP2020534605A; US20200204637A1; EP4401433A2; US12495099B2; KR102500594B1; US11671514B2; US11381656B2; EP3682619A1

Abstract

서비스 계층 메시지 템플릿의 개념이 도입되고, 이는 요청 템플릿 또는 응답 템플릿일 수 있다. 메시지 템플릿들이 생성되어 서비스 계층에 저장될 수 있다. 각각의 메시지 템플릿은 요청 또는 응답 파라미터들 및 그 값들의 세트를 포함할 수 있다. 일단 준비가 되면, 애플리케이션은 메시지 템플릿(즉, 요청 템플릿)에 포함되는 요청 파라미터들을 포함하지 않는 요청을 서비스 계층에 전송할 수 있고, 대신에, 메시지 템플릿 식별자가 전송될 수 있다. 요청 파라미터들이 메시지 템플릿에 포함되고 서비스 계층에 저장되므로, 서비스 계층과 애플리케이션(또는 다른 서비스 계층) 사이의 통신 오버헤드가 감소될 수 있다.

Description

통신 네트워크에서의 서비스 계층 메시지 템플릿들

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

본 출원은 2017년 9월 15일자로 출원된 미국 가특허 출원 제62/558,940호의 이익을 주장하며, 이 출원은 그 전체가 참조로 본 명세서에 포함된다.

예를 들어, oneM2M, ETSI(European Telecommunications Standards Institute), 및 OCF(Open Connectivity Foundation)와 같은 다수의 표준 기관들은 애플리케이션들, 심지어 상이한 산업 부문들로부터의 애플리케이션들 간의 데이터의 교환 및 공유를 위한 단일 수평 플랫폼을 정의하는 M2M/IoT 서비스 계층들을 개발하고 있다.

M2M/IoT 서비스 계층은 애플리케이션들 및 디바이스들에게 서비스 계층에 의해 지원되는 M2M/IoT 지향 능력들(M2M/IoT 서비스들)의 집합에 대한 액세스를 제공할 수 있다. 이러한 능력들은 API(Application Programming Interface)들을 통해 애플리케이션들에 이용가능하게 될 수 있다. 예를 들어, M2M/IoT 서비스 계층은 (애플리케이션들이 적절한 액세스 권한들을 갖는다면) 이들 애플리케이션들에 의해 발견, 검색, 및/또는 가입될 수 있는 대용량들의 M2M/IoT 데이터를 유지할 수 있다. 서비스 계층에 의해 제공될 수 있는 M2M/IoT 서비스들의 추가적인 예들은 보안, 과금, 디바이스 관리, 프로비저닝, 및 접속성 관리를 포함한다.

oneM2M 표준은 "공통 서비스 엔티티(CSE)"의 형태로 그 서비스 계층을 구현한다. oneM2M 서비스 계층의 목적은 상이한 "수직(vertical)" M2M 시스템들 및 애플리케이션들에 의해 이용될 수 있는 "수평" 서비스들을 제공하는 것이다. oneM2M CSE는 4개의 참조 포인트를 지원한다. Mca 참조 포인트는 애플리케이션 엔티티(AE)와 인터페이싱한다. Mcc 참조 포인트는 동일한 서비스 제공자 도메인 내에서 다른 CSE와 인터페이싱하고, Mcc' 참조 포인트는 상이한 서비스 제공자 도메인에서 다른 CSE와 인터페이싱한다. Mcn 참조 포인트는 기본 네트워크 서비스 엔티티(NSE)와 인터페이싱한다. NSE는 디바이스 관리, 위치 서비스들 및 디바이스 트리거링과 같은 기본 네트워크 서비스들을 CSE들에 제공한다. CSE는, "발견" 및 "데이터 관리 및 저장소"와 같은, "공통 서비스 기능들(CSF들)"이라고 불리는 복수의 논리 기능들을 포함할 수 있다.

oneM2M에서, 요청/응답 모델은 그 Mca, Mcc, 및 Mcc' 참조 포인트들에 대해 채택되었다. 예를 들어, AE는 그 리소스들 또는 서비스들에 액세스하기 위해 CSE에 요청 메시지를 전송할 수 있다. oneM2M은 다양한 파라미터들에 따라 요청 메시지를 처리하고 대응하는 응답 메시지를 생성하기 위한 몇몇 진보된 특징들을 제공한다. 또한, 각각의 응답 메시지는 다양한 응답 파라미터들을 포함할 수 있다. 이러한 파라미터들은 복수의 요청 및 응답 메시지들에서 반복될 수 있어서, 잠재적으로 큰 크기의 요청/응답 메시지들을 야기한다.

배경기술란에서 설명된 바와 같이, 서비스 계층 요청 메시지는 요청 파라미터들의 세트를 포함할 수 있고, 이는 요청 메시지들의 크기를 증가시키고 서비스 계층과 애플리케이션(또는 다른 서비스 계층) 사이의 통신 효율을 감소시킨다. 유사하게, 서비스 계층 응답 메시지는 응답 메시지를 차례로 확대하는 복수의 응답 파라미터들을 포함할 수 있다. 또한, 동일한 또는 상이한 애플리케이션들로부터의 요청 메시지들은 중복되는 동일한 값들을 갖는 동일한 요청 파라미터들을 포함할 수 있다. 또한, 서비스 계층으로부터 요청자로의 응답 메시지들은 또한 중복 응답 파라미터들을 포함할 수 있다. 특히, IoT 서비스 계층에서, 요청 메시지들은 너무 많은 요청 파라미터들로 인해 크게 될 수 있고, 기본 네트워크들이 3GPP 협대역 IoT 및 다른 저전력 광역 네트워킹 기술들과 같은 제한된 통신 용량을 가질 때, 높은 오버헤드를 불가피하게 도입하고 관리가 번거롭게 될 수 있다.

특히 저전력 광역 네트워크들과 같은 제한된 대역폭을 갖는 기본 네트워크들에 대해, 통신 오버헤드 및 다른 관련 메트릭들과 관련하여, 큰 요청 및 응답 메시지들에 의해 야기되는 서비스 계층과 애플리케이션들(또는 다른 서비스 계층) 사이의 통신 효율을 개선하는 방법들 및 장치들이 본 명세서에서 설명된다.

일 양태에 따르면, 요청 템플릿 또는 응답 템플릿을 포함할 수 있는 서비스 계층 메시지 템플릿이 이용될 수 있다. 메시지 템플릿들이 생성되어 서비스 계층에 저장될 수 있다. 각각의 메시지 템플릿은 요청 또는 응답 파라미터들 및 그 값들의 세트를 포함할 수 있다. 일단 준비가 되면, 애플리케이션은 메시지 템플릿(즉, 요청 템플릿)에 포함되는 요청 파라미터들을 포함하지 않는 요청을 서비스 계층에 전송할 수 있고, 대신에, 메시지 템플릿 식별자가 전송될 수 있다. 요청 파라미터들이 메시지 템플릿에 포함되고 서비스 계층에 저장되므로, 서비스 계층과 애플리케이션(또는 다른 서비스 계층) 사이의 통신 오버헤드가 감소될 수 있다.

이 요약은 상세한 설명에서 이하 추가로 설명되는 개념들의 선택을 간략화된 형태로 소개하기 위해 제공된다. 이 요약은 청구되는 주제의 핵심 특징들 또는 필수 특징들을 식별하고자 의도되는 것도 아니고, 청구되는 주제의 범위를 제한하는데 이용하고자 의도되는 것도 아니다. 또한, 청구되는 주제는 본 개시내용의 임의의 부분에서 언급되는 임의의 또는 모든 단점들을 해결하는 제한들에 제약되는 것도 아니다.

첨부 도면들과 관련하여 예로서 주어지는 이하의 설명으로부터 보다 상세한 이해를 가질 수 있을 것이다.
도 1은 oneM2M에 의해 명시된 네트워크 아키텍처를 도시하는 도면이다.
도 2는 사용자 장비(UE)로서 각각의 스마트 계측기가 서버와 통신하기 위해 3GPP 협대역 사물 인터넷(NB-IoT)과 같은 저전력 광역 액세스 기술들을 이용하는 스마트 계측 이용 사례를 도시한다.
도 3은 애플리케이션과 서비스 계층 사이의 상호작용들을 도시한다.
도 4는 복수의 애플리케이션들(예를 들어, 도 2에서 스마트 계측기들 상의 스마트 계측기 애플리케이션들)이 동일한 서비스 계층과 상호작용하는 예를 도시한다.
도 5는 그 크기를 감소시키는 관점에서 서비스 계층 요청 메시지들을 최적화하기 위해 요청 템플릿들을 활용하는 방법들의 일 실시예를 도시한다.
도 6은 그 크기를 감소시키는 관점에서 서비스 계층 응답 메시지들을 최적화하기 위해 응답 템플릿들을 활용하는 방법들의 일 실시예를 도시한다.
도 7은 메시지 템플릿 관리를 위한 전체적인 방법을 도시한다.
도 8은 독립 요청을 이용하여 요청자에 의해 개시되는 요청 템플릿 생성을 위한 방법을 도시한다.
도 9는 도 8의 방법과 관련한 예를 도시하는 도면이다.
도 10은 정규 요청을 전송할 때 요청자에 의해 개시되는 요청 템플릿 생성을 위한 방법을 도시한다.
도 11은 서비스 계층에 의해 개시되는 요청 템플릿들을 생성하기 위한 방법 및 생성된 요청 템플릿들의 식별자들이 별개의 통지 메시지를 이용하여 요청자에게 다시 전송되는 것을 도시한다.
도 12는 서비스 계층이 일부 유사한 요청 파라미터들을 이용하는 3개의 연속적인 정규 요청을 수신하는 예를 도시한다.
도 13은 서비스 계층에 의해 개시되는 요청 템플릿들을 생성하기 위한 방법 및 생성된 요청 템플릿들의 식별자들이 요청자에게 정규 응답으로 다시 피기백되는 것을 도시한다.
도 14는 서비스 계층에 의해 개시되는 사전적 요청 템플릿 생성을 위한 방법을 도시한다.
도 15는 응답 템플릿 생성을 위한 절차를 도시한다.
도 16은 3개의 잠재적인 사례들이 도시되는 메시지 템플릿 할당 및 발견을 위한 방법을 도시한다.
도 17은 서비스 계층 등록 절차들 동안에 메시지 템플릿을 생성/할당하기 위한 단순화되고 더 경량인 접근법을 도시한다.
도 18은 메시지 템플릿을 검색하기 위한 방법을 도시한다.
도 19는 요청 템플릿을 활용하기 위한 방법을 도시한다.
도 20은 요청 및 응답 템플릿들을 활용하기 위한 방법을 도시한다.
도 21은 전용 메시지를 이용하여 메시지 템플릿을 업데이트하기 위한 방법을 도시한다.
도 22는 요청자가 요청 메시지를 서비스 계층에 전송할 때 동시에 메시지 템플릿을 업데이트하기 위한 방법을 도시한다.
도 23은 전용 메시지들을 이용하여 메시지 템플릿을 삭제하기 위한 방법을 도시한다.
도 24는 요청자가 요청 메시지를 서비스 계층에 전송할 때 동시에 메시지 템플릿을 삭제하기 위한 방법을 도시한다.
도 25는 하나의 요청 메시지에서 복수의 요청 템플릿을 활용하기 위한 방법을 도시한다.
도 26은 트랜지트 서비스 계층이 템플릿 관련 기능을 지원하지 않을 때 멀티-홉 서비스 계층 통신들을 위해 요청 템플릿들을 이용하기 위한 방법을 도시한다.
도 27은 목적지 서비스 계층이 템플릿 관련 기능을 지원하지 않을 때 멀티-홉 서비스 계층 통신들에서 요청 템플릿들을 이용하기 위한 방법을 도시한다.
도 28은 트랜지트 서비스 계층 및 목적지 서비스 계층 양쪽 모두가 템플릿 관련 기능을 지원할 때 멀티-홉 서비스 계층 통신들에서 요청 템플릿들을 이용하기 위한 방법을 도시한다.
도 29는 요청자가 템플릿 관련 기능을 지원하지 않을 때 멀티-홉 서비스 계층 통신들에서 요청 템플릿들을 이용하기 위한 방법을 도시한다.
도 30은 메시지 템플릿 정책을 생성하기 위한 방법을 도시한다.
도 31은 메시지 템플릿을 메시지 템플릿 정책들과 연관시키거나 그 반대의 경우의 방법을 도시한다.
도 32는 기존의 메시지 템플릿 정책을 검색/업데이트/삭제하는 방법을 도시한다.
도 33은 messageTemplate 리소스에 대한 구조의 일 예를 도시한다.
도 34는 <messageTemplate> 리소스를 동작시키는 방법(예를 들어, <messageTemplate> 리소스의 생성/검색/업데이트/삭제)을 도시한다.
도 35는 messageTemplatePolicy 리소스의 구조를 도시한다.
도 36은 <messageTemplatePolicy> 리소스를 동작시키는 방법(예를 들어, <messageTemplatePolicy> 리소스의 생성/검색/업데이트/삭제)을 도시한다.
도 37은 서비스 계층(예를 들어, oneM2M CSE)에서의 메시지 템플릿 관리를 위한 사용자 인터페이스의 일 실시예를 도시한다.
도 38은 서비스 계층(예를 들어, oneM2M CSE)에서의 메시지 템플릿 정책 관리를 위한 사용자 인터페이스를 도시한다.
도 39a는 하나 이상의 개시되는 실시예가 구현될 수 있는 예시적인 기기간(M2M), 사물 인터넷(IoT) 또는 사물 웹(WoT) 통신 시스템의 시스템도이다.
도 39b는 도 39a에 도시된 M2M/IoT/WoT 통신 시스템 내에서 이용될 수 있는 예시적인 아키텍처의 시스템도이다.
도 39c는 도 39a 및 도 39b에 도시된 통신 시스템 내에서 이용될 수 있는 M2M/IoT/WoT 디바이스, 게이트웨이, 또는 서버와 같은 예시적인 통신 네트워크 장치의 시스템도이다.
도 39d는 도 39a 및 도 39b의 통신 시스템의 노드 또는 장치가 구현될 수 있는 예시적인 컴퓨팅 시스템의 블록도이다.

oneM2M 표준은 "공통 서비스 엔티티(CSE)"의 형태로 서비스 계층을 구현한다. oneM2M 서비스 계층의 목적은 상이한 "수직" M2M 시스템들 및 애플리케이션들에 의해 이용될 수 있는 "수평" 서비스들을 제공하는 것이다. CSE는 도 1에 도시된 바와 같은 4개의 참조 포인트를 지원한다. Mca 참조 포인트는 애플리케이션 엔티티(AE)와 인터페이싱한다. Mcc 참조 포인트는 동일한 서비스 제공자 도메인 내에서 다른 CSE와 인터페이싱하고, Mcc' 참조 포인트는 상이한 서비스 제공자 도메인에서 다른 CSE와 인터페이싱한다. Mcn 참조 포인트는 기본 네트워크 서비스 엔티티(NSE)와 인터페이싱한다. NSE는 디바이스 관리, 위치 서비스들 및 디바이스 트리거링과 같은 기본 네트워크 서비스들을 CSE들에 제공한다. CSE는, "발견" 및 "데이터 관리 및 저장소"와 같은, "공통 서비스 기능들(CSF들)"이라고 불리는 복수의 논리 기능들을 포함한다.

oneM2M 아키텍처는 도 1에 도시된 바와 같이, 다음과 같은 유형들의 노드들을 가능하게 한다: 애플리케이션 서비스 노드, 애플리케이션 전용 노드, 중간 노드, 인프라스트럭처 노드, 및 비-oneM2M 노드.

애플리케이션 서비스 노드(ASN)는 하나의 CSE를 포함하고 적어도 하나의 애플리케이션 엔티티(AE)를 포함하는 노드이다. 물리적 매핑의 예로서, ASN은 센서 등과 같은 M2M 디바이스에 존재할 수 있다.

애플리케이션 전용 노드(ADN)는 적어도 하나의 AE를 포함하고 CSE를 포함하지 않는 노드이다. oneM2M 시스템의 필드 도메인에는 0개 이상의 ADN이 있을 수 있다. 물리적 매핑의 예로서, ADN은 제약된 M2M 디바이스에 존재할 수 있다.

중간 노드(MN)는 하나의 CSE를 포함하고 0개 이상의 AE를 포함하는 노드이다. oneM2M 시스템의 필드 도메인에는 0개 이상의 MN이 있을 수 있다. 물리적 매핑의 예로서, MN은 M2M 게이트웨이에 존재할 수 있다.

인프라스트럭처 노드(IN)는 하나의 CSE를 포함하고 0개 이상의 AE를 포함하는 노드이다. 인프라스트럭처 도메인에 oneM2M 서비스 제공자당 정확히 하나의 IN이 있다. IN의 CSE는 다른 노드 유형들에 적용가능하지 않은 CSE 기능들을 포함할 수 있다. 물리적 매핑의 예로서, IN은 M2M 서비스 인프라스트럭처에 존재할 수 있다.

비-oneM2M 노드(NoDN)는 oneM2M 엔티티들(AE들이나 CSE들이 아님)을 포함하지 않는 노드이다. 이러한 노드들은, 관리를 포함한, 연동 목적들을 위해 oneM2M 시스템에 부속된 디바이스들을 나타낸다.

oneM2M에서, 요청/응답 모델은 그 Mca, Mcc, 및 Mcc' 참조 포인트들에 대해 채택되었다. 예를 들어, AE는 그 리소스들 또는 서비스들에 액세스하기 위해 CSE에 요청 메시지를 전송할 수 있다. oneM2M은 표 1에 기술된 바와 같은 일부 새로운 파라미터들을 통해 요청 메시지를 처리하고 대응하는 응답 메시지를 생성하기 위한 몇몇 진보된 특징들을 제공한다. 또한, 각각의 응답 메시지는 표 2에 열거된 바와 같은 일부 응답 파라미터들을 포함한다. 이러한 파라미터들은 복수의 요청 및 응답 메시지들에서 반복될 수 있고 큰 크기의 oneM2M 요청 또는 응답 메시지를 초래할 수 있다는 점에 유의한다.

<표 1>

<표 2>

본 명세서에 설명된 기술적 해결책이 다루는 기술적 문제를 더 잘 이해하기 위해, 예시를 위해 이용 사례가 제시된다. 도 2는 사용자 장비(UE)로서 각각의 스마트 계측기가 서버와 통신하기 위해 3GPP 협대역 사물 인터넷(NB-IoT)과 같은 저전력 광역 액세스 기술들을 이용하는 스마트 계측 이용 사례를 도시하며, 여기서 IoT 서비스 계층은 다양한 UE들로부터의 계측기 데이터를 저장 및 관리하기 위해 존재하고, 서버는 전기 회사에 의해 배치될 수 있다. 예를 들어, 계측기 판독들을 서버에 주기적으로 전송하기 위해 각각의 UE 상에서 실행되는 스마트 계측기 애플리케이션이 존재할 수 있다. 또한, 복수의 스마트 계측기들(예를 들어, 동일한 커뮤니티에 배치됨)은 동일한 방식(예를 들어, 보고 빈도, 요청 메시지들이 서버에 의해 처리되는 방법 등)으로 서버에 그 판독들을 보고할 수 있다. 이와 같이, 각각의 스마트 계측기는 유사한 요청 메시지들을 서버에 반복적으로 전송할 수 있고, 복수의 계측기들은 또한 상이한 시간들에서 서버에게 유사한 요청 메시지들을 전송할 수 있다. 이들 2개의 양태는 도 3 및 도 4와 관련하여 요약되고 더 논의된다.

도 3은 애플리케이션과 서비스 계층 사이의 상호작용들을 도시한다. 이 예에서, 애플리케이션(예를 들어, 도 2에서 스마트 계측기 상의 스마트 계측기 애플리케이션)은 서비스 계층에 요청 메시지들을 반복적으로 전송한다. 각각의 요청 메시지는 요청 파라미터들의 세트를 포함하고; 마찬가지로, 대응하는 응답 메시지는 응답 파라미터들을 포함한다. 또한, 애플리케이션은 특정 지속시간들 동안 서비스 계층으로부터 동일한 서비스들/리소스들을 요청할 수 있고; 따라서, 각각의 반복된 요청 메시지는 동일한 요청 파라미터들의 세트를 포함한다.

도 4는 복수의 애플리케이션들(예를 들어, 도 2의 스마트 계측기들 상의 스마트 계측기 애플리케이션들)이 동일한 서비스 계층과 상호작용하는 다른 예를 도시한다. 이 시나리오에서, 3개(또는 그 이상)의 애플리케이션이 상이한 서비스/리소스들에 액세스할 수 있지만, 이들은 서비스 계층에게 그 요청 메시지들을 동일한 방식으로 처리하도록 지시할 수 있다. 예를 들어, 이들은 동일한 요청 메시지 만료 시간, 동일한 결과 만료 시간 등을 서비스 계층에 표시할 수 있다. 따라서, 각각의 애플리케이션으로부터의 요청 메시지는 동일한 요청 파라미터들의 세트를 포함할 수 있다.

전술한 이용 사례에 의해 예시된 문제에 대한 기술적 해결책으로 진행하기 전에, 특정 용어들이 단지 설명의 용이함을 위해 본 명세서에서 정의된다. 다음의 용어들은 다음의 의미들을 가질 수 있다:

서비스 계층은 애플리케이션들과 애플리케이션 프로토콜 계층들 사이의 프로토콜 계층으로서 설명될 수 있다. 서비스 계층은 리소스들을 저장하고, 애플리케이션들 및 다른 서비스 계층들에 노출되고 이들에 의해 액세스되고 조작될 수 있는 서비스들을 제공한다.

요청/응답 모델은 서비스 계층과 애플리케이션 사이의(또는 2개의 서비스 계층 사이의) 상호작용 모델일 수 있다. 이 모델에서, 애플리케이션(또는 다른 서비스 계층)은 요청 메시지를 서비스 계층에 전송하고, 서비스 계층은 차례로 응답 메시지를 다시 애플리케이션(또는 다른 서비스 계층)에 전송한다.

요청 메시지는 서비스 계층에 의해 제공되는 서비스들을 요청하기 위해 애플리케이션(또는 다른 서비스 계층)으로부터 서비스 계층으로 전송되는 메시지일 수 있다. 서비스 계층은 수신된 요청 메시지를 처리하고, 응답 메시지를 요청 메시지의 발신자에게 전송할 것이다. 요청 메시지는 서비스 계층으로부터 다른 애플리케이션으로 또한 발행될 수 있다.

요청 파라미터들은, 요청 메시지를 언제/어떻게 처리할지, 생성된 결과를 어떻게 유지할지, 응답 메시지를 언제/어떻게 다시 전송할지 등을 서비스 계층에게 지시하는, 요청 메시지에 포함된 파라미터들일 수 있다.

응답 메시지는 요청 메시지를 수신 및 처리한 결과로서 서비스 계층으로부터 애플리케이션(또는 다른 서비스 계층)으로 전송된 메시지일 수 있다. 응답 메시지는 또한 애플리케이션으로부터 서비스 계층으로 발행될 수 있다.

응답 파라미터들은 응답 메시지에 포함된 파라미터들일 수 있다. 예를 들어, 요청자가 서비스 계층으로부터 리소스를 검색하라고 요청할 때, 서비스 계층에 의해 생성된 응답 메시지는 검색된 리소스의 표현을 포함하기 위해 "콘텐츠" 파라미터를 포함할 수 있다.

메시지 템플릿(MT)은 요청 메시지들을 설명하기 위한 요청 템플릿 또는 응답 메시지들을 설명하기 위한 응답 템플릿일 수 있다. 요청 템플릿들은 서비스 계층에서 그리고/또는 요청자 측에서 메모리에 저장되고 애플리케이션들에 의해 발견 및 검색될 수 있고; 응답 템플릿들은 서비스 계층 및/또는 요청자 측에 또한 저장될 수 있다. 메시지 템플릿들은 서비스 계층, 애플리케이션들, 및/또는 다른 서비스 계층들에 의해 관리될 수 있다. MT는 테이블, XML(extensible mark-up language) 문서 또는 임의의 다른 적절한 머신 판독가능한 데이터 구조 또는 문서와 같은 템플릿의 파라미터 값들을 보유하는 임의의 적절한 데이터 구조의 형태를 취할 수 있다.

요청 템플릿(REQT)은 요청들에서 반복적으로 이용되는 주어진 메시지에 대한 일부 공통 요청 파라미터들 및 그 값들을 포함한다. 애플리케이션 또는 다른 서비스 계층은 요청 파라미터들의 공통 이용된 서브세트가 템플릿에 포함되면 생략될 수 있는 최적화된 요청을 생성하기 위해 요청 메시지 템플릿을 활용할 수 있다.

응답 템플릿(RSPT)은 응답 메시지가 어떻게 생성되어야 하는지 그리고 응답 메시지가 어떻게 보이는지를 기술한다. 응답 템플릿은 요청 템플릿 또는 요청과 연관될 수 있고, 이와 같이, 서비스 계층은 요청 템플릿을 이용하여 수신된 최적화된 요청을 처리할 때, 어떤 응답 템플릿이 응답 메시지를 생성하는데 이용되어야 하는지를 알게 된다. 또한, 서비스 계층은 서비스 계층으로부터 요청자로 반복적으로 전송될 응답 파라미터들을 포함하기 위해 요청자 측에서 응답 템플릿을 생성할 수 있고; 서비스 계층은 이러한 종류의 응답 템플릿을 이용하여 이들 반복된 응답 파라미터들을 생략함으로써 최적화된 응답을 생성할 수 있고; 요청자는 이러한 종류의 응답 템플릿을 국부적으로 저장하고, 이를 수신된 최적화된 응답으로부터의 원래 응답 메시지를 복원하는데 이용할 수 있다. 응답 템플릿은 요청 템플릿을 포함하거나, 요청 템플릿을 포함하지 않는 요청에 응답하는데 이용될 수 있다는 점에 유의한다.

메시지 템플릿 식별자(MTID)는 요청 템플릿 또는 응답 템플릿일 수 있는, 서비스 계층에 저장된 메시지 템플릿의 범용 리소스 식별자 또는 수치 식별자일 수 있다.

요청 템플릿 식별자(RQTID)는 서비스 계층에 저장된 요청 템플릿의 범용 리소스 식별자 또는 수치 식별자일 수 있다.

응답 템플릿 식별자(RSTID)는 서비스 계층에 저장된 응답 템플릿의 범용 리소스 식별자 또는 수치 식별자일 수 있다.

메시지 템플릿 관리는 메시지 템플릿을 생성하는 것, 메시지 템플릿을 검색하는 것, 메시지 템플릿을 활용하는 것, 메시지 템플릿을 업데이트하는 것, 메시지 템플릿을 삭제하는 것, 메시지 템플릿을 하나 이상의 메시지 템플릿 정책과 연관시키는 것 등을 위한 작업들을 포함할 수 있다.

메시지 템플릿 정책은 메시지 템플릿들의 적용가능성을 기술하거나 제한하기 위한 조건들(예를 들어, 어느 타겟 리소스에 대해 어느 요청자에게 어느 메시지 템플릿을 적용할지 여부/이를 언제 적용할지)을 포함할 수 있다.

정규 요청은 서비스 계층 또는 애플리케이션 계층에서 본래 정의되고 지원되는 요청 메시지일 수 있다. 정규 요청은 서비스 계층에 의해 명시된 요청 파라미터들의 세트를 포함하는데 이용된다. 정규 요청은 임의의 요청 템플릿을 활용하지 않는다.

최적화된 요청은 요청 템플릿을 활용함으로써 향상된 요청 메시지일 수 있다. 일반적으로, 요청 템플릿 식별자를 포함하고 요청 템플릿에 포함되는 이러한 요청 파라미터들을 제거함으로써 요청자 측에서 최적화된 요청이 작성된다. 따라서, 최적화된 요청은 정규 요청보다 짧다.

정규 응답은 서비스 계층 또는 애플리케이션 계층에서 본래 정의되고 지원되는 응답 메시지일 수 있다. 정규 응답은 서비스 계층에 의해 명시된 응답 파라미터들의 세트를 포함하는데 이용된다. 정규 응답은 요청자 측에 저장된 임의의 응답 템플릿을 활용하지 않는다.

최적화된 응답은 응답 템플릿을 활용함으로써 향상된 응답 메시지일 수 있다. 일반적으로, 응답 템플릿 식별자를 포함하고 응답 템플릿에 포함되는 이러한 응답 파라미터들을 제거함으로써 서비스 계층 측에서 최적화된 응답이 작성된다. 따라서, 최적화된 응답은 정규 응답보다 짧다.

본 설명의 나머지에서, 메시지 템플릿은 명시적으로 언급되지 않는 한 요청 템플릿 또는 응답 템플릿 중 어느 하나를 지칭할 수 있다. 마찬가지로, 메시지 템플릿 식별자(MTID)는 명시적으로 언급되지 않는 한, 요청 템플릿 식별자(RQTID) 또는 응답 템플릿 식별자(RSTID)를 지칭할 수 있다.

이하의 설명에서, 메시지 템플릿들을 활용하기 위한 메커니즘들이 설명된다. 이어서, 메시지 템플릿 관리를 위한 전체 절차가 설명될 것이고, 메시지 템플릿 생성, 메시지 템플릿 할당 및 발견, 메시지 템플릿 검색, 메시지 템플릿 이용, 메시지 템플릿 업데이트, 메시지 템플릿 삭제와 같이, 수행될 수 있는 각각의 메시지 템플릿 관리 작업의 실시예들의 설명이 이어진다.

단지 설명의 용이함을 위해, 이하의 설명에서, 요청 메시지들은 애플리케이션(또는 다른 서비스 계층)으로부터 서비스 계층으로 발행되는 것으로 설명된다. 그러나, 본 명세서에 설명된 개념들, 메커니즘들, 및 실시예들은 서비스 계층이 요청 메시지들을 애플리케이션에 전송하고 이에 따라 응답 메시지들이 애플리케이션으로부터 서비스 계층으로 전송되는 시나리오에 직접 적용될 수 있다.

도 5는 그 크기를 감소시키는 관점에서 서비스 계층 요청 메시지들을 최적화하기 위해 요청 템플릿들을 활용하는 방법들의 일 실시예를 도시한다. 도 5에서의 요청자는 애플리케이션 또는 다른 서비스 계층일 수 있고; 게다가, 각각의 단계는 다음의 설명에서 상세히 설명될 수 있는 몇몇 하위단계들을 포함할 수 있다는 점에 유의한다. 요청 템플릿에 포함된 요청 파라미터들은 임의의 특정 순서로 있지 않을 수 있다는 점에 유의한다.

도 5를 참조하면, 단계 1에서, 요청자는 요청 템플릿(REQT)을 생성하라고 요청한다. 대안적으로, 서비스 계층은 일부 REQT들을 사전에 생성할 수 있다. 요청은 그 요청에서 보통 나타날 정보 요소들에 대해 이용될 디폴트 값들을 포함할 수 있다. REQT는 이들 디폴트 값들에 기반하여 구축될 수 있다. REQT가 이후에 요청자에 의해 이용될 때, 디폴트 값들은 REQT가 이용될 것임을 나타내는 요청에 상이한 값들이 제공되지 않으면 서비스 계층에 의해 가정될 수 있다.

단계 2에서, 서비스 계층은 REQT, REQT 식별자를 생성하고, 이들을 서비스 계층이 구현되는 네트워크 장치의 메모리에 국부적으로 저장한다.

단계 3에서, 생성된 REQT를 활용할 수 있는 REQT의 생성자가 아닌 요청자의 경우, 요청자는 서비스 계층에 전송될 미래의 요청 메시지들을 최적화하기 위해 그 콘텐츠(예를 들어, 어느 요청 파라미터들이 REQT에 포함되었는지)를 알 필요가 있다. 이와 같이, 요청자는 REQT 및 그 연관 식별자를 발견 및 검색할 필요가 있다. 대안적으로, 도면에 도시되지 않았지만, 서비스 계층은 요청자에게 하나 이상의 REQT를 능동적으로 할당할 수 있다.

단계 4에서, REQT를 검색하거나 REQT를 할당 또는 통지받은 후에, 요청자는 이를 이용하여 최적화된 요청을 생성하고, 이는 REQT의 식별자를 포함하고, REQT에 이미 포함된 이러한 파라미터들을 배제할 것이다. REQT에 포함되지 않은 임의의 요청 파라미터들에 대해, 요청자는 여전히 이들을 최적화된 요청에 포함시킬 필요가 있다. 최적화된 요청이 정규 요청보다 더 적은 파라미터들을 포함하기 때문에, 그 크기가 감소되고, 서비스 계층과의 통신 오버헤드도 감소될 것이다.

단계 5에서, 요청자는 최적화된 요청을 서비스 계층에 전송한다. 최적화된 요청은 단계 4에서 최적화된 요청을 생성하는데 이용된 REQT의 식별자를 포함한다는 점에 유의한다. 요청은 또한 REQT의 일부인 정보 요소들에 대한 값들을 제공할 수 있다. 값들의 존재는 REQT 상의 디폴트 값들이 제공된 값들로 무시되어야 하는 것을 표시하기 위해 요청자에 의해 이용될 수 있다.

단계 6에서, 서비스 계층은 최적화된 요청을 수신하고, REQT에 따라 이를 처리한다. 구체적으로, 서비스 계층은 먼저 적절한 REQT를 찾아내기 위해 최적화된 요청에 포함된 REQT 식별자를 이용하고; 이후, 정규 요청을 처리하기 위해 이용하는 것으로 가정되는 방식으로 수신된 최적화된 요청을 처리하기 위해 최적화된 요청 내의 다른 파라미터들/정보와 함께 REQT에 포함된 요청 파라미터들 및 다른 정보를 이용한다. 그 후, 서비스 계층은 정규 응답을 생성하고, 서비스 계층이 응답 템플릿들을 지원하지 않으면 이를 요청자에게 다시 전송하고; 응답 템플릿이 지원되면, 서비스 계층은 응답 템플릿을 활용하여 최적화된 응답들을 생성할 수 있다(도 5 참조).

도 5에 도시된 전체 절차가 (메시지 템플릿 없는 단일 요청/응답에 비해) 서비스 계층과 요청자 사이의 요청 템플릿들을 생성/발견/검색하기 위한 더 많은 메시징을 초래하지만, 요청자가 동일한 유형의 요청을 서비스 계층에 반복적으로 전송할 것이고/것이거나 메시지 템플릿이 복수의 요청자들에 의해 이용될 것인 경우에는 상당한 절감이 달성될 수 있다는 것에 유의한다. 이것은 모든 후속 요청들(또는 복수의 요청자들로부터의 요청들)이 REQT를 이용할 수 있기 때문이다.

도 6은 그 크기를 감소시키는 관점에서 서비스 계층 응답 메시지들을 최적화하기 위해 응답 템플릿들을 활용하는 방법들의 일 실시예를 도시한다. 도 6의 요청자는 애플리케이션 또는 다른 서비스 계층일 수 있고; 또한, 도 6의 각각의 단계는 몇몇 하위단계들을 포함할 수 있다는 점에 유의한다. 응답 템플릿에 포함된 응답 파라미터들은 임의의 특정 순서로 있지 않을 수 있다는 점에 유의한다.

도 6을 참조하면, 단계 1에서, 요청자는 응답 템플릿(RSPT)을 생성하라고 요청한다. 대안적으로, 서비스 계층은 또한 일부 RSPT들을 생성하도록 개시할 수 있다. 요청자로부터의 요청은 RSPT를 구축하는데 이용되어야 하는 응답 파라미터들, RSPT 식별자, 또는 완전한 응답을 제공할 수 있다. 예를 들어, 요청자는 RSPT를 구축할 때 어떤 응답 파라미터들이 가정되어야 하는지를 나타낼 수 있다.

단계 2에서, 서비스 계층은 RSPT, RSPT 식별자를 생성하고, 이들을 서비스 계층이 구현되는 네트워크 장치의 메모리에 국부적으로 저장한다.

단계 3에서, 서비스 계층은 요청자에게 동일한 RSPT 및 식별자를 전송하여 요청자가 장래에 수신될 임의의 최적화된 응답을 정확하게 처리하기 위해 이를 이용할 수 있도록 한다.

단계 4에서, 요청자는 국부적으로 RSPT를 저장한다.

단계 5에서, 서비스 계층은, 수신된 요청을 처리할 때, 요청자에 의해 알려진 RSPT에 따라 최적화된 응답을 생성한다. 최적화된 응답은 이용된 RSPT의 식별자를 포함할 수 있다. 정규 응답과 비교하여, 최적화된 응답은 RSPT에 이미 포함된 이들 파라미터들/정보를 배제하고, 메시지 크기는 감소될 것이다. 요청자에 의해 발행되는 수신된 요청은 서비스 계층에게 요청을 전송할 때 특정 RSPT를 생성 및/또는 이용하도록 서비스 계층에게 명시적으로 요청할 수 있고; RSPT를 이용하라는 요청은 요청 메시지에서 RSPT 식별자 또는 "USE RSPT" 플래그를 포함함으로써 표시될 수 있다는 점에 유의한다.

단계 6에서, 서비스 계층은 최적화된 응답을 요청자에게 전송한다. 최적화된 응답은 RSPT 식별자를 포함한다. 최적화된 응답은 RSPT에 포함된 이들 응답 파라미터들을 생략하지만, RSPT 식별자를 포함한다. RSPT에서 정의된 값들을 무시하기 위해, 응답은 RSPT에서 디폴트 값들을 할당받았던 파라미터들 중 일부에 대한 값들을 포함할 수 있다.

단계 7에서, 요청자는 최적화된 응답을 수신하고, RSPT 식별자를 이용하여 대응하는 RSPT를 찾아내고, 응답 파라미터들 및 RSPT에 포함된 정보를 이용하여 최적화된 응답을 처리한다.

이제, 메시지 템플릿 관리 방법들이 설명될 것이다. 일 양태에 따르면, 요청자(즉, 애플리케이션 또는 다른 서비스 계층)는 서비스 계층에서 메시지 템플릿의 생성을 개시할 수 있다. 메시지 템플릿이 생성되면, 그것은 동일한 또는 다른 요청자들에 할당되거나 이들에 의해 발견될 수 있다. 요청자는 적절한 메시지 템플릿을 발견하거나 할당받은 후에, 일부 요청(또는 응답) 파라미터들이 생략되고 메시지 템플릿 식별자로 대체될 최적화된 요청들(또는 응답들)을 생성하기 위해 이를 이용할 수 있다. 그 후, 메시지 템플릿은 RESTful 방식으로 조작될 수 있다(즉, 메시지 템플릿을 검색하고, 메시지 템플릿을 업데이트하고, 메시지 템플릿을 삭제할 수 있다).

도 7은 도 5 및 도 6과 관련하여 설명된 것에 기반하고 그와 일치하는 메시지 템플릿 관리를 위한 전체 방법을 도시한다. 도 7에 도시된 개념 중 하나는 요청자 또는 서비스 계층에 의해 생성된 메시지 템플릿이 다른 요청자들에게 할당되고, 이들에 의해 발견, 및/또는 이용될 수 있다는 것이다.

도 7을 참조하면, 단계 1에서, 메시지 템플릿이 생성되어 서비스 계층에 저장되고; 이것은 요청자1에 의해 또는 서비스 계층 자체에 의해 개시될 수 있다. 메시지 템플릿은 도 5 및 도 6에서 설명된 바와 같이 생성될 수 있다.

단계 2에서, 생성된 메시지 템플릿은 요청자2(또는 요청자1 또한)에 할당되고/되거나 이에 의해 발견된다. 서비스 계층은 요청자1에 의해 생성된 메시지 템플릿을 요청자2에게 할당할 수 있다는 점에 유의한다(그리고, 도면에 도시되어 있지 않지만, 그 반대도 마찬가지이다). 메시지 템플릿을 발견하거나 메시지 템플릿을 할당받은 후에, 요청자2(또는 요청자1)는 메시지 템플릿이 업데이트될 때(단계 5에서) 또는 삭제될 때(단계 6에서) 자동 통지를 수신하기 위해 메시지 템플릿에 가입할 수 있다는 것에 유의한다. 여기서, 요청자에 대해 메시지 템플릿이 할당되는 것은, 1) 메시지 템플릿 및 그 식별자가 요청자에게 주어진다는 것; 2) 요청자가 요청 템플릿이면 최적화된 요청들을 생성하기 위해 할당된 메시지 템플릿을 이용하거나, 응답 템플릿이면 최적화된 응답들로부터 정규 응답들을 생성하도록 허가되고/되거나 제약된다는 것을 의미한다.

단계 3에서, 요청자2(또는 요청자1)는 서비스 계층으로부터 메시지 템플릿을 검색한다.

단계 4에서, 요청자2(또는 요청자1)는 메시지 템플릿(즉, 요청 템플릿)을 이용하여 최적화된 요청들을 생성하고 서비스 계층과 상호작용한다. 복수의 템플릿들은 최적화된 요청을 생성하기 위해 공동으로 활용될 수 있다는 점에 유의한다. 서비스 계층은 최적화된 요청을 수신할 때, 대응하는 템플릿을 찾고 이를 이용하여 최적화된 요청을 처리한다. 이 프로세스에서, 요청자2(또는 요청자1)는 서비스 계층에 요청 메시지를 전송할 때, 응답 템플릿을 생성하고/하거나 응답 템플릿을 이용하여 요청자2(또는 요청자1)에 대한 최적화된 응답을 생성하도록 서비스 계층에 표시하고 지시할 수 있다.

단계 5에서, 메시지 템플릿은 요청자2(또는 요청자1) 또는 서비스 계층 자체에 의해 업데이트될 수 있다. 예를 들어, 메시지 템플릿에 포함된 파라미터들 또는 정보가 업데이트될 수 있다. 업데이트된 메시지 템플릿이 복수의 요청자들에 의해 이용 및/또는 가입되었다면, 서비스 계층은 이러한 요청자들에게 통지를 전송하고 이들에게 업데이트들을 통지할 것이다.

단계 6에서, 메시지 템플릿은 요청자2(또는 요청자1) 또는 서비스 계층 자체에 의해 삭제될 수 있다. 삭제된 메시지 템플릿이 복수의 요청자에 의해 이용되거나 가입되었다면, 서비스 계층은 이들 요청자들에게 통지를 전송하고 이들에게 메시지 템플릿의 제거를 통지할 것이다.

일 양태에서, 요청자는 요청 메시지를 서비스 계층으로 전송함으로써 요청 템플릿의 생성을 능동적으로 개시할 수 있다. 이 단계 전에, 요청자는 서비스 계층이, 예를 들어, 서비스 발견을 통해, 메시지 템플릿 기능들을 지원한다는 것을 발견할 수 있고; 이를 가능하게 하기 위해, 서비스 계층은 그 메시지 템플릿 기능들이 요청자에 의해 발견될 수 있도록 이들을 노출/고지할 필요가 있다. 요청자가 요청 템플릿 생성 요청을 서비스 계층에 전송하는 두 가지 사례가 있다. 사례 1에서, 요청자는 전용 요청 템플릿 생성 요청을 서비스 계층에 전송하고; 이 요청은 필요에 따라 그 값들을 포함하는 일부 요청 파라미터들을 포함할 것이다. 사례 2에서, 요청자는 정규 요청에 요청 템플릿 생성 표시자(RQTCI)를 피기백하고; RQTCI는 서비스 계층에게 요청 템플릿을 어떻게 생성하는지(예를 들어, 어느 요청 파라미터들 및 그 값들이 생성될 메시지 템플릿에 포함될 것인지)를 통지한다. 서비스 계층은 RQTCI가 명시하는 것에 따라 요청 템플릿을 생성한다.

도 8은 독립 요청을 이용하여 요청자에 의해 개시되는 요청 템플릿 생성을 위한 방법을 도시한다. 단계 1에서, 요청자는 요청 템플릿 생성 요청을 서비스 계층에게 전송하여 요청 템플릿을 생성하라고 서비스 계층에 지시한다. 이 메시지는 다음과 같은 파라미터들을 포함할 수 있다.

ㆍ templateType: 생성될 메시지 템플릿의 유형이 요청 템플릿임을 나타낸다.

ㆍ numOfRequestTemplatesToBeCreated (Nt): 생성될 요청 템플릿들의 수를 나타낸다. 요청자는 복수의 요청 템플릿들을 생성하도록 요청할 수 있고; 이 경우, 각각의 템플릿에 포함될 요청 파라미터들은 listOfRequestParameters에 포함된다.

ㆍ listOfRequestParameters: 생성될 요청 템플릿에 포함될 그 값들을 포함하는 요청 파라미터들의 리스트를 나타낸다. 일반적으로, 이러한 파라미터들 및 그 값들은 미래의 요청들에서 반복적으로 이용될 것이다. 이와 같이, 요청 템플릿을 생성하여 이들을 포함하는 것에 의해, 이들은 미래의 요청들에서 생략될 수 있고, 결국 미래의 요청들의 크기를 감소시킬 수 있다. numOfRequestTemplateToBeCreated가 1보다 큰(즉, Nt>1) 경우, listOfRequestParameters는 모든 포함된 파라미터들을 Nt 하위 그룹들로 분할해야 하고, 각각의 하위 그룹 내의 파라미터들은 별개의 요청 템플릿을 생성하는데 이용될 것이다. 도 9에 도시된 바와 같이, 요청 메시지에서 원래 Np(예를 들어, Np=15) 요청 파라미터들이 있고 Nt=3인 것으로 가정한다. 이 예에서, listOfRequestParameters는 파라미터들의 3개의 하위 그룹을 포함할 것이다. 제1 하위 그룹은 2개의 요청 파라미터를 포함하고 제1 요청 템플릿(REQT1)을 생성하는데 이용될 것이고, 제2 하위 그룹은 다음 3개의 요청 파라미터를 포함하고 제2 요청 템플릿(REQT2)을 생성하는데 이용될 것이고, 제3 하위 그룹은 마지막 2개의 파라미터를 포함하고 제3 요청 템플릿(REQT3)을 생성하는데 이용될 것이다. 일부 요청 파라미터들은 도 8이 보여주는 바와 같이 요청 템플릿에 포함되거나 이용되지 않을 것이라는 점에 유의한다. oneM2M을 예로서 취하면, 표 1에 도시된 일부 요청 파라미터들은 요청 템플릿에 포함될 수 있다: 동작, 요청 만료 타임스탬프, 결과 만료 타임스탬프, 동작 실행 시간, 응답 유형, 결과 지속성, 결과 콘텐츠, 이벤트 카테고리, 전달 집성, 그룹 요청 식별자, 필터 기준, 발견 결과 유형, 보안 정보 등.

ㆍ listOfExistingRequestTemplateIDs: 서비스 계층에서 이미 생성되고 저장된 기존의 요청 템플릿 식별자들의 리스트를 나타낸다. 이 파라미터는 기존의 요청 템플릿들에 기반하여 새로운 요청 템플릿을 생성하는데 이용되어, 요청자는 요청 파라미터들을 나타낼 필요가 없고 기존의 요청 템플릿들의 식별자만을 나타낼 필요가 있다. 이 파라미터가 단계 1에 포함된다면, 생성될 요청 템플릿은 이들 기존의 요청 템플릿들에 더하여 listOfRequestParameters에 표시된 임의의 파라미터들에 기반할 것이다. 다시 말해서, 생성될 요청 템플릿은 Nt=1인 경우에 listOfRequestParameters 및 이들 기존의 요청 템플릿들에 포함된 모든 요청 파라미터들을 포함할 것이다. 여전히 도 9를 예로서 이용하면, 도 9에 도시된 바와 같이, listOfExistingRequestTemplateIDs가 3개의 요청 템플릿(REQT1, REQT2, 및 REQT3)을 포함하면, 서비스 계층은 이들 3개의 기존의 요청 템플릿의 식별자들만을 포함할 수 있고 본질적으로 REQT1, REQT2, 및 REQT3으로부터의 모든 요청 파라미터들을 포함할 수 있는 새로운 요청 템플릿 REQT123을 생성할 것이다. 이러한 새로운 요청 템플릿을 생성함으로써, 서비스 계층은 요청자들이 기존의 요청 템플릿들을 활용하거나 재이용하기 위해 더 많은 유연성 및 더 높은 효율을 제공한다. 예를 들어, 요청자는 이후에 단순히 요청 템플릿 REQT123을 이용하여 최적화된 요청을 생성할 수 있고, REQT123의 식별자를 서비스 계층에게 알려야만 할 필요가 있고; 그렇지 않으면 이러한 새로운 템플릿을 이용하지 않을 경우, 요청자는 동일한 최적화된 요청을 생성하기 위해 REQT1, REQT2, 및 REQT3을 함께 이용할 필요가 있고, (각각 REQT1, REQT2, 및 REQT3에 대한) 3개의 식별자를 서비스 계층에게 통지할 필요가 있다. numOfRequestTemplatesToBeCreated가 1보다 큰(즉, Nt>1) 경우, listOfRequestParameters가 요청 파라미터들을 몇 개의 하위 그룹들로 분할하는 방법과 유사하게, listOfExistingRequestTemplateIDs는 모든 포함된 템플릿 식별자들을 Nt 하위 그룹들로 분할해야 하고, 각각의 하위 그룹 내의 템플릿 식별자들은 별개의 요청 템플릿을 생성하는데 이용될 것이다.

ㆍ listOfAllowedRequestors: 단계 2에서 생성될 요청 템플릿들을 활용할 수 있는 요청자들의 리스트를 나타낸다. 이 파라미터는 임의적이다.

ㆍ listOfTargetResources: 단계 2에서 생성될 요청 템플릿들이 적용될 수 있는 타겟 리소스들의 리스트를 나타낸다. 이 파라미터는 임의적이다.

ㆍ MTPList: 생성되고 있는 요청 템플릿에 적용될 기존의 메시지 템플릿 정책들의 리스트를 나타낸다. 이 파라미터는 임의적이다. 이 파라미터가 포함되는 경우, listOfAllowedRequestors 및 listOfTargetResources가 필요하지 않을 수 있다.

여전히 도 8을 참조하면, 단계 2에서, 서비스 계층은 단계 1로부터 요청 템플릿 생성 요청을 수신하고 이를 처리하여 요청자에 의해 요구되는 바와 같은 대응하는 요청 템플릿들을 생성한다. 서비스 계층은 동일한 템플릿이 이전에 생성되었는지를 체크할 수 있고; 만일 그렇다면, 새로운 것을 생성하지 않을 수 있다. 생성된 요청 템플릿은 일부 요청 파라미터들 및 다른 특성들(예를 들어, 생성, 만료 시간, 허용된 요청자들의 리스트, 타겟 리소스들의 리스트, 자식으로서의 다른 요청 템플릿들의 리스트 등)을 가질 수 있다. 일 실시예에서, numOfRequestTemplatesToBeCreated가 1(즉, Nt=1)과 동일하면, 서비스 계층은 새로운 요청 템플릿을 생성하기 위해 listOfRequestParameters에 포함된 모든 요청 파라미터들 및 listOfExistingRequestTemplateIDs에 표시된 임의의 기존의 요청 템플릿들을 단순히 이용한다는 점에 유의한다. 서비스 계층은 생성된 요청 템플릿에 대한 식별자를 할당한다. 또한, 일 실시예에서, numOfRequestTemplatesToBeCreated가 1보다 큰(즉, Nt>1) 경우, 서비스 계층은 Nt 요청 템플릿들을 생성할 것이라는 점에 유의한다. 생성될 각각의 요청 템플릿은 listOfRequestParameters의 하위 그룹에 포함된 요청 파라미터들 및 하위 그룹 listOfExistingRequestTemplateIDs에 포함된 임의의 기존의 템플릿 식별자들에 기반할 것이다. 서비스 계층은 각각의 생성된 요청 템플릿에 대한 식별자를 할당한다. 생성되면, 템플릿의 파라미터 값들을 포함하기 위한 임의의 적절한 데이터 구조를 포함할 수 있는 요청 템플릿(들)은 서비스 계층을 구현하는 네트워크 장치(예를 들어, 서버, 게이트웨이, 디바이스)의 메모리에 저장될 수 있다.

요청 템플릿은 테이블, XML 문서, 또는 임의의 다른 적절한 데이터 구조 또는 문서와 같은 임의의 적절한 형태의 데이터 구조로 구현될 수 있다. 위의 스마트 계측 이용 사례를 참조하면, 이하에서는, oneM2M 프로토콜들을 이용하여 서버 서비스 계층(즉, serverCSE)에서 contentInstance 리소스를 생성하는 것을 통해 그 판독들을 주기적으로 보고하는 AE로서 스마트 계측기(즉, 계측기 AE123)를 가정하여, 그 이용 사례의 맥락에서 생성될 수 있는 템플릿의 예를 예시한다. 이하에서 보여지는 요청 템플릿은 다음과 같은 9개의 파라미터를 포함하는 서버에서 생성될 수 있지만, 더 많은 요청 파라미터들이 이용 사례 요건에 의존하는 요청 템플릿에 포함될 수 있다:

1. 동작은 리소스를 생성하는 것이다.

2. 발신자 또는 요청자는 할당된 식별자 meterAE123을 갖는 애플리케이션으로서 서버에 등록된 스마트 계측기이다.

3. 리소스는 meterAE123의 컨테이너 meterContainer234 하에서 생성될 것이다.

4. 생성될 리소스 유형은 contentInstance이다(즉, 각각의 보고된 판독은 상이한 contentInstance에 저장될 것이다).

5. 요청 만료 시간은 1800초이다. 다시 말해서, meterAE123으로부터의 각각의 수신된 생성 요청은 1800초 후에 만료될 것이다.

6. 동작 실행 시간은 600초이다. 다시 말해서, 서버는 600초까지 meterAE123으로부터의 생성 요청을 처리할 필요가 있다.

7. 응답 유형은 서버가 즉시 스마트 계측기에 ACK를 전송하고 나중에 응답이 뒤따르는 비-차단 동기 사례이다.

8. 각각의 수신된 생성 요청에 대한 이벤트 카테고리는 서버가 다른 CSE에 요청을 전달할 경우 "최선의 노력"으로 설정된다.

9. 토큰 요청 표시자는 참으로 설정되고, 이는 스마트 계측기가 토큰 요청 절차를 지원한다는 것을 의미하고, 발신자는 수신자가 응답에서 토큰 요청 정보 파라미터를 제공하면 토큰 요청 절차를 시도할 수 있다.

다음은 XML 포맷의 이러한 값들을 포함하는 템플릿의 예이다:

여전히 도 8을 참조하면, 단계 3에서, 서비스 계층은 요청 템플릿 생성 응답을 요청자에게 전송한다. 이 메시지는 모든 생성된 요청 템플릿들의 식별자들(즉, 요청 템플릿 식별자들의 리스트 - RQTID)을 포함한다.

도 10은 정규 요청을 전송할 때 요청자에 의해 개시되는 요청 템플릿 생성을 위한 방법을 도시한다. 단계 1에서, 요청자가 서비스 계층에서 리소스 또는 서비스에 액세스하기 위한 정규 요청을 전송할 때, 요청자는 이 메시지에서 새로운 파라미터 요청 템플릿 생성 표시자(RQTCI)를 포함한다. RQTCI는 서비스 계층에게 이 정규 요청을 처리하는 것 이외에 요청 템플릿들을 추가적으로 생성하도록 지시하는데 이용된다. RQTCI는 기본적으로 도 8의 단계 1에 포함된 바와 같은 모든 정보를 나타내고; 유일한 예외는 RQTCI가 그들이 이미 정규 요청에 포함되어 있기 때문에 요청 파라미터 값들을 포함할 필요가 없다는 것이다. 본질적으로, RQTCI는 템플릿이 요청에 포함되고 RQTCI에 의해 표시/암시되는 파라미터들에 기반하여 구축되어야 한다는 표시로서 역할한다. 요청자가 유사한 후속 요청들을 발행할 때, 이는 동일한 파라미터들을 다시 재전송하는 대신에 템플릿 식별자를 이용할 수 있다. 물론, 후속 요청에서 상이할 필요가 있는 파라미터들은 요청자에 의해 무시될 수 있다. 무시는 요청자가 템플릿에서 이용되는 것과 상이한 일부 값들을 이용하도록 응답자에게 지시할 수 있다는 것을 의미한다. 이 요청은 생성되고 있는 요청 템플릿에 적용될 기존의 메시지 템플릿 정책들의 리스트를 나타내기 위해 MTPList를 포함할 수 있다는 점에 유의한다.

단계 2에서, 서비스 계층은 단계 1로부터 수신된 요청을 처리하고 정규 응답을 생성한다. 그 후, 서비스 계층은 RQTCI에 의해 표시된 바와 같이 요청 템플릿들을 생성한다.

단계 3에서, 서비스 계층은 정규 응답을 요청자에게 전송한다. 도 8에서의 단계 3과 유사하게, 단계 2에서 생성된 요청 템플릿들의 식별자들(즉, RQTID)이 이 응답 메시지에 포함된다.

다른 양태에서, 서비스 계층은 요청자로부터 정규 요청들을 수신하는 동안 요청 템플릿의 생성을 능동적으로 개시할 수 있다. 서비스 계층은 복수의 정규 요청들이 유사한 요청 파라미터들을 이용하는 것을 관측할 때, 이들 요청 파라미터들을 포함하는 요청 템플릿을 생성할 수 있다. 그 후, 서비스 계층은 요청자에게 생성된 요청 템플릿을 통지할 필요가 있으며, 따라서 요청자는 이를 활용하여 정규 요청들의 크기를 감소시키고 최적화된 요청들을 생성할 수 있고; 서비스 계층이 이 작업을 수행하기 위한 두 가지 사례가 있다. 사례 1에서, 서비스 계층은 전용 요청 템플릿 통지를 요청자에게 전송하고; 사례 2에서, 서비스 계층은 요청자로부터 다음 정규 요청을 대기하고, 대응하는 응답 메시지에서 생성된 요청 템플릿의 식별자를 피기백한다. 요청자는 서비스 계층에게 요청 템플릿들을 이용할 수 있고 이를 이용할 의향이 있음을 표시할 수 있다. 이러한 표시는 등록 동안 서비스 계층에 제공될 수 있거나 또는 표시는 서비스 계층에 의해 할당되는 경우, 요청자가 미래의 유사한 요청들에 대한 메시지 템플릿을 이용할 의향이 있음을 서비스 계층에 표시하기 위해 다른 요청 메시지들에 포함될 수 있다.

도 11은 서비스 계층에 의해 개시되는 요청 템플릿들을 생성하기 위한 방법 및 생성된 요청 템플릿들의 식별자들이 별개의 통지 메시지를 이용하여 요청자에게 다시 전송되는 것을 도시한다.

단계 1 내지 단계 4에서, 요청자는 2개의 연속적인 정규 요청을 서비스 계층에 전송하고, 서비스 계층은 2개의 연속적인 응답으로 응답한다. 도면이 명시적으로 보여주지는 않지만, 요청자로부터 서비스 계층으로의 2개보다 많은 정규 요청이 있을 수 있다. 요청들은 요청자가 유사할 수 있는 미래의 요청들 및/또는 응답들을 위한 메시지 템플릿을 이용할 의향이 있고/있거나 이를 이용할 수 있다는 표시를 포함할 수 있다.

단계 5에서, 서비스 계층은 이러한 정규 요청들을 분석하고, 요청자가 각각의 정규 요청에서 유사하거나 동일한 요청 파라미터들을 이용한다는 것을 지능적으로 알아낸다. 그 후, 서비스 계층은 요청 템플릿(또는 복수의 요청 템플릿들)을 생성하기로 결정한다. 서비스 계층은 또한 생성된 요청 템플릿을 하나 이상의 기존의 메시지 템플릿 정책과 연관시킬 수 있다. 예를 들어, 유사한 요청 파라미터들을 이용하는 수신된 연속적인 요청들(또는 비-연속적인 요청들)의 수가 임계 정수 이상일 때, 서비스 계층은 요청 템플릿들을 생성하기로 결정한다. 그 다음, 모든 이러한 요청들에 이용되는 요청 파라미터들이 동일한 경우, 서비스 계층은 모든 이러한 파라미터들을 포함하기 위해 하나의 요청 템플릿을 단순히 생성할 수 있다. 이러한 요청들이 유사한 요청 파라미터들을 이용하지만 정확히 동일한 것들이 아니라면, 서비스 계층은 복수의 요청 템플릿들을 생성할 수 있다. 예를 들어, 이러한 요청들에서 공통으로 이용되는 요청 파라미터들의 각각의 세트는 요청 템플릿을 생성하는데 이용될 수 있다(각각의 요청에서 공통으로 이용되지 않는 요청 파라미터들은 요청 템플릿을 생성하는데 또한 이용될 수 있다).

도 12는 서비스 계층이 3개의 연속적인 정규 요청을 수신하는 예를 도시하며, 이는 도면이 도시하는 바와 같이 일부 유사한 요청 파라미터들을 이용한다. 이러한 특정 시나리오의 경우, 서비스 계층은 다음의 요청 템플릿들을 생성할 수 있지만, 추가 템플릿들도 가능할 수 있다.

ㆍ 세트 S123에 포함된 요청 파라미터들에 대한 요청 템플릿을 생성한다.

ㆍ 세트 S12에 포함된 요청 파라미터들에 대한 요청 템플릿을 생성한다.

ㆍ 세트 S13에 포함된 요청 파라미터들에 대한 요청 템플릿을 생성한다.

ㆍ 세트 S23에 포함된 요청 파라미터들에 대한 요청 템플릿을 생성한다.

ㆍ 세트 S12-S123에 포함된 요청 파라미터들에 대한 요청 템플릿을 생성한다.

ㆍ 세트 S13-S123에 포함된 요청 파라미터들에 대한 요청 템플릿을 생성한다.

ㆍ 세트 S23-S123에 포함된 요청 파라미터들에 대한 요청 템플릿을 생성한다.

ㆍ 세트 S1에 포함된 요청 파라미터들에 대한 요청 템플릿을 생성한다. 이것은 요청#1이 반복될 경우에 유용하다.

ㆍ 세트 S2에 포함된 요청 파라미터들에 대한 요청 템플릿을 생성한다. 이것은 요청#2가 반복될 경우에 유용하다.

ㆍ 세트 S3에 포함된 요청 파라미터들에 대한 요청 템플릿을 생성한다. 이것은 요청#3이 반복될 경우에 유용하다.

단계 6에서, 서비스 계층은 이에 따라 단계 5에서 결정된 바와 같이 요청 템플릿들을 생성한다.

단계 7에서, 서비스 계층은 요청 템플릿 통지를 요청자에게 전송하여 단계 6에서 생성된 요청 템플릿들의 식별자들(즉, RQTID)을 요청자에게 통지한다. 대안적으로, 서비스 계층은, 요청자가 RQTID에 기반하여 생성된 요청 템플릿을 검색하기 위한 별도의 단계를 취할 필요가 없도록, 이 단계에서 각각의 생성된 요청 템플릿의 표현을 포함할 수 있다.

단계 8에서, 요청자는 단계 7로부터 RQTID를 성공적으로 수신했는지를 나타내기 위해 요청 템플릿 통지 응답을 다시 서비스 계층으로 전송한다.

도 11에서, 대안적으로, 단계 5 및 단계 6은 단계 3과 단계 4 사이에서 발생할 수 있다는 점에 유의한다. 그 후, 서비스 계층은 단계 4에서 RQTID를 피기백할 수 있고; 따라서, 단계 7 및 단계 8은 필요하지 않다.

도 13은 서비스 계층에 의해 개시되는 요청 템플릿들을 생성하기 위한 방법 및 생성된 요청 템플릿들의 식별자들이 요청자에게 다시 정규 응답으로 피기백되는 것을 도시한다. 단계 1 내지 단계 6은 도 11의 단계 1 내지 단계 6과 동일하다.

단계 7에서, 요청자는 새로운 정규 요청을 서비스 계층에 전송한다.

단계 8에서, 서비스 계층은 새로운 정규 요청을 수신한다. 서비스 계층은 이를 처리하고 정규 응답을 생성한다. 서비스 계층은 이러한 정규 응답 메시지에서 단계 6에서 생성된 요청 템플릿들의 식별자들(즉, RQTID)을 피기백한다.

다른 양태에서, 서비스 계층 자체(또는 관리 애플리케이션)는 사전에 요청 템플릿들을 생성할 수 있다. 그 후, 요청자는 서비스 계층으로부터 임의의 적절한 요청 템플릿을 발견하고 템플릿을 활용하여 최적화된 요청들을 생성하고 정규 요청들의 크기를 단축시킬 수 있다.

도 14는 서비스 계층에 의해 개시되는 사전적 요청 템플릿 생성을 위한 방법을 도시한다.

단계 1에서, 서비스 계층(또는 그 관리 애플리케이션)은 요청자로부터의 임의의 정규 요청 메시지들을 고려하지 않고 일부 요청 템플릿들을 사전에 생성할 수 있지만, 요청자에게 제공될 수 있는 그 능력 및 서비스들에만 기반한다. 이러한 방식으로, 요청자는 이러한 요청 템플릿들을 발견할(또는 할당받을) 필요가 있고 이들을 이용하여 서비스 계층과 상호작용할 수 있다. 다시 말해서, 이러한 요청 템플릿들을 생성함으로써, 서비스 계층은 이들 요청 템플릿들에 기술된 바와 같이 요청 파라미터들을 이용하는 요청 메시지들만을 수락하는 것을 명시할 수 있고; 서비스 계층은 요청자가 그 요청 메시지에 있는 새로운 값들을 서비스 계층에 표시함으로써 일부 요청 파라미터들의 값을 덮어쓸 수 있도록 요청 템플릿에 대한 제약들을 상실할 수 있다. 서비스 계층은 이들 생성된 요청 템플릿들을 요청자에게 할당할 수 있고, 이는 아래에 설명될 것이라는 점에 유의한다. 서비스 계층은 또한 생성된 요청 템플릿을 하나 이상의 기존의 메시지 템플릿 정책과 연관시킬 수 있다.

단계 2에서, 요청자는 템플릿 발견 요청을 서비스 계층으로 전송하여 메시지 템플릿 필터(MTFilter)에 기반하여 요청 템플릿들을 발견한다. MTFilter은 요청자가 이용하도록 허용되는 요청 템플릿들, 특정 타겟 리소스들에 적용가능한 요청 템플릿들, 특정 요청 파라미터들을 포함하는 요청 템플릿들, 특정 요청 유형들에 대한 요청 템플릿들, 요청 템플릿이 갖는 다른 특성들 등과 같은 다양한 검색 기준들을 나타낼 수 있다.

단계 3에서, 서비스 계층은 MTFilter에 의해 표시된 기준에 따라 국부적으로 저장된 요청 템플릿들을 검색한다. 그 후, 서비스 계층은 MTFilter과 일치하는 요청 템플릿들의 리스트(즉, MTList에서의 메시지 템플릿 식별자들의 리스트)를 포함함으로써 템플릿 발견 응답 메시지를 요청자에게 전송한다. 도면에 도시되어 있지는 않지만, 요청자는 발견된 요청 템플릿의 콘텐츠들을 검색하여 이를 이용하여 최적화된 요청을 생성할 수 있기 전에 서비스 계층에 후속 요청을 전송할 수 있다. 요청 템플릿을 어떻게 검색할지가 이하에서 논의된다.

또 다른 양태에서, 요청자는 정규 요청(또는 최적화된 요청)을 서비스 계층에 전송할 때, 응답 템플릿들에 관련된 일부 작업들을 수행하라고(예를 들어, 새로운 응답 템플릿을 생성하라고) 서비스 계층에게 요청하기 위해 응답 템플릿 표시자(RSTI)를 피기백한다. RSTI가 새로운 응답 템플릿을 생성하는 것을 나타내는 경우, 서비스 계층은 새로운 응답 템플릿을 생성하고, 이를 응답 템플릿 식별자(RSTID)와 함께 할당하고, 이를 국부적으로 저장할 것이다. 그 후, 서비스 계층은 정규 응답(또는 최적화된 응답)을 요청자에게 전송한다. 이 응답 메시지는 응답 템플릿 생성 표시자(RSTCI) 및 RSTID를 포함할 것이고; RSTCI는 서비스가 방금 생성된 응답 템플릿을 포함하고; 그 후 요청자는 RSTCI에 따라 동일한 응답 템플릿을 생성하고, 그 식별자를 RSTID에 설정하고, 국부적으로 이를 저장한다. 요청자가 동일한 응답 템플릿을 생성하는 이유는 요청자가 임의의 미래의 최적화된 응답 메시지를 수신할 때 원래 응답 메시지를 복원하기 위해 동일한 응답 템플릿을 이용할 필요가 있기 때문이다.

도 14는 응답 템플릿 생성을 위한 절차를 도시한다. 단계 1에서, 요청자는 요청 메시지(정규 요청 또는 최적화된 요청 중 어느 하나)를 서비스 계층에 전송한다. 이 메시지는 단계 3에서 응답 템플릿을 생성하도록 서비스 계층에게 지시하는 새로운 파라미터 응답 템플릿 표시자(RSTI)를 포함할 수 있다. 이와 같이, RSTI는 응답 템플릿에 포함될 응답 파라미터들 및 그 값들을 또한 포함할 수 있다. 이 요청은 생성되는 응답 템플릿에 적용할 기존의 메시지 템플릿 정책들의 리스트를 나타내기 위해 MTPList를 포함할 수 있다.

단계 2에서, 서비스 계층은 요청 메시지를 처리하고 정규 응답 메시지를 생성한다.

단계 3에서, RSTI가 단계 1에 포함되면, 서비스 계층은 응답 템플릿을 생성한다. 서비스 계층은 또한, 요청자가 단계 1에서의 어떠한 정책을 표시하더라도, 생성된 응답 템플릿을 하나 이상의 기존의 메시지 템플릿 정책과 연관시킬 수 있다. 응답 템플릿에 포함될 응답 파라미터들은 RSTI로부터의 것일 수 있거나 또는 서비스 계층에 의해 결정될 수 있다. oneM2M 서비스 계층을 예로서 취하면, 서비스 계층은 각각의 미래의 응답에서 동일한 값을 갖는 다음의 응답 파라미터들을 이용하기로 결정할 수 있고; 이와 같이, 응답 템플릿은 이러한 파라미터들을 포함하도록 생성될 수 있다. 응답 템플릿에 포함될 수 있는 oneM2M 응답 파라미터들은 콘텐츠, 출처, 결과 만료 타임스탬프, 이벤트 카테고리 등을 포함한다.

단계 4에서, 서비스 계층은 요청자가 또한 그 측에서 동일한 응답 템플릿을 생성할 필요가 있는지를 결정한다. 예인 경우, 단계 5에 응답 템플릿 생성 표시자(RSTCI) 및 응답 템플릿 식별자(RSTID)가 포함될 것이고; 그렇지 않다면, 요청자는 나중에 서비스 계층으로부터 임의의 응답 템플릿을 발견하고 검색할 수 있고, 단계 5는 임의의 RSTCI 및 RSTID를 포함하지 않을 것이다.

단계 5에서, 서비스 계층은 단계 2에서 생성된 응답을 요청자에게 전송한다. 이 메시지는 단계 4에서 생성된 RSTCI 및 RSTID를 포함할 수 있다. 또한, 이 단계는 이전에 생성된 임의의 응답 템플릿 및 그 식별자를 피기백할 수 있다.

단계 6에서, 요청자는 단계 5로부터 수신된 응답을 처리한다. 단계 5가 RSTCI 및 RSTID를 포함하는 경우, RSTCI를 이용하여 응답 템플릿을 생성하고 이를 국부적으로 저장한다. 생성된 응답 템플릿의 식별자는 단계 5로부터 RSTID로 설정될 것이다.

다른 양태에서, 서비스 계층은 먼저 자신을 서비스 계층에 등록할 때 적절한 요청 템플릿들을 요청자에게 할당할 수 있거나, 또는 서비스 계층은 그렇게 하기 위해 전용 템플릿 할당 요청을 이용한다. 대안적으로, 요청자는 서비스 계층으로 메시지 템플릿 필터(즉, MTFilter)를 갖는 템플릿 발견 요청을 발행하고, 임의의 원하는 메시지 템플릿을 검색하도록 지시할 수 있다. 메시지 템플릿을 발견하거나 메시지 템플릿을 할당받은 후에, 요청자는 메시지 템플릿이 미래에 업데이트 또는 삭제될 때 자동 통지들을 수신하기 위해 메시지 템플릿에 가입할 수 있다.

도 16은 3개의 잠재적인 사례가 도시되는 메시지 템플릿 할당 및 발견을 위한 방법을 도시한다. 사례 1에서, 서비스 계층은 요청자가 자신을 서비스 계층에 등록할 때 기존의 메시지 템플릿들을 요청자에게 할당한다. 사례 2에서, 서비스 계층은 별개의 전용 요청 메시지를 이용하여 기존의 메시지 템플릿들을 요청자에게 할당한다. 사례 3에서, 요청자는 서비스 계층으로부터 기존의 메시지 템플릿을 발견한다. 이들 3가지 사례는 임의의 순서로 실행될 수 있고 함께 이용될 필요가 없다. 다시 말해서, 1) 단계 1 및 단계 2는 사례 1에 대해 함께 실행될 필요가 있지만, 다른 단계들에 대한 의존성을 갖지 않고; 2) 단계 3 및 단계 4는 사례 2에 대해 함께 수행될 필요가 있지만, 다른 단계들에 대한 의존성을 갖지 않고; 3) 단계 5 및 단계 6은 함께 발생할 필요가 있지만, 다른 단계들에 대한 의존성을 갖지 않는다.

단계 1에서, 요청자는 서비스 계층 등록 요청(예를 들어, oneM2M에서의 AE 등록 또는 CSE 등록)을 서비스 계층에 전송한다. 이 등록 요청에서, 요청자는 다음과 같은 정보를 표시할 수 있으며, 이에 기반하여 서비스 계층은 요청자에 대한 더 적절한 메시지 템플릿들을 선택하고 할당할 수 있고; 추가로, 서비스 계층은 또한 이들 정보를 활용하여 요청자에 대한 새로운 메시지 템플릿들을 생성할 수 있다:

ㆍ 요청자가 요청 템플릿들, 응답 템플릿들, 또는 둘 다를 이용할 수 있는지?

ㆍ 요청자가 어떤 메시지 템플릿들로 프로비저닝되고자 하는지?

ㆍ 요청자가 어떤 유형들의 요청들(즉, CRUD)을 자주 전송할지?

ㆍ 요청자가 어떤 요청 및/또는 응답 파라미터들을 많이 이용할지?

단계 2에서, 서비스 계층은 단계 1로부터의 요청을 처리하고 서비스 계층 등록 응답을 요청자에게 전송한다. 이 응답은 서비스 계층이 요청자에게 할당하는 메시지 템플릿 식별자들의 리스트를 나타내기 위해 새로운 파라미터 MTList를 포함한다.

단계 3에서, 서비스 계층은 템플릿 할당 요청을 요청자에게 전송한다. 이 요청은 서비스 계층이 요청자에게 할당하는 메시지 템플릿 식별자들의 리스트를 나타내기 위해 새로운 파라미터 MTList를 포함한다.

단계 4에서, 요청자는 응답을 서비스 계층에 전송한다.

단계 5에서, 도 14의 단계 2와 동일하다.

단계 6에서, 도 14의 단계 3과 동일하다.

도 17은 서비스 계층 등록 절차들 동안에 메시지 템플릿을 생성/할당하기 위한 단순화되고 더 경량인 접근법을 도시한다. 단계 1에서, 요청자는 서비스 계층 등록 요청을 전송함으로써 서비스 계층에 등록한다. 이 요청에서, 요청자는 그 값들을 포함하는 일부 디폴트 요청 파라미터들을 나타내거나 표현하며, 이는 후속 요청들에서 반복적으로 이용할 것이다.

단계 2에서, 서비스 계층은 이들 디폴트 파라미터들을 기록하기 위해 요청자에 대한 디폴트 요청 템플릿을 생성한다. 디폴트 템플릿은 메시지 템플릿 식별자를 명시적으로 포함하지 않는 경우 요청자로부터의 임의의 미래 요청 메시지가 이 디폴트 템플릿에 기반하여 서비스 계층에 의해 처리될 것임을 의미한다. 디폴트 템플릿은 동일한 요청자에 의해서만 이용될 것이다.

단계 3에서, 서비스 계층은 서비스 계층 등록 응답을 요청자에게 전송한다. 서비스 계층 등록이 성공적인지 여부를 나타내는 것에 더하여, 서비스 계층은 또한 디폴트 템플릿이 단계 2에서 생성되었는지를 나타낸다.

단계 4에서, 서비스 계층 등록이 성공적이고, 디폴트 템플릿이 성공적으로 생성된 후에, 요청자는 최적화된 요청을 서비스 계층에 전송한다. 이 최적화된 요청은 더 이상 메시지 템플릿 식별자를 포함할 필요가 없고, 또한, 이 최적화된 요청은 단계 1에 포함된 어떠한 디폴트 파라미터들도 포함하지 않는다.

단계 5에서, 서비스 계층은 수신된 최적화된 요청을 처리하기 위해 단계 2에서 생성된 바와 같은 요청자의 디폴트 템플릿을 이용한다.

단계 6에서, 서비스 계층은 단계 4로부터 수신된 최적화된 요청에 대한 응답으로서 요청자에게 메시지를 전송한다.

또 다른 양태에 따르면, 요청자는 메시지 템플릿이 저장되는 서비스 계층으로부터 특정 메시지 템플릿을 검색하기 위해 메시지 템플릿 식별자(MTID)를 이용할 수 있다. 요청자는 전술한 절차들 중 하나로부터 MTID를 획득했을 수 있다.

도 18은 메시지 템플릿을 검색하기 위한 방법을 도시한다.

단계 1에서, 요청자는 템플릿 검색 요청을 서비스 계층에 전송한다. 이 메시지는 서비스 계층으로부터 검색될 메시지 템플릿의 식별자(즉, MTID)를 포함한다.

단계 2에서, 서비스 계층은 단계 1에서 MTID로 표시된 바와 같은 메시지 템플릿을 찾아내고 이 메시지 템플릿의 표현을 포함하는 응답을 생성한다.

단계 3에서, 서비스 계층은 요청자에게 응답을 다시 전송한다.

다른 양태에 따르면, 요청 템플릿을 발견한 후에, 요청 템플릿을 할당받거나 요청 템플릿을 그 자체로 생성하는 것에 의해, 요청자는 많은 요청 파라미터들을 포함하는 정규 요청과 대조적으로 더 작은 메시지 크기를 갖는 최적화된 요청을 생성하는데 이를 이용할 수 있다. 서비스 계층은 최적화된 요청을 수신할 때, 최적화된 요청으로부터 요청 템플릿 식별자(RQTID)를 추출하고, 대응하는 템플릿을 이용하여 최적화된 요청을 처리한다. RQTID에 의해 표시된 바와 같은 요청 템플릿이 다른 네트워크 위치(예를 들어, 데이터베이스, 템플릿들의 저장소, 다른 서비스 계층 등)에 위치하는 경우, 서비스 계층은 최적화된 요청을 적절히 처리하기 위해 다른 서비스 계층으로부터 요청 템플릿을 먼저 페치할 필요가 있다.

도 19는 요청 템플릿을 활용하기 위한 방법을 도시한다. 단계 1에서, 요청자는 최적화된 요청을 서비스 계층 SL1에 전송한다. 이 메시지는 요청자가 최적화된 요청을 생성하는데 이용한 요청 템플릿의 식별자를 나타내는 RQTID를 포함한다. 정규 요청으로부터 최적화된 요청을 생성하기 위해, 요청자는 기본적으로 요청 템플릿에 포함되는 요청 파라미터들을 정규 요청으로부터 제거하고 RQTID를 정규 요청에 삽입한다.

예를 들어, 위에서 논의된 스마트 계측기 예를 계속하면, oneM2M이 서비스 계층으로서 이용되는 것으로 가정하여, 스마트 계측기로부터 도 2의 서버로의 최적화된 요청 메시지는 다음의 형태를 취할 수 있고, 여기서 rqtid123은 전술한 예시적인 스마트 계측기 요청 템플릿을 나타내고 서버에 저장된다:

이 예에서, pc는 datatype m2m:primitiveContent:의 콘텐츠 파라미터이고, Originator. cin에 의해 제공될 리소스의 속성들은 datatype m2m:contentInstance의 <contentInstance> 리소스의 루트 요소이다. 이것은 요청 발신자에 의해 공급되는 필수 속성들(및 이 예에 도시되지 않은 임의적 속성들)을 포함한다. 이 예에서, 콘텐츠 파라미터는 2개의 속성들: contentInfo (cnf) - 이는 base64 인코딩을 명시함 - 및 content (con) 자체로 구성되는 <contentInstance> 리소스의 인스턴스를 포함한다.

요청 템플릿이 이용가능하지 않거나 이용되지 않았다면, 스마트 계측기는 다음의 정규 요청 메시지를 서버에 전송할 필요가 있을 것이다. 대조적으로, 최적화된 요청은 RQTID를 포함할 필요가 있지만, 9개의 요청 파라미터를 제거함으로써 메시지 크기를 감소시킨다.

여전히 도 19를 참조하면, 단계 2에서, 서비스 계층 SL1은 RQTID에 기반하여 대응하는 요청 템플릿을 찾아낸다. 요청 템플릿이 다른 서비스 계층 SL2에 저장되면, 서비스 계층 SL1은 단계들 3 및 4를 이용하여 요청 템플릿을 검색한다.

단계 3에서, 서비스 계층 SL1은 RQTID에 의해 표시된 바와 같이 요청 템플릿을 검색하기 위해 템플릿 검색 요청을 서비스 계층 SL2에 전송한다.

단계 4에서, 서비스 계층 SL2는 템플릿 검색 응답을 서비스 계층 SL1에 전송한다. 이 응답은 검색된 요청 템플릿의 표현(즉, 요청 파라미터들)을 포함한다.

단계 5에서, 서비스 계층 SL1은 검색된 요청 템플릿으로부터의 정보를 이용하여 최적화된 요청을 정규 요청으로 변환한다(즉, 요청 템플릿에 포함된 요청 파라미터들을 최적화된 요청에 복사하고 최적화된 요청으로부터 RQTID를 제거한다). 그 후, 서비스 계층 SL1은 정규 요청을 처리하고 정규 응답을 생성한다.

단계 6에서, 서비스 계층 SL1은 요청자에게 정규 응답을 다시 전송한다.

도 20은 요청 및 응답 템플릿들을 활용하기 위한 방법을 도시한다. 단계 1에서, 요청자는 최적화된 요청을 서비스 계층 SL1에 전송한다. 이 메시지는 요청자가 최적화된 요청을 생성하는데 이용한 요청 템플릿의 식별자를 나타내는 RQTID를 포함한다. 정규 요청으로부터 최적화된 요청을 생성하기 위해, 요청자는 기본적으로 요청 템플릿에 포함된 요청 파라미터들을 정규 요청으로부터 제거하고, RQTID를 정규 요청에 삽입한다. 또한, 최적화된 요청은 또한 응답 템플릿 표시자(RSTI)를 포함한다. RSTI는 다음과 같은 값들을 가질 수 있으며, 이에 기반하여, 단계 7에서 서비스 계층 SL1이 응답 템플릿을 생성 및/또는 활용할지 여부를 결정할 것이다:

ㆍ RSTI = "정규 응답" - 이것은 단계 7에서 서비스 계층 SL1에게 응답 템플릿을 생성 또는 활용하지 않도록 지시하지만, 요청자에게 정규 응답을 전송하도록 지시한다.

ㆍ RSTI = "새로운 응답 템플릿의 생성" - 이것은 단계 7에서 서비스 계층 SL1에게 응답 템플릿을 생성하도록 지시한다. 이 경우, RSTI는 또한 값들을 포함하는 어느 응답 파라미터들이 응답 템플릿에 포함되어야 하는지를 나타낸다.

ㆍ RSTI = "응답 템플릿을 이용하여 최적화된 응답을 생성함" - 이것은 단계 7에서 서비스 계층 SL1에게 응답 템플릿을 활용하여 최적화된 응답을 생성하도록 지시한다. 이 경우, RSTI는 또한 최적화된 응답을 생성하는데 이용될 응답 템플릿의 식별자(즉, RSTID)를 나타낸다.

단계 2에서, 서비스 계층 SL1은 RQTID에 기반하여 대응하는 요청 템플릿을 찾아낸다. 요청 템플릿이 다른 서비스 계층 SL2에 저장되면, 서비스 계층 SL1은 요청 템플릿을 검색하기 위해 단계 3 및 4를 이용한다.

단계 3에서, 서비스 계층 SL1은 RQTID에 의해 표시된 바와 같이 요청 템플릿을 검색하기 위해 템플릿 검색 요청을 서비스 계층 SL2로 전송한다.

단계 5에서, 서비스 계층 SL1은 검색된 요청 템플릿을 이용하여 최적화된 요청을 정규 요청으로 변환한다(즉, 요청 템플릿에 포함된 요청 파라미터들을 최적화된 요청에 복사하고 최적화된 요청으로부터 RQTID를 제거한다).

단계 6에서, 서비스 계층 SL1은 정규 요청을 처리하고 정규 응답을 생성한다.

단계 7에서, 단계 1에 포함된 RSTI에 따라, 서비스 계층 SL1은 다음의 동작들을 수행한다.

ㆍ RSTI = "정규 응답"이면, 단계 8.1에서는 아무것도 하지 않고 요청자에게 정규 응답만을 전송한다.

ㆍ RSTI = "새로운 응답 템플릿의 생성"이면, RSTI에 포함된 그 값들을 포함하는 모든 응답 파라미터들을 응답 템플릿에 복사함으로써 응답 템플릿을 생성하고 생성된 응답 템플릿에 대한 식별자(즉, RSTID)를 할당한다. 이어서, 생성된 응답 템플릿을 단계 8.2에서 파라미터 RSTCI 및 RSTID를 통해 요청자에게 전송한다.

ㆍ RSTI = "응답 템플릿을 이용하여 최적화된 응답을 생성함"이면, 단계 1에서 RSTI에 표시된 바와 같이 응답 템플릿을 활용하여 최적화된 응답을 생성한다. 그 후, 단계 8.3에서 최적화된 응답을 요청자에게 전송한다.

단계 8에서, 서비스 계층은 다음의 3가지 단계 중 하나를 이용하여 요청자에게 응답을 전송한다:

ㆍ 단계 8.1: 서비스 계층 SL1은 요청자에게 정규 응답을 전송한다.

ㆍ 단계 8.2: 서비스 계층 SL2는 요청자에게 정규 또는 최적화된 응답을 전송한다. 그러나, 정규 응답은 2개의 새로운 파라미터 RSTCI 및 RSTID를 포함한다. RSTCI는 단계 7에서 생성된 응답 템플릿을 포함하고, RSTID는 그 식별자이다. 최적화된 응답을 전송하는 경우, 최적화된 응답은 단계 7에서 생성되고 RSTCI에 포함된 새로운 응답 템플릿에 기반할 것이다.

ㆍ 단계 8.3: 서비스 계층 SL1은 요청자에게 단계 7에서 생성된 최적화된 응답을 전송한다. 이 메시지는 최적화된 응답을 생성하기 위해 단계 7에서 이용되는 응답 템플릿의 식별자를 포함한다.

단계 9에서, 요청자는 단계 8.1, 단계 8.2 또는 단계 8.3으로부터 수신된 응답 메시지를 처리한다.

그 응답이 단계 8.1로부터의 것(즉, 어떠한 새로운 파라미터도 없는 정규 응답)이면, 요청자는 단순히 이를 정규 응답으로서 처리한다.

그 응답이 단계 8.2로부터의 것(즉, RSTCI 및 RSTID가 포함된 정규 응답)이면, 요청자는 RSTCI에 따라 국부적으로 동일한 응답 템플릿을 생성/저장하고, 서비스 계층 SL1에 저장되는 동일한 응답 템플릿 및 요청자가 동일한 식별자를 갖도록 그 식별자를 RSTID로 설정한다.

그 응답이 단계 8.3으로부터의 것(즉, 최적화된 응답)이면, 요청자는 RSTID에 따라 대응하는 응답 템플릿을 찾아낸다. 그 후, 요청자는 응답 템플릿을 이용하여 최적화된 응답을 정규 응답으로 변환한다(즉, 응답 템플릿으로부터의 모든 응답 파라미터들 및 그 값들을 최적화된 응답에 복사한다).

또 다른 양태에서, 요청자는 메시지 템플릿 식별자(MTID)를 이용하여 서비스 계층에 저장된 특정 메시지 템플릿을 업데이트할 수 있다. 2개의 시나리오가 있을 수 있다. 사례 1에서, 요청자는 전용 템플릿 업데이트 요청을 서비스 계층에 전송하고; 사례 2에서, 요청자는 서비스 계층과의 임의의 종류의 정상 요청들을 수행할 때, MTID + 메시지 템플릿 업데이트 표시자(MTUI)를 서비스 계층에 동시에 전송하고; 그 결과, 서비스 계층은 먼저 요청자로부터의 정상 요청을 처리할 것이고, 이후 MTID 및 MTUI가 명시하는 것에 따라 대응하는 메시지 템플릿을 업데이트할 것이다. 업데이트된 메시지 템플릿이 다른 요청자들에 의해 이용 및/또는 가입되었다면, 서비스 계층은 이러한 요청자들에게 통지를 전송할 필요가 있고 이들에게 업데이트를 알릴 필요가 있다. 또한, 서비스 계층은 기존의 템플릿을 참조하는 요청자로부터의 인입 요청들을 모니터링할 수 있다. 이러한 모니터링에 기반하여, SL은 기존의 템플릿 파라미터 값들이 업데이트를 요구하는 사례들(예를 들어, 요청자가 기존의 템플릿에서 요청 파라미터를 계속 덮어씀) 및/또는 새로운 공통 파라미터들이 템플릿에 추가될 수 있는 사례들(예를 들어, 요청자가 기존의 템플릿에 포함되지 않은 새로운 파라미터들을 계속 이용함)을 검출할 수 있고; 서비스 계층은 그 기존의 파라미터 값들을 업데이트하고/하거나 새로운 파라미터들을 템플릿에 추가함으로써 기존의 템플릿을 자동으로 업데이트할 수 있다.

도 21은 전용 메시지를 이용하여 메시지 템플릿을 업데이트하기 위한 방법을 도시한다. 단계 1에서, 요청자는 템플릿 업데이트 요청을 서비스 계층에 전송한다. 이 메시지는 업데이트될 메시지 템플릿의 식별자(즉, MTID) 및 그 파라미터들/속성들(예를 들어, 그 허용된 요청자들, 그 타겟 리소스들, 그 자식 요청 템플릿 등)을 포함한다.

단계 2에서, 서비스 계층은 이에 따라 단계 1에 포함된 다른 정보에 따라 MTID에 의해 표시된 바와 같은 메시지 템플릿에 대한 업데이트를 행한다. 업데이트된 메시지 템플릿이 다른 요청자들에 의해 이용 및/또는 가입되었다면, 서비스 계층은 이러한 요청자들에게 통지를 전송할 필요가 있고 이들에게 업데이트를 알릴 필요가 있다.

단계 3에서, 서비스 계층은 단계 1이 성공적으로 처리되었는지를 나타내기 위해 템플릿 업데이트 응답을 요청자에게 전송한다.

도 22는 요청자가 요청 메시지를 서비스 계층에 전송할 때 동시에 메시지 템플릿을 업데이트하기 위한 방법을 도시한다. 단계 1에서, 요청자는 요청 메시지(정규 메시지 또는 최적화된 메시지 중 어느 하나)를 서비스 계층에 전송한다. 이 메시지는 다음과 같은 정보를 포함한다:

ㆍ MTID: 업데이트될 기존의 메시지 템플릿의 식별자이다.

ㆍ MTUI: 메시지 템플릿 업데이트 표시자이다. 이 파라미터는 서비스 계층에게 1) MTID에 의해 표시된 바와 같은 메시지 식별자가 업데이트될 필요가 있음; 2) 업데이트될 메시지 템플릿의 파라미터들 및/또는 특성들을 알려준다. 대안적으로, 이 파라미터는 이 요청 메시지에 포함되는 일부 요청 파라미터들을 표시할 수 있고, 서비스 계층은 MTID로 표시된 메시지 템플릿을 업데이트하기 위해 이들을 이용할 것이다.

단계 2에서, 서비스 계층은 요청 메시지를 처리하고 정규 응답(또는 최적화된 응답)을 생성한다. 그 다음, 서비스 계층은 단계 1에서의 MTUI에 따라 MTID에 의해 표시된 바와 같이 메시지 템플릿을 업데이트한다. 업데이트된 메시지 템플릿이 다른 요청자들에 의해 이용 및/또는 가입되었다면, 서비스 계층은 이러한 요청자들에게 통지를 전송할 필요가 있고 이들에게 업데이트를 알릴 필요가 있다.

단계 3에서, 서비스 계층은 단계 1이 성공적으로 처리되었는지를 나타내기 위해 응답을 요청자에게 전송한다.

다른 양태에서, 요청자는 메시지 템플릿 식별자(MTID)를 이용하여 서비스 계층에 저장된 특정 메시지 템플릿을 삭제할 수 있다. 2개의 시나리오가 존재한다. 사례 1에서, 요청자는 전용 템플릿 삭제 요청을 서비스 계층에 전송하고; 사례 2에서, 요청자는 서비스 계층과의 임의의 종류의 정상 요청들을 수행할 때, MTID + 메시지 템플릿 삭제 표시자(MTDI)를 서비스 계층에 동시에 전송하고; 그 결과, 서비스 계층은 먼저 요청자로부터의 정상 요청을 처리할 것이고, 이어서 MTID 및 MTDI가 명시하는 것에 따라 대응하는 메시지 템플릿을 삭제할 것이다. 삭제된 메시지 템플릿이 다른 요청자들에 의해 이용되거나 가입되었다면, 서비스 계층은 이들 요청자들에게 통지를 전송하고 이들에게 메시지 템플릿의 제거를 알릴 것이다. 여기서 삭제 동작은 요청자가 더 이상 삭제된 메시지 템플릿을 이용하기를 원하지 않는다는 것을 의미할 수 있다. 또한, 서비스 계층은 기존의 템플릿들이 어떻게 이용되었는지를 모니터링할 수 있고; 템플릿이 어떤 시간 동안 임의의 요청자에 의해 이용되지 않았거나 더 이상 관련되지 않으면, 서비스 계층은 이 템플릿을 자동으로 삭제할 수 있다.

도 23은 전용 메시지를 이용하여 메시지 템플릿을 삭제하기 위한 방법을 도시한다. 단계 1에서, 요청자는 템플릿 삭제 요청을 서비스 계층에 전송한다. 이 메시지는 삭제될 메시지 템플릿의 식별자(즉, MTID)를 포함한다.

단계 2에서, 서비스 계층은 이에 따라 MTID에 의해 표시된 바와 같이 메시지 템플릿을 제거한다. 삭제된 메시지 템플릿이 다른 요청자들에 의해 이용되거나 가입되었다면, 서비스 계층은 이들 요청자들에게 통지를 전송하고 이들에게 메시지 템플릿의 제거를 알릴 것이다.

단계 3에서, 서비스 계층은 단계 1이 성공적으로 처리되었는지를 나타내기 위해 템플릿 삭제 응답을 요청자에게 전송한다.

도 24는 요청자가 요청 메시지를 서비스 계층에 전송할 때 동시에 메시지 템플릿을 삭제하기 위한 방법을 도시한다. 단계 1에서, 요청자는 요청 메시지(정규 메시지 또는 최적화된 메시지 중 어느 하나)를 서비스 계층에 전송한다. 이 메시지는 다음과 같은 정보를 포함한다:

ㆍ MTID: 삭제될 기존의 메시지 템플릿의 식별자이다.

ㆍ MTDI: 메시지 템플릿 삭제 표시자이다. 이 파라미터는 MTID에 의해 표시된 바와 같이 메시지 템플릿을 삭제하도록 서비스 계층에게 알려준다.

단계 2에서, 서비스 계층은 요청 메시지를 처리하고 정규 응답(또는 최적화된 응답)을 생성한다. 그 다음, 서비스 계층은 MTID에 의해 표시된 바와 같이 메시지 템플릿을 삭제한다. 삭제된 메시지 템플릿이 다른 요청자들에 의해 이용되거나 가입되었다면, 서비스 계층은 이들 요청자들에게 통지를 전송하고 이들에게 메시지 템플릿의 제거를 알릴 것이다.

다른 양태에서, RQTID가 일반적으로 요청 파라미터들의 총 크기보다 훨씬 짧다는 사실이 주어지면, 요청자는 하나의 최적화된 요청에서 복수의 RQTID들을 포함할 수 있다. 그 후, 서비스 계층은 이들 복수의 RQTID들의 합집합(즉, 이들 RQTID들에 포함된 모든 요청 파라미터들의 조합)을 이용하여 최적화된 요청을 처리하고, 이에 따라 요청자에 대한 하나의 응답 메시지를 생성할 것이다. 이 특징은 복수의 요청 템플릿이 공동 템플릿으로서 함께 이용되고 요청 템플릿들의 관리 및 재이용 시에 더 많은 세분성 및 유연성을 제공하는 것을 허용한다.

도 25는 하나의 요청 메시지에서 복수의 요청 템플릿을 활용하기 위한 방법을 도시한다. 1) 요청자는 2개 이상(이 도면은 3개의 발견된 템플릿을 보여줌)의 요청 템플릿들을 발견하였고; 2) 이들 템플릿들 각각은 임의의 동일한 파라미터를 포함하지 않지만, 요청자가 이용할 요청 파라미터들의 서브세트를 포함하고; 3) 템플릿들은 요청자가 이용할 필요가 있는 모든 요청 파라미터들을 함께 포함하고 있는 것으로 가정한다.

단계 1에서, 요청자는 이들 3개의 요청 템플릿을 이용하여, 이들 템플릿들에서 어떠한 요청 파라미터도 포함하지 않지만, 이들 3개의 템플릿의 식별자들(즉, RQTID1, RQTID2, 및 RQTID3)만을 포함하는 최적화된 요청을 생성한다.

단계 2에서, 서비스 계층은 RQTID1, RQTID2, 및 RQTID3에 의해 표시된 바와 같이 이들 3개의 요청 템플릿에 포함된 모든 요청 파라미터들을 이용하여 최적화된 요청을 처리한다. 그 다음, 서비스 계층은 응답 메시지를 생성한다. 요청 템플릿에 포함된 요청 파라미터들은 반드시 순서대로 되어 있을 필요가 없다는 점에 유의한다.

단계 3에서, 서비스 계층은 단계 1에서 최적화된 요청이 성공적으로 처리되었는지를 나타내기 위해 응답 메시지를 요청자에게 전송한다.

또 다른 양태에 따르면, 메시지 템플릿들은 멀티-홉 서비스 계층 통신들 하에서 이용될 수 있다. 요청자가 요청 메시지들을 중간의 트랜지트 서비스 계층을 통해 목적지 서비스 계층에 전송한다고 가정한다. 2개의 서비스 계층 홉(즉, 요청자와 트랜지트 서비스 계층 사이의 제1 홉 및 트랜지트 서비스 계층과 목적지 서비스 계층 사이의 제2 홉)이 있다. 예를 들어, 요청자는 서비스 계층 그룹 동작을 트랜지트 서비스 계층에 전송하고, 이것은 이어서 그 동작을 하나 또는 복수의 목적지 서비스 계층(즉, 그룹 멤버들)에 전개한다. 따라서, 요청 템플릿들은 다음의 4가지 사례에서 활용될 수 있다.

사례 1에서, 요청자는 요청 템플릿을 이용하여 최적화된 요청들을 생성하고 이들을 트랜지트 서비스 계층에 전송하고, 트랜지트 서비스 계층은 단순히 임의의 최적화된 요청을 목적지 서비스 계층에 전달하며, 여기서 최적화된 요청은 대응하는 요청 템플릿에 기반하여 처리될 것이고; 이 경우, 트랜지트 서비스 계층은 템플릿 관련 기능을 갖지 않는다.

사례 2에서, 요청자는 여전히 요청 템플릿을 이용하여 최적화된 요청들을 생성하고 이들을 트랜지트 서비스 계층에 전송하지만, 트랜지트 서비스 계층은 그 요청 템플릿을 활용하여 요청자로부터 수신된 최적화된 요청을 처리하고, 정규 요청을 목적지 서비스 계층에 전달하며; 이 경우, 목적지 서비스 계층은 어떠한 템플릿 관련 기능도 갖지 않는다.

사례 3에서, 요청자는 여전히 요청 템플릿을 이용하여 최적화된 요청들을 생성하고 이들을 트랜지트 서비스 계층에 전송하고, 트랜지트 서비스 계층은 그 요청 템플릿을 이용하여 최적화된 요청을 처리하고; 또한, 트랜지트 서비스 계층은 다른 요청 템플릿을 이용하여 새로운 최적화된 요청을 생성하고 새로운 최적화된 요청을 목적지 서비스 계층에 전달하며, 새로운 최적화된 요청은 대응하는 요청 템플릿을 이용하여 처리될 것이고; 이 경우에, 트랜지트 서비스 계층과 목적지 서비스 계층 양쪽 모두는 템플릿 관련 기능을 갖지만, 2개의 서비스 계층 홉은 상이한 요청 템플릿을 이용한다.

사례 4에서, 요청자는 정규 요청들을 트랜지트 서비스 계층에 전송하고, 이는 요청 템플릿을 이용하여 최적화된 요청을 생성하고 이를 목적지 서비스 계층에 전송하며; 이 경우에, 요청자는 템플릿 관련 기능을 지원하지 않는다.

위의 멀티-홉 시나리오들을 더 효율적으로 가능하게 하기 위해, RQTID는 확인가능한 네트워크 주소 또는 식별자(예를 들어, URI)의 포맷으로 있을 수 있다는 점에 유의한다. 이 포맷에서의 RQTID는 중간 또는 트랜지트 서비스 계층들뿐만 아니라 목적지 서비스 계층들이 요청 템플릿을 다른 네트워크 위치로부터 페치하고 이를 국부적으로 저장할 수 있게 하고, 결국 이들이 원래 요청 템플릿의 국부적 사본을 갖지 않더라도 최적화된 요청들을 처리할 수 있게 할 것이다.

도 26은 트랜지트 서비스 계층이 템플릿 관련 기능을 지원하지 않을 때 멀티-홉 서비스 계층 통신들을 위해 요청 템플릿들을 이용하기 위한 방법을 도시한다. 단계 1에서, 요청자는 최적화된 요청을 트랜지트 서비스 계층에 전송한다. 이 메시지는 요청자가 최적화된 요청을 생성하는데 이용한 요청 템플릿의 식별자를 나타내는 RQTID를 포함한다. 요청자는 또한 단계 2에서 서비스 계층에게 그 요청을 다른 서비스 계층에 자동으로 전달하도록 지시하기 위해 이 메시지에 새로운 표시자를 포함할 수 있다.

단계 2에서, 트랜지트 서비스 계층은 단순히 최적화된 요청을 목적지 서비스 계층에 전달한다.

단계 3에서, 트랜지트 서비스 계층은 최적화된 요청을 목적지 서비스 계층에 전송한다.

단계 4에서, 목적지 서비스 계층은 최적화된 요청을 수신하고 RQTID를 이용하여 대응하는 요청 템플릿을 찾는다. 그 후, 목적지 서비스 계층은 요청 템플릿에 기반하여 최적화된 요청을 처리하고 정규 응답을 생성한다.

단계 5에서, 목적지 서비스 계층은 전송 서비스 계층에 정규 응답을 다시 전송한다.

단계 6에서, 트랜지트 서비스 계층은 정규 응답을 수신하고, 단계 7에서, 트랜지트 서비스 계층은 정규 응답을 요청자에게 전달한다.

도 27은 목적지 서비스 계층이 템플릿 관련 기능을 지원하지 않을 때 멀티-홉 서비스 계층 통신들에서 요청 템플릿들을 이용하기 위한 방법을 도시한다. 단계 1에서, 요청자는 최적화된 요청을 트랜지트 서비스 계층에 전송한다. 이 메시지는 요청자가 최적화된 요청을 생성하는데 이용한 요청 템플릿의 식별자를 나타내는 RQTID를 포함한다. 요청자는 또한 단계 2에서 서비스 계층에게 이 최적화된 요청을 다른 서비스 계층으로 전달하기 전에 이를 처리하도록 지시하기 위해 이 메시지에 새로운 표시자를 포함할 수 있다.

단계 2에서, 트랜지트 서비스 계층은 RQTID에 기반하여 대응하는 요청 템플릿을 찾는다. 그 다음, 트랜지트 서비스 계층은 요청 템플릿을 이용하여 최적화된 요청을 정규 요청으로 변환한다(즉, 요청 템플릿에 포함된 요청 파라미터들을 최적화된 요청에 복사하고 최적화된 요청으로부터 RQTID를 제거한다).

단계 3에서, 트랜지트 서비스 계층은 정규 요청을 목적지 서비스 계층에 전송한다.

단계 4에서, 목적지 서비스 계층은 정규 요청을 처리하고, 트랜지트 서비스 계층에 정규 응답을 다시 전송한다.

단계 5에서, 트랜지트 서비스 계층은 정규 응답을 수신하고, 단계 6에서, 트랜지트 서비스 계층은 정규 응답을 요청자에게 전달한다.

도 28은 트랜지트 서비스 계층과 목적지 서비스 계층 둘 다가 템플릿 관련 기능을 지원할 때 멀티-홉 서비스 계층 통신들에서 요청 템플릿들을 이용하기 위한 방법을 도시한다. 단계 1에서, 요청자는 최적화된 요청을 트랜지트 서비스 계층에 전송한다. 이 메시지는 요청자가 최적화된 요청을 생성하는데 이용한 요청 템플릿의 식별자를 나타내는 RQTID1을 포함한다. 요청자는 또한 단계 2에서 서비스 계층에게 이 최적화된 요청을 다른 서비스 계층으로 전달하기 전에 이를 처리하도록 지시하기 위해 이 메시지에 새로운 표시자를 포함할 수 있다.

단계 2에서, 트랜지트 서비스 계층은 RQTID1에 기반하여 대응하는 요청 템플릿을 찾는다. 그 다음, 트랜지트 서비스 계층은 요청 템플릿을 이용하여 최적화된 요청을 정규 요청으로 변환한다(즉, 요청 템플릿에 포함된 요청 파라미터들을 최적화된 요청에 복사하고 최적화된 요청으로부터 RQTID1을 제거한다).

단계 3에서, 트랜지트 서비스 계층은 RQTID2에 의해 표시된 바와 같은 다른 요청 템플릿을 이용하여 단계 2에서의 정규 요청을 최적화된 요청으로 변환한다(즉, 정규 요청으로부터 RQTID2에 의해 표시된 바와 같이 요청 템플릿에 포함된 요청 파라미터들을 제거하고, 정규 요청에 RQTID2를 삽입한다).

단계 4에서, 트랜지트 서비스 계층은 최적화된 요청을 목적지 서비스 계층에 전송한다.

단계 5에서, 목적지 서비스 계층은 최적화된 요청을 수신하고 RQTID2를 이용하여 대응하는 요청 템플릿을 찾는다. 그 후, 목적지 서비스 계층은 요청 템플릿에 기반하여 최적화된 요청을 처리하고 정규 응답을 생성한다.

단계 6에서, 목적지 서비스 계층은 정규 응답을 트랜지트 서비스 계층에 전송한다.

단계 7에서, 트랜지트 서비스 계층은 정규 응답을 수신하고, 단계 8에서, 트랜지트 서비스 계층은 정규 응답을 요청자에게 전달한다.

도 29는 요청자가 템플릿 관련 기능을 지원하지 않을 때 멀티-홉 서비스 계층 통신들에서 요청 템플릿들을 이용하기 위한 방법을 도시한다. 단계 1에서, 요청자는 정규 요청을 트랜지트 서비스 계층에 전송한다. 요청자는 또한 단계 2에서 서비스 계층에게 이 최적화된 요청을 다른 서비스 계층으로 전달하기 전에 이를 처리하도록 지시하기 위해 이 메시지에 새로운 표시자를 포함할 수 있다.

단계 2에서, 트랜지트 서비스 계층은 RQTID에 의해 표시된 바와 같은 요청 템플릿을 이용하여 정규 요청을 최적화된 요청으로 변환한다(즉, 정규 요청으로부터 RQTID에 의해 표시된 바와 같이 요청 템플릿에 포함된 요청 파라미터들을 제거하고, 정규 요청에 RQTID를 삽입한다).

단계 5에서, 목적지 서비스 계층은 정규 응답을 트랜지트 서비스 계층에 전송한다.

다른 양태에서, 요청자 또는 서비스 계층은 하나 이상의 메시지 템플릿(메시지 템플릿 정책들로도 지칭됨)에 대한 특정 적용가능성 정책들을 명시할 수 있다. 메시지 템플릿 정책이 복수의 템플릿에 적용될 수 있고; 또한, 템플릿의 적용가능성이 복수의 메시지 템플릿 정책에 의해 제약되거나 정의될 수 있다. 서비스 계층은 메시지 템플릿 정책들을 이용하여 어느 요청자에 대해 템플릿을 적용할지 여부/언제 적용할지를 결정할 수 있다. 메시지 템플릿 정책들은 템플릿의 일부로서 또는 템플릿의 외부에 있는 별개의 정보 객체 또는 리소스로서 정의될 수 있고, 후자의 경우에, 템플릿과 대응하는 메시지 템플릿 정책들 사이의 연관은 서비스 계층 또는 요청자에 의해 확립될 것이다. 이와 같이, 요청자는, 서비스 계층이 요청자에 대해 설정된 메시지 템플릿 정책들에 따라 적절한 템플릿을 자동으로 찾거나 식별할 수 있기 때문에, 템플릿 식별자를 명시적으로 표시하지 않고 최적화된 요청들을 생성할 수 있다. 예를 들어, 요청자는 서비스 계층에게 명시된 템플릿을 모든 그 요청들에 적용할 것을 지시하는 메시지 템플릿 정책을 서비스 계층에 명시할 수 있다.

도 30은 메시지 템플릿 정책을 생성하기 위한 방법을 도시한다. 단계 1에서, 요청자는 메시지 템플릿 정책을 생성하라고 서비스 계층에게 지시하는 메시지 템플릿 정책 생성 요청을 서비스에 전송한다. 이 메시지는 다음과 같은 정보를 포함할 수 있다:

(a) policyType: 생성될 이러한 정책이 메시지 템플릿에 대한 것임을 나타낸다.

(b) policyElement: 이것은 정책들이 무엇을 정의하는지, 허용하는지, 제한하는지 등을 기술한다. 정책은 복수의 policyElements로 구성될 수 있으며, 이는 합집합 및/또는 교집합 동작에서 함께 전체 정책을 정의한다. policyElement는 다음의 조건들에 기반하거나 이들을 기술할 수 있다:

ㆍ 서비스 계층에 의해 국부적으로 호스팅되는 리소스들을 타겟으로 하는 요청들은 메시지 템플릿을 이용할 수 있다.

ㆍ 원격 서비스 계층 상에서 호스팅되는 리소스들을 타겟으로 하는 요청들은 메시지 템플릿을 이용할 수 있다.

ㆍ 특정 유형의 리소스들을 타겟으로 하는 요청들은 메시지 템플릿을 이용할 수 있다.

ㆍ 서비스 계층에 대한 등록자들인 요청자들로부터의 요청들은 메시지 템플릿을 이용할 수 있다.

ㆍ 특정 시간 윈도우에서 발행된 요청들은 메시지 템플릿을 이용할 수 있다.

ㆍ 특정 위치들로부터 발행된 요청들은 메시지 템플릿을 이용할 수 있다.

ㆍ 특정 위치들에서의 디바이스들을 타겟으로 하는 요청들은 메시지 템플릿을 이용할 수 있다.

ㆍ 특정 크기 임계치를 초과하는 요청들은 메시지 템플릿을 이용할 수 있다.

ㆍ 특정 임계치를 초과하는 속도로 발행되는 요청들은 메시지 템플릿을 이용할 수 있다.

(c) MTList: 이것은 생성 정책들이 적용될 메시지 템플릿 식별자들의 리스트이다. 이러한 파라미터는 임의적이다. 이 파라미터가 단계 1에 포함되지 않으면, 생성 정책들이 적용될 수 있는 메시지 템플릿들은 계류 중이고, 도 31의 절차는 하나 이상의 메시지 템플릿을 생성 정책들과 연관시키는데 이용될 수 있다.

단계 2에서, 단계 1에 포함된 정보에 따라, 서비스 계층은 대응하는 메시지 템플릿 정책들을 생성한다. 대안적으로, 요청자로부터의 요청 없이, 서비스 계층 자체는 사전에 메시지 템플릿 정책을 생성하고 이를 임의의 기존의 메시지 템플릿과 연관시킬 수 있다. MTList가 단계 1에 포함된다면, 서비스 계층은, 예를 들어, 이들을 방금 생성된 메시지 템플릿 정책과 연관시킴으로써, MTList에 포함된 이들 메시지 템플릿들을 업데이트할 필요가 있다.

단계 3에서, 서비스 계층은 메시지 템플릿이 성공적으로 생성되었는지 및/또는 MTList 내의 명시된 메시지 템플릿과의 연관이 성공적이었는지를 나타내기 위해 메시지 템플릿 정책 생성 응답을 요청자에게 전송한다. MTList가 단계 1에 포함되지 않으면, 요청자(또는 서비스 계층)는 메시지 템플릿을 생성하려고 개시할 때, 기존의 메시지 템플릿 정책을 표시하고 이를 생성될 메시지 템플릿과 연관시킬 수 있다는 점에 유의한다.

도 31은 메시지 템플릿을 메시지 템플릿 정책들과 연관시키거나 그 반대의 경우의 방법을 도시한다. 단계 1에서, 요청자는 메시지 템플릿 정책 연관 요청을 서비스 계층에 전송한다. 이 메시지는 다음의 2개의 파라미터를 포함할 필요가 있다:

ㆍ MTPList: MTList에 포함된 바와 같이 메시지 템플릿 각각에 함께 적용될 메시지 템플릿 정책 식별자들의 리스트이다.

ㆍ MTList: 메시지 템플릿들의 리스트이다. 각각의 템플릿의 적용가능성은 MTPList에 포함된 바와 같이 모든 정책들에 의해 기술된다.

단계 2에서, 서비스 계층은 MTPList 내의 모든 정책들을 MTList 내의 각각의 템플릿과 연관시킨다. 서비스 계층은 요청자로부터 임의의 요청을 수신하지 않고 특정 정책들을 기존의 메시지 템플릿과 사전에 연관시킬 수 있다는 점에 유의하고; 이 경우, 단계 1은 필요하지 않다.

단계 3에서, 서비스 계층은 단계 1에서의 요청이 성공적으로 처리되었는지를 나타내기 위해 메시지 템플릿 정책 연관 응답을 요청자에게 전송한다.

도 32는 기존의 메시지 템플릿 정책을 검색/업데이트/삭제하기 위한 방법을 도시한다. 단계 1에서, 요청자는 기존의 메시지 템플릿 정책을 검색, 업데이트 또는 삭제하라는 요청을 서비스 계층에 전송한다. 이 메시지는 동작될 기존의 메시지 템플릿 정책의 식별자(즉, MTPID)를 포함한다.

단계 2에서, 서비스 계층은 단계 1로부터의 요청을 처리한다. 단계 1이 기존의 메시지 템플릿 정책을 삭제하도록 요청하고, 그 정책이 이미 하나 또는 복수의 메시지 템플릿과 연관되었다면, 서비스 계층은 이들 메시지 템플릿들을 업데이트하고 이들을 삭제되는 정책과 연관해제할 수 있다.

단계 3에서, 서비스 계층은 요청자에게 응답을 전송한다. 단계 1이 기존의 메시지 템플릿 정책을 검색하도록 요청하는 경우, 이 메시지는 그 표현을 포함한다.

전술한 메시지 템플릿 관리 및 이용의 다양한 양태들은, 일 실시예에서, oneM2M 기능 아키텍처에서 새로운 메시지 템플릿 관리(MTM) CSF로서 구현될 수 있다. 시간 관련 oneM2M 요청 파라미터들(예를 들어, 요청 만료 시간, 결과 만료 시간, 동작 실행 시간, 결과 지속성 등)은 상대 값들이 상이한 요청 메시지들에 대해 동일하게 유지될 수 있으므로 요청 템플릿에서 그 상대 값들을 포함할 것이다. 이 MTM CSF는 CSE에 존재하고 그 서비스들을 다른 CSE들 및/또는 AE들에 노출시킬 수 있다. MTM CSF는 전술한 양태들에 대응하는 이하의 기능들을 갖는다.

ㆍ MTM CSF는 다른 호스팅 CSE들로부터 요청들을 수신하고 이들을 분석하는 것에 의해 메시지 템플릿들(즉, <messageTemplate>)을 자동으로 생성할 수 있다.

ㆍ MTM CSF는 <messageTemplate> 리소스들을 다른 AE들/CSE들에 노출시킨다. 다시 말해서, AE/CSE는 MTM CSF로부터 <messageTemplate> 리소스를 생성/검색/업데이트/삭제할 수 있다. <messageTemplate> 리소스가 생성된 후에, AE(또는 CSE)는 그 표현들을 검색하고, <messageTemplate>가 요청 템플릿이면 차례로 이를 이용하여 최적화된 요청들을 생성할 수 있다.

메시지 템플릿 관리의 다양한 양태들과 관련하여 전술한 기능 엔티티들은 다음과 같이 oneM2M 엔티티들에 매핑할 수 있다: 1) 서비스 계층은 oneM2M CSE에 매핑하고; 2) 요청자는 oneM2M AE 또는 CSE에 매핑한다. 예를 들어, IN-AE1은 IN-CSE1에서 <messageTemplate1>을 생성할 수 있다. 나중에, IN-AE1은 <messageTemplate1>에 기반하여 최적화된 요청들을 생성할 수 있고, IN-CSE1에 최적화된 요청을 전송할 수 있다. 그 다음, IN-CSE1은 <messageTemplate1>을 이용하여 수신된 최적화된 요청을 처리한다. 또한, IN-CSE1에 대한 최적화된 요청들을 생성하기 위해 IN-AE2와 같은 다른 애플리케이션들에 의해 <messageTemplate1>이 이용될 수 있다.

여러 새로운 공통 속성들이 표 3에서 제안된다.

<표 3>

표 4는 검색, 업데이트 및 삭제 동작들에 대한 새로운 요청 메시지 파라미터를 열거하며, 이는 전술한 메시지 템플릿 관리 및 이용 기술들에 기반하여 더 효율적인 RESTful 동작을 지원하는데 이용될 수 있다.

<표 4>

AE 또는 CSE 등록을 위해 응답 메시지에 포함될 수 있는 새로운 응답 파라미터(MTList)가 도입될 수 있다. 예를 들어, AE/CSE가 호스팅 CSE에 등록할 때, 호스팅 CSE는 그 CSEBase 하에서 <AE> 또는 <remoteCSE> 자식 리소스를 생성할 것이고; 섹션 5.3에서 제안된 메시지 템플릿 할당을 지원하기 위해, 호스팅 CSE는 등록된 AE/CSE에 대한 적절한 메시지 템플릿들을 선택하고 응답 메시지에서 그 식별자들(즉, MTList 파라미터)을 포함한다. 또한, 또는 대안적으로, 호스팅 CSE는 MTList에 포함된 임의의 템플릿이 <AE> 또는 <remoteCSE>에 적용가능하고 이에 의해 이용될 수 있다는 것을 나타내기 위해 <AE> 또는 <remoteCSE> 리소스에 대한 새로운 속성으로서 MTList를 추가할 수 있다.

RSTCI 및 RSTID는 CSE로부터 AE/CSE로의 임의의 응답 메시지에 포함될 수 있는 2개의 새로운 응답 파라미터로서 도입될 수 있다. RSTCI는 새로운 응답 템플릿을 생성하도록 응답 메시지의 수신자에게 알려주고, 이 파라미터는 응답 템플릿을 생성하기 위해 모든 요구된 정보를 포함하고; 생성된 응답 메시지의 식별자는 RSTID로 설정될 것이다.

MTList는 <CSEBase>, <node>, <AE> 및 <remoteCSE>와 같은 기존의 oneM2M 리소스들에 대한 새로운 속성으로서 도입될 수 있다. MTList는 애플리케이션(<AE> 및/또는 <node>로 표시됨) 또는 서비스 계층(<CSEBase> 및/또는 <remoteCSE>로 표시됨)에 적용가능하고 이에 의해 이용될 수 있는 메시지 템플릿 식별자들의 리스트를 포함한다. 이 속성은 기입가능하다.

messageTemplate는 메시지 템플릿을 나타내는데 이용될 수 있다. AE/CSE는 messageTemplate 리소스를 발견 및 검색할 수 있고; 이어서 이것은 요청 메시지 내의 그 식별자를 포함할 수 있고, 각각의 개별 요청 파라미터를 포함할 필요가 없다. 이와 같이, 요청 메시지 크기가 감소될 것이고, 차례로 메시지 오버헤드가 크게 감소될 수 있다.

도 33은 messageTemplate 리소스에 대한 구조의 일 예를 도시한다. <messageTemplate> 리소스는 표 5에 명시된 자식 리소스들을 포함할 수 있다.

<표 5>

<messageTemplate> 리소스는 표 6에 명시된 속성들을 포함할 수 있다.

<표 6>

도 34는 <messageTemplate> 리소스를 동작시키는 방법(예를 들어, <messageTemplate> 리소스의 생성/검색/업데이트/삭제)을 도시한다. 발신자는 CSE 또는 AE일 수 있는 반면, 수신자는 CSE이다. 상세한 설명들이 표 7, 표 8, 표 9, 및 표 10에 각각 주어져 있다.

생성 <messageTemplate> 절차는 표 7에 기술된 바와 같이 <messageTemplate> 리소스를 생성하는데 이용될 수 있다.

<표 7>

검색 <messageTemplate> 절차는 표 8에 기술된 바와 같이 기존의 <messageTemplate> 리소스의 속성들을 검색하는데 이용될 수 있다.

<표 8>

업데이트 <messageTemplate> 절차는, 예를 들어 그 listOfAllowedRequestors 속성에 대한 업데이트와 같이, 표 9에 기술된 대로 기존의 <messageTemplate> 리소스를 업데이트하는데 이용될 수 있다.

<표 9>

삭제 <messageTemplate> 절차는 표 10에 기술된 바와 같이 기존의 <messageTemplate> 리소스를 삭제하는데 이용될 수 있다.

<표 10>

새로운 messageTemplatePolicy 리소스는 메시지 템플릿을 나타내는데 이용될 수 있다. AE/CSE는 messageTemplatePolicy 리소스를 발견 및 검색할 수 있고; 이후 이를 하나 이상의 메시지 템플릿과 연관시킬 수 있다. 일 실시예에 따른 messageTemplatePolicy 리소스의 구조가 도 35에 도시되어 있다.

<messageTemplatePolicy> 리소스는 표 11에 명시된 자식 리소스들을 포함할 수 있다.

<표 11>

<messageTemplatePolicy> 리소스는 표 12에 명시된 속성들을 포함할 수 있다.

<표 12>

도 36은 <messageTemplatePolicy> 리소스를 동작시키는 방법(예를 들어, <messageTemplatePolicy> 리소스의 생성/검색/업데이트/삭제)을 도시한다. 발신자는 CSE 또는 AE일 수 있는 반면, 수신자는 CSE이다. 상세한 설명들이 표 13, 표 14, 표 15, 및 표 16에 각각 주어져 있다.

생성 <messageTemplatePolicy> 절차는 표 13에 기술된 바와 같이 <messageTemplatePolicy> 리소스를 생성하는데 이용될 수 있다.

<표 13>

검색 <messageTemplatePolicy> 절차는 표 14에 기술된 바와 같이 기존의 <messageTemplatePolicy> 리소스의 속성들을 검색하는데 이용될 수 있다.

<표 14>

업데이트 <messageTemplatePolicy> 절차는, 예를 들어 그 templatePolicyElement 속성에 대한 업데이트와 같이, 표 15에 기술된 대로 기존의 <messageTemplatePolicy> 리소스를 업데이트하는데 이용될 수 있다.

<표 15>

삭제 <messageTemplatePolicy> 절차는 표 16에 기술된 바와 같이 기존의 <messageTemplatePolicy> 리소스를 삭제하는데 이용될 수 있다.

<표 16>

도 37은 서비스 계층(예를 들어, oneM2M CSE)에서의 메시지 템플릿 관리를 위한 사용자 인터페이스의 일 실시예를 도시한다. 이 인터페이스는 사용자 또는 애플리케이션이 CSE를 통해 다음의 작업들을 개시하고 수행하는 것을 허용한다:

ㆍ 새로운 메시지 템플릿의 생성,

ㆍ 메시지 템플릿들의 검색,

ㆍ 하나 이상의 메시지 템플릿의 표시,

ㆍ 하나 이상의 메시지 템플릿의 업데이트, 및

ㆍ 하나 이상의 메시지 템플릿의 삭제.

도 38은 서비스 계층(예를 들어, oneM2M CSE)에서의 메시지 템플릿 정책 관리를 위한 사용자 인터페이스를 도시한다. 이 인터페이스는 사용자 또는 애플리케이션이 CSE를 통해 다음의 작업들을 개시하고 수행하는 것을 허용한다:

ㆍ 새로운 메시지 템플릿 정책의 생성,

ㆍ 메시지 템플릿 정책들의 검색,

ㆍ 하나 이상의 메시지 템플릿 정책의 표시,

ㆍ 하나 이상의 메시지 템플릿 정책의 업데이트, 및

ㆍ 하나 이상의 메시지 템플릿 정책의 삭제.

전술한 메시지 템플릿 관리 및 이용의 다양한 양태들은, 일 실시예에서, W3C(World Wide Web Consortium) WoT 아키텍처에서의 사물 설명(TD)의 일부로서 구현될 수 있고, 여기서 WoT 서비언트는 클라이언트 및 서버 기능들 모두를 지원하기 위해 디바이스, 게이트웨이, 및/또는 서버 내의 논리 모듈로서 정의된다. 각각의 WoT 서비언트는 WoT 서비언트의 리소스가 어떻게 액세스되어야 하는지를 설명하는 TD를 갖는다. 이전 스마트 계측기 이용 사례를 예로서 취하면, 서버는 WoT 서비언트를 갖거나 이로써 구현될 것이다. 메시지 템플릿 관리를 지원하기 위해, 일 실시예에서, 다음 절차들이 제안된다: 1) 서버의 WoT 서비언트가 그 TD에서 요청 템플릿을 기술하고 이를 포함한다. 이 템플릿은 위에서 주어진 예시적인 XML 포맷 템플릿과 동일할 수 있거나 더 많은 요청 파라미터들을 포함할 수 있다. TD에서, WoT 서비언트는 또한 이 템플릿이 스마트 계측기(또는 더 많은 스마트 계측기들)에만 적용가능하다는 것을 명시할 수 있고; 2) WoT 클라이언트로서 스마트 계측기는 WoT 서비언트의 TD가 저장되어 있는 WoT 서비언트 또는 다른 위치들로부터 TD를 발견 및 검색하고; 3) 스마트 계측기는 TD로부터 템플릿을 추상화하고 그 템플릿에 포함된 각각의 파라미터의 의미를 이해하고; 4) 스마트 계측기는 템플릿을 이용하여 템플릿 식별자를 포함하는 (예를 들어, 그 계측기 판독을 서버에 보고하기 위한) 최적화된 요청 메시지를 생성하고; 5) 스마트 계측기는 최적화된 요청을 WoT 서비언트(즉, 서버)에 전송하고; 6) WoT 서비언트는 최적화된 요청을 수신하고, (최적화된 요청에 포함된 템플릿 식별자로 표시된 바와 같은) 대응하는 템플릿을 이용하여 최적화된 요청을 처리하고; 7) WoT 서비언트는 스마트 계측기에게 응답을 전송한다. 대안적으로, 스마트 계측기(또는 다른 계측기들, WoT 클라이언트들, WoT 서비언트들 등)는 그 TD를 업데이트함으로써 템플릿을 능동적으로 생성하고/하거나 이를 WoT 서비언트의 TD에 삽입할 수 있다.

도 39a는 하나 이상의 개시된 실시예가 구현될 수 있는 예시적인 기기간(M2M), 사물 인터넷(IoT), 또는 사물 웹(WoT) 통신 시스템(10)의 도면이다. 일반적으로, M2M 기술들은 IoT/WoT에 대한 구성 블록들을 제공하고, 임의의 M2M 디바이스, M2M 게이트웨이, M2M 서버, 또는 M2M 서비스 플랫폼은 IoT/WoT의 구성요소 또는 장치는 물론 IoT/WoT 서비스 계층 등일 수 있다. 도 5 내지 도 8, 도 10, 도 11, 도 13 내지 도 32, 도 34 및 도 36 중 임의의 것에 도시된 엔티티들 중 임의의 것은, 도 39a 내지 도 39d에 도시된 것들과 같은, 통신 시스템의 네트워크 장치를 포함할 수 있다.

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

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

도 39a에 도시된 바와 같이, 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 애플리케이션(20)으로부터 수신될 수 있다. M2M 디바이스들(18) 및 M2M 게이트웨이들(14)은, 예를 들어, 셀룰러, WLAN, WPAN(예컨대, 지그비(Zigbee), 6LoWPAN, 블루투스(Bluetooth)), 직접 무선 링크, 및 유선을 포함하는 다양한 네트워크들을 통해 통신할 수 있다. 예시적인 M2M 디바이스들은 태블릿들, 스마트폰들, 의료 디바이스들, 온도 및 날씨 모니터들, 커넥티드 카들, 스마트 계측기들, 게임 콘솔들, PDA들, 건강 및 피트니스 모니터들, 조명들, 서모스탯들, 가전기기들, 차고 문들 및 다른 액추에이터 기반 디바이스들, 보안 디바이스들, 및 스마트 콘센트들을 포함하지만, 이들로 제한되지는 않는다.

도 39b를 참조하면, 필드 도메인에서의 도시된 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')은, 서버들, 컴퓨터들, 디바이스들, 가상 머신들(예컨대, 클라우드 컴퓨팅/저장소 팜들 등) 등을 포함할 수 있는, 네트워크의 하나 이상의 네트워크 장치에 의해 구현될 수 있다.

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

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

일반적으로, 도 39b에 도시된 서비스 계층들(22 및 22') 등의 서비스 계층은, 애플리케이션 프로그래밍 인터페이스들(API들) 및 기본 네트워킹 인터페이스들의 세트를 통해 추가 가치 서비스 능력들을 지원하는 소프트웨어 미들웨어 계층을 정의한다. ETSI M2M과 oneM2M 아키텍처들 양쪽 모두는 서비스 계층을 정의한다. ETSI M2M의 서비스 계층은 SCL(Service Capability Layer)이라고 지칭된다. SCL은 ETSI M2M 아키텍처의 다양하고 상이한 노드들에서 구현될 수 있다. 예를 들어, 서비스 계층의 인스턴스는 M2M 디바이스(여기서 디바이스 SCL(DSCL)이라고 지칭됨), 게이트웨이(여기서 게이트웨이 SCL(GSCL)이라고 지칭됨), 및/또는 네트워크 노드(여기서 네트워크 SCL(NSCL)이라고 지칭됨) 내에 구현될 수 있다. oneM2M 서비스 계층은 CSF들(즉, 서비스 능력들)의 세트를 지원한다. 하나 이상의 특정한 유형의 CSF들의 세트의 인스턴스화는 상이한 유형들의 네트워크 노드들(예를 들어, 인프라스트럭처 노드, 중간 노드, 애플리케이션 특정 노드) 상에서 호스팅될 수 있는 공통 서비스 엔티티(CSE)라고 지칭된다. 3GPP(Third Generation Partnership Project)는 또한 MTC(machine-type communications)에 대한 아키텍처도 정의하였다. 그 아키텍처에서, 서비스 계층, 및 이것이 제공하는 서비스 능력들은 서비스 능력 서버(SCS)의 일부로서 구현된다. ETSI M2M 아키텍처의 DSCL, GSCL, 또는 NSCL에, 3GPP MTC 아키텍처의 SCS에, oneM2M 아키텍처의 CSF 또는 CSE에, 또는 네트워크의 어떤 다른 노드에 구현되든 간에, 서비스 계층의 인스턴스는, 서버들, 컴퓨터들, 및 다른 컴퓨팅 디바이스들 또는 노드들을 포함한, 네트워크 내의 하나 이상의 독립형 노드 상에서 실행되는 논리 엔티티(예컨대, 소프트웨어, 컴퓨터 실행가능한 명령어들 등)로서 또는 하나 이상의 기존의 노드의 일부로서 구현될 수 있다. 예로서, 서비스 계층 또는 그 구성요소의 인스턴스는 아래에 설명되는 도 39c 또는 도 39d에 도시되는 일반적인 아키텍처를 갖는 네트워크 장치(예를 들어, 서버, 컴퓨터, 게이트웨이, 디바이스 등) 상에서 실행되는 소프트웨어의 형태로 구현될 수 있다.

게다가, 본 명세서에서 설명되는 방법들 및 기능들은 서비스들에 액세스하기 위해 SOA(Service Oriented Architecture) 및/또는 ROA(Resource-Oriented Architecture)를 이용하는 M2M 네트워크의 일부로서 구현될 수 있다.

도 39c는 도 39a 및 도 39b에 도시된 것과 같은 M2M 네트워크 내의 M2M 서버, 게이트웨이, 디바이스, 또는 다른 네트워크 장치로서 동작할 수 있는, 도 5 내지 도 8, 도 10, 도 11, 도 13 내지 도 32, 도 34 및 도 36에 도시된 엔티티들 중 하나와 같은 네트워크 장치의 예시적인 하드웨어/소프트웨어 아키텍처의 블록도이다. 도 39c에 도시된 바와 같이, 네트워크 장치(30)는 프로세서(32), 비이동식 메모리(44), 이동식 메모리(46), 스피커/마이크로폰(38), 키패드(40), 디스플레이, 터치패드, 및/또는 표시기들(42), 전원(48), 전역 포지셔닝 시스템(GPS) 칩셋(50), 및 다른 주변기기들(52)을 포함할 수 있다. 네트워크 장치(30)는 또한 트랜시버(34) 및 전송/수신 요소(36)와 같은 통신 회로를 포함할 수 있다. 네트워크 장치(30)는, 실시예와 일관되면서 전술된 요소들의 임의의 하위조합을 포함할 수 있다는 것을 이해할 것이다. 이 네트워크 장치는, 도 5 내지 도 8, 도 10, 도 11, 도 13 내지 도 32, 도 34 및 도 36과 관련하여 도시되고 설명된 방법 동작들과 같이, 본 명세서에서 설명되는 메시지 템플릿 관리 능력들 및 방법들을 구현하는 장치일 수 있다.

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

도 39c에 도시된 바와 같이, 프로세서(32)는 그 통신 회로(예를 들어, 트랜시버(34) 및 전송/수신 요소(36))에 결합된다. 프로세서(32)는, 컴퓨터 실행가능한 명령어들의 실행을 통해, 네트워크 장치(30)가 접속되는 네트워크를 통해 다른 네트워크 장치들과 통신하게 하기 위해 통신 회로를 제어할 수 있다. 특히, 프로세서(32)는 본 명세서(예컨대, 도 5 내지 도 8, 도 10, 도 11, 도 13 내지 도 32, 도 34 및 도 36)에서 그리고 청구항들에서 설명된 전송 및 수신 단계들을 수행하기 위해 통신 회로를 제어할 수 있다. 도 39c가 프로세서(32)와 트랜시버(34)를 별도의 구성요소들로서 도시하고 있지만, 프로세서(32)와 트랜시버(34)는 전자 패키지 또는 칩 내에 함께 통합될 수 있다는 것을 이해할 것이다.

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

또한, 전송/수신 요소(36)가 도 39c에 단일 요소로서 도시되지만, 네트워크 장치(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(subscriber identity module) 카드, 메모리 스틱, SD(secure digital) 메모리 카드 등을 포함할 수 있다. 다른 실시예들에서, 프로세서(32)는, 서버 또는 홈 컴퓨터 상에서와 같이, 네트워크 장치(30) 상에 물리적으로 위치되지 않은 메모리로부터의 정보에 액세스하고 이에 데이터를 저장할 수 있다. 프로세서(32)는 디스플레이 또는 표시기들(42) 상의 조명 패턴들, 이미지들 또는 색상들을 제어하여 장치의 상태를 반영하거나 장치를 구성하고 특히 네트워크 장치와 통신하는 기본 네트워크들, 애플리케이션들 또는 다른 서비스들을 구성할 수 있다. 일 실시예에서, 디스플레이/표시기들(42)은 도 31에 도시되고 본 명세서에 설명되는 그래픽 사용자 인터페이스를 제시할 수 있다.

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

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

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

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

도 39d는 도 39a 및 도 39b에 도시된 것과 같은 M2M 네트워크 내의 M2M 서버, 게이트웨이, 디바이스, 또는 다른 네트워크 장치로서 동작할 수 있는, 도 5 내지 도 8, 도 10, 도 11, 도 13 내지 도 32, 도 34 및 도 36에 도시되고 본 명세서에서 설명된 엔티티들과 같은 네트워크의 하나 이상의 네트워크 장치를 구현하는데 또한 이용될 수 있는 예시적인 컴퓨팅 시스템(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)은 도 39a 내지 도 39d의 네트워크(12)와 같은 외부 통신 네트워크에 컴퓨팅 시스템(90)을 접속하여, 컴퓨팅 시스템(90)이 네트워크의 다른 장치들과 통신할 수 있게 하는데 이용될 수 있는, 예를 들어 네트워크 어댑터(97)와 같은 통신 회로를 포함할 수 있다. 통신 회로는, 단독으로 또는 CPU(91)와 조합하여, 본 명세서(예를 들어, 도 5 내지 도 8, 도 10, 도 11, 도 13 내지 도 32, 도 34 및 도 36)에서 그리고 청구항들에서 설명된 전송 및 수신 단계들을 수행하는데 이용될 수 있다.

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

다음은 위의 설명에서 나타날 수 있는 서비스 계층 기술들에 관한 약어들의 리스트이다. 달리 명시되지 않는 한, 본 명세서에서 이용되는 약어들은 아래 열거된 대응하는 용어를 지칭한다.

3GPP 3세대 파트너쉽 프로젝트

AE 애플리케이션 엔티티

CSE 공통 서비스 엔티티

CSF 공통 서비스 기능

IoT 사물 인터넷

M2M 기기간

MT 메시지 템플릿

MTCI 메시지 템플릿 생성 표시자

MTID 메시지 템플릿 식별자

MTM 메시지 템플릿 관리

MTP 메시지 템플릿 정책

MTPID 메시지 템플릿 정책 식별자

MTUI 메시지 템플릿 업데이트 표시자

NB-IoT 협대역 IoT

OCF 개방 접속성 파운데이션

REST 리소스 상태 전송

REQT 요청 템플릿

RQTCI 요청 템플릿 생성 표시자

RQTID 요청 템플릿 식별자

RSPT 응답 템플릿

RSTCI 응답 템플릿 생성 표시자

RSTID 응답 템플릿 식별자

UE 사용자 장비

URI 통합 리소스 식별자

본 작성된 설명은 최상의 모드를 포함하는 본 발명을 개시하고, 또한 관련 기술분야의 임의의 통상의 기술자가 임의의 디바이스들 또는 시스템들을 제조하여 이용하고 임의의 통합된 방법들을 수행하는 것을 포함하여 본 발명을 실시할 수 있도록 하기 위해 예들을 이용한다. 본 발명의 특허가능한 범위는 청구항들에 의해 정의되며, 관련 기술분야의 통상의 기술자에게 떠오르는 다른 예들을 포함할 수 있다. 이러한 다른 예들은, 이들이 청구항들의 문자 그대로의 표현과 상이하지 않은 요소들을 가지거나, 또는 이들이 청구항들의 문자 그대로의 표현과 실질적인 차이들이 없는 등가의 요소들을 포함하면, 청구항들의 범위 내에 있는 것으로 의도된다.

Claims

적어도 하나의 프로세서 및 메모리를 포함하는 네트워크 장치로서,
상기 메모리는, 상기 적어도 하나의 프로세서에 의해 실행될 때, 통신 네트워크의 서비스 계층을 구현하고, 상기 서비스 계층으로 하여금,
상기 네트워크 장치의 상기 메모리에, 하나 이상의 메시지 템플릿을 저장하는 것 - 각각의 메시지 템플릿은 상기 통신 네트워크 상의 하나 이상의 디바이스로부터 상기 서비스 계층에 의해 수신될 수 있는 각각의 유형의 메시지와 연관된 파라미터들의 하나 이상의 값을 포함하고, 각각의 메시지 템플릿은 상기 메시지 템플릿을 고유하게 식별하는 연관된 메시지 템플릿 식별자를 가짐 -;
상기 통신 네트워크 상의 디바이스로부터, 정보 및 메시지 템플릿 식별자를 포함하는 메시지를 수신하는 것;
상기 디바이스로부터의 상기 메시지에 응답하여 상기 메모리로부터, 상기 디바이스로부터 수신된 상기 메시지 내의 상기 메시지 템플릿 식별자와 일치하는 연관된 메시지 템플릿 식별자를 갖는 저장된 메시지 템플릿을 검색하는 것;
수신된 메시지 내의 상기 정보를 검색된 메시지 템플릿 내의 파라미터 값들과 결합하여 완전한 메시지를 형성하는 것; 및
상기 완전한 메시지를 처리하는 것
을 포함하는 동작들을 수행하게 하는 실행가능한 명령어들을 저장하는, 네트워크 장치.
제1항에 있어서,
상기 실행가능한 명령어들은 또한 상기 서비스 계층으로 하여금,
새로운 메시지 템플릿을 생성하라는 요청을 수신하는 것 - 상기 요청은 상기 메시지 템플릿이 나타낼 각각의 유형의 메시지와 연관된 파라미터들의 하나 이상의 값을 포함하는 새로운 메시지 템플릿을 생성하라는 것임 -;
상기 새로운 메시지 템플릿을 생성하는 것 - 상기 새로운 메시지 템플릿은 수신된 파라미터 값들을 포함함 -;
상기 새로운 메시지 템플릿과 연관된 식별자를 생성하는 것;
상기 메모리에, 그 식별자와 관련하여 상기 새로운 메시지 템플릿을 저장하는 것; 및
상기 새로운 메시지 템플릿을 생성하라는 상기 요청에 대한 응답을 전송하는 것 - 상기 응답은 상기 새로운 메시지 템플릿과 연관된 상기 식별자를 포함함 -
을 포함하는 동작들을 수행하게 하는, 네트워크 장치.
제2항에 있어서,
상기 새로운 메시지 템플릿을 생성하라는 상기 요청을 수신하는 것 대신에, 상기 서비스 계층은 상기 새로운 메시지 템플릿을 생성하기로 결정하고 상기 새로운 메시지 템플릿에 포함될 파라미터 값들을 결정하는, 네트워크 장치.
제3항에 있어서,
상기 새로운 메시지 템플릿의 생성 결정은 상기 통신 네트워크 상의 디바이스들로부터 상기 서비스 계층에 의해 수신된 메시지들에 기반하는, 네트워크 장치.
제1항에 있어서,
상기 실행가능한 명령어들은 또한 상기 서비스 계층으로 하여금,
응답 메시지 템플릿을 생성하는 것 - 상기 응답 메시지 템플릿은 상기 디바이스로부터 수신된 상기 메시지에 대한 응답과 연관될 파라미터들의 값들을 포함하고, 상기 응답 메시지 템플릿은 연관된 식별자를 가짐 -;
그 연관된 식별자와 함께 상기 응답 메시지 템플릿을 상기 디바이스에 제공하거나 상기 디바이스가 그 연관된 식별자와 함께 상기 응답 메시지 템플릿의 그 자신의 사본을 생성하라고 요청하는 것;
상기 디바이스로부터 수신된 상기 메시지에 응답하여 상기 디바이스에게, 상기 응답 메시지 템플릿과 연관된 식별자를 포함하지만 상기 응답 메시지 템플릿의 상기 파라미터 값들을 포함하지 않는 응답 메시지를 전송하는 것
을 포함하는 동작들을 수행하게 하는, 네트워크 장치.
제1항에 있어서,
상기 실행가능한 명령어들은 또한 상기 서비스 계층으로 하여금,
상기 네트워크 상의 하나 이상의 디바이스의 그룹을 선택하는 것;
요청 메시지들을 상기 서비스 계층에 전송할 때 상기 그룹의 디바이스들에 의해 이용될 저장된 메시지 템플릿 식별자들 중 하나를 상기 디바이스들의 그룹에 할당하는 것; 및
할당된 메시지 템플릿 식별자를 상기 디바이스들의 그룹에 전송하는 것
을 포함하는 동작들을 수행하게 하는, 네트워크 장치.
제1항에 있어서,
상기 디바이스로부터 수신된 상기 메시지는 상기 디바이스에 의해 호스팅되는 애플리케이션으로부터 수신되는, 네트워크 장치.
방법으로서,
통신 네트워크의 서비스 계층 엔티티의 메모리에, 하나 이상의 메시지 템플릿을 저장하는 단계 - 각각의 메시지 템플릿은 상기 통신 네트워크 상의 하나 이상의 디바이스로부터 상기 서비스 계층 엔티티에 의해 수신될 수 있는 각각의 유형의 메시지와 연관된 파라미터들의 하나 이상의 값을 포함하고, 각각의 메시지 템플릿은 상기 메시지 템플릿을 고유하게 식별하는 연관된 메시지 템플릿 식별자를 가짐 -;
상기 서비스 계층 엔티티에 의해, 상기 통신 네트워크 상의 디바이스로부터, 정보 및 메시지 템플릿 식별자를 포함하는 메시지를 수신하는 단계;
상기 디바이스로부터의 상기 메시지에 응답하여 상기 메모리로부터 상기 서비스 계층 엔티티에 의해, 상기 디바이스로부터 수신된 상기 메시지 내의 상기 메시지 템플릿 식별자와 일치하는 연관된 메시지 템플릿 식별자를 갖는 저장된 메시지 템플릿을 검색하는 단계;
상기 서비스 계층 엔티티에 의해, 수신된 메시지 내의 상기 정보를 검색된 메시지 템플릿 내의 파라미터 값들과 결합하여 완전한 메시지를 형성하는 단계; 및
상기 서비스 계층 엔티티에 의해, 상기 완전한 메시지를 처리하는 단계
를 포함하는, 방법.
제8항에 있어서,
상기 서비스 계층 엔티티에 의해, 새로운 메시지 템플릿을 생성하라는 요청을 수신하는 단계 - 상기 요청은 상기 메시지 템플릿이 나타낼 각각의 유형의 메시지와 연관된 파라미터들의 하나 이상의 값을 포함하는 새로운 메시지 템플릿을 생성하라는 것임 -;
상기 서비스 계층 엔티티에 의해, 상기 새로운 메시지 템플릿을 생성하는 단계 - 상기 새로운 메시지 템플릿은 수신된 파라미터 값들을 포함함 -;
상기 서비스 계층 엔티티에 의해, 상기 새로운 메시지 템플릿과 연관된 식별자를 생성하는 단계;
상기 서비스 계층 엔티티에 의해 상기 메모리에, 그 식별자와 관련하여 상기 새로운 메시지 템플릿을 저장하는 단계; 및
상기 서비스 계층 엔티티에 의해, 상기 새로운 메시지 템플릿을 생성하라는 상기 요청에 대한 응답을 전송하는 단계 - 상기 응답은 상기 새로운 메시지 템플릿과 연관된 상기 식별자를 포함함 -
를 더 포함하는, 방법.
제9항에 있어서,
상기 새로운 메시지 템플릿을 생성하라는 상기 요청을 수신하는 단계 대신에, 상기 서비스 계층 엔티티에 의해, 상기 새로운 메시지 템플릿을 생성하기로 결정하고 상기 새로운 메시지 템플릿에 포함될 파라미터 값들을 결정하는 단계를 더 포함하는, 방법.
제10항에 있어서,
상기 새로운 메시지 템플릿의 생성 결정은 상기 통신 네트워크 상의 디바이스들로부터 상기 서비스 계층 엔티티에 의해 수신된 메시지들에 기반하는, 방법.
제8항에 있어서,
상기 서비스 계층 엔티티에 의해, 응답 메시지 템플릿을 생성하는 단계 - 상기 응답 메시지 템플릿은 상기 디바이스로부터 수신된 상기 메시지에 대한 응답과 연관될 파라미터들의 값들을 포함하고, 상기 응답 메시지 템플릿은 연관된 식별자를 가짐 -;
상기 서비스 계층 엔티티에 의해, 그 연관된 식별자와 함께 상기 응답 메시지 템플릿을 상기 디바이스에 제공하거나 상기 디바이스가 그 연관된 식별자와 함께 상기 응답 메시지 템플릿의 그 자신의 사본을 생성하라고 요청하는 단계;
상기 서비스 계층 엔티티에 의해 상기 디바이스로부터 수신된 상기 메시지에 응답하여 상기 디바이스에게, 상기 응답 메시지 템플릿과 연관된 식별자를 포함하지만 상기 응답 메시지 템플릿의 상기 파라미터 값들을 포함하지 않는 응답 메시지를 전송하는 단계
를 더 포함하는, 방법.
제8항에 있어서,
상기 서비스 계층 엔티티에 의해, 상기 네트워크 상의 하나 이상의 디바이스의 그룹을 선택하는 단계;
상기 서비스 계층 엔티티에 의해, 요청 메시지들을 상기 서비스 계층 엔티티에 전송할 때 상기 그룹의 디바이스들에 의해 이용될 저장된 메시지 템플릿 식별자들 중 하나를 상기 디바이스들의 그룹에 할당하는 단계; 및
상기 서비스 계층 엔티티에 의해, 할당된 메시지 템플릿 식별자를 상기 디바이스들의 그룹에 전송하는 단계
를 더 포함하는, 방법.
제8항에 있어서,
상기 디바이스로부터 수신된 상기 메시지는 상기 디바이스에 의해 호스팅되는 애플리케이션으로부터 수신되는, 방법.
통신 네트워크에 결합되고 적어도 하나의 프로세서 및 메모리를 포함하는 디바이스로서,
상기 메모리는 상기 적어도 하나의 프로세서에 의해 실행될 때, 상기 디바이스로 하여금,
상기 통신 네트워크의 서비스 계층에 저장된 메시지 템플릿의 식별자 및 정보를 포함하는 요청 메시지를 생성하는 것 - 상기 저장된 메시지 템플릿은 상기 요청 메시지와 연관된 공통 파라미터들의 값들을 포함함 -; 및
상기 요청 메시지를 상기 서비스 계층에 전송하는 것 - 상기 요청 메시지는 상기 정보 및 상기 메시지 템플릿 식별자를 포함하지만, 상기 서비스 계층에 저장된 상기 메시지 템플릿의 공통 파라미터들의 값들을 포함하지 않음 -
을 포함하는 동작들을 수행하게 하는 실행가능한 명령어들을 저장하는, 디바이스.
제15항에 있어서,
상기 실행가능한 명령어들은 또한 상기 디바이스로 하여금,
새로운 메시지 템플릿을 생성하라는 요청을 상기 서비스 계층에 전송하는 것 - 상기 요청은 상기 디바이스가 상기 서비스 계층에 전송할 수 있는 요청 메시지의 유형과 공통으로 연관된 하나 이상의 파라미터의 값을 포함함 -;
상기 서비스 계층으로부터, 상기 디바이스로부터의 상기 요청에 응답하여 상기 서비스 계층에 의해 생성된 새로운 메시지 템플릿과 연관된 식별자를 수신하는 것; 및 그 후,
그 유형의 메시지들을 상기 서비스 계층에 전송할 때 상기 새로운 메시지 템플릿 식별자를 이용하는 것
을 포함하는 동작들을 수행하게 하는, 디바이스.
제16항에 있어서,
상기 새로운 메시지 템플릿을 생성하라는 상기 요청은 생성될 상기 새로운 메시지 템플릿의 유형의 식별자를 포함하는, 디바이스.
제17항에 있어서,
상기 새로운 메시지 템플릿을 생성하라는 상기 요청은 상기 새로운 메시지 템플릿에 포함될 상기 하나 이상의 파라미터 및 이들 파라미터들의 값들의 리스트를 더 포함하는, 디바이스.
제18항에 있어서,
상기 새로운 메시지 템플릿을 생성하라는 상기 요청은 상기 새로운 메시지 템플릿을 이용하도록 허용되는 다른 디바이스들의 리스트를 더 포함하는, 디바이스.
제20항에 있어서,
상기 새로운 메시지 템플릿을 생성하라는 상기 요청은 복수의 새로운 메시지 템플릿을 생성하라는 요청을 포함하는, 디바이스.