KR101850802B1 - 향상된 발견을 위한 시스템들 및 방법들 - Google Patents

Abstract

본 명세서에는 향상된 서비스 발견을 제공하는 다양한 디바이스들, 방법들, 프로세스들 및 시스템들이 개시된다. 네트워크에서의 엔티티들은 서비스 발견에 대한 요청들을 리소스 디렉토리에 보낼 수 있고, 리소스 디렉토리는 요청된 발견 정보로 응답할 수 있다. 이러한 발견 정보는 요청 엔티티와 리소스 디렉토리 사이의 경로상에 배치되는 네트워크 노드에서 캐싱될 수 있다. 유사한 발견 요청 검출시, 네트워크 노드는, 캐싱된 발견 정보로 응답할 수 있거나, 캐싱된 발견 정보에 기초하여 다른 엔티티에 요청을 전달할 수 있거나, 또는 요청된 발견 정보를 가질 수 있는 다른 엔티티의 어드레스 또는 위치로 응답할 수 있다.

Description

향상된 발견을 위한 시스템들 및 방법들{SYSTEMS AND METHODS FOR ENHANCED DISCOVERY}

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

본 출원은 2013년 5월 16일자 "EMBODIMENTS TO PROVIDE ENHANCED DISCOVERY"라는 제목으로 출원된 미국 가특허 출원 61/823,988호의 이익을 주장하며, 그 내용들은 본 명세서에 참조로써 원용된다.

M2M(Machine-to-Machine) 기술들 및 인터넷과 같은, 현재의 네트워크 및 통신 기술들은, 디바이스들이 유선 및 무선 통신 시스템들을 사용하여 상호 더 직접적으로 통신하게 한다. M2M 기술들은 특히, IoT(Internet of Things), 고유하게 식별가능한 오브젝트들의 시스템, 및, 인터넷과 같은, 네트워크를 통해 상호 통신하는 이러한 오브젝트들의 가상 표현들의 추가 실현을 가능하게 한다. IoT는, 심지어, 식료품 상점에서의 제품들 또는 가정에서의 가전제품들과 같은, 일상적인 매일의 오브젝트들과의 통신을 촉진할 수 있고, 이에 의해 이러한 오브젝트들의 지식을 향상시키는 것에 의해 비용과 낭비를 절감할 수 있다. 예를 들어, 상점들은 재고에 있을 수 있거나 또는 판매되었을 수 있는 오브젝트들과 통신할 수 있거나, 또는 이들로부터 데이터를 얻을 수 있는 것에 의해 매우 정확한 재고 데이터를 유지할 수 있다. 통신가능하게 접속되는 엔티티들 및 오브젝트들의 다른 네트워크들 또한 유사한 기능성을 촉진할 수 있다.

접속되는 엔티티들의 IoT 또는 유사한 네트워크들을 포함하는, 거의 모든 통신 네트워크에서의 엔티티들 각각은, 이들이 작업들을 달성하고 기능들을 수행하기 위해 통신할 수 있도록, 네트워크에서의 다른 엔티티들을 발견하는 메커니즘을 필요로 한다. 현재의 발견 메커니즘들은 통상적으로 2가지 형태들을 취한다. 디렉토리 기반의 발견에서는, 네트워크에서의 엔티티들이 리소스들을 발견하도록 쿼리할 수 있는 디렉토리 서버 또는 다른 디렉토리 엔티티가 존재한다. (본 명세서에 사용되는 바와 같은 "리소스들"이란 네트워크에서 사용가능한 임의의 디바이스들, 서비스들, 엔티티들, 및 임의의 다른 기능, 능력, 또는 "사물"을 말한다.) 디렉토리 서버들은 네트워크에 대해 집중 배치되거나 또는 분산될 수 있다. 디렉토리가 없는 발견에서는, 개별 엔티티들이 네트워크, 또는 그 서브섹션 도처에 발견 요청들을 방송하거나 또는 멀티캐스트한다. 엔티티들을 제공하는 리소스는 엔티티에서 사용가능한 리소스들을 보고하는 것에 의해 이러한 요청에 응답한다. IETF(Internet Engineering Task Force) SLP(Service Location Protocol)를 사용하는 것들과 같은, 일부 구현들은, 디렉토리 기반의 및 디렉토리가 없는 발견 양자 모두를 지원할 수 있다.

현재의 구현들에서, 동일한 타입의 리소스에 대한 다수의 발견 요청들은, 네트워크에서의 엔티티들이 동일한 타입들의 리소스들을 사용하려고 시도하는 바와 같이 리소스를 제공하는 리소스 디렉토리 서버 또는 엔티티에 의해 처리될 수 있다. 유사하거나 또는 동일한 타입의 발견 요청들의 이러한 반복된 처리는, 이러한 엔티티들에게 상당한 오버헤드를 추가할 수 있고, 이러한 엔티티들이 제한된 처리, 통신, 전력, 및/또는 다른 능력들을 갖는 경우, 다른 작업들을 수행하는 엔티티의 능력에 영향을 줄 수 있다.

본 명세서에 개시되는 실시예들은, 접속되는 엔티티들의 네트워크에서의 네트워크 노드에서 제1 엔티티로부터 제1 발견 요청을 수신하고, 제1 발견 요청을 리소스 디렉토리 엔티티에 송신하고, 리소스 디렉토리 엔티티로부터 제1 발견 응답을 수신하고, 제1 발견 응답에 기초하여 네트워크 노드에서 제1 발견 응답 데이터를 저장하고, 제1 발견 응답을 제1 엔티티에 송신하는 방법들을 포함한다. 그리고 나서, 네트워크 노드가 제2 엔티티로부터 제2 발견 요청을 수신할 때, 이는 제2 발견 요청의 발견 요청 데이터가 제1 발견 응답 데이터에 대응한다고 결정할 수 있고, 이에 따라 제2 요청을 리소스 디렉토리에 전달하는 대신에 제1 발견 응답을 포함하는 제2 발견 응답을 제2 엔티티에 송신할 수 있다.

본 명세서에 개시되는 실시예들은, 접속되는 엔티티들의 네트워크에서의 네트워크 노드에서 제1 엔티티로부터 제1 발견 요청을 수신하고, 제1 발견 요청을 리소스 디렉토리 엔티티에 송신하고, 리소스 디렉토리 엔티티로부터 제1 발견 응답을 수신하고, 제1 발견 응답에 기초하여 네트워크 노드에서 제1 발견 응답 데이터를 저장하고, 제1 발견 응답을 제1 엔티티에 송신하는 명령어들을 실행하는 프로세서를 포함하는 네트워크 노드를 더 포함한다. 그리고 나서, 네트워크 노드가 제2 엔티티로부터 제2 발견 요청을 수신할 때, 이는 제2 발견 요청의 발견 요청 데이터가 제1 발견 응답 데이터에 대응한다고 결정할 수 있고, 이에 따라 제2 요청을 리소스 디렉토리에 전달하는 대신에 제1 발견 응답을 포함하는 제2 발견 응답을 제2 엔티티에 송신할 수 있다.

본 명세서에 개시되는 실시예들은, 접속되는 엔티티들의 네트워크에서의 네트워크 노드에서 제1 엔티티로부터 제1 발견 요청을 수신하고, 제1 발견 요청을 리소스 디렉토리 엔티티에 송신하고, 리소스 디렉토리 엔티티로부터 제1 발견 응답을 수신하고, 제1 발견 응답에 기초하여 네트워크 노드에서 제1 발견 응답 데이터를 저장하고, 제1 발견 응답을 제1 엔티티에 송신하는 명령어들을 실행하는 프로세서를 포함하는 네트워크 노드를 더 포함한다. 그리고 나서, 네트워크 노드가 제2 엔티티로부터 제2 발견 요청을 수신할 때, 이는 제2 발견 요청의 발견 요청 데이터가 제1 발견 응답 데이터에 대응한다고 결정할 수 있고, 이에 따라 제1 엔티티의 위치를 포함하는 제2 발견 응답을 제2 엔티티에 송신하거나, 또는 제2 요청을 제2 엔티티에 리다이렉트할 수 있다.

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

도 1은 향상된 리소스 발견의 실시예들이 구현될 수 있는 예시적인 시스템을 도시한다.
도 2는 향상된 리소스 발견의 실시예들을 구현하는 예시적인 처리를 보여주는 신호 흐름을 도시한다.
도 3은 향상된 리소스 발견의 실시예들이 구현될 수 있는 예시적인 시스템을 도시한다.
도 4는 향상된 리소스 발견의 실시예들에 사용될 수 있는 예시적인 메시지 포맷을 도시한다.
도 5는 향상된 리소스 발견의 실시예들을 구현하는 예시적인 처리를 보여주는 신호 흐름을 도시한다.
도 6은 향상된 리소스 발견의 실시예들이 구현될 수 있는 예시적인 시스템을 도시한다.
도 7은 향상된 리소스 발견의 실시예들에 사용될 수 있는 예시적인 메시지 포맷을 도시한다.
도 8은 향상된 리소스 발견의 실시예들을 구현하는 예시적인 처리를 보여주는 신호 흐름을 도시한다.
도 9는 향상된 리소스 발견의 실시예들이 구현될 수 있는 예시적인 시스템을 도시한다.
도 10은 향상된 리소스 발견의 실시예들을 구현하는 예시적인 처리를 보여주는 신호 흐름을 도시한다.
도 11은 향상된 리소스 발견의 실시예들이 구현될 수 있는 예시적인 시스템을 도시한다.
도 12는 향상된 리소스 발견의 실시예들을 구현하는 예시적인 처리를 보여주는 신호 흐름을 도시한다.
도 13은 향상된 리소스 발견의 실시예들이 구현될 수 있는 예시적인 시스템을 도시한다.
도 14는 향상된 리소스 발견의 실시예들을 구현하는 예시적인 처리를 보여주는 신호 흐름을 도시한다.
도 15는 향상된 리소스 발견의 실시예들에서 발견 데이터를 저장하는데 사용될 수 있는 예시적인 구조를 도시한다.
도 16은 향상된 리소스 발견의 실시예들을 구현하는 예시적인 방법을 도시한다.
도 17은 향상된 리소스 발견의 실시예들을 구현하는 예시적인 방법을 도시한다.
도 18은 향상된 리소스 발견의 실시예들을 구현하는 예시적인 방법을 도시한다.
도 19는 향상된 리소스 발견의 실시예들에 사용될 수 있는 예시적인 메시지 포맷을 도시한다.
도 20은 향상된 리소스 발견의 실시예들이 구현될 수 있는 예시적인 시스템을 도시한다.
도 21a는 하나 이상의 개시되는 실시예들이 구현될 수 있는 예시적인 M2M(Machine-to-Machine) 또는 IoT(Internet of Things) 통신 시스템의 시스템 도면이다.
도 21b는 도 12a에 도시되는 M2M/IoT 통신 시스템 내에 사용될 수 있는 예시적인 아키텍처의 시스템 도면이다.
도 21c는 도 12a에 도시되는 통신 시스템 내에 사용될 수 있는 예시적인 M2M/IoT 단말 또는 게이트웨이 디바이스의 시스템 도면이다.
도 21d는 도 12a의 통신 시스템의 양상들이 구현될 수 있는 예시적인 컴퓨팅 시스템의 블럭도이다.

본 명세서에 기재되는 실시예들은 REST(Representational State Transfer) 아키텍처의 관점에서 설명될 수 있고, 설명되는 컴포넌트들 및 엔티티들은 REST 아키텍처(RESTful 아키텍처)의 제약들에 따른다. RESTful 아키텍처는 사용되는 물리적 컴포넌트 구현 또는 통신 프로토콜들의 관점에서보다는 오히려 아키텍처에 사용되는 컴포넌트들, 엔티티들, 커넥터들, 및 데이터 엘리먼트들에 적용되는 제약들의 관점에서 설명된다. 따라서, 이러한 컴포넌트들, 엔티티들, 커넥터들, 및 데이터 엘리먼트들의 역할들 및 기능들은, 고유하게 어드레싱 가능한 리소스들의 표현들이 엔티티들 사이에 전달될 수 있는, RESTful 아키텍처를 사용하여 설명될 수 있다. 그러나, 본 명세서에 기재되는 바와 같은 다른 환경에서 구현될 수 있는 많은 다른 실시예들이 고려된다. 예를 들어, 즉각적인 개시내용의 실시예들은, SOA(Service Oriented Architecture), 또는 리소스들의 발견을 허용하는 임의의 다른 아키텍처나 또는 관념의 관점에서 정의되거나 또는 설명되는 아키텍처들에 구현될 수 있다.

통상의 기술자는 즉각적인 실시예들의 구현들이 본 개시내용의 범위 내에 남아 있으면서 변경될 수 있다는 점을 인식할 것이다. 통상의 기술자는, 개시되는 예시적인 실시예들이, ETSI(European Telecommunications Standards Institute) M2M 아키텍처를 참조하여 본 명세서에 가끔 설명되지만, ETSI M2M 아키텍처를 사용하는 구현들에 제한되는 것은 아니라는 점을 또한 인식할 것이다. 개시되는 실시예들은, oneM2M 및 다른 M2M 시스템들 및 아키텍처들과 같은, 접속된 엔티티들을 갖는 다른 아키텍처들 및 시스템들에 구현될 수 있다. 개시되는 실시예들은, 컴퓨터 네트워크들 및 하나 이상의 컴퓨터 네트워크들을 갖는 시스템들에 보다 일반적으로 또한 적용될 수 있다. 예를 들어, 개시되는 실시예들은, 인터넷 상의 또는 상호접속되는 디바이스들을 포함하는 임의의 네트워크에서의 라우터, 허브, 게이트웨이, 스위치, 또는 서버에서 구현될 수 있다. 모든 이러한 실시예들은 본 개시내용의 범위 내의 것으로서 고려된다.

현재의 리소스 발견 메커니즘들에 존재하는 쟁점들에 대처하기 위해서, 즉각적인 개시내용은 통신가능하게 접속되는 엔티티들의 임의의 네트워크 또는 수집에 사용될 수 있는 여러 실시예들을 설명할 것이다. 다수의 개시되는 실시예들에서, 발견 요청기와 리소스 디렉토리 또는 리소스 제공 엔티티 사이의 경로를 따라 중간 노드들에 있는 인네트워크 스토리지(innetwork storage)가 사용될 수 있다. 예를 들어, 본 명세서에 보다 상세히 설명되는 바와 같이, 보다 효율적인 리소스 발견은, 발견 요청들을 리소스 디렉토리나 또는 리소스 제공 엔티티에 전달하는 대신에 발견 요청들에 응답할 수 있는 중간 노드들에서 캐싱(caching)하는 발견 결과들을 사용하여 구현될 수 있다. 다른 실시예들에서는, 리소스 디렉토리 또는 리소스 제공 엔티티에 근접한 노드들에게 캐싱된 발견 결과들을 알려주는데 중간 노드들에 의한 발견 결과들의 방송이 사용될 수 있다. 또 다른 실시예들에서는, 리소스 디렉토리, 리소스 제공 엔티티, 및/또는 중간 노드들이 요청기의 표시를 포함하는 발견 요청들의 기록들을 유지할 수 있다. 동일하거나 또는 유사한 발견 요청이 노드, 디렉토리, 또는 엔티티에 의해 나중에 수신될 때, 이전 요청기가 요청된 발견 결과를 가질 수 있다는 것을 요청기에게 통지하거나, 또는 요청을 이전 요청기에 전달할 수 있다.

다른 실시예들은 캐싱된 발견 결과들의 업데이트 수정을 허용한다. 예를 들어, 캐싱된 발견 결과가 무효로 또는 불완전하게 되는, 일 실시예에서, 캐싱 디렉토리, 엔티티, 또는 노드는, 캐싱된 발견 결과를 네트워크에서의 정보의 공개 및 비공개에 기초하여 수정하여 캐싱된 발견 결과의 유틸리티를 연장할 수 있다. 중간 노드는, 다수의 리소스 디렉토리들 또는 리소스 제공 엔티티들로부터 발견 결과들을 또한 수신할 수 있고, 리소스 검색 및 전달을 위해 다수의 리소스 제공기들간 로드 밸런싱(load-balancing)을 제공하도록 이러한 결과들을 조합할 수 있다. 대안적으로, 중간 노드는, 전체 발견 결과를 저장하지 않을 수 있고, 이 중 일부를 캐싱하기만 할 수 있다. 이러한 메커니즘들을 가능하게 하는 예시적인 메시지들 및 프로시저들이 본 개시내용에 정의된다. 즉각적인 개시내용에서, 본 개시내용에 설명되는 예시적인 실시예들을 도시하는 일부 예들에 SLP가 사용될 수 있지만, 개시되는 실시예들을 구현하는 다른 프로토콜들 및 메커니즘들이 본 개시내용의 범위 내의 것으로서 고려된다.

즉각적인 개시내용 전반적으로, 다양한 실시예들의 도시에 사용되는 예시적인 리소스는 감시 비디오 콘텐츠의 제공기일 것이라는 점에 주목하자. 이는 많은 실시예들 중 단지 하나이며 본 명세서 예시적인 목적으로만 사용된다. 개시되는 실시예들은 임의의 리소스, 서비스, 엔티티, 디바이스 등에 적용가능할 수 있고, 이러한 예의 사용에 의해 임의의 실시예에 대한 제한이 의도되는 것은 아니다.

도 1은 본 명세서에 개시되는 실시예들을 지원할 수 있는 예시적인 아키텍처(100)를 도시한다. 도 1에 관하여 설명되는 다양한 엔티티들은 예시적인 목적으로만 사용되며, 다른 아키텍처들 및 구성들이 고려된다는 점에 주목하자. 설명되는 다양한 엔티티들은, 임의 수 및 조합의 디바이스들 및 소프트웨어를 사용하여 구현될 수 있고, 임의의 네트워크, 네트워크의 부분 등에 배치될 수 있으며, 본 명세서에 설명되는 또는 그렇지 않은, 임의의 다른 엔티티들과 상호접속 및/또는 통신할 수 있다. 모든 이러한 실시예들은 본 개시내용의 범위 내의 것으로서 고려된다.

발견 요청은, 엔티티들(111-113) 중 하나와 같은, 예를 들어, 엣지 네트워크 또는 RAN(Radio Access Network)(110)에서의 엔티티에 의해 송신될 수 있다. 이러한 발견 요청은 리소스 디렉토리(130)에 어드레싱되거나 또는 다른 방식으로 보내진다. 발견 요청은, 코어 네트워크(120)에서의 게이트웨이(121)에서 먼저 수신될 수 있고, 그리고 나서, 리소스 디렉토리(130)로의 요청의 전달을 촉진하는, 노드들(122-129)의 임의의 조합과 같은, 하나 이상의 중간 노드들을 횡단한다. 리소스 디렉토리(130)는 그리고 나서 요청 엔티티에 보내지는 발견 결과에 의해 응답할 수 있다. 노드들(122-129)의 임의의 조합과 게이트웨이(121)에 의해 요청 엔티티에 발견 결과가 전달되는 동안, 이러한 노드들 중 임의의 것 및/또는 게이트웨이(121)가 발견 결과, 또는 그 일부 부분을 캐싱할 수 있다. 아키텍처(100)에서 각각의 노드 및 게이트웨이는, 각각의 노드 또는 게이트웨이가 결정하도록 구성될 수 있는 임의의 기준들에 기초하여 또는 이러한 노드들 및 게이트웨이의 구성에 기초하여, 발견 결과를 캐싱할지를 독립적으로 및 개별적으로 결정할 수 있다. 발견 결과를 캐싱하였던 노드들(122-129) 중 하나 또는 게이트웨이(121)에 의해 동일하거나 또는 유사한 발견 요청이 수신될 때, 이러한 엔티티들은, 요청을 리소스 디렉토리(130)에 전달하지 않고, 캐싱된 데이터에 의해 스스로 요청에 응답할 수 있다. 이는, 리소스 디렉토리(130)가 동일하거나 또는 유사한 발견 요청들을 여러번 취급하는 것을 방지하는 것에 의해 리소스 디렉토리(130) 상의 로드를 효과적으로 감소시키고, 그 경로의 링크들 도처에서 반복적 리소스 발견 결과들 및 응답들을 제거하는 것에 의해 리소스 디렉토리(130)로의 경로 상의 네트워크 대역폭을 또한 절약한다. 이러한 발견 요청에 응답되는 중간 노드들은, 발견 요청을 리소스 디렉토리(130)에게 통지하는 통지를 리소스 디렉토리(130)에 보낼 수 있거나, 또는 다수의 발견 요청들에 대해 조합된 통지를 응답하였던 것에 보낼 수 있다. 이는 해당 리소스가 발견되었던 횟수에 기초하여 리소스 디렉토리(130)가 리소스의 인기를 결정하게 할 수 있다.

일 실시예에서, 발견 요청은 상이한 타입들의 리소스 발견을 나타내는 하나 이상의 식별자들을 포함하는 구조일 수 있는 발견 키 필드(discovery key field)를 포함할 수 있다. 본 명세서에 보다 상세히 논의되는 바와 같이, 여러가지 가능한 식별자들은 발견 타입, 범위(scope), 술부(predicate), 및/또는 타입과 범위의 조합을 나타낼 수 있다. 일 실시예에서, 발견 키 필드의 콘텐츠는 발견 응답에서 요청기에게 에코 백될 수 있다(echoed back). 발견 키 필드는, 리소스 디렉토리(130)와 같은, 리소스 디렉토리에 의해 인식될 수 있는 임의의 데이터 또는 인디케이터들을 포함할 수 있다. 예를 들어, 데이터 콘텐츠가 애플리케이션에 의해 제공되는 경우, 요청기가 관심이 있는 데이터, 요청된 데이터의 타입, 및/또는 요청된 데이터가 수집 및/또는 저장되는 위치와 관련되는 키 워드들이 필드에 있을 수 있다. 예를 들어, 요청기가 M2M 및/또는 IoT 리소스로부터의 감시 비디오 콘텐츠에 관심이 있다는 것을 요청이 나타낼 수 있다. 발견 키 필드는 또한, 또는 그 대신에, 예를 들어, 호스팅 위치와 조합되는 콘텐츠의 식별자를 포함하는 것에 의해, 요청된 콘텐츠의 캐싱 위치(들)를 나타내는 하나 이상의 식별자들을 포함할 수 있다. 발견 키 필드는 또한, 또는 그 대신에, 서비스 프로바이더를 나타내는 하나 이상의 식별자들을 포함할 수 있고, 일부 실시예들에서는, 서비스의 호스팅 위치와 조합되는 서비스의 식별자를 포함할 수 있다. 발견 키 필드는 또한, 또는 그 대신에, 서비스의 타입 및 요청기의 관심의 위치(요청기의 위치일 수 있음)를 나타내는 하나 이상의 식별자들을 포함할 수 있어, 요청기에 가장 근접한 서비스 프로바이더들의 결정을 가능하게 한다.

도 2는 리소스 발견에 대한 예시적인 신호들 및 프로시저들을 도시하는 예시적이지만 비제한적인 신호 흐름(200)을 도시한다. 211에서, 엔티티(210)는 리소스 디렉토리(260)에 어드레싱되고 게이트웨이(240)에서 수신될 수 있는 발견 요청을 보낼 수 있다. 발견 요청(211)은, 예를 들어 발견 키 필드에, 요청된 서비스와 관련되는 데이터를 포함할 수 있다. 예를 들어, 발견 요청(211)은 요청된 콘텐츠를 요청하는 엔티티의 위치(대부분의 실시예들에서, 지리학적 위치보다는 오히려, 어드레스 또는 액세스의 수단과 같은, 논리적 위치; 그러나 지리학적 위치 실시예들 또한 고려됨) 및/또는 요청된 콘텐츠의 식별자를 나타낼 수 있다. 일 예에서, 발견 요청(211)은 요청기가 감시 비디오 콘텐츠 리소스를 발견하길 원한다는 것을 나타낼 수 있다.

게이트웨이(240)는, 발견 요청(211)의 수신시, 요청된 리소스에 대한 로컬하게 캐싱된 리소스 정보를 갖고 있지 않은지를 결정할 수 있고, 이에 응답하여, 발견 요청(212)을 생성하여, 발견 요청(213)으로서의 요청을 리소스 디렉토리(260)에 중계할 수 있는, 중간 노드(250)에 보낼 수 있다. 리소스 디렉토리(260)는 발견 응답(218)으로서 엔티티(210)에 또한 다시 중계되는 발견 응답(216)으로서 응답을 중계하는 중간 노드(250)에 보내어지는 발견 응답(214)에 의해 응답할 수 있다. 일 예에서, 발견 응답(214)은 감시 비디오 콘텐츠 리소스의 어드레스 또는 위치를 나타낼 수 있다.

발견 응답(214)의 수신시, 블럭 215에서, 중간 노드(250)는 유사한 발견 요청들에 응답시 나중의 사용을 위해, 발견 응답(214), 또는 그 일부 부분을 캐싱할 것을 결정할 수 있다. 유사하게, 게이트웨이(240) 또한, 발견 응답(216)의 수신시, 유사한 발견 요청들에 응답시 나중의 사용을 위해, 발견 응답(214), 또는 그 일부 부분을 캐싱할 것을 결정할 수 있다.

219에서, 엔티티(220)는 발견 요청(211)과 동일하거나 또는 유사한 발견 요청을 보낼 수 있다. 예를 들어, 발견 요청(219)은 발견 요청(211)과 동일한 콘텐츠 위치 식별자를 포함할 수 있다. 대안적으로, 또는 추가로, 이러한 요청은, 일 예에서, 엔티티(220)가 요청(211)에 표시되는 엔티티(210)와 동일한 감시 비디오 콘텐츠 리소스에 관심이 있다는 것을 나타낼 수 있다. 엔티티(220)는 또한 발견 요청(211)을 보낸 엔티티(210)와 동일한 게이트웨이, 게이트웨이(240)를 사용할 수 있다. 그러나, 게이트웨이(240)는 엔티티(210)의 발견 요청(211)에 대한 발견 응답을 캐싱하였기 때문에, 블럭 221에서, 게이트웨이(240)는, 발견 요청(219)을 수신하는 것에 응답하여, 엔티티(220)에 보내어지는 발견 응답(222)을 생성할 수 있다. 이는 네트워크를 통해 리소스 디렉토리(260)에 발견 요청을 전달할 필요성을 제거하고, 이에 따라, 중간 노드(250) 및 리소스 디렉토리(260)와 같은, 이러한 요청을 처리하는데 그렇지 않으면 연관될 엘리먼트들 상의 일부 오버헤드 및 부담을 제거한다. 일 예에서, 발견 응답(222)은, 게이트웨이(240)가 응답(214)에서 감시 비디오 콘텐츠 리소스의 어드레스 또는 위치 수신시 캐싱하였던 감시 비디오 콘텐츠 리소스의 어드레스 또는 위치를 나타낼 수 있다. 감시 비디오 콘텐츠 리소스 어드레스 또는 위치에 대한 요청들, 및 이러한 요청들에 대한 응답들의 발견, 뿐만 아니라, 임의의 다른 리소스 또는 서비스에 대한 요청들, 및 이러한 요청들에 대한 응답들의 발견이 개시되는 실시예들 중 임의의 것에 사용될 수 있다는 점에 주목하자. 모든 이러한 실시예들은 본 개시내용의 범위 내의 것으로서 고려된다.

223에서, 엔티티(230)는 발견 요청(211)과 동일하거나 또는 유사한 발견 요청을 보낼 수 있다. 예를 들어, 발견 요청(223)은 발견 요청(211)과 동일한 콘텐츠 위치 식별자를 포함할 수 있다. 엔티티(230)는 발견 요청(211)을 보낸 엔티티(210)와 동일한 게이트웨이, 게이트웨이(240)를 사용하지 않을 수 있다. 따라서, 발견 요청(223)은 게이트웨이(240)를 바이패스할 수 있다. 그러나, 엔티티(230)로부터 리소스 디렉토리(260)까지의 경로는 엔티티(210)의 발견 요청(211)에 대한 발견 응답을 캐싱하였던 중간 노드(250)를 횡단할 수 있다. 따라서, 블럭 224에서, 중간 노드(250)는 발견 요청(223)을 수신하는 것에 응답하여 엔티티(230)에 보내어지는 발견 응답(225)을 생성할 수 있다. 이는 네트워크를 통해 리소스 디렉토리(260)에 발견 요청을 전달할 필요성을 제거하고, 이에 따라, 다른 중간 노드들 및 리소스 디렉토리(260)와 같은, 이러한 요청을 처리하는데 그렇지 않으면 연관될 엘리먼트들 상의 일부 오버헤드 및 부담을 제거한다.

일 실시예에서, 중간 노드는, 발견 결과를 캐싱하고, 그 결과 및/또는 관련된 정보를 자신의 네트워크 또는 자신의 네트워크의 서브섹션에 있는 엔티티들에 방송할 수 있다. 이러한 정보 방송은 본 명세서에 설명되는 바와 같은 발견 키 필드에 방송에 의해 광고되고 있는 리소스의 특성들을 표시하는 데이터를 포함할 수 있다. 방송 오버헤드를 낮게 유지하기 위해서, 중간 노드는, 그를 통해 방송이 송신될 수 있는 인터페이스를 선택할 수 있고, 방송이 보내어질 수 있는 홉들(hops)의 수를 특정하는 것에 의해 방송 반경을 제한할 수 있다.

도 3은 이러한 실시예들을 지원할 수 있는 예시적인 아키텍처(300)를 도시한다. 본 예에서, 중간 노드(327)는, 캐싱된 발견 응답을 가질 수 있고, 인터페이스들을 통해 관련된 발견 정보를 중간 노드들(329, 326 및 324)에 방송할 수 있지만, 인터페이스를 통해 이러한 정보를 중간 노드(328)에 방송하지 않을 수 있다. 중간 노드(327)는, 중간 노드들(329, 326 및 324)이 이러한 정보를 그들의 이웃들에게 더 이상 전달하지 않도록, 이러한 정보가 보내어질 수 있는 홉들의 수를, 예를 들어, 1개의 홉으로 제한할 수 있다. 따라서, 본 예에서, 중간 노드들(327, 329, 326 및 324) 중 임의의 것을 횡단하는 임의의 발견 요청은 해당 노드에서 캐싱된 정보를 사용하여 어드레싱될 수 있다. 예를 들어, 엣지 네트워크(310)에서의 엔티티들(311-313), 또는 코어 네트워크(320)에 진입하는 엔티티들(340, 350 및 360) 중, 중간 노드들(327, 329, 326 및 324) 중 임의의 것에 저장된 캐싱된 발견 응답의 발견 키 필드 데이터와 일치하는 임의의 것으로부터의 임의의 발견 요청은 캐싱된 정보와 함께 그 노드에 의해 어드레싱될 수 있다. 나머지 노드들(321, 322, 323 및 325)은, 그들이 보통 그러하듯이 이러한 트래픽을 단지 중계할 수 있지만, 이러한 응답들이 캐싱된 발견 응답 데이터를 사용하는 노드에서 유래되더라도 검출되는 응답들을 또한 캐싱할 수 있다. 대안적으로, 본 명세서에 보다 상세히 설명되듯이, 개시되는 실시예들을 사용하여 이러한 노드들은 요청을 어드레싱하기 위해 캐싱된 발견 응답 또는 관련된 정보를 갖는 노드들에 요청들을 보낼 수 있다.

일 실시예에서, 방송 발견 응답은 도 4의 예시적이지만 비제한적인 방송 메시지(400)로서 보내어질 수 있다. 메시지(400)에서 필드 broadcastID 필드(410)는 방송 메시지의 식별자일 수 있다. BroadcastID(410)는, 방송 메시지(400)를 유래시킨 엔티티의, IP(Internet Protocol) 어드레스와 같은, 식별자를 포함할 수 있다. 메시지(400)는, 캐싱된 발견 응답으로부터 추출될 수 있고, 본 명세서에 개시되는 바와 같은 발견 키 필드 데이터를 포함할 수 있는, discoveryKey 필드(420)를 또한 포함할 수 있다. 메시지(400)는, 메시지 및/또는 그 안에 포함된 정보의 상태를 나타낼 수 있는 상태 필드(430)를 또한 포함할 수 있다. 예를 들어, 상태(430)는 메시지(400)가 이웃 노드들에게 새롭게 캐싱된 발견 결과를 통지하는 방송 메시지라는 것을 나타낼 수 있거나, 또는 이는 메시지(400)가 이전에 제공된 발견 결과를 삭제하려는 의도의 방송 메시지라는 것을 나타낼 수 있다. 메시지(400)는, 캐싱된 발견 응답이 얼마나 오래 유효한 것으로 고려되는지를 나타낼 수 있는 수명 필드(440)를 또한 포함할 수 있다. 이러한 수명은 발견 정보를 방송하는 노드에 의해 추정될 수 있다. 수명은, 캐싱된 발견 응답이 만료되는 시간의 양(예를 들어, 시간, 날짜 등) 또는 특정 시간(예를 들어, 특정 날짜의 오후)을 포함하는, 임의의 형태로 제공될 수 있다. 메시지(400)는, 방송 메시지가 전파될 홉들의 수를 지정할 수 있고, 이에 따라 캐싱된 발견 응답 또는 관련된 정보의 송신 반경을 제한하는 수단을 제공하는 홉 필드(450)를 더 포함할 수 있다.

도 5는 발견 응답 또는 관련된 정보를 방송하는 예시적인 신호들 및 프로시저들을 도시하는 예시적이지만 비제한적인 신호 흐름(500)을 도시한다. 블럭 511에서, 중간 노드(540)는 리소스 디렉토리(590)에서 생성되는 발견 결과를 캐싱할 수 있다. 마찬가지로, 512에서, 게이트웨이(530) 또한 리소스 디렉토리(590)에서 생성되는 동일한 발견 결과를 캐싱할 수 있다. 게이트웨이(530)는 발견 결과 또는 관련된 정보를, 일 실시예에서, 도 4의 메시지 포맷을 사용하여 방송할 수 있다. 메시지의 홉 필드는 단일 홉을 나타낼 수 있고, 따라서, 단 하나의 다른 중간 노드, 중간 노드(550)에 직접 접속될 수 있는, 게이트웨이(530)는, 발견 결과 정보와 함께 메시지를 514에서 중간 노드(550)에 방송할 수 있다. 중간 노드(540)는, 중간 노드들(560, 570 및 580)에 직접 접속될 수 있고, 따라서 발견 결과 또는 관련된 정보를 513에서 도 4의 메시지 포맷을 사용하여 이러한 노드들 각각에 방송할 수 있다. 따라서, 중간 노드(550)는, 발견 결과 정보를 가질 수 있고, 게이트웨이(530)는 이러한 정보를 갖는다는 것을 알 수 있는 한편, 중간 노드들(560, 570 및 580) 각각은, 발견 결과 정보를 가질 수 있고, 중간 노드(540)가 이러한 정보를 갖는다는 것을 알 수 있다.

515에서, 엔티티(510)는 중간 노드(540) 및 게이트웨이(530)에 저장된 캐싱된 발견 결과 정보에 대응하는(즉, 이와 동일한 발견 키 필드 정보를 갖는) 발견 요청을 보낼 수 있다. 발견 요청(515)이 중간 노드(550)에 도달할 때, 일 실시예에서, 중간 노드(550)는 자신의 캐싱된 발견 정보를 사용하여 응답할 수 있는 한편, 다른 실시예에서, 중간 노드(550)는 이러한 요청을, 게이트웨이(530)가 캐싱된 발견 결과 정보를 갖는다는, 방송(514)을 수신하는 것에 의해 결정되는, 지식에 기초하여, 516에서 게이트웨이(530)에 전달할 수 있다. 게이트웨이(530)는, 517에서, 캐싱된 정보를 사용하여 발견 응답을 생성할 수 있고, 518에서 이를 요청 엔티티(510)에 보낼 수 있다.

중간 노드(540) 및 게이트웨이(530)에 저장된 캐싱된 발견 결과 정보에 대응하는(즉, 이와 동일한 발견 키 필드 정보를 갖는) 유사한 발견 요청이 엔티티(520)에 의해 송신될 수 있다. 이러한 요청이 중간 노드(560)에 도달할 때, 이 노드는, 이러한 요청을, 중간 노드(540)가 캐싱된 발견 결과 정보를 갖는다는, 방송(513)을 수신하는 것에 의해 결정되는, 지식에 기초하여, 521에서 중간 노드(540)에 전달할 수 있다. 중간 노드(540)는, 522에서, 캐싱된 정보를 사용하여 발견 응답을 생성할 수 있고, 522에서 이를 요청 엔티티(520)에 보낼 수 있다.

발견 요청이 중간 노드 또는 리소스 디렉토리에 의해 전달되거나 또는 응답될 때, 요청 및/또는 응답은 다른 중간 노드 또는 리소스 디렉토리에 의해 기록될 수 있다. 기록된 발견 요청은, 요청이 응답된 후 가까운 시간내에 요청기가 발견 응답을 가질 것이라는 표시로서의 역할을 할 수 있다. 초기 응답을 기록하였던 노드 또는 리소스 디렉토리에 또는 이에 의해 차후 동일하거나 또는 유사한 발견 요청이 전달되거나 수신되면, 이는 초기 요청을 보냈던 이전 요청기가 발견 결과를 가질 것이라는 것을 요청기에게 통지할 수 있다. 대안적으로, 초기 응답을 기록하였던 노드 또는 리소스 디렉토리는 이러한 요청을 이전 요청기에 전달할 수 있다. 이러한 실시예들에서, 이러한 노드들에서 캐싱된 정보를 초래할 수 있는 요청들을 수신하였던 노드들을 추적하기 위해, 중간 노드 및/또는 리소스 디렉토리는 본 명세서에 설명되는 바와 같이 이러한 정보를 캡처하는 기록들을 유지할 수 있다.

도 6은 이러한 실시예들을 지원할 수 있는 예시적인 아키텍처(600)를 도시한다. 엣지 네트워크(610)의 엔티티(611)는 리소스 디렉토리(630)에 발견 요청을 보낼 수 있다. 리소스 디렉토리(630)는 이러한 요청의 기록을 유지할 수 있다. 이러한 기록들의 유지, 및 미래의 유사한 요청들을 처리할지 또는 이러한 요청들을 이전 요청기에 보낼지를 결정하는데 필요한 처리는, 이러한 기록들을 리소스 디렉토리 또는 다른 엔티티의 적지않은 양의 리소스들을 소비할 수 있다는 점에 주목하자. 따라서, 일 실시예에서는, 리소스 디렉토리로의 경로를 따르는 일부 위치에 구성될 수 있는 프록시 노드가 사용될 수 있다. 이러한 프록시는, 이러한 기록들을 유지할 수 있고, 요청이 리소스 디렉토리에 의해 취급될 것인지 또는 발견 정보의 캐싱된 사본을 사용하여 응답하는 이전 요청기로 우회될 것인지를 결정할 수 있다. 예를 들어, 노드(629)는 리소스 디렉토리(630) 바로 앞에 있으므로 프록시 노드로서 역할을 할 수 있다. 대안적으로, 노드들(623, 625, 626, 628), 또는 및/또는 게이트웨이(321) 중 하나와 같은, 코어 네트워크(620)의 네트워크 엣지에 더 가까운 노드들이, 프록시 노드로서 역할을 할 수 있다. 대안적으로, 프록시 노드는 리소스 디렉토리(630)에 대해 프록시로서 기능만을 하는 전용 디바이스 또는 엔티티일 수 있다. 모든 이러한 실시예들이 본 개시내용의 범위 내의 것으로서 고려된다.

엔티티(611)가 자신의 발견 요청을 보낸 후, 엔티티(612)가 엔티티(611)에 의해 보내어진 요청과 동일한 발견 키 필드 정보를 갖는 후속 발견 요청을 보낼 수 있다. 이러한 요청의 수신시, 리소스 디렉토리(630)는 이러한 요청을 처리하여 그 결과를 자신이 보내는 것 대신에 엔티티(611)가 발견 결과를 갖고 있다는 것을 엔티티(612)에게 알릴 수 있다. 따라서, 엔티티(612)는 엔티티(611)로부터 그 결과를 검색할 수 있고, 리소스 디렉토리(630)가 그 결과를 다시 결정하거나 또는 이러한 정보를 스토리지로부터 꺼내기 위해 추가적 리소스들을 사용하는 것을 피한다.

일 실시예에서, 엔티티(611)가 요청된 발견 정보를 갖는다는 것을 엔티티(612)에 알리는 리소스 디렉토리(630)에 의해 보내어진 메시지는 도 7에서의 메시지(700)로 도시된 포맷으로 보내어질 수 있다. DiscoveryKey 필드(720)는, 양자 모두의 요청들에서와 동일한 발견 키 필드 데이터를 가질 수 있고, 이전에 요청되었던 것과 동일한 발견 키 필드 데이터라는 것을 요청기에 확인해주는 역할을 할 수 있다. Location 필드(730)는, 기록된 발견 요청들에 기초하여 결정되는 것으로서, 발견 결과를 가질 수 있는 엔티티들의 하나 이상의 잠재적 위치들의 표시를 제공할 수 있다. NotificationID(710)는, 본 예에서는 리소스 디렉토리(630)인, 메시지(700)를 유래시킨 엔티티의, IP 어드레스와 같은, 식별자를 포함할 수 있는 메시지(700)의 식별자일 수 있다.

도 8은 요청된 발견 정보를 가질 수 있는 다른 엔티티에 요청기를 리다이렉트하는 예시적인 신호들 및 프로시저들을 도시하는 예시적이지만 비제한적인 신호 흐름(800)을 도시한다. 811에서, 엔티티(810)는 리소스 디렉토리(840)에 발견 요청을 송신할 수 있다. 그러나, 이러한 요청은, 네트워크에서의 임의의 엔티티 또는 디바이스일 수 있는, 리소스 디렉토리 프록시(830)에 의해 인터셉트될 수 있다. 812에서, 리소스 디렉토리 프록시(830)에 의해, 이러한 요청은, 예를 들어, 동일한 발견 키 필드 데이터를 갖는 이전 요청의 기록을 갖고 있지 않다는 것에 기초하여, 리소스 디렉토리(840)에 중계되어야 한다고 결정할 수 있다. 이러한 요청은 그리고 나서 813에서 리소스 디렉토리(840)에 중계되고, 815에서, 엔티티(810)에 응답이 보내어지는 기록을 행하는, 리소스 디렉토리 프록시(830)에 발견 응답(814)이 송신된다. 816에서, 발견 응답은 엔티티(810)에 제공된다.

후속하여, 엔티티(820)는 요청(811)과 동일한 발견 키 필드 데이터를 갖는 요청(817)을 송신할 수 있다. 요청(817)은, 리소스 디렉토리 프록시(830)에 의해 또한 인터셉트될 수 있으며, 이는, 예를 들어, 동일한 발견 키 필드 데이터를 갖는 이전 요청(811) 또는 응답(814)의 기록을 갖는 것에 기초하여, 리소스 디렉토리(840) 보다는 오히려 엔티티(810)에 요청하는 것에 의해 이러한 요청이 취급될 수 있다는 것을 블럭 818에서 결정할 수 있다. 리소스 디렉토리 프록시(830)는 그리고 나서 엔티티(820)에 암시적 발견 결과 통지(819)를 보낼 수 있고, 엔티티(820)는 메시지(819)에서의 이러한 정보를 사용하여 엔티티(810)가 요청을 처리할 것이라는 점을 결정할 수 있다. 엔티티(820)는, 그리고 나서 발견 결과를 검색하는 요청(821)을 송신할 수 있고, 822에서 결과를 수신할 수 있다.

대안적으로, 요청된 발견 결과들을 갖는 다른 엔티티들에 요청기들을 리다이렉트하는 것보다는 오히려, 일부 실시예들에서, 요청들 자체가 이러한 엔티티들에 리다이렉트될 수 있다. 도 9는 이러한 실시예들을 지원할 수 있는 예시적인 아키텍처(900)를 도시한다. 엣지 네트워크(910)의 엔티티(911)는 리소스 디렉토리(930)에 발견 요청을 보낼 수 있다. 노드(924)는 이러한 요청의 기록을 유지할 수 있고, 일부 시점 뒤에, 엔티티(911)가 요청에 응답하여 리소스 디렉토리(930)에 의해 생성되는 발견 결과를 가질 것이라고 암시적으로 가정한다. 이후 시점에, 엔티티(912)가 동일한 발견 키 필드 데이터를 갖는 유사한 발견 요청을 보낼 수 있다. 이러한 요청은 노드(924)를 포함할 수 있는 경로를 지나갈 수 있다. 이러한 요청을 수신하는 것, 및 동일한 발견 키 필드 데이터를 갖고 엔티티(911)에 의해 보내어진 요청의 기록을 갖고 있다고 결정하는 것에 응답하여, 노드(924)는 이러한 요청을 리소스 디렉토리(930)에 전달하기 보다는 오히려 엔티티(911)에 리다이렉트할 수 있다. 엔티티(911)는 그리고 나서 리소스 디렉토리(930)로부터 보내어진 것으로부터 수신한 저장된 발견 결과 데이터에 의해 이러한 요청에 응답할 수 있다.

도 10은 요청된 발견 정보를 가질 수 있는 다른 엔티티에 요청을 리다이렉트하는 예시적인 신호들 및 프로시저들을 도시하는 예시적이지만 비제한적인 신호 흐름(1000)을 도시한다. 엔티티(1010)는 리소스 디렉토리(1040)에 발견 요청(1011)을 보낼 수 있다. 중간 노드(1030)가, 엔티티(1010)와 리소스 디렉토리(1040) 사이의 경로에 있을 수 있고, 따라서 블럭 1012에서 요청(1011)을 관찰 및 저장할 수 있다. 후속하여, 엔티티(1020)는, 중간 노드(1030)를 또한 횡단할 수 있고, 요청(1011)과 동일한 발견 키 필드 데이터를 갖는 유사한 발견 요청(1014)을 보낼 수 있다. 이러한 요청을 수신하는 것, 및, 블럭 1015에서, 엔티티(1010)에 의해 보내어진 요청(1011)의 기록을 갖고 있으며, 요청(1011)이 요청(1014)과 동일한 발견 키 필드 데이터를 갖고 있다고 결정하는 것에 응답하여, 중간 노드(1030)는 요청을 리소스 디렉토리(1040)에 전달하기 보다는 오히려 엔티티(1010)에 발견 요청(1016)으로서 리다이렉트할 수 있다. 엔티티(1010)는 그리고 나서 발견 요청(1017)에 의해 이러한 요청에 응답할 수 있고, 리소스 디렉토리(1040)로부터 보내어진 것으로부터 수신한 저장된 발견 결과 데이터를 엔티티(1020)에 보낼 수 있다.

본 명세서에서 주목되는 바와 같이, 캐싱된 발견 결과는 만료되거나 또는 무효로 되기 전까지 제한된 수명을 가질 수 있다. 따라서, 일 실시예에서, 캐싱 노드는, 이러한 수명을 연장하기 위해 및/또는 이러한 결과를 계속 사용하여 리소스 디렉토리에 관련된 발견 요청을 보내는 것을 회피하기 위해, 캐싱된 발견 결과를 지능적으로 수정하도록 구성될 수 있다. 캐싱된 발견 결과를 수정하는 방법 및 시점의 결정은 콘텐츠 서버로부터 수신되는 콘텐츠 공개 메시지에 기초할 수 있다. 이러한 메시지는 특정 콘텐츠와 관련되는 콘텐츠 식별자를 포함할 수 있다. 이러한 콘텐츠 식별자는 콘텐츠 서버의 위치를 요청하는 발견 요청들의 발견 키 필드 데이터에 또한 포함될 수 있어 특정 콘텐츠가 요청 엔티티에 의해 취득될 수 있다. 예를 들어, 발견 키 필드 데이터는 특정 콘텐츠의 위치를 포함할 수 있다. 상이한 콘텐츠 서버로부터의 특정 콘텐츠의 공개는 캐싱된 발견 결과들을 불완전하게 할 수 있다. 캐싱된 발견 결과를 수정하는 방법 및 시점의 결정은 또한, 또는 그 대신에, 콘텐츠 서버로부터 수신되는 콘텐츠 비공개 메시지에 기초할 수 있다. 콘텐츠 서버가 자신의 스토리지로부터 특정 콘텐츠를 삭제할 때, 이는 특정 삭제된 콘텐츠와 관련된 콘텐츠 식별자를 포함하는 이러한 메시지를 보낼 수 있다. 콘텐츠 식별자는 콘텐츠 서버의 위치를 요청하는 발견 요청들의 발견 키 필드 데이터에 또한 포함될 수 있어 특정 콘텐츠가 요청 엔티티에 의해 취득될 수 있다. 콘텐츠 서버로부터의 콘텐츠의 비공개는 캐싱된 발견 결과를 무효로 할 수 있다.

도 11은 이러한 실시예들을 지원할 수 있는 예시적인 아키텍처(1100)를 도시한다. 본 예에서, 노드(1127)는, 서버(1142) 및 노드(1126)일 수 있는, 특정 콘텐츠의 위치를 나타내는 발견 결과를 캐싱하였을 수 있다. 서버(1141)는 노드(1127)에서 캐싱된 발견 결과에서 식별되는 콘텐츠와 동일한 콘텐츠 식별자를 갖는 콘텐츠 공개 메시지를 보낼 수 있다. 이러한 공개 정보는 노드들(1124, 1127, 및 1129)에 의해 리소스 디렉토리(1130)에 전달될 수 있다. 콘텐츠 공개 메시지 검출시, 노드(1127)는 서버(1141)를 콘텐츠의 추가 위치로서 반영하도록 콘텐츠와 관련된 자신의 캐싱된 발견 결과를 수정할 수 있다.

노드(1126)는 후속하여 콘텐츠의 자신의 캐싱된 사본을 삭제할 수 있고, 노드(1127)에서 캐싱된 발견 결과에서 식별되는 콘텐츠와 동일한 콘텐츠 식별자를 갖는 콘텐츠 비공개 메시지를 생성하여 방송하거나 또는 다른 방식으로 송신할 수 있다. 콘텐츠 비공개 메시지 검출시, 노드(1127)는 콘텐츠와 관련된 위치들로부터 노드(1126)를 제거하도록 콘텐츠와 관련된 자신의 캐싱된 발견 결과를 수정할 수 있다.

도 12는 캐싱된 발견 결과들을 업데이트하는 예시적인 신호들 및 프로시저들을 도시하는 예시적이지만 비제한적인 신호 흐름(1200)을 도시한다. 본 예에서, 중간 노드(1230)는, 블럭 1211에서, 제2 서버(도시되지 않음) 및 중간 노드(1230)일 수 있는, 특정 콘텐츠의 위치를 나타내는 발견 결과를 캐싱하였을 수 있다. 서버(1210)는 블럭 1211에서 중간 노드(1230)에 의해 캐싱된 발견 결과에서 식별되는 콘텐츠와 동일한 콘텐츠 식별자를 갖는 콘텐츠 공개 메시지(1212)를 보낼 수 있다. 콘텐츠 공개 메시지(1212) 검출시, 노드(1230)는, 이러한 메시지를 메시지(1213)로서 리소스 디렉토리(1240)에 전달할 수 있고, 블럭 1214에서, 서버(1210)를 콘텐츠의 추가 위치로서 반영하도록 콘텐츠와 관련된 자신의 캐싱된 발견 결과를 수정할 수 있다.

중간 노드(1220)는 후속하여 콘텐츠의 자신의 캐싱된 사본을 삭제할 수 있고, 노드(1127)에서 캐싱된 발견 결과에서 식별되는 콘텐츠와 동일한 콘텐츠 식별자를 갖는 콘텐츠 비공개 메시지(1215)를 송신할 수 있다. 콘텐츠 비공개 메시지(1215) 검출시, 노드(1230)는 이러한 메시지를 메시지(1216)로서 리소스 디렉토리(1240)에 전달할 수 있고, 블럭 1217에서, 콘텐츠와 관련된 위치들로부터 노드(1220)를 제거하도록 콘텐츠와 관련된 자신의 캐싱된 발견 결과를 수정할 수 있다.

일 실시예에서, 발견 결과들은 발견 결과들을 분할 및/또는 조합하는 것에 의해서에 있어서 중간 노드에 의해 조작될 수 있다. 중간 노드는, 예를 들어, 노드가 제한된 스토리지 능력을 갖는다고 결정하는 것에 응답하여 그 일부를 캐싱하는 것에 의해 발견 결과를 분할할 수 있다. 이는 리소스가 제한되더라도 노드가 적어도 일부 발견 정보를 유지하게 할 것이다.

일부 실시예들에서는, 다수의 분산된 리소스 디렉토리들이 사용될 수 있다. 노드는 동일한 리소스에 대한 발견 요청들에 대해(예를 들어, 발견 요청들이 동일한 발견 키 필드 정보를 갖는 경우) 다수의 리소스 디렉토리들로부터의 발견 결과들을 전달 및/또는 캐싱할 수 있다. 캐싱 노드는 미래 요청기들에게 보다 완전한 발견 결과 정보를 제공할 수 있도록 상이한 리소스 디렉토리들로부터의 이러한 발견 결과들을 조합할 수 있다. 결과들을 조합하는 것은, 다수의 리소스 프로바이더들 도처에서 그 리소스에 대한 로드를 밸런싱하는 것을 도울 수 있는, 요청기들에게 요청된 리소스에 대한 더 큰 범위의 소스들을 또한 제공할 수 있다.

도 13은 이러한 실시예들을 지원할 수 있는 예시적인 아키텍처(1300)를 도시한다. 본 예에서, 엔티티(1352)는 특정 콘텐츠의 위치를 나타내는 발견 키 필드 데이터를 갖는 발견 요청을 리소스 디렉토리(1340)에 보낼 수 있고, 리소스 디렉토리(1340)는 콘텐츠의 위치가 게이트웨이(1321)라는 것을 나타내는 발견 결과들로 응답할 수 있다. 중간 노드(1327)는 이러한 발견 결과를 캐싱할 수 있다.

후속하여, 엔티티(1354)는 특정 콘텐츠의 위치를 나타내는 동일한 발견 키 필드 데이터를 갖는 발견 요청을 리소스 디렉토리(1330)에 보낼 수 있고, 리소스 디렉토리(1330)는 콘텐츠의 위치가 노드(1323)이라는 것을 나타내는 발견 결과들로 응답할 수 있다. 중간 노드(1327)는 이러한 발견 결과를 또한 캐싱할 수 있다. 중간 노드(1327)는 그리고 나서 이러한 2개의 발견 결과들을 특정 콘텐츠의 양자 모두의 위치들을 나타내는 발견 키 필드 데이터를 갖는 1개의 발견 결과로 조합할 수 있다.

차후 시점에, 엔티티(1353)는 특정 콘텐츠의 위치를 나타내는 동일한 발견 키 필드 데이터를 갖는 발견 요청을 리소스 디렉토리(1330)에 보낼 수 있다. 이제, 이러한 요청이 중간 노드(1327)에 도달할 때, 특정 콘텐츠에 대한 위치들의 보다 완전한 리스트로 이러한 요청에 응답할 수 있다. 엔티티(1353)는 그리고 나서 어느 하나의 위치로부터 콘텐츠를 검색할 것을 선택할 수 있다. 유사하게, 엔티티(1351)가 중간 노드(1327)를 횡단하는 특정 콘텐츠의 위치를 나타내는 동일한 발견 키 필드 데이터를 갖는 요청을 보내면, 이 노드는 콘텐츠에 대한 위치들의 보다 완전한 리스트로 요청에 또한 응답할 수 있다.

도 14는 캐싱된 발견 결과들을 조작하는 예시적인 신호들 및 프로시저들을 도시하는 예시적이지만 비제한적인 신호 흐름(1400)을 도시한다. 본 예에서, 엔티티(1410)는 특정 콘텐츠의 위치를 나타내는 발견 키 필드 데이터를 갖는 발견 요청(1411)을 리소스 디렉토리(1490)에 보낼 수 있다. 리소스 디렉토리(1490)는 콘텐츠의 위치가 게이트웨이(1450)라는 것을 나타내는 발견 응답(1412)으로 응답할 수 있다. 중간 노드(1470)는 1413에서 이러한 응답을 엔티티(1410)에 보낼 수 있고, 블럭 1414에서 이러한 발견 결과를 캐싱할 수 있다.

후속하여, 엔티티(1420)는 특정 콘텐츠의 위치를 나타내는 동일한 발견 키 필드 데이터를 갖는 발견 요청(1415)을 리소스 디렉토리(1480)에 보낼 수 있다. 리소스 디렉토리(1480)는 콘텐츠의 위치가 중간 노드(1460)라는 것을 나타내는 발견 응답(1416)으로 응답할 수 있다. 중간 노드(1470)는, 1417에서 이러한 응답을 엔티티(1420)에 보낼 수 있고, 블럭 1418에서 이러한 발견 결과를 캐싱할 수 있다. 블럭 1419에서, 중간 노드(1470)는 그리고 나서 이러한 2개의 발견 결과들을 특정 콘텐츠의 양자 모두의 위치들을 나타내는 발견 키 필드 데이터를 갖는 1개의 발견 결과로 조합할 수 있다.

차후 시점에, 엔티티(1430)는 특정 콘텐츠의 위치를 나타내는 동일한 발견 키 필드 데이터를 갖는 발견 요청(1421)을 어느 하나의 리소스 디렉토리에 보낼 수 있다. 그러나, 요청(1421)이 중간 노드(1470)에 도달할 때, 이러한 노드는 게이트웨이(1450) 및 중간 노드(1460) 양자 모두를 포함하는 특정 콘텐츠에 대한 위치들의 보다 완전한 리스트를 갖는 응답(1422)으로 이러한 요청에 응답할 수 있다. 엔티티(1430)는 그리고 나서 1423에서 게이트웨이(1450)로부터 콘텐츠를 검색할 것을 선택할 수 있다. 유사하게, 엔티티(1440)는 특정 콘텐츠의 위치를 나타내는 동일한 발견 키 필드 데이터를 갖는 발견 요청(1424)을 어느 하나의 리소스 디렉토리에 보낼 수 있다. 여기서 다시, 요청(1424)이 중간 노드(1470)에 도달할 때, 이러한 노드는 게이트웨이(1450) 및 중간 노드(1460) 양자 모두를 포함하는 특정 콘텐츠에 대한 위치들의 보다 완전한 리스트를 갖는 응답(1425)으로 이러한 요청에 응답할 수 있다. 엔티티(1440)는 그리고 나서 1426에서 중간 노드(1460)로부터 콘텐츠를 검색할 것을 선택할 수 있다.

도 15는 다양한 개시되는 리소스 발견 메커니즘들을 가능하게 하도록 개시되는 실시예들에 따라 노드들에 사용될 수 있는 예시적이지만 비제한적인 구조(1500)를 도시한다. 구조(1500)는, 하드웨어, 소프트웨어, 또는 이들의 조합으로 구현될 수 있다. 구조(1500)는 노드를 통과하며 검출되는 발견 결과들을 저장하는데 사용될 수 있는 발견 응답 캐시를 포함할 수 있다. 이러한 결과들은 이러한 결과들의 발견 키 필드에 있는 데이터를 사용하여 인덱싱될 수 있다. 수명을 포함하는 발견 결과들에 대해서, 해당 수명의 만료시, 캐싱된 발견 결과들은 발견 응답 캐시(1510)로부터 삭제될 수 있다. 따라서, 일부 실시예들에서, 발견 응답 캐시(1510)에 존재하는 이러한 결과들은 유효한 것으로 간주될 수 있다.

구조(1500)는, 노드 구현된 구조(1500)에 의해, 예를 들어, 리소스 디렉토리 이외의 다른 노드에 전달되는 발견 요청들을 기록할 수 있는 발견 요청 기록들(1520)을 또한 포함할 수 있다. 이러한 기록들은 이러한 요청들의 발견 키 필드에 있는 데이터를 사용하여 인덱싱될 수 있다.

구조(1500)는, 자신의 네트워크 또는 네트워크 서브섹션일 수 있는, 노드의 "이웃"에 있는 발견 결과 방송 메시지들의 기록일 수 있는 이웃에서의 발견 응답(1530)을 또한 포함할 수 있다. 캐싱 노드에 의해 발견 결과가 이웃에서 방송되면, 이는 방송 레이블로 마킹될 수 있다. (예를 들어, 캐시 대체, 수명 만료 등으로 인해) 발견 응답 캐시로부터 발견 결과가 삭제될 때, 본래 발견 결과 방송 메시지와 동일하게 방송 홉이 설정된 업데이트 통지가 캐싱 노드로부터 이웃 노드들에 방송될 수 있다. 업데이트 통지를 보내는 캐싱 노드가 이러한 발견 결과를 캐싱하는 유일한 이웃이면, 동일한 발견 키 필드 데이터를 갖는 특정 기록은 이웃에서의 발견 응답(1530)으로부터 제거될 수 있다.

도 16은 일 실시예에 따라 발견 요청을 처리하는 예시적이지만 비제한적인 방법(1600)을 도시한다. 방법(1600)에 관하여 개시되는 기능들, 액션, 및/또는 단계들 중 임의의 것은, 개시되는 기능들, 액션 및 단계들의 서브세트와, 임의의 순서로, 또는 독립적으로, 및 본 명세서에 개시되거나 또는 그렇지 않은, 임의의 다른 기능들, 액션들 및 단계들과 조합하여, 수행될 수 있다는 점에 주목하자. 모든 이러한 실시예들은 본 개시내용의 범위 내의 것으로서 고려된다.

블럭 1610에서, 노드는 발견 요청을 수신할 수 있다. 블럭 1615에서, 노드는, 블럭 1620에서, 일치하는 발견 응답의 캐싱된 사본이 존재한다고 결정하기 위해, 발견 요청의 발견 키 필드에서의 데이터에 일치하는 정보를 자신의 발견 응답 캐시에 배치하려고 시도할 수 있다. 일치하는 발견 응답의 캐싱된 사본이 존재하면, 블럭 1625에서 이러한 사본으로부터의 데이터는 응답으로서 요청기에 리턴된다.

일치하는 발견 응답이 존재하지 않으면, 블럭 1630에서, 노드는, 블럭 1635에서, 노드에 이전에 방송되었던 일치하는 발견 응답의 캐싱된 사본이 존재한다고 결정하기 위해, 발견 요청의 발견 키 필드에서의 데이터에 일치하는 정보를 자신의 이웃에서의 발견 응답에 배치하려고 시도할 수 있다. 일치하는 방송 메시지가 발견되면, 노드는 일치하는 발견 키 필드 데이터를 갖는 메시지를 방송한 이웃 노드에 발견 요청을 전달할 수 있다.

일치하는 방송 메시지가 발견되지 않으면, 블럭 1645에서, 노드는, 블럭 1650에서, 동일한 리소스 상의 정보에 대한 이전 요청이 수신되었는지 결정하기 위해, 발견 요청의 발견 키 필드에서의 데이터에 일치하는 정보를 자신의 발견 요청 기록에 배치하려고 시도할 수 있다. 그렇다면, 이는 이전 요청기가 일치하는 발견 응답의 사본을 갖는다는 것을 나타낼 수 있다. 일치하는 발견 요청이 발견되면, 일부 실시예들에서 노드와 이전 요청기 및/또는 리소스 디렉토리 사이의 거리들, 노드에 알려져 있다면 리소스 디렉토리의 상태 등과 같은 기준들과 함께, 블럭 1655에서, 발견 요청을 이전 요청기에 전달할 것인지 결정한다. 노드가 요청을 이전 요청기에 전달하기로 결정하면 블럭 1660에서 그렇게 한다. 그렇지 않으면, 블럭 1665에서, 발견 요청은 리소스 디렉토리에 전달된다.

도 17은 일 실시예에 따라 발견 응답을 처리하는 예시적이지만 비제한적인 방법(1700)을 도시한다. 방법(1700)에 관하여 개시되는 기능들, 액션, 및/또는 단계들 중 임의의 것은, 개시되는 기능들, 액션 및 단계들의 서브세트와, 임의의 순서로, 또는 독립적으로, 및 본 명세서에 개시되거나 또는 그렇지 않은, 임의의 다른 기능들, 액션들 및 단계들과 조합하여, 수행될 수 있다는 점에 주목하자. 모든 이러한 실시예들은 본 개시내용의 범위 내의 것으로서 고려된다.

블럭 1710에서, 발견 응답은 노드(네트워크에서의 임의의 엔티티일 수 있음)에 의해 수신될 수 있다. 블럭 1720에서, 노드는 발견 응답을 캐싱할 것인지 결정할 수 있다. 그렇다면, 이루어질 수 있는 2개의 결정들이 더 존재한다. 블럭 1730에서, 노드는 응답에서의 발견 결과들이 노드에서 이미 캐싱된 다른 결과들과 조합될 수 있는지 결정할 수 있다. 이는 캐싱된 발견 키 필드 데이터를 응답에 포함되는 발견 키 필드와 일치시키는 것에 의해 수행될 수 있다. 이러한 엔트리가 발견되지 않으면, 블럭 1735에서 노드는 발견 응답 캐시에 발견 응답을 저장한다. 일치하는 엔트리가 발견되면, 블럭 1740에서 이러한 엔트리는 보다 최근에 수신된 결과들과 조합되고, 이러한 조합된 엔트리는 발견 응답 캐시에 저장된다.

블럭 1750에서, 노드는 이웃에서의 발견 결과를 방송할 것인지 또한 결정할 수 있다. 이러한 결정은 차후 시점에 및/또는 주기적으로 이루어질 수 있고, 모든 저장된 발견 결과들에 적용될 수 있다. 이러한 결정을 위해 사용되는 기준은 캐싱된 결과들이 사용되거나 또는 다른 엔티티들에 제공되는 빈도수를 포함한다. 노드가 결과들을 방송하기로 결정하면, 블럭 1760에서 이러한 결과들을 갖는 방송 메시지가 생성되어 노드의 이웃에 송신된다.

도 18은 일 실시예에 따라 수신된 발견 결과 방송 메시지를 처리하는 예시적이지만 비제한적인 방법(1800)을 도시한다. 방법(1700)에 관하여 개시되는 기능들, 액션, 및/또는 단계들 중 임의의 것은, 개시되는 기능들, 액션 및 단계들의 서브세트와, 임의의 순서로, 또는 독립적으로, 및 본 명세서에 개시되거나 또는 그렇지 않은, 임의의 다른 기능들, 액션들 및 단계들과 조합하여, 수행될 수 있다는 점에 주목하자. 모든 이러한 실시예들은 본 개시내용의 범위 내의 것으로서 고려된다.

블럭 1810에서 노드(네트워크에서의 임의의 엔티티일 수 있음)는 발견 결과 방송 메시지를 수신할 수 있다. 블럭 1815에서, 노드는, 블럭 1820에서, 홉 카운트가 이제 제로인지 결정하기 위해, 메시지에 표시되는 홉 카운트를 1만큼 감소시킬 수 있다. 그렇다면, 블럭 1825에서 노드는 방송 메시지를 자신의 다른 이웃들에게 전달하는 것을 억제한다. 홉 카운트가 여전히 제로보다 크면, 블럭 1830에서 노드는, 감소된 홉 카운트를 반영하도록 수정된, 방송 메시지를 자신의 이웃들에게 송신한다.

노드는, 블럭 1835에서, 메시지가 자신의 이웃에서의 발견 응답에 있는 노드의 엔트리들에 추가될 의도인 캐싱 메시지인지, 또는 자신의 이웃에서의 발견 응답에 있는 노드의 엔트리들로부터 결과를 제거할 의도인 삭제 메시지인지 결정하기 위해 방송 메시지의 상태 필드를 또한 평가할 수 있다. 메시지가 이웃 결과들에 추가될 의도인 것으로 상태가 나타내면, 블럭 1845에서 노드는 수신된 방송 메시지의 것과 일치하는 발견 키 필드 데이터를 갖는 이미 캐싱된 임의의 결과들을 갖는지 결정할 수 있다. 그렇다면, 블럭 1855에서 노드는 방송 메시지로부터의 결과들을 자신의 이웃에서의 발견 응답에 있는 기존의 일치하는 엔트리에 추가할 수 있다. 그렇지 않다면, 블럭 1865에서 노드는 방송 메시지 결과들에 대해 자신의 이웃에서의 발견 응답에 새로운 엔트리를 생성하여 추가할 수 있다.

메시지가 자신의 이웃에서의 발견 응답에 있는 노드의 엔트리들로부터 결과를 제거할 의도인 삭제 메시지인 것으로 상태가 나타내면, 블럭 1850에서 노드는 수신된 방송 메시지의 유래자(originator)가 수신된 방송 메시지의 발견 키 필드 데이터에 일치하는 이웃에서의 발견 응답에 있는 캐싱된 엔트리 뿐인지 결정할 수 있다. 그렇다면, 블럭 1860에서 노드는 자신의 이웃에서의 발견 응답으로부터 엔트리를 제거할 수 있다. 수신된 방송 메시지의 발견 키 필드 데이터에 일치하는 엔트리와 관련된 다른 엔티티들이 존재하면, 블럭 1870에서 노드는 엔트리로부터 유래자만을 제거하고 엔트리의 나머지 데이터는 자신의 캐시에 남겨 둘 수 있다.

개시되는 실시예들은 SLP(Service Location Protocol)를 사용하여 구현될 수 있다. SLP에서, 서비스들은 서비스 타입 및 범위에 기초하여 또는 명시되는 술부(predicate)를 만족하는 서비스들에 기초하여 발견될 수 있다. 따라서, SLP 구현들에서, SLP 발견 메시지들에 대한 발견 키 필드 데이터는, 타입, 범위, 술부 및 이들의 임의의 조합 중 하나 이상을 포함할 수 있다. 일 실시예에 따른 예시적이지만 비제한적인 SLP 서비스 응답 메시지(1900)가 도 19에 도시된다. 서비스 응답 메시지(1900)는 서비스 위치 헤더(1910), 서비스 타입의 길이(1915), 서비스 타입 문자열(1920), 범위 리스트의 길이(1925), 범위 리스트 문자열(1930), 술부 문자열의 길이(1935), 서비스 요청 술부(1940), 에러 코드(1945), URL 엔트리 카운트(1950), 및 URL(Universal Resource Locator) 엔트리들의 리스팅(1960)을 포함할 수 있다. 메시지(1900)에 포함되는 서비스 타입, 범위 리스트 및 술부의 포함 및/또는 콘텐츠는 서비스 응답 메시지(1900)의 생성을 초래한 유래(originating) 요청 메시지의 발견 키 필드 데이터에 의존될 수 있다는 점에 주목하자.

도 20은 SLP 서비스 발견의 예시적인 실시예에 사용될 수 있는 네트워크 구성(2000)을 도시한다. UA들(User Agents)(2011-2014)은 서비스 발견을 위해 DA들(Directory Agents)(2041 및 2042) 중 하나 이상과 통신할 수 있다. SA(Service Agent)(2021)는 서비스 등록을 위해 DA(2041)와 통신할 수 있는 한편, SA(2022)는 서비스 등록을 위해 DA(2042)와 통신할 수 있다. 이러한 통신들은 네트워크 노드들(2001-2007)에 의해 촉진될 수 있다.

일 예에서는, "service:device:sensor1://temperature", "service:device:sensor2://temperature" 및 "service:device:sensor1://humidity"라는 URL들을 갖는 서비스들이 SA(2021)에 의해 DA(2041)에 등록될 수 있다. "service:device:sensor3://humidity", "service:device:sensor4://humidity" 및 "service:device:sensor5://temperature"라는 URL들을 갖는 서비스들이 SA(2022)에 의해 DA(2042)에 등록될 수 있다. 이러한 서비스들, 및 이들을 제공하는 서비스 에이전트들의 위치들은, SLP를 사용하여 현재 가능한 것보다 연관된 엔티티들에 대해 더 낮은 오버헤드로 더 효율적인 발견 프로세스들을 제공할 수 있는 개시된 실시예들을 사용하여 발견될 수 있다.

예를 들어, US(2011)는 온도를 나타내도록 서비스 타입이 설정된 서비스 발견 요청을 DA(2041)에 보낼 수 있다. DA(2041)는 "service:device:sensor1://temperature" 및 "service:device:sensor2://temperature"라는 URL들을 포함하는 발견 응답을 리턴할 수 있다. 노드(2002)는 이하 표 1(발견 결과 캐싱)에 보여지는 바와 같이 발견 결과를 캐싱할 수 있다(예를 들어, 자신의 발견 응답 캐시에 저장함).

UA(2012)는 서비스 타입이 동일한(즉, 서비스 타입이 온도로 설정된) 서비스 발견 요청을 DA(2041)에 보낼 수 있다. 노드(2001)는 이러한 요청을 US(2011)에 전달할 수 있는데, 이는 노드(2001)가 자신의 발견 요청 기록 캐시에 UA(2001)의 이전 발견 요청의 기록을 행하였을 수 있기 때문에 발견 결과를 갖는 것으로 암시적으로 가정될 수 있다. UA(2001)는 자신의 로컬하게 캐싱된 발견 결과로 UA(2012)에 응답할 수 있다.

UA(2013)는 온도로 또한 서비스 타입이 설정된 서비스 발견 요청을 DA(2041)에 보낼 수 있다. 노드(2002)는, 이러한 서비스 발견 요청을, DA(2041)에 전달하기 보다는 오히려, 자신의 로컬하게 캐싱된 발견 결과로 요청에 응답할 수 있는 노드(2006)에 전달할 수 있다. 노드(2002)는 이러한 발견 결과를 그 노드를 횡단할 때 자신의 발견 응답 캐시에 캐싱할 수 있다. 노드(2002)의 발견 응답 캐시는 이제 위 표 1의 콘텐츠를, 적어도 일부, 또한 반영할 수 있다. 노드(2002)는 이웃 노드(2003)에 최근 캐시된 발견 결과를 또한 방송할 수 있다.

US(2015)는 서비스 타입이 동일한(즉, 온도로 설정된) 서비스 발견 요청을 DA(2041)에 보낼 수 있다. 노드(2003)가 이러한 서비스 발견 요청을 수신할 때, 이는 노드(2002)로부터 수신된 캐싱된 발견 결과를 자신의 이웃 캐시에서의 발견 응답에 저장하였는지를 결정할 수 있고, 이에 따라 요청을 노드(2005)에 및 DA(2041) 쪽으로 대신에 노드(2002)에 전달할 수 있다. 노드(2002)는 자신의 로컬하게 캐싱된 발견 결과로 전달된 서비스 발견 요청에 응답할 수 있다.

SA(2021)는 URL이 "service:device:sensor6://temperature"인 새로운 서비스 등록을 DA(2041)에 보낼 수 있다. 이러한 등록 정보는 아래 표 2에 보여지는 바와 같이 캐싱된 발견 결과를 지능적으로 수정할 수 있는 노드(2006)에 도달할 수 있다.

UA(2013)는 서비스 타입이 온도로 설정된 서비스 발견 요청을 DA(2041)에 보낼 수 있다. 노드(2006)는 UA(2013)에 응답할 수 있고 표 2에 반영된 발견 결과들을 제공할 수 있다.

US(2015)는 서비스 타입이 습도로 설정된 서비스 발견 요청을 DA(2041)에 보낼 수 있다. DA(2041)는 "service:device:sensor1://humidity"라는 서비스 URL을 포함하는 서비스 응답으로 UA(5)에 응답할 수 있다. 노드(2003)는 아래 표 3에 보여지는 바와 같이 그 노드를 횡단할 때 이러한 발견을 캐싱할 수 있다.

UA(2013)는 그리고 나서 서비스 타입이 또한 습도로 설정된 서비스 발견 요청을 DA(2042)에 보낼 수 있다. DA(2042)는 "service:device:sensor3://humidity" 및 "service:device:sensor4://humidity"의 서비스 URL들을 포함하는 서비스 응답으로 UA(2013)에 응답할 수 있다. 노드(2003)는 이러한 발견 응답을 또한 캐싱할 수 있고 아래 표 4에 보여지는 바와 같이 2개의 발견 결과들을 조합할 수 있다.

UA(2014)는 마찬가지로 서비스 타입이 습도로 설정된 서비스 발견 요청을 DA(2042)에 보낼 수 있다. UA(2014)는 본 명세서에 개시되는 메커니즘들을 사용하여 노드(2003)으로부터 완전한 발견 결과들을 이제 취득할 수 있다.

도 21a는 향상된 발견을 위한 시스템들 및 방법들 중 하나 이상의 개시되는 실시예들이 구현될 수 있는 예시적인 M2M 또는 IoT 통신 시스템(10)의 도면이다. 일반적으로, M2M 기술들은 IoT에 대한 구성 요소들을 제공하고, 임의의 M2M 디바이스, 게이트웨이, 또는 서비스 플랫폼은 IoT 뿐만 아니라 IoT 서비스 레이어 등의 컴포넌트일 수 있다.

도 21a에 도시된 바와 같이, M2M/IoT 통신 시스템(10)은 통신 네트워크(12)를 포함한다. 통신 네트워크(12)는 고정 네트워크 또는 무선 네트워크(예를 들어, WLAN, 셀룰러 등) 또는 이종 네트워크들의 네트워크일 수 있다. 예를 들어, 통신 네트워크(12)는, 음성, 데이터, 비디오, 메시징, 방송 등과 같은 콘텐츠를 다수의 사용자들에게 제공하는 다수의 액세스 네트워크들로 구성될 수 있다. 예를 들어, 통신 네트워크(12)는, CDMA(Code Division Multiple Access), TDMA(Time Division Multiple Access), FDMA(Frequency Division Multiple Access), OFDMA(Orthogonal FDMA), SC-FDMA(Singe-Carrier FDMA) 등과 같은 하나 이상의 채널 액세스 방법들을 채택할 수 있다. 또한, 통신 네트워크(12)는, 예를 들어, 코어 네트워크, 인터넷, 센서 네트워크, 산업적 제어 네트워크, 개인 영역 네트워크, 융합된 개인 네트워크, 위성 네트워크, 홈 네트워크, 또는 기업 네트워크와 같은 다른 네트워크들을 포함할 수 있다.

도 21a에 도시된 바와 같이, M2M/IoT 통신 시스템(10)은 M2M 게이트웨이 디바이스(14) 및 M2M 단말 디바이스들(18)을 포함할 수 있다. 임의의 수의 M2M 게이트웨이 디바이스들(14) 및 M2M 단말 디바이스들(18)이 원하는 바에 따라 M2M/IoT 통신 시스템(10)에 포함될 수 있다는 점이 이해될 것이다. M2M 게이트웨이 디바이스들(14) 및 M2M 단말 디바이스들(18) 각각은 통신 네트워크(12) 또는 직접 무선 링크를 통해 신호들을 송신 및 수신하도록 구성될 수 있다. M2M 게이트웨이 디바이스(14)는 고정 네트워크 M2M 디바이스들(예를 들어, PLC) 뿐만 아니라 무선 M2M 디바이스들(예를 들어, 셀룰러 및 논-셀룰러)이, 통신 네트워크(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)), 직접 무선 링크, 및 유선을 포함하는 다양한 네트워크들을 통해 통신할 수 있다. 리소스 디렉토리들, 게이트웨이들, 프록시들, 서버들, UA들, DA들, SA들, 임의의 다른 타입의 노드들, 및 임의의 다른 개시되는 엔티티들과 같은, 본 명세서에 설명되는 엔티티들 중 임의의 것은, M2M 디바이스들(18), 게이트웨이들(14), 및 서비스 플랫폼(22)과 같은 디바이스들 상에서, 일부가 또는 전부가, 구현되거나, 실행되거나, 또는 다른 방식으로 가능하게 될 수 있다. 예를 들어, 게이트웨이들(121, 240), 및 본 명세서에 설명되는 다른 게이트웨이들 각각은 게이트웨이(14)와 같은 게이트웨이일 수 있다. 마찬가지로, 엔티티들(111, 112), 및 본 명세서에 설명되는 그와 유사한 것들 각각은 M2M 디바이스(18)와 같은 디바이스일 수 있거나, 또는 이러한 디바이스 상에 구현될 수 있다. 모든 이러한 실시예들은 본 개시내용의 범위 내의 것으로서 고려된다.

도시된 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 서비스 플랫폼(22)은, 또한, 데이터를 수집하여, 상이한 타입들의 M2M 애플리케이션들(20)과 호환될 수 있도록 데이터를 변환할 수 있다. M2M 서비스 플랫폼(22)의 기능들은, 예를 들어, 웹 서버로서, 셀룰러 코어 네트워크에서, 클라우드에서 등 다양한 방식들로 구현될 수 있다.

또한, 도 21b를 참조하면, M2M 서비스 플랫폼은, 다양한 애플리케이션들 및 버티컬들(verticals)이 영향을 줄 수 있는 서비스 전달 능력들의 코어 세트를 제공하는 서비스 레이어(26)(예를 들어, 본 명세서에 설명되는 바와 같은 NSCL(Network Service Capability Layer))를 통상적으로 구현한다. 이러한 서비스 능력들은, M2M 애플리케이션들(20)이, 디바이스들과 상호작용하여, 데이터 수집, 데이터 분석, 디바이스 관리, 보안, 빌링(billing), 서비스/디바이스 발견 등과 같은 기능들을 수행할 수 있게 한다. 본질적으로, 이러한 서비스 능력들은 이러한 기능들을 구현하는 부담에서 애플리케이션들을 자유롭게 하며, 따라서 애플리케이션 개발을 단순하게 하며, 시장에 대한 비용 및 시간을 줄여준다. 서비스 레이어(26)는, 또한, M2M 애플리케이션들(20)이, 서비스 레이어(26)가 제공하는 서비스들과 관련하여 다양한 네트워크들(12)을 통해 통신할 수 있게 한다.

일부 실시예들에서, M2M 애플리케이션들(20)은 향상된 발견을 위한 시스템들 및 방법들의 개시된 것들을 사용할 수 있는 디바이스들을 포함하는 하나 이상의 피어-투-피어 네트워크들의 생성을 위한 기초를 형성하는 바람직한 애플리케이션들을 포함할 수 있다. M2M 애플리케이션들(20)은, 이에 제한되는 것은 아니지만, 수송, 건강 및 건강관리, 접속된 가정, 에너지 관리, 자산 추적, 및 보안 및 감시와 같은, 다양한 산업들에서의 애플리케이션들을 포함할 수 있다. 위에 언급된 바와 같이, 시스템의 디바이스들, 게이트웨이들, 및 다른 서버들에 걸쳐 실행되는, M2M 서비스 레이어는, 예를 들어, 데이터 수집, 디바이스 관리, 보안, 빌링(billing), 위치 추적/지오펜싱(geofencing), 디바이스/서비스 발견, 및 레거시 시스템들 통합과 같은 기능들을 지원하고, 이러한 기능들을 서비스들로서 M2M 애플리케이션들(20)에 제공한다. 설명된 서비스 레이어 및 오브젝트들이 상호작용하는 애플리케이션들은 M2M 애플리케이션들(20)의 것들과 같은 애플리케이션들일 수 있다.

도 21c는, 예를 들어, M2M 단말 디바이스(18) 또는 M2M 게이트웨이 디바이스(14)와 같은, 예시적인 M2M 디바이스(30)의 시스템 도면이다. 도 21c에 도시된 바와 같이, M2M 디바이스(30)는, 프로세서(32), 송수신기(34), 송신/수신 엘리먼트(36), 스피커/마이크로폰(38), 키패드(40), 디스플레이/터치패드/인디케이터들(예를 들어, 하나 이상의 LED들(Light Emitting Diodes))(42), 비-분리형 메모리(44), 분리형 메모리(46), 전원(48), GPS(Global Positioning System) 칩셋(50), 및 다른 주변기기들(52)을 포함할 수 있다. M2M 디바이스(40)는 실시예에 부합하면서 전술한 엘리먼트들의 임의의 서브-조합을 포함할 수 있다는 점이 이해될 것이다. 이러한 디바이스는 향상된 발견을 위해 개시된 시스템들 및 방법들을 사용하는 디바이스일 수 있다.

프로세서(32)는, 범용 프로세서, 특수 목적 프로세서, 종래의 프로세서, DSP(Digital Signal Processor), 복수의 마이크로프로세서들, DSP 코어와 관련된 하나 이상의 마이크로프로세서들, 컨트롤러, 마이크로컨트롤러, 하나 이상의 ASIC들(Application Specific Integrated Circuits), 하나 이상의 FPGA(Field Programmable Gate Array) 회로들, 임의의 다른 타입 및 수의 IC들(Integrated Circuits), 상태 머신 등일 수 있다. 프로세서(32)는, 신호 코딩, 데이터 처리, 전력 제어, 입력/출력 처리, 및/또는 M2M 디바이스(30)가 무선 환경에서 동작할 수 있게 하는 임의의 다른 기능을 수행할 수 있다. 프로세서(32)는 송신/수신 엘리먼트(36)에 연결될 수 있는 송수신기(34)에 연결될 수 있다. 도 21c는 프로세서(32)와 송수신기(34)를 별도의 컴포넌트들로서 묘사하지만, 프로세서(32)와 송수신기(34)는 전자 패키지 또는 칩 내에 함께 통합될 수 있다는 점이 이해될 것이다. 프로세서(32)는 애플리케이션-레이어 프로그램들(예를 들어, 브라우저들) 및/또는 RAN(Radio Access-Layer) 프로그램들 및/또는 통신을 수행할 수 있다. 프로세서(32)는, 예를 들어, 액세스 레이어 및/또는 애플리케이션 레이어에서와 같은, 인증, 보안 키 승낙, 및/또는 암호화 동작들과 같은, 보안 동작들을 수행할 수 있다.

송신/수신 엘리먼트(36)는 M2M 서비스 플랫폼(9)에 신호들을 송신하도록, 및/또는 이로부터의 신호들을 수신하도록 구성될 수 있다. 예를 들어, 일 실시예에서, 송신/수신 엘리먼트(36)는 RF 신호들을 송신 및/또는 수신하도록 구성되는 안테나일 수 있다. 송신/수신 엘리먼트(36)는, WLAN, WPAN, 셀룰러 등과 같은, 다양한 네트워크들 및 에어 인터페이스들을 지원할 수 있다. 일 실시예에서, 송신/수신 엘리먼트(36)는, 예를 들어, IR, UV, 또는 가시광 신호들을 송신 및/또는 수신하도록 구성되는 이미터/검출기일 수 있다. 또 다른 실시예에서, 송신/수신 엘리먼트(36)는 RF 및 광 신호들 양자 모두를 송신 및 수신하도록 구성될 수 있다. 송신/수신 엘리먼트(36)는 무선 또는 유선 신호들의 임의의 조합을 송신 및/또는 수신하도록 구성될 수 있다는 점이 이해될 것이다.

또한, 송신/수신 엘리먼트(36)가 단일 엘리먼트로서 도 21c에 묘사되지만, 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)와 같은, 임의의 타입의 적절한 메모리로부터 정보를 액세스할 수 있고, 거기에 데이터를 저장할 수 있다. 비-분리형 메모리(44)는, RAM(Random-Access Memory), ROM(Read- Only Memory), 하드 디스크, 또는 다른 타입의 메모리 스토리지 디바이스를 포함할 수 있다. 분리형 메모리(46)는, SIM(Subscriber Identity Module) 카드, 메모리 스틱, SD(Secure Digital) 메모리 카드 등을 포함할 수 있다. 다른 실시예들에서, 프로세서(32)는, 서버 또는 가정용 컴퓨터와 같은, M2M 디바이스(30) 상에 물리적으로 위치되지 않는 메모리로부터 정보를 액세스할 수 있고, 거기에 데이터를 저장할 수 있다. 프로세서(32)는, 본 명세서에서 제시된 실시예들의 일부에서 설명되는 것들과 같은, 다양한 조건들 및 파라미터들에 응답하여, 디스플레이 또는 인디케이터들(42) 상의 점등 패턴들, 이미지들 또는 컬러들을 제어하도록 구성될 수 있다.

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

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

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

도 21d는, 예를 들어, 도 21a 및 도 21b의 M2M 서비스 플랫폼(22)이 구현될 수 있는 예시적인 컴퓨팅 시스템(90)의 블럭도이다. 컴퓨팅 시스템(90)은, 컴퓨터 또는 서버를 포함할 수 있고, 주로 컴퓨터 판독가능 명령어들에 의해 제어될 수 있는데, 이러한 컴퓨터 판독가능 명령어들은, 소프트웨어의 형태일 수 있거나, 이러한 소프트웨어가 저장되거나 액세스되는, 어디서든지, 또는 어느 것에 의해 있을 수 있다. 이러한 컴퓨터 판독가능 명령어들은, 컴퓨팅 시스템(90)으로 하여금 작업하게 하도록 CPU(Central Processing Unit)(91) 내에서 실행될 수 있다. 많은 알려진 워크스테이션들, 서버들, 및 퍼스널 컴퓨터들에서, 중앙 처리 유닛(91)은 마이크로프로세서라 불리우는 단일 칩 CPU에 의해 구현된다. 다른 머신들에서, 중앙 처리 유닛(91)은 다수의 프로세서들을 포함할 수 있다. 코프로세서(81)는, 메인 CPU(91)와는 구별되며, 추가적 기능들을 수행하거나 또는 CPU(91)를 도와주는 옵션의 프로세서이다. CPU(91) 및/또는 코프로세서(81)는, 향상된 발견을 위해 개시되는 시스템들 및 방법들에 관련된 데이터를, 수신하고, 생성하고, 처리할 수 있다.

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

시스템 버스(80)에 연결되는 메모리 디바이스들은 RAM(Random Access Memory)(82) 및 ROM(Read Only Memory)(93)을 포함한다. 이러한 메모리들은 정보가 저장 및 검색되게 하는 회로를 포함한다. ROM들(93)은 쉽게 수정될 수 없는 저장된 데이터를 일반적으로 포함한다. RAM(82)에 저장되는 데이터는 CPU(91) 또는 다른 하드웨어 디바이스들에 의해 판독 또는 변경될 수 있다. RAM(82) 및/또는 ROM(93)에 대한 액세스는 메모리 제어기(92)에 의해 제어될 수 있다. 메모리 제어기(92)는 명령어들이 실행될 때 가상 어드레스들을 물리적 어드레스들로 변환하는 어드레스 변환 기능을 제공할 수 있다. 메모리 제어기(92)는, 또한, 시스템 내의 프로세스들을 격리시키고, 시스템 프로세스들을 사용자 프로세스들로부터 격리시키는 메모리 보호 기능을 제공할 수 있다. 따라서, 제1 모드에서 실행하는 프로그램은 자기 자신의 프로세스 가상 어드레스 공간에 의해 맵핑되는 메모리만을 액세스할 수 있다; 프로세스들 사이에 공유하는 메모리가 셋업되지 않으면 다른 프로세스의 가상 어드레스 공간 내의 메모리를 액세스할 수 없다.

또한, 컴퓨팅 시스템(90)은, 프린터(94), 키보드(84), 마우스(95), 및 디스크 드라이브(85)와 같은, 주변기기들에 CPU(91)로부터의 명령어들을 통신하는 것을 담당하는 주변기기 제어기(83)를 포함할 수 있다.

디스플레이 제어기(96)에 의해 제어되는 디스플레이(86)는, 컴퓨팅 시스템(90)에 의해 생성되는 가시적 출력을 디스플레이하는데 사용된다. 이러한 가시적 출력은, 텍스트, 그래픽, 애니메이션 그래픽, 및 비디오를 포함할 수 있다. 디스플레이(86)는, CRT 기반의 비디오 디스플레이, LCD 기반의 평면 패널 디스플레이, 가스 플라즈마 기반의 평면 패널 디스플레이, 또는 터치 패널로 구현될 수 있다. 디스플레이 제어기(96)는 디스플레이(86)에 보내어지는 비디오 신호를 생성하는데 요구되는 전자 컴포넌트들을 포함한다.

또한, 컴퓨팅 시스템(90)은, 도 21a 및 도 21b의 네트워크(12)와 같은, 외부 통신 네트워크에 컴퓨팅 시스템(90)을 접속하는 데 사용될 수 있는 네트워크 어댑터(97)를 포함할 수 있다. 일 실시예에서, 네트워크 어댑터(97)는 향상된 발견을 위해 개시되는 시스템들 및 방법들에 관련되는 데이터를 수신 및 송신할 수 있다.

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

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

본 작성된 설명은, 최상의 모드를 포함하여, 본 발명을 개시하는, 또한 통상의 기술자가, 임의의 디바이스들 또는 시스템들을 제조하고 사용하여, 임의의 포함되는 방법들을 수행하는 것을 포함하여, 본 발명을 실시할 수 있게 하는, 예들을 사용한다. 본 발명의 특허가능한 범위는, 청구항들에 의해 정의되며, 통상의 기술자에게 떠오르는 다른 예들을 포함할 수 있다. 이러한 다른 예들은, 그들이 청구항들의 기재와 다르지 않은 구조적 엘리먼트들을 가지는 경우에 또는 그들이 청구항들의 기재와의 미미한 차이를 갖는 등가의 구조적 엘리먼트들을 포함하는 경우에, 청구항들의 범위 내에 있는 것으로 의도된다.

Claims (20)

1. 방법으로서,
   접속되는 엔티티들의 네트워크에서의 네트워크 노드에서 제1 엔티티로부터 제1 발견 요청을 수신하는 단계;
   상기 제1 발견 요청을 상기 네트워크 노드로부터 리소스 디렉토리 엔티티에 송신하는 단계;
   상기 리소스 디렉토리 엔티티로부터 상기 네트워크 노드에서 제1 발견 응답을 수신하는 단계;
   상기 제1 발견 응답에 기초하여 상기 네트워크 노드에서 제1 발견 응답 데이터를 저장하는 단계;
   상기 제1 발견 응답을 상기 네트워크 노드로부터 상기 제1 엔티티에 송신하는 단계;
   상기 네트워크 노드에서 제2 엔티티로부터 제2 발견 요청을 수신하는 단계;
   상기 네트워크 노드에서, 상기 제2 발견 요청의 발견 요청 데이터가 상기 제1 발견 응답 데이터에 대응한다고 결정하는 단계; 및
   상기 네트워크 노드로부터, 상기 제1 발견 응답 데이터를 포함하는 제2 발견 응답을 상기 제2 엔티티에 송신하고, 상기 네트워크 노드가 상기 제1 발견 응답 데이터를 포함하는 상기 제2 발견 응답을 상기 제2 엔티티에 송신하였음을 지시하는 통지를 상기 리소스 디렉토리 엔티티에 송신하는 단계
   를 포함하는 방법.
2. 제1항에 있어서,
   제3 발견 요청의 발견 요청 데이터가 상기 제1 발견 응답 데이터에 대응한다고 결정하는 단계; 및
   상기 제1 엔티티의 위치를 포함하는 제3 발견 응답을 상기 제2 엔티티에 송신하는 단계
   를 더 포함하는 방법.
3. 제1항에 있어서,
   제3 발견 요청의 발견 요청 데이터가 상기 제1 발견 응답 데이터에 대응한다고 결정하는 단계; 및
   상기 제3 발견 요청을 상기 제1 엔티티에 송신하는 단계
   를 더 포함하는 방법.
4. 제1항에 있어서,
   제3 엔티티로부터 제3 발견 응답을 수신하는 단계;
   상기 제3 발견 응답의 제2 발견 응답 데이터의 제1 서브세트가 상기 제1 발견 응답 데이터의 제1 서브세트에 대응한다고 결정하는 단계; 및
   상기 제2 발견 응답 데이터의 제2 서브세트를 포함하도록 상기 제1 발견 응답 데이터를 수정하는 것에 의해 상기 제2 발견 응답 데이터의 제2 서브세트를 저장하는 단계
   를 더 포함하는 방법.
5. 제1항에 있어서,
   제3 엔티티로부터 제3 발견 응답을 수신하는 단계;
   상기 제3 발견 응답의 제2 발견 응답 데이터의 제1 서브세트를 결정하는 단계; 및
   상기 제2 발견 응답 데이터의 제1 서브세트를 저장하는 단계
   를 더 포함하는 방법.
6. 제1항에 있어서,
   상기 제1 발견 응답 데이터에서 식별되는 서비스와 관련되는 서비스 제공 엔티티의 식별자를 포함하는 메시지를 수신하는 단계- 상기 메시지는 상기 서비스 제공 엔티티가 서비스를 제공할 수 있다는 것을 나타냄 -; 및
   상기 서비스 제공 엔티티의 식별자를 포함하도록 상기 제1 발견 응답 데이터를 수정하는 것에 의해 상기 서비스 제공 엔티티의 식별자를 저장하는 단계
   를 더 포함하는 방법.
7. 제1항에 있어서,
   상기 제1 발견 응답 데이터에서 식별되는 서비스와 관련되는 서비스 제공 엔티티의 식별자를 포함하는 메시지를 수신하는 단계- 상기 메시지는 상기 서비스 제공 엔티티가 서비스를 제공할 수 없다는 것을 나타냄 -; 및
   상기 제1 발견 응답 데이터가 상기 서비스 제공 엔티티의 식별자를 포함한다고 결정하는 단계; 및
   상기 서비스 제공 엔티티의 식별자를 상기 제1 발견 응답 데이터로부터 삭제하는 단계
   를 더 포함하는 방법.
8. 접속되는 엔티티들의 네트워크에서의 네트워크 노드로서,
   컴퓨터 판독가능 명령어들을 실행하도록 구성되는 제1 프로세서; 및
   상기 제1 프로세서에 통신가능하게 연결되는 제1 메모리
   를 포함하고,
   상기 제1 메모리는, 상기 제1 프로세서에 의해 실행될 때, 상기 제1 프로세서로 하여금,
   접속되는 엔티티들의 네트워크에서의 제1 엔티티로부터 제1 발견 요청을 수신하는 단계;
   상기 제1 발견 요청을 리소스 디렉토리 엔티티에 송신하는 단계;
   상기 리소스 디렉토리 엔티티로부터 제1 발견 응답을 수신하는 단계;
   상기 제1 발견 응답에 기초하여 제1 발견 응답 데이터를 저장하는 단계;
   상기 제1 발견 응답을 상기 제1 엔티티에 송신하는 단계;
   상기 접속되는 엔티티들의 네트워크에서의 제2 엔티티로부터 제2 발견 요청을 수신하는 단계;
   상기 제2 발견 요청의 발견 요청 데이터가 상기 제1 발견 응답 데이터에 대응한다고 결정하는 단계; 및
   상기 제1 발견 응답 데이터를 포함하는 제2 발견 응답을 상기 제2 엔티티에 송신하고, 상기 네트워크 노드가 상기 제1 발견 응답 데이터를 포함하는 상기 제2 발견 응답을 상기 제2 엔티티에 송신하였음을 지시하는 통지를 상기 리소스 디렉토리 엔티티에 송신하는 단계
   를 포함하는 동작들을 수행하게 하는 컴퓨터 판독가능 명령어들을 저장하는
   네트워크 노드.
9. 제8항에 있어서,
   상기 동작들은,
   제3 발견 요청의 발견 요청 데이터가 상기 제1 발견 응답 데이터에 대응한다고 결정하는 단계; 및
   상기 제1 엔티티의 위치를 포함하는 제3 발견 응답을 상기 제2 엔티티에 송신하는 단계
   를 더 포함하는 네트워크 노드.
10. 제8항에 있어서,
    상기 동작들은,
    제3 발견 요청의 발견 요청 데이터가 상기 제1 발견 응답 데이터에 대응한다고 결정하는 단계; 및
    상기 제3 발견 요청을 상기 제1 엔티티에 송신하는 단계
    를 더 포함하는 네트워크 노드.
11. 제8항에 있어서,
    상기 동작들은,
    제3 엔티티로부터 제3 발견 응답을 수신하는 단계;
    상기 제3 발견 응답의 제2 발견 응답 데이터의 제1 서브세트가 상기 제1 발견 응답 데이터의 제1 서브세트에 대응한다고 결정하는 단계; 및
    상기 제2 발견 응답 데이터의 제2 서브세트를 포함하도록 상기 제1 발견 응답 데이터를 수정하는 것에 의해 상기 제2 발견 응답 데이터의 제2 서브세트를 저장하는 단계
    를 더 포함하는 네트워크 노드.
12. 제8항에 있어서,
    상기 동작들은,
    제3 엔티티로부터 제3 발견 응답을 수신하는 단계;
    상기 제3 발견 응답의 제2 발견 응답 데이터의 제1 서브세트를 결정하는 단계; 및
    상기 제2 발견 응답 데이터의 제1 서브세트를 저장하는 단계
    를 더 포함하는 네트워크 노드.
13. 제8항에 있어서,
    상기 동작들은,
    상기 제1 발견 응답 데이터에서 식별되는 서비스와 관련되는 서비스 제공 엔티티의 식별자를 포함하는 메시지를 수신하는 단계- 상기 메시지는 상기 서비스 제공 엔티티가 서비스를 제공할 수 있다는 것을 나타냄 -; 및
    상기 서비스 제공 엔티티의 식별자를 포함하도록 상기 제1 발견 응답 데이터를 수정하는 것에 의해 상기 서비스 제공 엔티티의 식별자를 저장하는 단계
    를 더 포함하는 네트워크 노드.
14. 제8항에 있어서,
    상기 동작들은,
    상기 제1 발견 응답 데이터에서 식별되는 서비스와 관련되는 서비스 제공 엔티티의 식별자를 포함하는 메시지를 수신하는 단계- 상기 메시지는 상기 서비스 제공 엔티티가 서비스를 제공할 수 없다는 것을 나타냄 -; 및
    상기 제1 발견 응답 데이터가 상기 서비스 제공 엔티티의 식별자를 포함한다고 결정하는 단계; 및
    상기 서비스 제공 엔티티의 식별자를 상기 제1 발견 응답 데이터로부터 삭제하는 단계
    를 더 포함하는 네트워크 노드.
15. 접속되는 엔티티들의 네트워크에서의 엔티티로서,
    컴퓨터 판독가능 명령어들을 실행하도록 구성되는 제1 프로세서; 및
    상기 제1 프로세서에 통신가능하게 연결되는 제1 메모리
    를 포함하고,
    상기 제1 메모리는, 상기 제1 프로세서에 의해 실행될 때, 상기 제1 프로세서로 하여금,
    접속되는 엔티티들의 네트워크에서의 제1 엔티티로부터 제1 발견 요청을 수신하는 단계;
    상기 제1 발견 요청을 리소스 디렉토리 엔티티에 송신하는 단계;
    상기 리소스 디렉토리 엔티티로부터 제1 발견 응답을 수신하는 단계;
    상기 제1 발견 응답에 기초하여 제1 발견 응답 데이터를 저장하는 단계;
    상기 제1 발견 응답을 상기 제1 엔티티에 송신하는 단계;
    상기 접속되는 엔티티들의 네트워크에서의 제2 엔티티로부터 제2 발견 요청을 수신하는 단계;
    상기 제2 발견 요청의 발견 요청 데이터가 상기 제1 발견 응답 데이터에 대응한다고 결정하는 단계; 및
    상기 제1 발견 응답 데이터를 포함하는 제2 발견 응답을 상기 제2 엔티티에 송신하고, 상기 제1 발견 응답 데이터를 포함하는 상기 제2 발견 응답이 상기 제2 엔티티에 송신되었음을 지시하는 통지를 상기 리소스 디렉토리 엔티티에 송신하는 단계
    를 포함하는 동작들을 수행하게 하는 컴퓨터 판독가능 명령어들을 저장하는
    엔티티.
16. 제15항에 있어서,
    상기 동작들은,
    제3 발견 요청의 발견 요청 데이터가 상기 제1 발견 응답 데이터에 대응한다고 결정하는 단계; 및
    상기 제1 엔티티의 위치를 포함하는 제3 발견 응답을 상기 제2 엔티티에 송신하는 단계
    를 더 포함하는 엔티티.
17. 제15항에 있어서,
    상기 동작들은,
    제3 발견 요청의 발견 요청 데이터가 상기 제1 발견 응답 데이터에 대응한다고 결정하는 단계; 및
    상기 제3 발견 요청을 상기 제1 엔티티에 송신하는 단계
    를 더 포함하는 엔티티.
18. 제15항에 있어서,
    상기 동작들은,
    제3 엔티티로부터 제3 발견 응답을 수신하는 단계;
    상기 제3 발견 응답의 제2 발견 응답 데이터의 제1 서브세트가 상기 제1 발견 응답 데이터의 제1 서브세트에 대응한다고 결정하는 단계; 및
    상기 제2 발견 응답 데이터의 제2 서브세트를 포함하도록 상기 제1 발견 응답 데이터를 수정하는 것에 의해 상기 제2 발견 응답 데이터의 제2 서브세트를 저장하는 단계
    를 더 포함하는 엔티티.
19. 제15항에 있어서,
    상기 동작들은,
    제3 엔티티로부터 제3 발견 응답을 수신하는 단계;
    상기 제3 발견 응답의 제2 발견 응답 데이터의 제1 서브세트를 결정하는 단계; 및
    상기 제2 발견 응답 데이터의 제1 서브세트를 저장하는 단계
    를 더 포함하는 엔티티.
20. 제15항에 있어서,
    상기 동작들은,
    상기 제1 발견 응답 데이터에서 식별되는 서비스와 관련되는 서비스 제공 엔티티의 식별자를 포함하는 메시지를 수신하는 단계- 상기 메시지는 상기 서비스 제공 엔티티가 서비스를 제공할 수 있다는 것을 나타냄 -; 및
    상기 서비스 제공 엔티티의 식별자를 포함하도록 상기 제1 발견 응답 데이터를 수정하는 것에 의해 상기 서비스 제공 엔티티의 식별자를 저장하는 단계
    를 더 포함하는 엔티티.

Images