KR101793204B1

KR101793204B1 - M2m 네트워크에 있어서의 리소스 및 속성 관리

Info

Publication number: KR101793204B1
Application number: KR1020167027775A
Authority: KR
Inventors: 라제쉬 발라
Original assignee: 지티이 코포레이션
Priority date: 2014-03-18
Filing date: 2015-03-18
Publication date: 2017-11-02
Also published as: JP6514315B2; US10616048B2; EP3120499A1; KR20160130306A; CN106537841B; EP3120499A4; WO2015143086A1; JP2017515430A; US20170099562A1; CN106537841A; EP3120499B1

Abstract

M2M(Machine to Machine) 시스템에 있어서, 리소스 관리는, M2M 디바이스들 그 자체를 대신하여, 또는 다른 디바이스를 대신하여, 리소스를 생성하고, 리소스를 공표하고, 공표된 리소스로부터 정보를 검색하고, 공표된 리소스를 삭제함에 의해 M2M 디바이스들에 의해 실행된다. 일부 실시 예들에 있어서, 리소스 관리 프로토콜은, 차일드 리소스 속성으로부터 페이런트 리소스가 도출되면 특정 특징을 물려받음에 의해 프로토콜 시그널링의 효율성을 제공하는 차일드 리소스 속성을 포함하도록 추가로 제공된다.

Description

M2M 네트워크에 있어서의 리소스 및 속성 관리{RESOURCE AND ATTRIBUTE MANAGEMENT IN MACHINE TO MACHINE NETWORKS}

본 특허 문서는 2014년 2월 10일자 출원된 미국 가특허출원번호 61/938,115호, 2014년 3월 18일자 출원된 미국 가특허출원번호 61/955,180호, 2014년 4월 3일자 출원된 미국 가특허출원번호 61/974,923호, 2014년 4월 23일자 출원된 미국 가특허출원번호 61/983,411호 및 2014년 5월 30일자 출원된 미국 가특허출원번호 62/005,961호의 우선권을 주장한다. 상술한 특허출원의 전체 내용은 본 문서의 개시의 일부로서 참조로서 수록된다.

본 특허 문서는 MTC(Machine Type Communication) 및 M2M(Machine-to-Machine) 통신을 포함하는 통신에 관한 것이다.

많은 애플리케이션에 있어서, 무선 네트워크에서 동작하는 무선 디바이스들은, 무선 네트워크에서 동작 중인 것이 아니라 통신적으로 도달 가능할 수 있는 다른 디바이스들 및 서버들과 통신한다. 무선 디바이스들에 대한 그러한 접속성을 제공하기 위해 여러 표준들이 이용될 수 있다. 예를 들어, IP(Internet Protocol)가 하나의 그러한 프레임워크(framework)이며, 그에 의해 무선 디바이스는 무선 디바이스에 할당된 IP 어드레스에 기초하여 다른 디바이스들과 통신적으로 결합될 수 있다.

예를 들어, MTC 및 M2M 통신 무선 디바이스를 포함하는 시스템에 있어서의 특정 동작 경우들은 IP 접속성을 위한 프레임워크가 없을 수 있다.

본 문서는, 다른 것들 중에서도, M2M 디바이스들간의 통신을 도모하는 기술들을 설명한다. 개시된 기술을 이용하여, 일부 실시 예에서는, 리소스가 M2M 디바이스에 의해 생성되고, 다른 M2M 디바이스에 알려지게 되고, M2M 디바이스에 의해 삭제될 수 있다.

하나의 예시적인 측면에 있어서, M2M 통신 시스템에 있어서 공표된 속성으로부터 정보를 검색하는 기술은 공표된 속성의 어드레스를 특정하고 공표된 속성의 신원을 포함함에 의해 정보 검색 요청을 발행하고, 정보 검색 요청에 응답하여 정보 응답을 수신하고, 선택적으로 수신된 정보 응답을 국소적으로 처리하거나 추가 처리를 위해 또 다른 M2M 디바이스에 전송하는 것을 포함한다.

다른 예시적인 측면에 있어서, M2M 통신 시스템에 있어서 공표된 리소스를 삭제하는 기술은 삭제될 속성이 누락된 리소스의 속성 리스트를 생성하고, 삭제될 속성을 호스팅하는 M2M 노드에 그 리스트를 전송하는 것을 포함한다.

또 다른 예시적인 측면에 있어서, M2M 통신 시스템에 있어서 공표된 속성을 생성하는 기술은 기원 M2M 노드에 의해 최초에 생성된 속성들이 리스트되는 생성 요청을 발행하고, 발행된 생성 요청에 대한 승인 응답(grant response)을 수신하는 것을 포함한다.

이러한 측면 및 다른 측면, 그리고 그들의 구현과 변형은 도면, 상세한 설명 및 청구범위에서 설명된다.

도 1은 무선 네트워크 아키텍처의 예시를 도시한 도면이다.
도 2는 무선 네트워크에서 동작할 수 있는 무선 디바이스의 예시의 블럭도이다.
도 3은 M2M 통신 시스템의 예시적인 아키텍처를 도시한 도면이다.
도 4a는 CSE베이스(CSEBase) 리소스의 예시를 도시한 도면이다.
도 4b는 원격CSE(remoteCSE) 리소스의 예시를 도시한 도면이다.
도 5는 M2M 시스템에 있어서 정보 흐름의 예시를 도시한 도면이다.
도 6은 속성 검색 절차 동안에 교환되는 메시지의 예시를 도시한 도면이다.
도 7은 속성 갱신 절차 동안에 교환되는 메시지의 예시를 도시한 도면이다.
도 8은 속성 삭제 절차 동안에 교환되는 메시지의 예시를 도시한 도면이다.
도 9는 M2M 통신 방법의 예시를 나타낸 흐름도이다.
도 10은 M2M 통신 장치의 예시를 나타낸 블럭도이다.
도 11은 M2M 통신 방법의 예시를 나타낸 흐름도이다.
도 12는 M2M 통신 장치의 예시를 나타낸 블럭도이다.
도 13은 M2M 통신 방법의 예시를 나타낸 흐름도이다.
도 14는 M2M 통신 장치의 예시를 나타낸 블럭도이다.

M2M에 있어서, 2개의 디바이들간의 통신은, 자동적으로, 즉, 인간 사용자에 의한 능동적인 참여없이 트리거(trigger)될 수 있다. 예를 들어, M2M 통신은 매주마다 1번 또는 특정 이벤트(예를 들어, 강우 이후 기계에 의해 기록된 강수량 측정)의 발생과 같은 시간 경계상에서 시작될 수 있다. M2M 통신에 참여하는 디바이스들은 오랜 기간(예를 들어, 수 시간 내지 수 개월)동안 (다른 디바이스와 통신이 없는) 수면 모드(sleep mode)로 되거나 또는 전력 차단될 수 있다. M2M 디바이스에 의한 장기간의 수면 사이클(long sleep cycles)의 결과로서, 통신 종단점에서의 리소스와 같은 동작 파라메타들이 디바이스의 2개의 각성 사이클들(awake cycles)간에 교체될 수 있다. 또한, M2M 디바이스들은 밧데리 동작될 수 있으며, 이들 디바이스들이 밧데리 교체를 위한 서비스를 받지 않아도 되도록 밧데리 수명을 절약하는 것이 유용할 수 있다.

M2M 디바이스는 특정 리소스를 갖출 수 있다. 예를 들어, 리소스는 메모리, 계산력(computational power), 센서, 다른 네트워크에 대한 접속성, 에너지 저장 기능, 디스플레이 리소스 등을 포함한다. 각 리소스는 리소스를 설명하는데 이용되는 대응 속성 세트를 가질 수 있다. 통신 메시지의 견지에서, 리소스는 M2M 디바이스를 설명하는데 이용되는 데이터 구조를 나타낼 수 있는 반면, 데이터 구조의 개별적인 요소는 속성으로 간주될 수 있다. M2M 디바이스가 국소적으로 이용할 수 있는 리소스들은 때때로 M2M 디바이스가 수면 모드이거나 다른 M2M 디바이스와 통신중이 아닐 때, 변경될 수 있다. 예를 들어, 저장 기능은 오프-라인 중에 비디오 감시 카메라에 추가될 수 있다. 다른 예시로서, 온/오프 유형 전구는 점차 약해지는 전구로 대체될 수 있으며, 그에 의해 조명을 조정하도록 그의 리소스를 제공한다. 유사하게, 리소스들은 M2M 디바이스로부터 제거되거나 삭제될 수 있다.

이용 가능한 리소스의 최신 스냅샷(snapshot)을 다른 M2M 디바이스에 제공하는 것은 일부 M2M 디바이스의 경우에 번거로울 수 있는데, 그 이유는 리소스 관리가 (예를 들어, 계산 및/또는 통신을 위한) 밧데리 전력을 소모할 수 있기 때문이다. 또한, 일부 M2M 디바이스들은 인간에 의한 접속이 곤란하거나 로컬 사용자 인터페이스를 가지지 않으며 원격으로 관리될 수 있다. 애플리케이션 서버는, 때때로, M2M 디바이스상에서 이용할 수 있는 리소스의 속성들을 알기를 원할 수 있다. 현재 통신중이 아닌 M2M 디바이스의 경우, 이 정보는 (1) M2M 디바이스를 기상(waking up)시키고 그의 속성을 조회하는 애플리케이션 서버에 의해, 또는 (2) 네트워크에서 있어서의 또 다른 디바이스(예를 들어, 게이트웨이 디바이스)(이 디바이스는 통신 가능하게 도달할 수 있음)에서 유지된 M2M 디바이스의 속성의 새도우 사본(shadow copy) 또는 클론 사본(clone copy)을 판독함에 의해 수집될 수 있다.

후자의 방법은, 다수의 서비스 제공자들의 제어하에 있을 수 있는 애플리케이션 서버로부터의 조회들이 개별적인 M2M 디바이스를 각성시킬 필요가 없고, 그에 따라 네트워크에 있어서의 밧데리 전력 및 통신 대역폭을 절감할 수 있기 때문에, M2M 통신에 특정한 장점을 제공한다. 개별적인 M2M 디바이스의 전체 개수의 속성들은 수백개의 엔트리들로 되고, 따라서 모든 속성들의 클론 사본 또는 새도우 사본을 저장하기 위한 수 킬로바이트 또는 수 메가바이트(예를 들어, 8Kbytes 내지 4Mbytes)의 대역폭 및 저장 공간이 이용된다. 애플리케이션 서버는 M2M 디바이스에 대한 모든 속성값을 필요로 하지는 않는다. 그러므로, M2M 디바이스의 속성을 그의 새도우 사본과 동기화시키는 것은 전송 시간, 전력 및 대역폭을 불필요하게 소모할 수 있다.

오늘날의 M2M 통신 시스템 및 프로토콜은 M2M 통신 시스템에서 일어나는 동작 상황을 적절하게 다루지 못한다. 본 문서에 개시된 기술들은, 다른 것들 중에서도, 다수의 서비스 제공자들의 혜택을 위해, M2M 통신 시스템에 있어서 속성의 삭제, 광고 및 리소스 효율적 생성을 제공한다.

M2M 에코시스템(ecosystem)의 E2E(End-to-End) 뷰(view)는, M2M 애플리케이션 서버(Application Server:AS) 및 M2M 디바이스/게이트웨이에 의해 호스팅되는 M2M 애플리케이션을 구비한다. 이러한 E2E 뷰에 있어서, M2M 서비스 플랫폼은, 데이터 관리, 디바이스 관리, 서비스 인에이블먼트 기능(Service Enablement capabilities) 등과 같은 서비스를 제공한다. 기반 운송 네트워크(underlying Transport Network)는 애플리케이션 서버와 M2M 디바이스/게이트웨이에 의해 호스팅되는 M2M 애플리케이션들간의 데이터 흐름에 운송 및 통신 서비스를 제공한다.

이하의 정의 세트는 oneM2M에 의해 전개되는 사양으로부터 취해진 것이다.

AF(Application Function): 종단간 M2M 해법에 대한 애플리케이션 로직을 제공. 예를 들어, 애플리케이션 기능들은 플리트 추적 애플리케이션(fleet tracking application), 원격 혈당 감시 애플리케이션 또는 원격 전력 계측 및 제어 애플리케이션일 수 있다.

애플리케이션 층: M2M 애플케이션 및 관련 사업 및 동작 로직을 구비함

CSE(Common Service Entity): 공통 서비스 엔티티(CSE)는 공통 서비스 기능들의 집합이다. M2M 노드에서의 공통 서비스 엔티티는, 또 다른 M2M 노드로부터의 서비스를 액세스하기 위해 또는 그 M2M 노드에서의 M2M 애플리케이션에 의해 이용되는 서비스들의 세트를 제공한다. 공통 서비스 엔티티는 기반 네트워크 기능을 이용할 수 있으며, 그 서비스를 달성하기 위해 서로 상호 작용할 수 있다.

CSF(Common Services Function): M2M 노드에 의해 M2M 시스템에 있어서의 다른 엔티티들에 제공되는 서비스/기능들의 세트를 구비함. 그러한 서비스/기능들은 oneM2M 사양에 기초하여 M2M 시스템내의 기준 포인트 X 및 Y를 통해 다른 공통 서비스 기능들(CSF)에게 노출된다. 또한, 공통 서비스 기능들은 기반 네트워크 서비스를 액세스하기 위한 기준 포인트 Z를 이용한다. 예를 들어, 그러한 CSF로는 데이터 관리&저장소, 디바이스 관리 및 M2M 세션 관리등이 있다.

공통 서비스 층: (몇 가지를 예로 들면, 관리, 발견(discovery) 및 정책 시행을 통해) M2M 애플리케이션을 인에이블하는 M2M 서비스 기능들로 구성된다.

네트워크 서비스 층: 운송, 접속성 및 서비스 기능들을 제공함.

M2M 애플리케이션: 이 애플리케이션은 서비스 로직을 실행시키고, oneM2M 지정 개방 인터페이스들의 세트를 통해 액세스할 수 있는 M2M 공통 서비스를 이용한다.

M2M 애플리케이션 서비스 제공자: 사용자에게 M2M 애플리케이션 서비스를 제공하는 엔티티(예를 들어, 회사).

M2M 디바이스: 감지 및/또는 액튜에이션(sensing and/or actuation) 서비스를 제공하는 장비. M2M 디바이스는 하나 이상의 M2M 애플리케이션들을 호스팅하고 하나 이상의 CSE들을 포함한다. M2M 디바이스는 감지&액튜에이션 장비과 함께 배치될 수 있지만, 반드시 함께 배치되어야만 하는 것은 아니다.

M2M 게이트웨이: 하나 이상의 CSE들을 포함하고 M2M 애플리케이션을 포함할 수 있는 장비. M2M 게이트웨이는 M2M 서비스 인프라구조 및 하나 이상의 M2M 디바이스와 통신한다.

M2M 노드: M2M 디바이스, M2M 게이트웨이 및 M2M 서비스 인프라구조와 같은 M2M 물리적 엔티티들을 나타내기 위해 M2M 애플리케이션(들) 및/또는 CSE(들)로 구성되는 논리적 엔티티.

M2M 서비스 인프라구조: M2M 서비스 제공자에게 데이터 및 코디네이션(coordination) 기능의 관리를 제공하고, M2M 디바이스 및/또는 M2M 게이트웨이와 통신하는 장비. M2M 서비스 인프라구조는 하나 이상의 CSE들을 포함한다.

M2M 서비스 제공자: M2M 애플리케이션 서비스 제공자 또는 사용자에게 M2M 서비스를 제공하는 엔티니(예를 들어, 회사).

기반 NSF(Network Services Function): 기반 네트워크 서비스 기능(NSF)은 M2M 노드 외부의 엔티티들로부터 CSE들로 서비스를 제공한다. 예를 들어, 그러한 서비스들은 디바이스 관리, 위치 서비스, 디바이스 도달 가능성 상태(Device Reachability Status), 디바이스 트리거링(Device Triggering)등을 포함한다.

S&A(Sensing and Actuation) 장비: 하나 이상의 M2M 애플리케이션 서비스와 상호 작용함에 의해 물리적 환경에 영향을 주고/주거나 감지하는 기능성을 제공하는 장비. 감지 및 액튜에이션 장비는 M2M 시스템과 상호 작용할 있지만, M2M 애플리케이션을 호스팅하는 것은 아니다. S&A 장비는 M2M 디바이스와 함께 배치되지만, 반드시 함께 배치될 필요는 없다.

X 기준 포인트: M2M 애프리케이션과 CSE간의 기준 포인트. X 기준 포인트는 M2M 애플리케이션이 CSE에 의해 제공된 서비스를 이용할 수 있게 하며, CSE가 M2M 애플리케이션과 다시 통신할 수 있게 한다.

Y 기준 포인트: 2개의 CSE들간의 기준 포인트. Y 기준 포인트는 CSE가 필요한 기능성을 달성하기 위해 다른 CSE의 서비스들을 이용할 수 있게 한다.

Z 기준 포인트: CSE와 기반 네트워크간의 기준 포인트. Z 기준 포인트는 CSE가 필요한 기능성을 달성하기 위해 기반 네트워크에 의해 제공된 (운송 및 접속성 서비스와는 다른) 서비스들을 이용할 수 있게 한다.

M2M 서비스들의 그러한 E2E 뷰에 있어서, M2M 애플리케이션 서버, M2M 디바이스들/게이트웨이들, M2M 서비스 플랫폼 및 운송 네트워크는 E2E M2M 서비스 프레임워크내의 다른 엔티티들로 간주될 수 있다. 이들 엔티티들의 각각은 다른 비지니스 엔티티들을 나타내는 것으로 간주될 수 있다. 예를 들어, M2M 애플리케이션 서비스 제공자는 종단 사용자에게 M2M 애플리케이션 서비스를 제공하는 비지니스 엔티티(예를 들어, 회사)이다. M2M 서비스 제공자(Service Provider: SP)는 감지 및 액튜에이션(S&A) 장비와 집적화될 수 있는 M2M 디바이스/게이트웨이로부터의 서비스들을 실현하는 M2M 애플리케이션 서비스 제공자가 사용하기 위한 M2M 서비스 플랫폼을 제공하는 또 다른 비지니스 엔티티(예를 들어, 회사)이다. 기반 네트워크 서비스 제공자는, IEEE, IETF, 3GPP, 3GPP2, BBF 등에 의해 정의된 것들과 같은 유선 및/또는 무선 기술들에 기초할 수 있는 기반 운송 네트워크를 제공한다.

M2M 서비스 프레임워크내에 있어서, M2M 디바이스/게이트웨이는 다른 M2M 서비스 제공자(SP들)에 의해 특정된 애플리케이션을 호스팅할 수 있다. 예를 들어, 에너지 관리, 홈 보안, 건강 감시등과 같은 서비스들을 지원하는 S&A 장비를 가진 스마트 홈(Smart Home)의 경우를 고려해보자. 그러한 서비스(에너지 관리, 홈 보안 및 건강 감시 등)는 다른 M2M 서비스 제공자에 의해 제공된다. 또한, 모든 이러한 서비스들은 다른 서비스를 위한 S&A 장비의 이용에 의해, 단일 홈 게이트웨이상의 스마트 홈에서 호스팅된다. 이러한 서비스 시나리오에 있어서, 홈 게이트웨이는 전형적으로 홈-소유자에 의해 소유되는 반면, S&A 장비는 서비스-지정적이다(S&A 장비를 소유한 자가 누구인지는 본 명세서에서 논의할 대상이 아니다). 예를 들어, 에너지 관리 서비스와 건강 감시 서비스를 위한 S&A 장비는 제공되는 서비스에 대해 특정적이며, 각 M2M 서비스 제공자(이 경우에 있어서 에너지 관리 및 건강 감시 서비스 제공자)에 의해 관리될 것을 요구한다. 유사하게, M2M 서비스 제공자들은 다른 M2M 서비스 제공자와 무관하게 홈 게이트웨이상의 그들 각각의 동작 환경 세트를 관리하기를 원할 수 있다. 예를 들어, 에너지 관리 서비스 제공자는 홈 게이트웨이상에 설치된 에너지 감시 소프트웨어/펌웨어(firmware)를 갱신하기를 원할 수 있다. 그러나, 그러한 갱신이 건강 감시 서비스 제공자에 의해 제공된 서비스에 영향을 미쳐서는 안된다. 그러한 다양한 서비스들의 세트를 제공하면서, 홈 게이트웨이가 다른 M2M 서비스 제공자들에 의해 제공되는 서비스들을 구분하기 위한 보안 환경을 제공할 필요가 있을 가능성이 높다.

도 1에는 무선 통신 네트워크 또는 시스템의 예시가 도시된다. 이 무선 통신 네트워크는 하나 이상의 기지국(Base station: BS)(105,107)과 하나 이상의 무선 디바이스들(110)을 포함할 수 있다. 기지국(105,107)은 하나 이상의 무선 디바이스(110)로, 다운 링크(DL) 신호로서 알려진, 순방향 링크(FL)상의 신호를 전송할 수 있다. 무선 디바이스(110)는 하나 이상의 기지국(105,107)으로, 업 링크(UL) 신호로서 알려진, 반전 링크(Reverse Link: RL)상의 신호를 전송할 수 있다. 무선 통신 시스템은 하나 이상의 기지국(105,107)을 제어하기 위해 하나 이상의 코어 네트워크(125)를 포함할 수 있다. 하나 이상의 기지국은 무선 액세스 네트워크를 형성한다. 기지국은, 무선 디바이스에 무선 액세스를 제공하는 그의 본질에 기인하여, 하나 이상의 다른 기지국과 조합하여, 또는 그 단독으로 액세스 포인트(Access Point: AP), 액세스 네트워크(Access Network: AN) 또는 e-노드B로서 지칭될 수 있다. 예를 들어, 본 기술 및 시스템들을 구현할 수 있는 무선 통신 시스템은, 다른 것들 중에서도, CDMA2000 1x, HRPD(High Rate Packet Data), LTE(Long-Term Evolution), UTRAN(Universal Terrestrial Radio Access Network) 및 WiMAX(Worldwide Interoperability for Microwave Access)와 같은 CDMA(Code Division Multiple Access)에 기초한 무선 통신 시스템을 포함한다.

도 2에는 무선 디바이스, 기지국 또는 다른 무선 통신 모듈을 구현하는 무선 송수신국(radio transceiver station)의 예시가 도시된다. 무선국의 다양한 예시들은, 도 1에 있는 기지국 및 무선 디바이스를 포함한다. 기지국 또는 무선 디바이스와 같은 무선국(205)은, 본 문서에 안출된 기술들 중 하나 이상과 같은 방법들을 구현하는 마이크로프로세서와 같은 프로세서 전자기기(210)를 포함할 수 있다. 무선국(205)은 하나 이상의 안테나(220)와 같은 하나 이상의 통신 인터페이스를 통해 무선 신호를 송신 및/또는 수신하도록 송수신 전자기기(215)를 포함할 수 있다. 무선국(205)은 데이터를 송신 및 수신하는 다른 통신 인터페이스를 포함할 수 있다. 일부 구현에 있어서, 무선국(205)은 유선 네트워크와 통신하기 위해 하나 이상의 유선 통신 인터페이스를 포함할 수 있다. 무선국(205)은 데이터 및/또는 명령과 같은 정보를 저장하도록 구성된 하나 이상의 메모리(225)를 포함할 수 있다. 일부 구현에 있어서, 프로세서 전자기기(210)는 적어도 송수신 전자기기(215)의 일부와 메모리(225)를 포함할 수 있다.

일부 구현에 있어서, 무선국들(205)은 CDMA 또는 GSM 기반 에어 인터페이스(air interface)에 기초하여 서로 통신할 수 있다. 일부 구현에 있어서, 무선국(205)은 OFDMA(Orthogonal Frequency-Division Multiple Access) 에어 인터페이스를 포함할 수 있는 OFDM(Orthogonal Frequency-Division Multiplexing) 에어 인터페이스에 기초하여 서로 통신할 수 있다. 일부 구현에 있어서, 무선국(205)은 CDMA20001x, HRPD, WiMAX, GSM, LTE, UMTS(Unversal Mobile Telecommunication System)와 같은 하나 이상의 무선 기술을 이용하여 통신할 수 있다.

일부 구현에 있어서, 무선국(205)은 802.11(a/b/g/n) 인터페이스와 같은 근거리 네트워크 접속성(local area network connectivity)을 갖도록 추가 구성될 수 있다. 그러한 인터페이스의 이용성은 무선국(205)이 근거리 접속을 통해 인터넷에 통신 가능하게 결합되게 한다. 예를 들어, 사용자는 케이블 모뎀 네트워크 또는 DSL 네트워크와 같은 고정 광대역 네트워크(fixed broadband newtork)를 거쳐 무선 근거리 네트워크 접속을 통해 서비스에 접속시킴에 의해 사용자 장비를 통해 그 서비스를 액세스할 수 있다(예를 들어, 홈 Wi-Fi 액세스). 상술한 무선국(205)은 본 문서에서 개시된 기술들을 구현하는데 이용될 수 있다. 유사하게, 액세스 네트워크(125)에 통신 가능하게 결합된 또 다른 엔티티 또는 모듈(예를 들어, 거기에 결합된 코어 또는 백본 네트워크(backbone network) 또는 애플리케이션 서버)은 일부 개시된 기술들을 구현할 수 있다.

oneM2M 시스템내로의 배치의 제 1 예시적인 실시 예

본 문서에 설명된 기술들은 oneM2M 사양(그의 현재 배포 버전이 일 예시로서 아래와 같이 설명됨)을 따르는 디바이스와 상호 동작하도록 배치될 수 있는 구현으로 실시될 수 있다.

본 문서에서는 이하의 용어가 이용된다.

ADN: 애플리케이션 전용노드(Application Dedicated Node)

ADN-AE: 애플리케이션 전용 노드에 상주하는 AE

AE:애플리케이션 엔티티(Application Entity)

App: 애플리케이션(Application)

ASN: 애플리케이션 서비스 노드(Application Service Node)

ASE-AE: 애플리케이션 서비스 노드에 있어서 CSE에 등록된 애플리케이션 엔티티

ASN-CSE: 애플리케이션 서비스 노드에 상주하는 CSE

BBF: 광대역 포럼(Broadband Forum)

CSE: 공통 서비스 엔티티(Common Service Entity)

CSF: 공통 서비스 기능(Common Service Function)

EF: 인에이블러 기능(Enabler Function)

IEEE: 전기 전자 엔지니어 협회(Institute of Electrical and Electronics Engineers)

IETF: 인터넷 엔지니어링 태스크 포스(Internet Engineering Task Force)

IN: 인프라구조 노드(Infrastructure Node)

IN-AE: 인프라구조 노드에 있어서 CSE에 등록된 애플리케이션 엔티티

IN-CSE: 인프라구조 노드에 상주하는 CSE

JNI: 자바 네이티브 인터페이스(Java Native Interface)

LTE: Long Term Evolution

MAC: 매체 액세스 제어(Medium Access Control)

M2M: Machine to Machine

MN: 중간 노드(Middle Node)

MN-CSE: 중간 노드에 상주하는 CSE

NSE: 네트워크 서비스 엔티티(Nerwork Service Entity)

SDO: 표준화 개발 기구(Standards Development Organization)

SP: 서비스 제공자(Service Provider)

UNet: 기반 네트워크(M2M 디바이스가 상주함)

M2M 통신에 있어서, 2개의 디바이스, 예를 들어, 애플리케이션 서버와 M2M 가능 디바이스는, 인간 사용자가 그 통신을 정확하게 개시하지 않고도 서로 통신할 수 있다. M2M 통신에 있어서, 통신이 이루어지는 2개의 종점들이 다른 네트워크에 있는 경우가 있다. 전형적인 애플리케이션 시나리오에서는, 하나의 종점이 연장된 시기간동안에 오프라인으로 진행할 수 있는 유틸리티 박스(utility box) 또는 센서일 수 있으며, 다른 종점이 관리되는 네트워크에 전개될 수 있는 M2M 서버 또는 유틸리티 빌링 서버(utility billing server)와 같은 애플리케이션 서버일 수 있다. 이들 두 종점들간에 왕복하는 데이터 패킷들(data packets)은 여러 라우팅 선택을 통해 라우팅될 수 있다. 예를 들어, 하나의 종점은 인가 스펙트럼(licensed spectrum)(예를 들어, LTE) 또는 비인가 스펙트럼(unlicensed spectrum)(예를 들어, Wi-Fi)를 통한 접속성을 가질 수 있다. 하나의 종점이 연장된 시기간 동안, 예를 들어, 수일 또는 수주 동안 오프라인일 경우, 마지막 통신 세션동안에 패킷을 그 종점으로 라우팅했던 방식이, 필연적으로 그 패킷을 현재 통신 세션에서 라우팅할 수 있는 방식으로 되는 것은 아닐 수 있다. 또한, 여러 라우팅 선택은 여러 비용(cost)(예를 들어, 전송 동안 대역폭 과금(bandwidth charges) 및 전력 손실)을 초래한다.

전력 또는 다른 리소스들을 절약하기 위하여, 일부 M2M 디바이스 또는 이들 디바이스들 상에서 수행되는 애플리케이션 엔티티들이 가끔씩 "오프라인"으로 진행할 수 있다. 애플리케이션 층 통신을 재수립하기 위해, 이들 M2M 엔티티들은 통신 전에 활성화될 수 있다. 트리거링이 수행되거나 정확한 모듈 또는 엔티티가 활성화될 수 있는 방식은 개별 M2M 디바이스들의 구성 및 기능에 의존한다.

oneM2M, ETSI TC M2M, TIA TR-50등(M2M SDO들)과 같은 기구에 의해 개발된 서비스 층 사양은 광범위한 시장 집중(수직) 기구들에 의한 M2M 해법들의 효율적인 전개를 지원할 필요가 있다. 서비스 층에 대한 집중에 따라, 그러한 기구들은 종단간 서비스(end-to-end services)의 운송 네트워크-독립적인 견해를 가지고 있었다. 아직, 그들은 그들의 서비스 층 사양이 다른 유형의 운송 네트워크들과 인터페이싱하는데 효율적으로 사용될 수 있음을 확실하게 할 필요가 있다. 그러한 운송 네트워크는 3GPP, 3GPP2, IEEE, IETF 및 BBF에 의해 정의되는 무선 또는 유선 네트워크를 포함하지만, 그에 국한되는 것은 아니다.

서비 층 사양에 있어서, 현재에는, M2M 요청을 달성하기 위해 공통 서비스 리소스를 유지하는 엔티티와 연관된 특정 M2M 디바이스를 식별하도록 하는 서비스 요청에 대한 방법이 없다. 더욱이, 대기(sleeping) M2M 디바이스가 M2M 통신 요청을 달성하기 위해 활성화되도록 트리거링되어야만 하는 경우, 현재의 시스템은, 그 요청이 라우팅되어야 하는 트리거링 디바이스를 특정하는 방식에 제한이 있다. 본 문서에서 안출된 기술은 이러한 문제점 및 다른 문제점들을 해결한다.

도 3에는 oneM2M 시스템에 의해 지원되는 일부 가능한 구성(300)이 도시된다. 도 3은 oneM2M에 의해 개발되고 있는 기능적 아키텍쳐 사양으로부터 발췌된 것이다.

이 예시적인 도면(300)에 있어서, ADN(ADN-AE들)상의 애플리케이션 엔티티들(AE들)은 IN-CSE에 등록할 수 있다. 유사하게, 무-노드(Node-less) AE들은 IN-CSE에 등록할 수 있다. ADN-AE들은 MN-CSE에 또한 등록할 수 있다. 그러한 등록은 원격 엔티티들/노드들에서의 AE들과 CSE들간의 등록이다.

CSE는 하나 이상의 CSF들의 예시이다. CSE는 M2M 애플리케이션에 의해 이용되고 공유될 수 있었던 CSF들의 서브셋을 제공한다. CSE는 그 서비스를 달성하기 위해 다른 CSE들과 상호 작용할 수 있고 UNet 기능을 이용할 수 있다. CSE는 M2M 환경에 대해 공통인 "서비스 기능들"의 세트를 구비한다. 그러한 서비스 기능들은, oneM2M에서 특정한 Mca 및 Mcc 기준 포인트들과 같은 기준 포인트들을 통해 다른 엔티티들에게 노출된다(도 3 참조). Mcc 기준 포인트는 CSE들간의 통신 흐름을 정의한다. 기준 포인트 Mcn은 기반 네트워크 서비스 엔티티들을 액세스하는데 이용된다. 예를 들어, CSE에 의해 제공되는 서비스 기능들로는 데이터 관리, 디바이스 관리, M2M 가입 관리, 위치 결정 서비스 등이 있다. CSE에 의해 제공된 그러한 "서브 기능들"은 논리적으로 CSF(Common Service Function)들로서 간주될 수 있다. CSE 내부에 있어서, CSF들의 일부는 필수적일 수 있으며 다른 것들은 선택적일 수 있다. 또한, CSF 내부에 있어서, 일부 서브 기능들은 필수적이거나 선택적일 수 있다(예를 들어, "디바이스 관리" CSF 내부에 있어서, "애플리케이션 소프트웨어 설치", "펌웨어 갱신", "로깅(Logging)", "모니터링" 등과 같은 서브 기능들의 일부는 필수적이거나 선택적일 수 있다).

CSF는 M2M 환경에 대해 공통이고 oneM2M과 같은 상호 연동(interworking) 사양에 의해 특정되는 서비스 기능들의 세트이다.

도 3에 있어서, 이하의 약어가 이용된다.

무-노드 AEs: 이 엔티티는, IN-AE가 애플리케이션 서비스 제공자에 의해 호스팅될 수 있음을 나타낸다.

노드: 적어도 하나의 CSE 및/또는 하나의 애플리케이션 엔티티(AE)를 포함하는 기능 엔티티. 노드는, 예를 들어, M2M 디바이스, 게이트웨이 또는 서버 인프라구조와 같은 물리적 장치에 포함될 수 있다. 일반적으로, 다른 노드에 상주하는 CSE들은 동일하지 않으며 그 노드에 있는 CSE에 의해 지원되는 서비스에 의존한다. 일부 실시 예들에 있어서, 2가지 유형의 노드들이 정의된다. 한가지 유형의 노드는 적어도 하나의 공통 서비스 엔티티 및/또는 하나 이상의 oneM2M 애플리케이션 엔티티들을 포함하는 기능 엔티티이다. 그러한 노드들은 CSE-가능 노드들로서 지칭될 수 있다. 다른 유형의 노드는 하나 이상의 애플리케이션 엔티티를 포함하고, 공통 서비스 엔티티(no Common Service Entity)가 없는 기능 엔티티이다. 그러한 노드들을 비-CSE 가능 노드(non-CSE capable node)들이라 한다. oneM2M 아키텍처에 있어서, CSE 가능 oneM2M 노드는, 예를 들어, M2M 디바이스, 게이트웨이 또는 서버 인프라구조와 같은 물리적 객체에 포함될 수 있다. 비-CSE 가능 oneM2M 노드는, 예를 들어, 센서, 액튜에이터(actuators) 등과 같은 물리적 객체에 포함될 수 있다. CSE 가능 및 비-CSE 가능 노드들은 Mca 기준 포인트를 통해 통신한다.

Mcc 기준 포인트는 가능한 Mcc 기준 포인트와 유사하게 되도록 하는 것을 목표로 한다. 그러나, M2M 서비스 제공자간 통신의 본질 때문에, 일부 차이점이 존재한다.

구성(200)에는 많은 다른 유형의 노드들이 존재한다. 노드는 실질적인 물리적 객체에 매핑될 수 있지만, 단일의 실질적인 객체에 필수적으로 매핑되어야 하는 것은 아니다. 그 노드는 다음을 포함한다.

애플리케이션 서비스 노드(ASN): 애플리케이션 서비스 노드는 하나의 공통 서비스 엔티티를 포함하고 적어도 하나의 애플리케이션 엔티티를 포함하는 노드이다. 애플리케이션 서비스 노드는 Mcc 기준 포인트를 통해 정확하게 하나의 중간 노드 또는 정확하게 하나의 인프라구조 노드와 통신할 수 있다. 예를 들어, 물리적 매핑은 M2M 디바이스에 상주할 수 있었단 애플리케이션 노드를 포함한다.

애플리케이션 전용 노드(ADN): 애플리케이션 전용 노드는 적어도 하나의 애플리케이션 엔티티를 포함하고, 공통 서비스 엔티티를 포함하지 않는다. 애플리케이션 전용 노드는 Mca 기준 포인트를 통해 중간 노드 또는 인프라구조 노드와 통신한다. 예를 들어, 물리적 매핑은 제한된 M2M 디바이스에 상주할 수 있었던 애플리케이션 전용 노드를 포함한다.

중간 노드(MN): 중간 노드는 하나의 공통 서비스 엔티티를 포함하고, 0 또는 그 이상의 애플리케이션 엔티티를 포함하는 노드이다. 중간 노드는 Mcc를 통해 IN 또는 다른 MN과 통신하고, Mcc를 통해 적어도 IN/MN/ASN과 통신하거나 Mca를 통해 ADN과 통신한다. 예를 들어, 물리적 매핑은 M2M 게이트웨이에 상주할 수 있었던 중간 노드를 포함할 수 있다.

인프라구조 노드(IN): 인프라구조 노드는 하나의 공통 서비스 엔티티를 포함하고 0 또는 그 이상의 애플리케이션 엔티티들을 포함하는 노드이다. 인프라구조 노드는 각 Mcc 기준 포인트들을 통해 하나 이상의 중간 노드(들) 및/또는 하나 이상의 애플리케이션 서비스 노드(들)과 통신한다. 또한, 인프라구조 노드는 각 Mca 기준 포인트들을 통해 하나 이상의 애플리케이션 전용 노드와 통신한다. 물리적 매핑의 예시: 인프라구조 노드는 M2M 서버 인프라구조에 상주할 수 있었다.

M2M 외부 식별자(M2M-Ext-ID)

M2M-Ext-ID는, CSE에게 지정되고, CSE-ID에 의해 식별되는, CSE에게 지정된 서비스가 기반 네트워크로부터 요청되면, M2M SP에 의해 이용된다.

M2M 외부 식별자로 인해, 기반 네트워크는 서비스 요청에 대해 CSE-ID와 연관된 M2M 디바이스를 식별할 수 있게 된다. 그러한 취지로, 기반 네트워크는 그것이 목표 M2M 디바이스에 할당했던 UNet-특정 식별자에 M2M-Ext-ID를 매핑한다. 또한, M2M SP는 CSE-ID, M2M-Ext-ID 및 UNet의 신원들간의 연관성을 유지시킬 수 있다.

여러 실시 예들에 있어서, CSE-ID와 M2M-Ext-ID간의 사전-프로비저닝된 연관성 및 동적 연관성이 구현될 수 있다.

각 CSE-ID마다, UNetwork-ID 또는 특정 기반 네트워크 식별자에 대한 단지 하나의 M2M-Ext-ID만이 존재해야 한다. 따라서, 다수의 기반 네트워크와 상호 연동하는 M2M SP는 기반 네트워크당 하나씩, 동일 CSE-ID와 연관된 다른 M2M-Ext-ID들을 가질 수 있으며, 기반 네트워크를 향해 개시한 임의 서비스 요청에 대해 적당한 M2M-Ext-ID를 선택할 것이다.

일반적으로, M2M 디바이스에 대한 M2M-Ext-ID의 UNet에 의한 매핑은 UNet 특정적이다.

일부 구성에 있어서, UNet 제공자 및 M2M 서비스 제공자는 CSE-ID에 의해 식별된 각 CSE에게로의 M2M-Ext-ID의 할당을 위해 협력할 수 있다. 동시에, UNet 제공자는 그러한 CSE를 호스팅하는 M2M 디바이스에 할당된 UNet-특정 식별자와의 M2M-Ext-ID의 연관성을 유지한다.

사전-프로비저닝된 M2M-Ext-ID의 경우, 연관된 CSE-ID와 함께 M2M-Ext-ID는 인프라구조 노드에서 프로비저닝될 수 있다. M2M 디바이스에 있는 CSE는 그것에 할당된 M2M-Ext-ID를 알 필요가 없다. 동적 M2M-Ext-ID의 경우, 기반 네트워크에 대해 특정된 M2M-Ext-ID는 필드 도메인(Field Domain)내의 각 M2M 디바이스에서 프로비저닝된다. 그러한 M2M-Ext-ID는 CSE 등록 동안에 IN-CSE에 운반된다.

트리거 수신자 식별자(트리거-수신자-ID)

트리거-수신자-ID는, 실행 환경상의 ASN/MN-CSE의 인스턴스(instance)를 식별하기 위해 트리거가 라우팅될 Unet로부터 디바이스 트리거링 서비스가 요청될 때, 이용된다. 예를 들어, 3GPP 디바이스 트리거링이 이용되면, 트리거-수신자-ID는, 예를 들어, 사양 3GPP 23.682에 특정된 애플리케이션-포트-식별자에 매핑된다.

사전-프로비저닝된 M2M-Ext-ID의 경우, 트리거-수신자-ID는 M2M-Ext-ID 및 연관된 CSE-ID와 함께 인프라구조 노드에서 프로비저닝된다. 동적 M2M-Ext-ID의 경우, 기반 네트워크에 대해 특정된 트리거-수신자-ID는 필드 도메인내의 각 M2M 디바이스에서 프로비저닝된다. 그러한 트리거-수신자-ID는 CSE 등록 동안에 IN-CSE로 운반된다.

아래의 표 1은 M2M 식별자들과 그들의 이용 성질들의 예시를 목록화한 것이다. 특히, 표 1에 리스트된 바와 같이, 외부 식별자는 UNet 제공자와 M2M SP간에 공동으로 할당되고, UNet의 서비스들을 이용하기를 원하고 2개의 프로비저닝 모드들, 즉, 대응하는 CSE의 등록 동안에 외부 식별자가 운반되는 동적 모드 및 프로비저닝 모드를 가질 수 있는 CSE에 속하는 M2M 노드에 할당된다.

M2M 식별자 수명 주기(lifecycle) 및 특성들

식별자	이하에 의해 할당됨	이하에게 할당됨	이하의 동안에 할당됨	수명	고유성	이하의 동안에 이용됨	주목
M2M 서비스 제공자 식별자	범위 밖	AE, CSE	범위 밖	범위 밖	글로벌(Global)	프로비저닝 동안
애플리케이션 엔티티 식별자	AE 또는 등록관 CSE(Registrar CSE)	AE	SE 스타트 업(start-up)동안	애플리케이션 엔티티 등록	글로벌	- 애플리케이션 엔티티 등록 동안 - 보안 콘텍스트 수립 동안 - AE에 의해 개시된 모든 다른 동작 동안	보안 요건들은 보안 콘텍스트 수립에 적용됨
애플리케이션 식별자	범위 밖	범위 밖	사전-프로비저닝되는 동안	범위 밖	M2M 서비스 전개에 특정됨	- 애플리케이션 엔티티 등록 동안
CSE 식별자	M2M SP	CSE	보안 프로비저닝 동안	CSE의 수명	글로벌	- 정보 흐름 동안(10 절) - 보안 콘텍스트 수립 동안	보안 요건들은 보안 콘텍스트 수립에 적용됨
M2M 노드 식별자	범위 밖	M2M 노드 호스팅 CSE	사전-프로비저닝되는 동안	M2M 노드의 수명	글로벌	- 디바이스 관리 동안	유일하게 독출될 필요가 있음
M2M 가입 식별자	M2M SP, 범위 밖	애플리케이션 엔티티, 동일한 M2M 가입자에 속하는 하나 이상의 CSE들	서비스 등록(signup)시	MMSP에의 M2M 서비스 가입 수명	글로벌	- 과금 및 정보 기록 동안 - 롤 기반 액세스 제어(role based access control) 동안 - 인증 동안	다수의 CSE는 동일한 M2M 가입 식별자를 할당받을 수 있음
M2M 요청 ID	Mcc: CSE Mca: 애플리케이션 엔티티	AE 또는 CSE에 의해 개시된 요청	Mcc: CSE에 의해 요청이 개시되거나 CSE에 의해 수신된 요청의 처리시. Mca: AE에 의해 요청이 개시될 때	요청 및 그에 대응하는 응답의 수명과 동일	Mcc: 글로벌 Mca: 로컬 또는 글로벌	요청 및 대응하는 응답 동안
외부 식별자	해당하는 경우, 기반 네트워크 제공자와 M2M SP간에 공동으로	기반 네트워크의 서비스를 이용하기를 원하는 CSE에 속하는 M2M 노드	행정 협정 동안	CSE의 수명	특정 기반 네트워크 제공자에 의해 결정되는 로컬 또는 글로벌	해당하는 경우, Mcn 기준 포인트를 통해 CSE에 의해 개시된 요청 동안	사전-프로비저닝된 모드: 인프라구조 노드에서 프로비저닝됨. 동적 모드: M2M 디바이스에서 프로비저닝됨. CSE 등록 동안에 IN-CSE로 운송됨
기반 네트워크 식별자	M2M SP	기반 네트워크	사전-프로비저닝되는 동안	기반 네트워크의 수명	M2M SP 도메인에 대해 로컬	UL 네트워크 선택 동안
트리거 수신자 식별자	실행 환경		ASN/MN-CSE 스타트-업 또는 활성화 동안	CSE의 수명	실행 환경-와이드	해당하는 경우, 디바이스 트리거링 절차 동안	사전-프로비저닝된 모드: 인프라구조 노드에서 M2M-Ext-ID와 함께 프로비저닝됨. 동적 모드: M2M 디바이스에서 프로비저닝됨. CSE 등록 동안에 M2M-Ext-ID와 함께 IN-CSE로 운송됨
M2M 서비스 식별자	M2M 서비스 제공자, 범위 밖				M2M 서비스 제공자에 대해 로컬	M2M 서비스 가입 동안

리소스 유형 CSEBase

<CSEBase> 리소스는 CSE를 나타내는데 이용될 수 있다. 이러한 <CSEBase> 리소스는 CSE 상에 상주중인 모든 리소스들에 대한 근원(root)일 수 있다.

도 4a에는 CSEBase 리소스에 포함된 속성들의 예시적인 리스트가 도시된다.

<CSEBase> 리소스는 표 2에 있는 차일드 리소스(child resource)를 포함한다.

<CSEBase>의 차일드 리소스 이름	차일드 리소스 유형	다중도	설명
[variable]	<remoteCSE>	0..n
[variable]	<node>	0..n
[variable]	<AE>	0..n
[variable]	<container>	0..n
[variable]	<group>	0..n
[variable]	<accessControlPolicy>	0..n
[variable]	<subscription>	0..n
[variable]	<mgmtCmd>	0..n
[variable]	<locationPolicy>	0..n
[variable]	<statsConfig>	0..n
[variable]	<statsCollect>	0..n

<CSEBase> 리소스는 표 3에 설명된 속성을 포함할 수 있다.

<CSEBase>의 속성 이름	다중도	RW/ RO/ WO	설명
resourceType	1	RO
creationTime	1	RO
lastModifiedTime	1	RO
accessControlPolicies	0..1	RW
labels	0..1	RW
cseType	1	WO	생성된 리소스에 의해 표시되는 CSE 노드의 유형을 나타냄
CSE-ID	1	WO	글로벌하게 유일한 CSE 식별자
supportedResourceType	1	RO	CSE에서 지원되는 리소스 유형의 리스트
pointOfAccess	0..n	RW	이 CSE에 접속시키기 위해 원격 CSE들에 의해 이용될 물리적 어드레스들의 리스트를 나타냄(예를 들어, IP 어드레스, FQDN). 이 속성은 그의 값을 원격 CSE들에게 공표하는데 이용됨
nodeLink	0..1	RO	노드 특정 정보를 저장하는 <node> 리소스의 기준(URI)
M2M-Ext-ID	0..1	RW	단지 ASN-CSE/MN-CSE에서만 지원됨. 이 속성이 설명된 7.1.8절을 참조. 이 속성은 M2M-Ext-ID 및 CSE-ID의 동적 연관성의 경우에만 이용됨.
Trigge-Recipient-ID	0..1	RW	단지 ASN-CSE/MN-CSE에서만 지원됨. 이 속성은 M2M-Ext-ID 및 CSE-ID의 동적 연관성의 경우에만 이용됨.
notificationCongestionPolicy	0..1	RO	이 속성은 가입 통지를 생성하는 CSE들에게 적용됨. 그것은, 각 가입자(AE 또는 CSE)에 대한 통지의 저장이 그 가입자에 대한 통지에 대한 최대 저장 한도에 도달하면 적용되는 규칙을 특정함. 예를 들어, 보다 높은 notificationStoragePriority의 새로운 통지를 위한 공간을 만들기 위해 보다 낮은 notificationStoragePriority의 저장된 통지를 삭제하거나, 모든 통지가 동일한 notificationStoragePriority일 때, 새로운 통지를 위한 공간을 만들기 위해 과거의 creationTime의 저장된 통지를 삭제함

리소스 유형 remoteCSE

<remoteCSE> 리소스는 등록관 CSE에 등록되는 원격 CSE를 나타낸다. <remoteCSE>는 <CSEBase> 바로 아래에 배치될 수 있다. 역으로, 각 등록된 CSE는 등록 CSE의 <CSEBase>내의 <remoteCSE>의 서브셋으로 표현될 수 있다. 예를 들어, CSE1이 CSE2에 등록하면, 생성된 2개의 <remoteCSE>가 존재할 수 있다. 즉, CSE1<CSEBase>/<remoteCSE2>에 하나 및 CSE2<CSEBase2>/<remoteCSE1>에 하나가 존재할 수 있다. 2개의 리소스의 생성이 상호 등록(mutual registration)을 반드시 암시하는 것은 아니다. 상술한 예시에서 <CSEBase1>/<remoteCSE2>가 CSE1에 등록된 CSE2를 자동적으로 의미하는 것은 아니다.

<remoteCSE> 리소스는, 예를 들어, 표 4에 리스트된 바와 같은, 차일드 리소스를 포함할 수 있다.

도 4b에는 <remoteCSE> 리소스와 함께 포함된 차일드 리소스의 예시가 리스트된다.

<remoteCSE>의 차일드 리소스 이름	차일드 리소스 유형	다중도	설명	<remoteCSEAnnc> 차일드 리소스 유형
[variable]	<AE>	0..n		AE <AEAnnc>
[variable]	<container>	0..n		<container> <containerAnnc>
[variable]	<group>	0..n		<group> <groupAnnc>
[variable]	<accessControlPolicy>	0..n		<accessControlPolicy> <accessControlPolicyAnnc>
[variable]	<subscription>	0..n		<subscription>
[variable]	<pollingChannel>	0..n	requestReachability가 거짓(FALSE)이면, 이러한 <remoteCSE>를 생성했던 CSE는 <pollingChannel> 리소스를 생성하고 긴 폴링(polling)을 수행해야 함	<pollingChannel>
[variable]	<schedule>	0..1	이 리소스는 노드의 도달 가능성 스케줄 정보를 정의함	<scheduleAnnc>

일부 실시 예들에 있어서, <remoteCSE> 리소스는 표 5에 리스트된 속성을 포함할 수 있다.

<remoteCSE>의 속성 이름	다중도	RW/ RO/ WO	설명	<remoteCSEAnnc> 속성
resourceType	1	RO		NA
parentID	1	RO		NA
creationTime	1	RO		NA
lastModifiedTime	1	RO		NA
expriationTime	1	RW		MA
accessControlPolicies	0..n	RW		MA
labels	0..1	RW		MA
announceTo	1	RW		NA
announcedAttribute	1	RW		NA
cseType	1	WO	생성된 리소스에 의해 표현된 CSE 노드의 유형을 나타냄	OA
pointOfAccess	0..n	RW	요청-도달가능 원격 CSE의 경우, 그것은 그것에 접속시키는데 이용될 물리적 어드레스들의 리스트를 나타냄(예를 들어, IP 어드레스, FQDN). 원격 CSE가 요청-도달 가능하지 않을 때 속성은 없음	OA
CSEBase	1	WO	원격 CSE에 의해 표현된 원래 CSE의 CSEBase의 URI	OA
CSE-ID	1	WO	글로벌하게 유일한 CSE 식별자	OA
M2M-Ext-ID	0..1	RW	단지 IN-CSE에서만 지원됨. 이 속성은 M2M-Ext-ID와 CSE-ID의 동적 연관성의 경우에만 이용됨	NA
Trigger-Recipient-ID	0..1	RW	단지 IN-CSE에서만 지원됨. 이 속성은 M2M-Ext-ID와 CSE-ID의 동적 연관성의 경우에만 이용됨	NA
requestReachability	1	RW	이 <remoteCSE>를 생성했던 CSE가 다른 AE/CSE(들)로부터 요청을 수신할 수 있으면, 이 속성은 "참(TRUE)"으로 설정되고, 그렇지 않으며, "거짓(FALSE)"으로 설정됨. 이 속성이 "거짓(FALSE)"으로 설정될지라도, 모든 엔티티에 의해 항상 AE/CSE가 도달할 수 없음을 의미하는 것은 아님. 예를 들어, 요청 AE/CSE는 동일한 NAT 뒤에 있으며, 그래서 그것은 동일한 NAT내에서 통신할 수 있음	OA
nodeLink	0..1	RO	노드 특정 정보를 저장하는 <node> 리소스의 기준 URI	OA

일부 실시 예들에 있어서, <remoteCSE> 및 공표된 <remoteCSE>는 2개의 리소스들을 구별할 수 있도록 구현하기 위한 다른 리소스 유형 코딩을 가질 것이다.

oneM2M 시스템에 있어서의 구현을 위한 예시적인 실시 예

본 문서에서 개시된 일부 기술들을 구현하기 위해, 일부 실시 예들에 있어서, 현재의 oneM2M 사양이 수정될 수 있는 방법을 설명하기 위한 예시적인 수정들이 제공된다. 그 예시는, 다른 것들 중에서도, 애플리케이션 엔티티 또는 공통 서비스 엔티티(CSE)로부터 공표된 속성을 생성 및 삭제하기 위한 oneM2M에서 지정된 현재 절차에 대해 이루어진 변경을 개시하며, 또한, 기원(original) 리소스 호스팅 CSE(original resource hosting CSE)에 의해 속성을 공표하고 공표 철회(de-announce)하기 위한 새로운 기술을 개시한다.

속성 공표 및 공표 철회를 지원하는 방법을 제안하기 위해 일부 수정이 제시된다. 속성 공표/공표 철회는 갱신(UPDATE) 및 삭제(DELETE) 동작을 이용하여 지원된다.

예시 1

10.2.18.6 AE 및 CSE가 공표된 속성의 생성을 개시하기 위한 절차

이 절은 AE 및 CSE가 공표된 속성(속성 공표)의 생성을 개시하기 위한 절차를 설명한다.

발신자(originator): 속성 공표를 개시하기 위한 요청의 발신자는 AE 또는 CSE일 수 있다. 발신자는 기원 리소스에서의 announcedAttribute 속성의 갱신에 의해 속성 공표를 요청할 수 있다.

발신자는 기원 리소스에서의 announcedAttribute 속성을 갱신할 수 있는데, 이것은 갱신(UPDATE) 요청을 이용하여 공표될 필요가 있는 속성을 그것에 추가함에 의해 이루어진다. 단지 OA로 마킹된 속성만이 원격 공표 리소스(remote announced resource)에 공표될 수 있다.

수신자: 발신자가 성공적으로 인증되었으면, 기원 리소스 호스팅 CSE일 수 있는 수신자는 그 요청의 성공적인 확인후 그 요청을 승인할 수 있다.

OA로서 마킹되지 않은, 요청에서 수신된 속성들은 유효하지 않다.

기원 리소스 구조에 존재하지 않는, 그 요청에서 수신된 속성들은 유효하지 않다.

요청에서 수신된 일부 속성들이 announcedAttribute 속성에 아직 존재하지 않으면, 수신자는 10.2.18.8 절에서의 절차에 따라 announceTo 속성에 리스트된 모든 공표된 리소스들에 그러한 속성들을 공표할 수 있다.

10.2.18.8 절에서의 절차에 따라 속성들의 성공적인 공표시, 수신자는 이하를 실행할 수 있다.

수신자는 10.1.3절에서 지정된 갱신(UPDATE) 응답으로 요청 AE/CSE에 응답할 수 있다. 공표된 속성의 콘텐츠는 그러한 응답에서 제공될 수 있다.

표 10.2.18.6-1: 공표된 속성들의 생성

예시 2

10.2.18.7 AE 및 CSE가 공표된 속성의 삭제를 개시하기 위한 절차

이 절은 AE 및 CSE가 공표된 속성의 삭제(속성 공표 철회)를 개시하기 위한 절차를 설명한다.

발신자: 속성 공표 철회를 개시하기 위한 요청의 발신자는 AE 또는 CSE일 수 있다. 발신자는 아래와 같이 기원 리소스에서의 announcedAttribute 속성의 갱신에 의해 속성 공표 철회를 요청할 수 있다.

발신자는 갱신(UPDATE) 요청을 이용하여 공표 철회될 필요가 있는 속성을 삭제함에 의해 기원 리소스에서의 announcedAttribute 속성을 갱신한다. 단지 OA로 마킹된 속성들만이 원격 공표 리소스에 대해 공표 철회될 수 있다.

수신자: 발신자가 성공적으로 인증되었으면, 기원 리소스 호스팅 CSE일 수 있는 수신자는 그 요청의 성공적인 확인 후 그 요청을 승인할 수 있다.

OA로 마킹되지 않은 요청에서 수신된 속성들은 유효하지 않다.

announcedAttribute 속성에 존재하는 일부 속성들이 요청에서 수신되지 않으면, 수신자는 10.2.18.9 절에서의 절차에 따라 announceTo 속성에 리스트된 모든 공표된 리소스들에 대해 그러한 속성들을 공표 철회할 수 있다.

10.2.18.9 절에서의 절차에 따라 모든 속성들의 성공적인 공표 철회시, 수신자는 이하를 실행할 수 있다.

수신자는 10.1.3절에서 지정된 갱신(UPDATE) 응답으로 요청 AE/CSE에 응답할 수 있다. 공표 철회된 속성들의 이름들이 그러한 응답에서 제공될 수 있다.

표 10.2.18.7-1: 공표된 속성들의 삭제

예시 3

10.2.18.8 속성을 공표하기 위한 기원 리소스 호스팅 CSE에 대한 절차

이 절은 원격 공표 리소스에 공표 속성을 생성하기 위해(즉, 속성 공표) 기원 리소스 호스팅 CSE에 의해 이용될 수 있는 절차를 설명한다.

발신자: 이 요청의 발신자는 기원 리소스 호스팅 CSE일 수 있다. 발신자는 10.1.3절에 특정된 바와 같이 갱신(UPDATE) 요청을 이용하여 공표 리소스에 공표 속성을 생성하도록 요청할 수 있다.

수신자: 발신자가 성공적으로 인증되었으면, 수신자(CSE 호스팅 공표 리소스)는 그 요청의 성공적인 확인 후에 그 요청을 승인할 수 있다. 수신자는 이하를 수행한다.

10.1.3절에 있는 부분적인 어드레싱(partial addressing)을 위한 절차에 따라 공표 리소스에 공표 속성을 생성.

10.1.3에서 처럼 갱신(UPDATE) 응답으로 발신자에게 응답.

수신자로부터 응답을 수신한 후 발신자는 이하의 단계를 수행할 수 있다: 공표된 속성이 성공적으로 생성되었으면, announcedAttribute 속성은 성공적으로 공표된 속성에 대한 속성 이름을 포함하도록 갱신될 수 있다.

announcedAttribute 속성에 있어서의 새로 공표된 속성에 대해, 발신자는 10.1.3절에서 처럼 갱신(UPDATE) 동작을 이용함에 의해 공표 리소스에서의 그들의 값이 계속 동기화되도록 하는 것을 담당한다.

표 10.2.18.8-1 속성:갱신(UPDATE)을 공표하기 위한 기원 리소스 호스팅 CSE

예시 4

10.2.18.9 속성을 공표 철회하기 위한 기원 리소스 호스팅 CSE에 대한 절차

이 절은 원격 공표 리소스에서의 공표 속성을 제거하기 위해(즉, 속성 공표 철회) 기원 리소스 호스팅 CSE에 의해 이용될 수 있는 절차를 설명한다.

발신자: 이 요청의 발신자는 기원 리소스 호스팅 CSE일 수 있다. 발신자는 10.1.4절에서 특정된 바와 같이 삭제(DELETE) 요청을 이용하여 공표된 속성을 제거하도록 요청할 수 있다.

수신자: 발신자가 성공적으로 인증되었으면, 수신자(CSE 호스팅 공표 리소스)는 그 요청의 성공적인 확인 후 그 요청을 승인할 수 있다. 수신자는 다음을 실행할 수 있다:

10.1.4절에서의 부분적인 어드레싱을 위한 절차에 따라 공표 철회된 속성을 삭제.

10.1.4절에서 처럼 적당한 삭제(DELETE) 응답으로 발신자에게 응답.

수신자로부터 응답을 수신하는 후 발신자는 이하의 단계들을 수행한다: 공표 철회된 속성이 성공적으로 제거되었으면, announcedAttribute 속성은 성공적으로 공표 철회된 속성에 대한 속성 이름들을 제거하도록 갱신될 수 있다.

표 10.2.18.9-1 속성:삭제(DELETE)를 공표 철회하기 위한 기원 리소스 호스팅 CSE

현재의 oneM2M 사양에 대한 가능한 수정

그 수정은 oneM2M에서의 부분적인 어드레싱에 대한 지원을 제안한다. 그러한 부분적인 어드레싱은 갱신(UPDATE) 및 삭제(DELETE) 동작의 이용에 의해 지원되도록 제안된다.

예시 5

8.1.1 설명

도 5는 요청 및 응답 기법의 이용에 기초한, 절차 내의 정보 교환을 다루는 통신의 전반적인 흐름을 보여주는 예시적인 도면이다. 이 기법은, 예를 들어,

AE와 CSE(Mca 기준 포인트)간; 및

CSE들(Mcc 기준 포인트)간의

통신에 적용된다.

그 통신은 요청 메시지에 있어서의 동작에 의거하여 AE 또는 CSE에 의해 개시될 수 있다.

8.1.2 요청

발신자로부터 수신자로의 요청은 이하의 정보를 포함한다.

to: 동작에 대한 목표 리소스 또는 목표 속성의 URI. to 정보는 9.3.1절에 따른다.

to 목표 리소스 또는 목표 속성은 발신자에 의해 알려질 필요가 있다. 그것은 사전-프로비너닝 또는 발견에 의해 알려질 수 있다.

용어, 목표 리소스는 항상 특정 동작에 대해 어드레싱되는 리소스를 지칭한다. 예를 들어, 리소스 "example"에 대한 생성 동작의 to 파라메타는 "/m2m.provider.com/exampleBase"일 수 있다. 동일한 리소스 "example"의 검색 동작의 to 파라메타는 "/m2m.provider.com/exampleBase/example"이다. 검색(RETRIEVE) 동작으로 특정 속성을 어드레싱하는데 이용될 때, 상기 예시에 있어서 "container" 속성에 대한 to 파라메타는 "/m2m.provider.com/exampleBase/example/container"이다.

fr: 발신자를 나타내는 식별자.

fr 정보는 액세스 권한 검증을 위한 발신자 신원을 체크하기 위해 수신자에 의해 이용될 수 있다.

cn: 전달될 리소스 콘텐츠.

op: 실행될 동작: 생성(Create(C)), 검색(Retrieve(R)), 갱신(Update(U)), 삭제(Delete(D)).

op 정보는 수신자에서 실행될 동작을 나타낸다.

생성(Create(C)): to 파라메타로 어드레싱할 수 있는 새로운 리소스가 생성된다.

검색(Retrieve(R)): 기존의 to 어드레싱 가능 리소스(existing to addressable resource)가 판독되어 발신자에게 다시 제공된다.

갱신(Update(U)): 기존의 to 어드레싱 가능 리소스의 콘텐츠가 cn 파라메타에서 처럼 새로운 콘텐츠로 대체된다. cn 파라메타에 있어서의 일부 속성들이 목표 리소스에 존재하지 않을 경우, 그러한 속성은 할당된 값에 의해 생성된다.

삭제(Delete(D)): 기존의 to 어드레싱 가능 리소스 및 모든 그의 서브-리소스들이 리소스 저장부로부터 삭제된다. 특정 속성을 어드레싱하는 to 파라메타의 경우, 그러한 속성은 리소스 저장부로부터 삭제된다.

통지(Notify(N)): 수신자상에서의 프로세싱한 수신자에 대한 정보는 발신자에 의해 표시되지 않는다.

ty 정보는 이하의 동작을 위해 요청에 존재할 수 있다:

생성(Create): ty는 생성될 리소스의 유형이다.

cn: 전달될 리소스 콘텐츠.

cn 정보는 이하의 동작을 위해 요청에 존재할 수 있다:

생성(Create): cn은 표 9.2-1에서 처럼 리소스 유형 태그를 가진 새로운 리소스의 콘텐츠이다.

갱신(Update): cn은 기존 리소스내에서 대체될 콘텐츠이다. cn은 또한 to 파라메타에 의해 어드레싱되는 리소스에서 생성될 속성에 대한 그들의 연관 값을 가진 새로운 속성을 포함할 수 있다.

검색(Retrieve): cn은 발견을 위해 적용될 필터이다.

통지(Notify): cn은 통지 정보이다.

cn 정보는 또한 비어있을 수 있음을 알아야 한다.

다른 허용된 정보는 다음과 같다:

nm: 생성될 리소스의 선택적 이름.

그 이름의 예시적인 이용은, 생성(Create) 리소스의 발신자가 새로 생성된 리소스의 식별자로서 이용되기를 원하는 이름을 포함한다. 이름"myContainer"를 가진 콘테이너(container)를 생성하기 위해, 그 요청은 파라메타 nm에 값 "myContainer"를 제공할 것이며, 생성된 리소스는 /<SCEBase>/myContainer일 수 있다.

ot: 메시지가 구축되었을 때의 선택적 발신 타임스탬프(timestamp).

발신 타임스탬프의 예시적인 이용은 동작(예를 들어, 메시지 로깅(message logging), 상관, 메시지 우선 순위화/스케줄링, 허용 성능 요청, 과금 등)을 측정 및 인에이블링하고, 성능(예를 들어, 분배 및 프로세싱 대기 시간, 폐루프 대기 시간, SLA들, 분석등)을 측정하는 것을 포함한다.

rqet: 선택적 요청 메시지 만료 타임스탬프.

요청 만료 타임스탬프의 예시적인 이용은, 요청 메시지가 더 이상 가치가 없는 그들의 부실(staleness)로 인해 만료되어야 하는 때를 나타내고, 메시지 스케줄링/우선 순위화를 알려주는 것을 포함한다. 요청이 요청 만료 타임스탬프를 특정 시간으로 설정했고, 그 요청이 그 요청을 현재 처리하고 있는 CSE가 아닌 호스팅 CSE상에서의 동작을 요구하면, 현재 CSE는 프로비저닝된 정책과 일치하게 요청 만료 타임스탬프 시간까지 호스팅 CSE에 그 요청을 배달하려는 시도를 계속할 수 있다.

rset: 선택적 결과 메시지 만료 타임스탬프.

결과 만료 타임스탬프의 예시적인 이용은, 더 이상 가치가 없는 결과의 예상된 부실로 인해 결과 메시지(지연-공차를 포함)가 만료되어야 하는 때를 나타내고, 메시지 스케줄링/우선 순위화를 알려주는 것을 포함한다. 그것은 최대 허용 전체 요청/결과 메시지 시퀀스 라운드 트립 기한(maximum allowed total request/result message sequence round trip deadline)을 설정하는데 이용될 수 있다.

rt: 선택적 응답 메시지 유형. 이것은 발행된 요청에 대한 응답이 무엇을 포함하고 있는지, 및 그 응답이 언제 발신자에게 전송되는지를 나타낸다.

긍정 응답(Acknowledgement): 요청이 로컬 CSE에 의해 허용되는 경우, 로컬 CSE는, 허용 후에, 로컬 CSE가 추가로 그 요청을 처리할 것을 확인하는 긍정 응답(Acknowledgement)으로 응답한다.

결과(Result): 요청이 로컬 CSE에 의해 허용되는 경우, 로컬 CSE는, 요청된 동작의 완료 후에 요청된 동작의 결과로 응답한다.

긍정 응답에 설정된 응답 유형의 예시적인 이용: 통신 시간과 에너지 소모를 최소화하도록 최적화된 발신자는 로컬 CSE에 요청을 표명하고, 그 요청이 허용되는지에 대한 긍정 응답을 획득하기를 원한다. 이 후, 발신자는 보다 덜한 전력 소모 모드로 절환되어 나중에 요청된 동작의 결과를 검색한다.

rd: 선택적 결과 메시지 도착지(destination).

로컬 CSE: 로컬 CSE는, 허용된 요청에 대한 응답에 있어서, 추후에 그 요청의 상태 및 요청된 동작의 결과를 액세스하는데 이용될 수 있는 기준(reference)을 포함한다.

발신자: 요청된 동작의 결과는 발신자에게 통지로서 전송될 필요가 있다.

로컬 CSE에 대해 설정된 결과 도착지의 예시적인 이용은, 결과 콘텐츠가 극도로 큰 시점, 또는 그 결과가 시간에 걸쳐 비동기적으로 집합될 목표 그룹으로부터 다수의 콘텐츠 부분들로 구성되는 시점을 포함한다.

rc: 선택적 결과 메시지 콘텐츠. 이 콘텐츠는 요청 동작의 결과의 예상되는 컴포넌트(component)들이 무엇인지를 나타낸다. 요청의 발신자는 동작의 결과를 다시 돌려받을 필요가 전혀 없다. 이것은, rc 정보내에 표시될 수 있다. rc의 정확한 설정은 op에 지정된 요청 동작에 의존할 수 있다. rc의 가능한 값은 다음과 같다:

"리소스(resource)": 다른 리소스에 대한 요청된 리소스의 링크의 어떠한 언급없이, 단지 요청된 리소스에 대한 표시(representation)만이 콘텐츠로서 복귀될 것이다. 이것은 디폴트 값(default value)이다.

"리소스;링크들(resource;links)": (아마도 최대 개수의 검색된 링크에 의해 제한되는) 다른 리소스에 대한 모든 링크들과 함께 요청된 리소스의 표시가 콘텐츠로서 복귀될 것이다.

"링크(links)": (아마도 최대 개수의 검색된 링크에 의해 제한되는) 다른 리소스에 대한 요청된 리소스의 링크들만이, 요청된 실제 리소스의 어떠한 표시없이, 콘텐츠로서 복귀될 것이다.

"무(nothing)": 무(nothing)는 응답의 콘텐츠로서 복귀될 수 있다.

"결과-통지(result-notification)": 동작이 완료되면 통지가 복귀될 것이다.

편집 주석(Edition Note): rc에 대해 설정된 것에 대한 세부 사항은, 요청 가능한 특정 동작이 정의될 때(예를 들어, AE를 등록하고, 콘테이너의 콘텐츠를 수정하는 등) 나중에 추가될 수 있다.

rp: 선택적 응답 지속. 이것은 응답을 포함하는 어드레스가 지속되는 기간을 나타낸다.

응답 지속의 예시적인 이용은 시간에 걸쳐 비동기적으로 집합된 응답 콘텐츠를 처리하기 위해 분석을 위한 충분한 지속을 요청하는 것을 포함한다. 결과 만료 타임스탬프가 특정되면, 응답 지속은 결과 만료 시간 이상 지속해야 한다.

ri: 요청 식별자.

요청 식별자의 예시적인 이용은 요청과 많은 응답들 중 하나간의 상관을 인에이블링하는 것을 포함한다.

oet: 선택적 동작 실행 시간. 그 시간은, 특정된 동작 op가 목표 CSE에 의해 실행될 시간을 나타낸다. 목표 CSE는 동작 실행 시간에 시작하는, 동작 실행 시간 표시자가 설정된 요청의 특정된 동작을 실행할 수 있다. 실행 시간이 이미 지났거나 표시자가 설정되지 않을 경우, 설정된 요청 만료 시간에 도달되지 않았더라도, 특정된 동작은 즉시 실행될 수 있다.

동작 실행 시간의 예시적인 이용은 동작 실행 시간에 동기적으로 실행될 흐름들의 비동기적 분산을 포함한다.

주석(NOTE) 4: 시-기반 흐름은 CSE에서 이용할 수 있는 시간 서비스에 의거하여 지원받지 못할 수 있다.

ec: 선택적 이벤트 카테고리(optional event category). 이 카테고리는 이 요청을 조정하는데 이용되어야 하는 이벤트 카테고리를 나타낸다. 이벤트 카테고리는 원격으로 호스팅된 리소스를 액세스하도록 하는 요청이 어떻게 CMDH CSF에서 처리되는지에 대해 영향을 준다. CMDH를 통한 접속의 선택 및 스케줄링은 다른 카테고리들을 구별할 수 있는 정책에 의해 이루어질 수 있다.

특정 값 X로 설정된 "이벤트 카테고리"의 예시적인 이용: 그 요청이 로컬 CSE와는 다른 호스팅 CSE상에서 실행될 동작을 요구중일 때, 그 요청은 호스팅 CSE으로의 경로 상에서 그 요청을 현재 처리하고 있는 CSE에 저장될 수 있는데, 이것은, 그 이벤트 카테고리 X가 호스팅 CSE로의 경로상의 다음 CSE에 도달하도록 통신 링크를 이용하는 것이 프로비저닝된 정책들에 의해 허용될 때까지 또는 요청 만료 타임스탬프가 만료될 때까지, 이루어진다.

da: 선택적 배달 집합 온/오프. 이것은 동일한 목표 CSE(들)로의 하나 이상의 원래 요청의 전송을 표명하기 위해 <배달(devivery)> 리소스의 CRUD 동작을 이용한다.

da가 선택적이기 때문에, 요청내에 존재하지 않을 때 이용될 디폴트 값이 있을 수 있다. 이 파라메타는 Mca를 통해 AE에 노출되지 않을 수 있다.

배달 집합 세트 온(delivery aggregation set on)의 예시적인 이용: 요청을 처리하는 CSE는 목표 CSE로의 경로상의 다음 CSE에 대한 <배달(delivery)> 리소스의 생성(CREATE)을 요청함에 의해 동일 목표 CSE에 대한 요청들의 집합을 이용할 수 있다.

gid: 선택적 그룹 요청 식별자: 그룹의 각 부재로 분산될 그룹 요청에 추가된 식별자

fc: 선택적 필터 기준: 필터링된 검색 동작에 대한 조건들은 표 8.1.2-1에 설명된다.

표 8.1.2-1: 필터 기준 조건들

HTTP 질의에 있어서 필터 기준 조건들의 예시적인 이용: 요청 그 자체의 질의 부분에 있어서 필터를 적용하는 HTTP GET 동작이 요청될 수 있다.

GET/root?label=one&label=two&createdBefore=2014-01-01T00:00:00&limit=128

그 예시는 createdBefore<2014-01-01T00:00:00 AND (label=one OR lable=two)와 같은 논리적 조건과 매칭되는 최대 128개의 리소스들을 발견한다.

일단 요청이 배달되면, 수신자는 목표 리소스를 결정하기 위해 그 요청을 분석한다.

목표 리소스가 또 다른 M2M 노드를 어드레싱중이면, 수신자는 그 요청을 적당하게 라우팅(routing)한다.

목표 리소스가 수신자를 어드레싱중이면, 그것은,

to 어드레싱된 리소스의 존재를 체크하고,

표 9.2.1에서 처럼 태그 값으로 리소스 유형을 식별하고,

요청된 동작을 실행하기 위해 fr 발신자에 대한 권한을 체크하고,

상술한 바와 같이 제공된 요청 파라메타들에 따라 (cn 콘텐츠가 제공될 경우, 그것을 이용하여) 요청된 동작을 실행하고,

요청 결과 콘텐츠에 의거하여, 성공적인 또는 성공하지 못한 동작 결과의 표시로 발신자에게 응답한다. 일부 특정 경우(예를 들어, 애플리케이션 표시에 기초한 또는 바인딩 프로토콜(binding protocol)에 있어서의 제한)에, 그 응답은 회피될 수 있다.

발신자 요청 메시지와 함께 시작된 메시지 흐름 절차는,

요청 메시지가 rqet(요청 만료 타임스탬프)에 따라 만료될 때, 또는

요청 메시지가 발신자에게 배달될 때,

끝나는 것으로 간주될 수 있다.

8.1.2.1 요청 메시지 파라메타들의 요약

표 8.1.2.1-1은 C, R, U, D 또는 N 동작에 적용되는 것과 같은 임의의 차이를 보여주는, 요청 메시지에 대해 8.1.2절에서 지정된 파라메타들을 요약한 것이다. "M"은 필수적임을 나타내고, "O"는 선택적임을 나타내며, "N/A"는 "적용할 수 없음"을 나타낸다.

표 8.1.2.1-1: 요청 메시지 파라메타들의 요약

예시 6

8.1.3 성공적인 동작

요청된 동작의 성공적인 완료의 경우에, 수신자로부터 요청의 발신자에게로의 응답은 이하의 정보를 포함한다.

to: 선택적. 발신자의 ID. 이것이 비-차단(non-blocking) 요청에 의해 트리거링된 동작의 결과를 소지한 응답인 경우에, "rd" 정보가 이용될 수 있다.

fr: 선택적. 수신자의 ID.

rs: 동작 결과: 예를 들어, 오케이(Okey), 오케이 및 실행됨; 오케이 및 스케줄링됨; 오케이 및 진행 중 등.

cn: 전달되거나 생성될(선택적) 선택적 리소스 콘텐츠

메타 데이터는 다음을 포함한다:

ot: 메시지가 구축되었을 때의 선택적 발신 타임스탬프.

rset: 선택적 결과 만료 타임스탬프. 수신자는, 요청 메시지에서 설정되면 결과 만료 타임스탬프를 반영하거나 결과 만료 타임스탬프 그 자체를 설정할 수 있다.

결과 만료 타임스탬프를 설정하는 수신자의 예시적인 이용은, 배달 시간의 값이, 예를 들어 속도에 기초한 항공기 위치에 대한 결과 메시지 마감과 같은 수신자 콘텍스트의 일부 변경에 의존할 때이다.

ri: 요청 식별자.

응답에 있어서의 ri는 대응하는 요청에 있어서의 ri와 매칭될 수 있음을 알아야 한다.

cs: 선택적인 상태 코드(예를 들어, 인증 타임아웃(timeout) 등).

ra: 종단 노드 응답의 임시 저장을 위한 선택적인 어드레스.

cn 정보는 이하의 경우에 응답에 존재할 수 있다.

생성(Create): cn은 생성된 리소스의 어드레스 및/또는 콘텐츠이다.

갱신(Update): cn은 기존 리소스에서 대체된 콘텐츠이다. cn은 새롭게 생성된 속성 및 그들의 값들이다.

삭제(Delete): cn은 실제 삭제된 콘텐츠이다.

cn 정보는 이하의 경우에 응답에 존재할 수 있다.

검색(Retrieve): cn은 발견된 리소스의 검색된 리소스 콘텐츠 또는 집합된 콘텐츠이다.

8.1.4 성공하지 못한 동작

요청된 동작의 성공하지 못한 완료의 경우에, 요청의 수신자로부터 요청의 발신자로의 응답은 이하의 정보를 포함한다.

to: 선택적. 발신자의 식별자. 이것이 비-차단 요청에 의해 트리거링된 동작의 결과를 소지하는 응답인 경우, "rd" 정보가 이용될 수 있다.

fr: 선택적. 수신자의 식별자

rs: 동작 결과: 예를 들어, 오케이가 아님.

cn: 선택적, 상태 코드(예를 들어, 인증, 타임아웃 등).

메타 정보는 다음을 포함한다:

ot: 메시지가 구축되었을 때의 선택적인 발신 타임스탬프.

rset: 선택적 결과 만료 타임스탬프.

ri: 요청 식별자

응답에 있어서의 ri는 대응하는 요청에 있어서의 ri와 매칭될 수 있음을 아라야 한다.

cs: 선택적, 상태 코드(예를 들어, 인증 타임아웃 등).

8.1.5 응답 메시지 파라메타들의 요약

표 8.1.5-1은 성공적인 C,R,U,D 또는 N 동작과 성공하지 못한 동작에 적용되는 임의 차이점을 보여주는, 응답 메시지에 대해 8.1.1 및 8.1.3 절에 특정된 파라메타들을 요약한 것이다. "M"은 필수적임을 나타내고, "O"는 선택적임을 나타내고, "N/A"는 적용할 수 없음을 나타낸다.

표 8.1.5-1: 응답 메시지 파라메타들의 요약

예시 7

10.1.3 갱신(U)

갱신 동작은 목표 리소스에서의 임의 속성에 대해 저장된 정보를 갱신하는데 이용될 수 있다. 갱신은 제때 실행될 필요가 있다. 예를 들어, 정보를 리프레시(refresh)하는데 있어서의 실패, 예를 들어, "ExpirationTime"은 리소스의 삭제로 결과할 수 있다. 발신자 CSE 또는 AE는 요청 메시지내에 그러한 속성(들)의 이름과 그들의 값을 포함시킴에 의해 목표 리소스에서의 특정 속성(들)을 갱신하거나 생성하도록 요청할 수 있다.

발신자는 갱신 요청 메시지를 이용하여 목표 리소스에서의 임의 속성을 갱신하도록 요청한다. 발신자는 갱신될 필요가 있는 속성(들)에 대한 새로운(제안된) 값을 보낼 수 있다. 갱신 동작은 특정 리소스 유형에 대해 "RW"(판독 기록)로 표시된 속성(9.6절에 정의됨)을 수정할 수 있게 한다.

발신자는 갱신 요청 메시지를 이용하여 목표 리소스에서의 속성들을 생성하도록 요청한다. 발신자는 요청 메시지에 있어서의 특정 리소스 유형 및 그와 관련된 값들에 대해 "RW"(판독 기록)으로 표시된 생성될 속성들(9.6절에 정의됨)의 이름을 보낼 수 있다.

요청 메시지에 포함될 정보에 대해서는 8.1.2를 참조하면 된다.

발신자가 일단 성공적으로 인증되었으면, 수신자는 어드레싱된 리소스의 존재, 제공된 속성의 유효성 및 그들을 수정하기 위한 권한을 검증하여, 제공된 속성을 갱신하고, 8.1.3절에 특정된 동작 결과와 함께 응답 메시지를 발신자에게 보낼 수 있다. 제공된 속성이 존재하지 않으면, 어드레싱된 리소스의 존재를 검증한 후, 수신자는 제공된 속성 및 권한을 확인하여 그들을 생성한다. 성공적인 확인시, 수신자는 그들의 관련 값들을 구비한 속성들을 생성하고, 8.1.3절에 특정된 동작 결과와 함께 응답 메시지를 발신자에게 보낸다.

도 6은 리소스를 검색하기 위한 예시적인 절차이다. 단계 001에서, 발신자는 리소스의 검색을 요청할 수 있다. 단계 002에서, 수신자는 요청을 처리할 수 있다. 단계 003에서, 수신자는 요청 메시지로 검색 요청에 응답한다.

도 7에는 리소스를 갱신하기 위한 예시적인 절차가 도시된다. 단계 001에서, 발신자는 갱신 요청 메시지내에 이하의 정보를 보낼 수 있다:

op: U(갱신)

to: 목표 리소스로의 URI

fr: 발신자(AE 또는 CSE)의 ID

cn: 목표 리소스에서 갱신되거나 생성될 속성(들)과 관련된 정보. cn 파라메타에 있어서의 그러한 속성의 이름 및 그와 관련하여 갱신되거나 할당된 값들.

단계 002에서, 발신자가 목표 리소스에 대한 수정을 실시하기 위한 적당한 권한을 가지는지를 수신자가 확인할 수 있다. 성공적인 확인시, 수신자는 요청된대로 리소스를 갱신할 수 있다. 제공된 속성이 존재하지 않으면, 수신자는, 발신자가 목표 리소스에 속성을 생성하기 위한 적당한 권한을 가지는지를 확인할 수 있다. 성공적인 확인시, 수신자는 요청된 대로 리소스에서의 속성을 그들의 관련값들과 함께 생성할 수 있다.

단계 003에서, 수신자는 이하의 정보를 포함하는 응답 메시지로 응답한다.

to: 선택적. 발신자의 ID. 이것이 비-차단 요청에 의해 트리거링된 동작의 결과를 소지한 응답인 경우, rd 정보가 이용될 수 있다.

fr: 선택적. 수신자의 ID.

rs: 동작 결과

cn: 선택적. 대체되거나 생성된 콘텐츠.

통상적인 예외:

to 정보에 있어서의 목표로 된 리소스가 존재하지 않는다. 수신자는 에러로 응답한다.

발신자는 리소스를 수정하거나 수신자상에 속성을 생성하기 위한 권한을 가지지 않는다.

cn에 있어서의 제공된 정보는 수신자에 의해 허용되지 않는다. 수신자는 에러로 응답한다.

예시 8

10.1.4 삭제(D)

삭제 동작은 수신자 CSE에서 리소스를 삭제하기 위해 발신자 CSE에 의해 이용될 수 있다.

삭제 동작은 수신자 CSE에서 목표 리소스로부터 특정 속성을 삭제하도록 하기 위해 발신자 CSE 또는 AE에 의해 이용될 수 있다.0.

삭제 절차는 목표 리소스의 모든 관련된 정보의 삭제를 포함할 수 있다.

발신자는 삭제 요청을 이용하여 리소스 또는 속성을 삭제하도록 요청할 수 있다.

발신자가 성공적으로 인증되었으면, 수신자는 요청된 리소스 또는 속성의 존재와, 그 리소스 또는 속성을 삭제하기 위한 권한을 검증한다.

도 8에는 리소스 또는 속성을 삭제하기 위한 예시적인 절차가 도시된다. 단계 001: 발신자는 수신자에게 삭제 요청 메시지를 보낼 수 있다.

op: D(삭제)

to: 목표 리소스 또는 속성의 URI

fr: 발신자(AE 또는 CSE)의 ID

단계 002에서, 수신자는 요청된 리소스 또는 속성의 존재를 검증하고, 발신자가 리소스/속성을 삭제하기 위한 적당한 권한을 가지고 있는지를 검증한다. 리소스의 삭제의 경우, 성공적인 확인시, 수신자는 칠드런(children) 리소스를 체크하고, 모든 칠드런 리소스 및 페어런트(parent) 리소스내의 관련 기준을 삭제하며, 그것은 리소스 그 자체를 삭제할 수 있다. 속성의 삭제의 경우, 성공적인 확인시, 수신자는 어드레싱된 속성을 삭제할 수 있다.

단계 003에서, 수신자는 이하의 정보를 포함할 수 있는 응답 메시지로 응답할 수 있다.

fr: 선택적. 수신자의 ID.

rs: 동작 결과

통상적인 예외:

to 정보에 있어서의 목표로 된 리소스/속성은 존재하지 않는다. 수신자는 에러로 응답한다.

발신자는 수신자 상의 리소스/속성을 삭제하기 위한 권한을 가지지 않는다. 수신자는 에러로 응답한다.

상술한 예시적인 수정은, 일부 실시 예에 있어서, 본 문서에 개시된 일부 기술을 구현하기 위해, 현재 oneM2M 사양의 특정 부분들이 수정될 수 있는 방법의 예시를 제공한다. 상술한 예시적인 수정은, 다른 것들 중에서, 요청, 검색, 응답, 삭제 및 갱신 메시지의 리소스 또는 속성을 교환하는 oneM2M에서 특정된 현재 절차에 대해 이루어진 변경을 개시한다. 상술한 예시적인 수정은, 또한, 메시지 파라메타에 대한 추가적인 변경을 제공하고, 이들 파라메타들이 전송 디바이스에 의해 이용되고 수신 디바이스에 의해 해독되고 작용할 수 있는 방식들을 제공한다.

상술한 설명에서 참조한 oneM2M 사양은 일부 실시 예를 설명하기 위한 예시로서 이용되며, 개시된 기술의 범주를 제한하기 위한 것은 아니다.

도 9에 도시된 바와 같이, 일부 실시 예에 있어서, M2M 통신 시스템에 있어서의 공표된 리소스로부터 정보를 검색하는 방법(600)은, 공표된 리소스의 어드레스를 특정하고 공표된 리소스의 신원을 포함함에 의해 정보 검색 요청을 발행하고(602), 정보 검색 요청에 응답하여, 정보 응답을 수신하고(604), 수신된 정보 응답을 국소적으로 처리하거나 추가 처리를 위해 다른 M2M에 전송하는 것을 선택적으로 행하는 것(606)을 포함한다.

도 10에 도시된 바와 같이, 일부 실시 예에 있어서, M2M 통신 시스템에 있어서 공표된 리소스로부터 정보를 검색하는 장치(700)는, 공표된 리소스의 어드레스를 특정하고 공표된 리소스의 신원을 포함함에 의해 정보 검색 요청을 발행하는 모듈(702), 정보 검색 요청에 응답하여, 정보 응답을 수신하는 모듈(704), 및 수신된 정보 응답을 국소적으로 처리하거나 추가 처리를 위해 다른 M2M에 전송하는 것을 선택적으로 행하는 모듈(706)을 포함한다.

도 11에 도시된 바와 같이, 일부 실시 예들에 있어서, M2M 통신 시스템에 있어서 공표된 리소스를 삭제하는 방법(800)은, 삭제될 속성이 누락된 리소스의 속성들의 리스트를 생성하고(802), 삭제될 속성을 호스팅하는 M2M 노드에 리스트를 전송하는(804) 것을 포함한다. 그 방법(800)은 도 1 내지 도 10에 대해 본 명세서에서 설명한 기술을 이용할 수 있다.

도 12에 도시된 바와 같이, 일부 실시 예들에 있어서, M2M 통신 시스템에 있어서 공표된 리소스를 삭제하는 장치(900)는, 삭제될 속성이 누락된 리소스의 속성들의 리스트를 생성하는 모듈(902)과, 삭제될 속성을 호스팅하는 M2M 노드에 리스트를 전송하는 모듈(904)을 포함한다.

도 13에 도시된 바와 같이, 일부 실시 예들에 있어서, M2M 통신 시스템에 있어서 공표된 리소스들을 생성하는 방법(1000)은, 발신 M2M 노드에 의해 원래 생성된 속성이 리스트된 생성 요청을 발행하고(1002), 발행된 생성 요청에 대한 승인 응답을 수신하는 것(1004)을 포함한다. 그 방법(1000)은 도 1 내지 10에 대해 본 명세서에서 설명된 기술을 이용할 수 있다.

도 14에 도시된 바와 같이, 일부 실시 예들에 있어서, M2M 통신 시스템에 있어서 공표된 리소스들을 생성하는 장치(1100)는, 발신 M2M 노드에 의해 원래 생성된 속성이 리스트된 생성 요청을 발행하는 모듈(1102)과, 발행된 생성 요청에 대한 승인 응답을 수신하는 모듈(1104)을 포함한다.

M2M 통신 시스템에 있어서의 리소스를 관리하는 기술이 개시됨을 알 것이다.

개시된 다른 실시 예 및 본 문서에서 설명된 기능 동작과 모듈들은 디지털 전자 회로로 구현되거나, 본 문서에서 개시된 구조와 그들의 구조적 등가물을 포함하는 소프트웨어, 펌웨어 또는 하드웨어로 구현되거나, 또는 그들의 하나 이상의 조합으로 구현될 수 있다. 개시된 실시 예 및 다른 실시 예들은 하나 이상의 컴퓨터 프로그램 제품, 즉, 데이터 프로세싱 장치의 동작을 제어하기 위해 또는 데이터 프로세싱 장치에 의한 실행을 위해 컴퓨터 독출 가능 매체상에서 인코딩된 컴퓨터 프로그램 명령어들의 하나 이상의 모듈들로서 구현될 수 있다. 컴퓨터 독출 가능 매체는 기계-독출 가능 저장 디바이스, 기계-독출 가능 저장 기판, 메모리 디바이스, 기계-독출 가능 전파 신호를 실현하는 물질 구성(composition of matter effecting a machine-readable propagated signal) 또는 그들 중 하나 이상의 조합일 수 있다. 용어 "데이터 처리 장치"는, 예를 들어, 프로그램 가능 프로세서, 컴퓨터, 다수의프로세서 또는 컴퓨터를 포함하는, 데이터 처리를 위한 모든 장치, 디바이스 및 기계를 포괄한다. 그 장치는, 하드웨어에 추가하여, 예를 들어, 프로세서 펌웨어, 프로토콜 스택, 데이터베이스 관리 시스템, 운영 시스템 또는 그들 중 하나 이상의 조합을 구성하는 코드와 같은, 해당 컴퓨터 프로그램에 대한 실행 환경을 생성하는 코드를 포함할 수 있다. 전파 신호는, 예를 들어, 적당한 수신기 장치에 전송하기 위한 정보를 인코딩하기 위해 생성된, 기계-생성 전기적, 광학적 또는 전자기적 신호와 같은, 인공 생성 신호이다.

컴퓨터 프로그램(이는 프로그램, 소프트웨어, 소프트웨어 애플리케이션, 스크립(script) 또는 코드로서 알려짐)은 컴파일되거나 해독된 언어를 포함하는 임의 형태의 프로그래밍 언어로 작성될 수 있으며, 자립형 프로그램(stand alone program) 또는 모듈, 컴포넌트, 서브루틴 또는 컴퓨터 환경에 이용하기에 적당한 다른 유닛을 포함하는 임의 형태로 전개될 수 있다. 컴퓨터 프로그램이 파일 시스템내의 파일에 반드시 대응하는 것은 아니다. 프로그램은 다른 프로그램 또는 데이터(예를 들어, 마크업 언어 문서에 저장된 하나 이상의 스크립)를 유지하는 파일의 일부, 해당 프로그램 전용의 단일 프로그램, 또는 다수의 코디네이팅된 파일(coordinated file)(예를 들어, 하나 이상의 모듈, 서브 프로그램들, 또는 코드의 일부를 저장하는 파일들)에 저장될 수 있다. 컴퓨터 프로그램은 통신 네트워크에 의해 상호 접속되고 다수의 사이트들을 통해 분산되거나 하나의 사이트에 배치되는 다수의 컴퓨터들 또는 하나의 컴퓨터상에서 실행되도록 전개될 수 있다.

본 문서에서 설명한 프로세스 및 로직 흐름은 입력 데이터에 대해 동작하고 출력을 생성함에 의해 기능들을 수행하도록 하나 이상의 컴퓨터 프로그램을 실행하는 하나 이상의 프로그램 가능 프로세서에 의해 수행될 수 있다. 프로세스들 및 로직 흐름들은, FPGA(Field Programmable Gate Array) 또는 ASIC(Application Specific Integrated Circuit)와 같은 전용 로직 회로에 의해 수행될 수 있으며, 그 장치는 그 전용 로직 회로로서 구현될 수 있다.

컴퓨터 프로그램의 실행에 적당한 프로세서들은, 예를 들어, 임의 유형의 디지털 컴퓨터의 임의의 하나 이상의 프로세서와, 전용 및 범용 마이크로프로세서를 포함한다. 일반적으로, 프로세서는 판독 전용 메모리 또는 랜덤 액세스 메모리 또는 그 둘 모두로부터 명령어 및 데이터를 수신할 것이다. 컴퓨터의 필수 구성 요소는 명령어를 수행하는 프로세서와, 명령어와 데이터를 저장하는 하나 이상의 메모리이다. 일반적으로, 컴퓨터는, 예를 들어, 자기 또는 마그네토 광학 디스크 또는 광학 디스크와 같은 데이터를 저장하는 하나 이상의 대형 저장 디바이스를 포함하거나, 그 대형 저장 디바이스로부터 데이터를 수신하거나 그 대형 저장 디바이스에 데이터를 전달하거나, 또는 그 두 동작 모두를 수행하도록 동작 가능하게 결합될 수 있다. 그러나, 컴퓨터가 그러한 디바이스들을 가질 필요는 없다. 컴퓨터 프로그램 명령어 및 데이터를 저장하는 판독 가능 매체는, 예를 들어, EPROM, EEPROM 및 플래시 메모리 디바이스와 같은 반도체 메모리 디바이스와; 예를 들어, 내부 하드 디스크 또는 제거 가능 디스크와 같은 자기 디스크와; CD ROM 및 DVD-ROM 디스크와 같은, 모든 형태의 비 휘발성 메모리, 매체, 메모리 디바이스를 포함한다. 프로세서 및 메모리는 전용 로직 회로에 의해 보강되거나 거기에 합체될 수 있다.

본 문서가 많은 특정적인 것을 포함하지만, 이들이 청구 범위에 기재되거나 청구될 수 있는 본 발명의 범주를 제한하는 것으로 이해되어서는 안될 것이며, 오히려 특정 실시 예에 특정된 특징들의 설명으로서 이해되어야 할 것이다. 개별적인 실시 예의 문맥으로 본 문서에서 설명한 임의 특징들은 단일 실시 예들을 조합하여 구현될 수 있다. 역으로, 단일 실시 예의 문맥으로 설명된 여러 특징들은 다수의 실시 예들로 개별적으로 구현되거나 임의 적당한 서브 조합으로 구현될 수 있다. 또한, 상기에서 특징들이 특정 조합으로 작용하는 것으로 설명되고 그와 같이 청구될 수 있지만, 청구된 조합으로부터의 하나 이상의 특징들은 일부 경우에 그 조합으로부터 수행될 수 있고, 청구된 조합은 서브-조합 또는 서브-조합의 변형으로 유도될 수 있다. 유사하게, 도면에 특정 순서로 동작들이 도시되어 있지만, 연속적인 순서로 또는 도시된 특정 순서로 그러한 동작이 수행되어야 하는 것으로 이해되거나 모든 도시된 동작들이 원하는 결과를 달성하도록 수행되어야 하는 것으로 이해되어서는 안된다.

단지 일부 예시와 구현들이 개시된다. 개시된 것에 기초하여, 설명된 예시 및 구현과 다른 구현에 대한 변형, 수정 및 개선이 이루어질 수 있다.

Claims

M2M(Machine-to-Machine) 통신 시스템에 있어서 공표된 속성으로부터 정보를 검색하는 방법으로서,
공표된 속성의 어드레스를 특정하고 공표된 속성의 신원을 포함함에 의해 정보 검색 요청을 발행하고,
정보 검색 요청에 응답하여, 정보 응답을 수신하고,
수신된 정보 요청을 국소적으로 처리하거나, 추가적인 처리를 위해 또 다른 M2M 디바이스에 전송하는 것을 선택적으로 행하는 것을 포함하고,
상기 방법은 AE(Application Entity) 또는 CSE(Common Service Entity)에 의해 실행되는
정보 검색 방법.
삭제
M2M 통신 시스템에 있어서 공표된 속성을 삭제하는 방법으로서,
삭제될 속성이 누락된 리소스의 속성들의 리스트를 생성하고,
삭제될 속성을 호스팅하는 M2M 노드에 상기 리스트를 전송하는 것을 포함하는
방법.
제 3 항에 있어서,
리소스들의 속성들의 리스트를 생성하는 발신자의 ID와, M2M 노드의 식별자 또는 동작 결과 중 적어도 하나를 포함하는 응답을 수신하는 것을 더 포함하는
방법.
제 3 항에 있어서,
목표 리소스에서의 특정 속성을 삭제하기 위해 리소스의 속성들의 리스트를 이용하는 것을 더 포함하는
방법.
M2M 통신 시스템에 있어서 이전에 공표된 리소스들을 생성하는 방법으로서,
발신 M2M 노드에 의해 원래 생성된 속성들이 리스트된 생성 요청을 발행하고,
발행된 생성 요청에 대한 승인 응답을 수신하는 것을 포함하는
방법.
제 6 항에 있어서,
생성된 속성에 대한 갱신 요청을 발행하고,
발행된 갱신 요청에 대한 승인 응답을 수신하는 것을 더 포함하는
방법.
제 7 항에 있어서,
갱신 요청은 목표 리소스에 대한 URI, 갱신 요청을 발행한 발신자의 신원 또는 갱신될 속성과 관련된 정보를 포함하는
방법.
제 7 항에 있어서,
발행된 갱신 요청에 대한 승인 응답은 갱신 요청을 발행한 발신자에서 생성된 속성을 갱신할 수 있게 하는
방법.
제 7 항에 있어서,
발행된 갱신 요청에 대한 승인 응답을 수신하지 않을 경우, 목표 리소스에서의 속성에 대한 또 다른 생성 요청을 발행하는
방법.
M2M(Machine-to-Machine) 통신 시스템에 있어서 공표된 속성으로부터 정보를 검색하는 장치로서,
공표된 속성을 특정하고, 공표된 속성을 포함하는 공표된 리소스의 신원을 포함함에 의해 정보 검색 요청을 발행하는 모듈과,
정보 검색 요청에 응답하여, 정보 응답을 수신하는 모듈과,
수신된 정보 요청을 국소적으로 처리하거나, 추가적인 처리를 위해 또 다른 M2M 디바이스에 전송하는 것을 선택적으로 행하는 모듈을 포함하는
장치.
제 11 항에 있어서,
상기 장치는 AE(Application Entity) 또는 CSE(Common Service Entity)를 포함하는
장치.
M2M 통신 시스템에 있어서 공표된 속성을 삭제하는 장치로서,
삭제될 속성이 누락된 리소스의 속성들의 리스트를 생성하는 모듈과,
삭제될 속성을 호스팅하는 M2M 노드에 상기 리스트를 전송하는 모듈을 포함하는
장치.
제 13 항에 있어서,
리소스들의 속성들의 리스트를 생성하는 발신자의 ID와, M2M 노드의 식별자 또는 동작 결과 중 적어도 하나를 포함하는 응답을 수신하는 모듈을 더 포함하는
장치.
제 13 항에 있어서,
목표 리소스에서의 특정 속성을 삭제하기 위해 리소스의 속성들의 리스트를 이용하는 모듈을 더 포함하는
장치.
M2M 통신 시스템에 있어서 이전에 공표된 리소스들을 생성하는 장치로서,
발신 M2M 노드에 의해 원래 생성된 속성들이 리스트된 생성 요청을 발행하는 모듈과,
발행된 생성 요청에 대한 승인 응답을 수신하는 모듈을 포함하는
장치.
제 16 항에 있어서,
생성된 속성에 대한 갱신 요청을 발행하는 모듈과,
발행된 갱신 요청에 대한 승인 응답을 수신하는 모듈을 더 포함하는
장치.
제 17 항에 있어서,
갱신 요청은 목표 리소스에 대한 URI, 발신자의 신원 또는 갱신될 속성과 관련된 정보를 포함하는
장치.
제 16 항에 있어서,
발행된 갱신 요청에 대한 승인 응답은 갱신 요청을 발행한 발신자에서 생성된 속성을 갱신할 수 있게 하는
장치.
제 16 항에 있어서,
발행된 갱신 요청에 대한 승인 응답이 수신되지 않았을 경우, 목표 리소스에서의 속성에 대한 또 다른 생성 요청을 발행하는 모듈을 더 포함하는
장치.