KR101972932B1 - 향상된 분산 리소스 디렉토리 - Google Patents

Abstract

예시적인 실시예에 따라, 향상된 분산 리소스 디렉토리는 리소스의 균일한 리소스 식별자를 알 필요없이 리소스 검색 능력을 제공한다. 예를 들어, 리소스 디렉토리 노드는 엔드포인트로부터 메시지 페이로드를 수신할 수 있다. 메시지 페이로드는 등록 요구 또는 리소스 검색 요구를 포함한다. 리소스 디렉토리 노드는 메시지 페이로드와 연관된 키들을 결정할 수 있다. 키들은 파라미터들과 이 파라미터들과 연관된 값들을 포함할 수 있다. 키들을 결정시, 키들은 피어 리소스 디렉토리의 아이덴티티를 갖는 매핑 정보를 생성하기 위해 해시 함수에 적용될 수 있다. 매핑 정보에 기초하여, 리소스 디렉토리는 메시지 페이로드를 피어 리소스 디렉토리에 전송할 수 있다. 리소스 디렉토리는 적절한 응답이 요구하는 엔드포인트에게 제공될 수 있도록 피어 리소스 디렉토리로부터 응답을 수신할 수 있다.

Description

향상된 분산 리소스 디렉토리{ENHANCED DISTRIBUTED RESOURCE DIRECTORY}

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

본 출원은 2014년 3월 11일자로 출원된 미국 가특허 출원 번호 제61/951,141호의 이익을 주장하고, 그 개시 내용은 본 명세서에 전체로서 제시된 바와 같이 참조로서 포함된다.

리소스 제약 노드 및 네트워크는 M2M(Machine-to-Machine) 및 IoT(Internet of Things) 시스템의 중요한 부분을 구성한다. IETF CoRE(IETF(internet Engineering Task Force) CoRE(Constrained RESTful Environments) Working Group)는 CoRE RD(Resource Directory)를 개발했다. 도 1은 CoRE 리소스 디렉토리 아키텍처의 예를 나타내고, CoRE 리소스 디렉토리는 웹 서버가 리소스 디렉토리를 발견할 수 있도록 리소스 디렉토리가 지원하는 웹 인터페이스를 특정한다. 또한, 웹 인터페이스는 웹 서버가 리소스 설명을 등록, 유지, 검색(lookup) 및 제거할 수 있게 한다. IETF는 또한 리소스 디렉토리와 연계하여 사용될 수 있는 링크 속성을 정의했다.

도 1을 참조하면, CoRE RD 아키텍처 내의 리소스 디렉토리(100)가 도시되어 있다. 리소스 디렉토리(100)는 인스턴스 엔드포인트(102)에 대해, 일반적으로 엔드포인트로서 지칭될 수 있는, 다른 웹 서버상에 호스팅되는 리소스와 연관되는 웹 링크를 위한 리포지토리(repository)일 수 있다. 엔드포인트는 포트와 연관된 웹 서버를 지칭할 수 있기 때문에, 물리적 노드는 하나 이상의 엔트포인트를 호스팅할 수 있다. 엔드포인트는 다양한 M2M/IoT 디바이스에서 호스팅될 수 있다. 리소스 디렉토리(100)는 웹 링크(리소스 디렉토리 엔트리라고 지칭됨)의 세트를 등록 및 유지하기 위해 엔드포인트(102)를 위한 한 세트의 RESTful(representation state transfer) 인터페이스를 구현한다. 인터페이스는 또한 리소스 디렉토리가 엔트리를 인증할 수 있게 하고, 클라이언트(예를 들어, 클라이언트(104))가 리소스 디렉토리(100)로부터 리소스를 검색할 수 있게 한다. 리소스는 일반적으로 RESTful 아키텍처에서 고유하게 주소 지정 가능한 엔티티를 지칭한다. 엔드포인트는 또한 클라이언트의 역할을 할 수 있고, 그에 따라 클라이언트는 또한 M2M/IoT 디바이스에서 호스팅될 수 있다.

여전히 대체로 도 1을 참조하면, 엔드포인트(102)는 사전에 리소스 디렉토리(100)상에 리소스 디렉토리 엔트리를 등록 및 유지한다. 엔트리는 소프트 상태이고 주기적으로 리프레시될 필요가 있을 수 있다. 엔드포인트(102)에는 주어진 리소스 디렉토리 엔트리를 등록, 갱신 및 제거하기 위해 인터페이스가 제공된다. 게다가, 리소스 디렉토리는 CoRE 링크 포맷을 이용하여 발견될 수 있다. 리소스 디렉토리, 예를 들어 리소스 디렉토리(100)는, 사전에 엔드포인트(100)로부터 웹 링크를 발견할 수 있으며 그들을 리소스 디렉토리 엔트리로서 추가할 수 있다. 리소스 디렉토리(100)는 또한 사전에 웹 링크를 발견하여 기존 리소스 디렉토리 엔트리를 인증할 수 있다. 리소스 디렉토리(100)에 보유된 웹 링크를 발견하기 위한 검색 인터페이스는 CoRE 링크 포맷을 이용하여 제공된다.

도 2는 CoRE 리소스 디렉토리 아키텍처에서 리소스 등록의 현재 기술을 예시한다. 도 1 및 도 2를 참조하면, 엔드포인트(102)는 등록 인터페이스(106)를 이용하여 그것의 리소스를 등록한다. 202에서, 등록 인터페이스(106)는 엔드포인트(102)로부터 POST를 수용한다. POST는 CoRE 링크 포맷에 따라 메시지 페이로드에서 디렉토리에 추가될 리소스의 리스트를 포함할 수 있다. POST는 또한 엔드포인트(102)의 명칭, 엔트포인트(102)와 연관된 도메인, 및 등록의 수명을 가리키는 질의 스트링 파라미터를 포함할 수 있다. 예에서, 엔드포인트 명칭을 제외한 모든 파라미터는 선택적이다. 다음으로, 리소스 디렉토리(100)는 리소스 디렉토리에서 새로운 리소스를 생성하거나 기존 리소스를 갱신하고 그 위치를 반송한다(204에서). 예에 따라서, 엔드포인트(100)는 등록 인터페이스(106)를 이용하여 등록을 리프레시할 때 수신하는 위치를 이용한다. 리소스 디렉토리(100)에서 엔드포인트 리소스는 수명 파라미터에 의해 표시되는 기간 동안 활성 상태를 유지한다. 엔드포인트(102)는 등록 인터페이스(106) 또는 갱신 인터페이스를 이용하여 이 기간 내에 엔트리를 리프레시할 책임이 있다.

도 1 내지 도 3과 연관된 배경 예를 계속해서 참조하면, 함께 등록된 리소스를 발견하는데 리소스 디렉토리(100)를 이용하기 위해, 검색 인터페이스(108)가 제공될 수 있다. 예시적 검색 인터페이스(108)는 예를 들어 "GET" 방법을 구현하기 위해 클라이언트(104)가 RD(100)와 상호 작용하도록 특정된다. 예시적 URI 템플릿은 /{+rd-lookup-base}{lookup-type}{?d,ep,gp,et,rt,page,count,resource-param}이다. 예시적 파라미터는 다음을 포함한다:

· rd-lookup-base:= RD Lookup Function Set path(준수 사양). 이것은 RD 검색 기능 설정의 경로이다. 일부 경우에, RD는 어느 때든지 이 변수에 대한 값 "rd-lookup"을 이용한다.

· lookup-type:=("d", "ep", "res", "gp")(준수 사양). 이 변수는 수행할 검색의 종류(예를 들어, 도메인, 엔드포인트 또는 리소스)를 선택하는데 이용된다.

· ep:= Endpoint(선택적). 엔드포인트, 그룹, 및 리소스 검색에 사용된다.

· d:= Domain(선택적). 도메인, 그룹, 엔드포인트, 및 리소스 검색에 사용된다.

· page:= Page(선택적). 파라미터는 계수 파라미터없이 이용될 수 없다. 결과는 인덱스(페이지*카운트)에서 시작하는 "카운트" 결과를 포함하는 페이지에 설정된 결과로부터 반송된다.

· count:= Count(선택적). 결과의 수는 이 파라미터 값에 한정될 수 있다. 일부 경우에, 파라미터가 존재하지 않으면, RD 구현 특정 디폴트 값이 이용된다.

· rt:= Resource type(선택적). 그룹, 엔드포인트, 및 리소스 검색에 사용된다.

· et:= Endpoint type(선택적). 그룹, 엔드포인트, 및 리소스 검색에 사용된다.

· resource-param:= Link attribute parameters(선택적). 이 파라미터는 RFC 6690 "CoRE 링크 포맷"의 섹션 4.1에 정의되어 있는 같은 임의의 링크 속성을 가리킬 수 있다. 리소스 검색에 이용된다.

도 3은 CoRE 리소스 디렉토리 아키텍처에서 리소스 검색을 위한 현재 기술을 예시한다. 도시된 바와 같이, 302에서, 클라이언트(104)는 리소스 유형(rt) 파라미터를 조사한다. 예에서, 클라이언트(104)는 온도 리소스 유형(예를 들어, 온도 센서)으로 리소스를 발견하려고 시도한다. 따라서, 리소스 유형은 온도로 설정된다. 304에서, 도시된 바와 같이, RD(100)는 리소스를 "coap://node1/temp"의 URI로 반송시킨다.

리소스 디렉토리(100)는, CoRE 리소스 디렉토리 아키텍처에 명시된 바와 같이, 집중화된다. 집중화된 리소스 디렉토리는 인터넷을 통한 확장성이 부족하다. 예를 들어, 어떤 클라이언트는 단지 그들의 로컬 도메인에서 리소스에 액세스하기를 원할 수 있다. 집중화된 리소스 디렉토리는 다른 클라이언트에게 영향을 미치지 않고서 그와 같은 로컬 리소스 관리를 잘 지원하지 않는다. 그 결과, 분산된 리소스 디렉토리가 제안되었다.

도 4는 예시적 DRD 아키텍처에서의 예시적 분산 리소스 디렉토리 DRD(400)를 예시한다. 제안된 분산 리소스 디렉토리 아키텍처는 분산 해시 테이블에 인터페이스를 특정하고, 분산 리소스 디렉토리를 가능하게 하기 위해 분산 해시 테이블 능력을 이용하는 방법을 특정한다. 참여 리소스 디렉토리는 분산 리소스 디렉토리 오버레이를 형성한다. 제안된 분산 리소스 디렉토리(DRD) 아키텍처는 집중화된 리소스 디렉토리와 같은 REST 인터페이스를 제공한다. 엔드포인트는 하나 이상의 CoAP(constrained application protocol) 서버를 실행 수 있는 물리적 노드일 수 있으며, DRD에서 REST 동작들(예를 들어, POST, GET)을 이용할 수 있다. 엔드포인트는 또한 클라이언트의 역할을 할 수 있다. 따라서, 엔드포인트는 CoAP 클라이언트로서 지칭될 수도 있다. 전통적인 또는 레거시 HTTP 클라이언트는 또한 DRD에 저장되는 리소스들에 액세스할 필요가 있을 수도 있다. 도시된 바와 같이, DRD 아키텍처에서 다양한 노드는 엔드포인트(EP)(402), 피어(P)(404), HTTP 프록시(HP)(406), HTTP 클라이언트(408), 및 CoAP 클라이언트(410)를 포함한다. 도시된 바와 같이, 엔드포인트(402)는 "노드(Node)"상에 존재하는 엔티티이고 CoAP 프로토콜을 이용하여 통신하기 때문에, CoAP 엔드포인트로서 지칭될 수 있다. CoAP 엔드포인트는 CoAP 메시지의 소스 또는 목적지일 수 있다. 피어(404)는 풀 오버레이 멤버 노드이며, 이것은 오버레이를 통해 경로가 뒤따르는 메시지를 목적지로 포워딩할 수 있다. 일부 피어는 또한 HTTP 프록시(406)의 역할을 할 수 있다. 다시 말해서, 피어의 역할을 하는 것 이외에, 노드는 또한 프로토콜 번역을 위한 프록시의 역할을 한다. HTTP 프록시(406)는 HTTP 및 CoAP 프로토콜 양쪽 모두를 실행할 수 있는 것은 물론이고 이들 둘 간의 번역을 행할 수 있다. HTTP 클라이언트(408)는 HTTP 메시지를 이용하여 주어진 리소스 디렉토리에 요구를 발송하는 클라이언트이다. CoAP 클라이언트(410)는 CoAP 메시지를 이용하여 주어진 리소스 디렉토리에 요구를 발송하는 CoAP 엔티티이다.

도 5는 분산 리소스 디렉토리(400)에서의 리소스 등록의 현재 기술을 예시한다. 예를 들어, 리소스 등록시, 502에서, EP(402a)는 그것의 리소스를 등록하기 위해 (메시지 페이로드에서의)리소스의 리스트를 포함하는 CoAP POST 메시지를 분산 리소스 디렉토리(400)에 송신한다. EP(402)는 그것의 리소스가 발견될 수 있도록 이것을 행한다. 피어, 예를 들어 제1 피어(404a)(이것은 분산 리소스 디렉토리 오버레이에 참여하기 위해 분산 해시 테이블 알고리즘을 실행한다)가 등록 메시지를 수신할 때, 분산 해시 테이블에서 리소스의 CoAP URI의 해시 하에 CoAP 등록 구조를 저장한다(504에서). CoAP 등록의 페이로드는 오버레이에 값으로서 저장된다. 506에서 제2 피어(404b)로부터 분산 해시 테이블 ACK 메시지를 취득한 후, 제1 피어(404a)는 리소스가 분산 리소스 디렉토리(400)에 등록되었다는 것을 나타내기 위해 (508에서) CoAP ACK 메시지를 EP(402a)로 송신한다.

502에서의 POST 요구는 엔드포인트(402a)를 고유하게 식별하기 위해 이용되는, 엔드포인트(402a)의 명칭을 표시하기 위해 질의 스트링 파라미터를 포함한다. 엔드포인트 명칭 설정은 다양한 대안을 가지고 있다. 한가지 방법은 엔드포인트 명칭을 생성하기 위해 디바이스의 MAC 주소를 해시하는 것이다. 다른 방법은 공통 명칭을 사용하는 것이다.

예로서, 여전히 도 4 및 도 5를 참조하면, 명칭 "9996172"을 갖는 엔드포인트가 분산 리소스 디렉토리(400)에 하나의 온도 리소스와 하나의 라이트 리소스 설명을 등록하기를 원할 경우, 엔드포인트는 POST 요구를 URI "coap://overlay-1.com/proxy-1/.well-known/core?ep=9996172"로 송신한다. 리소스 설명은 메시지의 페이로드에 포함된다. 등록 메시지의 예는 아래 주어진다:

Req: POST coap://overlay-1.com/proxy-1/.well-known/core?ep=9996172

payload:

</temperature-1>;1t=41;rt="temperature";if="sensor"

</light-2>;lt=41;rt="LightLux";if="sensor"

그 결과, 해싱 함수에 적용되는 키는 coap://overlay-1.com/proxy-1/.well-known/core?ep=9996172이고, 이것은 제2 피어(404b)(P2)가 값을 저장하기 위한 피어라는 것을 결정한다. 제2 피어(404b)상에 저장되는 값은 페이로드이다.

또한, 도 6을 참조하면, 도 6은 분산 리소스 디렉토리(400)에서의 리소스 발견의 현재 기술을 예시한다. 분산 리소스 디렉토리(400)는 리소스의 주소 정보를 얻기 위해 CoAP URI와 노드-ID 간의 매핑 정보를 페치함으로써 랑데부를 지원한다. 구체적으로, 602에서, 엔드포인트(도 6에서의 클라이언트(410a))는 요청된 리소스의 URI 정보를 포함하는, CoAP GET 요구를 분산 리소스 디렉토리(400)로 송신한다. 이 요구(도 6에서의 피어(404c))를 다루고 있는 분산 리소스 디렉토리 피어는 604에서, CoAP URI의 해시를 위한 분산 해시 테이블 검색을 수행한다. 다음으로, 분산 해시 테이블은 리소스의 값의 원인이 되는 피어(도 6에서의 피어(404b))를 찾는다. 606에서, 목적지 피어(404b)는 저장된 값을 피어(404c)로 반송한다. 608에서, 피어(404c)는 콘텐츠(예를 들어, 저장된 값)를 클라이언트(410)에게 반송하며, 이것은 엔드포인트(410a)로서 지칭될 수도 있다.

예를 들어, 클라이언트(410a)가 본 명세서에 명시된 바와 같은 URI:coap://overlay-1.com/proxy-1/.well-known/core?ep=9996172를 갖는 리소스를 발견하기를 원하면, 피어(404c)는 GET 요구를 수신하고, 피어(404b)에 매핑되는, URI에 해싱 함수를 이용한다. 그 결과, 피어(404c)는 그 요구를 피어(404b)로 포워딩한다. 피어(404b)는 리소스의 페이로드를 피어(404c)로 반송하고나서, 차례로 페이로드를 클라이언트(410a)에게 반송한다.

상술한 바와 같이, CoRE 리소스 디렉토리는 CoRE 리소스 디렉토리가 집중화되도록 중앙 리소스 디렉토리를 포함한다. 본 명세서에서, 집중화된 디렉토리가 동시에 클라이언트에 의해 효율적으로 액세스되지 않고 IoT 시스템 또는 M2M 네트워크에 대해 효율적으로 일정한 비율로 변경되지 않는다는 것이 인지된다. 게다가, 본 명세서에서, 상술한 분산 리소스 디렉토리는 다른 결점 중에서, 한정된 등록 능력 및 검색 능력을 갖는다는 것이 인지된다.

본 명세서에서는, 향상된 분산 리소스 디렉토리(DRD)를 위한 방법, 디바이스 및 시스템이 기술된다. 예시적인 실시예에서, 노드, 예를 들어 리소스 디렉토리 노드는, 분산 리소스 디렉토리에서 네트워크에서, 엔드포인트로부터 메시지 페이로드를 수신한다. 메시지 페이로드는 등록 요구 또는 리소스 검색 요구를 포함할 수 있다. 메시지 페이로드를 수신시, 리소스 디렉토리 서버는 메시지 페이로드와 연관된 키들을 결정할 수 있다. 키들은 파라미터들과 이 파라미터들과 연관된 값들을 가질 수 있다. 키들을 결정시, 키들은 피어 리소스 디렉토리와 연관된 매핑 정보를 생성하기 위해 해시 함수에 적용된다. 매핑 정보에 기초하여, 리소스 디렉토리 서버는 메시지 페이로드를 피어 리소스 디렉토리에게 전송할 수 있다. 메시지 페이로드를 전송시, 리소스 디렉토리 노드는 피어 리소스 디렉토리로부터 응답을 수신할 수 있다. 응답은 피어 리소스 디렉토리에 저장되는 리소스의 위치 또는 콘텐츠를 표시할 수 있다. 응답을 수신시, 리소스 디렉토리 노드는 응답을 결합시킴으로써 그 결과로 생기는 응답을 생성할 수 있다. 리소스 디렉토리 노드는 결과로 생기는 응답을 요구하는 엔드포인트에 전송할 수 있으며, 이것은 웹 서버일 수 있다. 결과로 생기는 응답은 해시 파라미터를 포함할 수 있다.

본 요약은 아래의 상세한 설명에서 더 설명되는 개념들의 발췌를 간단한 형태로 소개하기 위해 제공된다. 이러한 요약은 청구된 주제의 핵심 특징들 또는 필수 특징들을 식별하도록 의도되지 않으며, 어떤 것도 청구된 주제의 범위를 한정하도록 이용되는 것으로 의도되지 않는다. 또한, 청구된 주제는 본 개시 내용의 모든 부분에서 언급된 임의의 또는 모든 단점을 해결하는 제한사항으로 한정되지 않는다.

더 상세한 이해는 첨부 도면들과 함께 예로서 주어지는 이하의 설명으로부터 이루어질 수 있다:
도 1은 CoRE(Constrained RESTful Environment) 리소스 디렉토리 아키텍처를 예시하는 시스템도이다;
도 2는 CoRE 리소스 디렉토리 아키텍처에서의 리소스 등록의 예를 예시하는 흐름도이다;
도 3은 CoRE 리소스 디렉토리 아키텍처에서의 리소스 검색의 예를 예시하는 흐름도이다;
도 4는 예시적인 분포 리소스 디렉토리 아키텍처를 예시하는 시스템도이다;
도 5는 도 4에 도시된 분포 리소스 디렉토리에서의 리소스 등록의 예를 예시하는 흐름도이다;
도 6은 도 4에 도시된 분포 리소스 디렉토리에서의 리소스 발견의 예를 예시하는 흐름도이다;
도 7은 예시적인 실시예에 따라 저장 지원 메커니즘을 이용하는 엔드포인트로부터의 리소스 등록을 예시하는 흐름도이다;
도 8은 예시적인 실시예에 따라 저장 지원 메커니즘에서의 다른 엔드포인트로부터의 리소스 등록을 예시하는 흐름도이다;
도 9는 예시적인 실시예에 따라 저장 지원 메커니즘에서 라이트 그룹 등록을 예시하는 흐름도이다;
도 10은 예시적인 실시예에 따라 저장 지원 메커니즘에서의 압력 그룹 등록을 예시하는 흐름도이다;
도 11은 예시적인 실시예에 따라 저장 지원 구현시의 리소스 검색을 예시하는 흐름도이다;
도 12는 예시적인 실시예에 따라 저장 지원 구현시의 다른 리소스 검색을 예시하는 흐름도이다;
도 13은 예시적인 실시예에 따라 저장 지원 구현시의 또 다른 리소스 검색을 예시하는 흐름도이다;
도 14는 예시적인 실시예에 따라 저장 지원 구현시의 또 다른 리소스 검색을 예시하는 흐름도이다;
도 15는 예시적인 실시예에 따라 리소스 등록의 예를 예시하는 흐름도이다;
도 16은 다른 예시적인 실시예에 따라 리소스 등록의 다른 예를 예시하는 흐름도이다;
도 17은 예시적인 실시예에 따라 라이트 그룹 등록을 예시하는 흐름도이다;
도 18은 예시적인 실시예에 따라 압력 그룹 등록을 예시하는 흐름도이다;
도 19는 예시적인 실시예에 따라 참조 보장 구현(reference ensured implementation)시의 리소스 검색 예를 예시하는 흐름도이다;
도 20은 예시적인 실시예에 따라 참조 보장 구현시의 다른 리소스 검색 예를 예시하는 흐름도이다;
도 21은 예시적인 실시예에 따라 참조 보장 구현시의 또 다른 리소스 검색을 예시하는 흐름도이다;
도 22a는 하나 이상의 개시된 실시예가 구현될 수 있는 예시적인 M2M 또는 IoT 통신 시스템의 시스템도이다;
도 22b는 도 22a에 예시된 M2M/IoT 통신 시스템 내에서 이용될 수 있는 예시적인 아키텍처의 시스템도이다;
도 22c는 도 22a에 예시되어 있는 통신 시스템 내에 사용될 수 있는 예시적인 M2M/IoT 단말 또는 게이트웨이 디바이스의 시스템도이다;
도 22d는 도 22a의 통신 시스템의 양태가 구현될 수 있는 예시적인 컴퓨팅 시스템의 블록도이다.

다음의 상세한 설명은 예시적인 실시예들을 예시하기 위해 제공되고 본 발명의 범위, 적용가능성, 또는 구성을 제한하도록 의도되지 않는다. 다양한 변화들은 본 발명의 사상 및 범위로부터 벗어나지 않고서 요소들 및 단계들의 기능 및 배열로 이루어질 수 있다.

용어 "오버레이 네트워크(overlay network)"는, 본 명세서에 사용되는 바와 같이, 다른 네트워크 위에 구축되는 네트워크를 지칭한다. 오버레이 네트워크에서의 노드는 가상 또는 논리 링크에 의해 연결되는 것으로서 생각될 수 있으며, 이들 각각은 기본적인 네트워크에서, 경로에 대응한다. 예를 들어, P2P(peer-to-peer) 네트워크와 같은 분산 시스템은 그들의 노드가 인터넷 위에서 실행되기 때문에 오버레이 네트워크라고 생각될 수 있다. "가정용 리소스 디렉토리(RD)"인 노드는, 본 명세서에 사용되는 바와 같이, EP가 그것의 리소스를 등록하기를 원할 때 엔드포인트(EP)를 위한 접촉의 제1 포인트를 지칭한다. 가정용 RD는 또한 클라이언트가 리소스를 발견하기를 원할 때 클라이언트를 위한 접촉의 제1 포인트를 지칭한다. 본 명세서에 사용되는 바와 같이, "저장(storing) RD"인 노드는, 리소스 등록 엔트리를 저장하는 피어와 가정용 RD가 클라이언트의 발견 요구를 포워딩하는 곳을 지칭할 수 있다. 본 명세서에 사용되는 바와 같이, 달리 정의되지 않는다면, "책임(Responsible) RD"인 노드는, 리소스 등록 메시지에서 모든 가능한 키에 대해 해싱 함수를 이용함으로써 발생되는 피어들의 RD를 지칭할 수 있다. 본 명세서에 사용되는 바와 같이, 달리 정의되지 않는다면, "코어 책임(Core Responsible) RD"인 노드는 가정용 RD가 리소스 발견 요구를 포워딩하는 접촉의 제1 포인트인 책임 RD들 중 하나를 지칭한다

예시적인 실시예에 따라, 향상된 분포 리소스 디렉토리는, 본 명세서에 기술되는 바와 같이, 리소스의 URI(uniform resource identifier)를 알지 못하고 리소스 검색을 지원할 수 있다. 일예에서, 리소스 설명의 다수의 사본은 다수의 리소스 디렉토리(RD)에 저장되고, 이것은 본 명세서에서 피어 RD로서 지칭된다. 참조 보장(RE) 구현으로서 지칭되는, 본 명세서에 기술되는 다른 예시적인 구현에서, 가정용 피어는 등록 메시지를 하나의 피어 RD에만 송신하고, 다른 피어 RD들에게 그것과 연관된 리소스 및 정보가 저장된 곳을 통보한다.

도 4에 도시된 분포 리소스 디렉토리 아키텍처를 일반적으로 참조하면, 본 명세서에서 기술되는 실시예는 고급 분포 리소스 검색을 가능하게 한다. 일예에서, 클라이언트는 리소스를 발견 및 검색하기 위해 사전에 리소스 URI를 알 필요가 없다. 예를 들어, 클라이언트는 그들 각각의 가정용 RD에 링크 파라미터 기반 질의를 특정하는 리소스를 요구 및 검색할 수 있다. 다시 말해서, 분포 리소스 디렉토리는 링크 파라미터 기반 질의를 충족하는 리소스를 클라이언트에게 반송할 수 있다.

저장 지원(SA) 구현으로서 지칭될 수 있는 예시적인 실시예에서, 리소스 등록의 여분의 사본은 다수의 피어에 제공된다. 본 명세서에서는, 데이터 저장 용량이 증가되었기 때문에, 그러한 데이터 저장과 연관된 비용이 감소되었고, 그에 따라 피어들은 효율적으로 데이터 저장 능력을 갖출 수 있다는 것이 인지된다. 이하 상세히 기술되는 바와 같이, 피어들은 리소스의 값으로 가능한 키 워드들/파라미터들에 대해 해싱 함수를 이용함으로써 데이터 저장을 위해 선택될 수 있다. 선택된 피어들은 그들의 저장 능력을 이용하여 리소스 등록을 저장할 수 있다. 일부 경우에, 모든 리소스 디렉토리 피어들 중에서 통합되고 분포된 해싱 공간을 생성하기 위해 H()로 표시되는 하나의 해싱 함수가 적용된다고 가정된다.

편의상, 본 명세서에 사용되는 바와 같이, 달리 정의되지 않는다면, 피어 RD는 단순히 피어로서 지칭될 수 있다. 클라이언트는 제한 없이 그리고 예의 방식으로 하기 제시된 것과 같은 다양한 검색 키 워드들/파라미터들을 지정할 수 있다:

ㆍ d: domain

· ep: endpoint

· gp: group name

· et: endpoint type

· rt: resource type

· lt: resource life time

· if: interface

추가적으로 예시하기 위해, 하나 이상의 RD 피어에 등록될 수 있는 페이로드와 리소스들의, 제한없이 제시된 예들이 하기에 나타나 있다:

1. ep=9996172

payload:</temperature-1>;lt=41;rt="Temperature";if="sensor",

</temperature-2>;lt=41;rt="LightLux";if="sensor"

2. ep=9234571

payload:</Temp-1>;rt="Temperature";if="gateway"

3. gp=lights

payload:<coap://host1:port1>;ep="node1";d="domain1"

<coap://host1:port 1>;ep="node2";d="domain1"

4. gp=pressure

Payload<coap://host2:port 2>;ep="node2";d="domain1"

예시적인 실시예에서, 주어진 엔드포인트는 후보 IP 주소를 다양한 방법으로 획득함으로써 디렉토리 서버를 찾을 수 있다. 예를 들어, 일부 경우에, 각각의 피어 RD는 적어도 하기 베이스 RD 리소스들을 갖는다: </rd>;rt="core.rd";</rd-lookup>;rt="core.rd-lookup"; 및 </rd-group>;rt="core.rd-group". 본 명세서에 기술되는 바와 같이, 엔드포인트는 리소스 인터페이스를 이용하여 그것의 가정용 RD에 그것의 리소스를 등록할 수 있다. 이 인터페이스는 엔드포인트로부터 POST를 수용할 수 있다. POST는 CoRE 링크 포맷으로 메시지 페이로드로서 디렉토리에 추가될 리소스들의 리스트를 포함할 수 있다. POST는 또한 질의 스트링 파라미터를 포함할 수 있다. 일부 경우에, 엔드포인트 또는 그룹의 명칭을 바로 해싱하는 것 대신에, 피어 RD는 리소스의 페이로드에 포함되어 있는 모든 파라미터들과 그들의 값(예를 들어, 리소스 링크 포맷 설명)에 해싱 함수를 적용할 수 있다. 해싱 함수가 적용된 후에, 가정용 RD는 동일 파라미터를 갖는 리소스를 저장하는 것에 책임이 있는 피어들의 주소를 획득할 수 있다. 따라서, 피어들의 큰 저장 용량과 이와 연관된 낮은 비용을 레버리지함으로써, 가정용 RD는 리소스 페이로드를 해시된 피어들에 전송할 수 있다. 앞서 논의한 바와 같이, 본 명세서에서 추가적으로 기술된 예시적인 SA 구현에 대해 기술된 4개의 예시적인 리소스들과 페이로드들이 있다. 도 4에서 EP(702)로서 예시되어 있는, EP 9996172의 리소스 등록을 포함하는 예가 첫번째로 기술될 것이다.

도 7 내지 도 21(이하 후술됨)은 리소스를 관리하고 검색하기 위한 방법들 및 장치의 다양한 실시예를 예시한다. 이러한 도면에서, 다양한 단계들 또는 동작들은 하나 이상의 엔드포인트, 클라이언트 및/또는 피어에 의해 수행된다는 것을 나타낸다. 이러한 도면들에 예시되어 있는 엔드포인트들, 클라이언트들 및/또는 피어들은 통신 네트워크에서 논리적 엔티티를 나타낼 수 있고 후술되는 도 22c 또는 도 22d에 예시된 일반적인 아키텍처들 중 하나를 포함할 수 있는, 그러한 네트워크의 노드의 메모리에 저장된 소프트웨어의 형태(예를 들어, 컴퓨터 실행가능 명령어들)로 구현될 수 있고, 또한 그러한 네트워크의 프로세서 상에서 실행되는 형태로 구현될 수 있다. 즉, 도 7 내지 도 21에 예시된 방법은 컴퓨터 실행가능 명령어들이, 노드의 프로세서에 의해 실행될 때, 도면들에 예시된 단계들을 수행하는, 예를 들어, 도 22c 또는 도 22d에 예시된 노드 또는 컴퓨터 시스템과 같은 네트워크 노드의 메모리에 저장되는 소프트웨어의 형태(예를 들어, 컴퓨터 실행가능 명령어들)로 구현될 수 있다. 이러한 도면들에 예시되어 있는 임의의 송신 및 및 수신 단계는 노드의 프로세서의 제어 하의 노드의 통신 회로(예를 들어, 각각 도 22c와 도 22d의 회로(34 또는 97))와 실행되는 컴퓨터 실행가능 명령어들(예를 들어, 소프트웨어)에 의해 수행될 수 있다는 것이 또한 이해된다.

이제, 도 7을 참조하면, 예시적인 네트워크(700)는 EP(702)와 피어들(1, 3, 5, 및 11)(P1, P3, P5, 및 P11)을 포함한다. 예시적인 네트워크(700)이 개시된 주제의 설명을 용이하게 하기 위해 간략화되지만, 본 개시 내용의 범주를 제한하려는 의도가 아니라는 것을 이해할 것이다. 다른 디바이스들, 시스템들, 및 구성들은 네트워크(400)와 같은 네트워크에 부가하여, 또는 이에 대신하여 본 명세서에 개시된 실시예들을 구현하는데 이용될 수 있고, 모든 그러한 실시예들은 본 개시 내용의 범주 내에 있는 것으로 간주된다. 또한, 참조 번호들은 도면들에서 동일 또는 유사한 특징들을 나타내기 위해 다양한 도면들에서 반복될 수 있다는 것이 이해될 것이다.

도시된 바와 같이, 예시적인 예에 따라, 엔드포인트(702)는 9996172의 명칭을 가지고 P1에 그것의 리소스들을 등록하며, 이것은 704에서 그것의 가정용 RD이다. 706에서, P1은 페이로드에 포함되는 링크 포맷을 해석하고 이 등록과 연관되는 키 워드들/파라미터들이 있다는 것을 결정할 수 있다:

· ep=9996172

· lt=41

· rt="Temperature"

· rt="LightLux"

· if="sensor"

상술한 키 워드들/파라미터들은 해싱 함수에 적용될 키들로서 이용될 수 있다. 해싱 함수가 적용될 때, 예에 따라, 결과는 P3, P5, 및 P11을 포함한다. 따라서, 708a, 708b, 및 708c에서, P1은 등록 메시지를 각각 P3, P5, 및 P7에 포워딩한다. 피어들 P3, P5, 및 P7은 각각 페이로드를 저장하고 확인(confirmation)을 P1으로 반송한다(710a-c에서). 712에서, P1은 확인 응답을 결합시킬 수 있다. 714에서, 확인에 응답하여, P1은 EP(702)에 응신한다. 일부 경우에, 상이한 키는 등록 메시지가 동일한 피어 RD에 포워딩되게 한다. 예를 들어, lt=41 또는 if="sensor"를 해싱함으로써, 양쪽 해시의 결과는 P5가 피어 리소스 디렉토리이어야 한다는 것을 나타낼 수 있다. 유사하게, rt="Temperatuer"와 rt="LightLux"를 해싱할 때, 양쪽 해시의 결과는 P11이 피어 리소스 디렉토리이어야 한다는 것을 나타낼 수 있다.

이제 도 8을 참조하면, 예시적인 네트워크(800)는 EP(802)로서 예시되어 있는 EP 9234571과, 피어들(3, 2, 11, 및 6)(P3, P2, P11, 및 P6)을 포함한다. 예시적인 네트워크(800)가 개시된 주제의 설명을 용이하게 하기 위해 간략화되지만, 본 개시 내용의 범주를 제한하려는 의도가 아니라는 것을 이해할 것이다. 다른 디바이스들, 시스템들, 및 구성들은 네트워크(800)와 같은 네트워크에 부가하여, 또는 이에 대신하여 본 명세서에 개시된 실시예들을 구현하는데 이용될 수 있고, 모든 그러한 실시예들은 본 개시 내용의 범주 내에 있는 것으로 간주된다.

도시된 바와 같이, 예시적인 예에 따라, 엔드포인트(802)는 9234571의 명칭을 가지고 P3에 그것의 리소스들을 등록하며, 이것은 804에서 그것의 가정용 RD이다. 806에서, P3는 페이로드에 포함되는 링크 포맷을 해석하고 이 등록과 연관되는 키 워드들/파라미터들이 있다는 것을 결정할 수 있다:

· ep=9234571

· rt="Temperature"

· if="gateway"

상술한 키 워드들/파라미터들은 해싱 함수의 입력들로서 이용될 수 있다. 해싱 함수가 적용될 때, 예에 따라, 결과는 P2, P11, 및 P5를 포함한다. 따라서, 808a, 808b, 및 808c에서, P3는 등록 메시지를 각각 P2, P11, 및 P5에 포워딩한다. 피어들 P2, P11, 및 P5는 각각 페이로드를 저장하고 확인을 P3로 반송한다(810a-c에서). 812에서, P3는 확인 응답을 결합시킬 수 있다. 814에서, 확인에 응답하여, P3는 EP(802)에 응신한다.

이제 도 9를 참조하면, "라이트(light)" 그룹 등록 예가 예시적인 실시예에 따라 제시된다. 도시된 바와 같이, 예시적인 네트워크(900)는 후술되는 바와 같은 관리 노드인 EP(902)와, 피어들(1, 3, 6, 및 2)(P1, P3, P6, 및 P2)을 포함한다. 예시적인 네트워크(900)가 개시된 주제의 설명을 용이하게 하기 위해 간략화되지만, 본 개시 내용의 범주를 제한하려는 의도가 아니라는 것을 이해할 것이다. 다른 디바이스들, 시스템들, 및 구성들은 네트워크(900)와 같은 네트워크에 부가하여, 또는 이에 대신하여 본 명세서에 개시된 실시예들을 구현하는데 이용될 수 있고, 모든 그러한 실시예들은 본 개시 내용의 범주 내에 있는 것으로 간주된다.

도시된 바와 같이, 예시된 예에 따라, 관리 노드(EP(902))는 그룹을 구성하는데 이용되었다. 904에서, EP(902)는 그것의 가정용 RD(P1)에 요구를 한다. 요구는 생성할 그룹의 명칭과 그룹이 속하는 선택적인 도메인을 표시한다. 등록 메시지는 또한 그 그룹에 속하는 엔드포인트의 리스트를 포함할 수 있다. 906에서, P1은 페이로드에 포함되는 링크 포맷을 해석하고 이 등록과 연관되는 키 워드들/파라미터들이 있다는 것을 결정한다:

· gp=lights

· ep="node1"

· d="domain1"

· ep="node2"

상술한 키 워드들/파라미터들은 해싱 함수의 입력들로서 이용될 수 있다. 해싱 함수가 적용될 때, 예에 따라, 결과는 P1, P3, P6, 및 P2를 포함한다. 따라서, 908a, 908b, 및 908c에서, P1은 등록 메시지를 각각 P3, P6, 및 P2에 포워딩한다. 피어들 P3, P6, 및 P2는 각각 페이로드를 저장하고 확인을 P1으로 반송한다(910a-c에서). P1은 해시된 피어들 중 하나이기 때문에, 907에서 등록 메시지를 저장할 수도 있다. 912에서, P3는 확인 응답을 결합시킬 수 있다. 914에서, 확인에 응답하여, P3는 EP(902)에 응신한다.

이제 도 10을 참조하면, "압력(pressure)" 그룹 등록 예가 예시적인 실시예에 따라 제시된다. 도시된 바와 같이, 예시적인 네트워크(1000)는 후술되는 바와 같은 관리 노드인 EP(1002)와, 피어들(1, 3, 6, 및 2)(P1, P3, P6, 및 P2)을 포함한다. 예시적인 네트워크(1000)가 개시된 주제의 설명을 용이하게 하기 위해 간략화되지만, 본 개시 내용의 범주를 제한하려는 의도가 아니라는 것을 이해할 것이다. 다른 디바이스들, 시스템들, 및 구성들은 네트워크(1000)와 같은 네트워크에 부가하여, 또는 이에 대신하여 본 명세서에 개시된 실시예들을 구현하는데 이용될 수 있고, 모든 그러한 실시예들은 본 개시 내용의 범주 내에 있는 것으로 간주된다.

도시된 바와 같이, 예시된 예에 따라, 관리 노드(EP(902))는 그룹을 구성하는데 이용되었다. 1004에서, EP(1002)는 그것의 가정용 RD(P1)에 요구를 한다. 요구는 생성할 그룹의 명칭과 그룹이 속하는 선택적인 도메인을 표시한다. 등록 메시지는 또한 그 그룹에 속하는 엔드포인트의 리스트를 포함할 수 있다. 1006에서, P1은 페이로드에 포함되는 링크 포맷을 해석하고 이 등록과 연관되는 키 워드들/파라미터들이 있다는 것을 결정한다:

· gp=pressure

· d="domain1"

· ep="node2"

상술한 키 워드들/파라미터들은 해싱 함수의 입력들로서 이용될 수 있다. 해싱 함수가 적용될 때, 예에 따라, 결과는 P1, P3, P6, 및 P2를 포함한다. 따라서, 1008a, 1008b, 및 1008c에서, P1은 등록 메시지를 각각 P3, P6, 및 P2에 포워딩한다. 피어들 P3, P6, 및 P2는 각각 페이로드를 저장하고 확인을 P1으로 반송한다(1010a-c에서). P1은 해시된 피어들 중 하나이기 때문에, 1007에서 등록 메시지를 저장할 수도 있다. 1012에서, P3는 확인 응답을 결합시킬 수 있다. 914에서, 확인에 응답하여, P3는 EP(1002)에 응신한다.

예로서, 분포된 리소스 및 그룹 등록이 도 7 내지 도 10을 참조하여 기술된 바와 같이 수행된 후, 피어 RD들은 예로서 그리고 제한없이 제시된, 표 1(하기)에 나타난 정보를 저장할 수 있다.

표 1: 예시적인 리소스 디렉토리 콘텐츠

P1
rd-group	2	gp=lights: <coap://host1:port1>;ep="node1";d="domain1", < coap://host1:port1>;ep="node2";d="domain1"
	3	gp=pressure: < coap://host2:port2>;ep="node2";d="domain1"
P2
rd	35	ep=9234571: </Temp-1>;rt="Temperature"; if="gateway"
rd-group	5	gp=lights: <coap://host1:port1>; ep="node1";d="domain1", <coap://host1:port1>;ep="node2";d="domain1"
	13	gp=pressure: <coap://host2:port2>;ep="node2";d="domain1"
P3
rd	121	ep=9996172: </temperature-1>;lt=41;rt="Temperature";if="sensor", </temperature-2>;lt=41;rt="LightLux";if="sensor"
rd-group	1	gp=lights: <coap://host1:port1>;ep="node1";d="domain1", <coap://host1:port1>;ep="node2";d="domain1"
P5
rd	132	ep=9996172: </temperature-1>;lt=41;rt="Temperature";if="sensor", </temperature-2>;lt=41;rt="LightLux";if="sensor"
P6
rd	11	ep=9234571: </Temp-1>;rt="Temperature";if="gateway"
rd-group	12	gp=lights: <coap://host1:port1>;ep="node1";d="domain1", <coap://host1:port1>;ep="node2";d="domain1"
P11
rd	245	ep=9996172: </temperature-1>;lt=41;rt="Temperature";if="sensor", </temperature-2>;lt=41;rt="LightLux";if="sensor"
	133	ep=9234571: </Temp-1>;rt="Temperature";if="gateway"
rd-group	2	gp=pressure: <coap://host2:port2>;ep="node2";d="domain1"

일부 경우에, 상술한 리소스 및 그룹 등록 방법들은 리소스들 및 그룹들이 상술한 기존 검색(발견) 인터페이스를 통해 검색(발견)되게 할 수 있다. 이제 리소스 및 그룹 검색으로 되돌아 가면, 배경으로서, 클라이언트는 리소스 검색 요구를 그것의 가정용 RD에 송신한다. 리소소 검색 요구는 클라이언트가 발견하기를 원하는 검색 유형 및 파라미터들을 지정할 수 있다. 가정용 RD는 요구를 분석하고 클라이언트가 특정하는 키들을 추출한다. 예시적인 실시예에서, 가정용 RD는 리소스 등록을 저장한 피어 RD들을 계산하기 위해 그 키들에 대해 해싱 함수를 적용한다. 키들은 AND/OR에 의해 연결될 수 있다. 예를 들어, 키들은 최종적인 RD들(RD들은 해시 함수가 적용된 이후에 표시된다)이 각각 동일한 리소스 등록을 저장하기 때문에 AND에 의해 연결될 수 있고, 요구는 그들 중 하나에 포워딩될 수 있다. 가정용 RD는 예를 들어, 목적지 RD의 로드 또는 가정용 RD와 목적지 RD 간의 대역폭과 같은 소정 맥락 정보에 기초하여 또는 무작위로 목적지 RD를 선택할 수 있다. 키들은 특정된 요구를 충족하는 리소스들이 최종적인 RD들에 걸쳐서 분포될 수 있을 것 같을 때 OR에 의해 연결될 수 있다. 그 결과, 가정용 RD는 리소스의 조인트 세트를 수신하기 위해 모든 최종적인 RD들에 요구를 포워딩할 필요가 있을 수 있다.

가정용 RD는 요구가 포워딩되어야 하는 피어 RD들을 결정할 수 있다. 가정용 RD가 피어 RD들로부터 응답을 수신한 후, 예를 들어, 중복없이, 리소스의 완벽한 리스트를 포함하는 검색 결과를 생성할 수 있고, 그 리스트를 요구하는 클라이언트에게 반송시킬 수 있다.

다양한 예시적인 실시예에 따라 리소스 및 그룹 검색을 설명하는 예들이 하기 제공된다. 도 11을 참조하면, GET /rd-lookup/res?rt="Temperature" AND it="gateway" 검색 요구를 포함하는 예가 도시되어 있다. 도 11은 클라이언트(1102), 가정용 RD(1104), 및 피어 11(P11)을 포함하는 예시적인 네트워크(1100)를 나타낸다. 예시적인 네트워크(1200)가 개시된 주제의 설명을 용이하게 하기 위해 간략화되지만 본 개시 내용의 범위를 제한하려는 의도는 아니라는 것을 이해할 것이다. 다른 디바이스들, 시스템들, 및 구성들은 네트워크(1100)와 같은 네트워크에 추가하여 또는 그 대신에, 본 명세서에서 개시된 실시예들을 구현하기 위하여 이용될 수도 있고, 이러한 모든 실시예들은 본 개시 내용의 범위 내인 것으로서 고려된다.

도시된 바와 같이, 1106에서, 클라이언트(1102)는 리소스 검색 요구를 그것의 가정용 RD(1104)로 송신한다. 클라이언트(1102)는 동시에 rt="Temperature" and it="gateway"를 충족시키는 리소스들을 취득하기를 원한다. 1108에서, 가정용 RD는 요구에 표시된 2개의 키에 해싱 함수를 적용한다. 해싱 함수가 적용될 때, 예에 따라, 결과는 P11과 P6를 포함한다. 예시적 양태에서, 가정용 RD(1104)는 완벽한 리소스 검색 결과를 얻기 위해 표시된 RD들(P11 및 P6) 중 하나를 선택할 수 있다. 예시된 예에서, 가정용 RD는 P11을 선택하고, 1110에서, 검색 요구를 P11으로 보낸다. 1112에서, P11은 요구와 연관된 응답을 가정용 RD(1104)로 반송한다. 가정용 RD(1104)는, 1114에서, 응답을 클라이언트(1102)에게 포워딩한다.

도 12를 참조하면, GET /rd-lookup/res?rt="LightLux" OR it="gateway" 요구를 포함하는 예가 도시되어 있다. 도 12는 클라이언트(1202), 가정용 RD(1204), 및 피어들 11(P11) 및 6(P6)를 포함하는 예시적인 네트워크(1200)를 나타낸다. 예시적인 네트워크(1100)가 개시된 주제의 설명을 용이하게 하기 위해 간략화되지만 본 개시 내용의 범위를 제한하려는 의도는 아니라는 것을 이해할 것이다. 다른 디바이스들, 시스템들, 및 구성들은 네트워크(1200)와 같은 네트워크에 추가하여 또는 그 대신에, 본 명세서에서 개시된 실시예들을 구현하기 위하여 이용될 수도 있고, 이러한 모든 실시예들은 본 개시 내용의 범위 내인 것으로서 고려된다.

도시된 바와 같이, 1206에서, 클라이언트(1202)는 리소스 검색 요구를 그것의 가정용 RD(1204)로 송신한다. 클라이언트(1202)는 rt="LightLux" or it="gateway"를 충족시키는 리소스들을 취득하기를 원한다. 1208에서, 가정용 RD는 요구에 표시된 2개의 키에 해싱 함수를 적용한다. 해싱 함수가 적용될 때, 예에 따라, 결과는 P11과 P6를 포함한다. 예시적 양태에서, OR이 키들을 연결하기 때문에, 가정용 RD(1104)는 완벽한 리소스 검색 결과를 얻기 위해 표시된 RD들(P11 및 P6) 양측 모두에 요구를 포워딩할 필요가 있다. 따라서, 예시된 예에서, 가정용 RD는 검색 요구를 P11(1210a에서)과 P6(1210b에서)에 송신한다. 1212a 및 1212b에서, P11 및 P6는, 각각 요구와 연관된 응답을 가정용 RD(1204)로 반송시킨다. 1214에서, 가정용 RD는 수신되는 응답을 결합시킬 수 있다. 또한, 1214에서, 가정용 RD(1204)는 중복 응답이 제거되도록 결과를 결합시킬 수 있다. 1216에서, 가정용 RD는 완벽한 검색 결과인 결합된 응답을, 클라이언트(1202)에 전송하고, 이렇게 함으로써 검색 요구를 충족시킨다.

도 13을 참조하면, GET /rd-lookup/gp?d="domain1" 검색 요구를 포함하는 그룹 검색 요구의 예가 도시되어 있다. 도 13은 클라이언트(1302), 가정용 RD(1304), 및 피어 1(P1)을 포함하는 예시적인 네트워크(1300)를 나타낸다. 예시적인 네트워크(1300)가 개시된 주제의 설명을 용이하게 하기 위해 간략화되지만 본 개시 내용의 범위를 제한하려는 의도는 아니라는 것을 이해할 것이다. 다른 디바이스들, 시스템들, 및 구성들은 네트워크(1300)와 같은 네트워크에 추가하여 또는 그 대신에, 본 명세서에서 개시된 실시예들을 구현하기 위하여 이용될 수도 있고, 이러한 모든 실시예들은 본 개시 내용의 범위 내인 것으로서 고려된다.

도시된 바와 같이, 1306에서, 클라이언트(1302)는 리소스 검색 요구를 그것의 가정용 RD(1304)로 송신한다. 클라이언트(1302)는 d="domain1"를 충족시키는 그룹들을 얻기를 원한다. 1308에서, 가정용 RD는 요구(d="domain1")에 표시된 키에 해싱 함수를 적용한다. 해싱 함수가 적용될 때, 예에 따라, 결과는 P1을 포함한다. 예시적인 예에서, 가정용 RD(1304)는 1310에서, 검색 요구를 P1에 송신한다. 1312에서, P11은 요구와 연관된 응답을 가정용 RD(1304)로 반송시킨다. 1314에서, 가정용 RD(1304)는 응답을 클라이언트(1302)에게 포워딩한다.

도 14를 참조하면, GET /rd-lookup/gp?ep="node2" 검색 요구를 포함하는 그룹 검색 요구의 예가 도시되어 있다. 도 14는 클라이언트(1402), 가정용 RD(1404), 및 피어 2(P2)를 포함하는 예시적인 네트워크(1400)를 나타낸다. 예시적인 네트워크(1400)가 개시된 주제의 설명을 용이하게 하기 위해 간략화되지만 본 개시 내용의 범위를 제한하려는 의도는 아니라는 것을 이해할 것이다. 다른 디바이스들, 시스템들, 및 구성들은 네트워크(1400)와 같은 네트워크에 추가하여 또는 그 대신에, 본 명세서에서 개시된 실시예들을 구현하기 위하여 이용될 수도 있고, 이러한 모든 실시예들은 본 개시 내용의 범위 내인 것으로서 고려된다.

도시된 바와 같이, 1406에서, 클라이언트(1402)는 리소스 검색 요구를 그것의 가정용 RD(1404)로 송신한다. 클라이언트(1402)는 그 안에 엔드포인트(node2)를 갖는 그룹을 얻기를 원한다. 1408에서, 가정용 RD는 요구(ep="node2")에 표시된 키에 해싱 함수를 적용한다. 해싱 함수가 적용될 때, 예에 따라, 결과는 노드 2인 P2를 포함한다. 예시적인 예에서, 가정용 RD(1404)는 1410에서, 검색 요구를 P2에 송신한다. 1412에서, P1은 요구와 연관된 응답을 가정용 RD(1404)로 반송시킨다. 1414에서, 가정용 RD(1404)는 응답을 클라이언트(1402)에게 포워딩한다.

참조 보장(RE) 구현으로서 참조될 수 있는 다른 예시적인 실시예에서, 피어 RD들은 예를 들어, 리소스들 자신을 저장하는 것 보다 저장 RD의 참조를 유지한다.

이제 도 15를 참조하면, EP(702)와 피어들 1, 3, 5, 및 11(P1, P3, P5, 및 P11)을 포함하는 예시적인 네트워크(700)가 도시되어 있다. 도시된 바와 같이, 예시된 예에 따라, 엔드포인트(702)는 9996172의 명칭을 가지고 1504에서 그 리소스들을 가정용 RD인 P1에 등록한다. 1506에서, P1은 페이로드에 포함되는 링크 포맷을 해석하여 이 등록과 연관되는 키 워드들/파라미터들이 있다고 결정할 수 있다:

· ep=9996172

· lt=41

· rt="Temperature"

· rt="LightLux"

· if="senser"

상술한 키 워드들/파라미터들은 해싱 함수에 적용될 키들로서 이용될 수 있다. 해싱 함수가 적용될 때, 예에 따라, 결과는 P3, P5, 및 P11을 포함한다. 또한, 예시된 예에 따라, 1506에서, P1은 등록 메시지가 포워딩되는 3개의 최종적인 RD들 중 하나(P3, P5 또는 P11)를 선택할 수 있다. 1508에서, P1은 등록 메시지를 선택된 피어(P3)에게 포워딩한다. 1510에서, P3는 페이로드를 저장하고 확인을 P1으로 반송한다. 1514a 및 1514b에서, P1은 등록 메시지가 P3에 저장된다는 것을 P5 및 P11에게 각각 통보한다. 1516a 및 1516b에서, P5 및 P11은, 각각 미래의 리소스 검색을 위해 적절한 참조 하에 P3의 주소를 저장한다. 1512에서, P1은 EP(702)에 응신하며, 이렇게 함으로써 리소스 요구를 충족시킨다.

이제 도 16을 참조하면, EP(802) 및 피어들 1, 3, 5, 및 11(P3, P2, P11, 및 P6)을 포함하는 예시적인 네트워크(800)가 도시되어 있다. 도시된 바와 같이, 예시적인 예에 따라, 엔드포인트(802)는 1604에서, 그 리소스들을 가정용 RD인 P3에 등록한다. 1606에서, P3는 페이로드에 포함되는 링크 포맷을 해석하여 이 등록과 연관되는 키 워드들/파라미터들이 있다고 결정할 수 있다:

· ep=9234571

· rt="Temperature"

· if="gateway"

상술한 키 워드들/파라미터들은 해싱 함수에 적용될 키들로서 이용될 수 있다. 해싱 함수가 적용될 때, 예에 따라, 결과는 P2, P11, 및 P6을 포함한다. 또한, 예시된 예에 따라, 1606에서, P3는 등록 메시지가 포워딩되는 3개의 최종적인 RD들 중 하나(P2, P11 또는 P6)를 선택할 수 있다. 1608에서, P3는 등록 메시지를 선택된 피어(P2)에게 포워딩한다. 1610에서, P2는 페이로드를 저장하고 확인을 P3로 반송한다. 1614a 및 1614b에서, P3는 등록 메시지가 P2에 저장된다는 것을 P11 및 P6에게 각각 통보한다. 1616a 및 1616b에서, P11 및 P6은, 각각 미래의 리소스 검색을 위해 적절한 참조 하에 P2의 주소를 저장한다. 1612에서, P1은 EP(802)에 응신하며, 이렇게 함으로써 리소스 요구를 충족시킨다.

이제 도 17을 참조하면, "lights" 그룹 등록 예가 예시적인 실시예에 따라 제공된다. 도시된 바와 같이, 예시적인 네트워크(900)는 하기 설명되는 바와 같은 관리 노드인 EP(902)와, 피어들 1, 3, 6, 및 2(P1, P3, P6, 및 P2)를 포함한다. 1704에서, EP(902)는 그것의 가정용 RD(P1)에 요구한다. 요구는 생성할 그룹의 명칭과 그룹이 속하는 선택적인 도메인을 표시한다. 등록 메시지는 또한 그 그룹에 속하는 엔드포인트의 리스트를 포함할 수 있다. 1706에서, P1은 페이로드에 포함되는 링크 포맷을 해석하여 이 등록과 연관되는 키 워드들/파라미터들이 있다고 결정할 수 있다:

· gp=lights

· ep="node1"

· d="domain1"

· ep="node2"

상술한 키 워드들/파라미터들은 해싱 함수의 입력으로서 이용될 수 있다. 해싱 함수가 적용될 때, 예에 따라, 결과는 P1, P3, P6, 및 P2를 포함한다. 도시된 바와 같이, 1708에서, P1은 예를 들어, 등록 메시지를 포워딩하는데 이용되는 네트워크 대역폭을 세이브하기 위해, 그 자체에 등록을 저장한다. 1712a-c에서, P1은 각각의 피어들이 책임지고 있는 파라미터를 포함하는, 리소스 등록이 P1에 저장된다는 것을 P3, P6, 및 P2에 통보할 수 있다. 1714a-c에서, P3, P6, 및 P2는 미래의 리소스 검색을 위해 적절한 참조 하에 P1의 주소를 저장한다. 1710에서, 결과는 EP(902)에 전송된다.

이제 도 18을 참조하면, "pressure" 그룹 등록 예가 예시적인 실시예에 따라 제공된다. 도시된 바와 같이, 예시적인 네트워크(1800)는 EP(1802)와 피어들 1 및 11을 포함한다. 예시적인 네트워크(1800)가 개시된 주제의 설명을 용이하게 하기 위해 간략화되지만 본 개시 내용의 범위를 제한하려는 의도는 아니라는 것을 이해할 것이다. 다른 디바이스들, 시스템들, 및 구성들은 네트워크(1800)와 같은 네트워크에 추가하여 또는 그 대신에, 본 명세서에서 개시된 실시예들을 구현하기 위하여 이용될 수도 있고, 이러한 모든 실시예들은 본 개시 내용의 범위 내인 것으로서 고려된다.

1804에서, 피어 P1은 그룹 등록 요구를 수신할 수 있다. 1806에서, 해싱 함수는 그룹 리소스를 피어 RD P11, P1, 및 P2에 매핑할 수 있다. 1808에서, P1은 등록 메시지를 포워딩시 네트워크 대역폭 이용을 세이브하기 위해 등록을 그 자체에 저장할 수 있다. 1810에서, P1은 리소스 등록이 P1에 저장된다는 것을 P11에게 통보할 수 있다. 도시된 바와 같이, P1의 주소가 (1804에서) 이미 P2에 통보되었기 때문에, P2는 1810에서 통보될 필요가 없다. 1812에서, P11은 미래의 리소스 검색을 위해 적절한 참조 하에 P1의 주소를 저장할 수 있다.

예시적인 실시예에서, 상술한 예에서 설명된 분포된 리소스 및 그룹 등록이 발생한 후에, 피어 RD들은 표 2(하기)에 나타난 정보를 저장할 수 있다.

표 2: 예시적인 RE 구현의 예시적 리소스 디렉토리 콘텐츠

P1
rd-group	2	gp=lights: <coap://host1:port1>; ep="node1";d="domain1?, < coap://host1:port1>;ep="node2";d="domain1"
	3	gp=pressure: < coap://host2:port2>;ep="node2";d="domain1"
P2
rd	35	ep=9234571: </Temp-1>;rt="Temperature"; if="gateway"
Reference	P1
P3
rd	121	ep=9996172: </temperature-1>;lt=41;rt="Temperature";if="sensor", </temperature-2>;lt=41;rt="LightLux";if="sensor"
Reference	P1
P5
Reference	P3
P6
Reference	P2
	P1
P11
Reference	P3
	P2
	P1

이제 리소스 및 그룹 검색 구현으로 되돌아 가면, 다른 예시적인 실시예에서, 클라이언트는 리소스 및 그룹 검색 요구를 그것의 가정용 RD에 전송할 수 있다. 가정용 RD는 파라미터들에 해싱 함수를 사용함으로써, 요구에 명시된 파라미터들에 대응하는 책임 피어 RD들을 결정할 수 있다. 한 예에서, 하나의 파라미터만이 요구에 포함되고, 가정용 RD는 책임 RD에 요구를 포워딩할 수 있다. 책임 RD는 요구에 명시된 검색 유형에 기초하여, rd 또는 rd-group 디렉토리를 검색할 수 있다. 책임 RD는 또한 그것의 참조 카테고리에 열거된 RD들에 요구를 포워딩할 수 있다. 가정용 RD는 책임 RD와 참조 카테고리에서의 RD들로부터 모든 응답을 수집할 수 있고 결과를 클라이언트에게 반송할 수 있다. 다른 예시적 시나리오에서, 요구에 포함되는 다중 파라미터가 있고 파라미터들은 AND에 의해 연결된다. 그러한 시나리오에서, 가정용 RD는 책임 RD들 중 하나(코어 책임 RD)로 요구를 포워딩할 수 있다. 코어 책임 RD는 다른 파라미터들에 대해 해싱 함수를 적용할 수 있으며 다른 책임 RD들이 있다고 결정할 수 있다. 코어 책임 RD는 참조 카테고리의 리스트에 대한 요구가 또한 부착되는 요구를 다른 책임 RD들에게 포워딩할 수 있다. 코어 책임 RD는 모든 책임 RD들의 참조 카테고리에서 RD들의 조인트 세트를 찾아낼 수 있다. 다음으로, 코어 책임 RD는 RD들의 조인트 세트에 요구를 포워딩할 수 있다. 코어 책임 RD는 모든 응답을 수집하여 그들을 차례로 응답을 클라이언트에게 반송하는 가정용 RD에게 반송시킬 수 있다.

다른 예시적 시나리오에서, 요구에 포함되는 다중 파라미터가 있고 파라미터들은 OR에 의해 연결된다. 그러한 시나리오에서, 가정용 RD는 책임 RD들(코어 책임 RD) 중 하나에게 요구를 포워딩할 수 있다. 코어 책임 RD는 해싱 함수를 다른 파라미터에게 적용할 수 있고 다른 책임 RD들이 있다고 결정할 수 있다. 코어 책임 RD는 참조 카테고리의 리스트에 대한 요구가 또한 첨부되어 있는, 요구를 다른 책임 RD들에게 포워딩할 수 있다. 코어 책임 RD는 모든 책임 RD들의 참조 카테고리에서 RD들의 수퍼 세트를 발견할 수 있다. 다음으로, 코어 책임 RD는 RD들의 수퍼 세트에게 요구를 포워딩할 수 있다. 이것은 모든 응답을 수집할 수 있고 응답을 클라이언트에게 차례로 반송하는 가정용 RD에게 반송할 수 있다.

이제 도 19를 참조하면, GET /rd-lookup/res?rt="Temperature" AND it="gateway" 검색 요구를 포함하는 예가 도시되어 있다. 도 19는 클라이언트(1902), 가정용 RD(1904), 및 피어들 11, 6, 1, 및 2를 포함하는 예시적인 네트워크(1900)를 나타낸다. 예시적인 네트워크(1900)가 개시된 주제의 설명을 용이하게 하기 위해 간략화되지만 본 개시 내용의 범위를 제한하려는 의도는 아니라는 것을 이해할 것이다. 다른 디바이스들, 시스템들, 및 구성들은 네트워크(1900)와 같은 네트워크에 추가하여 또는 그 대신에, 본 명세서에서 개시된 실시예들을 구현하기 위하여 이용될 수도 있고, 이러한 모든 실시예들은 본 개시 내용의 범위 내인 것으로서 고려된다.

도시된 바와 같이, 1906에서, 클라이언트(1902)는 리소스 검색 요구를 그것의 가정용 RD(1904)로 송신한다. 클라이언트(1902)는 동시에 rt="Temperature" and it="gateway"를 충족시키는 리소스들을 취득하기를 원한다. 1908에서, 가정용 RD(1904)는 예시된 예에 따라 P11 및 P6인, 책임 RD들을 취득하기 위해 해싱 함수에 2개의 키를 적용할 수 있다. 가정용 RD(1904)는 그들 중 하나를 코어 책임 RD로서 선택할 수 있다. 예시된 예에서, 가정용 RD(1904)는 P11을 선택하고, 그에 따라 요구를 포워딩한다(1910에서). 도시된 바와 같이, P11은 다른 파라미터에 해싱 함수를 이용할 수 있고, P6이 또한 책임 RD라고 결정할 수 있다. 1912에서, P11은 요구를 P6에 송신할 수 있고 참조 리스트 요구는 요구에 포함(첨부)될 수 있다. 예에서, P6가 어떠한 매칭 리소스도 찾지 못하면, 1914에서, P2 및 P1의 주소를 P11로 반송시킬 수 있다. 1916에서, P11은 P1과 P2가 (양쪽 참조 리스트에서)조인트 세트를 포함한다고 결정한다. 1918a 및 1918b에서, P11은 그 이후에 P1 및 P2 양측에 각각 요구를 포워딩할 수 있다. 도시된 바와 같이, 예시된 예에 따라, P1이 어떠한 매칭 리소스도 찾지 못하면, 1920a에서 "찾을 수 없음(not found)" 응답을 반송시킬 수 있다. 예시된 예에 따라, P2는 매칭 리소스를 찾고, 그것을 P11로 반송시킨다(1920b에서). 1922에서, P11은 그 이후에 응답을 클라이언트(1902)에게 차례로 전송하는, 가정용 RD(1904)에게 리소스를 반송시킬 수 있다(1924에서).

이제 도 20을 참조하면, GET /rd-lookup/res?rt="LightLux" OR it="gateway" 검색 요구를 포함하는 예가 도시되어 있다. 도 20은 클라이언트(2002), 가정용 RD(2004), 및 피어들 11, 6, 1, 2, 및 3을 포함하는 예시적인 네트워크(2000)를 나타낸다. 예시적인 네트워크(2000)가 개시된 주제의 설명을 용이하게 하기 위해 간략화되지만 본 개시 내용의 범위를 제한하려는 의도는 아니라는 것을 이해할 것이다. 다른 디바이스들, 시스템들, 및 구성들은 네트워크(2000)와 같은 네트워크에 추가하여 또는 그 대신에, 본 명세서에서 개시된 실시예들을 구현하기 위하여 이용될 수도 있고, 이러한 모든 실시예들은 본 개시 내용의 범위 내인 것으로서 고려된다.

도시된 바와 같이, 2006에서, 클라이언트(2002)는 리소스 검색 요구를 그것의 가정용 RD(2004)로 송신한다. 클라이언트(2002)는 rt="LightLux" or it="gateway"를 충족시키는 리소스들을 취득하기를 원한다. 2008에서, 가정용 RD(2004)는 예시된 예에서 P11 및 P6인, 대응하는 RD들을 취득하기 위해 해싱 함수에 2개의 키를 적용할 수 있다. 가정용 RD(2004)는 그들 중 하나를 코어 책임 RD(예시된 예에서 P11)로서 선택할 수 있다. P11은 다른 파라미터에 해싱 함수를 적용할 수 있고, P6이 또한 책임 RD라고 결정할 수 있다. 2012에서, P11은 요구를 P6에 송신할 수 있고, 참조 리스트가 또한 첨부될 수 있다. 2014에서, P6가 어떠한 매칭 리소스도 찾지 못하면, P2 및 P1의 주소를 P11로 반송시킬 수 있다. 2016에서, 예시된 예에 따라, P11은 P1, P2 및 P3가 양쪽 참조 리스트의 슈퍼 세트라고 결정할 수 있다. 2018a-c에서, P11은 그 이후에 P1, P2 및 P3에 각각 요구를 포워딩할 수 있다. 2018a에서, P1이 어떠한 매칭 리소스도 찾지 못하면, "찾을 수 없음(not found)" 응답을 반송시킬 수 있다. 2018b 및 2018c에서, P2 및 P3는 매칭 리소스를 찾고, 그것을 P11로 반송시킨다. P11은 모든 매칭 리소스들을 연관시킬 수 있으며 그들을 응답을 클라이언트(2002)에게 차례로 전송하는(2022에서), 가정용 RD(2004)로 반송시킬 수 있다(2020에서).

도 21은 예시적인 실시예에 따라 다른 예시적인 리소스 검색예 4를 나타낸다. 이 예시적인 실시예에서, 클라이언트(2102)는 그룹 검색을 수행할 수 있다. 2106에서, 클라이언트(2102)는 GET /rd-lookup/gp?ep="node2" 요구를 그것의 가정용 RD(2104)로 송신한다. 도시된 바와 같이, 클라이언트(2102)는 그 안에 엔드포인트(node2)를 갖는 그룹을 얻기를 원한다. 2108에서, 가정용 RD(2104)는 예시된 예에서 P2인, 대응하는 RD를 취득하기 위해 해싱 함수에 키(ep="node2")를 적용할 수 있다. 가정용 RD(2104)는 2110에서, 요구를 P2에 포워딩할 수 있다. P2는 참조 카테고리에 저장되는 P1을 가질 수 있다. 그 결과, P2는 2112에서, P1으로 요구를 포워딩할 수 있다. 2114에서, 예시된 예에 따라, P1은 매칭 리소스를 찾고 그들을 P2로 반송시킨다. 2116에서, P2는 응답을 클라이언트(2102)에게 차례로 전송하는, 가정용 RD(2104)로 응답을 반송시킬 수 있다.

따라서, 상술한 개시 내용을 통해 설명된 바와 같이, 노드는 엔드포인트로부터 수신되는 메시지 페이로드와 연관되는 하나 이상의 키들을 결정할 수 있다. 엔드포인트는 웹 서버, M2M 디바이스, 또는 게이트웨이로서 작동하도록 구성될 수 있다. 노드는 프로세서, 메모리, 및 통신 회로를 포함할 수 있다. 노드는 그것의 통신 회로를 통해 통신 네트워크에 연결될 수 있고, 노드는 노드의 프로세서에 의해 실행될 때, 노드가 다양한 동작을 수행할 수 있게 하는, 노드의 메모리에 저장되는 컴퓨터 실행가능 명령어들을 포함할 수 있다. 한 예에서, 메시지 페이로드는 등록 요구를 포함한다. 노드는 매핑 정보를 생성하기 위해 하나 이상의 키를 해시 함수에 적용할 수 있다. 상술한 바와 같이, 매핑 정보는 피어 리소스 디렉토리 서버의 적어도 하나의 아이덴티티를 포함할 수 있다. 노드는 매핑 정보에 기초하여, 메시지 페이로드를 하나 이상의 피어 리소스 디렉토리 서버로 전송할 수 있다. 노드는 하나 이상의 피어 리소스 디렉토리 서버로부터 적어도 하나의 응답을 수신할 수 있다. 적어도 하나의 응답은 리소스의 위치를 나타낼 수 있다. 그리고, 위에서도 상세히 설명된 바와 같이, 수신되는 적어도 하나의 응답에 기초하여, 노드(예를 들어, 리소스 디렉토리 서버)는 결과로 생기는 응답을 엔드포인트로 전송할 수 있다. 메시지 페이로드와 연관되는 하나 이상의 키는 적어도 하나의 파라미터와 적어도 하나의 파라미터와 연관되는 적어도 하나의 값을 포함할 수 있다. 적어도 하나의 파라미터는 도메인, 엔드포인트, 그룹 명칭, 엔드포인트 유형, 리소스 유형, 리소스 수명, 또는 인터페이스를 포함할 수 있다. 위에서 상세히 기술된 일례에서, 적어도 하나의 파라미터는 복수의 파라미터이고 적어도 하나의 값은 복수의 값이고, 해시 함수는 등록 요구시 파라미터들 및 값들 각각에 적용된다. 또한, 메시지 페이로드가 전송되는 하나 이상의 피어 리소스 디렉토리 서버는 각각이 메시지 페이로드를 저장하는 복수의 피어 리소스 디렉토리 서버일 수 있고, 노드는 얼마나 많은 파라미터들이 메시지 페이로드에 있는지에 기초하여, 얼마나 많은 피어 리소스 디렉토리 서브들이 복수의 피어 리소스 디렉토리 서버들에 있는지를 결정할 수 있다. 대안적으로, 위에서도 상세히 설명된 바와 같이, 메시지 페이로드가 전송되는 하나 이상의 피어 리소스 디렉토리 서버는 메시지 페이로드를 저장하는 선택된 하나의 피어 리소스 디렉토리 서버일 수 있으며, 노드는 복수의 피어 리소스 디렉터가 메시지 페이로드를 저장하는 선택된 하나의 피어 리소스 디렉토리에 참조를 저장하도록 선택된 하나의 피어 리소스 디렉토리에 대한 참조를 복수의 피어 리소스 디렉토리 서버에 전송할 수 있다. 등록 요구가 엔드포인트의 명칭 및 리소스 설명을 포함할 수 있다는 것이 이해될 것이다.

다른 예에서, 메시지 페이로드는 리소스 검색 요구를 포함하고, 메시지 페이로드와 연관되는 하나 이상의 키는 하나 이상의 파라미터를 포함한다. 리소스 검색 요구는 검색 유형 및 하나 이상의 파라미터를 포함할 수 있다. 한 예에서, 파라미터가 제1 논리 접속사(예를 들어, AND)를 이용하여 서로 연결되면, 노드는 메시지 페이로드를 복수의 피어 리소스 디렉토리 서버로 전송한다. 복수는 얼마나 많은 파라미터들이 메시지 페이로드에 있는지에 기초할 수 있다. 다른 예에서, 위에서 상세히 설명된 바와 같이, 파라미터들이 제2 논리 접속사(예를 들어, OR)를 이용하여 서로 연결되면, 노드는 메시지 페이로드를 하나의 피어 리소스 디렉토리 서버에만 전송한다. 따라서, 메시지 페이로드가 전송되는 하나 이상의 피어 리소스 디렉토리 서버는 리소스 검색 요구를 매핑 정보에 의해 표시된 다른 피어 리소스 디렉토리 서버들에 전파하는 선택된 하나의 피어 리소스 디렉토리 서버일 수 있다.

도 22a는 하나 이상의 개시된 실시예들이 구현될 수 있는 예시적인 M2M(machine-to-machine), IoT(Internet of Things), 또는 WoT(Web of Things) 통신 시스템(10)의 도면이다. 일반적으로, M2M 기술은 IoT/WoT를 위한 빌딩 블록을 제공하고, 임의의 M2M 디바이스, M2M 게이트웨이 또는 M2M 서비스 플랫폼은 IoT/WoT의 컴포넌트뿐만 아니라 IoT/WoT 서비스 계층 등일 수 있다. 도 7 내지 도 21 중 임의의 도면에 예시된 클라이언트들, 엔드포인트들, 피어들 또는 리소스 디렉토리들 중 어떤 것도 도 22a 내지 도 22d에 예시된 것과 같은 통신 시스템의 노드를 포함할 수 있다.

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

도 22a에 도시된 바와 같이, M2M/IoT/WoT 통신 시스템(10)은 기반구조 도메인 및 필드 도메인을 포함할 수 있다. 기반구조 도메인은 종단 대 종단 M2M 배치의 네트워크 측을 지칭하고, 필드 도메인은 통상적으로 M2M 게이트웨이 뒤의 지역 네트워크들을 지칭한다. 필드 도메인 및 기반구조 도메인은 둘 모두 다양한 네트워크 노드들(예를 들어, 서버들, 게이트웨이들, 디바이스)을 포함할 수 있다. 예를 들어, 필드 도메인은 M2M 게이트웨이들(14) 및 단말 디바이스들(18)을 포함할 수 있다. 임의의 수의 M2M 게이트웨이 디바이스(14)들과 M2M 단말 디바이스(18)들이 원하는 바에 따라 M2M/IoT/WoT 통신 시스템(10)에 포함될 수 있다는 점이 이해될 것이다. M2M 게이트웨이 디바이스(14)들 및 M2M 단말 디바이스(18)들 각각은 통신 네트워크(12) 또는 직접 무선 링크를 통해 신호들을 송신 및 수신하도록 구성된다. M2M 게이트웨이 디바이스(14)는 무선 M2M 디바이스(예를 들어, 셀룰러 및 비-셀룰러)뿐만 아니라 고정 네트워크 M2M 디바이스(예를 들어, PLC)가 통신 네트워크(12) 또는 직접 무선 링크 등의 오퍼레이터 네트워크를 통해 통신하는 것을 허용한다. 예를 들어, M2M 디바이스(18)들은 통신 네트워크(12) 또는 직접 무선 링크를 통해 데이터를 수집하고 그 데이터를 M2M 애플리케이션(20) 또는 M2M 디바이스들(18)에 전송할 수 있다. M2M 디바이스(18)들은 또한 M2M 애플리케이션(20) 또는 M2M 디바이스(18)로부터 데이터를 수신할 수 있다. 또한, 데이터 및 신호는 후술되는 바와 같이, M2M 서비스 계층(22)을 통해 M2M 애플리케이션(20)에 송신되고 이로부터 수신될 수 있다. M2M 디바이스(18)들 및 게이트웨이(14)들은, 예를 들어, 셀룰러, WLAN, WPAN(예를 들어, 지그비(Zigbee), 6LoWPAN, 블루투스(Bluetooth)), 직접 무선 링크, 및 유선을 포함하는 다양한 네트워크들을 통해 통신할 수 있다. 예시적인 M2M 디바이스(18)들은 태블릿들, 스마트 폰들, 의료 디바이스들, 온도, 및 날씨 모니터들, 커넥티드 카들, 스마트 계량기들, 게임 콘솔들, 개인용 정보 단말기들, 건강, 및 피트니스 모니터들, 라이트들, 온도 조절기들, 어플라이언스들, 차고 도어들 및 다른 액추에이터-기반 디바이스들, 보안 디바이스들 및 스마트 배출구들을 포함하지만, 이에 한정되지는 않는다.

도 22b를 참조하면, 필드 도메인에서의 예시된 M2M 서비스 계층(22)은 M2M 애플리케이션(20), M2M 게이트웨이 디바이스(14)들 및 M2M 단말 디바이스(18)들 및 통신 네트워크(12)에 대한 서비스를 제공한다. M2M 서비스 계층(22)은 임의 수의 M2M 애플리케이션들, M2M 게이트웨이 디바이스(14)들, M2M 단말기 디바이스(18)들, 및 통신 네트워크(12)들과 원하는 대로 통신할 수 있음이 이해될 것이다. M2M 서비스 계층(22)은 하나 이상의 서버, 컴퓨터, 또는 그와 유사한 것에 의해 구현될 수 있다. M2M 서비스 계층(22)은 M2M 단말 디바이스(18)들, M2M 게이트웨이 디바이스(14)들 및 M2M 애플리케이션(20)들에 적용되는 서비스 능력들을 제공한다. M2M 서비스 계층(22)의 기능들은 예를 들어, 웹 서버로서, 셀룰러 코어 네트워크, 클라우드 등에서 다양한 방식들로 구현될 수 있다.

예시된 M2M 서비스 계층(22)과 유사하게, 기반구조 도메인내에 M2M 서비스 계층(22')이 존재한다. M2M 서비스 계층(22')은 기반구조 도메인 내의 M2M 애플리케이션(20') 및 기본 통신 네트워크(12')에 대한 서비스들을 제공한다. M2M 서비스 계층(22')은 필드 도메인 내의 M2M 게이트웨이 디바이스(14)들 및 M2M 단말 디바이스(18)들에 대한 서비스들도 제공한다. M2M 서비스 계층(22')은 임의 수의 M2M 애플리케이션들, M2M 게이트웨이 디바이스들 및 M2M 단말 디바이스들과 통신할 수 있다는 것을 이해할 것이다. M2M 서비스 계층(22')은 상이한 서비스 제공자에 의해 서비스 계층과 상호작용할 수 있다. M2M 서비스 계층(22')은 하나 이상의 서버들, 컴퓨터들, 또는 가상 머신들(예를 들어, 클라우드/컴퓨트/저장 팜들, 기타 등등) 또는 이와 유사한 것에 의해 구현될 수 있다.

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

M2M 애플리케이션들(20, 20')은 제한 없이, 수송, 건강 및 건강 관리, 접속되는 홈, 에너지 관리, 자산 추적, 및 보안과 감시와 같은 다양한 산업들에서의 응용들을 포함할 수 있다. 앞서 언급한 바와 같이,

시스템의 디바이스들, 게이트웨이들, 및 다른 서버들에 걸쳐 실행되는 M2M 서비스 계층은, 예를 들어, 데이터 수집, 디바이스 관리, 보안, 빌링, 위치 추적/지오펜싱(geofencing), 디바이스/서비스 발견, 및 레거시 시스템들 통합과 같은 기능들을 지원하고, 이러한 기능들을 서비스들로서 M2M 애플리케이션들(20, 20')에 제공한다.

일반적으로, 도 22a 및 22b에 예시된 서비스 계층들(22, 22')과 같은 서비스 계층(SL)은 한 세트의 애플리케이션 프로그램 인터테이스(API)들 및 기본 네트워킹 인터페이스를 통하여 부가 가치 서비스 능력들을 지원하는 소프트웨어 미들웨어 계층을 정의한다. ETSI M2M과 oneM2M 아키텍처들 양쪽 모두는 서비스 계층을 정의한다. ETSI M2M의 서비스 계층은 서비스 기능 계층(SCL)으로 지칭된다. SCL은 ETSI M2M 아키텍처의 다양한 상이한 노드들에서 구현될 수 있다. 예를 들어, 서비스 계층의 인스턴스는 M2M 디바이스(여기서 디바이스 SCL(DSCL)이라 지칭됨), 게이트웨이(여기서 게이트웨이 SCL(GSCL)이라 지칭됨), 및/또는 네트워크 노드(여기서 네트워크 SCL(NSCL)이라 지칭됨) 내에서 구현될 수 있다. oneM2M 서비스 계층은 한 세트의 공통 서비스 기능(CSF)(즉, 서비스 능력)을 지원한다. CSF들 중의 하나 이상의 특정 유형들의 세트의 인스턴스 발생은 상이한 유형들의 네트워크 노드들(예를 들어, 기반구조 노드, 미들 노드, 애플리케이션-특정 노드)상에서 호스팅될 수 있는 CSE(Common Services Entity)로서 지칭될 수 있다. 3세대 파트너쉽 프로젝트(3GPP)는 또한 MTC(machine-type communication)들에 대한 아키텍처를 정의했다. 그 아키텍처에서, 서비스 계층, 및 이것이 제공하는 서비스 능력들은 서비스 능력 서버(SCS)의 일부로서 구현된다. ETSI M2M 아키텍처의 DSCL, GSCL, 또는 NSCL에서, 3GPP MTC 아키텍처의 서비스 능력 서버(SCS)(Service Capability Server)에서, oneM2M 아키텍처의 CSF 또는 CSE에서, 또는 네트워크의 일부 다른 노드에서 구현되든 간에, 서비스 계층의 인스턴스는, 서버들, 컴퓨터들, 및 다른 컴퓨팅 디바이스들 또는 노드들을 포함하는 네트워크 내의 하나 이상의 독립형 노드들 상에서 실행하는 논리 엔티티(예를 들어, 소프트웨어, 컴퓨터 실행가능 명령어들 및 이와 유사한 것)로서, 또는 하나 이상의 기존 노드들의 일부로서 구현될 수 있다. 예로서, 서비스 계층 또는 그 컴포넌트의 인스턴스(예를 들어, AS/SCS(100))는 하기에 기술되는 도 22c 또는 도 22d에 예시되는 일반적인 아키텍처를 갖는 네트워크 노드(예를 들어, 서버, 컴퓨터, 게이트웨이, 디바이스, 또는 이와 유사한 것) 상에서 실행하는 소프트웨어의 형태로 구현될 수 있다.

또한, 본 명세서에 기술되는 방법들 및 기능성들은 예를 들어 상술한 네트워크 및 애플리케이션 관리 서비스와 같은 서비스에 액세스하기 위해 SOA(Service Oriented Architecture) 및/또는 ROA(resource-oriented architecture)를 이용하는 M2M 네트워크의 일부로서 구현될 수 있다.

도 22c는 도 22a 및 도 22b에 예시된 것과 같은 M2M 네트워크에서 M2M 서버, 게이트웨이, 디바이스, 또는 다른 노드로서 동작할 수 있는 도 7 내지 도 21에 예시된 클라이언트들, 엔드포인트들, 피어들, 또는 리소스 디렉토리들 중 하나와 같은 네트워크의 노드의 예시적인 하드웨어/소프트웨어 아키텍처의 블록도이다. 도 22c에 도시된 바와 같이, 노드(30)는 프로세서(32), 송수신기(34), 송신/수신 요소(36), 스피커/마이크로폰(38), 키패드(40), 디스플레이/터치패드(42), 비이동식 메모리(44), 이동식 메모리(46), 전원(48), GPS(global positioning system) 칩셋(50), 및 다른 주변 장치들(52)을 포함할 수 있다. 노드(30)는 또한 송수신기(34) 및 송신/수신 요소(36)와 같은 통신 회로를 포함할 수 있다. 노드(30)는 일 실시예에 부합하도록 유지되면서 전술한 요소들의 임의의 하위-조합을 포함할 수 있다는 것을 이해할 것이다. 이 노드는 본 명세서에서 기술되는 리소스 디렉토리 기능성을 구현시킨 노드일 수 있다.

프로세서(32)는 범용 프로세서, 특수 목적 프로세서, 종래의 프로세서, 디지털 신호 프로세서(DSP), 복수의 마이크로프로세서, DSP 코어와 연관되는 하나 이상의 마이크로프로세서, 제어기, 마이크로제어기, ASIC(Specific Integrated Circuit)들, FPGA(Field Programmable Gate Array) 회로들, 임의의 다른 유형의 집적 회로(IC), 상태 머신, 및 이와 유사한 것일 수 있다. 프로세서(32)는 신호 코딩, 데이터 처리, 전력 제어, 입출력 처리, 및/또는 노드(30)가 무선 환경에서 동작할 수 있게 하는 임의의 다른 기능성을 수행할 수 있다. 프로세서(32)는 송신/수신 요소(36)에 결합될 수 있는 송수신기(34)에 결합될 수 있다. 도 22c가 프로세서(32)와 송수신기(34)를 별도의 컴포넌트들로서 묘사하고 있지만, 프로세서(32)와 송수신기(34)는 전자 패키지 또는 칩 내에 함께 통합될 수 있다는 것을 이해할 것이다. 프로세서(32)는 애플리케이션-계층 프로그램(예를 들어, 브라우저)들 및/또는 RAN(radio access-layer) 프로그램들 및/또는 통신을 수행할 수 있다. 프로세서(32)는 예를 들어, 액세스-계층 및/또는 애플리케이션 계층 등에서의 인증, 보안 키 일치, 및/또는 암호화 연산들 등과 같은 보안 동작을 수행할 수 있다.

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

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

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

송수신기(34)는 송신/수신 요소(36)에 의해 송신될 신호들을 변조하고, 송신/수신 요소(36)에 의해 수신되는 신호들을 복조하도록 구성될 수 있다. 위에서 주지된 바와 같이, 노드(30)는 다중-모드 능력들을 가질 수 있다. 따라서, 송수신기(34)는 노드(30)가 예를 들어, UTRA 및 IEEE 802.11과 같은 여러 RAT들을 통해 통신 가능하도록 하는 여러 송수신기들을 포함할 수 있다.

프로세서(32)는 비이동식 메모리(44) 및/또는 이동식 메모리(46)와 같은 임의의 유형의 적절한 메모리로부터 정보에 액세스할 수 있고, 거기에 데이터를 저장할 수 있다. 비이동식 메모리(44)는 RAM(random-access memory), ROM(read-only memory), 하드 디스크, 또는 임의의 다른 유형의 메모리 저장 디바이스를 포함할 수 있다. 이동식 메모리(46)는 SIM(subscriber identity module) 카드, 메모리 스틱, SD(secure digital) 메모리 카드, 및 이와 유사한 것을 포함할 수 있다. 기타 실시예들에서, 프로세서(32)는 서버 또는 가정용 컴퓨터와 같은, 노드(30) 상에 물리적으로 위치되지 않는 메모리로부터 정보에 액세스할 수 있고, 거기에 데이터를 저장할 수 있다. 프로세서(32)는 UE(예를 들어, GUI(1400)를 참조)의 상태와, 특히 UE와 통신하는 기본 네트워크들, 애플리케이션들, 또는 다른 서비스들의 상태를 반영하기 위해 디스플레이 또는 표시기(42) 상에 조명 패턴들, 이미지들, 또는 컬러들을 제어하도록 구성될 수 있다. 프로세서(32)는 전원(48)으로부터 전력을 수신할 수 있고, 노드(30) 내의 다른 컴포넌트들에 전력을 분산시키고 및/또는 제어하도록 구성될 수 있다. 전원(48)은 노드(30)에 전력을 공급하기 위한 임의의 적절한 디바이스일 수 있다. 예를 들어, 전원(48)은 하나 이상의 드라이 셀 배터리(예를 들어, 니켈-카드뮴(NiCd), 니켈-아연(NiZn), 니켈 금속 수소화물(NiMH), 리튬-이온(Li-이온) 등), 태양광 전지들, 연료 전지들 등을 포함할 수 있다.

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

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

도 22d는 도 22a 및 도 22b에 예시된 것과 같은 M2M 네트워크에서 M2M 서버, 게이트웨이, 디바이스, 또는 다른 노드로서 동작할 수 있는 도 7 내지 도 21에 예시된 클라이언트들, 피어들, 및 리소스 디렉토리들과 같은 네트워크의 하나 이상의 노드를 구현하는데 이용될 수 있는 예시적인 컴퓨팅 시스템(90)의 블록도이다. 컴퓨팅 시스템(90)은 컴퓨터 또는 서버를 포함할 수 있고, 주로 컴퓨터 판독가능 명령어들에 의해 제어될 수 있으며, 이는 소프트웨어의 형태로 어느 곳이나 있을 수 있거나, 이러한 소프트웨어가 저장되거나 액세스되는 것이면 무엇이든 가능하다. 이러한 컴퓨터 판독가능 명령어들은 컴퓨팅 시스템(90)이 작업할 수 있도록 중앙 처리 유닛(CPU)(91) 내에서 실행될 수 있다. 많은 공지된 워크스테이션, 서버, 및 개인용 컴퓨터에서, 중앙 처리 유닛(91)은 마이크로프로세서로 불리는 단일-칩 CPU에 의해 구현된다. 다른 머신들에서, 중앙 처리 유닛(91)은 복수의 프로세서를 포함할 수 있다. 코프로세서(81)는 추가 기능을 수행하거나 CPU(91)를 보조하는, 메인 CPU(91)와는 별개인 옵션의 프로세서이다. CPU(91) 및/또는 코프로세서(81)는, 세션 크리덴셜(session credential)들에 기초한 인증 또는 세션 크리덴셜들의 수신과 같이, 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)은 도 22a 및 도 22b의 네트워크(12)와 같은 외부 통신 네트워크에 컴퓨팅 시스템(90)을 접속시켜서 컴퓨팅 시스템(90)이 네트워크의 다른 노드들과 통신할 수 있게 하기 위해 사용될 수 있는, 예를 들어, 네트워크 어댑터(97)와 같은 통신 회로를 포함할 수 있다. 통신 회로는, 단독으로 또는 CPU(91)와 결합하여, 본 명세서(예를 들어, 도 7 내지 도 21) 및 청구항에 기술된 송신 및 수신 단계들을 수행하는데 이용될 수 있다.

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

도면들에 예시된 바와 같이, 본 개시 내용의 주제의 양호한 실시예들을 설명함에 있어서, 특정 용어가 명료성을 위하여 채택된다. 그러나, 청구된 주제는 그와 같이 선정된 특정 용어로 한정되는 것으로 의도되지 않고, 각각의 특정 구성 요소가 유사한 목적을 달성하기 위해 유사한 방식으로 동작하는 모든 기술적 등가물을 포함하는 것으로 이해되어야 할 것이다.

다음의 것은 상술한 설명에서 출현할 수 있는 서비스 레벨 기술들에 관한 두문자어들의 리스트이다. 달리 정의되지 않는다면, 본 명세서에 사용되는 두문자어들은 아래 열거된 대응하는 용어를 지칭한다.

CoAP Constrained Application Protocol

CoRE Constrained RESTful Environment

DHT Distributed Hash Table

DRD Distributed Resource Directory

EP End Point

HTTP Hypertext Transfer Protocol

IETF Internet Engineering Task Force

IoT Internet of Things

M2M Machine to Machine

MAC Medium Access Control

RD Resource Directory

RE Reference Ensured Mechanism

SA Storage Assisted Mechanism

URI Uniform Resource Identifier

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

Claims (20)

1. 프로세서, 메모리, 및 통신 회로를 포함하는 노드로서,
   상기 노드는 상기 통신 회로를 통해 통신 네트워크에 접속되고, 상기 노드는 상기 노드의 상기 프로세서에 의해 실행될 때, 상기 노드가
   엔드포인트로부터 수신되는 메시지 페이로드와 연관되는 하나 이상의 키를 결정하고 - 상기 메시지 페이로드는 리소스와 연관되는 등록 요구를 포함함 -;
   상기 하나 이상의 키를 해시 함수에 적용하여 매핑 정보를 생성하고 - 상기 매핑 정보는 피어 리소스 디렉토리 서버의 적어도 하나의 아이덴티티를 포함함 -;
   상기 매핑 정보에 기초하여, 상기 메시지 페이로드를 하나 이상의 피어 리소스 디렉토리 서버에 송신하고;
   상기 하나 이상의 피어 리소스 디렉토리 서버로부터 적어도 하나의 응답을 수신하고 - 상기 적어도 하나의 응답은 상기 리소스가 저장되는 각각의 위치를 표시함 -;
   수신된 상기 적어도 하나의 응답에 기초하여, 결과로 생기는 응답을 상기 엔드포인트에 송신하게 하는,
   상기 노드의 상기 메모리에 저장되는 컴퓨터 실행가능 명령어들을 더 포함하고,
   상기 메시지 페이로드와 연관되는 상기 하나 이상의 키는 적어도 하나의 파라미터 및 상기 적어도 하나의 파라미터와 연관되는 적어도 하나의 값을 포함하는, 노드.
2. 삭제
3. 제1항에 있어서,
   상기 적어도 하나의 파라미터는 도메인, 엔드포인트, 그룹 명칭, 엔드포인트 유형, 리소스 유형, 리소스 수명, 또는 인터페이스를 표시하는 노드.
4. 제1항에 있어서,
   상기 적어도 하나의 파라미터는 복수의 파라미터이고, 상기 적어도 하나의 값은 복수의 값이고, 상기 해시 함수는 등록 요구시 상기 파라미터들과 상기 값들 각각에 적용되는 노드.
5. 제4항에 있어서,
   상기 메시지 페이로드가 송신되는 상기 하나 이상의 피어 리소스 디렉토리 서버는 상기 메시지 페이로드를 각각이 저장하는 복수의 피어 리소스 디렉토리 서버이고, 상기 컴퓨터 실행가능 명령어들은 또한 상기 노드가
   얼마나 많은 파라미터가 상기 메시지 페이로드에 있는지에 기초하여, 얼마나 많은 피어 리소스 디렉토리 서버가 상기 복수의 피어 리소스 디렉토리 서버에 있는지를 결정하게 하는 노드.
6. 제4항에 있어서,
   상기 메시지 페이로드가 송신되는 상기 하나 이상의 피어 리소스 디렉토리 서버는 상기 메시지 페이로드를 저장하는 선택된 하나의 피어 리소스 디렉토리 서버이고, 상기 컴퓨터 실행가능 명령어들은 또한 상기 노드가
   복수의 피어 리소스 디렉토리 서버에, 상기 선택된 하나의 피어 리소스 디렉토리에 대한 참조를 송신하여, 상기 복수의 피어 리소스 디렉토리가 상기 메시지 페이로드를 저장하는 상기 선택된 하나의 피어 리소스 디렉토리에 대한 참조를 저장하게 하는 노드.
7. 제1항에 있어서,
   상기 등록 요구는 상기 엔드포인트의 명칭 및 리소스 설명을 포함하는 노드.
8. 제1항에 있어서,
   상기 엔드포인트는 웹 서버, M2M(machine-to-machine) 디바이스, 또는 게이트웨이로서 동작하도록 구성되는 노드.
9. 프로세서, 메모리, 및 통신 회로를 포함하는 노드로서,
   상기 노드는 상기 통신 회로를 통해 통신 네트워크에 접속되고, 상기 노드는 상기 노드의 상기 프로세서에 의해 실행될 때, 상기 노드가
   엔드포인트로부터 수신되는 메시지 페이로드와 연관되는 하나 이상의 키를 결정하고 - 상기 메시지 페이로드는 리소스와 연관되는 리소스 검색 요구를 포함함 -;
   상기 하나 이상의 키를 해시 함수에 적용하여 매핑 정보를 생성하고 - 상기 매핑 정보는 피어 리소스 디렉토리 서버의 적어도 하나의 아이덴티티를 포함함 -;
   상기 매핑 정보에 기초하여, 상기 메시지 페이로드를 하나 이상의 피어 리소스 디렉토리 서버에 송신하고;
   상기 하나 이상의 피어 리소스 디렉토리 서버로부터 적어도 하나의 응답을 수신하고 - 상기 적어도 하나의 응답은 상기 하나 이상의 피어 리소스 디렉토리 서버 상에 저장되는 리소스의 콘텐츠를 표시함 -; 및
   수신된 상기 적어도 하나의 응답에 기초하여, 결과로 생기는 응답을 상기 엔드포인트에 송신하게 하는,
   상기 노드의 상기 메모리에 저장되는 컴퓨터 실행가능 명령어들을 더 포함하고,
   상기 메시지 페이로드와 연관되는 상기 하나 이상의 키는 하나 이상의 파라미터를 포함하는, 노드.
10. 삭제
11. 제9항에 있어서,
    상기 하나 이상의 파라미터는 도메인, 엔드포인트, 그룹 명칭, 엔드포인트 유형, 리소스 유형, 리소스 수명, 또는 인터페이스를 표시하는 노드.
12. 제9항에 있어서,
    상기 리소스 검색 요구는 검색 유형과 하나 이상의 파라미터를 포함하는 노드.
13. 제9항에 있어서,
    상기 하나 이상의 파라미터는 복수의 파라미터이고, 상기 컴퓨터 실행가능 명령어들은 또한 상기 노드가
    상기 파라미터들이 제1 논리 접속사를 이용하여 서로 접속되는 경우, 상기 메시지 페이로드를 복수의 피어 리소스 디렉토리 서버에 송신하고 - 상기 복수는 얼마나 많은 파라미터가 상기 메시지 페이로드에 있는지에 기초함 -;
    상기 파라미터들이 제2 논리 접속사를 이용하여 서로 접속되는 경우, 상기 메시지 페이로드를 하나의 피어 리소스 디렉토리 서버에만 송신하게 하는 노드.
14. 제9항에 있어서,
    상기 메시지 페이로드가 송신되는 상기 하나 이상의 피어 리소스 디렉토리 서버는 상기 리소스 검색 요구를 상기 매핑 정보에 의해 표시된 다른 피어 리소스 디렉토리 서버들에 전파하는 선택된 하나의 피어 리소스 디렉토리 서버인 노드.
15. 제9항에 있어서,
    상기 엔드포인트는 웹 서버, M2M(machine-to-machine) 디바이스, 또는 게이트웨이로서 동작하도록 구성되는 노드.
16. 방법으로서,
    리소스 디렉토리 서버에 의해, 엔드포인트로부터 수신되는 메시지 페이로드와 연관되는 하나 이상의 키를 결정하는 단계 - 상기 메시지 페이로드는 리소스와 연관되는 등록 요구 또는 리소스 검색 요구 중 적어도 하나를 포함함 -;
    상기 하나 이상의 키를 해시 함수에 적용하여 매핑 정보를 생성하는 단계 - 상기 매핑 정보는 피어 리소스 디렉토리 서버의 적어도 하나의 아이덴티티를 포함함 -;
    상기 매핑 정보에 기초하여, 상기 메시지 페이로드를 하나 이상의 피어 리소스 디렉토리 서버에 송신하는 단계;
    상기 리소스 디렉토리 서버에서, 하나 이상의 피어 리소스 디렉토리 서버로부터 적어도 하나의 응답을 수신하는 단계 - 상기 적어도 하나의 응답은 상기 리소스가 저장되는 각각의 위치 또는 상기 하나 이상의 피어 리소스 디렉토리 서버 상에 저장되는 리소스의 콘텐츠를 표시함 -; 및
    수신된 상기 적어도 하나의 응답에 기초하여, 결과로 생기는 응답을 상기 엔드포인트에 송신하는 단계
    를 포함하고,
    상기 메시지 페이로드와 연관되는 상기 하나 이상의 키는 적어도 하나의 파라미터 및 상기 적어도 하나의 파라미터와 연관되는 적어도 하나의 값을 포함하는, 방법.
17. 삭제
18. 제16항에 있어서,
    상기 적어도 하나의 파라미터는 도메인, 엔드포인트, 그룹 명칭, 엔드포인트 유형, 리소스 유형, 리소스 수명, 또는 인터페이스를 표시하는 방법.
19. 제16항에 있어서,
    상기 등록 요구는 상기 엔드포인트의 명칭 및 리소스 설명을 포함하는 방법.
20. 제16항에 있어서,
    상기 리소스 검색 요구는 검색 유형과 하나 이상의 파라미터를 포함하는 방법.

Images