KR101877188B1

KR101877188B1 - Ｍｑｔｔ 프로토콜을 이용한 서비스 층 상호연동

Info

Publication number: KR101877188B1
Application number: KR1020177004684A
Authority: KR
Inventors: 필립 브라운; 데일 엔. 시드; 폴 엘. 주니어 러셀; 광 루; 윌리엄 로버트 4세 플린; 리쥔 둥; 홍쿤 리; 쉬 리; 칭 리; 충강 왕
Original assignee: 콘비다 와이어리스, 엘엘씨
Priority date: 2014-07-21
Filing date: 2015-07-21
Publication date: 2018-07-10
Also published as: WO2016014516A1; JP2018160272A; KR20170033399A; EP3195566A1; JP6692862B2; EP3195566B1; JP6367465B2; CN106797391B; CN106797391A; US10313858B2; KR20180079475A; JP2017523519A; EP3576379A1; EP3576379B1; US20180213378A1

Abstract

MQTT 서버 기능을 oneM2M CSE 내에 통합하고, 그뿐만 아니라 이러한 CSE-기반의 MQTT 서버들을 자원 주소에 기초하여 토픽 구조 주변에 구성된 네트워크에 상호접속하는 방법들이 제안된다. 이 방법들은, AE, CSE 및 MQTT 서버에 의해 AE-ID로서 이용될 수 있는 식별자를 동적으로 할당, 배정 및 전달할 수 있다. MQTT 서버는, CSE를 호스팅하는 모든 서비스 층 노드에서 MQTT 서버가 이용가능하도록 M2M 서비스 층 내에 상호연동될 수 있다. MQTT 서버-대-서버 접속들은 동적으로 확립될 수 있어서 서비스 층 엔티티들 사이의 트래픽을 용이하게 한다.

Description

ＭＱＴＴ 프로토콜을 이용한 서비스 층 상호연동{SERVICE LAYER INTERWORKING USING MQTT PROTOCOL}

oneM2M 서비스 층은 공통 기능(또는 서비스 능력) 세트로 구성되며, 그 인스턴스화(instantiation)는 공통 서비스 엔티티(CSE; Common Services Entity)라고 한다. 도 1은, 도 1에 도시된 바와 같은 Mca, Mcc 및 Mcn 기준점을 통해 노출되는 oneM2M 서비스 층의 공통 기능을 나타내는 도면이다.

Mca 기준점은, 애플리케이션 엔티티(AE)(102)와 CSE(104) 사이의 통신 흐름을 표기하고, Mcc 기준점은 동일한 M2M 서비스 제공자 도메인 내의 2개의 CSE(104 및 106) 사이의 통신 흐름을 표기한다. Mca 및 Mcc를 통한 통신은, 쌍을 이룬 요청/응답 메시지를 통해 이루어지며, 여기서, 각각의 요청은 타겟 CSE에서 호스팅되는 자원에 관한 특정한 RESTful 동작(예를 들어, 생성, 회수, 업데이트, 삭제)을 수행한다.

Mcc'는 상이한 M2M SP들의 인프라스트럭쳐 도메인에 위치한 CSE들 사이에서 이용된다. Mcn은, 트랜스포트 및 접속 이외의 서비스에 대해 CSE(104)와 기저 NSE(Network Services Entity)(108) 사이에서 이용된다.

oneM2M 서비스 층에서, CSE는 "노드"라고 하는 아키텍쳐적 엔티티에서 호스팅된다. 노드는, a) 하나의 CSE와 0개 이상의 AE, 또는 b) 하나 이상의 AE를 포함하는 기능적 엔티티이다.

도 2는 다양한 타입의 노드 구성을 지원하는 oneM2M 아키텍쳐의 도면이다. 도 2는 간소화된 표현이며 엔티티들 사이의 모든 가능한 구성 또는 관계를 반영하지는 않는다.

도 3은 oneM2M CSE(302)에 의해 수행되는 공통 서비스 기능(CSF; common service function)의 초기 세트를 나타내는 도면이다. 특정한 CSE 구현은 모든 기능을 지원하지는 않지만, 완전한 구현은 도면 내의 모든 기능을 포함할 수 있다.

Uniform Resource Identifier Generic Syntax는 5개의 컴포넌트(방식, 권한, 경로, 질의 및 프래그먼트)의 계층적 시퀀스로 구성된 인터넷 구성이다. 도 4는 oneM2M 어드레싱에서 중요한 Uniform Resource Identifier Generic Syntax의 방식, 권한 및 경로 컴포넌트를 나타내는 도면이다.

oneM2M 서비스 층의 모든 엔티티는 ROA 아키텍쳐에서 자원으로서 표시된다. 서비스 층 노드 상의 AE 또는 CSE의 각각의 인스턴스화는 고유 식별자를 가질 것이 요구된다. 이 고유 식별자는, 그 호스팅 CSE 상의 해당 엔티티에 대한 자원 구조의 루트(또는 베이스) 주소를 나타내는 절대 URI(Uniform Resource Identifier)를 유도하는 데 이용된다. 그 구조 내의 모든 자원은 또한, 계층적 또는 비계층적 방식으로, 타겟 자원을 개별적으로 식별하는 경로 컴포넌트를 갖는 FQDN(Fully Qualified Domain Name) URI를 통해 고유하게 어드레싱될 수 있어야 한다. FQDN은 자원을 호스팅하는 CSE를 포함하는 노드의 네트워크 주소를 제공하며, 경로는 그 노드 상의 타겟 자원의 정확한 위치를 제공한다.

이하의 2가지 예시적인 URI 값은 동일한 자원을 어드레싱하고 상기의 원칙들, 즉, 먼저 계층적 경로 구조를 이용하고 그 다음 비계층적 구조를 이용하는 것을 예시한다.

1) //CSE04.M2MSPabc.com/CSEBase01/alpha/container02/instance01

2) //CSE04.M2MSPabc.com/CSEBase01/resource12345678

URI #2의 밑줄친 부분은 이 예시적인 CSE에 대한 베이스 자원 구조의 주소를 나타내고, 또한 대응하는 CSE 식별자도 구현한다. URI #1의 밑줄친 부분은 "alpha"라는 애플리케이션에 대한 자원 구조의 주소를 나타내고, 또한 대응하는 AE 식별자도 구현한다.

CSE 또는 AE와 연관된 자원 구조는 또한, CSE 또는 AE를 호스팅하는 노드와의 통신을 확립하는 데 이용되는 라우팅 정보 ―일반적으로 하나 이상의 IP 주소― 를 보유하는 PoA(pointOfAccess)라고 알려진 속성을 포함한다. (예를 들어, 통보와 함께) AE를 타겟팅하기 위하여, 먼저 AE가 등록된 CSE에 도달한 다음 AE-PoA 속성의 정보를 이용하여 타겟 AE에 대한 요청을 어드레싱하는 것이 필요하다.

서비스 층 요청/응답 메시지는, 서비스 층 엔티티들 사이의 메시지 이동을 용이하게 하기 위해 애플리케이션 프로토콜을 통해 운반되는 API를 포함한다. 서비스 층은, 자신이 서비스하는 애플리케이션과 하위 네트워크 층 사이에 위치하기 때문에, 도 5에 나타낸 바와 같이 종종 "미들웨어"라고 지칭된다.

ETSI M2M과 oneM2M 양쪽 모두는 초기에 HTTP와 CoAP에 동의했지만, 애플리케이션 프로토콜 층에서 바인딩을 위한 다양한 선택사항이 있다. oneM2M은 MQTT(Message Queuing Telemetry Transport) 프로토콜 바인딩도 지원하기로 약속했다 ―서비스 층의 RESTful 요청/응답(일-대-일) 메시지 쌍과 이벤트-구동형, 퍼블리시/가입(일-대-다) MQTT 프로토콜 사이의 대비에 의해 관심대상이 된 선택. 이러한 차이점들에도 불구하고, MQTT는 프로토콜 오버헤드가 매우 낮고 간단하며 효율적인 설계로 인해 M2M 애플리케이션에 대해 매력적인 선택으로 남아 있다.

MQTT 프로토콜은, 1990년대 말 IBM과 Eurotech에 의해 처음 개발되었다; 이것은 공식 채택(프로세스 진행중) 및 추가 개발을 위해 2013년에 OASIS 표준 기구에 제출되었다. MQTT는, Facebook의 Messenger 모바일 앱에 가장 많이 배치된 제약된 디바이스 및 낮은 대역폭 네트워크에 맞게 구성된 낮은 오버헤드 메시지 큐잉(message queuing) 및 트랜스포트 프로토콜이다.

도 6은 MQTT의 퍼블리시/가입(또는 클라이언트/서버) 모델을 나타내는 도면이다. MQTT의 핵심 요소들은, (퍼블리셔(602)와 가입자(604) 양쪽 모두일 수 있는) 클라이언트들, (중개자라고도 하는) 서버들, 세션들, 가입 및 토픽들이다.

도 7은 MQTT의 요소들을 나타내는 도면이다. HTTP처럼, MQTT 프로토콜은 2개의 역할: 클라이언트(702)와 서버(704)를 구별한다는 점에서 비대칭이다.

MQTT 용어에서, 클라이언트(702)는 MQTT를 이용하는 프로그램 또는 디바이스이다. 이것은 항상 서버로의 네트워크 접속을 확립한다. 클라이언트(702)는

● 다른 클라이언트들이 관심을 가질수도 있는 애플리케이션 메시지를 퍼블리시할 수 있다.

● 수신하기를 원하는 애플리케이션 메시지의 요청에 가입할 수 있다.

● 애플리케이션 메시지 요청의 제거에 대해 가입해지할 수 있다.

● 서버로부터 접속해제할 수 있다.

MQTT 서버(704)는 클라이언트로부터의 접속을 수락하는 엔티티이다. HTTP와는 달리, 이것은 일반적으로 애플리케이션 로직을 실행하지 않고, 대신에 MQTT 서버(704)는 애플리케이션 메시지를 퍼블리시하는 클라이언트와 이를 수신하기 위해 가입한 클라이언트 사이에서 중개자로서 역할한다.

토픽들은 MQTT에서 "Q"이다 ― 이들은 퍼블리셔들을 가입자들과 링크시키기 위하여 서버에 의해 유지되는 메시지 큐(message queue)들로 명명된다. MQTT 클라이언트(702)는 MQTT 서버(704)에 PUBLISH 메시지(즉, 제공된 토픽 명칭에 가입된 임의의 클라이언트에게 불투명한 메시지 페이로드를 전달하는 명령어)를 발행할 때 퍼블리셔의 역할을 취하고, SUBSCRIBE 메시지(즉, 제공된 토픽 필터와 정합하는 임의의 PUBLISH 메시지를 수신하는 명령어)를 MQTT 서버(704)에 발행할 때 가입자의 역할을 취한다. 토픽 필터는 하나 이상의 토픽에 대한 관심을 나타내기 위해 가입(Subscription)에 포함된 표현식(expression)이다. 토픽 필터는 와일드카드 문자(wildcard character)를 포함할 수 있다. PUBLISH 메시지는 3개의 QoS 보증 레벨(최대 한 번, 적어도 한 번, 정확히 한 번) 중 하나와 함께 전달된다.

도 8은 MQTT에서 클라이언트와 서버 사이의 2개 레벨의 부착(attachment)을 표현하는 세션 및 가입을 나타내는 도면이다. 세션(801 및 802)은 클라이언트와 서버 사이의 상태유지(stateful) 상호작용(즉, 활성 TCP/IP 네트워크 접속)이며, 고유 클라이언트 식별자에 의해 식별된다. 세션(801 및 802)은, 클라이언트가 CONNECT 메시지를 서버에 전송하는 것에 의해서만 확립될 수 있다. CONNECT, PUBLISH 및 SUBSCRIBE 메시지 내의 플래그(flag)는 세션이 단절된 경우 세션 상태가 유지되는 방법을 결정한다.

가입(804 및 806)은 서버에 의해 유지되는 하나 이상의 토픽(즉, 메시지 큐)에 대한 클라이언트의 논리적 부착이다. 가입(806)은 단 하나의 세션(801)과 연관되지만, 세션 단절 이벤트시에 보존될 세션 상태를 구성하고, 동일한 클라이언트에 의해 후속 세션이 확립될 때 저장된 가입된 메시지의 전달을 트리거하는 것이 가능하다. 따라서, 가입은 "일시적"(가입 806) 또는 "지속적"(가입 804) 일 수 있다.

가장 높은 QoS 레벨로 동작하는 지속적 가입(804)은 (서버 상의 이용가능한 저장 용량의 한계 내에서) 연관된 클라이언트에 대한 저장-및-포워드 모드로 동작하는 서버를 야기하는 반면, 가장 낮은 QoS 레벨로 동작하는 일시적 가입(806)은 연관된 클라이언트에 대한 통과 모드(pass-through mode)에서 동작하는 서버를 야기한다.

MQTT 네트워크 접속은 클라이언트(702)와 서버(704) 사이에서만 존재한다. MQTT 클라이언트(702)의 관점에서, 모든 인입하는 애플리케이션 메시지는 서버(704)로부터 유래하고, 서버(704)에의 가입으로부터 발생하는 애플리케이션 메시지를 수신하는 MQTT 클라이언트(702)는 네트워크 층(예를 들어, IP)에서 그 메시지를 발신한 클라이언트에 도달조차 하지 못할 수도 있다. 이와 관련하여, 서버(704)가 애플리케이션 메시지 ―토픽 명칭을 그 가입 목록(즉, 토픽 필터)와 대조하여 정합시킴― 를 포워딩할지를 결정하는 메커니즘은 토픽 명칭 필드를 네트워크 주소의 형태로서 취급한다.

그러나, 서버(704)는 가입을 네트워크 접속(예를 들어, IP 주소)과 직접 연관시키지 않기 때문에, 고려해야 할 중간 단계가 있다. 가입은 세션과 연관되며, 세션은 서버에 접속하는 모든 클라이언트에 대해 고유해야 하는 클라이언트 식별자(ClientID)와 연관된다. ClientID는 최대 65,535 바이트의 UTF-8 인코딩된 문자열이다; 그러나, 서버는 길이를 최대 23개의 UTF-8 인코딩된 바이트로 제약할 수 있다. ClientID 메커니즘은 세션 상태의 보존을 허용하고 저장-및-포워드 능력을 인에이블한다(원할 경우).

따라서, MQTT 어드레싱 연관 세트는 다음과 같다:

"/"는 토픽 명칭을 계층적 레벨들로 분할하는 데 이용되는 토픽 레벨 분리자(separator)이다. "#"는 뒤따르는 모든 레벨(들)에서 정합하는 다중-레벨 와일드카드 문자이다. 단 하나의 레벨에서만 정합하는 단일-레벨 와일드카드 문자 "+"도 있다(미도시).

이 예에서, Acme Alarm Co.는 MQTT 서버에 접속하고 그 ClientID 값 "Acme-Alarm-xyz"를 이용하여 세션을 확립했다. 이것은 그 거리 주소(1234 Elm St., Anytown)에 대한 모든 정합에 대응하는 토픽 명칭을 갖는 애플리케이션 메시지에 가입했다. Acme Alarm은 이 위치에서 센서와 네트워크 제어기를 설치했으며 제어기는 토픽 명칭 "/Anytown/Elm St./1234/<sensorX>/<info>"를 갖는 애플리케이션 메시지를 퍼블리시하고 있다. 서버는 인입 애플리케이션 메시지를 Acme에 속하는 이 가입과 비교하고 토픽 정합을 갖는 임의의 메시지를 대응하는 네트워크 접속 주소에 포워딩한다.

MQTT V3.1.1 명세는 다음과 같은 선언(statement)을 포함한다:

단일 엔티티는 MQTT 클라이언트 및 MQTT 서버 구현 모두를 준수할 수 있다. 예를 들어, 인바운드 접속을 수락하고 다른 서버로의 아웃바운드 접속을 확립하는 서버는 MQTT 클라이언트와 MQTT 서버로서 준수해야 한다.

(상기의) MQTT 명세로부터의 준수 선언은, 예약된 프로토콜 필드(일반적으로 클라이언트-서버 접속과 서버-서버 접속을 구별하는 데 필요함)를 이용하는 구현을 다룬다. 그러나, 다음과 같이, 서버-서버 접속을 구별할 필요없이 또한 명세를 위반하지 않고 MQTT 서버들을 상호접속하는 것이 가능하다.

서버들 중 하나만이 이러한 방식으로 구성된 경우, 이들 사이에서, 클라이언트 기능이 내장된 서버를 향하는, 일방향의 트래픽 흐름만이 존재할 수 있다. 이것은, 도 9에 도시된 바와 같이, 다른 서버들에 가입하고 트래픽을 자신을 향하도록 조향할 수 있게 한다.

도 9는 MQTT 서버들 사이의 메시지들의 일방향 흐름을 나타내는 도면이다. 도 9에서, "S1/C1"로 식별된 MQTT 클라이언트(902)는 이전에 서버 S1에 SUBSCRIBE 메시지를 전송하여, 서버 S1이 토픽 필터 "S1/C1/#"로 토픽 큐를 설정하게 했다. 후속해서, 처음 5개 문자들이 "S1/C1"과 동일한 토픽 명칭 필드를 갖는 서버 S1에 도달하는 임의의 PUBLISH 메시지는 ClientS1/C1(902)에 포워딩될 것이다.

독립형 클라이언트들에서 도시된 "퍼블리시" 및 "가입" 기능은, 흐름에 도시된 메시지를 처리할 때 클라이언트가 어떤 역할(퍼블리셔 또는 가입자)을 갖는지를 나타낸다.

서버 S1의 내장 클라이언트 기능(904)에 의해 서버 S2에 전송된 SUBSCRIBE 메시지는 서버 S2가 토픽 필터 "S1/#"로 토픽 큐를 설정하게 한다. 이것은 2개의 서버들 사이에 (단방향) 접속을 형성하는 작업이다. 후속해서, 처음 2개 문자가 "S1"인 토픽 명칭 필드를 갖는 서버 S2에 도달하는 임의의 PUBLISH 메시지는 서버 S1에 포워딩될 것이다. 이런 방식으로, 서버 S1에 접속된 클라이언트는, 서버 S1 또는 서버 S2(또는 서버 S1이 접속을 확립한 기타 임의의 서버)에 접속된 클라이언트에 의해 도달될 수 있다.

서버 S1의 클라이언트(902)가 서버 S2에 DISCONNECT 메시지를 전송함으로써 언제든지 접속이 끊어질 수 있다; 대응하는 (SUBSCRIBE 이전의) CONNECT 메시지는 도시되어 있지 않지만 가정된다. 서버 S2는, 서버 S1의 클라이언트(902)로부터의 접속이 또 다른 서버와 연관되어 있다는 어떠한 표시도 갖고 있지 않다; 서버 S1은 (프로토콜 레벨에서) 서버 S2에게 어떤 다른 클라이언트처럼 나타난다.

도 10은 MQTT 서버들과 어느 한 쪽의 서버에 접속된 클라이언트 사이의 양방향 트래픽 흐름을 나타내는 도면이다. 이 경우, 클라이언트 S1/C1과 S2/C1 양쪽 모두는, 이전에 그들 각각의 서버에 SUBSCRIBE 메시지를 전송하여, 이들 서버들이 도시된 토픽 필터로 토픽 큐를 설정하게 했다. 각각의 서버의 내장된 클라이언트 기능에 의해 전송된 SUBSCRIBE 메시지는, 수신 서버가 원래의 서버 + 클라이언트 조합을 가리키는 토픽 필터로 토픽 큐를 설정하게 한다. 이 동작 쌍이 함께 2개의 서버들 사이에 양방향 접속을 형성한다 ―한 서버에 접속된 클라이언트는 다른 서버에 접속된 클라이언트에 도달할 수 있고, 그 반대의 경우도 마찬가지이다. 따라서, 상이한 서버들에 접속된 클라이언트들 사이에서 요청/응답 메시징이 가능하게 된다.

서버들 사이에 전송된 SUBSCRIBE 메시지들은 서로 독립적(즉, 프로토콜 레벨에서 한 메시지는 다른 메시지를 트리거하지 않음)이라는 점에 유의하는 것이 중요하다. SUBSCRIBE 메시지를 수신하는 서버는, ― 적어도 구현이 표준을 준수해야하는 경우가 아니라면―, 메시지가 순수 클라이언트가 아닌 클라이언트-가능형 서버와 연관되어 있다는 것을 프로토콜에서 시그널링받을 수 있는 방법을 갖지 않는다. 이 시나리오에서 간단한 접근법은, 시스템 초기화의 일부로 서버들 사이에 정적 접속을 확립하되, 각각의 서버는 시작시에 접속을 확립하는 데 필요한 정보로 미리구성되도록 하는 것이다.

대안으로서, 독립형 서버 구현에 내장된 로직은 SUBSCRIBE 메시지의 토픽 필터 필드 내의 특정한 패턴을 서버-발신된 메시지에 대한 마커로서 취급하고 그 마커를 신호로서 이용하여 리턴 방향으로 동반 SUBSCRIBE 메시지(companion SUBSCRIBE message)를 시작할 수 있다. 통합된 서버 기능을 갖춘 상위층 로직은 또한, 필요에 따라 동적으로 접속을 트리거하고 개시할 수 있다.

토픽 명칭 공간에서 관리된 계층적 ―또는 URI형― 구조가 운영되고 토픽 명칭 필드를 채우는 데 이용된 값/주소의 전역적 고유성이 유지되는 한, 협력 서버들에 접속된 클라이언트들 사이의 지속적인 양방향 통신이 가능하다.

oneM2M은 MQTT 프로토콜 바인딩에 대한 기술 명세를 개발하고 있는 중이다. oneM2M 아키텍쳐 내에서 MQTT 서버의 배치와 관련하여 수 개의 구성 대안이 기술 명세에 나와 있지만, 이들 구성들 모두는 MQTT 서버가 MQTT 클라이언트와만 통신하고 oneM2M 서비스 층의 다른 MQTT 서버와는 통신하지 않는 기능적으로 및 논리적으로 별개의 엔티티라는 특성을 공유한다.

도 11은, 모든 AE(1104) 및 CSE(1106 및 1108)로의 접속을 유지하는 서비스 제공자 도메인 내의 단일의 MQTT 서버(1102)를 나타내는 도면이다. 이것은 가장 직접적인 구성이다.

도 12a 및 12b는 oneM2M 실시예에서의 복수의 MQTT 서버의 이용을 나타낸다. 인프라스트럭쳐 도메인 내의 단일의 모놀리식 MQTT 서버에 대한 대안은, 중간 노드들에 복수의 MQTT 서버를 배치하고 (Mca 기준점을 통해서만) 네트워크 엣지에 더 가까운 MQTT를 지원하는 것이다. 또 다른 대안은, 필드 도메인에서 Mca 트래픽을 운반하는 하나의(또는 아마도 더 많은) MQTT 네트워크(들)과 Mcc 트래픽을 다시 인프라스트럭쳐 도메인으로 운반하는 별개의 MQTT 네트워크를 갖는 것일 것이다. 이 시나리오에서, 독립된 MQTT 네트워크들 사이의 상호연동은 oneM2M 서비스 층에 의해 수행될 것이다.

도 13은 MQTT 서버(1302)를 갖는 oneM2M 실시예를 나타낸다. 단일 MQTT 서버(도 11)의 개념을 oneM2M 아키텍쳐 구성(도 2)에 적용하면, 도 13의 예시와 같은 결과를 얻을 수 있다. 임의의 2개의 서비스 층 엔티티들 사이의 트래픽은 MQTT 서버(1302)를 통해 흘러야 하고, 임의의 2개의 서비스 층 엔티티들 사이의 통신은, 이들 양쪽 모두가 MQTT 서버(1302)에 접속되어 있지 않는 한(또는 서비스 층이 MQTT-접속된 엔티티로부터 비-MQTT-접속된 엔티티로 트래픽을 전달하는 추가 로직을 제공하지 않는 한) 가능하지 않다.

도 13에 표시된 구성은 현재 개발 작업에 대한 초점이다. MQTT 서버들을 추가하고 MQTT 서버들 사이에 서비스 층 엔티티들을 재분배할 수 있지만(예를 들어, 도 12에서 제안된 바와 같이 MQTT 서버들을 필드 도메인에 배치), 특정한 MQTT 클라이언트가 접속하는 MQTT 서버의 임의의 변경은 새로운 서버의 네트워크 주소를 미리 클라이언트에 제공할 것을 요구할 것이다. 이것은, MQTT가 클라이언트가 서버를 검색하는 메커니즘을 갖지 않지만, 클라이언트가 항상 서버에 대한 접속을 시작하기 때문이다(따라서, 네트워크 접속이 이루어질 수 있기 전에 네트워크 주소가 클라이언트에게 이용가능해야 한다).

MQTT 서버 기능을 oneM2M CSE 내에 통합하고 이러한 CSE-기반의 MQTT 서버를 자원 주소에 기초하여 토픽 구조 주변에 구성된 네트워크에 상호접속하는 방법이 설명된다. 이것은 전술된 식별자 할당과 네트워크 집중화 및 오버헤드 문제를 해결한다.

이 방법은, AE, CSE 및 MQTT 서버에 의해 AE-ID로서 이용될 수 있는 식별자를 동적으로 할당, 배정 및 전달할 수 있다. 이것은 CSE의 제어 하에서 애플리케이션 등록 프로세스의 일부로서 수행된다.

MQTT 서버는, CSE를 호스팅하는 모든 서비스 층 노드에서 MQTT 서버가 이용가능하도록 M2M 서비스 층 내에 상호접속될 수 있다. 클라이언트 기능을 내장하고 계층적 애플리케이션 층 어드레싱 방식을 적용함으로써 MQTT 서버(본 개시내용에서는 "MQTT 서버+"라고 함)가 강화되어, 모든 CSE에서 MQTT 서버 기능을 배치할 수 있다.

MQTT 서버-대-서버 접속은 동적으로 확립되어 서비스 층 엔티티들 사이의 트래픽을 용이하게 한다. 모든 CSE가 자원 주소에 기초하여 상호접속된 네트워크에서 MQTT 서버 및 클라이언트로서 동작함으로써, 서비스 층 프리미티브는 중간 서비스 층 로직에 의해 다시 처리되지 않고 발신자로부터 타겟으로 직접 전달될 수 있다.

본 요약은, 이하의 상세한 설명에서 더 설명되는 선발된 개념들을 간략화된 형태로 소개하기 위해 제공되는 것이다. 본 요약은, 청구 대상의 핵심 피쳐나 본질적 피쳐들을 식별하기 위함도 아니고, 청구 대상의 범위를 제한하기 위해 이용되는 것도 아니다. 또한, 청구 대상은 본 개시의 임의의 부분에서 언급된 임의의 또는 모든 단점을 해결하는 한도로 제한되지 않는다.

첨부된 도면과 연계하여, 예를 통해 주어지는 이하의 상세한 설명으로부터 더 상세한 이해를 얻을 수 있다. 이하에서:
도 1은 oneM2M 서비스 층의 공통 기능을 나타내는 도면이다.
도 2는 다양한 타입의 노드 구성을 지원하는 oneM2M 아키텍쳐의 도면이다.
도 3은 oneM2M CSE에 의해 수행되는 공통 서비스 기능(CSF; common service function)의 초기 세트를 나타내는 도면이다.
도 4는 oneM2M 어드레싱에서 중요한 Uniform Resource Identifier Generic Syntax의 방식, 권한 및 경로 컴포넌트를 나타내는 도면이다.
도 5는 예시적인 서비스 층 프로토콜 스택을 나타내는 도면이다.
도 6은 MQTT의 퍼블리시/가입(또는 클라이언트/서버) 모델을 나타내는 도면이다.
도 7은 MQTT의 코어 요소들을 나타내는 도면이다.
도 8은 MQTT에서 클라이언트와 서버 사이의 2개 레벨의 부착(attachment)을 표현하는 세션들 및 가입들을 나타내는 도면이다.
도 9는 MQTT 서버들 사이의 메시지들의 일방향 흐름을 나타내는 도면이다.
도 10은 MQTT 서버들과 어느 한 쪽의 서버에 접속된 클라이언트들 사이의 양방향 트래픽 흐름을 나타내는 도면이다.
도 11은, 모든 AE 및 CSE로의 접속들을 유지하는 서비스 제공자 도메인 내의 단일의 MQTT 서버를 나타내는 도면이다.
도 12a 및 도 12b는 oneM2M 실시예에서의 복수의 MQTT 서버의 이용을 나타낸다.
도 13은 MQTT 서버를 갖는 oneM2M 실시예를 나타낸다.
도 14는 oneM2M에 대한 예시적인 MQTT 메시지 흐름을 도시하는 도면이다.
도 15는 인프라스트럭쳐 도메인에 위치한 단일의 표준 MQTT 서버를 이용한 예시적인 메시지 흐름을 나타내는 도면이다.
도 16은 3개의 토픽 필터의 이용을 나타내는 도면이다.
도 17은 MQTT를 갖는 oneM2M 실시예를 나타내는 도면이다.
도 18은 서비스 층 생성 동작의 예를 나타내는 흐름도이다.
도 19은 서비스 층 회수 동작의 예를 나타내는 흐름도이다.
도 20은 강화된 oneM2M ROA 실시예에서의 MQTT CSF를 나타내는 도면이다.
도 21은 한 실시예의 그래픽 사용자 인터페이스의 도면이다.
도 22a는 예시적인 시스템 및 방법의 하나 이상의 개시된 실시예가 구현될 수 있는 예시적인 M2M(machine-to-machine) 또는 IoT(Internet of Things) 통신 시스템의 도면이다.
도 22b는 필드 도메인 및 인프라스트럭쳐 도메인을 갖는 M2M 서비스 층의 도면이다.
도 22c는 UE 또는 또 다른 엔드 노드 디바이스 등의 예시적인 디바이스의 도면이다.
도 22d는 노드 또는 논리적 엔티티들을 구현하는 데 이용될 수 있는 컴퓨터 시스템 또는 서버의 도면이다.

도 14는 oneM2M에 대한 예시적인 MQTT 메시지 흐름을 도시하는 도면이다. 도 14에 도시된 MQTT에 대한 메시지 흐름은 실현가능하지만, 서비스 층 엔티티(AE 1402 또는 CSE 1404)에 의존하여 MQTT 가입을 설정하기 위한 목적으로 고유 토픽 필터 값을 연관된 MQTT 클라이언트(1406 및 1408)에 제공한다. 이 "자체-가입"은 응답(및 통보) 트래픽을 다시 가입측 엔티티에 보낸다. 도 14에서, MQTT 접속 및 가입 단계들이 성공적으로 수행되었다고 가정되고, AE(1402) 및 CSE(1404)가 MQTT 서버(1414) 내부의 도시된 토픽 큐들에 대한 토픽 필터 값으로서 그들 각각의 서비스 층 ID를 이용했다는 점에 유의한다. 이 목적을 위해 AE-ID 및 CSE-ID 이외의 값을 이용할 수도 있지만, 이들 ID들은, 이미 엔티티를 고유하게 식별하고 서비스 층 API에서 운반되며 MQTT 토픽 명칭 구조와 잘 상관된다는 이점을 갖는다.

그러나, oneM2M AE에 관한 특정한 문제가 있다. (연관된 MQTT 클라이언트를 통해) AE(1402)는 초기 서비스 층 등록 이전에 전송된 제1 SUBSCRIBE 메시지의 토픽 필터 필드에서 고유 식별자를 MQTT 서버(1414)에 전달할 수 있어야 한다. 이것은, AE로 다시 전달되는 응답 메시지를 라우팅하기 위한 고유 토픽을 서버에게 제공한다. AE-ID는, AE가 등록할 때까지 등록자 CSE에 의해 할당되지 않기 때문에 여기서 이용될 수 없다 ―등록 요청에 대한 응답은 먼저 AE-ID 값을 다시 AE에 운반한다. 전반적으로 MQTT 토픽 명칭의 동적 제공에 이용될 수 있는 범용 메커니즘이 없고, oneM2M 식별자(예를 들어, AE ID, CSE ID)와 정렬되는 메커니즘은 훨씬 적다.

둘째, 더 일반적인 문제는 서버 주변의 MQTT 네트워크의 고유한 중앙집중화에 있다. 도 14에 나타낸 바와 같이, MQTT 클라이언트들은 서로 직접 통신할 수 없으므로, 이들간의 통신을 중개하기 위해 서버에 의존해야 한다. 그러나 네이티브(native) MQTT 프로토콜은 MQTT 서버들 사이의 통신을 지원하지 않는다; 서버 X에 접속된 MQTT 클라이언트는 서버 Y에 접속된 MQTT 클라이언트와 메시지를 교환할 수 없다. 따라서, (예를 들어 네트워크 확장의 결과로서) M2M SP 도메인 내에 하나보다 많은 MQTT 서버가 존재한다면, (추가 오버헤드를 수반하는) MQTT 서버들 사이의 상호연동은 서비스 층 레벨에서 관리되거나 회피되어야 한다.

도 14에 나타낸 기능은, 예를 들어, 후술되는 도 22c 또는 도 22d에 도시된 것들 중 하나와 같은, M2M 네트워크의 노드(예를 들어, 서버, 게이트웨이, 디바이스 또는 기타의 컴퓨터 시스템)의 메모리에 저장되고 프로세서에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능한 명령어)의 형태로 구현될 수 있다는 것을 이해해야 한다.

도 15는 인프라스트럭쳐 도메인에 위치한 단일의 표준 MQTT 서버를 이용한 예시적인 메시지 흐름을 나타내는 도면이다. 이 흐름은, oneM2M 시스템이 (일단 완료되고 나면) Mca 및 Mcc 기준점 양쪽 모두에 적용되는 oneM2M TS-0010에서 명시된 MQTT 프로토콜 바인딩을 따름으로써 동작하는 방식을 나타냅니다. 이것은, 후술되는 도 19의 동작 단계들에서 수행되는 동일한 서비스 레벨 동작에 비해 이 접근법의 비효율성을 나타낸다.

이하의 단계들은, 도 13에 도시된 구성과 일치하는 단일 MQTT 서버에 대한 (대응하는 AE-ID 또는 CSE-ID에 기초한) 모든 MQTT 클라이언트의 접속 및 등록을 전제로 한다.

도 15의 단계 1에서, ADN-AE("발신자 AE")(1502)는 서비스 층 회수 요청 프리미티브를 ADN MQTT 클라이언트(1504)에 전송한다. 프리미티브의 "to" 파라미터는 <IN CSEBase> 아래에 위치한 자원에 대한 URI이다. "from" 파라미터는 AE-ID이다.

도 15의 단계 2에서, ADN MQTT 클라이언트(1504)는 PUBLISH 메시지를 (전역) MQTT 서버(1506)에 발행한다. 토픽 명칭 문자열은, 등록자 CSE-ID (AE가 등록된 MN-CSE)로 설정된다.

도 15의 단계 3에서, MQTT 서버는 수신된 토픽 명칭 문자열을 그 가입 목록과 비교하고 MN-CSE-ID에 대한 정합을 찾는다. MQTT 서버(1506)는 PUBLISH 메시지를 대응하는 MQTT 클라이언트(1504)에 포워딩한다.

도 15의 단계 4에서, MN MQTT 클라이언트(1504)는 수신된 페이로드(즉, 회수 요청 프리미티브)를 MN-CSE(1508)(등록자 CSE)에 전달한다.

도 15의 단계 5에서, MN-CSE(1508)는 회수 요청의 "to" 파라미터를 검사하고, 프리미티브가 다른 CSE에 어드레싱되었는지를 결정한다.

도 15의 단계 6에서, MN-CSE(1508)는 "from" 파라미터를 자신의 CSE-ID로 업데이트하고 업데이트된 프리미티브를 MN MQTT 클라이언트(1510)에 포워딩한다.

도 15의 단계 7에서, MN MQTT 클라이언트(1510)는 PUBLISH 메시지를 MQTT 서버(1506)에 발행한다. 토픽 명칭 문자열은 타겟 CSE-ID 1512(자원이 위치해 있는 IN-CSE)로 설정된다.

도 15의 단계 8에서, MQTT 서버(1506)는 수신된 토픽 명칭 문자열을 그 가입 목록과 비교하고 IN-CSE-ID에 대한 정합을 찾는다. MQTT 서버(1506)는 PUBLISH 메시지를 대응하는 MQTT 클라이언트에 포워딩한다.

도 15의 단계 9에서, IN MQTT 클라이언트는 수신된 페이로드(즉, 회수 요청 프리미티브)를 IN-CSE(1512)(타겟 CSE)에 전달한다.

도 15의 단계 10에서, 명시된 자원 콘텐츠가 회수된다(발신자 AE(1502)가 액세스 권한을 갖는 경우).

도 15의 단계 11에서, IN-CSE(1512)는 회수 응답 프리미티브를 IN MQTT 클라이언트(1514)에 전송하여 동작의 성공 또는 실패를 표시한다. 송출 프리미티브의 "to" 파라미터는 수신된 "from" 파라미터(MN-CSE-ID)로 설정된다. "cn" 파라미터는 적절한 콘텐츠로 설정된다; (도시된) 성공 사례에서, 이것은 회수된 자원의 요청된 콘텐츠로 설정된다.

도 15의 단계 12에서, IN MQTT 클라이언트(1514)는 PUBLISH 메시지를 MQTT 서버에 발행한다. 토픽 명칭 문자열은 수신측 CSE-ID("from" 파라미터에서 식별된 MN-CSE(1508))로 설정된다.

도 15의 단계 15에서, MQTT 서버(1506)는 수신된 토픽 명칭 문자열을 그 가입 목록과 비교하고 MN-CSE-ID에 대한 정합을 찾는다. MQTT 서버(1506)는 PUBLISH 메시지를 대응하는 MQTT 클라이언트에 포워딩한다.

도 15의 단계 14에서, MN MQTT 클라이언트(1510)는 수신된 페이로드(즉, 회수 응답 프리미티브)를 MN-CSE(1508)에 전달한다.

도 15의 단계 15에서, MN-CSE(1508)는 회수 응답을 검사하고 이것을 대응하는 회수 요청과 상관시킨다.

도 15의 단계 16에서, MN-CSE(1508)는 "to" 파라미터를 발신자 AE-ID로 업데이트하고 업데이트된 회수 응답 프리미티브를 MN MQTT 클라이언트(1510)에 포워딩한다.

도 15의 단계 17에서, MN MQTT 클라이언트(1510)는 PUBLISH 메시지를 MQTT 서버(1506)에 발행한다. 토픽 명칭 문자열은 (요청을 시작한) 발신자 AE-ID로 설정된다.

도 15의 단계 18에서, MQTT 서버(1506)는 수신된 토픽 명칭 문자열을 그 가입 목록과 비교하고 AE-ID에 대한 정합을 찾는다. MQTT 서버(1506)는 PUBLISH 메시지를 대응하는 MQTT 클라이언트에 포워딩한다.

도 15의 단계 19에서, ADN MQTT 클라이언트(1504)는 수신된 페이로드(즉, 회수 응답 프리미티브)를 AE(1502)에 전달한다.

MQTT V3.1.1 명세 [2]는 다음과 같은 선언을 포함한다:

서버 구현은 다른 목적을 위해 선행하는 $ 문자로 시작하는 토픽 명칭을 이용할 수 있다.

$SYS/는 서버-고유의 정보 또는 제어 API를 포함하는 토픽의 접두사로 널리 채택되었다($SYS/ has been widely adopted as a prefix to topics that contain Server-specific information or control APIs.).

MQTT의 이 특성은, AE 등록 절차를 수행하기 전에 AE-ID 값을 AE에 할당할 목적으로 oneM2M 실시예에 특유한 토픽 공간을 생성하기 위해 여기서 활용된다. 특히, 토픽 명칭 문자열 "$SYS/oneM2M/AE ID/"는, 널(null) 클라이언트 식별자(ClientId)를 이용하여 MQTT 서버+에 접속을 시도하는 MQTT 클라이언트를 식별하는 플래그로서 MQTT 서버+ 구현에서 이용된다. 이 플래그는 접속 엔티티로의 AE ID 값의 사전-할당을 야기하는 도 18에 개요된 일련의 작업을 트리거한다. 이 AE ID 값은, 차례로, 접속 엔티티가 서버+와 연관된 CSE로부터의 응답을 수신하기 위한 목적으로 MQTT 서버+에의 가입을 설정하는 데 이용된다. 이 메커니즘에 대한 추가 상세사항이 이하에 제공된다.

도 15에 나타낸 단계들을 수행하는 엔티티들은, 도 22c 또는 도 22d에 나타낸 것들과 같은 컴퓨터 시스템 또는 네트워크 노드의 메모리에 저장되고 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능한 명령어)의 형태로 구현될 수 있는 논리적 엔티티라는 것을 이해해야 한다. 즉, 도 15에 나타낸 방법(들)은, 도 22c 또는 도 22d에 나타낸 노드 또는 컴퓨터 시스템과 같은 네트워크 노드의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행가능한 명령어)의 형태로 구현될 수 있고, 이 컴퓨터 실행가능한 명령어들은, 노드의 프로세서에 의해 실행될 때, 도 15에 나타낸 단계들을 수행한다. 또한, 도 15에 나타낸 임의의 전송 및 수신 단계들은, 노드의 프로세서와 프로세서가 실행하는 컴퓨터 실행가능한 명령어(예를 들어, 소프트웨어)의 제어하에서, 노드의 통신 회로에 의해 수행될 수 있다는 것도 역시 이해해야 한다.

도 16은 3개의 토픽 필터의 이용을 나타내는 도면이다. MQTT 와일드카드 문자는, 요청을 전송하는 엔티티가 그 자원 주소에 기초하여 한 세트의 가입을 통해 응답 트래픽을 수신할 수 있게 하는 데 활용된다. 도 16의 3개의 토픽 필터 문자열은, CSEBase 아래의 첫 번째 레벨에서 슬래시로 끝나는 토픽 명칭 문자열을 제외하고, MN-CSE-ID를 포함하는 토픽 명칭을 갖는 모든 메시지가 MN 상의 MQTT 클라이언트에 포워딩되게 한다. 따라서, AE는 CSE에 등록할 수 있고 "/"가 붙은 AE 식별자(AE-ID)에 대응하는 URI에서 인입 메시지를 수신할 수 있다 ― 그 CSEBase 주위에 형성된 토픽 명칭을 갖는 모든 다른 메시지는 CSE 그 자체로 라우팅된다. 이러한 방식으로, AE 자원에 관한 CRUD 동작이 행위를 위해 CSE에 전달되지만, 메시지가 AE 자체에 도달하기 위한 경로가 여전히 있다.

MQTT 문자열은 대소문자가 구별되지만, RFC 3968 URI의 호스트 컴포넌트는 대소문자를 구분하지 않는다. 따라서, 대소문자가 구별되는 MQTT 토픽 명칭과 토픽 필터 문자열이 라우팅 목적으로 이용되는 URI 값(예를 들어, 호스트 컴포넌트)과 적절하게 상관되는 것이 보장되도록 반드시 주의해야 한다.

oneM2M Functional Architecture는 업데이트되어 CSE의 각각의 발생과 함께 배치된 MQTT 서버+ 기능 엔티티의 존재를 반영한다. 이러한 실시예는, 도면에 도시된 바와 같이 협력 서버들 사이의 트래픽 흐름을 가능하게 하기 위해 아래에 설명되는 양방향 상호연동 능력을 이용할 것이다. 도 13은, oneM2M에서 현재 접근법을 나타내는 MQTT 서버 배치에 대한 대안적 뷰를 도시한다.

다음 2개 도면은, CSE들(1804 및 1806)이 MQTT 서버+ 기능에 의해 강화된, ADN-AE(1802), MN-CSE(1804) 및 IN-CSE(1806)를 수반하는 샘플 통신 흐름을 나타낸다. 서비스 층 생성 및 회수 동작들만이 도시되어 있지만, 여기서 나타낸 방법들은 전체 CRUD-SN 동작들의 전체 수트(entire suite)에 동등하게 적용된다: 생성, 회수, 업데이트, 삭제, 가입 및 통보. 이러한 동작들(또는 "프리미티브들")은 완전히 MQTT PUBLISH 메시지의 페이로드 파라미터 내에서 운반된다; 이것은 도면의 "동작" 부분에 도시되어 있다.

도 18은 서비스 층 생성 동작의 예를 나타내는 흐름도이다.

도 18의 전제 조건 단계들.

이들 단계들은 시스템 초기화의 일부로 수행되거나 노드들 사이의 네트워크 접속이 (재)설정되어야 할 때마다 수행된다. 도 18에 QoS 레벨들이 도시되어 있는 곳에서, 이들은 예시의 목적을 위해 레벨 0으로 설정된다. 실제로, 설명된 기술들은 이용된 QoS 레벨과는 독립적이다. 도 18의 전제 조건 단계 1에서, MN-CSE(1804)는 중간 노드(MN)(1810) 상의 MQTT 클라이언트(1808)에게 그 MN과 연관된 MQTT 서버+(1812)에 CONNECT 메시지를 발행할 것을 지시한다. M2M 서비스 제공자 도메인에서 고유한 MN CSE 식별자는, CONNECT 메시지의 ClientID 파라미터로서 이용된다(ClientID는 그 MQTT 서버+로의 모든 접속들에 걸쳐 고유해야 한다).

도 18의 전제 조건 단계 2에서, MQTT 서버+(1812)는 접속이 수락되었다는 것을 나타내는 CONNACK 메시지로 응답한다.

도 18의 전제 조건 단계 3에서, MN-CSE(1804)는 MN MQTT 클라이언트(1808)에게 SUBSCRIBE 메시지를 MN MQTT 서버+(1812)에 발행할 것을 지시한다. MN-CSE-ID는 SUBSCRIBE 메시지에서 토픽 필터 파라미터를 형성하는 데 이용된다. 4개의 별개의 토픽 필터 문자열이 이 파라미터에 포함된다: 처음 3개의 문자열은 MN-CSE(1804)에 어드레싱된 트래픽이 그 쪽으로 라우팅되게 한다. 4번째 문자열은 시스템-특유의 값 "$SYS/oneM2M/AE-ID/+"이다. 이 토픽에 퍼블리시하는 클라이언트는 <AE> 자원 명칭 값(클라이언트는 이 값을 등록자 CSE와의 연락을 개시하기 전에 "자체-가입"에 이용할 수 있음)의 사전-할당 요청을 서버+/등록자 CSE에게 시그널링하고 있다. 섹션 참조.

도 18의 전제 조건 단계 4에서, MQTT 서버+(1812)가 4개의 가입 요청 각각이 수신되고 처리되었음을 나타내는 SUBACK 메시지로 응답한다.

AE 널 접속

도 18의 전제 조건 단계 5에서, 애플리케이션 전용 노드(ADN)(1816) 상의 MQTT 클라이언트(1814)는, ADN-AE(1802)("발신자 AE")에 의해, CONNECT 메시지를 자신의 등록자 CSE와 연관된 MQTT 서버(1804)(이 MQTT 서버+(1812)의 주소는 미리구성됨)에 발행할 것을 지시받는다. 클라이언트 식별자(ClientID) 파라미터는 널(0 바이트 길이)이다.

도 18의 전제 조건 단계 6에서, MQTT 서버+(1812)는,널 ClientID를 수신한 결과, 이 세션에 대해 고유 ClientID 값을 할당하고 접속이 수락되었다는 것을 나타내는 CONNACK 메시지로 응답한다.

도 18의 전제 조건 단계 7에서, ADN-AE(1802)는 ADN MQTT 클라이언트(1814)에게 SUBSCRIBE 메시지를 등록자 CSE(1804)의 MQTT 서버+(1812)에 발행할 것을 지시한다. 토픽 필터 파라미터는, <AE> 자원 명칭의 사전-할당 요청과 연관된 가입을 나타내는 시스템-특유의 문자열 "$SYS/oneM2M/AE-ID"이다.

도 18의 전제 조건 단계 8에서, MQTT 서버+(1812)는 가입 요청이 수신되어 처리되었다는 것을 나타내는 SUBACK 메시지로 응답한다. MQTT 서버+(1812)는, 특수 문자 "/"와 이 세션에 대한 ClientID 값을 수신된 토픽 필터 문자열 "$SYS/oneM2M/AE-ID"에 추가함으로써 클라이언트에 대한 가입 필터를 생성한다.

AE-ID 할당

도 18의 전제 조건 단계 9에서, ADN-AE(1802)는 ADN MQTT 클라이언트(1814)에게 PUBLISH 메시지를 등록자 CSE(1804)의 MQTT 서버+(1812)에 발행할 것을 지시한다. 토픽 명칭 파라미터는, 등록자 CSE(1804)에 의한 <AE> 자원 명칭의 사전-할당에 대한 플래그를 나타내는, 시스템-특유의 문자열 "$SYS/oneM2M/AE-ID"이다. 페이로드 파라미터는 널(0 바이트 길이)이다.

도 18의 전제 조건 단계 10에서, MN-CSE(1804)(등록자 CSE)의 MQTT 서버+(1812)는, 시스템-특유의 토픽 명칭 문자열 "$SYS/oneM2M/AE-ID"를 갖는 PUBLISH 메시지를 수신하면, 특수 문자 "/"와 이 세션에 대한 ClientID 값을 그 문자열에 추가한다. 수정된 토픽 명칭 문자열은 도 18의 전제 조건 단계 3으로부터의 MN MQTT 클라이언트(1808)에 대한 가입 필터를 위한 정합이므로, MQTT 서버+(1812)는 수정된 PUBLISH 메시지를 MN MQTT Client에 포워딩한다.

수정된 토픽 명칭 문자열도 역시 도 18의 전제 조건 단계 7로부터의 ADN MQTT 클라이언트에 대한 가입 필터를 위한 정합이지만, 퍼블리셔와 가입자가 동일하기 때문에 이 경우에는 서버+(1812)는 메시지를 포워딩하지 않는다.

도 18의 전제 조건 단계 11에서, MN-CSE(1804)는, MN MQTT 클라이언트(1808)로부터 수정된 시스템-특유의 문자열을 갖는 PUBLISH 메시지를 수신하면, 요청을 처리하고 <AE> 자원 명칭 값을 할당한다.

도 18의 전제 조건 단계 12에서, MN-CSE(1804)는 MN MQTT 클라이언트(1808)에게 PUBLISH 메시지를 연관된 MQTT 서버+에 발행할 것을 지시한다. 토픽 명칭 파라미터는, 도 18의 전제 조건 단계 10에서 수신된 바로 그 시스템-특유의 문자열로 설정된다. 페이로드는 (미리) 할당된 <AE> 자원 명칭이다.

도 18의 전제 조건 단계 13에서, MQTT 서버+(1812)는, 수정된 시스템-특유의 토픽 명칭 문자열을 갖는 PUBLISH 메시지를 수신하면, 그 문자열이 도 18의 전제 조건 단계 8로부터의 ADN MQTT 클라이언트(1814)에 대한 가입 필터를 위한 정합인지를 결정한다. MQTT 서버+(1812)는 PUBLISH 메시지를 ADN MQTT 클라이언트(1814)에 포워딩한다.

도 18의 전제 조건 단계 14에서, ADN-AE(1802)는 페이로드 파라미터를 그 새로운 <AE> 자원 명칭으로서 저장한다.

AE 널 해제

도 18의 전제 조건 단계 15에서, ADN-AE(1802)는 ADN MQTT 클라이언트에게 UNSUBSCRIBE 메시지를 등록자 CSE(1804)의 MQTT 서버+(1812)에 발행할 것을 지시한다. 이용 된 토픽 필터 파라미터 값은 도 18의 전제 조건 단계 14에서 저장된 것과 동일한 것이다.

도 18의 전제 조건 단계 16에서, MQTT 서버+(1812)는 UNSUBACK 메시지로 응답한다.

도 18의 전제 조건 단계 17에서, ADN-AE(1802)는 ADN MQTT 클라이언트(1814)에게 DISCONNECT 메시지를 등록자 CSE의 MQTT 서버+(1812)에 발행할 것을 지시한다. 그 다음, ADN MQTT 클라이언트는 네트워크 접속을 폐쇄한다.

도 18의 전제 조건 단계 18에서, ADN-AE(1802)는 ADN MQTT 클라이언트(1814)에게 CONNECT 메시지를 그 등록자 CSE(1804)와 연관된 MQTT 서버+(1812) 기능에 발행할 것을 지시한다. AE 식별자(AE-ID), 또는 도 18의 전제 조건 단계 14에서([0124]) 저장된 <AE> 자원 명칭에 기초한 국지적으로 고유한 상대적 버전은, CONNECT 메시지에서 ClientID 파라미터로서 이용된다.

도 18의 전제 조건 단계 19에서, The MQTT 서버+(1812)는 접속이 수락되었다는 것을 나타내는 CONNACK 메시지로 응답한다.

도 18의 전제 조건 단계 20에서, ADN MQTT 클라이언트(1814)는 SUBSCRIBE 메시지를 등록자 CSE(1804)의 MQTT 서버+(1812)에 발행할 것을 지시받는다. <AE> URI는 SUBSCRIBE 메시지에서 토픽 필터 파라미터를 형성하는 데 이용된다. 구체적으로는, 특수 문자 "/"가 <AE> URI에 추가되어 토픽 필터 문자열을 생성한다.

도 18의 전제 조건 단계 21에서, MQTT 서버+(182)는 가입 요청이 수신되어 처리되었다는 것을 나타내는 SUBACK 메시지로 응답한다.

도 18 의 동작 단계들

도 18의 동작 단계 1에서, ADN-AE(1802)("발신자 AE")는 서비스 층 요청 프리미티브를 ADN MQTT 클라이언트(1814)에 발행한다. op (Operation, 동작) 파라미터는 "C"(Create)로 설정된다. 프리미티브의 to 파라미터는 <MN-CSEBase> URI(이것은 또한 MQTT 토픽 명칭 문자열로서도 이용된다)이다. ty 파라미터는, 등록자 CSE에게 ADN-AE에 대한 <AE> 자원을 생성할 것을(즉, 애플리케이션 등록을 수행할 것을) 지시하는, <AE> 자원 타입을 나타낸다. nm 파라미터는, 도 18의 전제 조건 단계 14에서 수신된 <AE> 자원 명칭 값으로 설정된다.

도 18의 동작 단계 2에서, ADN MQTT 클라이언트(1814)는 PUBLISH 메시지를 (접속을 확립한) MN MQTT 서버+(1812)에 발행한다.

도 18의 동작 단계 3에서, MN MQTT 서버+(1812)는 수신된 토픽 명칭(<MN-CSEBase> URI)을 그 가입 목록과 비교하고 MN MQTT 클라이언트(1808)에 대응하는 정합을 찾는다(상기 도 18 예의 전제 조건 단계 3을 참조). MN MQTT 서버+(1812)는 PUBLISH 메시지를 MN MQTT 클라이언트(1808)에 포워딩한다.

도 18의 동작 단계 4에서, MN MQTT 클라이언트(1808)는 수신된 페이로드(즉, 서비스 층 생성 요청 프리미티브)를 MN-CSE(1804)(등록자 CSE)에 전달한다.

도 18의 동작 단계 5에서, (AE가 성공적으로 인증되고 충분한 액세스 권한을 갖는 경우) MN-CSEBase 하에 <AE> 자원이 생성된다.

도 18의 동작 단계 6에서, MN-CSE(1804)는, rs 파라미터에서 생성(Create) 동작의 성공 또는 실패를 나타내는 응답 프리미티브를 MN MQTT 클라이언트(1808)에 전송한다. 송출 응답 프리미티브의 to 파라미터는, 방금 생성된 <AE> 자원의 URI로 설정된다. cn 파라미터는, 적절한 콘텐츠로 설정된다; (도시된) 성공 사례에서는, 이것은 생성된 <AE> 자원의 URI로 설정된다.

도 18의 동작 단계 7에서, MN MQTT 클라이언트(1808)는 PUBLISH 메시지를 연관된 MN MQTT 서버+(1812)에 발행한다.

도 18의 동작 단계 8에서, MN MQTT 서버+(1812)는 수신된 토픽 명칭(<AE> URI)을 그 가입 목록과 비교하고 ADN MQTT 클라이언트(1814)에 대응하는 정합을 찾는다. MN MQTT 서버+(1812)는 PUBLISH 메시지를 ADN MQTT 클라이언트(1814)에 포워딩한다.

도 18의 동작 단계 9에서, ADN MQTT 클라이언트(1814)는 수신된 페이로드(즉, 생성 응답 프리미티브)를 ADN-AE(1802)에 전달한다.

한 실시예는, MQTT 서버+(1812) 등의 MQTT 서버에서의 방법이다. 도 18의 전제 조건 단계 9에서와 같이, 애플리케이션 식별자에 대한 요청과 관련된 미리결정된 토픽 필터 파라미터를 이용하는 ADN(1816) 등의 애플리케이션으로부터의 퍼블리시 요청이 수신된다. 도 18의 전제 조건 단계 10에서와 같이, 미리결정된 토픽 필터 파라미터에 응답하여, 임시 클라이언트 ID를 포함하는 등록자 CSE(1804)에 대한 메시지가 발행된다. 도 18의 전제 조건 단계 12에서와 같이 페이로드로서 할당된 애플리케이션 명칭을 포함하는 등록자 CSE(1804)로부터의 메시지가 수신된다. 도 18의 전제 조건 단계 13에서와 같이, 할당된 애플리케이션 명칭이 애플리케이션에 제공된다. 도 18의 전제 조건 단계 20에서와 같이, 토픽 필터의 일부로서 할당된 애플리케이션 명칭을 포함하는 애플리케이션으로부터의 가입 요청이 수신된다.

또 다른 실시예는, ADN(1802) 등의 애플리케이션에서의 방법이다. 도 18의 전제 조건 단계 9에서와 같이, 애플리케이션 식별자에 대한 요청과 관련된 미리결정된 토픽 필터 파라미터를 이용하는 MQTT 서버+(1812) 등의 MQTT 서버로의 퍼블리시 요청이 전송된다. 페이로드로서 할당된 애플리케이션 명칭을 포함하는 MQTT 서버+(1812)로부터의 메시지가 수신된다. 도 18의 전제 조건 단계 20에서와 같이, 토픽 필터의 일부로서 할당된 애플리케이션 명칭을 포함하는 MQTT 서버(1812)로의 가입 요청이 전송된다.

도 18에 나타낸 단계들을 수행하는 엔티티들은, 도 22c 또는 도 22d에 나타낸 것들과 같은 컴퓨터 시스템 또는 네트워크 노드의 메모리에 저장되고 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능한 명령어)의 형태로 구현될 수 있는 논리적 엔티티라는 것을 이해해야 한다. 즉, 도 18에 나타낸 방법(들)은, 도 22c 또는 도 22d에 나타낸 노드 또는 컴퓨터 시스템과 같은 네트워크 노드의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행가능한 명령어)의 형태로 구현될 수 있고, 이 컴퓨터 실행가능한 명령어들은, 노드의 프로세서에 의해 실행될 때, 도 18에 나타낸 단계들을 수행한다. 또한, 도 18에 나타낸 임의의 전송 및 수신 단계들은, 노드의 프로세서와 프로세서가 실행하는 컴퓨터 실행가능한 명령어(예를 들어, 소프트웨어)의 제어하에서, 노드의 통신 회로에 의해 수행될 수 있다는 것도 역시 이해해야 한다.

도 19은 서비스 층 회수 동작의 예를 나타내는 흐름도이다.

도 19의 전제 조건 단계들.

이들 단계들은 노드들 사이의 네트워크 접속이 (재)설정되어야 할 때마다 수행될 수 있다. AE(1802)는 이미 등록되어 AE-ID를 할당받았다.

도 19의 전제 조건 단계 1에서, ADN-AE(1802)는 ADN MQTT 클라이언트(1814)에게 CONNECT 메시지를 그 등록자 CSE(1804)와 연관된 MQTT 서버+(1812)에 발행할 것을 지시한다. AE 식별자(AE-ID), 또는 <AE> 자원 명칭에 기초하여 국지적으로 고유한 상대적 버전이 CONNECT 메시지에서 ClientID 파라미터로서 이용된다.

도 19의 전제 조건 단계 2에서, MQTT 서버+(1812)는 접속이 수락되었다는 것을 나타내는 CONNACK 메시지로 응답한다.

도 19의 전제 조건 단계 3에서, ADN-AE(1802)는 ADN MQTT 클라이언트에게 SUBSCRIBE 메시지를 등록자 CSE(1804)의 MQTT 서버+(1812)에 발행할 것을 지시한다. <AE> URI는 SUBSCRIBE 메시지에서 토픽 필터 파라미터를 형성하는 데 이용된다. 구체적으로는, MQTT 특수 문자 "/"가 <AE> URI에 추가되어 토픽 필터 문자열을 구성한다.

도 19의 전제 조건 단계 4에서, MQTT 서버+(1812)는 가입 요청이 수신되어 처리되었다는 것을 나타내는 SUBACK 메시지로 응답한다.

도 19의 전제 조건 단계 5에서, IN-CSE(1806)는 IN MQTT 클라이언트(1820)에게 CONNECT 메시지를 그 IN(1824)와 연관된 MQTT 서버+(1822)에 발행할 것을 지시한다. IN의 CSE 식별자(M2M 서비스 공급자 도메인에 걸쳐 고유한 IN-CSE-ID)는 CONNECT 메시지에서 ClientID 파라미터로서 이용된다.

도 19의 전제 조건 단계 6에서, MQTT 서버+(1812)는 접속이 수락되었다는 것을 나타내는 CONNACK 메시지로 응답한다.

도 19의 전제 조건 단계 7에서, IN-CSE(1806)는 IN MQTT 클라이언트(1820)에게 SUBSCRIBE 메시지를 IN MQTT 서버+(1822)에 발행할 것을 지시한다. IN-CSE-ID는 SUBSCRIBE 메시지에서 토픽 필터 파라미터를 구성하는 데 이용된다. 3개의 별개의 토픽 필터 문자열이 이 파라미터에 포함된다: '<IN-CSE-ID>' 외에, MQTT 단일-레벨 및 다중-레벨 와일드카드 문자들을 '<IN-CSE-ID>'에 추가함으로써 형성된 2개의 추가 문자열.

도 19의 전제 조건 단계 8에서, MQTT 서버+(1822)가 3개의 가입 요청 각각이 수신되고 처리되었음을 나타내는 SUBACK 메시지로 응답한다.

단계들 9 내지 16에서, MQTT 서버+(1822)는, CONNECT 또는 SUBSCRIBE를 발행할 때 MQTT 클라이언트로서 동작한다.

도 19의 전제 조건 단계 9에서, MN-CSE(1804)는 MN MQTT 서버+(1812)에게 CONNECT 메시지를 IN MQTT 서버+(1822)(IN MQTT 서버+(1822)의 주소는 미리구성됨)에 발행할 것을 지시한다. MN-CSE-ID는 ClientID 파라미터로서 이용된다.

도 19의 전제 조건 단계 10에서, IN MQTT 서버+(1822)는 접속이 수락되었다는 것을 나타내는 CONNACK 메시지로 응답한다.

도 19의 전제 조건 단계 11에서, MN-CSE(1804)는 MN MQTT 서버+(1812)에게 SUBSCRIBE 메시지를 IN MQTT 서버+(1822)에 발행할 것을 지시한다. <MN-CSE-ID> URI는 SUBSCRIBE 메시지에서 토픽 필터 파라미터 문자열을 형성하는 데 이용된다. 구체적으로는, MQTT 특수 문자 "/#"가 <MN-CSE-ID> URI에 추가되어 토픽 필터 문자열을 구성한다. 이 문자열은, IN MQTT 서버+(1822)에게 MN-CSEBase의 첫 번째 레벨 또는 그 아래의 임의의 수신된 토픽 명칭을 MN MQTT 서버+(1812)에 포워딩할 것을 지시한다.

도 19의 전제 조건 단계 12에서, IN MQTT 서버+(1822)는 가입 요청이 수신되어 처리되었다는 것을 나타내는 SUBACK 메시지로 응답한다.

도 19의 전제 조건 단계 13에서, IN-CSE(1806)는 IN MQTT 서버+(1822)에게 CONNECT 메시지를 MN MQTT 서버+(1822)(MN MQTT 서버+(1812)의 주소는 미리구성됨)에 발행할 것을 지시한다. IN-CSE-ID는 ClientID 파라미터로서 이용된다.

도 19의 전제 조건 단계 14에서, MN MQTT 서버+(1812)는 접속이 수락되었다는 것을 나타내는 CONNACK 메시지로 응답한다.

도 19의 전제 조건 단계 15에서, IN-CSE(1806)는 IN MQTT 서버+(1822)에게 SUBSCRIBE 메시지를 MN MQTT 서버+(1822)에 발행할 것을 지시한다. <IN-CSE-ID> URI는 SUBSCRIBE 메시지에서 토픽 필터 파라미터 문자열을 형성하는 데 이용된다. 구체적으로는, MQTT 특수 문자 "/#"가 <IN-CSE-ID> URI에 추가되어 토픽 필터 문자열을 구성한다. 이 문자열은, MN MQTT 서버+(1812)에게 IN-CSEBase의 첫 번째 레벨 또는 그 아래의 임의의 수신된 토픽 명칭을 IN MQTT 서버+(1822)에 포워딩할 것을 지시한다.

도 19의 전제 조건 단계 16에서, MN MQTT 서버+(1812)는 가입 요청이 수신되어 처리되었다는 것을 나타내는 SUBACK 메시지로 응답한다.

도 19의 동작 단계들

이하의 단계들은 상기의 전제 조건 단계들이 발생했다고 가정한다.

도 19의 동작 단계 1에서, ADN-AE(1802)("발신자 AE")는 서비스 층 회수 요청 프리미티브를 ADN MQTT 클라이언트(1814)에 발행한다. 프리미티브의 to 파라미터는 <IN-CSEBase> 아래에 위치한 자원에 대한 URI이다(이것은 MQTT 토픽 명칭 문자열로서도 이용된다). fr 파라미터는 <AE-ID> URI이다(이 URI는 응답을 어드레싱하기 위해 타겟 CSE에 의해 이용된다).

도 19의 동작 단계 2에서, ADN MQTT 클라이언트(1814)는, 자신의 페이로드로서 요청 프리미티브를 갖는 PUBLISH 메시지를 (도 19의 전제 조건 단계 [0141]에서 접속을 확립한) MN MQTT 서버+(1812)에 발행한다.

도 19의 동작 단계 3에서, MN MQTT 서버+(1812)는 수신된 토픽 명칭(<IN-CSEBase> 아래의 자원 URI)을 그 가입 목록과 비교하고 IN MQTT 서버+(1822)에 대응하는 정합을 찾는다(상기 도 19의 전제 조건 단계 14 참조). MN MQTT 서버+(1812)는 PUBLISH 메시지를 IN MQTT 서버+(1822)에 포워딩한다.

도 19의 동작 단계 4에서, IN MQTT 서버+(1822)는 수신된 토픽 명칭(<IN-CSEBase> 아래의 자원 URI)을 그 가입 목록과 비교하고 IN MQTT 클라이언트에 대응하는 정합을 찾는다(상기 도 19의 전제 조건 단계 6 참조). IN MQTT 서버+는 PUBLISH 메시지를 IN MQTT 클라이언트(1820)에 포워딩한다.

도 19의 동작 단계 5에서, IN MQTT 클라이언트는 수신된 페이로드(즉, 회수 요청 프리미티브)를 IN-CSE(1806)(타겟 CSE)에 전달한다.

도 19의 동작 단계 6에서, 명시된 자원 콘텐츠가 회수된다(발신자 AE(1802)가 액세스 권한을 갖는 경우).

도 19의 동작 단계 7에서, IN-CSE(1806)는 IN MQTT 클라이언트(1820)에 회수 응답 프리미티브를 발행한다. 송출 프리미티브의 to 파라미터는 수신된 fr 파라미터( "/"가 추가된 <AE> URI)로 설정된다. cn 파라미터는 적절한 콘텐츠로 설정된다; (도시된) 성공 사례에서, 이것은 회수된 자원의 요청된 콘텐츠로 설정된다.

도 19의 동작 단계 8에서, IN MQTT 클라이언트(1820)는 자신의 페이로드로서 응답 프리미티브를 갖는 PUBLISH 메시지를 IN MQTT 서버+(1822)에 발행한다.

도 19의 동작 단계 9에서, IN MQTT 서버+(1822)는 수신된 토픽 명칭("/"가 첨부된, <MN-CSEBase> 아래에 있는 <AE>의 URI)을 그 가입 목록과 비교하고 MN MQTT 서버+(1812)에 대응하는 정합을 찾는다(상기 전제 조건 단계 14([0155]) 참조). IN MQTT 서버+(1822)는 PUBLISH 메시지를 MN MQTT 서버+(1812)에 포워딩한다.

도 19의 동작 단계 10에서, MN MQTT 서버+(1812)는 수신된 토픽 명칭("/"가 첨부된, <MN-CSEBase> 아래에 있는 <AE>의 URI)을 비교하고 ADN-AE에 대응하는 정합을 찾는다. MN MQTT 서버+(1812)는 PUBLISH 메시지를 ADN MQTT 클라이언트(1814)에 포워딩한다. 또한 도 16의 토픽 명칭 정합 예를 참조한다.

도 19의 동작 단계 11에서, ADN MQTT 클라이언트(1814)는 회수 응답(즉, PUBLISH 메시지의 페이로드)을 발신자 AE(1802)에 전달한다.

한 실시예는 중간 노드의 MQTT 서버+(1812)에서의 방법이다. 도 19의 전제 조건 단계 3에 도시된 바와 같이, 중간 노드(1810) 및 애플리케이션(1816)을 나타내는 토픽 필터와 함께 애플리케이션으로부터 가입 요청이 수신된다. 도 19의 전제 조건 단계 11에 도시된 바와 같이, 인프라스트럭쳐 노드(1824)를 나타내는 토픽 필터와 함께 토픽에 대해 인프라스트럭쳐 노드(1824)의 MQTT 서버(1822)에 가입 요청이 전송된다. 도 19의 전제 조건 단계 15에 도시된 바와 같이, 인프라스트럭쳐 노드(1824)를 나타내는 토픽 필터와 함께 토픽에 대해 인프라스트럭쳐 노드(1824)의 MQTT 서버(1822)로부터 가입 요청이 수신된다. 메시지는, 중간 노드 및 인프라스트럭쳐 노드들에서 생성된 토픽을 이용하여 애플리케이션과 인프라스트럭쳐 노드 사이의 중간 노드를 통해 포워딩될 수 있다.

도 19에 나타낸 단계들을 수행하는 엔티티들은, 도 22c 또는 도 22d에 나타낸 것들과 같은 컴퓨터 시스템 또는 네트워크 노드의 메모리에 저장되고 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능한 명령어)의 형태로 구현될 수 있는 논리적 엔티티라는 것을 이해해야 한다. 즉, 도 19에 나타낸 방법(들)은, 도 22c 또는 도 22d에 나타낸 노드 또는 컴퓨터 시스템과 같은 네트워크 노드의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행가능한 명령어)의 형태로 구현될 수 있고, 이 컴퓨터 실행가능한 명령어들은, 노드의 프로세서에 의해 실행될 때, 도 19에 나타낸 단계들을 수행한다. 또한, 도 19에 나타낸 임의의 전송 및 수신 단계들은, 노드의 프로세서와 프로세서가 실행하는 컴퓨터 실행가능한 명령어(예를 들어, 소프트웨어)의 제어하에서, 노드의 통신 회로에 의해 수행될 수 있다는 것도 역시 이해해야 한다.

도 20은 강화된 oneM2M ROA 실시예에서의 MQTT CSF를 나타내는 도면이다. 전술된 MQTT 서버+ 기능은 애드-온 소프트웨어 라이브러리로서 구현될 수 있다 ―이것은 기능하기 위하여 CSE에 통합할 필요가 없다. 그러나, 도 20에 도시된 바와 같이 MQTT 퍼블리케이션 및 전달 기능이 다른 서비스 기능과 더욱 밀접하게 결합되어 있다면 추가적인 최적화가 가능하다.

예를 들어, MQTT 서버+(2004)와 CSE(2002)가 별개인 경우 접속의 동적 확립 및 단절은 번거로운데, 이것은, CSE(2002)가 MQTT 서버+(2004)에 의해 유지되는 접속들을 이들을 관리하기 위하여 항상 (아마도 이들이 별개의 엔티티인 경우 질의 메커니즘을 통해) 알아야 할 필요가 있기 때문이다. CSE(2002) 내로의 통합은 이 문제를 완화된다. 또한, 통합된 MQTT 서버(2004)가 AE-ID 사전-할당을 요청하는 트리거 문자열을 처리를 위해 CSE(2002)에 직접 전달하고 그 결과를 요청측 AE에 직접 반환할 수 있기 때문에, AE-ID 사전-할당은 훨씬 적은 프로토콜 오버헤드를 요구할 것이다.

도 20에 나타낸 기능은, 예를 들어, 후술되는 도 22c 또는 도 22d에 도시된 것들 중 하나와 같은, M2M 네트워크의 노드(예를 들어, 서버, 게이트웨이, 디바이스 또는 기타의 컴퓨터 시스템)의 메모리에 저장되고 프로세서에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능한 명령어)의 형태로 구현될 수 있다는 것을 이해해야 한다.

그래픽 사용자 인터페이스(GUI) 등의 인터페이스는, 사용자를 보조하여 MQTT를 이용해 서비스 층 ROA 상호연동에 관련된 기능을 제어 및/또는 구성할 수 있다. 도 21은 사용자가 식별자 번호를 결정하고 디바이스를 등록 및 등록취소하는 것을 허용하는 인터페이스(2102)를 나타내는 도면이다. 인터페이스(2102)는 이하에서 설명되는 도 22c 내지 도 22d에 도시된 것들과 같은 디스플레이를 이용하여 생성될 수 있다는 것을 이해해야 한다.

M2M/IoT/WoT 통신 시스템의 예

도 22a는 하나 이상의 개시된 실시예들이 구현될 수 있는 예시적인 머신-대-머신(M2M), 사물 인터넷(IoT), 또는 사물 웹(WoT) 통신 시스템(10)의 도면이다. 일반적으로, M2M 기술은 IoT/WoT를 위한 구축 블록을 제공하고, 임의의 M2M 디바이스, M2M 게이트웨이, M2M 서버, 또는 M2M 서비스 플랫폼은 IoT/WoT의 한 컴포넌트 또는 노드 뿐만 아니라 IoT/WoT 서비스 층 등일 수도 있다. 통신 시스템(10)은 개시된 실시예의 기능을 구현하는 데 이용될 수 있고, GUI(2102)를 생성하기 위해 발신자 AE(1802), MQTT 서버+(1812, 1822 및 2004) 및 CSE(1804, 1806 및 2002) 및 논리적 엔티티 등의 기능 및 논리적 엔티티들을 포함할 수 있다.

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

도 22a에 도시된 바와 같이, M2M/ IoT/WoT 통신 시스템(10)은 인프라스트럭쳐 도메인(Infrastructure Domain) 및 필드 도메인(Field Domain)을 포함할 수 있다. 인프라스트럭쳐 도메인이란 단-대-단 M2M 배치의 네트워크측을 말하고, 필드 도메인이란, 대개는 M2M 게이트웨이 뒤쪽의, 영역 네트워크(area network)를 말한다. 필드 도메인과 인프라스트럭쳐 도메인 양쪽 모두는, 다양한 상이한 네트워크 노드(예를 들어, 서버, 게이트웨이, 디바이스 등)를 포함할 수 있다. 예를 들어, 필드 도메인은 M2M 게이트웨이(14)와 단말 디바이스(18)를 포함할 수 있다. 원한다면 임의 개수의 M2M 게이트웨이 디바이스(14)와 M2M 단말 디바이스(18)가 M2M/IoT/WoT 통신 시스템(10)에 포함될 수 있다는 것을 이해할 것이다. M2M 게이트웨이 디바이스(14)와 M2M 단말 디바이스(18) 각각은, 통신 회로를 이용하여, 통신 네트워크(12) 또는 직접 무선 링크를 통해 신호를 전송 및 수신하도록 구성된다. M2M 게이트웨이(14)는 무선 M2M 디바이스(예를 들어, 셀룰러 및 비-셀룰러) 뿐만 아니라 고정된 네트워크 M2M 디바이스(예를 들어, PLC)가 통신 네트워크(12) 또는 직접 무선 링크 등의 오퍼레이터 네트워크를 통해 통신하는 것을 허용한다. 예를 들어, M2M 단말 디바이스(18)는 데이터를 수집하고, 이 데이터를, 통신 네트워크(12) 또는 직접 무선 링크를 통해, M2M 애플리케이션(20) 또는 기타의 M2M 디바이스(18)에 전송할 수 있다. M2M 단말 디바이스(18)는 또한 M2M 애플리케이션(20) 또는 M2M 단말 디바이스(18)로부터 데이터를 수신할 수도 있다. 또한, 데이터와 신호는, 후술되는 바와 같이, M2M 서비스 층(22)을 통해 M2M 애플리케이션(20)에 전송되거나 이로부터 수신될 수 있다. M2M 단말 디바이스(18)와 게이트웨이(14)는, 예를 들어, 셀룰러, WLAN, WPAN(예를 들어, Zigbee, 6LoWPAN, Bluetooth), 직접 무선 링크, 및 와이어라인 등을 포함한 다양한 네트워크를 통해 통신할 수 있다.

예시적인 M2M 단말 디바이스(18)로는, 태블릿, 스마트폰, 의료 디바이스, 온도 및 날씨 모니터, 접속된 자동차, 스마트 계측기, 게임 콘솔 개인 디지털 보조도구, 건강 및 휘트니스 모니터, 등(light), 온도 조절 장치, 가전 제품, 차고 문 및 기타의 액츄에이터-기반의 디바이스, 보안 디바이스 및 스마트 콘센트가 포함되지만, 이것으로 제한되지 않는다.

도 22b를 참조하여, 필드 도메인 내의 예시된 M2M 서비스 층(22)은, M2M 애플리케이션(20), M2M 게이트웨이 디바이스(14), M2M 단말 디바이스(18) 및 통신 네트워크(12)에 서비스를 제공한다. 통신 네트워크(12)는 개시된 실시예의 기능을 구현하는 데 이용될 수 있고, 발신자 AE(1802), MQTT 서버+(1812, 1822 및 2004) 및 CSE(1804, 1806 및 2002) 등의 기능 및 논리적 엔티티들을 포함할 수 있다. M2M 서비스 층(22)은, 예를 들어, 후술되는 도 22c 및 도 22d에 나타낸 디바이스들을 포함한, 하나 이상의 서버, 컴퓨터, 디바이스, 가상 머신(예를 들어, 클라우드/스토리지 팜 등) 등에 의해 구현될 수 있다. 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')은, 서버, 컴퓨터, 디바이스, 가상 머신(예를 들어, 클라우드 컴퓨팅/스토리지 팜 등) 등을 포함할 수 있는, 네트워크의 하나 이상의 노드에 의해 구현될 수 있다.

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

본 출원의 방법들은 서비스 층들(22 및 22')의 일부로서 구현될 수 있다. 서비스 층(22 및 22')은, 한 세트의 애플리케이션 프로그래밍 인터페이스(API)와 기저 네트워킹 인터페이스를 통해 가치-부가된 서비스 능력을 지원하는 소프트웨어 미들웨어 층이다. ETSI M2M과 oneM2M 양쪽 모두는 본 출원의 접속 방법들을 포함할 수 있는 서비스 층을 이용한다. ETSI M2M의 서비스 층은 서비스 능력 층(SCL; Service Capability Layer)이라 부를 수 있다. SCL은, M2M 디바이스 내에 구현되거나(이 경우, 디바이스 SCL(DSCL)이라고 함), 게이트웨이 내에 구현되거나(이 경우, 게이트웨이 SCL(GSCL)이라고 함), 및/또는 네트워크 노드 내에 구현될 수 있다(이 경우, 네트워크 SCL(NSCL)이라고 함). oneM2M 서비스 층은 한 세트의 공통 서비스 기능(CSF; Common Service Function)(즉, 서비스 능력)을 지원한다. 한 세트의 하나 이상의 특정한 타입의 CSF의 인스턴스화는 상이한 타입의 네트워크 노드들(예를 들어, 인프라스트럭쳐 노드, 중간 노드, 애플리케이션-특유의 노드) 상에서 호스팅될 수 있는 공통 서비스 엔티티(CSE; Common Services Entity)라고 언급된다. 또한, 본 출원의 접속 방법들은, 서비스 중심 아키텍쳐(SOA; Service Oriented Architecture) 및/또는 자원 중심 아키텍쳐(ROA; resource-oriented architecture)를 이용하여 본 출원의 접속 방법 등의 서비스들에 액세스하는 M2M 네트워크의 일부로서 구현될 수 있다.

일부 실시예에서, M2M 애플리케이션(20 및 20')은 개시된 시스템 및 방법과 연계하여 이용될 수 있다. M2M 애플리케이션들(20 및 20 ')은 UE 또는 게이트웨이와 상호작용하는 애플리케이션들을 포함할 수 있고, 다른 개시된 시스템들 및 방법들과 연계하여 이용될 수도 있다.

한 실시예에서, GUI(2102)를 생성하는 발신자 AE(1802), MQTT 서버+(1812, 1822 및 2004) 및 CSE(1804, 1806 및 2002) 등의 논리적 엔티티들은, 도 22b에 도시된 바와 같이, M2M 서버, M2M 게이트웨이 또는 M2M 디바이스 등의, M2M 노드에 의해 호스팅되는 M2M 서비스 층 인스턴스 내에 호스팅될 수 있다. 예를 들어, GUI(2102)를 생성하는 발신자 AE(1802), MQTT 서버+(1812, 1822 및 2004) 및 CSE(1804, 1806 및 2002) 및 논리적 엔티티 등의 논리적 엔티티들은, M2M 서비스 층 인스턴스 내에 또는 기존의 서비스 능력 내의 서브-기능으로서 개개의 서비스 능력을 포함할 수 있다.

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

일반적으로, 서비스 층(22 및 22')은, 한 세트의 애플리케이션 프로그래밍 인터페이스(API)와 기저 네트워킹 인터페이스를 통해 가치-부가된 서비스 능력을 지원하는 소프트웨어 미들웨어 층을 정의한다. ETSI M2M 및 oneM2M 아키텍쳐 양쪽 모두는 서비스 층을 정의한다. ETSI M2M의 서비스 층은 서비스 능력 층(SCL; Service Capability Layer)이라 부를 수 있다. SCL은 ETSI M2M 아키텍쳐의 다양한 상이한 노드들에서 구현될 수 있다. 예를 들어, 서비스 층의 인스턴스(instance)는, M2M 디바이스 내에 구현되거나(이 경우, 디바이스 SCL(DSCL)이라 부름), 게이트웨이 내에 구현되거나(이 경우, 게이트웨이 SCL(GSCL)이라 부름), 및/또는 네트워크 노드 내에 구현될 수 있다(이 경우, 네트워크 SCL(NSCL)이라 부름). oneM2M 서비스 층은 한 세트의 공통 서비스 기능(CSF; Common Service Function)(즉, 서비스 능력)을 지원한다. 한 세트의 하나 이상의 특정한 타입의 CSF의 인스턴스화는 상이한 타입의 네트워크 노드들(예를 들어, 인프라스트럭쳐 노드, 중간 노드, 애플리케이션-특유의 노드) 상에서 호스팅될 수 있는 공통 서비스 엔티티(CSE; Common Services Entity)라고 언급된다. 제3세대 파트너쉽 프로젝트(3GPP)도 역시 머신-타입 통신(MTC)에 대한 아키텍쳐를 정의했다. 이 아키텍쳐에서, 서비스 층, 및 이 층이 제공하는 서비스 능력들은, 서비스 능력 서버(SCS)의 일부로서 구현될 수 있다. ETSI M2M 아키텍쳐의 DSCL, GSCL, 또는 NSCL에서 구현되든, 3GPP MTC 아키텍쳐의 서비스 능력 서버(SCS)에서 구현되든, oneM2M 아키텍쳐의 CSF 또는 CSE에서 구현되든, 네트워크의 어떤 다른 노드에서 구현되든, 서비스 층의 인스턴스는, 서버, 컴퓨터, 및 다른 컴퓨터 디바이스나 노드를 포함한 네트워크 내의 하나 이상의 단독형 노드 상에서, 또는 하나 이상의 기존의 노드의 일부로서 실행되는 논리적 엔티티(예를 들어, 소프트웨어, 컴퓨터-실행가능한 명령어 등)로서 구현될 수 있다. 예로서, 서비스 층 또는 그 컴포넌트의 인스턴스는 후술되는 도 22c 또는 도 22d에 나타낸 일반적 아키텍쳐를 갖는 네트워크 노드(예를 들어, 서버, 컴퓨터, 게이트웨이, 디바이스 등) 상에서 실행되는 소프트웨어의 형태로 구현될 수 있다.

또한, GUI(2102)를 생성하는 발신자 AE(1802), MQTT 서버+(1812, 1822 및 2004) 및 CSE(1804, 1806 및 2002) 및 논리적 엔티티 등의 논리적 엔티티들은, 서비스-중심 아키텍처(SOA) 및/또는 자원-중심 아키텍쳐(ROA)를 이용하여 본 출원의 서비스에 액세스하는 M2M 네트워크의 일부로서 구현될 수 있다.

도 22c는, M2M 디바이스(18), M2M 게이트웨이(14), M2M 서버 등의, M2M 네트워크 노드(30)의 예시적인 하드웨어/소프트웨어 아키텍쳐의 블록도이다. 노드(30)는, GUI (2102)를 생성하는 발신자 AE(1802), MQTT 서버+(1812, 1822 및 2004) 및 CSE(1804, 1806 및 2002) 및 논리적 엔티티 등의 논리적 엔티티들을 실행하거나 포함할 수 있다. 디바이스(30)는, 도 22a 및 도 22b에 도시된 M2M 네트워크의 일부 또는 비-M2M 네트워크의 일부일 수 있다. 도 22c에 도시된 바와 같이, M2M 노드(30)는, 프로세서 (32), 비-착탈식 메모리(44), 착탈식 메모리(46), 스피커/마이크로폰(38), 키패드(40), 디스플레이, 터치패드 및/또는 표시기(42), 전원(48), GPS(global positioning system) 칩셋(50), 및 기타의 주변기기(52)를 포함할 수 있다. 노드(30)는 또한, 트랜시버(34) 및 송/수신 요소(36) 등의 통신 회로를 포함할 수 있다. M2M 노드(30)는, 실시예와 여전히 일치되면서 전술된 요소들의 임의의 부조합(sub-combination)을 포함할 수 있다는 것을 이해할 것이다. 이 노드는, 여기서 설명된 SMSF 기능을 구현하는 노드일 수 있다.

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

도 22c에 도시된 바와 같이, 프로세서(32)는 그 통신 회로(예를 들어, 트랜시버(34) 및 전송/수신 요소(36))에 결합된다. 프로세서(32)는, 컴퓨터 실행가능한 명령어들의 실행을 통해, 노드(30)로 하여금 자신이 접속된 네트워크를 통해 다른 노드들과 통신하게 하기 위하여 통신 회로를 제어할 수 있다. 특히, 프로세서(32)는, 여기서 및 청구항들에서 설명된 전송 및 수신 단계들을 수행하기 위하여 통신 회로를 제어할 수 있다. 도 22c는 프로세서(32)와 트랜시버(34)를 별개의 컴포넌트로서 도시하고 있지만, 프로세서(32)와 트랜시버(34)는 전자적 팩키지 또는 칩 내에 함께 통합될 수도 있다는 것을 이해할 것이다.

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

또한, 전송/수신 요소(36)가 도 22c에서는 단일 요소로 도시되어 있지만, M2M 노드(30)는 임의 개수의 전송/수신 요소(36)를 포함할 수도 있다. 더 구체적으로는, M2M 노드(30)는 MIMO 기술을 채용할 수도 있다. 따라서, 실시예에서, M2M 노드(30)는, 무선 신호를 전송 및 수신하기 위해 2개 이상의 전송/수신 요소(36)(예를 들어, 복수의 안테나)를 포함할 수도 있다.

트랜시버(34)는, 전송/수신 요소(36)에 의해 전송되는 신호를 변조하고 전송/수신 유닛(36)에 의해 수신되는 신호를 복조하도록 구성될 수 있다. 앞서 언급한 바와 같이, M2M 노드(30)는 멀티-모드 능력을 가질 수도 있다. 따라서, 트랜시버(34)는, M2M 노드(30)가, 예를 들어, UTRA 및 IEEE 802.11 등의 복수의 RAT을 이용하여 통신할 수 있게 하기 위한 복수의 트랜시버를 포함할 수 있다.

프로세서(32)는, 비착탈식 메모리(44) 및/또는 착탈식 메모리(46) 등의, 임의의 타입의 적절한 메모리로부터 정보를 액세스하거나, 여기에 데이터를 저장할 수도 있다. 예를 들어, 프로세서(32)는, 전술된 바와 같이, 세션 컨텍스트를 그 메모리 내에 저장할 수 있다. 비착탈식 메모리(44)는, 랜덤 액세스 메모리(RAM), 판독-전용 메모리(ROM), 하드 디스크, 또는 기타 임의 타입의 메모리 저장 디바이스를 포함할 수 있다. 착탈식 메모리(46)는, 가입자 신원 모듈(SIM; subscriber identity module), 메모리 스틱, 보안 디지털(SD; secure digital) 메모리 카드 등을 포함할 수 있다. 다른 실시예에서, 프로세서(32)는, 서버 또는 가정용 컴퓨터 등의, M2M 노드(30)에 물리적으로 위치해 있지 않은 메모리로부터 정보를 액세스하거나, 여기에 데이터를 저장할 수도 있다. 프로세서(32)는, M2M 서비스 층 세션 이전 또는 공유의 상태를 반영하거나 사용자로부터 입력을 획득하거나 노드의 세션 이전 또는 공유 능력 또는 설정에 관한 정보를 사용자에게 디스플레이하기 위해, 디스플레이 또는 표시기(42) 상의 조명 패턴, 이미지 또는 컬러를 제어하도록 구성될 수 있다. 또 다른 예에서, 디스플레이는 세션 상태에 관한 정보를 보여줄 수 있다. 본 개시내용은, oneM2M 실시예에서 RESTful 사용자/애플리케이션 API를 정의한다. 디스플레이 상에 표시될 수 있는 그래픽 사용자 인터페이스는, 여기서 설명된 기저 서비스 층 세션 기능을 통해, 사용자가 E2E 세션 또는 그 이전 또는 공유를 대화식으로 설정 및 관리하는 것을 허용하도록 API 상단에서 층을 이룰 수도 있다.

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

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

프로세서(32)는 또한, 추가 특징, 기능 및/또는 유선이나 무선 접속을 제공하는 하나 이상의 소프트웨어 및/또는 하드웨어 모듈을 포함할 수도 있는 다른 주변기기(52)에 결합될 수도 있다. 예를 들어, 주변기기(52)는, 가속도계, e-나침반, 위성 트랜시버, 센서, (사진 또는 비디오용) 디지털 카메라, USB(Universal Serial Bus) 포트, 진동 디바이스, 텔레비전 트랜시버, 핸즈프리 헤드셋, Bluetooth® 모듈, 주파수 변조(FM) 무선 유닛, 디지털 음악 재생기, 매체 재생기, 비디오 게임 플레이어 모듈, 인터넷 브라우저 등을 포함할 수 있다.

도 22d는, M2M 서버, 게이트웨이, 디바이스 또는 기타의 노드 등의, M2M 네트워크의 하나 이상의 노드를 구현하는 데에도 이용될 수 있는 예시적인 컴퓨팅 시스템(90)의 블록도이다. 컴퓨팅 시스템(90)은 컴퓨터 또는 서버를 포함할 수 있고, 주로, 소프트웨어 형태일 수 있는 컴퓨터 판독가능한 명령어에 의해, 또는 심지어, 이러한 소프트웨어가 저장되거나 액세스되는 어떠한 수단에 의해 제어될 수 있다. 컴퓨팅 시스템(90)은, GUI (2102)를 생성하는 발신자 AE(1802), MQTT 서버+(1812, 1822 및 2004) 및 CSE(1804, 1806 및 2002) 및 논리적 엔티티 등의 논리적 엔티티들을 실행하거나 포함할 수 있다. 컴퓨팅 시스템(90)은, 예를 들어, M2M 디바이스, 사용자 장비, 게이트웨이, UE/GW, 또는 모바일 케어 네트워크, 서비스 층 네트워크 애플리케이션 제공자, 단말 디바이스(18) 또는 M2M 게이트웨이 디바이스(14)의 노드들을 포함한 기타 임의의 노드일 수 있다. 이러한 컴퓨터 판독가능한 명령어는 중앙 처리 유닛(CPU)(91) 등의 프로세서 내에서 실행되어 컴퓨팅 시스템(90)이 작업을 수행하게 할 수 있다. 많은 공지된 워크스테이션, 서버 및 개인용 컴퓨터에서, 중앙 처리 유닛(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)에 전송되는 비디오 신호를 생성하는 데 요구되는 전자 컴포넌트를 포함한다.

또한, 컴퓨팅 시스템(90)은, 예를 들어, 컴퓨팅 시스템(90)을, 도 22a 및 도 22b의 네트워크(12) 등의 외부의 통신 네트워크에 접속하여 컴퓨팅 시스템(90)이 네트워크의 다른 노드들과 통신할 수 있게 하는 데 이용될 수 있는 네트워크 어댑터(97) 등의 통신 회로를 포함할 수 있다.

여기서 설명된 시스템들, 방법들, 및 프로세스들 중 임의의 것 또는 전부는 컴퓨터 판독가능한 저장 매체에 저장된 컴퓨터 실행가능한 명령어(즉, 프로그램 코드)의 형태로 구현될 수 있고, 이 명령어는, M2M 서버, 게이트웨이, 디바이스 등의, M2M 네트워크의 노드 등의 머신에 의해 실행될 때, 여기서 설명된 시스템, 방법, 및 프로세스를 수행 및/또는 구현한다는 것을 이해할 것이다. 구체적으로는, 게이트웨이, UE, UE/GW, 또는 모바일 코어 네트워크, 서비스 층 또는 네트워크 애플리케이션 제공자의 노드들 중 임의의 노드의 동작을 포함한, 전술된 단계들, 동작들 또는 기능들 중 임의의 것은, 이러한 컴퓨터 실행가능한 명령어의 형태로 구현될 수 있다. GUI(2102)를 생성하는 발신자 AE(1802), MQTT 서버+(1812, 1822 및 2004) 및 CSE(1804, 1806 및 2002) 및 논리적 엔티티 등의 논리적 엔티티들은, 컴퓨터 판독가능한 저장 매체에 저장된 컴퓨터 실행가능한 명령어의 형태로 구현될 수 있다. 컴퓨터 판독가능한 저장 매체로는, 정보 저장을 위한 임의의 비일시적(즉, 유형의 또는 물리적) 방법이나 기술로 구현된 휘발성 및 비휘발성의, 착탈식 또는 비착탈식 매체 양쪽 모두가 포함되지만, 이러한 컴퓨터 판독가능한 저장 매체로서 신호는 포함되지 않는다. 컴퓨터 판독가능 저장 매체로서는, RAM, ROM, EEPROM, 플래쉬 메모리 또는 기타의 메모리 기술, CD-ROM, DVD, 또는 기타의 광학 디스크 스토리지, 자기 카셋트, 자기 테이프, 자기 디스크 저장 또는 기타의 자기 저장 디바이스, 또는 컴퓨터에 의해 액세스될 수 있고 원하는 정보를 저장하는 데 이용될 수 있는 기타 임의의 유형의 또는 물리적 매체가 포함되지만, 이것으로만 제한되는 것은 아니다.

본 개시내용의 주제의 바람직한 실시예를 설명하는 데 있어서, 도면들에 예시된 바와 같이, 특정한 전문용어는 명료성을 위해 채용된 것이다. 그러나, 청구 대상은 이와 같이 선택된 전문용어로 제한되고자 함은 아니고, 각각의 특정한 요소는 유사한 목적을 달성하는 유사한 방식으로 동작하는 모든 기술적 균등물을 포함한다는 것을 이해해야 한다.

상기의 설명은, 최상의 모드를 포함한 본 발명을 개시하기 위해, 및 본 분야의 통상의 기술자가, 임의의 디바이스 또는 시스템을 제작하고 이용하며 임의의 포함된 방법을 수행하는 것을 포함한 본 발명을 실시할 수 있게 하기 위해, 예들을 이용하고 있다. 본 발명의 특허가능한 범위는 청구항들에 의해 정의되며 본 기술분야의 통상의 기술자에게 발생할 수 있는 다른 예들을 포함할 수 있다. 이러한 다른 예들은, 청구항의 자구(literal language)와 상이하지 않은 요소를 포함하거나, 청구항의 자구와 사소한 차이를 갖는 균등한 요소를 포함한다면, 청구항의 범위 내에 드는 것이다.

Claims

프로세서 및 메모리를 포함하는 노드로서, 상기 노드는 상기 노드의 상기 메모리에 저장된 컴퓨터-실행가능한 명령어들을 더 포함하고, 상기 명령어들은, 상기 노드의 상기 프로세서에 의해 실행될 때, 상기 노드로 하여금:
애플리케이션 식별자의 사전-할당에 대한 요청에 관련된 미리결정된 토픽 필터 파라미터(topic filter parameter)를 이용하는 애플리케이션으로부터의 퍼블리시 요청(publish request)을 수신하고 - 상기 애플리케이션은 등록자(registrar)에 아직 등록되지 않음 - ;
상기 미리결정된 토픽 필터 파라미터에 응답하여, 임시 클라이언트 식별자(ID)를 포함하는 상기 등록자에 대한 메시지를 퍼블리시하며;
할당된 애플리케이션 명칭을 페이로드(payload)로서 포함하는 상기 등록자로부터의 메시지를 수신하고;
상기 할당된 애플리케이션 명칭을 상기 애플리케이션에 제공하며;
상기 토픽 필터의 일부로서 상기 할당된 애플리케이션 명칭을 포함하는 상기 애플리케이션으로부터의 가입 요청을 수신하게 하는, 노드.
제1항에 있어서, 상기 임시 클라이언트 식별자는 널 식별자(null identifier)인, 노드.
제1항에 있어서, 상기 노드는 MQTT(Message Queuing Telemetry Transport) 서버를 구현하는, 노드.
제3항에 있어서, 상기 MQTT 서버는 클라이언트 기능을 포함하는, 노드.
제1항에 있어서, 상기 등록자는 등록자 공통 서비스 엔티티(CSE; Common Services Entity )인, 노드.
프로세서 및 메모리를 포함하는 노드로서, 상기 노드는 상기 노드의 상기 메모리에 저장된 컴퓨터-실행가능한 명령어들을 더 포함하고, 상기 명령어들은, 상기 노드의 상기 프로세서에 의해 실행될 때, 상기 노드로 하여금:
애플리케이션 식별자의 사전-할당에 대한 요청에 관련된 미리결정된 토픽 필터 파라미터를 이용하는 서버로의 퍼블리시 요청을 전송하고 - 상기 애플리케이션은 등록자에 아직 등록되지 않음 - ;
상기 등록자로부터 할당된 애플리케이션 명칭을 페이로드(payload)로서 포함하는 상기 서버로부터의 메시지를 수신하고;
상기 토픽 필터의 일부로서 상기 할당된 애플리케이션 명칭을 포함하는 상기 서버로의 가입 요청을 전송하게 하는, 노드.
제6항에 있어서, 상기 서버는 MQTT(Message Queuing Telemetry Transport) 서버인, 노드.
프로세서 및 메모리를 포함하는 노드로서, 상기 노드는 상기 노드의 상기 메모리에 저장된 컴퓨터-실행가능한 명령어들을 더 포함하고, 상기 명령어들은, 상기 노드의 상기 프로세서에 의해 실행될 때, 상기 노드로 하여금:
중간 노드 및 애플리케이션을 나타내는 토픽 필터와 함께 상기 애플리케이션으로부터 가입 요청을 수신하고;
인프라스트럭쳐 노드를 나타내는 토픽 필터와 함께 토픽에 대해 상기 인프라스트럭쳐 노드에서의 서버에 가입 요청을 전송하며;
인프라스트럭쳐 노드를 나타내는 토픽 필터와 함께 토픽에 대해 상기 인프라스트럭쳐 노드에서의 상기 서버로부터 가입 요청을 수신하게 하며,
상기 중간 노드와 인프라스트럭쳐 노드들에서 생성된 토픽들을 이용하여 상기 애플리케이션과 상기 인프라스트럭쳐 노드 사이에 상기 중간 노드를 통해 메시지들이 포워딩되는, 노드.
제8항에 있어서, 상기 노드는 중간 노드인, 노드.
제8항에 있어서, 상기 노드는 MQTT(Message Queuing Telemetry Transport) 서버를 구현하는, 노드.
제10항에 있어서, 상기 MQTT 서버는 클라이언트 기능을 포함하는, 노드.
제8항에 있어서, 상기 인프라스트럭쳐 노드에서의 상기 서버는 MQTT(Message Queuing Telemetry Transport) 서버인, 노드.
노드에 의해 이용되기 위한 방법으로서, 상기 노드는 프로세서와 메모리를 포함하고, 상기 노드는 상기 메모리에 저장된 컴퓨터-실행가능한 명령어들을 더 포함하며, 상기 명령어들은, 상기 프로세서에 의해 실행될 때,
애플리케이션 식별자의 사전-할당에 대한 요청에 관련된 미리결정된 토픽 필터 파라미터(topic filter parameter)를 이용하는 애플리케이션으로부터의 퍼블리시 요청(publish request)을 수신하는 기능 - 상기 애플리케이션은 등록자(registrar)에 아직 등록되지 않음 - ;
상기 미리결정된 토픽 필터 파라미터에 응답하여, 임시 클라이언트 식별자(ID)를 포함하는 상기 등록자에 대한 메시지를 퍼블리시하는 기능;
할당된 애플리케이션 명칭을 페이로드(payload)로서 포함하는 상기 등록자로부터의 메시지를 수신하는 기능;
상기 할당된 애플리케이션 명칭을 상기 애플리케이션에 제공하는 기능; 및
상기 토픽 필터의 일부로서 상기 할당된 애플리케이션 명칭을 포함하는 상기 애플리케이션으로부터의 가입 요청을 수신하는 기능
을 포함하는 방법의 기능들을 수행하는, 방법.
제13항에 있어서, 상기 임시 클라이언트 식별자는 널 식별자(null identifier)인, 방법.
제13항에 있어서, 상기 노드는 MQTT(Message Queuing Telemetry Transport) 서버를 구현하는, 방법.
제15항에 있어서, 상기 MQTT 서버는 클라이언트 기능을 포함하는, 방법.
제13항에 있어서, 상기 등록자는 등록자 CSE(Common Services Entity)인, 방법.
노드에 의해 이용되기 위한 방법으로서, 상기 노드는 프로세서와 메모리를 포함하고, 상기 노드는 상기 메모리에 저장된 컴퓨터-실행가능한 명령어들을 더 포함하며, 상기 명령어들은, 상기 프로세서에 의해 실행될 때,
애플리케이션 식별자의 사전-할당에 대한 요청에 관련된 미리결정된 토픽 필터 파라미터를 이용하는 서버로의 퍼블리시 요청을 전송하는 기능 - 상기 애플리케이션은 등록자에 아직 등록되지 않음 - ;
상기 등록자로부터 할당된 애플리케이션 명칭을 페이로드(payload)로서 포함하는 상기 서버로부터의 메시지를 수신하는 기능; 및
상기 토픽 필터의 일부로서 상기 할당된 애플리케이션 명칭을 포함하는 상기 서버로의 가입 요청을 전송하는 기능
을 포함하는 방법의 기능들을 수행하는, 방법.
제18항에 있어서, 상기 노드는 애플리케이션을 구현하는, 방법.
제18항에 있어서, 상기 서버는 클라이언트 기능을 포함하는 MQTT(Message Queuing Telemetry Transport) 서버인, 방법.
노드에 의해 이용되기 위한 방법으로서, 상기 노드는 프로세서와 메모리를 포함하고, 상기 노드는 상기 메모리에 저장된 컴퓨터-실행가능한 명령어들을 더 포함하며, 상기 명령어들은, 상기 프로세서에 의해 실행될 때,
중간 노드 및 애플리케이션을 나타내는 토픽 필터와 함께 상기 애플리케이션으로부터의 가입 요청을 수신하는 기능;
인프라스트럭쳐 노드를 나타내는 토픽 필터와 함께 토픽에 대해 상기 인프라스트럭쳐 노드에서의 서버에 가입 요청을 전송하는 기능;
상기 인프라스트럭쳐 노드를 나타내는 토픽 필터와 함께 토픽에 대해 상기 인프라스트럭쳐 노드에서의 상기 서버로부터 가입 요청을 수신하는 기능
을 포함하는 방법의 기능들을 수행하고,
상기 중간 노드와 인프라스트럭쳐 노드들에서 생성된 토픽들을 이용하여 상기 애플리케이션과 상기 인프라스트럭쳐 노드 사이에서 상기 중간 노드를 통해 메시지들이 포워딩되는, 방법.
제21항에 있어서, 상기 노드는 중간 노드인, 방법.
제21항에 있어서, 상기 노드는 MQTT(Message Queuing Telemetry Transport) 서버를 구현하는, 방법.
제23항에 있어서, 상기 MQTT 서버는 클라이언트 기능을 포함하는, 방법.
제21항에 있어서, 상기 인프라스트럭쳐 노드에서의 상기 서버는 MQTT(Message Queuing Telemetry Transport) 서버인, 방법.