KR20090015871A - 하이브리드 파이버 케이블 인프라스트럭처를 통한 데이터 전달을 위한 방법 및 시스템 - Google Patents

Abstract

본 발명은 콘텐트를 위해 원래 초기 목적지로 향하던 다운로드 요구를 인터셉트하는 단계, 다운로드 요구를 처리하는 단계, 로컬 캐시 내에서 콘텐트를 탐색하는 단계, 콘텐트가 로컬 캐시 내에 있으면 로컬 캐시로부터 다운로드 요구에 대한 서비스를 제공하는 단계, 콘텐트가 로컬 캐시 내에서 발견되지 않으면 다운로드 요구를 초기 목적지로 포워딩하는 단계와 인터셉트한 다운로드 요구를 서버에게 통지하는 단계를 포함하는 방법에 관한 것으로서, 서버는 콘텐트를 하나 이상의 채널을 통해 하나 이상의 클라이언트에게 전송한다. 또한, 본 발명은 클라이언트로부터의 요구를 경청하는 단계, 클라이언트로부터 콘텐트를 위해 인터셉트된 다운로드 요구를 수신하는 단계, 하나 이상의 비디오 채널 내의 이용가능 대역폭의 양을 관리하는 단계, 콘텐트를 비디오 채널에 적합한 포맷으로 캡슐화(encapsulate)하는 단계와 콘텐트를 하나 이상의 비디오 채널을 통해 하나 이상의 클라이언트에게 전송하는 단계를 포함하는 방법에 관한 것이다.

비디오 채널, 하이브리드 파이버 케이블 인프라스트럭처, 이용가능 대역폭, 로컬 캐시, 다운로드 요구

Description

하이브리드 파이버 케이블 인프라스트럭처를 통한 데이터 전달을 위한 방법 및 시스템{METHODS AND SYSTEM FOR DATA TRANSFER OVER HYBRID FIBER CABLE INFRASTRUCTURE}

<관련 출원>

본 출원은, ""Methods and System for Data Transfer Over Hybrid Fiber Cable Infrastructure"라는 명칭으로 2007년 8월 8일자 미국 가출원 번호 제60/954,580호를 우선권 주장한다.

본 발명은 피어-투-피어(P2P) 콘텐트 전달의 가속 및 HFC 네트워크를 통한 MPEG2 전송(TS) 비디오 채널과 데이터 오버 케이블 서비스(data over cable service; DOCSIS) 간의 P2P 콘텐트의 로드 밸런싱에 관한 것으로서, 보다 상세하게는, 콘텐트를 처리하여 비디오형 전송 패킷 내에 캡슐화함으로써 하이브리드 파이버 케이블 인프라스트럭처(HFC)에서 MPEG2 전송 비디오 채널 내의 이용가능 대역폭(BW)이 존재하는 기간들 동안, DOCSIS를 통해 일반적인 P2P 메시지를 효율적으로 그리고 투명하게 감시하고 처리하며 임의의 P2P 데이터(예를 들어, 텔레비전 인코딩된 미디어 콘텐트, 텔레비전 인코딩된 미디어 스트리밍, 프로그램, 운영 체제 분산 이미지 등이 있으며, 이러한 예로 한정되지 않음)를 컴퓨팅 장치들(예를 들어, 퍼스널 컴퓨터(PC), 셋톱 박스(STB), 오버 더 탑 박스(OTT) 또는 케이블 모뎀(CM)이 있으며, 이러한 예로 한정되지 않음)에 전달하고, 이를 비디오 채널을 통해 전송하고, 전송한 콘텐트를 비디오 채널로부터 추출하고 처리하며, 컴퓨팅 장치에 의한 추후 요구를 위해 콘텐트를 캐싱하도록 저장 장치가 존재하는 경우 이 저장 장치를 이용하는 시스템 및 방법에 관한 것이다.

최근에, 인터넷 트래픽 크기가 기하급수적으로 성장하였다. 연구에 의하면, 이러한 성장은 주로 P2P 네트워크를 통해 전송되는 비디오 파일에 기인한다. 또한, 비디오 콘텐트의 배포(그러나, 반드시 P2P를 통할 필요는 없음)가 인터넷 트래픽을 더 증가시킬 것으로 예상된다.

P2P 컴퓨터 네트워크는, 비교적 작은 개수의 서버들 내에 컴퓨팅 능력과 대역폭을 집중시키기보다는 네트워크의 참가자들의 컴퓨팅 능력 및 대역폭에 주로 의존하는 네트워크이다.

이러한 네트워크 장치의 모델은 통신이 일반적으로 중앙 서버로 및 중앙 서버로부터 행해지고 이에 따라 콘텐트 배포가 보다 효율적이고 강건한(robust) 방식으로 행해지는 (한 피어가 서버이고 나머지 하나의 피어가 클라이언트인 P2P 네트워크의 특별한 경우인) 클라이언트-서버 모델과 다르다.

최근의 시장 조사에 따르면 대부분의 인터넷 트래픽이 P2P 네트워크에 의해 생성된다. 게다가, P2P 콘텐트는 상당한 반복성을 띈다. 실제로, 시장 조사에 의하면 P2P 콘텐트의 최대 70%가 서로 다른 피어들에게 적어도 2번 재전송된다.

많은 P2P 프로토콜 구현예가 존재하지만, 일반적으로 P2P 트래픽은 아래와 같은 특징이 있다.

1. 다운로드된 파일들은 단편(piece)들로 형성되며, 각 단편은 자신의 고유한 설명(해시(hash), 스트링, 이름, 범위 등)을 갖는다. 단편들에 의해, 많은 피어 소스들을 이용한 다운로드 작업의 병렬화가 가능해지고 이에 따라 특히 업로드 속도가 다운로드 속도보다 느린 비대칭 네트워크에서 다운로드 속도를 가속시킬 수 있다.

2. 피어들은 자신들의 고유한 설명들에 기초하여 단편들을 거래/다운로드한다.

P2P 트래픽은 데이터 버스트 검색 및 대부분의 유휴 접속(http)과는 달리 "all that you can get" 트래픽이다. 이 사실은, BW 제한 공급 채널에서 모든 사용자의 BW 요구를 수용하도록 동일한 대역폭을 통계적 평균화에 의존하는 다수의 사용자에게 재판매하기 때문에 (스테디 스테이트 트래픽 흐름을 위해서가 아닌 트래픽 버스트용으로 설계된) 케이블 조작자 DOCSIS 채널의 사업 모델에 상당한 무게를 실어준다. P2P 트래픽의 기하급수적 성장 요인은 비용이 많은 드는 해결책(몇 개의 예를 들자면, 노드 분리(split), 스펙트럼 중첩, 보다 많은 DOCSIS 직교 진폭 변조(QAM))을 이용하여 케이블 플랜트(cable plant)를 강제로 업그레이드시키는 것이다.

게다가, 케이블 하이브리드 파이버 콕스(HFC) 플랜트에서, (DOCSIS 프로토콜로서 구현된) 네트워크 미디어는 서비스 그룹(SG) 상의 모든 사용자들 간에 공유된 다. 따라서, 항상 온(on)인 스테디 스테이트인, "all that you can get" 다운로드 서비스는, 미상관(uncorrelated) 네트워킹 요구의 통계적 영향에 악영향을 끼치고 특히 네트워크 용량의 러시 아워(통상적으로 저녁)일 때 부정적인 고객 만족을 야기시킨다. 또한, P2P 콘텐트가 상당한 반복성을 띈다는 점은 잘 알려져 있으며, 즉, 여러 사용자가 동일한 콘텐트를 다운로드한다는 점이다. 미디어가 SG 상의 모든 사용자들 간에 공유되는 동안, 접속은 개별적이며, 즉, 동일한 콘텐트가 SG 상의 다수의 사용자에게 전송되고 이러한 비효율에 대한 해결책은 현재로선 없다.

DOCSIS 채널에 대한 한 가지 해결책은 P2P 서비스들의 우선 순위를 줄이기 위해 딥 패킷 검사(Deep Packet Inspection; DPI)를 이용하는 것이다. 이것은 한편에선 다수의 고객이 실행시키고 있는 P2P 애플리케이션 만족을 줄이고 다른 한편에선 DPI가 관련이 없도록 P2P 서비스들을 숨기는 방식들을 촉진하는 효과가 있다.

다른 해결책은 스펙트럼 중첩, 아날로그 채널의 자유화, 노드 분리 등에 의해 케이블 플랜트 용량을 업그레이드하는 것이다. P2P 애플리케이션들은 "all you can get"이므로, (비록 구현하는 데 매우 많은 비용이 드는) 이 해결책은 새로운 이용가능 BW를 다시 빠르게 채울 때 P2P 트래픽에 대하여 실제적인 해결책을 제공하지는 않는다.

DOCSIS 채널들이 자신들의 BW를 SG 상의 모든 사용자들과 공유하는 동안, 채널 BW가 제공되지만 항상 사용되지는 않는 (비디오-온-디맨드(VOD)와 같은) 많은 비디오 관련 서비스들이 존재한다. 이러한 서비스들을 위해 할당된 BW는 예상되는 피크 사용 함수이며 실제로 하루 시간의 작은 일부분에만 사용된다.

게다가, 최근의 기술 흐름에 의하면, 채널들을 스위치드 서비스(switched service)(스위치드-디지털-비디오(SDV))에 할당할 수 있으며 이에 따라 이러한 특정 서비스들에 대하여 튜닝하는 사용자에 의해 그러한 할당 요구를 요구받을 때에만 채널 자신들의 BW를 브로드캐스팅하고 이용할 수 있다. 점점 더 많은 서비스가 스위치드 기술로 전이될 것으로 예상되며, 그 이유는 이 기술이 요구되지 않는 서비스를 위한 BW를 자유롭게 하고 HFC 용량을 실제로 증가시키지 않고서 더욱 많은 서비스 신청을 제공하기 위해 통계를 이용하는 기회를 제공하기 때문이다. 다시 말하면, 스위치드 서비스들이 많아질수록, 한 날의 소정의 시간대에서 이용가능한 자유로운 BW의 양도 커진다. 통상적인 현재의 HFC 설치에서는, 이러한 자유로운 BW의 양이 DOCSIS 채널에서 신청된 BW의 양의 최대 약 10배로 된다. 이러한 인자는 스위치드 서비스로의 전이가 증가함에 따라 더 성장할 것으로 예상된다. 이러한 이용가능 BW에서의 유일한 문제점은 비디오 채널들에 존재하며 현재로선 DOCSIS 채널과 비디오 채널 간의 접속이 없다는 점이다.

따라서, (VOD 채널, MPEG 전송(TS) 채널, SDV 채널을 포함하지만, 이러한 예로 한정되지는 않는) 넌(non)-DOCSIS 채널 내의 이용가능한 자유로운 BW를 사용하고 이 BW를 사용하여 최대한 노력하여 그리고 잠재적으로 P2P 트래픽을 P2P 애플리케이션에 의해 사용될 로컬 캐시로 투명하게 다시 방향 설정(redirect)시키는 시스템 및 방법이 필요하다. 이러한 시스템은, 사용자의 습관을 변경하는 것을 포함해선 안 되며(즉, 사용자들은 자신들이 선호하는 P2P 프로토콜과 함께 그리고 클라이언트를 좋아하는 경우 이 클라이언트와 함께 계속해서 작업할 것이다), P2P 메시지를 투명하게 잡고 재방향 설정된 P2P 콘텐트를 비디오 채널로부터 컴퓨팅 장치로 전달하기 위해 사용자 컴퓨팅 장치에 더하여 저 비용의 하드웨어 또는 소프트웨어를 필요로 해야 하며, http와 같은 인터랙티브 서비스를 위해 DOCSIS 채널을 자유롭게 하는 동안 P2P 콘텐트를 위한 다운로드 속도(오프라인에선 주로 다운로드 방향)의 상당한 증가를 제공해야 하며, 콘텐트의 대부분이 반복성을 띄며 콘텐트를 다수의 피어에게 한번에 전송하고(멀티캐스팅) 심지어 미래에 콘텐트를 요구할 것으로 예상되는 클라이언트들에게 그 콘텐트를 푸싱(push)한다는 사실을 이용해야 하며, 비디오 채널을 인터페이싱하고 전송된 P2P 콘텐트를 캡쳐하기 위해 HFC 플랜트에 대량 업그레이드를 관련시킨다기보다는 HFC 리소스 매니저에게 인터페이스를 이용하여 저 비용 스트리밍 서버를 추가하고 사용자 구내(premises)에서 튜닝 장치들에 대한 소프트웨어 수정을 포함해야 한다.

본 명세서에서 설명하는 바와 같은 "LibraPeer" 시스템 및 방법은, 피어 컴퓨팅 장치에서 로컬 캐시 및 넌(non) DOCSIS 채널 내의 이용가능한 자유로운 BW를 사용함으로써 DOCSIS 채널로부터 넌 DOCSIS 채널로의 투명한 P2P 트래픽 오프로딩(offloading) 및 P2P 트래픽 가속을 제공한다. 또한, 콘텐트는 다운로드하고 있는 피어의 특정 파라미터들에 따라 변경될 수 있다.

LibraPeer 시스템은 LibraPeer 클라이언트들 및 서버로 이루어진다. LibraPeer 클라이언트는 피어 컴퓨팅 장치상에서 동작하는 2개의 드라이버인 P2P 드라이버와 LibraPeer 드라이버, 및 (네트워크 접속의 소정의 종류를 통해 피어 컴퓨팅 장치에 부착된 또는 심지어 피어 컴퓨팅 장치 내부의) LibraPeer 튜닝 장치로 이루어진다. 양측 드라이버 기능성의 분리는 순수하게 논리적이며 이 드라이버들의 실제 구현에선 하나의 드라이버 또는 많은 드라이버로 될 수 있음에 주목하기 바란다. LibraPeer 서버는 케이블 구내에서 통상적으로 허브 또는 헤드엔드(Head-End)에서 동작하는 컴퓨팅 장치로 이루어진다.

LibraPeer 서버는, 피어 컴퓨팅 장치로부터 LibraPeer 클라이언트의 P2P 트래픽 요구들을 수집하고, 이들을 우선 순위화하며, 이들을 전처리하고, 전송 콘텐트를 만들고, 넌-DOCSIS 채널 상의 이용가능한 자유로운 BW를 얻기 위해 케이블 플랜트에서 리소스 관리와 인터페이싱하며, 선택된 전송 경로를 LibraPeer 클라이언트에게 통지하고, 마지막으로 넌-DOCSIS 채널 내의 이용가능한 자유로운 BW에서 콘텐트를 전송하는 것을 담당한다.

LibraPeer 드라이버는, LibraPeer 서버에 의해 통지된 특정 전송 경로 상의 LibraPeer 장치를 튜닝하고 경로에 있는 전송 멀티플렉서로부터 LibraPeer 생성 트래픽을 추출하는 것을 담당한다. 트래픽은 P2P 드라이버에 의한 잠재적인 액세스를 위해 로컬 콘텐트 캐시 상에 놓인다.

피어 컴퓨팅 장치에서의 P2P 드라이버는, P2P 트래픽을 투명하게 감시하고 인터셉트하며 이에 따라 관련 요구들 및 트래픽을 원격 피어 또는 LibraPeer 서버 및 로컬 캐시에게 다시 방향 설정하는 것을 담당한다.

피어 컴퓨팅 장치가 초기화될 때, LibraPeer 드라이버 및 P2P 드라이버는, 잠재적으로 안전한 접속(통상적으로 안전한 소켓층(SSL), 그러나 이러한 예로 한정되지 않음)으로 DOCSIS 채널을 통해 또는 다른 임의의 양방향 가능 채널(예를 들어, STB 환경에서의 아웃-오브-밴드(OOB) 채널, 그러나 이러한 예로 한정되지 않음)을 통해 LibraPeer 서버에 등록된다. 이러한 등록시, 피어 컴퓨팅 장치는 LibraPeer 클라이언트 ID 및 여러 개의 목적지 ID들을 할당받는다. 또한, 피어 컴퓨팅 장치는 LibraPeer 생성 트래픽의 설명에서 잠재적으로 사용될 소정 개수의 키들을 할당받는다. 이어서, LibraPeer 드라이버는, LibraPeer 튜너 장치((LibraPeer 생성 트래픽을 수신하도록 수정된 소프트웨어) 케이블 모뎀, DVB-C 튜너 카드, DVB-C 튜너 외부 장치, 셋톱 박스 또는 LibraPeer 생성 트래픽을 수신하는 클라이언트를 실행하는 LAN에 접속된 오버-더-탑 장치 또는 소정의 QAM 주파수를 튜닝할 수 있으며 수신된 비디오 전송 트래픽으로부터 LibraPeer 생성 트래픽을 추출할 작은 클라이언트를 실행시킬 수 있는 다른 임의의 장치를 포함하지만, 이러한 예로 한정되지는 않음)를 자동 검출한다.

일 실시예에서, P2P 애플리케이션이 메시지를 다른 P2P 엔티티에게 전송할 때, 이 메시지는 네트워크상에 전송되기 전에 P2P 드라이버에 의해 잡히고 그 메시지의 콘텐트에 대하여 분석된다. P2P 데이터를 위한 임의의 요구가 먼저 로컬 LibraPeer 캐시에서 체크된다. 히트(hit)의 경우, 이 요구는 폐기되고 P2P 애플리케이션은 로컬 LibraPeer 캐시로부터 콘텐트를 수신한다. 미스(miss)가 검출되는 경우, 즉, 콘텐트가 로컬 LibraPeer 캐시 내에 존재하지 않는 경우, 요구는 자신의 초기 목적지로 포워딩된다. 또한, LibraPeer 서버는 요구 특성을 통지받는다. 다른 일 실시예에서, P2P 드라이버는 본 명세서에서 설명하는 본 발명의 이점들을 활용하도록 특히 설계된 P2P 애플리케이션 내에 임베딩된다.

LibraPeer 드라이버는 LibraPeer 서버에 의해 발행되는 임의의 전송 통지를 항상 경청한다. 전송 통지는 일반적으로 QAM 주파수 및 LibraPeer 목적지 ID로 이루어진다(그러나, 이러한 예로 한정되지는 않는다). 이러한 전송이 통지될 때마다, LibraPeer 드라이버는 LibraPeer 튜너 장치를 통지된 주파수에 튜닝하고 등록 단계에서 수신되는 목적지 ID들 중 하나와 일치하는 LibraPeer 목적지 ID를 갖는 LibraPeer 생성 트래픽을 (전송 패킷 트래픽으로부터) 추출한다. 이어서, 트래픽은 복호화되고, 잠재적으로 처리된다(이러한 처리의 일례로는, 영화 파일 내에 타겟 광고의 삽입 또는 기존의 광고를 다른 방식을 통해 피어에게 특히 전송된 다른 광고로 대체, 워터마크 삽입, 암호화 및 복호화, 등이 있다). 이어서, 콘텐트는 인덱싱되고 로컬 LibraPeer 캐시 내에 배치된다.

LibraPeer 서버는 DOCSIS 채널을 통해 행해진 LibraPeer P2P 클라이언트로부터의 요구를 항상 경청한다. 또한, 이 서버는, 넌-DOCSIS QAM 내에 존재하는 자유로운 BW의 양을 감시하고, 케이블 플랜트의 리소스 매니저를 인터페이싱하고 트래픽을 새로운 비디오 세션의 형태로 전송하고 모든 트래픽이 변조되기 전에 (일반적으로 인터넷 프로토콜(IP) 패킷 형태로) 이 모든 트래픽을 수신하며 패킷들의 소정 유형들의 이용가능한 BW을 LibraPeer 생성 트래픽으로 대체하고 이를 변조기에 출력하는 등을 포함하는 다양한 방법들에 의해 LibraPeer 생성 트래픽을 삽입하며, 이러한 방법들로 한정되지는 않는다.

LibraPeer 서버는 (P2P 스트리밍 트래픽에 대한 보다 높은 우선 순위와 같은) 기저 트래픽의 성질, 다양한 프리미엄 계정, 이용가능한 자유로운 BW와 같은 다양한 케이블 조작자 통계 등을 포함하는 수많은 기준들에 따라 요구들의 서비스 제공에 대하여 우선 순위를 제공하지만, 이러한 예로 한정되지는 않는다.

LibraPeer 생성 트래픽을 LibraPeer 튜너 장치에 전송하기 전에, LibraPeer 서버는 튜닝 주파수, 서비스 ID, 목적지 ID 등을 포함하는 트래픽이 추출되어야 하는 방식을 LibraPeer 드라이버에게 통지하지만, 이러한 예로 한정되지는 않는다. 이 통지는 일반적 IP 오버 DOCSIS 채널, LibraPeer 생성 메시지의 형태인 기구성 비디오 채널, OOB 채널 또는 다른 임의의 다운링크 채널을 포함하는 채널을 통해 전송되지만, 이러한 예로 한정되지는 않는다.

LibraPeer 서버는, 특정한 멀티캐스트 목적지 ID를 이용함으로써 동일한 트래픽을 (그 트래픽을 요구하진 않았지만 미래에 요구할 가능성이 큰, 즉, P2P 요구 를 서빙하는 것과는 대조적으로 P2P 트래픽을 푸싱하는 클라이언트를 포함하는) 다수의 LibraPeer 튜너 장치들에게 전송하는 것을 결정할 수 있고 이에 따라 특히 유명한 P2P 콘텐트의 전송시 전송 효율을 더 향상시킬 수 있다. 이러한 콘텐트 푸싱은 피어 선호의 클라이언트 상에 또는 서버상에 구축된 프로파일에 따라 더 행해질 수 있다.

전술한 개요의 관점에서 볼 때, 본 명세서에서 설명하는 LibraPeer 시스템이 P2P 트래픽 캐시 및 멀티캐스팅 푸싱을 이용함으로써 DOCSIS 채널로부터 넌-DOCSIS 채널로 투명한 P2P 트래픽 오프로딩 및 P2P 트래픽 가속을 제공하기 위한 고유한 시스템 및 방법을 제공한다는 점은 명백하다. 방금 전술한 이점들에 더하여, LibraPeer 시스템의 다른 이점들은 첨부 도면과 함께 이하의 상세한 설명으로부터 명백해질 것이다.

본 발명의 특정한 특징들, 양태들 및 이점들은 다음에 따르는 설명 및 첨부 도면을 참조하여 보다 잘 이해될 것이다.

본 발명에 의하면, P2P 콘텐트의 전송 효율을 향상시킬 수 있다.

본 발명의 바람직한 실시예의 다음에 따르는 설명에서는, 본 발명의 일부이며 본 발명이 실시될 수 있는 특정 실시예들을 예시적으로 도시하고 있는 첨부 도면을 참조한다. 본 발명의 범위로부터 벗어나지 않고서 다른 실시예들을 활용할 수 있으며 구조적 변경을 행할 수 있음을 이해할 수 있다.

본 발명은, 콘텐트를 위해, 원래 초기 목적지로 향하던 다운로드 요구를 인터셉트하는 단계와, 다운로드 요구를 처리하는 단계와, 로컬 캐시 내에서 콘텐트를 탐색하는 단계와, 콘텐트가 로컬 캐시 내에 있으면 로컬 캐시로부터 다운로드 요구에 대한 서비스를 제공하는 단계와, 콘텐트가 로컬 캐시 내에서 발견되지 않으면 다운로드 요구를 초기 목적지로 포워딩하는 단계와, 인터셉트한 다운로드 요구를 서버에게 통지하는 단계를 포함하는 방법에 관한 것이고, 여기서 서버는 콘텐트를 하나 이상의 채널을 통해 하나 이상의 클라이언트에게 전송한다.

또한, 본 발명은 클라이언트로부터의 요구를 경청하는 단계와, 클라이언트로부터, 콘텐트를 위해 인터셉트된 다운로드 요구를 수신하는 단계와, 하나 이상의 비디오 채널 내의 이용가능 대역폭의 양을 관리하는 단계와, 콘텐트를 비디오 채널에 적합한 포맷으로 캡슐화하는 단계와, 콘텐트를 하나 이상의 비디오 채널을 통해 하나 이상의 클라이언트에게 전송하는 단계를 포함하는 방법에 관한 것이다.

1. 예시적인 동작 환경

본 발명은 적어도 3개 파트로 이루어지는데, 즉, 통상적으로 케이블 조작자 구내 내에 위치하는 LibraPeer(LP) 서버와, 통상적으로 최종 사용자 구내에서의 컴퓨팅 장치 내에 위치하는 2개의 LibraPeer 드라이버와, 통상적으로 최종 사용자 구내에 위치하는 튜닝 장치이다.

도 1은 본 발명의 일부를 구현할 수 있는 적합한 컴퓨팅 시스템 환경(100)의 일례를 도시한다. 컴퓨팅 시스템 환경(100)은 단지 적합한 컴퓨팅 환경의 일례이며 본 발명의 기능성이나 사용 범위에 임의의 제한을 가하려는 것이 아니다. 컴퓨 팅 시스템 환경(100)을, 예시적인 동작 환경(100)에 예시한 구성요소들의 임의의 하나 또는 조합에 관한 임의의 종속성이나 요구 사항을 갖는 것으로서 해석해선 안된다.

본 발명은 수많은 다른 범용이나 전용 컴퓨팅 시스템 환경 또는 구성에서 동작가능하다. 본 발명과 함께 사용하는 데 적합할 수 있는 잘 알려져 있는 컴퓨팅 시스템, 환경, 및/또는 구성의 예로는, 퍼스널 컴퓨터, 서버 컴퓨터, 핸드헬드, 랩탑이나 이동 컴퓨터 또는 셀폰 및 PDA와 같은 통신 장치, 멀티프로세서 시스템, 마이크로프로세서 기반 시스템, 셋톱 박스(STB), 오버-더-탑 박스(OTT), 프로그래밍가능 전자 제품, 네트워크 PC, 미니컴퓨터, 메인프레임 컴퓨터, 전술한 시스템이나 장치 중 임의의 것을 포함하는 분산 컴퓨팅 환경 등이 있지만, 이러한 예로 한정되지는 않는다.

본 발명의 일부는, LibraPeer 튜너 장치(115)의 컴포넌트들을 포함하는 하드웨어 모듈과 조합하여 컴퓨터에 의해 실행되는 프로그램 모듈과 같은 컴퓨터 실행가능 명령어의 일반적인 문맥으로 설명될 수 있다. 일반적으로, 프로그램 모듈은, 특정한 작업을 수행하거나 특정한 추상 데이터 유형을 구현하는, 루틴, 프로그램, 오브젝트, 컴포넌트, 데이터 구조 등을 포함한다. 또한, 본 발명은 통신 네트워크를 통해 링크된 원격 처리 장치들에 의해 작업들이 수행되는 분산 컴퓨팅 환경에서 실시될 수 있다. 분산 컴퓨팅 환경에서, 프로그램 모듈은 메모리 저장 장치를 포함하는 로컬 및 원격 컴퓨터 저장 매체 둘 다에 위치할 수 있다. 도 1을 참조해 보면, 본 발명을 구현하기 위한 예시적인 시스템은 컴퓨터(103)의 형태인 범용 컴 퓨팅 장치를 포함한다.

컴퓨터(103)의 컴포넌트들은, 처리 유닛(104), 시스템 메모리(102), 시스템 메모리를 비롯한 다양한 시스템 컴포넌트들을 처리 유닛(104)에 연결하는 시스템 버스(108), 비휘발성 메모리(101), 오디오 인터페이스(105), 키보드(112), 입력/출력 인터페이스(111)를 통해 접속된 마우스(113) 또는 다른 임의의 포인팅 장치, 모니터(107) 또는 비디오 인터페이스(106)를 통해 접속된 텔레비전, 프로제거 등을 비롯한 다른 임의의 관찰 장치를 포함할 수 있지만, 이에 한정되지는 않는다.

컴퓨터(110)는 원격 컴퓨터(118)와 같은 하나 이상의 원격 컴퓨터에 대한 논리적 접속부를 이용하여 네트워크화 환경에서 동작할 수 있다. 원격 컴퓨터(118)는, 퍼스널 컴퓨터, 서버, 라우터, 네트워크 PC, 피어 장치, 또는 다른 공통 네트워크 노드일 수 있으며, 통상적으로 컴퓨터(103)에 대하여 전술한 요소들 중 많은 부분 또는 전부를 포함한다. 도 1에 도시한 논리적 접속부는 WAN(117)을 포함하지만, LAN과 같은 다른 네트워크를 포함할 수도 있다. 이러한 네트워킹 환경은 가정, 사무실, 전사적 컴퓨터 네트워크, 인트라넷, 인터넷에서 흔하다.

WAN 네트워킹 환경에서 사용될 때, 컴퓨터(103)는 통상적으로 모뎀(114)을 포함한다. 모뎀(114)은, 내장형 또는 외장형일 수 있으며, 네트워크 인터페이스(110) 또는 다른 적절한 메커니즘을 통해 시스템 버스(108)에 접속될 수 있다. 도시한 네트워크 접속부들이 예시적이며 컴퓨터들 간의 통신 링크를 확립하는 다른 수단들을 이용할 수 있음을 인식할 것이다.

LibraPeer 서버는 일반적으로 전술한 것(122)과 유사한 컴퓨터상에서 실행되 는 컴퓨터 실행가능 명령어로 이루어지지만 서버 활동성의 일반적인 범위로부터 벗어나지 않고서 다른 임의의 구현예도 가능하다.

이제 예시적인 동작 환경을 설명하였으며, 본 명세서의 나머지 부분은 DOCSIS 채널로부터 비디오 채널로의 투명한 P2P 트래픽 오프로딩 및 P2P 트래픽 가속을 제공하는 LibraPeer 시스템을 구현하는 프로그램 모듈 및 프로세스에 대해서 설명한다.

2. 도입

본 명세서에서 설명하는 바와 같은 LibraPeer 시스템 및 방법은, 콘텐트를 멀티캐스팅하고 피어 컴퓨팅 장치 내에 존재하는 로컬 캐시 내에 푸싱하기 위해 스위치드 비디오 채널 내의 이용가능한 자유로운 BW를 이용함으로써, P2P 애플리케이션 레벨에서 또는 P2P 애플리케이션 레벨 아래에서 P2P 트래픽 처리, DOCSIS 네트워크로부터 MPEG2 TS 네트워크로의 P2P 트래픽 오프로딩, 및 P2P 트래픽 가속을 제공한다.

본 명세서에서 설명하는 바와 같은 LibraPeer는 P2P 네트워크에서 사용하는 데 적용가능한 한편 당업자라면 LibraPeer에 의해 제시되는 전술한 시스템 및 방법이 (비디오-온-디맨드와 같이) 임의의 P2P 네트워크의 일부가 아니며 주로 비대칭 트래픽 특성에 의해 특징지워지는 콘텐트 및 미디어 배포와 같은 다른 많은 사용에 적용가능하다는 것, 즉, 주로 사용자 구내 컴퓨팅 장치 내로의 다운로드로 이루어진다는 것을 이해할 것이라는 점에 주목하기 바란다. 이러한 잠재적으로 제시되는 서비스는 콘텐트를 LibraPeer 서버 내에 두고 그 콘텐트를 위해 요구를 인터셉트하 며 (반드시 P2P 애플리케이션으로부터의 콘텐트일 필요는 없음) LibraPeer (오프 DOCSIS) 경로 및 캐시를 통해 이들에게 서비스를 제공한다.

일반적으로, LibraPeer는 도 2에 도시한 네트워크와 같은 P2P 네트워크에서 동작한다. 피어(202)들은 단편 위치에 관한 이전의 지식에 따라 파일들의 단편들을 거래한다. 하나의 P2P 네트워크 예(BitTorrent 네트워크)에서, 이러한 지식은 중앙 컴퓨팅(트랙커) 장치(203)에 의해 이용가능할 수 있으며 다른 임의의 피어(202)에 의해 배포/풀링/갱신될 수 있다. 파일의 소정의 단편을 요구하는 피어(202)들은 다른 피어들로부터 직접적으로 그렇게 요구한다. 피어-투-피어 통신이 선택 사항이며 다른 P2P 프로토콜에서 피어들이 중앙 서버들로부터 콘텐트의 단편들을 다운로드할 수 있다는 점에 주목하기 바란다. 이러한 모든 P2P 통신은, 허브/헤드엔드(210)로부터 발생하는 HFC 세그먼트(213) 상의 모든 피어들에 의해 공유되는 전용 DOCSIS 채널을 통해 실행되는 DOCSIS 데이터 프로토콜을 통해 행해진다. 콘텐트 흐름의 대부분이 반복성을 띄며 동일한 콘텐트가 모든 요구 피어들에게 별도로 전송된다는 사실을 이용하는 방식이 현재로선 존재하지 않는다. 또한, 많은 BW P2P 콘텐트는 DOCSIS 채널을 채우고 웹 브라우징과 같은 인터랙티브 활동성을 위한 이용가능 BW처럼 고객 만족을 줄인다.

동시에, 스위치드 채널들 대부분(VOD, 스위치드-디지털-비디오(SDV) 서비스 등, 그러나 이러한 예로 한정되지는 않음)은 부분적으로 미사용되어 있지만, 이들이 DOCSIS 채널의 일부가 아니므로, DOCSIS 채널 상의 P2P 애플리케이션에 의해 야기된 BW 로드를 경감하는 데 사용될 수 없다.

LibraPeer는 이러한 이슈들을 모두 해결한다. LibraPeer P2P 드라이버(즉, 일반적으로 컴퓨팅 장치 네트워크 스택에서 P2P 메시지를 생성하는 P2P 애플리케이션의 레벨보다 하위 레벨(303)에서 동작하지만, 보다 높은 레벨에서 동작할 수도 있음)는, P2P 메시지를 투명하게 감시하고 인터셉트하며, 이 메시지를, 다른 피어들에게 포워딩하거나 자신의 로컬 캐시(510)로부터 서비스 제공하는 것을 결정한다. 또한, 이것은 현재 다운로드 및 이들의 상태(511)의 LibraPeer 서버를 갱신하여 관련 콘텐트를 프리페치함으로써 미래의 요구에 대하여 준비할 수 있다. 로컬 캐시는 LibraPeer(LP) 드라이버(518)에 의해 전송되는 소정의 우선 순위(519) 상태에 따라 LibraPeer 서버에 의해 갱신(516)되고 있다. LibraPeer 드라이버는, LibraPeer 생성 트래픽이 전송되는 비디오 TS 채널들, DOCSIS 채널, 및 P2P 드라이버가 로컬 캐시로부터 콘텐트를 수신하고 있는 그 로컬 캐시 간의 결함을 보완하는 것을 담당한다. 또한, 이것은 로컬 캐시의 상태를 LibraPeer 서버에게 통지하는 것 뿐만 아니라 로컬 캐시를 관리하는 것을 담당한다.

3. 시스템 아키텍처

전술한 프로세스들은 도 4의 일반적 시스템 도에 의해 도시되어 있다. 특히, 도 4의 시스템 도는 전술한 바와 같이 LibraPeer를 구현하기 위한 프로그램 (그리고 가능하다면 하드웨어) 모듈 간의 상호 관계를 도시하고 있다.

3.1 LibraPeer 클라이언트

3.1.1 2P 및 LibraPeer 드라이버

일반적으로, P2P(422) 및 LibraPeer(419) 드라이버는, 사용자의 요구에 의해 또는 시스템 로딩을 동작시키는 컴퓨팅 장치(421)의 일부로서 디폴트로 로딩된다. 로딩되면, P2P 드라이버는 (가능하다면, 애플리케이션(420) 레벨에서 또는 애플리케이션 레벨 아래에서 네트워킹 스택의 층들 중 하나 내에 후크 또는 필터를 삽입함으로써) 컴퓨팅 장치의 네트워킹 경로를 인터페이싱한다(514). 필터는, 예를 들어, 모든 네트워킹 메시지들이 인터셉트되도록 마이크로소프트 윈도우 환경 내에 전송 드라이버 인터페이스(TDI) 필터를 포함하지만, 이러한 예로 한정되지는 않는다. 다른 일 실시예에서, P2P 드라이버는 스스로 고유한 애플리케이션이며 콘텐트 다운로드 서비스를 독립적인 방식으로 제공할 것이다. P2P 및 LibraPeer 드라이버는 자신들을 LibraPeer 서버에 등록하며, 적어도 클라이언트 ID 및 적어도 하나의 목적지 ID 및 잠재적으로 다른 파라미터들(암호화/복호화 키, 워터마크 등을 포함하지만, 이러한 예로 한정되지는 않음)을 수신한다. 클라이언트 ID는 메시지의 소스를 식별하도록 기능을 하며 목적지 ID는 서버로부터 클라이언트들에게로 흐르는 콘텐트의 목적지를 결정하도록 기능을 한다. 이어서, 양측 드라이버들은 인터럽트 구동 상태를 입력한다. 인터럽트는 LibraPeer 하드웨어(414) 장치를 통해 비디오 채널로부터 도달하는 LibraPeer 생성 트래픽, DOCSIS(418)를 통해 다른 네트워크 엔티티들에게 전송된 P2P 애플리케이션(420)으로부터의 P2P 메시지를 포함하지만, 이러한 예로 한정되지는 않는다.

투명한 동작을 위해, LibraPeer P2P 드라이버는 일반적으로 전송층보다 높지만 애플리케이션층보다 낮은 커널 모드로 로딩된다(하지만, P2P 드라이버가 P2P 애플리케이션 아래의 어떠한 레벨에서도 동작할 수 있으며 여전히 투명한 P2P 메시지 처리를 제공하고 이에 따라 본 발명의 주요 사상으로부터 벗어나지 않는다는 점을 당업자라면 이해할 것이다). 이 층에서, 소켓층(302)으로부터의 모든 통신이 수신되고 감시된다. P2P 트래픽 특징들(소정의 P2P 프로토콜을 특징짓는 문자들의 특별한 시퀀스, 다른 P2P 프로토콜을 특징짓는 http 요구 및 다른 임의의 특징적 콘텐트 다운로드 요구를 포함하지만, 이러한 예로 한정되지는 않음) 중 임의의 것의 검출시, P2P 드라이버는 접속 특성(예를 들어, 목적지 IP 어드레스 및 포트 번호가 있지만, 이에 한정되지는 않음)에 주목하고 P2P 관련 메시지들을 경청하기 시작한다. P2P 드라이버가 P2P 파일 단편 요구 또는 임의의 콘텐트 다운로드 요구를 검출할 때, 캐시 히트(hit)를 위해 로컬 캐시 콘텐트(423)를 먼저 체크한다. 히트가 존재하는 경우, 단편은 로컬 캐시(423)로부터 서비스 제공되고 요구는 폐기된다. 미스인 경우, 메시지는 하위층으로 포워딩되고 이에 따라 초기 목적지로 포워딩된다. 다른 일 실시예에서, P2P 드라이버는 전술한 바와 같이 P2P 드라이버 서비스에 더하여 콘텐트 다운로드 및 업로드 서비스를 제공하는 애플리케이션 층에서 실행되는 독립적 애플리케이션으로 이루어진다.

본 발명의 일부 실시예에서, 데이터가 애플리케이션 레벨로 복귀되기 전에 국부적으로 처리된다는 점에 주목하기 바란다. 이러한 처리는, 예를 들어, 잠재적으로 개인화된 광고 삽입 또는 비디오, 게임 등을 포함하는 콘텐트 유형의 대체이지만, 이러한 예로 한정되지는 않고, 다른 처리들은 일부 이전 단계에서 수신된 키에 따른 콘텐트의 복호화 및 암호화, 워터마킹 등이지만, 이러한 예로 한정되지는 않는다. 본 명세서에서 설명한 바와 같은 LibraPeer가 HFC 네트워크에서 사용하는 데 적합하지만, 당업자라면 LibraPeer P2P 드라이버에 의해 제시된 전술한 콘텐트 처리 실시예가 무선, ADSL 등을 포함하는 다른 네트워크에 적용가능하지만, 이러한 예로 한정되지 않는다는 점에 주목하기 바란다.

LibraPeer 드라이버는, 검사되고 처리될 LibraPeer 생성 트래픽이 존재할 때마다 LibraPeer 튜너 장치 하드웨어(414)에 의해 인터럽트된다. 정확한 행동 방식은 LibraPeer 하드웨어 장치에 의해 결정된다. 수정된 케이블 모뎀(415)에서, LibraPeer 드라이버에 대한 인터페이스는 일반적인 이더넷 네트워크 인터페이스(110)이며, 그 이유는 CM 수정이 DOCSIS 레벨에서만 행해지기 때문이다. LibraPeer 생성 트래픽은 LibraPeer 드라이버에게 이더넷 프레임 내에 캡슐화된 일반적인 UDP/TCP/Raw로서 전송된다. 실제로, 동일한 인터페이스는 비디오 채널로부터 LibraPeer 생성 트래픽을 추출하여 이를 LibraPeer 네트워킹 층(310 내지 312)에 의해 처리될 네트워크 인터페이스(110)를 거쳐 UDP/TCP/Raw를 통해 LibraPeer 튜닝 드라이버에 전송하는 LibraPeer 클라이언트를 실행하는 STB 119,416을 이용하여 사용된다. DVB-C 튜너(417)는 일반적으로 채널 TS 트래픽을 컴퓨팅 장치 메모리(102)로 직접 추출한다. LibraPeer 튜너 장치는, 이 경우, 수신된 TS 트래픽으로부터 LibraPeer 생성 트래픽을 추출하고 로컬 콘텐트 캐시를 LibraPeer 생성 데이터로 갱신한다.

3.1.2 LibraPeer 튜닝 장치 하드웨어

일반적으로, LibraPeer 드라이버는 (통상적으로 DOCSIS 채널(418)에서 일반적인 암호화된 TCP 접속부를 통해) LibraPeer 서버 메시지를 경청하고 LibraPeer 튜닝 장치 하드웨어(414)를 그 특정한 주파수로 튜닝한다. LibraPeer 튜닝 장치 하드웨어는, 특정한 주파수 채널에서 모든 데이터를 캡쳐하고 판독하는 DVB-C 튜너(417), 및 소프트웨어 수정된 케이블 모뎀(415)으로 이루어질 수 있다(소프트웨어 수정이 필요한 이유는, 넌-DOCSIS 채널을 통해 LibraPeer 생성 트래픽이 전송되고 일반적인 CM은 채널로 튜닝될 수 있기 전에 다양한 DOCSIS 관련 동작들을 수행할 필요가 있기 때문이다). CM이 넌-DOCSIS 채널로 튜닝되고 그 채널로부터 모든 정보를 추출하기 위해, DOCSIS 관련 단계들(예를 들어, CMTS에 등록 배치)을 스킵(skip)하고 소정의 주파수로 튜닝할 수 있고 수신된 트래픽을 캡슐화하며 필요 시 이를 컴퓨팅 장치에 전송하는 특별한 소프트웨어, 또는 LibraPeer 드라이버로부터 소정의 채널 주파수에 튜닝하라는 커맨드를 수용하는 작은 소프트웨어를 갖는 셋톱 박스는, 전송 패킷들을 추출하고, 이어서 일부 이더넷 프레이밍(예를 들어, UDP/TCP 및 미가공이 있으며, 이러한 예로 한정되지는 않음)으로 캡슐화하고, 다양한 네트워킹 층(312, 311, 310)들을 통해 처리되도록 LibraPeer 드라이버에 전송한다. 방금 설명한 일반적인 사상으로부터 벗어나지 않고서 비디오 채널로부터의 여분의 데이터를 활용하고 구조적 변경을 행할 수 있음을 이해할 수 있다.

튜닝되는 그 주파수부터 LibraPeer 하드웨어가 판독하는 데이터는 일반적으로 701의 형태인 전송 스트림이다. 이어서, LibraPeer 하드웨어는 LibraPeer 생성 트래픽(515)을 경청하고, LibraPeer 콘텐트 단편의 시작을 시그널링하는 (제어 비트(704)에 존재하는) 페이로드 유닛 시작 인디케이터(PUSI), 유니캐스트(특정 클라이언트에게 전송되는 경우) 또는 멀티캐스트(콘텐트가 다수의 클라이언트에게 전송 되는 경우)일 수 있는 목적지 ID(709)를 포함하는 전송 패킷들로부터 판독하는 다양한 비트들에 따라 LibraPeer 생성 트래픽(LibraPeer ID를 갖는 TS 패킷(704))을 추출하지만, 이러한 예로 한정되지는 않는다.

종래의 QAM 장치(413)를 통해 LibraPeer 생성 트래픽을 전송하기 위해 필요한 PCR 필드(705)를 포함한 다양한 추가 필드들이 처리되거나 폐기될 수 있다는 점에 주목하기 바란다.

본 발명의 범위로부터 벗어나지 않고서 다른 실시예들(예를 들어, 비디오 채널을 통해 알려져 있는 프로토콜의 전송 스트림 형태가 아닌 실시예들, 그러나 이에 한정되지 않음)을 활용하고 구조적 변경을 행할 수 있다는 점을 이해할 수 있다.

콘텐트 ID(711) 및 단편 설명(712)에 따라 LibraPeer 데이터(709)가 추출되고(713) 로컬 저장 장치(516) 캐시(423)에 저장된다. 단편 설명은, 예를 들어 P2P 스트리밍을 위해 콘텐트가 사용되는 경우 전체 다운로드된 파일 또는 타이밍 파라미터들로부터의 단편의 범위를 포함할 수 있다.

일반적인 키프 어라이브(keep-alive; 517) 및 콘텐트 캐시 상태(518) 통지가 LibraPeer 서버에 전송된다.

3.2 LibraPeer 서버

LibraPeer 콘텐트 저장 장치(409)는 콘텐트 수집(ingesting), 태깅 및 전처리 모듈(403)에 의해 항상 갱신된다. 이 모듈은 (통상적으로 매우 넓은 접속부를 통해 접속되는) WAN(401)으로부터 요구된 콘텐트를 프리페치하고 캐싱하며, LibraPeer 클라이언트 내로의 푸싱을 위해 콘텐트의 로컬 주입(예를 들어, 클라이언트 드라이버에서 추구 광고 삽입을 위해 전처리될 수 있음)을 가능하게 한다. 또한, 이 모듈은 자신의 작업들 중 임의의 작업을 지원할 임의의 외부 엔티티를 인터페이싱할 수 있다. 또한, 이 모듈은 콘텐트 배포가 쉽도록 통상적으로 콘텐트를 콘텐트 배포 전에 배치할 수 있다.

일 실시예에서, 콘텐트 수집, 태깅 및 전처리 모듈(403)은, 요구된 콘텐트가 비디오 콘텐트로 이루어져 있음을 검출할 때마다, 트랜스코딩, 해상도 변경, 프레임 속도 변경, 및 전송된 콘텐트를 채널 순간 특성들(예를 들어, 이용가능 BW) 중 하나 이상으로 조절함으로써 BW 제한 채널을 통해 LibraPeer 클라이언트에 대하여 콘텐트 스트리밍을 지원할 임의의 다른 전처리를 포함하는 일련의 단계들로 콘텐트를 전처리하지만, 이러한 예로 한정되지는 않는다.

LibraPeer 서버(424)는 클라이언트 요구 메시지(702)를 경청한다. 모든 클라이언트 요구는 세션 DB(408)에 로깅된다(log).

주기적인 간격(519)으로, 우선순위화 모듈(409)은, 모든 클라이언트 요구를 검사하고, 인기(popularity), 긴급성(실시간 스트리밍 또는 넌-인터랙티브 다운로드), 크기, 요구하는 클라이언트 서비스 등급(프리미엄, 일반 등), (피어들에게 배포되도록 지불되는 파일과 같은) 다양한 사업 관련 합의서와 같은 단편 특징들과 같은 특정 파라미터들에 따라 그 요구들을 분류하지만, 이러한 예로 한정되지는 않는다. 이어서, LibraPeer 전송, 우선순위화 및 스케쥴링 모듈(404)은 일 실시예에서 가장 긴급한 요구를 취하고, 리소스 매니저(405)를 인터페이싱하며, 다른 일 실 시예에선 스트리머(407)를 인터페이싱하며 (임의의 지속 기간일 수 있는) 다음 전송 시간 슬라이스 동안 이용가능한 자유로운 BW의 양을 계산한다. LibraPeer 전송, 우선순위화 및 스케쥴링 모듈(404)은, 예를 들어, 이용가능한 BW에 기초하여, 클라이언트에게 요구의 전처리된 버전을 전송하는 것을 결정할 수 있다. 이어서, 이 모듈은 LibraPeer 저장 장치(409)로부터 취해진 LibraPeer 전송 패킷 트래픽(701) 및 관련 콘텐트(709)의 각각의 전송을 스케쥴링한다(520).

전송 항목은 통상적으로 LibraPeer 드라이버와의 TCP (또는 UDP, 미가공 이더넷 IP 메시지와 같은 다른 임의의 프로토콜을 포함하지만, 이러한 예로 한정되지는 않음) 접속을 거쳐 일반적인 DOCSIS 채널을 통해 관련 클라이언트들에게 LibraPeer 메시지(714)로 전송된다. 이어서, LibraPeer 서버는 LibraPeer 생성 트래픽을 적절한 자유로운 BW 채널(413) 내로 스트리밍한다(407).

4. LibraPeer 의 동작 항목

4.1 데이터 요구의 등록 및 응답

모든 인터랙티브 LibraPeer 등록 및 서버로부터 클라이언트로 그리고 그 반대로의 메시지 전달은 일반적인 DOCSIS 채널을 통해 또는 OOB를 통해 행해지며, 그 이유는 양방향 채널(업로드 및 다운로드)을 요구하지만 일반적으로 많은 BW를 소모하지 않기 때문이다.

LibraPeer 서버로부터의 데이터 전달 응답은, 목적지 튜너를 타겟팅하는 데 사용되는 어드레싱 태그를 갖는 (이용가능한 BW가 존재하는 경우) 비디오 채널을 통해 행해진다. 이 트래픽은 일반적으로 높은 BW와 다운로드 방향만을 갖는다.

피어 사이를 흐르는 메시지는, 콘텐트 암호화 또는 DRM을 비롯한 추가 이점을 위해, 변경될 수 있으며, 이러한 예로 한정되지는 않는다.

일 실시예에서, 콘텐트는 LibraPeer 서버에서 암호화 상태로 유지되고 복호화는 보다 이른 단계에서 전송된 키를 이용하여 LibraPeer 드라이버에서 행해진다. 이러한 실시예에서, 콘텐트 제공자는 사용자들의 콘텐트의 클리어 버전에 액세스할 수 있는 그 사용자들을 더 제어한다. 이러한 한 가지 제어는 LibraPeer 드라이버에서 콘텐트를 복호화하고 워터마크를 잠재적으로 삽입하는 것이다. 콘텐트가 다른 피어에 의해 요구되면 그리고 워터마킹된 피어에 의해 서비스 받으면, 콘텐트 워터마크는 제거되며 그 다른 피어에게 전송되기 전에 다시 암호화된다.

다른 실시예에서, (예를 들어, BitTorrent 프로토콜의 경우 .torrent 파일과 같이) 콘텐트 요구를 설명하는 메시지 또는 기타 임의의 유사한 메타데이터는, LibraPeer 서버에 의해 추후에 전송될 콘텐트의 변경된 버전을 반영하기 위해 LibraPeer P2P 드라이버를 그대로 두는 동안 변경될 수 있다. 이러한 변경은 이러한 실시예에서 요구되며, 그 이유는 잠재적으로 P2P 애플리케이션이 요구된 메타데이터(해시 스트링을 포함하지만, 이러한 예로 한정되지는 않음)와 수신된 실제 (변경된) 콘텐트 간의 일치를 요구하기 때문이다.

4.2 LibraPeer 전송

비디오 채널 내의 이용가능 BW는 여러 소스들로부터 할당될 수 있다. 즉, 이러한 한 소스는 통상적으로 스위치드 서비스를 위해 할당된 모든 QAM BW를 제공하고 요구시 이용가능한 BW를 인가할 수 있는 스위치드-디지털-비디오 장치 내에 존재하는 리소스 매니저(405)이다. 다른 방법은, 비디오 트래픽(VOD)을 포함하며, 심지어 브로드캐스트 비디오 채널을 포함함)을 버퍼링하고 NULL이나 다른 TS 패킷들로 대체하는 것이다. 또 다른 방식은 에지 장치를 모방하고 여러 개의 단일 프로그램 전송 스트림(SPTS)으로부터 에지 장치에 전달될 수 있는 다중 프로그램 전송 스트림(MPTS)(LibraPeer 생성 트래픽을 하나 이상의 SPTS 서비스로서 포함함)을 생성하는 것이다.

(즉, 모든 도출된 복잡성이 있는 DOCSIS 변조기 뿐만 아니라) 비디오 전송 채널이 존재하는 변조기들의 이점을 활용하기 위해, LibraPeer 생성 트래픽은 비디오 전송 트래픽으로서 위장된다. 일반적으로, 에지 QAM(413)은 트래픽을 물리적 HFC 라인에 스트리밍하는 데 이용되는 비트율(BR)을 계산하기 위해 프로그램 클록 기준(PCR)을 이용한다. 비디오 TS 트래픽을 에뮬레이션하기 위해, PCR가 규칙적인 간격(통상적으로 밀리초의 10분의 1마다)으로 LibraPeer 전송 패킷 내에 삽입되며 LibraPeer 생성 트래픽이 전송되는 BR에 따라 리스탬핑된다(restamped).

LibraPeer 스트림을 에지 QAM에 전송할 가능성이 없는 경우(VOD 서버가 직접적으로 변조되고 에지 QAM 또는 멀티플렉싱 장치로부터 흘러나오며 이용가능한 BW를 갖는 브로드캐스트 채널들에 의해 전송될 미리 구축된 비디오 채널 멀티플렉서를 제공하는 경우를 포함하지만, 이에 한정되지는 않음), LibraPeer 생성 트래픽은 패킷 대체 기술에 의해 삽입될 수 있다. 이 방법에서, 비디오 소스(406)로부터 발생하는 모든 트래픽은 적은 고정 시간 지연을 겪게 되는 LibraPeer 콘텐트 스트리머(407) 내로 전달된다. 이러한 시간 지연 동안, 404로부터 발생하는 LibraPeer 생성 트래픽은 초기 비디오 스트림 대신에 또는 초기 비디오 스트림에 더하여 삽입될 수 있다. 프로그램 특정 정보(PSI) 패킷과 같은 추가 스트림 특징(그러나 이러한 예로 한정되지는 않음)을 갱신하여 새로운 서비스(비디오 서비스 내에 어떠한 간섭도 발생하지 않도록 LibraPeer 생성 트래픽을 새로운 서비스 내의 사설 데이터로서 설정하는 것을 포함하지만, 이러한 예로 한정되지는 않음)의 추가를 반영해야 한다는 점에 주목하기 바란다.

통상적으로 서버는, 이용가능한 BW를 감시하고, 로드 밸런싱하며, 모든 비디오 채널들 내의 자유로운 BW를 충분히 활용하기 위해 이용가능한 BW를 갖는 모든 비디오 채널들 간의 LibraPeer 생성 트래픽을 위해 리소스 매니저(405)와 협상한다.

도 6은 애플리케이션이 이용될 수 있는 바람직한 일 실시예의 이점들을 제공한다. 이것은, 비디오 채널(607)들이 대부분 미사용중인 동안 레거시 HFC 네트워크에서 P2P가 DOCSIS 채널(604)을 어떻게 채우는지를 알 수 있다. LibraPeer를 이용하게 되면, P2P 트래픽 메시지들은 컴퓨팅 장치(606)에서 투명하게 잡히고 전처리되며 케이블 조작자 구내(premise; 601)에 위치하는 LibraPeer 서버에 전송된다. (예를 들어, P2P 콘텐트는 콘텐트 제공자에 의해 푸싱된 다소 빠른 단계에서 캐싱되었거나 심지어 이용가능 형태의 콘텐트를 갖는 다른 엔티티로부터 요구되었으므로) 케이블 조작자 구내에 존재하는 P2P 콘텐트의 일부는 캡슐화된다. 존재하는 P2P 콘텐트의 일부는 비디오 채널들이 미사용중인 동안 LibraPeer 생성 트래픽 내에 캡슐화되고 비디오 채널(612)들을 통해 전송된다(이에 따라 보다 적은 다운로드 특징들을 갖는 다른 많은 인터랙티브 애플리케이션을 위해 DOCSIS 채널들을 자유롭게 하는 동안 피어에겐 이용가능한 BW가 훨씬 더 많아진다). LibraPeer 튜닝 장치(611), 또는 LibraPeer 튜닝 드라이버(613)를 갖는 STB는 LibraPeer 생성 트래픽을 픽업하고, 이 트래픽을 처리하며(즉, 이 트래픽을 콘텐트 개인화 및 타겟 광고를 포함하는 피어에 잠재적으로 적응시키며, 이러한 예로 한정되지는 않음), 이 트래픽을 로컬 캐시 내에 배치되도록 또는 즉시 사용되도록 컴퓨팅 장치(606) 내에서 실행되는 P2P 애플리케이션에 투명하게 전달한다.

LibraPeer에 대한 위 설명은 단지 예시 및 설명을 위해 제시되었다. 이러한 설명은 본 발명을 개시된 특정 형태로 제한하거나 철저히 하려는 것이 아니다. 이러한 교시에서 볼 때 많은 수정 및 변동이 가능하다. 게다가, 전술한 대체 실시예들 중 임의의 실시예 또는 전부를 필요한 임의의 조합으로 이용하여 LibraPeer의 하이브리드 실시예들을 추가로 형성할 수 있다는 점에 주목하기 바란다.

도 1은 본 명세서에서 설명하는 바와 같이 "LibraPeer"를 구현하는 예시적인 시스템을 구성하는 범용 컴퓨팅 장치를 도시하는 일반적인 시스템 도면이다.

도 2는 본 명세서에서 설명하는 바와 같이 콘텐트 다운로드를 위한 예시적인 피어-투-피어(P2P) 네트워크를 도시한다.

도 3은 본 명세서에서 설명하는 바와 같이 "LibraPeer"를 구현하기 위한 프로그램 모듈들을 도시하는 예시적인 아키텍처 도면이다.

도 4는 LibraPeer 및 P2P 드라이버 환경을 나타내는 아키텍처 시스템 도면이다.

도 5는 본 명세서에서 설명하는 바와 같이 LibraPeer의 일 실시예의 일반적인 동작을 도시하는 흐름도이다.

도 6은 본 발명을 실시할 수 있는 특정 일 실시예에서의 이점을 도시한다.

도 7은 LibraPeer 서버 및 클라이언트 간의 통신에 사용되는 몇 개의 포맷을 도시한다.

<도면의 주요 부분에 대한 부호 설명>

101 비휘발성 메모리 102 시스템 메모리

103 컴퓨터 104 처리 유닛

105 인터페이스 111 입력/출력 인터페이스

202 피어 203 중앙 컴퓨팅 장치

303 P2P 드라이버 309 LibraPeer 튜닝 장치

414 LibraPeer 튜닝 장치 419 LibraPeer 튜닝 드라이버

Claims (42)

1. 콘텐트를 위해, 원래 초기 목적지로 향하던 다운로드 요구를 인터셉트하는 단계;

   상기 다운로드 요구를 처리하는 단계;

   로컬 캐시 내에서 상기 콘텐트를 탐색하는 단계;

   상기 콘텐트가 상기 로컬 캐시 내에 있으면 상기 로컬 캐시로부터 상기 다운로드 요구에 대한 서비스를 제공하는 단계;

   상기 콘텐트가 상기 로컬 캐시 내에서 발견되지 않으면 상기 다운로드 요구를 상기 초기 목적지로 포워딩하는 단계; 및

   인터셉트한 다운로드 요구를 서버에게 통지하는 단계를 포함하고,

   상기 서버는 상기 콘텐트를 하나 이상의 채널을 통해 하나 이상의 클라이언트에게 전송하는 방법.
2. 제 1 항에 있어서,

   애플리케이션 레벨에서 또는 애플리케이션 레벨 아래에서 컴퓨팅 장치 내의 네트워크 스택 경로를 인터페이싱하는 단계를 더 포함하는 방법.
3. 제 1 항에 있어서,

   상기 다운로드 요구를 상기 초기 목적지로 포워딩하는 단계는 데이터 오버 케이블 서비스(Data Over Cable Service; DOCSIS) 채널을 통해 수행되는 방법.
4. 제 1 항에 있어서,

   상기 서버로부터 상기 콘텐트를 수신하는 단계;

   상기 서버로부터 수신한 상기 콘텐트를 처리하는 단계; 및

   상기 콘텐트를 상기 로컬 캐시 내에 두는 단계

   를 더 포함하는 방법.
5. 제 1 항에 있어서,

   상기 콘텐트 및 다운로드 요구는 P2P 애플리케이션 유형에 속하는 방법.
6. 제 1 항에 있어서,

   상기 콘텐트 및 상기 다운로드 요구 중 하나를 전처리하는 단계

   를 더 포함하는 방법.
7. 제 1 항에 있어서,

   콘텐트 목적지, 키, 기타 피어 관련 정보로 이루어지는 그룹 중 하나에 따라 상기 콘텐트 및 상기 다운로드 요구 중 하나를 변경하는 단계를 더 포함하는 방법.
8. 제 1 항에 있어서,

   상기 처리하는 단계는 하나 이상의 비디오 프레임의 대체 및 광고 삽입을 포함하는 방법.
9. 제 1 항에 있어서,

   상기 처리하는 단계는 상기 콘텐트의 암호화 또는 복호화를 포함하는 방법.
10. 제 1 항에 있어서,

    상기 로컬 캐시는 저장 장치 상에 저장되는 방법.
11. 제 1 항에 있어서,

    상기 로컬 캐시는 메모리 장치 상에 있는 방법.
12. 제 1 항에 있어서,

    상기 방법은 튜닝 동작과 동시에 실행되도록 구성된 방법.
13. 제 12 항에 있어서,

    상기 튜닝 동작과 상기 방법은 단일 컴퓨팅 장치 상에서 수행되는 방법.
14. 제 12 항에 있어서,

    상기 튜닝 동작과 상기 방법은 서로 다른 컴퓨팅 장치들 상에서 수행되는 방 법.
15. 제 14 항에 있어서,

    상기 서로 다른 컴퓨팅 장치들은 유선 네트워크를 통해 통신하는 방법.
16. 제 15 항에 있어서,

    상기 유선 네트워크는, 이더넷(Ethernet), 파이어와이어(Firewire), 이더넷 오버 파워라인(Ethernet over power line), 직렬, 병렬로 이루어지는 그룹 중에서 선택되는 유형에 속하는 방법.
17. 제 14 항에 있어서,

    상기 서로 다른 컴퓨팅 장치들은 무선 네트워크를 통해 통신하는 방법.
18. 제 17 항에 있어서,

    상기 무선 네트워크는 802.11b/g/n, Wimax, HSPA, UMTS, GSM, 인피니밴드(Infiniband), 블루투스(Bluetooth)로 이루어지는 그룹 중에서 선택되는 유형에 속하는 방법.
19. 클라이언트로부터의 요구를 경청하는 단계;

    상기 클라이언트로부터, 콘텐트를 위해 인터셉트된 다운로드 요구를 수신하 는 단계;

    하나 이상의 비디오 채널 내의 이용가능 대역폭의 양을 관리하는 단계;

    상기 콘텐트를 비디오 채널에 적합한 포맷으로 캡슐화(encapsulate)하는 단계; 및

    상기 콘텐트를 하나 이상의 비디오 채널을 통해 하나 이상의 클라이언트에게 전송하는 단계를 포함하는 방법.
20. 제 19 항에 있어서,

    상기 관리 단계는 상기 하나 이상의 비디오 채널 내의 상기 이용가능 대역폭의 양을 감시하는 단계를 포함하는 방법.
21. 제 19 항에 있어서,

    상기 콘텐트는 전처리되고 채널 대역폭에 적응되는 방법.
22. 제 19 항에 있어서,

    상기 콘텐트 및 다운로드 요구는 P2P 애플리케이션 유형에 속하는 방법.
23. 제 19 항에 있어서,

    미래의 요구들을 보다 양호하게 추정하기 위해 과거 피어 요구들을 프로파일링하는 단계를 더 포함하는 방법.
24. 제 19 항에 있어서,

    피어가 미래 요구들을 위해 자신의 프로파일을 수동적으로 구성할 수 있는 방법.
25. 제 19 항에 있어서,

    상기 하나 이상의 클라이언트에게 전송 항목을 통지하는 단계를 더 포함하는 방법.
26. 제 25 항에 있어서,

    상기 통지 단계는, 데이터 오버 케이블 서비스(DOCSIS), 아웃 오브 밴드(OOB), 비디오로 이루어지는 그룹 중에서 선택되는 채널 유형을 통해 실행되는 방법.
27. 제 19 항에 있어서,

    보다 효율적인 후 전송 처리(post-transmission processing)가 가능하도록 상기 콘텐트를 전처리하는 단계를 더 포함하는 방법.
28. 제 27 항에 있어서,

    상기 전처리 단계는 빠른 광고 삽입이 가능하도록 상기 콘텐트를 적응시키는 단계를 포함하는 방법.
29. 제 27 항에 있어서,

    상기 전처리 단계는 기존의 광고를 다른 광고로 빠르게 대체할 수 있도록 상기 콘텐트를 적응시키는 단계를 포함하는 방법.
30. 제 27 항에 있어서,

    상기 전처리 단계는, 하나의 슬라이스를 다수의 슬라이스로 분할하는 단계, 움직임 벡터를 검사하여 포인팅 타겟을 찾는 단계, 인터 매크로 블록을 인트라 매크로 블록으로 변환하는 단계로 이루어지는 그룹 중 적어도 하나를 포함하는 방법.
31. 제 19 항에 있어서,

    상기 콘텐트가 비디오 포맷을 갖는 경우 상기 콘텐트를 전처리하는 단계와,

    상기 콘텐트의 서로 다른 해상도들, 프레임율들, 비트율들, 기타 비디오 인코딩 파라미터들을를 갖는 다수의 버전을 생성하는 단계

    를 더 포함하는 방법.
32. 제 31 항에 있어서,

    상기 전송 채널 내의 이용가능 대역폭에 따라 다수의 버전 중 적어도 하나를 전송하는 단계를 더 포함하는 방법.
33. 제 31 항에 있어서,

    디스플레이에 따라 다수의 버전 중 적어도 하나를 전송하고 서로 다른 타겟들의 기능들을 처리하는 단계를 더 포함하는 방법.
34. 제 19 항에 있어서,

    다수의 클라이언트 요구를 유지하는 단계를 더 포함하는 방법.
35. 제 34 항에 있어서,

    콘텐트 유형, 긴급성, 다양한 사용자 계정 레벨, 이용가능 대역폭으로 이루어지는 그룹 중 하나에 따라 선택된 콘텐트 버전 및 다수의 클라이언트 요구에 대한 서비스 제공의 우선 순위 부여 단계를 더 포함하는 방법.
36. 제 19 항에 있어서,

    상기 하나 이상의 비디오 채널 중에서 상기 콘텐트의 전송을 로드 밸런싱(load balance)하는 단계를 더 포함하는 방법.
37. 제 19 항에 있어서,

    프로그램 클록 기준(Program Clock Reference; PCR)을 삽입하고, 프로그램 특정 정보(Program Specific Information; PSI)를 갱신하고, 일반적인 비디오 에지 직교 진폭 변조(QAM)를 통해 상기 콘텐트를 전송함으로써, 상기 콘텐트가 일반적인 비디오 콘텐트처럼 작용하도록 상기 콘텐트를 전처리하는 단계를 더 포함하는 방법.
38. 제 37 항에 있어서,

    상기 전처리된 콘텐트는 일반적인 미수정 셋톱 박스(STB)에 의해 보이도록 구성되는 방법.
39. 제 19 항에 있어서,

    상기 전송 단계는 비디오-온-디맨드(VOD) 또는 스위치드-디지털-비디오(SDV) 세션으로서 수행되는 방법.
40. 제 19 항에 있어서,

    상기 전송 단계는 유형에 기초하여 소정의 패킷들을 기존의 멀티플렉스로 대체함으로써 수행되는 방법.
41. 제 19 항에 있어서,

    상기 콘텐트는 다수의 클라이언트에게 전송되는 방법.
42. 제 19 항에 있어서,

    하나 이상의 클라이언트가 나중에 요구할 것으로 상기 서버가 예상하는 콘텐트를, 상기 하나 이상의 클라이언트에게 전송하는 단계를 더 포함하는 방법.

Images