KR20150114404A

KR20150114404A - 콘텐츠-중심 네트워크 내의 장치 등록 및 발견을 위한 시스템과 방법

Info

Publication number: KR20150114404A
Application number: KR1020150038880A
Authority: KR
Inventors: 마하데반 프리야
Original assignee: 팔로 알토 리서치 센터 인코포레이티드
Priority date: 2014-04-01
Filing date: 2015-03-20
Publication date: 2015-10-12
Also published as: EP2928117B1; US20150281376A1; EP2928117A1; JP2015197920A; CN104980484A

Abstract

본 발명의 일 실시예는 콘텐츠 중심 네트워크(content centric network, CCN) 내의 장치 등록 및 발견을 위한 시스템을 제공한다. 동작 동안, 시스템은, 컴퓨터에 의해서, 클라이언트 장치의 등록을 위한 인터레스트를 수신한다. 상기 인터레스트는 상기 클라이언트 장치와 연관된 적어도 유일한 식별자를 포함한다. 상기 인터레스트에 응답하여, 시스템은 콘텐츠 오브젝트를 생성하고, 이는 상기 클라이언트 장치에 할당된 적어도 이름을 포함하고, 그리고, 상기 콘텐츠 오브젝트를 상기 클라이언트 장치에 송신함으로써, 상기 클라이언트가 상기 CCN 내의 다른 클라이언트 장치들에 의해 발견될 수 있도록 한다.

Description

콘텐츠-중심 네트워크 내의 장치 등록 및 발견을 위한 시스템과 방법{SYSTEM AND METHOD FOR DEVICE REGISTRATION AND DISCOVERY IN CONTENT-CENTRIC NETWORKS}

본 개시는 일반적으로는 콘텐츠-중심 네트워크(CCN)에 관련된다. 좀더 상세하게는, 본 개시는 콘텐츠-중심 네트워크(CCN) 내의 장치 등록 및 발견을 위한 시스템 및 방법에 관련된다.

인터넷 및 전자 상거래의 확산은 네트워크 산업에서의 혁명적 변화를 계속해서 가속시키고 있다. 오늘날, 온라인 영화 관람부터 일간 뉴스 배달, 소비자 판매, 그리고 인스턴트 메시징에 이르기까지, 상당한 수의 정보교환이 온라인에서 수행된다. 증가하는 인터넷 어플리케이션은 또한 모바일로 되고 있다. 그러나, 현재의 인터넷은 주로 위치-기반의 어드레싱 기법(scheme)에서 동작한다. 2 개의 가장 흔한 프로토콜인, 인터넷 프로토콜(IP)과 이더넷 프로토콜은 둘다 종단-호스트 어드레스를 기반으로 한다. 즉, 콘텐츠의 소비자는 물리적 오브젝트나 위치와 전형적으로 연관되는 어드레스(예를 들면, IP 어드레스나 이더넷 미디어 접근 제어(MAC) 어드레스)로부터 콘텐츠를 명시적으로 요청함으로써 콘텐츠를 수신할 수 있을뿐이다. 제한적인 어드레싱 기법은 항상 변화하는 네트워크 수요를 충족시키기에 점점 더 부적합해지고 있다.

최근에, 정보-중심 네트워크(information-centric network, ICN) 아키텍처가 콘텐츠가 직접 명명되고 다루어지는 산업에서 제안되어 왔다. 콘텐츠-중심 네트워크(CCN)은 콘텐츠 전송에 새로운 접근 방법을 가져온다. 콘텐츠가 이동하는 엔드-투-엔드(end-to-end) 대화로서 어플리케이션 레벨에서 관찰되는 네트워크 트래픽을 갖는 대신에, 콘텐츠는 그 유일한 이름에 기초하여 요청되거나 반환되고, 그리고 네트워크는 제공자로부터 소비자로 콘텐츠를 라우팅하게 된다. 콘텐츠는, 텍스트, 이미지, 비디오 및/또는 오디오와 같은 데이터의 형식을 포함하여, 통신 시스템에서 전송될 수 있는 데이터를 포함한다는 것을 주목하라. 소비자와 제공자는 컴퓨터 주변의 사람이나 CCN 내부 또는 외부의 자동화 프로세스일 수 있다. 콘텐츠의 부분은 전체 콘텐츠나 콘텐츠의 각 부분을 참조할 수 있다. 예를 들면, 신문 기사는 데이터 패킷으로 구현되는 복수의 콘텐츠의 부분으로 표현될 수 있다. 콘텐츠의 부분은 또한 콘텐츠의 부분을 인증 날짜, 생성 날짜, 콘텐츠 소유자 등과 같은 정보로 기술하거나 증강하는 메타데이터와 연관될 수 있다.

CCN에서, 이름은 중요한 역할을 갖는다. 좀더 상세하게는, 콘텐츠 오브젝트와 인터레스트(interest)는 그들의 이름에 의해서 식별되며, 이는 전형적으로 계층적으로 구조화된 가변-길이 식별자(HSVLI)이다. 인터레스트와 콘텐츠 오브젝트는 그들의 이름에 기초하여 네트워크를 통해 흐른다. 컴퓨팅 장치가 최초에 CCN 네트워크에 합류할 때, 인터레스트 메시지를 어디로 전달해야 하는지 알아야 하며, 또한 새로운 환경 내의 기본 서비스를 획득하기 위하여 송신되어야 하는 인터레스트 메시지 내에 어떤 이름이나 이름 프리픽스가 포함될지 알아야 한다. 또한, 장치는 자신을 CCN 네트워크에 등록해야 한다.

본 실시예의 일 변형에서, 상기 인터레스트는 상기 클라이언트 장치와 연관된 공개키, 장치 타입, 장치 모델 번호 및 임의의 포맷의 장치 식별자 중의 하나 이상을 더 포함한다.

본 실시예의 일 변형에서, 상기 콘텐츠 오브젝트는 상기 클라이언트 장치에 할당된 라우팅될 수 있는 이름 프리픽스, 서브디렉토리 장치-디스커버리(device-discovery) 네임스페이스, 상기 클라이언트 장치가 데이터를 발행하기 위한 하나 이상의 네임스페이스, 그리고 선택적으로 상기 클라이언트 장치가 서명 키를 획득하기 위한 네임스페이스 중의 하나 이상을 포함한다.

본 실시예의 일 변형에서, 상기 인터레스트는 미리-결정된 이름 프리픽스를 갖는다.

다른 변형에서, 시스템은 상기 클라이언트 장치의 초기 구성 동안 상기 클라이언트 장치에게 상기 미리-결정된 이름 프리픽스를 통지한다.

다른 변형에서, 상기 미리-결정된 이름 프리픽스가 상기 클라이언트 장치의 제조자에 의해서 제공된다.

본 실시예의 일 변형에서, 시스템은 상기 할당된 이름을 사용하여 상기 클라이언트 장치를 추가함으로써 장치 데이터베이스를 갱신한다.

다른 변형에서, 시스템은 상기 CCN 내의 다른 장치들의 발견을 위한 추가적인 인터레스트를 수신한다. 상기 추가적인 인터레스트에 응답하여, 시스템은 상기 장치 데이터베이스에 저장된 정보에 기초하여 장치-리스트 콘텐츠 오브젝트를 생성하고 상기 장치-리스트 콘텐츠 오브젝트를 반환한다.

다른 변형에서, 시스템은 상기 추가적인 인터레스트를 송신하는 장치가 상기 장치-리스트 콘텐츠 오브젝트를 획득하도록 인가되었는지 여부를 결정하기 위한 보안 점검을 수행한다. 상기 추가적인 인터레스트를 송신하는 장치가 상기 장치-리스트 콘텐츠 오브젝트를 획득하도록 인가되었다는 결정에 응답하여, 시스템은 상기 장치-리스트 콘텐츠 오브젝트를 상기 인가된 장치로 송신한다.

도 1은 본 발명의 일 실시예에 따른, 네트워크 아키텍처를 보여준다.
도 2는 본 발명의 일 실시예에 따른, CCN 동적 네임스페이스 구성 프로토콜(DNCP) 클라이언트의 아키텍처를 표현하는 도면을 보여준다.
도 3은 본 발명의 일 실시예에 따른, CCN-DNCP 서버의 아키텍처를 표현하는 도면을 보여준다.
도 4는 본 발명의 일 실시예에 따른, 동적 네임스페이스 구성을 위한 서버 프로세스를 보여주는 흐름도이다.
도 5는 본 발명의 일 실시예에 따른, 동적 네임스페이스 구성을 위한 클라이언트 프로세스를 보여주는 흐름도이다.
도 6은 본 발명의 일 실시예에 따른, 장치-디스커버리 중계자의 아키텍처를 보여주는 도면이다.
도 7은 본 발명의 일 실시예에 따른, 장치-디스커버리 중계자에 의해 수행되는 장치-등록 프로세스를 보여주는 흐름도이다.
도 8은 본 발명의 일 실시예에 따른, 장치-디스커버리 중계자에 의해 수행되는 장치-디스커버리 프로세스를 보여주는 흐름도이다.
도 9는 본 발명의 일 실시예에 따른, 장치 등록 및 발견을 위한 시스템을 보여준다.
도면에서, 유사한 참조 번호는 동일한 도면 구성요소를 참조한다.

본 발명의 실시예는 CCN 내의 장치 등록 및 디스커버리를 위한 시스템 및 방법을 제공한다. 본 해결 방법은 새로운 "아웃-오브-더-박스(out-of-the-box)" 장치들이 그들의 장치를 발행하기 위하여 네트워크에 자신들을 등록하는 것을 허용하며, 그리고 현존하는 장치들이 네트워크 내에 새롭게 등록된 장치들을 발견하도록 허용한다. 또한, 만일 새로운 장치가 라우팅될 수 있는 이름 프리픽스를 갖고 있고 그리고 그 이름 프리픽스 하에 도달되려고 한다면, 해당 이름 프리픽스에 대한 적절한 인터레스트 메시지가 이 장치로 라우팅될 수 있다. 그것은 또한 하나 이상의 인가된 이름 프리픽스 하에 콘텐츠 서빙(또는 발행)을 시작할 수 있다. 좀 더 상세하게는, 장치가 새로운 "아웃-오브-더-박스"일 때, 또는 새로운 CCN 환경에 도입될 때, 초기 구성의 일부로서 등록 서비스와 장치-디스커버리 서비스의 네임스페이스를 획득한다. 연속하여, 그것은 필요한 등록 정보를 포함하는 인터레스트 메시지를 등록 서비스의 네임스페이스에 송신할 수 있다. 만일 등록 서비스가 필요한 모든 정보가 인터레스트 메시지에 의해서 제공되었다고 결정한다면, 등록 서비스는 콘텐츠 오브젝트를 장치에 반환하고, 그리고 장치 데이터베이스 내에 장치 이름 및 상기 장치 이름과 연관된 다른 정보를 포함한다. 장치는 또한 인터레스트 메시지를 장치-디스커버리 서비스의 네임스페이스로 송신할 수 있으며, 이는 콘텐츠 오브젝트를 반환한다. 반환된 콘텐츠 오브젝트는 선택적으로 네트워크 내의 모든 등록된 장치를 리스팅한다.

일반적으로, CCN은 두 가지 유형의 메시지인, 인터레스트와 콘텐츠 오브젝트를 사용한다. 인터레스트는 콘텐츠 오브젝트의 "이름"으로 불리기도 하는, 계층적으로 구조화된 가변-길이 식별자(HSVLI)를 실어나르고, 오브젝트에 대한 요청으로서 제공된다. 만일 네트워크 구성요소(예를 들면, 라우터)가 동일한 이름에 대한 복수의 인터레스트를 수신하면, 그것은 이들 인터레스트를 집합한다. 매칭 콘텐츠 오브젝트를 갖는 인터레스트의 경로를 따라서 있는 네트워크 구성요소는 상기 오브젝트를 캐싱하고 반환하여 인터레스트를 충족할 수 있다. 콘텐츠 오브젝트는 인터레스트의 기원(들)을 향하는 인터레스트의 역 경로를 뒤따른다. 콘텐츠 오브젝트는, 다른 정보들 중에도, 동일한 HSVLI, 오브젝트의 페이로드 및 HSVLI를 페이로드에 결속하도록 사용되는 암호화 정보를 포함한다.

본 개시에 사용되는 용어는 일반적으로 다음과 같이 정의된다(그러나 그들의 해석은 이에 한정되지 않는다).

"HSVLI:" 계층적으로 구조화된 가변-길이 식별자(HSVLI)이며, 또한 이름이라고 불림. 이것은 이름 컴포넌트의 정렬 리스트이며, 가변길이 옥텟(octet) 문자열일 수 있다. 인간-판독 가능한 형식에서, 이것은 ccnx:/path/part와 같은 포맷으로 표현될 수 있다. 또한, HSVLO는 사람이 읽지 못할 수 있다. 상술한 것처럼, HSVLI는 콘텐츠를 지칭하며, 이들이 콘텐츠에 대한 조직적인 구조를 표현할 수 있고 적어도 인간에게 부분적으로 의미있는 것이 바람직하다. HSVLI의 각 컴포넌트는 임의의 길이를 가질 수 있다. 또한, HSVLI는 명시적으로 구획된 컴포넌트를 가질 수 있으며, 바이트의 시퀀스를 포함할 수 있고, 그리고 인간-판독가능한 문자에 한정되지 않는다. 가장 긴-프리픽스-매칭 룩업(lookup)은 HSVLI를 갖는 패킷을 전달하는 데 있어서 중요하다. 예를 들면, "parc/home/bob" 내의 인터레스트를 나타내는 HSVLI는 "parc/home/bob/test.txt"와 "parc/home/bob/bar.txt"에 매칭할 것이다. 이름 컴포넌트의 수의 맥락에서, 매칭하는 것 중에 가장 긴 것이 제일 좋은 것으로 여겨지는데, 이는 그것이 가장 명확하기 때문이다. HSVLI의 상세한 설명은, 2009년 9월 23일에 출원된, 발명자 Van L. Jacobson과 James D. Thornton의 "SYSTEM FOR FORWARIDNG A PACKET WITH A HIERARCHICHALLY STRUCTURED VARIABLE-LENGTH IDENTIFIER"라는 제목의 미국 특허 번호 제8,160,069호에서 찾을 수 있다.

"인터레스트:" 콘텐츠 오브젝트에 대한 요청. 인터레스트는 HSVLI 이름 프리픽스를 명시하고 그리고 동일한 이름 프리픽스를 갖는 복수의 오브젝트 중에서 선택하도록 사용될 수 있는 그 밖의 옵션 선택기를 명시한다. 인터레스트 이름 프리픽스(그리고 선택적으로 발행자 키-ID 매칭과 같은 다른 필요한 파라미터)에 매칭하는 이름을 갖는 콘텐츠 오브젝트는 인터레스트를 만족시킨다.

"콘텐츠 오브젝트:" 인터레스트에 응답하여 송신되는 데이터 오브젝트. 이것은 암호화 서명을 통해 함께 결속되는 HSVLI 이름과 콘텐츠 페이로드를 갖는다. 선택에 의해서, 모든 콘텐츠 오브젝트는 상기 콘텐츠 오브젝트의 SHA-256 다이제스트(digest)로 구성되는 함축적인 단말 이름 컴포넌트를 갖는다. 일 실시예에서, 함축적 다이제스트는 유선상으로 전송되지 않으며, 필요 시, 각 홉(hop)에서 계산된다.

"페이스(face)": CCN에서, 용어 페이스는 인터페이스의 개념의 일반화이다. 페이스는 네트워크 또는 직접 어플리케이션 부분으로의 연결일 수 있다. 페이스는 특정 네트워크 인터페이스 상에 브로드캐스트나 멀티캐스트 패킷을 송신하고 수신하거나, 또는 기본 전송 내의 포인트-투-포인트(point-to-point) 어드레싱을 사용하거나 터널(예를 들면, TCP 터널)을 사용하여 패킷을 송신하고 수신하도록 구성될 수 있다. 페이스는 또한, UDP 같은 캡슐화 기법이나 OS-특정 인터-프로세스 통신 경로를 통한, 동일한 장치에서 수행되는 싱글 어플리케이션 프로세스로의 연결일 수 있다. 모든 메시지는 페이스를 통해 도착하고 페이스를 통해 송출된다.

앞에서 언급한 것처럼, HSVLI는 콘텐츠의 부분을 지시하며, 계층적으로 구조화되고, 그리고 가장 일반적인 레벨에서부터 가장 특정한 레벨로 정렬되는 인접 컴포넌트를 포함한다. 각 HSVLI의 길이는 고정이 아니다. 콘텐츠-중심 네트워크에서, 종래의 IP 네트워크와는 다르게, 패킷은 HSVLI에 의해 식별될 수 있다. 예를 들면, "abcd/bob/papers/ccn/news"는 콘텐츠의 이름일 수 있고 그리고 대응하는 패킷(들), 즉, "ABCD"라는 이름의 조직에서 "Bob"이라는 이름의 사용자를 위한 신문들의 컬렉션 "ccn"으로부터의 "news" 기사를 식별할 수 있다. 콘텐츠의 부분을 요청하기 위하여, 노드는 콘텐츠의 이름에 의해 콘텐츠 내의 인터레스트를 표현(예를 들면, 브로드캐스트)한다. 콘텐츠의 부분의 인터레스트는 콘텐츠의 이름이나 식별자에 따른 콘텐츠에 대한 이름일 수 있다. 콘텐츠는, 만일 네트워크에서 가용하다면, 상기 콘텐츠를 저장하는 노드로부터 요청하는 노드로 되 송신될 수 있다. 라우팅 인프라구조는 정보를 가지고 있을 것 같은 예상 노드로 인터레스트를 전파하고 그리고 다음으로 상기 인터레스트 메시지에 의해 횡단된 역 경로를 따라서 가용한 콘텐츠를 운반한다. 필수적으로 콘텐츠 오브젝트는 인터레스트 메시지가 남긴 자취를 따라가서, 요청한 노드에 도달한다.

도 1은 본 발명의 일 실시예에 따른, 네트워크 아키텍처를 보여준다. 본 예에서, 네트워크(180)는 노드(100-145)를 포함한다. 네트워크 내의 각 노드는 하나 이상의 다른 노드와 연결되어 있다. 네트워크 연결(185)은 이러한 연결의 예이다. 네트워크 연결은 선으로 표현되지만, 각 선은 또한 서브-네트워크 또는 한 노드를 다른 노드에 연결하는 수퍼-네트워크를 표현할 수 있다. 네트워크(180)는 콘텐츠-중심, 로컬 네트워크, 수퍼-네트워크, 또는 서브-네트워크일 수 있다. 이들 네트워크 각각은 일 네트워크 내의 노드가 다른 네트워크 내의 노드에 도달할 수 있도록 상호 연결될 수 있다. 네트워크 연결은 브로드밴드, 무선, 전화, 위성, 또는 기타 다른 유형의 네트워크 연결일 수 있다. 노드는 컴퓨터 시스템, 사용자를 표현하는 엔드-포인트, 및/또는 인터레스트를 생성하거나 콘텐츠를 만들 수 있는 장치일 수 있다.

본 발명의 일 실시예에 따르면, 소비자는 콘텐츠의 부분에 대한 인터레스트를 생성하고 상기 인터레스트를 네트워크(180) 내의 노드로 전달할 수 있다. 콘텐츠의 부분은 네트워크 내부나 외부에 위치할 수 있는 발행자나 콘텐츠 제작자에 의해서 네트워크(180) 내의 노드에 저장될 수 있다. 예를 들면, 도 1에서, 콘텐츠의 부분 내의 인터레스트는 노드(105)에서 유래한다. 만일 콘텐츠가 노드에서 가용하지 않다면, 인터레스트는 제1 노드에 연결된 하나 이상의 노드로 흘러간다. 예를 들면, 도 1 에서, 인터레스트는 노드(115)로 흘러가는데(인터레스트 흐름 150), 이것은 가용한 콘텐츠를 갖고 있지 않다. 다음으로, 인터레스트는 노드(115)로부터 노드(125)로 흘러가는데(인터레스트 흐름 155), 이는 역시 콘텐츠를 갖고 있지 않다. 다음으로, 인터레스트는 노드(130)로 흘러가는데(인터레스트 흐름 160), 이는 가용한 콘텐츠를 갖고 있다. 콘텐츠 오브젝트의 흐름은 다음으로 노드(105)에 도달할 때까지 그의 경로를 역으로 되돌리고(콘텐츠 흐름 165, 170, 그리고 175), 여기서 콘텐츠가 배달된다. 인증 같은 다른 프로세스가 콘텐츠 흐름에 포함될 수 있다.

네트워크(180)에서, 콘텐츠 홀더(노드 130)와 인터레스트 생성 노드(노드 105) 간의 경로 내의 어떤 수의 중간 노드(노드 100-145)라도, 네트워크를 횡단할 때, 콘텐츠의 로컬 사본의 캐싱(caching)에 참여할 수 있다. 캐싱은 국지적으로 캐싱된 콘텐츠로의 접근을 내재적으로 공유함으로써 다른 구독자에게 인접한 제2 구독자에 대한 네트워크 부하를 경감한다.

CCN 내의, 각 노드는 세 개의 주요 데이터 구조를 유지하는데, 이는 전달 정보 베이스(FIB), 콘텐츠 저장소(CS), 그리고 펜딩 인터레스트 테이블(PIT)을 포함한다.

FIB는 인터레스트 패킷을 매칭 콘텐츠 오브젝트의 잠재적인 소스(들)로 전달하도록 사용될 수 있다. 전형적으로, 라우팅 프로토콜은 네트워크 내의 모든 노드 간의 FIB를 채우도록 사용될 수 있다. FIB 엔트리는 종종, 매칭 인터레스트가 전달되어야 하는 적어도 하나의 페이스의 물리적 어드레스를 포함하는 각 엔트리를 갖는, 이름 프리픽스에 의해서 인덱싱될 수 있다. 인터레스트 메시지를 전달하는 동안, 이름의 가장 긴-프리픽스-매칭 룩업이 매칭 엔트리를 발견하기 위하여 FIB에서 수행된다.

콘텐츠 저장소(CS)는 IP 라우터에 의해서 사용되는 버퍼 메모리와 유사하다. 좀더 상세하게는, CS는 이 노드를 통과하는 콘텐츠 오브젝트를 일시적으로 버퍼링하면서, 상이한 소비자들에 의한 효율적인 데이터 검색을 허용한다. 라우터가 인터레스트 패킷을 수신할 때, 그것은 그의 콘텐츠 저장소에 매칭 콘텐츠 오브젝트가 있는지 여부를 우선 점검한다.

펜딩 인터레스트 테이블(PIT)은 콘텐츠 소스(들)를 향해 상향 전달된 인터레스트를 추적하여 반환된 콘텐츠 오브젝트가 그의 요청자(들)에게 다운스트림을 송신할 수 있도록 한다. CCN 내의, 오직 인터레스트 패킷만이 라우팅된다. 반환 콘텐츠 오브젝트는 콘텐츠 요청자에게 돌아가는 인터레스트 패킷의 자취를 따라간다. 인터레스트에 대한 PIT 엔트리는 인터레스트의 이름과 상기 인터레스트를 요청한 하나 또는 복수의 인커밍 페이스를 명시한다.

인터레스트 패킷이 특정 페이스에 도달할 때, 가장 긴-매칭 룩업(lookup)이 콘텐츠 이름이나 HSVLI에 기초하여 수행된다. 이름 룩업에 사용되는 인덱스 구조는 CS 매칭이 PIT 매칭보다 선호되는 방식으로 정렬되고, 이는 FIB 매칭보다 선호될 것이다. 따라서, 만일 CS 내에 인터레스에 매칭하는 콘텐츠 오브젝트가 이미 있다면, 콘텐츠 오브젝트는 인터레스트가 도달한 페이스를 통해 송출되고 인터레스트는 폐기될 것이다. 그렇지 않으면, PIT는 매칭이 발견될 수 있는지 여부를 알기 위해 점검될 것이다. 만일 그렇다면, 인터레스트의 도달 페이스는 PIT 엔트리의 요청 페이스 리스트에 추가될 것이고, 인터레스트는 폐기될 것이다. 아니면, FIB가 점검되고 인터레스트는 매칭 FIB 엔트리에 리스팅된 더 많은 페이스 중의 하나를 따라서 전달된다.

전술한 것처럼, CCN 내의, (인터레스트와 콘텐츠 오브젝트를 포함하는) 패킷은 그들의 이름 프리픽스에 기초하여 네트워크를 통해 흘러간다. 장치가 초기화될 때(최초의 시간 동안 또는 그것이 네트워크에 합류할 때), 장치는 네트워크의 다른 장치에 그의 존재를 통지해야 하고 네트워크 라우터에게 그의 페이스의 물리적 어드레스를 알려야 한다. 예를 들면, 센서(예를 들면, 온도계)가 최초로 가정에 설치될 때, 센서는 그의 데이터를 어디로 송신할 지 알 수 있도록 구성되어야 한다. 유사하게, 랩톱이나 태블릿 컴퓨터가 가정의 환경에서 커피숍으로 이동될 때, 컴퓨터는 그의 인터레스트를 어디로 송신할 지 알아야 하고, 그리고 선택적으로 네트워크 상의 다른 장치에게 그것에 도달하는 방법을 알려야 한다. 비록 초기화 동안 장치를 수작업으로 구성하는 것이 가능하지만, 현존하는 CCN 프로토콜은 자동화된 장치 초기화에 대한 해법이 없다.

현존하는 인터넷 프로토콜(IP) 네트워크에서, 동적 호스트 구성 프로토콜(DHCP)은, 인터페이스와 서비스를 위한 IP 주소와 같은, 네트워크 구성 파라미터를 동적으로 구성하도록 사용된다. 좀더 상세하게는, DHCP는 컴퓨터가 DHCP 서버로부터 자동으로 IP 어드레스와 네트워킹 파라미터를 요청하도록 허용함으로써 ,네트워크 관리자나 사용자가 설정을 수작업으로 구성할 필요를 감소시킨다. 유사한 메커니즘은, 장치가 처음으로 온라인에 출현할 때 또는 새로운 환경에 소개될 때, 장치를 초기화하기 위해서 CCN 내에서 필요하다. 좀 더 상세하게는, 장치가 CCN 네트워크에서 적절하게 기능하기 위하여, 장치는 특정 서비스를 수신하기 위한 인터레스트 패킷을 어디로 송신할 지 알아야 한다. CCN은 이름 프리픽스에 의존하여 패킷을 이동하기 때문에, 장치의 초기 구성은 네임스페이스의 구성을 포함할 것이다. 예를 들면, 장치는 FIB 내에 (하나 이상의 적절한 엔트리를 포함할 수 있는) 디폴트 전달 정보를 설정하거나, 또는 이러한 서비스에 대한 요청이 (인터레스트의 형식으로) 적절하게 전달될 수 있도록 다양한 서비스의 네임스페이스를 구성할 필요가 있다. 또한, 이 서비스를 획득하기 위하여, 장치는 적절한 인터레스트 메시지에 포함되는 이름이나 이름 프리픽스를 알아야 한다. 이들 서비스의 예는, 장치 등록, 서비스 디스커버리, 키(key)를 인가하는 인증 서비스 등을 포함하지만, 이에 한정되지 않는다.

장치 초기화에 대한 자동화 해법을 제공하기 위하여, 일부 실시예에서, 시스템은 동적 네임스페이스 구성 프로토콜(DNCP)을 구현함으로써, 예를 들면, 디폴트 전달 엔트리, 장치의 등록 및 디스커버리 서비스의 네임 스페이스 및 이름 풀이(우회) 서비스의 네임스페이스와 같은, 장치의 적절한 기능을 위해 요구되는 네임스페이스를 갖는 장치를 자동으로 구성한다. DNCP가 제대로 동작하게 하기 위하여, 다음의 조건이 충족되어야 한다는 것을 주목하라, 먼저, 각 장치는 기본 CCN 스택을 을 수행하여야 하고 CCN 인터레스트와 콘텐츠 오브젝트를 생성하고 프로세싱할 수 있어야 한다. 둘째, 장치는 수동으로 구성되거나 또는 기본 네트워크 연결을 자동을 설정할 수 있다(이는 이더넷, WiFi, 블루투스 등을 포함할 있지만 이에 한정되지 않는다). 셋 째, 각 장치는 제조사가 공급하는 유일한 장치 식별자가 제공되어야 하며, 이는 미디어 접근 제어(MAC) 어드레스와 유사하다. 이러한 장치 ID는 16이나 32 바이트 길이일 수 있고, 또는 임의의 길이일 수 있다는 것을 주목하라. 또한, 그것은 장치 제조자에 의해 정의되는 형식을 취할 수 있다. 예를 들면, 특정 제조자에 의해 제작되는 각 온도 센서는 제조자에 의해 발행된 유일한 ID를 가질 수 있다. 또한, 각 장치는 그것이 발행하고자 하는 콘텐츠 오브젝트에 서명하기 위해서, 공개-개인키 쌍, 대칭키, 또는 CCN 요구사항에 부합하는 그 밖의 서명 키와 같은, 서명 키로 미리-로딩되어야 한다. 만일 장치가 그러한 키들로 미리-구성되지 않는다면, DNCP 서비스는 장치를 적절한 서비스로 전환하여, 이 서비스의 이름을 명시함으로써 그의 키를 획득하거나 인증하도록 해야 한다.

도 2는 본 발명의 일 실시예에 따른, CCN 동적 네임스페이스 구성 프로토콜(DNCP) 클라이언트의 아키텍처를 표현하는 도면을 보여준다. 도 2에서, CCN-DNCP 클라이언트(200)는, 페이스(202, 204, 206)와 같은, 복수의 페이스, 인터레스트 생성 모듈(208), 전달 모듈(210), 수신 모듈(212), 전달 정보 베이스(FIB)(214) 및 네임스페이스 구성 모듈(216)을 포함한다.

페이스(202-206)는 물리적 인터페이스만이 아니라 패킷을 송수신할 수 있는 어플리케이션 프로세스도 포함할 수 있다. 인터레스트 생성 모듈(208)은 콘텐츠나 서비스에 대한 요청일 수 있는, 인터레스트 패킷을 생성하는 책임이 있다. 일부 실시예에서, 인터레스트-생성 모듈(208)은 "HELLO" 인터레스트 메시지를 생성하도록 구성되는데, 이는 DNCP 서비스를 요청하도록 사용될 수 있다. 다른 실시예에서, "HELLO" 인터레스트 메시지는 미리-결정된 네임스페이스 내에 생성된다. 즉, 시스템은 DNCP 목적으로 ("/hello" 같은) 네임스페이스를 미리 정의하고 보유하며, CCN-DNCP 클라이언트(200)는 이와 같은 네임스페이스로 (머신에서 동작하는 CCN 스택에 의해서) 미리 구성된다. 만일 미리-정의된 DCNP 네임스페이스가 "/hello"라면, "HELLO" 인터레스트는 네임스페이스를 "/hello"로서 갖는다는 것을 주목하라.

전달 모듈(210)은, 인터레스트나 콘텐츠 오브젝트와 같은, 패킷을 CCN-DNCP 클라이언트(200) 상의 다양한 페이스에 전달하는 역할을 한다. CCN 프로토콜에 따라서, 전달 모듈(210)은 FIB(214) 내의 엔트리를 기초로 인터레스트를 전달하고, (도 2에 도시되지 않은) PIT 내의 엔트리에 기초하여 콘텐츠 오브젝트를 전달한다. 일부 실시예에서, 전달 모듈(210)은 "HELLO" 인터레스트를 DNCP 클라이언트(200) 상의 모든 페이스에 전달(또는 브로드캐스트)하도록 구성된다. FIB(214)는 인터레스트를 전달하는 정보를 저장한다. FIB(214) 내의 엔트리는 때로는 이름 프리픽스로 인덱싱된다. 일부 실시예에서, FIB(214)는 (초기화 프로세스 동안) 디폴트 엔트리로 미리 채워질수 있으며, 전달 모듈(210)은 이들 디폴트 엔트리를 사용하여 인터레스트를 전달할 수 있다.

수신 모듈(212)은 다양한 페이스로부터 인터레스트와 콘텐츠 오브젝트를 포함하는 패킷을 수신하는 역할을 맡는다. 예를 들면, 수신 모듈(212)은 기존에 송신된 인터레스트에 응답하여 콘텐츠 오브젝트를 수신할 수 있다. 일부 실시예에서, 수신 모듈(212)은 원격 DNCP 서버로부터 "HELLO" 인터레스트에 대한 응답을 수신할 수 있다. DNCP 응답은 FIB(214)에 대한 디폴트 엔트리 및, 장치 등록 및 디스커버리, 서비스 디스커버리, 콘텐츠 이름에 대한 서명 키나 해시를 획득하기 위한 풀이 서비스, 키 서비스, 인쇄 서비스, 그리고 오늘날 사용되고 있거나 미래에 발견될 그 밖의 네트워크 서비스와 같은, 다양한 서비스에 대한 네임스페이스를 포함할 수 있지만 이에 한정되지 않는다.

FIB(214)에 대한 디폴트 엔트리는 디포트 전달자의 물리적 어드레스를 명시할 수 있으며, 이는 DMZ(비무장 지역) 라우터일 수 있고 MAC 어드레스 00:01:02:03:04:05를 가질 수 있다. 따라서, 루트 네임스페이스 "/" 내의 인터레스트는 디폴트 전달자로 전달될 수 있다. 다른 디폴트 엔트리는 로컬 라우터 및 그의 매칭 네임스페이스의 물리적 어드레스를 명시할 수 있다. 예를 들면, 추가적인 디폴트(default) 엔트리는 이름 프리픽스 "/abc"를 MAC 어드레스 12:34:56:78:9A:9B에 매핑할 수 있으며, 이는 "/abc" 네임스페이스 내의 모든 인터레스트가 MAC 어드레스 12:34:56:78:9A:9B를 갖는 페이스로 전달되어야 한다는 것을 의미한다.

네임스페이스 구성 모듈(216)은 DNCP 응답에 기초하여 CCN-DNCP 클라이언트(200) 상의 네임스페이스를 구성하는 역할을 한다. 일단 네임스페이스가 올바르게 구성되면, 인터레스트-생성 모듈(208)은 적절하게 다양한 서비스 요청을 (인터레스트의 형식으로) 생성할 수 있고, 전달 모듈(210)은 적절한 목적지로 서비스 요청을 전달할 수 있다. 예를 들면, DNCP 응답이 만일 방 2015호에 제공되는 장치-디스커버리 서비스에 대한 네임스페이스가 "/devices/room2015"라고 명시한다면, 인터레스트-생성 모듈(208)은 이름 프리픽스 "/devices/room2015"를 갖는 인터레스트를 생성할 수 있고, 전달 모듈(210)은 이름 프리픽스에 기초하여 이 인터레스트를 전달할 수 있다. 또한, 시스템은 하부구조 스키마(substructure scheme)를 사용하여 장치 유형에 기초하는 장치-디스커버리 스페이스를 정제할 수 있다. 예를 들면, 네임스페이스 "/devices/room2015/thermometers"가 방 2015호내의 모든 온도계를 발견하도록 사용될 수 있다. 다른 추가적인 네임스페이스가 또한 DNCP 응답에 포함되어서, 네임스페이스 구성 모듈(216)이 적절하게 이들 네임스페이스를 구성하도록 허용할 수 있다. 예를 들면, 네트워크는 프린터를 포함할 수 있으며, 새로운 클라이언트 장치에 대한 DNCP 응답은 프린터 서비스에 대한 네임스페이스가 "/abc/printer"라고 선언할 수 있다. 새로운 장치가 문서를 출력하려고 시도할 때, 이는 그의 인쇄 요청을 네임스페이스 "/abc/printer"에 송신할 수 있다. 네임스페이스와 연관되는 전달 정보는 FIB(214)에 저장된다는 것을 주목하라.

도 3은 본 발명의 일 실시예에 따른, CCN-DNCP 서버의 아키텍처를 표현하는 도면을 보여준다. 도 3에서, CCN-DNCP 서버(300)는, 페이스(302, 304, 306) 같은 많은 페이스, 패킷-프로세싱 모듈(308), DNCP 리스너(310), DNCP-응답-생성 모듈(312), DNCP 데이터베이스(314), 그리고 전달 모듈(316)을 포함한다.

페이스(302-306)는 페이스(202-206)와 유사하며, 물리적 인터레이스와 어플리케이션 프로세스를 포함할 수 있다. 패킷-프로세싱 모듈(308)은 다양한 페이스 상에 수신된 패킷을 프로세싱하는 역할을 한다. 일부 실시예에서, 패킷-프로세싱 모듈(308)은 수신된 패킷의 이름 프리픽스를 추출한다. 다른 실시예에서, 만일 수신된 인터레스트의 이름 프리픽스가 미리 결정된 DNCP 네임스페이스(예를 들면, "/hello" 네임스페이스) 내에 있다면, 패킷-프로세싱 모듈(308)은 인터레스트를 DNCP 리스너(310)에 전달하고, 이는 미리 결정된 네임스페이스 내의 인터레스트를 청취한다. 앞서 언급한 예에서, 미리 결정된 DNCP 네임스페이스는 "/hello"이다. DNCP 리스너(310)가 미리 결정된 DNCP 네임스페이스 내의 "HELLO" 인터레스트 메시지를 수신하면, CCN-DNCP 서버(300)는 "HELLO" 인터레스트를 수신하는 노드가 DNCP 서비스를 요청하고 있다고 결정한다. DNCP 요청에 응답하여, DNCP-응답-생성 모듈(312)은, DNCP 데이터베이스(314)에 저장된 정보에 기초하여, 콘텐츠 패킷의 형식으로, 적절한 DNCP 응답을 생성한다. DNCP 데이터베이스(314)는 디폴트 FIB 엔트리와, 장치 등록 및 디스커버리, 네트워크 서비스 디스커버리를 위한 네임스페이스, 풀이(resolution) 서비스의 네임스페이스, 키 서비스의 네임스페이스 등과 같은 다양한 네임스페이스 구성 정보를 저장한다. 장치 등록 및 디스커버리에 대한 네임스페이스는 클라이언트 장치가 등록 또는 장치-디스커버리 인터레스트 메시지를 서버에 송신하도록 허용한다. 서비스 디스커버리 네임스페이스는 클라이언트 장치가 가용한 네트워크 서비스를 발견하기 위하여 인터레스트 메시지를 송신하도록 허용한다. 풀이(resolution) 서비스의 네임스페이스는 클라이언트 장치가 발행자 키나 콘텐츠 이름의 해시를 획득하기 위하여 인터레스트 메시지를 네임스페이스에 송신하도록 허용한다. 키(key) 서비스의 네임스페이스는, 클라이언트 장치가 인증 키에 의해 미리-로딩되지 않았다면, 클라이언트 장치가 인증된 서명 키를 획득하기 위하여 인터레스트 메시지를 송신하도록 허용한다. 네트워크 환경은 시간에 따라 변하기 때문에, DNCP 응답 패킷은 각 네임스페이스에 대한 리스 시간을 선택적으로 포함함으로써, 네임스페이스가 얼마나 오랫동안 유효하게 남아있을 것인지 알릴 수 있다는 것을 주목하라. 이러한 시나리오에서, 클라이언트 장치는 DNCP 인터레스트를 주기적으로 송신하여 그들의 네임스페이스 구성이 여전히 유효하다는 것을 보장하고, 그리고 필요 시 그들의 네임스페이스 구성을 갱신해야 한다. 클라이언트 장치는 이전의 DNCP 응답을 수신했기 때문에, DNCP 인터레스트를 다시 브로드캐스팅할 필요 없이, DNCP 인터레스트를 DNCP 서비스에 직접 송신할 수 있다는 것을 주목하라.

(콘텐츠 오브젝트로서) 생성된 DNCP 응답 패킷은 전달 모듈(316)에 의해 "HELLO" 인터레스트의 인커밍 페이스로 다시 전달됨으로써 응답 패킷이 "HELLO" 인터레스트의 본래 노드로 역-전달되는 것을 보장한다.

DNCP 데이터베이스에 저장된 구성 정보가 싱글 콘텐츠 오브젝트에게는 너무 많거나, 또는 구성 정보가 복수의 섹터를 포함하고 있고, 이 중 일부는 장치 운영에 필수적이고, 이 중 일부는 선택적인 상황이 존재한다. 예를 들면, 디폴트 FIB 엔트리는 필수적인 구성 정보인 반면, 프린터 서비스는 선택적이다. 일부 실시예에서, DNCP-응답-생성 모듈(312)은 클라이언트 장치가 추가적인 구성 정보를 회득하도록 하는 명령을 포함하는 DNCP 콘텐츠 오브젝트를 생성할 수 있다. 예를 들면, 클라이언트 장치가 CCN-DNCP 서버(300)에 전달되는 제1 "HELLO" 인터레스트를 송신할 때, DNCP-응답-생성 모듈(312)은 (디폴트 FIB 엔트리와 장치 등록을 위한 네임스페이스 같은) 필수적인 구성 정보를 포함하는 DNCP 콘텐츠 오브젝트를 생성할 수 있다. DNCP 콘텐츠 오브젝트는 더 많은 DNCP 정보가 가용하다는 것을 나타낼 수 있고, 그리고 추가적인 DNCP 정보와 연관된 네임스페이스를 명시할 수 있다. 따라서, 추가적인 정보를 획득하기 위하여, 클라이언트 장치는 특정 네임스페이스에 추가적인 DNCP 요청을 송신할 수 있다. 예를 들면, 클라이언트 장치에 대한 초기 DNCP 응답은 프린팅 서비스가 이용 가능하다는 것을 지시하고, 그리고 프린팅 서비스에 대한 네임스페이스를 획득하기 위하여, 클라이언트 장치는 새로운 "HELLO" 인터레스트를 "/hello-1" 네임스페이스에 송신해야 한다. 유사하게, 만일 가용한 DNCP 정보가 복수의 콘텐츠 오브젝트를 점유한다면, 클라이언트 장치로 송신된 제1 콘텐츠 오브젝트는 클라이언트 장치가 후속하는 콘텐츠 오브젝트를 검색하기 위하여 새로운 "HELLO" 인터레스트를 "/hello-1" 네임스페이스에 송신해야 한다고 지시할 수 있다.

도 4는 본 발명의 일 실시예에 따른, 동적 네임스페이스 구성을 위한 서버 프로세스를 보여주는 흐름도이다. 동작 동안, 시스템은 미리 결정된 네임스페이스 내의 인터레스트 청취하고(동작 402), 그리고 이 네임스페이스 내의 이름 프리픽스를 갖는 미리 결정된 인터레스트가 클라이언트 장치로부터 수신되었는지 여부를 결정한다(동작 404). 예를 들면, 미리 결정된 네임스페이스는 "/hello" 같은, DNCP 네임스페이스일 수 있고, 그리고 미리 결정된 DNCP 인터레스트는 미리 정의된 "HELLO" 패킷일 수 있다. 일부 실시예에서, DNCP 네임스페이스와 "HELLO" 인터레스트의 포맷은 서버와 클라이언트 장치에서 동작하는 CCN 프로토콜에 의해 미리 구성된다.

만일 시스템이 DNCP 인터레스트를 수신하면, 시스템은 DNCP 응답을 생성하고(동작 406), 그리고 DNCP 인터레스트의 본래의 노드로 DNCP 응답을 송신한다(동작 408). DNCP 응답은 (클라이언트 장치가 그의 인터레스트를 송신할 수 있는 디폴트 페이스 같은) 디폴트 FIB 엔트리와 다양한 서비스를 위한 네임스페이스도 포함한다. 일부 실시예에서, DNCP 인터레스트는 클라이언트에 의해 요청된 서비스의 타입을 지시하고, DNCP 응답은 요청된 서비스에 기초하여 생성된다. 예를 들면, DNCP 인터레스트는 본래의 노드가 서명 키를 갖고 있지 않다고 지시할 수 있다. 응답으로, DNCP 응답은, 클라이언트는 서명 키를 획득하기 위한 인터레스트를 송신할 수 있는, 키 서비스의 네임스페이스를 포함한다.

도 5는 본 발명의 일 실시예에 따른, 동적 네임스페이스 구성을 위한 클라이언트 프로세스를 보여주는 흐름도이다. 동작 동안, 새로운 환경에 합류하거나 처음으로 온라인을 도입한 클라이언트 장치는 그의 모든 페이스 상에 DNCP 요청 메시지를 브로드캐스팅한다(동작 502). 일부 실시예에서, DNCP 요청 메시지는 미리 정의된 네임스페이스 내의 이름 프리픽스를 갖는 인터레스트 패킷이다. 미리 정의된 네임스페이스는 DNCP 서비스에 대하여 특별하게 보유된 네임스페이스일 수 있다. 예를 들면, 시스템은 DNCP 서비스에 대하여 네임스페이스 "/hello"를 보유할 수 있다. DNCP 인터레스트나 "HELLO" 인터레스트는 이름 프리픽스 "/hello"를 갖는다. DNCP 인터레스트(또는 "HELLO" 인터레스트)는 클라이언트 장치의 모든 페이스 상에 브로드캐스팅되기 때문에, DNCP 서비스는 직접 "HELLO" 인터레스트를 그의 페이스 중의 하나에 수신하거나, 또는 다른 장치에 의해 전달된 "HELLO" 인터레스트를 수신할 수 있다. 일부 실시예에서, 브리지의 태스크를 수행하거나 또는 장치들이 CCN 네트워크 내의 "HELLO" 인터레스트를 수신하거나 DNCP 서비스에 전달할 수 있도록 세팅된 전달정보를 갖는, 네트워크 환경 내의 (다른 클라이언트 장치와 같은) 다른 장치들이 존재한다.

클라이언트 장치는 다음으로 DNCP 서비스로부터 DNCP 응답 패킷을 수신한다(동작 504). DNCP 응답 패킷은 콘텐츠 오브젝트의 형식이다. 일부 실시예에서, DNCP 콘텐츠 오브젝트의 이름은 "/hello" 같은 인터레스트 메시지의 이름에 매칭한다. DNCP 콘텐츠 오브젝트는, 디폴트 FIB 엔트리와 클라이언트 장치가 필요한 서비스를 획득하기 위하여 사용할 수 있는 다양한 네임스페이스 같은, 클라이언트 장치를 구성하도록 사용될 수 있는 정보를 포함할 수 있다. DNCP 응답을 수신하면, 클라이언트 장치는 그의 FIB를 디폴트 엔트리로 채우고 그리고 그의 네임스페이스를 구성한다(동작 506). 일단 FIB가 디폴트 엔트리로 채워지고 네임스페이스가 구성되면, 클라이언트 장치는 서비스를 획득하기 위하여 적절한 이름 프리픽스를 갖는 인터레스트를 생성할 수 있다.

일부 실시예에서, DNCP 응답에 포함되는 네임스페이스는, 그들이 특정한 미리 결정된 기간 동안만 유효하다는 것을 의미하는, (하루나 열흘 같은) 리스 시간을 가지고 있다. 이러한 시나리오에서, 클라이언트 장치는 리스 시간이 만료되었는지 여부를 결정할 수 있고(동작 508), 그리고 최신의 구성 설정을 획득하기 위하여 DNCP 인터레스트를 재 송신할 수 있다(동작 502).

도 2-5에 도시된 예에서, DNCP 요청은 DNCP 서버나 서버 프로세스에 의해서 응답된다는 것을 주목하라. 실제로, 컴퓨터의 클러스터에서 동작하는 DNCP-응답 프로세스를 갖는 것도 가능하다. 무엇보다도, DNCP 인터레스트에 응답하기 위하여 CCN 네트워크 내에 다른 피어 클라이언트 컴퓨터를 가질 수 있다. 일부 실시예에서, 피어 클라이언트 머신은 재-전환 정보를 포함하는 콘텐츠 오브젝트를 갖는 DNCP 인터레스트에 응답할 수 있다. 예를 들면, 콘텐츠 오브젝트는, 요청한 클라이언트가 DNCP 요청을 송신할 수 있는, (DNCP 인터레스트의 네임스페이스와 상이한) 다른 DNCP 네임스페이스를 제공할 수 있다. 이 재-전환 콘텐츠 오브젝트는 또한 CCN 네트워크 내의 다른 클라이언트 장치의 구성 정보를 포함할 수 있다. 예를 들면, CCN 네트워크에 합류하는 클라이언트 장치는 DNCP 인터레스트를 "/hello" 네임스페이스에 송신하고, CCN 네트워크 내의 현존하는 피어 클라이언트 장치로부터 콘텐츠 오브젝트를 수신한다. 콘텐츠 오브젝트는 새로운 클라이언트 장치가 구성 정보를 획득하기 위하여 새로운 DNCP 인터레스트를 네임스페이스 "/name-abc"에 송신해야 한다는 것을 지시한다. 또한, 콘텐츠 오브젝트는 네트워크 상의 다른 피어 장치가 새로운 장치의 등록과 네트워크 상의 다른 새로운 장치의 발견을 위하여 "/device-discovery" 네임스페이스를 사용해야 한다고 명시할 수 있다.

일단 클라이언트 장치가 필요한 네임스페이스 구성 정보를 수신하면, 장치 등록 및 발견과 같은, 서비스를 획득하기 위하여 인터레스트 패킷을 적절한 네임스페이스에 송신할 수 있다. 장치의 등록은 장치가 하나 이상의 인가된 이름 프리픽스 하에 그의 데이터를 발행하기 위하여, 그리고/또는 네트워크 상의 다른 장치가 이 장치에 도달하는 것을 허용하기 위하여, 필수적이다. 더욱이, 등록은 장치가 네트워크 상에 허용되었는지 그리고 장치가 다른 인증/보안 프로세스를 필요로 하는지를 검증하는 것을 허용한다. 일부 실시예에서, 네트워크가 새로운 장치를 등록하고 발견하기 위하여, 모든 장치 등록 및 설정 서비스가 특정 네임스페이스 내의 인터레스트 메시지를 청취하도록 구성된다. 이 특정 네임스페이스는 미리-정의될 수 있고 합의될 수 있다. 등록 프로세스 동안, 새로운 장치는, 인터레스트 메시지에 포함된 장치 ID 및 장치와 연관되는 다른 정보를 갖는, 인터레스트 메시지를 이 특정 네임스페이스에 송신할 수 있다. 이들 인터레스트 메시지에 응답하도록 인가되는 서비스(예를 들면, 장치-등록 서비스나 장치-디스커버리 서비스)는 콘텐츠 오브젝트로 응답할 수 있다. 콘텐츠 오브젝트는 장치 ID를 확인하고 그의 데이터를 발행하기 위하여 장치에 의해 사용될 수 있는 추가적인 정보를 제공한다.

일부 실시예에서, 장치-디스커버리 중재자는 네트워크 내의 장치에 이름을 할당하고 장치가 그들의 데이터를 발행할 수 있는 곳에 네임스페이스를 제공한다. 그렇게 하기 위하여, 장치-디스커버리 중재자는 장치-디스커버리 네임스페이스 스키마(schema)를 관리해야하는데, 이는 다양한 유형의 장치를 표현할 수 있는 조직화된 네임스페이스 구조를 포함한다. 또한, 장치-디스커버리 중재자는 동일한 CCN 네트워크 내의 다른 장치를 발견하도록 지원한다.

장치-디스커버리 네임스페이스 스키마는 의미있는 방식으로 다양한 유형의 장치와 연관되는 네임스페이스를 조직하여 네트워크 내의 장치 발견을 용이하게 한다. 장치-디스커버리 네임스페이스 스키마를 다루는 몇 가지 기법이 있다. 한가지 옵션은 이름 프리픽스를 장치-디스커버리 네임스페이스의 루트(root) 프리픽스로서 선택하는 것이다. 예를 들면, 네임스페이스 "/devices"는 모든 장치-디스커버리 서비스에 대하여 루트 프리픽스로서 사용될 수 있다. 추가로, 서브구조 스키마는 장치 디스커버리의 영역을 더 정제하도록 사용될 수도 있다. 예를 들면, 네임스페이스 "/devices/abc/room2105"는 "/abc" 네임스페이스 내에 방 2015호의 모든 장치-디스커버리 서비스에 대한 네임스페이스 프리픽스로서 제공될 수 있다.

또한, 서브구조 스키마를 사용하여 장치 유형에 기초하여 장치-디스커버리 네임스페이스를 정제할 수 있다. 예를 들면, 네임스페이스 "/devices/abc/printers"는 "/device/abc" 네임스페이스 내의 새로운 프린터를 발견하도록 사용될 수 있고, 반면 "/devices/abc/thermometers/room2105"는 "/abc" 네임스페이스 내의 방 2015호의 온도계에 관련된 모든 장치-디스커버리 서비스에 대하여 사용될 수 있다. 네임스페이스 내의 다양한 서브구조를 어떻게 생성하고 관리하는지에 대한 결정은 장치-디스커버리 서비스에 의해서 다루어질 수 있다.

두 번째 옵션은 장치가 장치 디스커버리를 위하여 그들의 자신의 제조자-공급 네임스페이스 스키마를 갖추는 것이다. 예를 들면, "def" 회사에 의해서 제조되는 모든 장치는 "/devices/def"를 그들의 루트 프리픽스로 사용할 수 있고 그리고 특정 네임스페이스 프리픽스에 인터레스트 메시지를 송신할 수 있다. 이 루트 이름 프리픽스 상에 청취하는 장치-디스커버리 서비스는 인터레스트 메시지를 프로세싱한다.

제1 및 제2 옵션은 장치 디스커버리를 위한 미리 결정된 네임스페이스 스키마에 의존한다는 것을 알 수 있다. 즉, 장치는 장치-디스커버리 네임스페이스로 (장치 제조자에 의해서 또는 장치에서 수행되는 CCN 프로토콜에 의해서) 미리-구성되고, 그리고 인터레스트를 미리-구성된 장치-디스커버리 네임스페이스에 자동으로 송신한다.

제3 옵션은, 장치가 새로이 박스에서 꺼내어 질 때, 또는 처음으로 환경에 소개될 때, 장치-디스커버리 네임스페이스를 자동으로 구성하는 앞서 언급한 DNCP 서비스에 의존한다. 좀더 상세하게는, 장치는 DNCP 네임스페이스 내의 모든 그의 페이스 상에 "HELLO" 인터레스트를 브로드캐스팅한다. DNCP 서비스는 ("/abc/devices" 같은) 장치-디스커버리 서비스의 루트 이름 프리픽스를 명시하는 콘텐츠 오브젝트를 갖는 "HELLO" 인터레스트에 응답한다. 일단 장치가 그러한 콘텐츠 오브젝트를 수신하면, 그것은 인터레스트 메시지를 장치-디스커버리 서비스에 대한 특정 루트 이름 프리픽스로 송신한다.

도 6은 본 발명의 일 실시예에 따른, 장치-디스커버리 중계자의 아키텍처를 보여주는 도면이다. 도 6에서, 장치-디스커버리 중계자(600)는, 페이스(602, 604, 606)와 같은, 많은 페이스, 패킷-프로세싱 모듈(608), 리스너(610), 장치-등록 모듈(612), 응답-생성 모듈(614), 네임스페이스 데이터베이스(616), 장치 데이터베이스(718), 그리고 전달 모듈(620)을 포함한다.

페이스(602-606)는 페이스(202-206)와 유사하며, 물리적 인터레이스와 어플리케이션 프로세스를 포함할 수 있다. 패킷-프로세싱 모듈(608)은 다양한 페이스 상에 수신된 패킷을 프로세싱하는 역할을 한다. 일부 실시예에서, 패킷-프로세싱 모듈(608)은 수신된 인터레스트의 이름 프리픽스를 점검하여, 만일 인터레스트의 이름 프리픽스가 장치-디스커버리 네임스페이스 내에 있다면, 인터레스트를 리스너(610)에게 송신한다. 리스너(610)는, "/abc/devices" 같은, 장치-디스커버리 네임스페이스의 루트 프리픽스 상의 인터레스트 메시지를 청취한다. 장치-디스커버리 네임스페이스는 장치-디스커버리 중계자(600)에 등록할 장치에 대하여 (이름 프리픽스 "/abc/devices/registration"를 갖는) 등록 서비스를 제공하고, 그리고 장치가 네트워크 상의 다른 장치를 발견하도록 (이름 프리픽스 "/abc/devices/list"를 갖는) 디스커버리 서비스를 제공할 수 있다는 것을 주목하라, 새로운 장치는 그것이 다른 장치에 의해서 발견될 수 있기 전에 먼저 등록해야 한다는 것을 주목하라.

리스너(610)가 등록 네임스페이스 내에 인터레스트 메시지를 수신할 때, 장치-등록 모듈(612)은 인터레스트 메시지에 포함된 정보를 추출함으로써 인터레스트를 송신하는 장치를 등록한다. 일부 실시예에서, 장치 등록을 위한 인터레스트 메시지는 장치와 연관되는 다양한 정보를 포함하며, 이는 (제조자에 의해 발급되는 유일한 ID일 수 있는) 장치 ID, 콘텐츠 서명을 위하여 장치에 의해 사용되는 공개키(또는 공개키에 대한 참조), 그리고 장치의 설명을 포함하지만 이에 한정되지 않는다. 장치의 설명은 (전구 또는 온도계와 같은) 장치 유형, 모델 번호 등을 포함할 수 있다. 수신된 등록 인터레스트에 기초하여, 장치-등록 모듈(612)은 인터레스트가 등록을 위하여 요구되는 모든 정보를 포함하는지 여부를 결정한다. 만일 그렇다면, 응답-생성 모듈(614)은 "등록 확인" 콘텐츠 오브젝트를 생성한다. "등록 확인" 콘텐츠 오브젝트는 장치의 할당된 이름을 포함할 수 있고, 선택적으로 장치에 대한 라우팅될 수 있는 이름 프리픽스를 포함할 수 있다. 예를 들면, 등록된 온도계는 이름 "/thermometer-id-123"과, 그리고 선택적으로 라우팅될 수 있는 이름 프리픽스 "/abc/Room2105/thermometer-id-123"이 주어질 수 있다. 다른 장치-등록 정보가 또한 "등록 확인" 콘텐츠 오브젝트에 포함될 수 있으며, 이는 서브디렉토리 네임스페이스, 장치가 데이터를 발행하기 위한 네임스페이스(또는 장치가 발행하도록 인가된 네임스페이스), 그리고 (이미 갖고 있지 않다면) 장치가 인증키를 획득할 수 있는 인증 권한을 위한 네임스페이스를 포함할 수 있지만 이에 한정되지 않는다. 다른 실시예에서, 보안 정책에 기초하여, 일단 장치가 키 서비스로부터 (공개-개인 키 쌍 같은) 키를 획득하면, 장치는 그의 공개키를 갖는 장치 이름을 장치-디스커버리 중개자(600)에게 송신해야 할 수 있다는 것을 주목하라. 이들 네임스페이스는 네임스페이스 데이터베이스(616)로부터 획득된다. 서브디렉토리 네임스페이스는 추가적인 장치-디스커버리 서비스를 허용한다는 것을 주목하라. 예를 들면, 서브디렉토리 네임스페이스 "/devices/abc/room2105"는 네임스페이스 "/abc" 내에 방 2015 내의 장치 디스커버리를 허용한다. 데이터를 발행하기 위한 온도계에 대한 네임스페이스는 "abc/Room2105/thermometer-id-123/data"일 수 있다. 응답-생성 모듈(614)이 복수의 콘텐츠 오브젝트를 생성하는 것이 가능하고, 각각은 장치 등록 정보의 부분과 다음의 부분을 획득하기 위하여 클라이언트 장치에 의해서 사용될 수 있는 네임스페이스를 포함한다는 것을 주목하라. 즉, 콘텐츠 오브젝트의 체인은, 각 아이템이 다음 아이템의 포인터를 포함하도록, 형성될 수 있다.

만일 장치-등록 모듈(612)이 모든 필요한 정보가 제공되지 않았다고 결정한다면, 응답-생성 모듈(614)은 장치가 자신을 올바르게 등록하기 위하여 어떤 정보가 필요한 지를 명시하는 "필요한 정보" 콘텐츠 오브젝트를 생성한다. 필요한 정보는, 장치-디스커버리 중재자(600)에 의해 현재 구현되는 특정 보안 정책에 따라, 인증 정보, 키(key) 정보 등을 포함할 수 있다. 콘텐츠 오브젝트("등록 확인" 또는 "필요한 정보")는 전달 모듈(620)에 의해 장치로 반환된다.

일단 장치가 등록되면, 장치 데이터베이스(618)는 새로운 장치 이름 및 상기 새로운 장치 이름에 연관되는 등록 정보를 포함하도록 갱신된다. 장치 데이터베이스(618)는 네트워크 상의 다른 장치를 발견하는 프로세스를 용이하게 한다. 동작 동안, 리스너(610)가 ("/abc/devices/list" 같은) 디스커버리 서비스 네임스페이스 내의 인터레스트 메시지를 수신할 때, 응답-생성 모듈(614)은 장치 데이터베이스(618)에 저장된 정보에 기초하여 콘텐츠 오브젝트를 생성한다. 일부 실시예에서, 이 콘텐츠 오브젝트는 네트워크 내의 현재 등록되어 있는 모든 장치의 리스트를 포함할 수 있다. 다른 실시에에서, 적절한 인증과 암호화는 장치-디스커버리 프로세스의 일부이다. 예를 들면, 오직 특정 장치만이 모든 등록된 장치들의 리스트를 획득하도록 인가된다. 또한, 등록된 클라이언트 장치는 선택적으로 네트워크 내의 다른 클라이언트 장치에 의해서 발견되지 않도록 자신을 숨길 수 있다.

초기의 등록 및 발견에 부가하여, 클라이언트 장치는 또한 주기적인 하트비트(heartbeat) 메시지를 장치-디스커버리 중계자(600)에게 송신하여, 장치-디스커버리 중계자(600)가 네트워크 내에 모든 액티브 장치의 갱신된 현재 리스트를 유지할 수 있게 된다. 일부 실시예에서, 리스너(610)는 (초기 장치 구성 동안 장치로 배포될 수 있는) 미리 결정된 하트비트 네임스페이스 내의 인터레스트 메시지를 청취할 수 있다. 장치에 의해 송신된 하트비트 인터레스트는 장치의 할당된 이름을 포함해야 하고 그리고 장치의 키로 서명된다. 일단 리스너(listner)(610)가 그러한 주기적 하트비트 메시지를 수신하면, 응답-생성 모듈(614)은 확인 콘텐츠 오브젝트를 생성하고, 그리고 전달 모듈(620)은 확인 콘텐츠 오브젝트를 장치로 송신한다.

도 7은 본 발명의 일 실시예에 따른, 장치-디스커버리 중계자에 의해 수행되는 장치-등록 프로세스를 보여주는 흐름도이다. 동작 동안, 장치-디스커버리 중계자는 등록 서비스의 네임스페이스 상의 등록 인터레스트를 청취하고(동작 702), 그리고 등록 인터레스트가 수신되었는지 여부를 결정한다(동작 704). 만일 그렇다면, 장치-디스커버리 중계자는 장치를 올바르게 등록하기 위하여 필요한 모든 정보가 등록 인터레스트에 포함되었는지 여부를 결정한다(동작 706). 이 정보-점검 동작은 장치가 이전에 등록되었는지 여부를 결정하고, 만일 그렇다면, 등록 갱신이 필요한지 여부를 결정하는 추가적인 단계를 포함한다. 무엇보다도, 장치-디스커버리 중계자는 또한 보안 점검을 수행하여 악의적인 노드들이 자신들을 네트워크에 등록하는 것을 방지하도록 장치가 자기 자신을 등록하는 것을 인가하도록 보장한다. 만일 모든 필요한 정보가 포함되었고 그리고 장치가 보안 점검을 통과한다면, 장치-디스커버리 중재자는 등록 확인 콘텐츠 오브젝트를 생성하며, 이는 장치에 할당된 이름을 포함하고 그리고 선택적으로 라우팅될 수 있는 이름 프리픽스를 포함한다(동작 708). 라우팅될 수 있는 이름 프리픽스는 장치가 다른 장치에 의해서 도달되는 것을 허용한다는 것을 주목하라. 예를 들면, 랩톱 컴퓨터는, 장치-디스커버리 중개자로부터, 이름 "/laptop"을 수신하고, 그리고 선택적으로 라우팅될 수 있는 이름 프리픽스 "/abc/laptop"을 수신할 수 있다. 따라서, 다른 장치는 인터레스트 메시지 "/abc/laptop"을 송신함으로써 랩톱에 도달할 수 있다. 다른 장치를 발견하고, 데이터 발행하고, 그리고 서명 키를 획득하기 위하여 장치에 의해서 사용될 수 있는 추가적인 정보는 또한 등록 확인 콘텐츠 오브젝트에 포함될 수 있다. 예를 들면, 앞서 언급한 랩톱 컴퓨터("/abc/laptop")는, "abc/research/papers" 같은, 랩톱에 할당된 라우팅될 수 있는 이름 프리픽스와 상이한 하나 이상의 이름 프리픽스 하에 데이터를 발행하도록 인가될 수 있다. 데이터 발행을 위한 이 추가적인 이름 프리픽스는 또한 등록 확인 콘텐츠 오브젝트에 포함될 수 있다. 장치-디스커버리 중개자는 다음으로 그의 장치 데이터베이스를 갱신하고(동작 710), 그리고 등록 확인 콘텐츠 오브젝트를 장치에 송신한다(동작 712). 만일 필요한 모든 정보가 등록 인터레스트에 의해서 제공되지 않았다면, 장치-디스커버리 중개자는 필요한-정보 콘텐츠 오브젝트를 생성하고(동작 714), 그리고 콘텐츠 오브젝트를 장치로 되 송신하여 추가적인 정보를 요청한다(동작 716).

도 8은 본 발명의 일 실시예에 따른, 장치-디스커버리 중계자에 의해 수행되는 장치-디스커버리 프로세스를 보여주는 흐름도이다. 동작 동안, 장치-디스커버리 중계자는 디스커버리 서비스의 네임스페이스 상의 인터레스트를 청취하고(동작 802), 그리고 인터레스트 수신되었는지 여부를 결정한다(동작 804). 만일 그렇다면, 장치-디스커버리 중계자는 인터레스트가 등록된 장치의 리스트를 수신하도록 인가된 장치에 의해서 송신되었는지 여부를 결정한다(동작 806). 그와 같이 하기 위하여, 장치-디스커버리 중계자는 인터레스트 메시지에 포함된 접근 정보(예를 들면, 키, 사용자 ID, 패스워드 등)에 기초하여 보안 체크를 수행할 수 있다. 만일 장치가 보안 체크를 통과하고 장치 리스트를 수신하도록 인가되면, 장치-디스커버리 중계자는 장치 데이터베이스로부터 등록된 장치의 리스트 획득하고(동작 808), 그리고 장치 리스트를 포함하는 콘텐츠 오브젝트를 생성하고(동작 810), 콘텐츠 오브젝트를 요청하는 장치로 송신한다(동작 812). 만일 장치-디스커버리 중계자가 장치가 장치의 리스트를 수신하도록 인가되지 않았다고 결정하면, 그것은 오류 메시지를 송신한다(동작 814).

장치-디스커버리 중계자는 장치 구성과 등록을 다루는 스탠드-얼론(stand-alone)의 중앙 서버에서 수행되는 프로세스일 수 있고, 또는 머신의 클러스터에서 수행되는 분산 프로세스일 수 있다. 대안으로, 그것은 클라이언트 장치의 부분일 수 있는, 어느 머신에서 수행되는 프로세스일 수 있다. 예를 들면, CCN 네트워크 내의, 클라이언트 장치는 필요한 장치 등록 및 디스커버리 서비스를 다른 클라이언트 장치에 제공할 능력이 있을 수 있다.

도 9는 본 발명의 일 실시예에 따른, 장치 등록 및 발견을 위한 시스템을 보여준다. 장치 등록 및 디스커버리를 위한 시스템(900)은 프로세서(910), 메모리(920), 저장소(930)를 포함한다. 저장소(930)는 전형적으로 메모리(920)로 로딩될 수 있는 명령을 저장하고 상술한 방법을 수행하는 프로세스(910)에 의해서 실행될 수 있다. 일 실시예에서, 저장소(930)의 명령은 장치-디스커버리 중계자 모듈(932), 네임스페이스 데이터베이스(934), 그리고 장치 데이터베이스(936)를 구현할 수 있고, 이들 모두 다양한 수단을 통해 서로 통신할 수 있다.

일부 실시예에서, 모듈(932, 934, 936)은 부분적으로 또는 전체적으로하드웨어로 구현될 수 있고 그리고 프로세서(910)의 일부일 수 있다. 또한, 일부 실시예에서, 시스템은 별도의 프로세서와 메모리를 포함하지 않을 수 있다. 대신에, 그들의 특정 태스크의 수행에 추가하여, 모듈(932, 934, 936)은, 별도의 또는 협력하는, 범용- 또는 특수-목적 컴퓨팅 엔진의 부분일 수 있다.

저장소(930)는 프로세서(910)에 의해 실행되는 프로그램을 저장한다. 특히, 저장소(930)는 장치 등록 및 발견을 용이하게 하는 시스템(어플리케이션)을 구현하는 프로그램을 저장한다. 동작 동안, 어플리케이션 프로그램은 저장소(930)에서 메모리(920)로 로딩될 수 있고, 그리고 프로세서(910)에 의해 실행될 수 있다. 결과로서, 시스템(900)은 상술한 기능을 수행할 수 있다. 시스템(900)은 (터치스크린 디스플레이일 수 있는) 선택적인 디스플레이(980), 키보드(960), 그리고 포인팅 장치(970)에 연결될 수 있고, 그리고 또한 하나 이상의 네트워크 인터페이스를 통해 네트워크(982)에 연결될 수 있다.

본 상세한 설명에 기술되는 데이터 구조와 코드는 전형적으로 컴퓨터-판독가능한 저장 매체에 저장되며, 이는 컴퓨터 시스템에 의한 사용을 위하여 코드 및/또는 데이터를 저장할 수 있는 장치나 매체일 수 있다. 컴퓨터-판독 가능한 저장 매체는 휘발성 메모리, 비-휘발성 메모리, 디스크 드라이브 같은 자성 및 광 저장 장치, 자성 테입, CD(컴팩트 디스크), DVD(디지털 다기능 디스크 또는 디지털 비디오 디스크), 또는 현재 알려져 있거나 나중에 개발될 컴퓨터-판독가능한 미디어를 저장할 수 있는 기타 미디어를 포함할 수 있지만, 이에 한정되지 않는다.

본 상세한 설명 섹션에 기술되는 방법과 프로세스는 코드 및/또는 데이터로서 구현되어, 상술한 것처럼, 컴퓨터-판독 가능한 저장 매체에 저장될 수 있다. 컴퓨터 시스템이 컴퓨터-판독 가능한 저장 매체에 저장된 코드 및/또는 데이터를 읽고 실행할 때, 컴퓨터 시스템은 데이터 구조와 코드로서 구현되어 컴퓨터-판독 가능한 저장 매체 내에 저장된 방법과 프로세스를 수행한다.

또한, 상술한 방법과 프로세스는 하드웨어 모듈이나 장치에 포함될 수 있다. 이들 모듈이나 장치는 어플리케이션-특정 집적 회로(ASIC) 칩, 필드-프로그래머블 게이트 어레이(FPGA), 특정 소프트웨어 모듈이나 특정 시간에 코드의 부분을 실행하는 전용 또는 공유 프로세서, 그리고/또는 현재 알려지거나 추후에 개발될 그밖의 프로그래머블-로직 장치를 포함하지만, 이에 한정되지는 않는다. 하드웨어 모듈이나 장치가 활성화되면, 그들은 그들 내에 포함된 방법과 프로세스를 수행한다.

위의 설명은 본 발명이 속하는 기술분야에서 통상의 지식을 가진자가 본 실시예들을 만들고 사용하는 것을 가능하게 하도록 표현되고, 특정 응용과 요구사항의 맥락에서 제공된다. 개시된 실시예에 대한 다양한 변경이 본 발명이 속하는 분야에서 통상의 지식을 가진자에게 명백할 것이며, 여기 정의되는 일반적인 원칙은 본 개시의 정신이나 영역으로부터 벗어나지 않고 다른 실시예와 응용에 적용될 수 있다. 따라서, 본 발명은 여기 설명되는 실시예에 한정되지 않고, 다만 여기 개시되는 원칙과 특징에 일치하는 가장 넓은 영역에 일치한다.

Claims

콘텐츠 중심 네트워크(content centric network, CCN)의 장치 등록 및 탐지를 위한 컴퓨터 시스템에 있어서,
프로세서; 및
상기 프로세서에 연결되고, 상기 프로세서에 의해서 실행될 때 상기 프로세서가 방법을 수행하도록 하는 명령들을 저장하는 저장 장치를 포함하고, 상기 방법은
컴퓨터에 의해서, 클라이언트 장치의 등록을 위한 인터레스트(Interest)를 수신하는 단계로, 상기 인터레스트는 적어도 상기 클라이언트 장치와 연관된 유일한 식별자를 포함하는, 상기 수신하는 단계;
상기 인터레스트에 응답하여 콘텐츠 오브젝트를 생성하는 단계로, 상기 콘텐츠 오브젝트는 적어도 상기 클라이언트 장치에 할당된 이름을 포함하는, 상기 생성하는 단계; 및
상기 콘텐츠 오브젝트를 상기 클라이언트 장치로 송신하는 단계로, 그에 의해 상기 CCN 내의 다른 클라이언트 장치들에 의해 상기 클라이언트 장치가 탐지되는 것이 가능해지는, 상기 송신하는 단계를 포함하는, 시스템.
제1항에 있어서, 상기 인터레스트는
상기 클라이언트 장치와 연관된 공개키;
장치 타입;
장치 모델 번호; 및
임의의 포맷의 장치 식별자
중의 하나 이상을 더 포함하는, 시스템.
제1항에 있어서, 상기 콘텐츠 오브젝트는
상기 클라이언트 장치에 할당된 라우팅가능한 이름 프리픽스(prefix);
서브디렉토리 장치-탐지(device-discovery) 네임스페이스(namespace);
상기 클라이언트 장치가 데이터를 발행하는 하나 이상의 네임스페이스들; 및
상기 클라이언트 장치가 서명 키를 획득하는 네임스페이스
중의 하나 이상을 포함하는, 시스템.
제1항에 있어서,
상기 인터레스트는 미리-결정된 이름 프리픽스를 갖는, 시스템.
제4항에 있어서,
상기 방법은, 상기 클라이언트 장치의 초기 구성 동안, 상기 클라이언트 장치에 상기 미리-결정된 이름 프리픽스를 통지하는 단계를 더 포함하는, 시스템.
제4항에 있어서,
상기 미리-결정된 이름 프리픽스는 상기 클라이언트 장치의 제조자에 의해 제공되는, 시스템.
제1항에 있어서,
상기 방법은 상기 할당된 이름을 사용하여 상기 클라이언트 장치를 추가함으로써 장치 데이터베이스를 갱신하는 단계를 더 포함하는, 시스템.
제7항에 있어서, 상기 방법은
상기 CCN 내의 다른 장치들의 탐지를 위한 추가 인터레스트를 수신하는 단계;
상기 추가 인터레스트에 응답하여, 상기 장치 데이터베이스에 저장된 정보에 기초하여 장치-리스트 콘텐츠 오브젝트를 생성하는 단계; 및
상기 장치-리스트 콘텐츠 오브젝트를 반환하는 단계를 더 포함하는, 시스템.
제8항에 있어서, 상기 방법은
상기 추가 인터레스트를 송신하는 장치가 상기 장치-리스트 콘텐츠 오브젝트를 획득하도록 인가되었는지 여부를 결정하기 위한 보안 체크를 수행하는 단계; 및
상기 추가 인터레스트를 송신하는 장치가 상기 장치-리스트 콘텐츠 오브젝트를 획득하도록 인가되었다는 결정에 응답하여, 상기 장치-리스트 콘텐츠 오브젝트를 상기 인가된 장치로 송신하는 단계를 더 포함하는, 시스템.