KR101973590B1

KR101973590B1 - 트래픽 스케줄링을 이용하는 네트워크 대역폭 규제

Info

Publication number: KR101973590B1
Application number: KR1020147013944A
Authority: KR
Inventors: 루이스 피. 슬로토우버
Original assignee: 포스월 미디어, 인코포레이티드
Priority date: 2011-10-25
Filing date: 2012-10-25
Publication date: 2019-04-29
Also published as: EP2772020A1; US9577899B2; JP2014531179A; WO2013063218A1; CA2851825A1; US20150207707A1; EP2772020B1; US8937866B2; EP2772020A4; US20130100810A1; KR20140091019A; CA2851825C; JP5982002B2

Abstract

네트워크 트래픽을 모니터링하고, 네트워크 로드들을 예측하며, 트래픽 보고 및 대역폭 예약 메커니즘들을 활용하여 트래픽을 스케줄링함으로써 네트워크 대역폭을 규제하기 위한 시스템들 및 방법들이 본원에 개시된다. 이들 시스템들 및 방법들은 네트워크 혼잡을 감소시킬 수 있으며 네트워크 애플리케이션들에 의한 더 효율적인 프로세싱을 지원할 수 있다. 트래픽 보고는 메시지들을 송신하고 수신하기 위해 적절한 시간들을 표시하는 제어 메시지들을 네트워크 코드들에 브로드캐스팅하는 것을 포함할 수 있다. 네트워크 노드들은 네트워크의 이용을 사전적으로 규제하기 위해 트래픽 보고들(예를 들어, 제어 메시지들)을 이용할 수 있다. 대역폭 예약은 데이터를 송신하고 수신하도록 대기하면서 네트워크 노드들이 생산적인 프로세싱을 행하게 허용할 수 있으며, 평균 대기 시간들을 감소시킬 수 있다. 예약들은 동기 또는 비동기 방식으로 구현될 수 있다. 예시적인 실시예에서, 예약 메커니즘은 전통적인 스트림 소켓 API를 에뮬레이트할 수 있다. 대역외 네트워크들에서 케이블 TV를 통해 더 효율적으로 실행하기 위해 강화된 TV 애플리케이션들을 가능하게 하는 실시예들이 설명된다.

Description

트래픽 스케줄링을 이용하는 네트워크 대역폭 규제{NETWORK BANDWIDTH REGULATION USING TRAFFIC SCHEDULING}

[0001] 본 발명은 일반적으로 네트워크 대역폭을 규제하기 위한 시스템들 및 방법들에 관한 것이다. 더 구체적으로, 다양한 예시적인 실시예들은 트래픽 보고 및 대역폭 예약 메커니즘들에 관한 것이다.

[0002] 통신들 네트워크들의 계속된 급증으로; 인터넷으로부터 케이블 TV, IPTV, 이동 광대역, WiFi 및 홈 네트워크들까지; 및 이들 네트워크들을 통해 송신되는 데이터에 대한 계속-늘어나는 요구; 네트워크 혼잡에 관한 우려들이 더 만연해지고 있다. 가능한한 빨리 더 큰 파이프들이 제공될 수 있음에 따라, 사용자 요구는 그들을 채우기에 위협이 된다. 인터넷을 뒷받침하는 것들과 같이 데이터 전달을 위한 최선-노력 메커니즘들은 종종 불충한 것으로 입증된다.

[0003] 네트워크 혼잡 우려들은 케이블 TV 네트워크의 대역외(OOB) 채널과 같은 좁은, 비대칭 채널들에 대해 특히 심각할 수 있다. OOB 케이블 채널들은 강화된 TV 이진 상호교환 포맷(EBIF) 또는 개방 케이블 애플리케이션 플랫폼(OCAP) 표준들을 이용하여 구현되는 것들과 같은 강화된 TV 애플리케이션들에 의해 발생되는 트래픽을 취급하기 위한 요건들에 의해 점점 더 혹사된다. 그와 같은 트래픽은 의결(voting)및 투표(polling) 데이터, 사용자 선호도 및 통계들 트래픽, t-커머스(t-commerce) 정보 및 다른 데이터를 포함할 수 있다. DSL을 통한 데이터 전달 및 이동 광대역 네트워크들은 유사한 도전과제들에 대면한다.

[0004] 대역-제한된 네트워크들을 통한 네트워크 혼잡의 문제점을 해결하기 위해, 다양한 방식들이 설명되었다. 일부는: ("테일 드롭(tail drop)" 또는 활성 큐(queue) 관리를 통한) 패킷 드롭핑, TCP 혼잡 회피, 명시적 혼잡 통보, 윈도우 쉐이핑(window shaping), 트래픽 쉐이핑(즉, 패킷 지연), 서비스 품질(QoS) 방식들, 및 관련된 대역폭 예약 기술들을 포함한다.

[0005] 필요한 것은 데이터를 송신하고 수신하기 위해 대기하면서 그리고 긴 메시지들, 과도한 핸드쉐이킹 또는 다른 QoS-타입 오버헤드를 요구하지 않고서 노드들이 프로세싱을 계속하게 허용하는 방식으로 혼잡을 감소시키기 위해 네트워크 대역폭을 조절하기 위한 시스템들 및 방법들이다.

[0006] 다양한 예시적인 실시예들에서, 네트워크 트래픽을 모니터링하는 단계, 네트워크 로드들을 예측하는 단계, 및 트래픽 보고 및 대역폭 예약 메커니즘들을 활용하여 트래픽을 스케줄링하는 단계를 포함하는 네트워크 대역폭을 조절하기 위한 시스템들 및 방법들이 제공될 수 있다. 트래픽 보고는 메시지들을 송신하고 수신하기 위한 적절한 시간들을 표시하는 제어 메시지들을 네트워크 노드들에 브로드캐스팅하는 단계를 포함할 수 있다. 네트워크 노드들은 네트워크의 이용을 사전에 조절하기 위해 트래픽 보고들(예를 들어, 제어 메시지들)을 이용할 수 있다. 예약들은 동기 또는 비동기 방식으로 구현될 수 있다. 예약 메커니즘은 전통적인 스트림 소켓 API를 에뮬레이트(emulate)할 수 있다.

[0007] 다른 예시적인 실시예에서, 트래픽 보고 브로드캐스트에 더하여, 클라이언트 노드들은 메시지들 또는 다른 데이터를 송신하거나 수신하기 전에 대역폭 예약들을 행할 수 있다.

[0008] 일부 예시적인 실시예들에서, 시스템들 및 방법들은 디지털 케이블 TV 대역 외(out-of-band: OOB) 네트워크에서의 사용자 데이터그램 프로토콜(UDP) 위에 대역폭 조절 및 경량성 전송 제어 프로토콜(TCP) 기능을 제공할 수 있으며, 강화된 텔레비전(ETV) 플랫폼 서버(Platform Server)가 강화된 TV 이진 상호교환 포맷(EBIF) 사용자 에이전트들을 실행하는 다수의 셋-톱 박스들(STBs)과 UDP를 이용하여 상호교환되는 하이퍼텍스트 전송 프로토콜(HTTP) 페이로드들을 통해 통신한다.

[0009] 다른 실시예들은 TCP 및 다른 프로토콜들을 활용하는 네트워크들을 포함한다; 대역-내 케이블 TV, DSL, 및 셀룰러/이동 네트워크들과 같은 네트워크들; 및 다른 아키텍처들 및 컴포넌트들에 기초한 네트워크들.

[00010] 다른 예시적인 실시예에서, 대역폭 조절은 EBIF 애플리케이션들에 투명한 방식으로 EBIF 사용자 에이전트에 의해 구현될 수 있다. 다른 실시예들에서, 트래픽 스케줄은 네트워크 애플리케이션들에 노출될 수 있으며, 네트워크 애플리케이션들은 그 후에 개시되는 트래픽 스케줄링 메커니즘들을 이용할 수 있으며 사용자-대면 행동을 적절하게 조정할 수 있다.

[00011] 다른 예시적인 실시예에서, 대역폭 조절 서버는 적절하게 관리되는 외부 이벤트들(예를 들어, 현재 시간의(time-of-day) 또는 연중의 시간 대역폭 예측들, 가능성있는 트래픽 스톰들(storms)을 표시하는 뉴스 속보 경보들)에 응답할 수 있다.

[00012] 전술한 일반 설명 및 후속하는 상세한 설명 둘 다는 예시적이며 단지 설명하는 것이며, 청구된 바와 같이 본 발명을 제한하지 않는 것이 이해될 것이다. 첨부하는 도면들은 명세서의 일부를 구성하고, 본 발명의 특정 실시예들을 예시하며, 상세한 설명과 함께, 본 발명의 원리들을 설명하도록 서빙한다.

[00013] 본 발명은 유사 참조 표시자들이 유사한 엘리먼트들을 지시하기 위해 이용되는, 첨부하는 도면들과 함께 다음의 상세한 설명을 숙독함으로써 더 완전히 이해될 수 있다.
[00014] 도 1은 케이블 시스템의 대역 외 네트워크에서 대역폭 조절을 제공하기 위한 시스템의 일 실시예를 도시하는 예시적인 아키텍처 도이다.
[00015] 도 2는 본 발명의 예시적인 실시예에 따른 트래픽 관리 서버의 일 실시예를 도시하는 예시적인 아키텍처 도이다.
[00016] 도 3은 본 발명의 예시적인 실시예에 따른 트래픽 관리 클라이언트의 일 실시예의 프로그래머의 관점을 도시하는 예시적인 아키텍처 도이다.
[00017] 도 4a는 HTTP의 종래 기술 TCP/STREAM 소켓 구현을 도시하는 흐름도이다.
[00018] 도 4b는 본 발명의 예시적인 실시예에 따른 HTTP의 동기(블로킹) 가상 소켓 구현을 도시하는 흐름도이다.
[00019] 도 4c는 본 발명의 예시적인 실시예에 따른 HTTP의 비동기(비-블로킹) 가상 소켓 구현을 도시하는 흐름도이다.
[00020] 도 5a는 예시적인 정보 패킷의 도식적 표현이다.
[00021] 도 5b는 예시적인 데이터 패킷의 도식적 표현이다.
[00022] 도 5c는 예시적인 ACK 패킷의 도식적 표현이다.
[00023] 도 5d는 예시적인 프로브 패킷의 도식적 표현이다.
[00024] 도 6a는 가상 소켓 구조의 도식적 표현이다.
[00025] 도 6b는 가상 소켓 테이블 구조의 도식적 표현이다.
[00026] 도 6c는 예약 큐 구조의 도시적 표현이다.
[00027] 도 7a는 대역폭 규제 없이 네트워크 로드의 시뮬레이션을 도시하는 그래프이다.
[00028] 도 7b는 대역폭 규제를 갖는 네트워크 로드의 시뮬레이션을 도시하는 그래프이다.
[00029] 도 7c는 대역폭 규제로 그리고 대역폭 규제 없이 시뮬레이팅된 네트워크 로드들 사이의 차이를 도시하는 그래프이다.

[00030] 도 1에 예시된 바와 같이, 본 개시물은 트래픽 관리(TM) 시스템들(100) 및 방법들의 문맥에서 트래픽 스케줄링을 이용한 네트워크 대역폭 규제에 관한 것이다. 더 구체적으로, 디지털 케이블 TV 대역 외(OOB) 네트워크의 문맥에서 예시적인 실시예가 개시되며 강화된 텔레비전(ETV) 플랫폼 서버(200)는 강화된 TV 이진 상호교환 포맷(EBIF) 사용자 에이전트들(410)을 실행하는 다수의 셋-탑 박스들(STBs)(400)로 사용자 데이터그램 프로토콜(UDP)을 이용하여 교환되는 하이퍼텍스트 전송 프로토콜(HTTP) 페이로드들을 통해 통신한다. 대역폭 규제를 제공하는데 더하여, 개시된 TM 시스템들(100) 및 방법들은 UDP 지원 보장된 전달, 패킷 시퀀싱, 흐름 제어 및 데이터 압축을 이용하여 경량 전송 제어 프로토콜(TCP) 기능을 제공할 수 있다.

[00031] 본원에 설명되는 시스템들 및 방법들은 또한 TCP 및 다른 프로토콜들을 활용하여 트래픽으로 이용하기 위해; 대역-내 케이블 TV, DSL 및 셀룰러/이동 네트워크들과 같은 다른 네트워크들에 대해; 그리고 다른 아키텍처들 및 컴포넌트들에 기초한 네트워크들에 대해 적합할 수 있다.

[00032] 본 예시적인 실시예에서, TM 시스템들(100) 및 방법들은 디지털 케이블 OOB 네트워크들의 다음의 특성들을 고려한다:

[00033] 비대칭 - 다운스트림 네트워크 대역폭(STB에 대한 헤드엔드(headend))이 업스트림보다 크다;

[00034] 낮은 대역폭 - 어느 한쪽 방향에서의 대역폭은 Mbps가 아니라 Kbps로 측정된다;

[00035] 높은 지연시간 - 하이브리드 파이버-동축(Hybrid Fiber-Coaxial: HFC) 네트워크를 통해 인터넷 프로토콜(IP)을 터널링하는 것은 지연들을 발생시킨다;

[00036] TCP 보다 선호되는 UDP - 대역폭 및 시간을 절감하며, 모든 케이블 OOB 네트워크들이 TCP를 제공하지 않는다;

[00037] HTTP 지배들 - 대부분의 트래픽은 HTTP 요청/응답에 모델링되지만, 예외들이 존재할 수 있다;

[00038] 요청/응답 이분법(dichotomy) - 대부분의 트래픽은 일 방향 또는 다른 방향으로 이동하는 데이터로 이루어지며 요청 방향은 훨씬 적은 데이터를 운반하는 경향이 있다;

[00039] 취약도(Fragility) - 업스트림 혼잡은 OOB 네트워크 및 네트워크 상의 STB들을 충돌시킬 수 있다;

[00040] 혼합된 전경 및 배경 - 일부 요청들은 적시의 응답을 필요로 하는 한편 다른 요청들은 그렇지 않다.

추정들 및 정의들

[00041] 현재 예시적인 실시예의 설명을 용이하게 하기 위해, 하부 네트워크에 관한 다음의 추정들이 이루어질 수 있다:

[00042] 케이블 OOB 네트워크들은 IPv6가 아니라, IPv4를 배타적으로 이용한다;

[00043] IP 패킷 헤더들은 20 바이트들을 차지한다;

[00044] UDP 패킷 헤더들은 8 바이트들을 차지한다;

[00045] 매체 액세스 제어(MAC) 계층 셀들은 적어도 34 바이트들(사이즈는 변화함)의 페이로드를 갖는다;

[00046] IP 및 UDP 헤더들의 28 바이트들과 함께, 하나의 MAC 셀에서 맞출 수 있는 최대 UDP 메시지 크기는 34 - 28 = 6 바이트들이다. 이는 TM 패킷 헤더들의 크기를 이끌어낸다;

[00047] 하이브리드 파이버 동축 네트워크 노드(HFC 노드, 즉, 복조기) 당 총 업스트림 대역폭은 500 내지 2000개의 STB들에 의해 공유되는 256 Kbps이다;

[00048] 슬롯된 알로하(Aloha) 네트워크들은 충돌들로 인해 36.8%의 이론적 최대 효율성을 갖는다;

[00049] 변조기 당 총 다운스트림 대역폭은 최대 32,000 STB들에 의해 공유되는, 2 Mbps이다;

[00050] 현재 실시예의 성능은 구현들에 이용될 수 있는 후속하는 수치적 상수들에 기초할 수 있다. 대표 값들은 전개되는 환경들의 특성들 및 실험에 기초하여 변화하기 쉬운 것이 주목된다:

[00051] MTU - TM 업스트림 트래픽에 대한 최대 전송 유닛(즉, UDP 패킷 크기)은 244 바이트들 또는 1952 비트들일 수 있다. 이는 하나의 MTU가 IP 및 UDP 헤더의 28 바이트들을 포함하는, 정확하게 6개의 MAC 셀들(272 바이트들)에 맞추게 허용한다. 모든 업스트림 메시지들의 99%는 1개의 MTU에 맞추어야 한다. 다운스트림인, MTU는 987 바이트들의 최대값까지 더 클 수 있다;

[00052] SLOT - 256 Kbps에서 하나의 MTU를 송신하기 위해 필요한 시간, EH는 0.008 초(8 밀리초들);

[00053] SLOTS_PER_SECOND - 상수 125(즉, 1000 ms/sec/8 ms/SLOT);

[00054] 슬롯 ID - 01/01/2000 00:00:00 이후에 하나의 슬롯(즉, 8 밀리초 시간 슬라이스)을 고유하게 식별하는 6-바이트 무부호 정수(또는 더 큼). 즉, 0의 슬롯 ID는 01/01/2000 00:00:00.000에서 시작하며, 01/01/2000 00:00:00.008에서 종료하는 8 밀리초 시간 슬라이스를 지칭한다; 슬롯 ID 2는 01/01/2000 00:00:00.008에서 시작하며 01/01/2000 00:00:00.016에서 종료하는 그 다음 시간 슬라이스를 지칭하는 등이다. 예를 들어,

의 날짜-시간에 대한 제 34 SLOT의 슬롯 ID는

이다. 이 날짜의 100 년 기념 초를 나타내는 제 1 SLOT의 슬롯 ID는

이다;

[00055]

- 모든 TM 트래픽에 대해 이용되는 실제 포트 번호(1962). 이 번호는 BIAP, Inc에 등록되었다;

[00056]

- 데이터 송신 함수(예를 들어,

)가 계속해서 블로킹해야 하는 패킷들사이의 최대 수의 밀리초들. 초기에 100 밀리초로 설정한다;

[00057]

- 리터닝 전에

가 시도해야 하는 최대 수의 패킷 재송신들. 초기에 5로 설정한다.

[00058]

- 데이터 수신 함수(예를 들어,

)가 데이터 패킷을 대기하면서 계속해서 블로킹해야 하는 최대 수의 밀리초들. 초기에 100 밀리초들로 설정한다.

트래픽 관리 아키텍처

[00059] 도 1은 케이블 시스템의 OOB 네트워크에서의 대역폭 규제를 제공하기 위한 시스템(100)의 일 실시예를 도시하는 예시적인 아키텍처 도이다. 도시되는 TM 클라이언트(420) 및 TM 서버(210) 컴포넌트들은 빌트-인 대역폭 규제로 UDP를 통해 TCP-형 기능을 제공할 수 있다.

[00060] 실시예는 트리 및 브랜치 토폴로지에서 HFC 노드들(300) 및 복수의 허브들(도시되지 않음)을 통해 접속되는 고객 전제들(premises)에 위치되는 다수의 STB들(400)과 통신하는 케이블 운영자 헤드엔드에 위치되는 하나 또는 그 초과의 ETV 플랫폼 서버들(EPS)(200)로 이루어질 수 있다. EPS(200)는 HTTP/TCP를 통해 아파치(Apache) HTTP 서버(220)에 HTTP 페이로드들로 이루어지는 착신 TM/UDP 트래픽을 릴레이하며 그 후에 중간 HFC 노드들(300) 및 허브들을 통해 TM/UDP를 통해 발신하는 STB(400)에 되돌려 HTTP/TCP 응답들을 릴레이하는 고성능 UDP 프록시 서버일 수 있는 TM 서버(210)를 포함할 수 있다.

[00061] STB들(즉, 클라이언트 노드들)(400)은 STB들(400) 상에 실행하는 EBIP 애플리케이션들(도시되지 않음)의 데이터 네트워킹 필요들을 지원하기 위해 TM 클라이언트(420)를 활용하는 EBIF 사용자 에이전트(410)를 포함할 수 있다. TM 클라이언트 컴포넌트(420)는 단지 단일의 실제 데이터그램 소켓/포트를 이용하면서 다수의 동시적 "가상" 스트림 소켓들 및 접속들을 제공하는, TCP 네트워킹을 위한 표준 스트림 소켓 애플리케이션 프로그래밍 인터페이스(Application Programming Interface: API)를 모방하는 정적 라이브러리일 수 있다.

[00062] 표시된 TM/UDP 프로토콜은 메시지 전달을 보장하기 위해 단순한 패킷 단편화, 시퀀싱 및 확인응답 방식을 이용할 수 있다. 대역폭 규제는 네트워크 로딩을 예측하기 위해, 그리고 (예를 들어, 대역폭 예약들을 통해) 업스트림 메시지들을 스케줄링하는 방법을 TM 클라이언트들(420)에 말하는 제어 메시지들을 STB들(400)에 브로드캐스트하기 위해 업스트림 트래픽을 모니터할 수 있는 TM 서버(210)에 의해 제어될 수 있다. 다운스트림 대역폭 규제는 TM 서버(210) 내에 전적으로 달성될 수 있다.

[00063] 도 1에 도시되는 아키텍처가 제공되면, 지원되는 3개의 동작 모드들이 존재할 수 있으며, 그 중 하나만이 임의의 특정 케이블 운영자를 위해 이용될 수 있다. 어느 모드가 지원되는지는 다음에 의존할 수 있다: (a) STB들(400)에 대한 로드 정보의 UDP 브로드캐스트를 위한 다운스트림 대역폭의 연속적인 트리클의 이용가능성, 및 (b) 클라이언트 시스템 상의 하나의 소켓/포트의 영구적인 할당. 이들 모드들은 다음과 같을 수 있다:

[00064] 모드 1 - (a) 및 (b)가 이용가능할 때, 그리고 TM 서버(210)는 주기적으로, 예를 들어, 매 10초마다 그리고 심한 로드 조건들 동안 더 자주 모든 STB들(400)에 인포 패킷들(이하에 도시함)을 브로드캐스트할 수 있다. 이것은 약 30 bps(0.03 Kbps)를 요구해야 한다;

[00065] 모드 2 - (a)가 이용가능하지만, (b)가 이용가능하지 않으며, TM 클라이언트(420)는 임의의 메시지를 송신하기 전에 인포 패킷을 대기해야 할 때, 이들 패킷들은 더 빈번하게 송신되어야 한다. 이는 약 270 bps(0.27 Kbps)를 요구해야 한다;

[00066] 모드 3 - (a)가 이용가능하지 않을 때, 프로브 패킷들(probe packets)(이하에 설명됨)은 모든 메시지를 송신하기 전에 "사정을 살피기" 위해 이용되어야 한다. 이는 구성된 제한들을 넘어선 간단한 대역폭 스파이크들을 야기할 수 있으며, 따라서 다른 모드들보다 덜 바람직할 수 있다.

트래픽 관리 서버

[00067] 도 2는 트래픽 관리(TM) 서버(210)의 예시적인 실시예를 도시하는 예시적인 아키텍처이다.

[00068] TM 서버(210)는 TM 보장된 전달 프로토콜 및 OOB 대역폭 규제를 구현하는 TCP 릴레이 서버에 대한 고성능 UDP일 수 있다. 착신 접속들 및 데이터는 UDP 청취자 프로세스(214)를 통해 수신될 수 있으며 접속/패킷은 아젠다(218) 상의 태스크로서 배치될 수 있다. 도 2에 점선들에 의해 도시된 바와 같이, 아젠다(218)는 여러 프로세스들에 의해 판독될 수 있다.

[00069] 접속은 데이터 또는 프로브 패킷이 IP 어드레스, 포트 및 ConnID(이하의 패킷 포맷들 섹션을 참조) 헤더 필드들의 새로운 조합으로 도달할 때마다 암시적으로 "개방"될 수 있다. 다수의 일꾼 스레드들을 각각 구현할 수 있는 차일드 프로세스들(216)은 적절한 순서로 그들을 원래 메시지들로 리어셈블링하고, ACK 패킷들을 필요에 따라 클라이언트에 리턴하면서, 그들이 도달함에 따라 이들 패킷들을 프로세스할 수 있다. 완료된 메시지들은 그 후에 표준 HTTP/TCP/IP 접속을 통해 아파치 HTTP 서버(220)에 송신될 수 있다. 아파치로부터의 HTTP 응답은 그 후에 "개방" 가상 접속을 통해(즉, 다운스트림 데이터 패킷들을 통해) 대응하는 클라이언트에 리턴될 수 있다.

[00070] 대역폭 규제 프로세스(212)는 착신 패킷들을 실시간으로 모니터할 수 있다. 이 정보 및 그 변경 레이트는 로딩 트렌드들을 추정하기 위해 이용될 수 있다. 이러한 추정으로부터, 대응하는

이 계산될 수 있다. 이러한

및 클록 동기화 정보는 모든 TM 클라이언트들(420)에 UDP를 통해 주기적으로 브로드캐스트될 수 있다.

트래픽 보고

[00071] 본 섹션은 TM 클라이언트들(420)에 로드 정보를 전달하기 위한 예시적인 방법을 설명한다.

[00072] TM 서버(210) 및 TM 클라이언트들(420)은 메시지들을 송신하기 위해 이용되는 시간을 확산시킴으로써 업스트림 OOB 대역폭을 관리할 수 있다. 모든 메시지는 고정된-사이즈의 데이터 패킷들로 분해될 수 있으며 각 패킷은 랜덤 지연에 의해 경계지워질 수 있다. 예를 들어, 현재 글로벌 송신 확률(즉, 변수

)이 32767인 경우에, (슬롯들에서의) 지연은 다음과 같이 계산될 수 있다:

[00073]

[00074] 이것은 0과 3 사이의 값을 발생시킨다. 예를 들어,

은 446을 리턴하는 경우에, 446%4 = 2이다. TM 클라이언트(420) 상의 채널/슬롯 예약 기능에 대한 호출은 호출자에게 16 밀리초의 예약 지연(즉, 8*2, 여기서 각 SLOT은 8 밀리초임)을 리턴할 것이다. 이 정보는 또한 현재의 슬롯 ID 값에 대해 2의 지연으로

변수를 업데이트하기 위해 이용될 수 있다. 이것은 TM 클라이언트(420)에 의해 유지되는 예약 큐에서의 제 1 가상 접속이 지금으로부터 16 밀리초(즉, 2 SLOT들)에서 송신하기 위한 패킷을 가짐을 의미하는 것으로 번역된다. 그 때, 예약 기능에 대한 후속하는 호출은 예약된 시간이 도달됨을 알 것이며 호출자에게 0을 리턴하며, 호출자는 그 후에 메시지를 송신할 것이다.

값은 다음과 같이 설정될 수 있다:

[00075] (1) 16,387의 디폴트 값으로 초기화된다.

[00076] (2) 모드들 1 및 2에서, 그 값은 TM 서버(210)에 의해 브로드캐스트되는 인포 패킷들로부터 직접 수신된다. 이 값은 임의의 이전

값을 대체한다. 모드 3에서, 대응하는 ACK 패킷을 발생시키기 위해 가능한한 곧 프로브 패킷이 송신된다.

[00077] (3) 모든 ACK 패킷은

값의 업데이트를 포함한다. 이 값은 임의의 이전

값을 대체한다.

[00078] (4) 송신된 패킷 확인응답이 만료할 때마다(즉, 패킷이 확인응답되지 않음),

값은 절반이 된다(1의 최소값). 이러한 방식으로 절반이 되는

없이 경과하는 매 초마다, 16,387의 최대 값까지,

는 100만큼 증가되도록 야기된다.

[00079] 상술한 바와 같이, 모드 1은 다운스트림 대역폭의 약 0.03 Kbps를 요구하는 인포 패킷들의 브로드캐스트 스트림을 발생시킨다. 모드 2는 0.27 Kbps를 요구한다. 모드에 따라, 클라이언트는 진짜의 소켓이 이용가능한 이후에 가능한한 곧 인포 패킷들에 대해 청취를 시작해야 한다.

랜덤 번호 발생

[00080] 본 섹션은 본 발명의 다양한 예시적인 실시예들의 다른 필요들 및 메시지 지연들을 계산하기 위해 적합한 랜덤 번호 발생기(즉,

및

)의 예시적인 구현을 제시한다:

[00081]

는 시동 시에 정확하게 한번 호출되어야 하며,

는 STB의 IPv4 어드레스의 uint32(4-바이트) 값이다.

클라이언트 클록 동기화

[00082] 본 섹션은 본 발명의 다양한 예시적인 실시예들을 위해 적합한 클라이언트 클록 동기화의 예시적인 방법을 설명한다.

[00083] TM 서버(210)로부터의 인포 패킷들 브로드캐스트는

업데이트들과 함께 타이밍 동기화 정보를 포함할 수 있다. 타이밍 정보는 인포 패킷의 2개의 필드들에 관여할 수 있다:

[00084]

(1-바이트) - 서버 클록에 따라 패킷이 송신된 초(second)를 식별하는 범위 0...119에서의 값. 그 값은 가장 최신의 짝수-넘버링된 분(minute)의 시작으로부터의 오프셋이다.

[00085]

(1-바이트) - 이 패킷을 송신하기 전에 동기화하는 초에서 경과한 SLOT들(0...124)의 수.

[00086] 예를 들어, 인포 패킷이 서버(210) 상에 구성되는 시간이 초의 단편을 포함하여,

인 경우에,

필드에 할당되는 값은 103일 것이다. 분 값인, 23은 홀수이기 때문에, 가장 최신의 짝수-넘버링된 분은 22이다.

으로부터

까지의 오프셋은

이거나, 103초이다.

[00087] 일단 초가 식별되면, 나머지 0.728 초들(728 밀리초들)이 설명되어야 한다. 하나의 SLOT이 0.008 초들(8 밀리초들)을 점유한다고 가정하면, 슬롯들의 수는

로서 계산된다. 이러한 값(예를 들어, 91)은 인포 패킷에서의

필드에 할당된다.

[00088] TM 클라이언트(420)가 인포 패킷을 수신할 때마다,

변수를 업데이트하기 위해 후속하는 단계들을 수행할 수 있다:

[00089] (1) 부동 소수점 변수

에서의 일부 시대(epoch) 이후에 초들로서 현재 날짜/시간(GMT)을 계산한다.

[00090] (2) 부동 소수점 변수

에서의 동일한 시대 이후의 초들로서 인포 패킷(GMT)에서 발견되는 2개의 필드들에 의해 정의되는 시간을 계산한다.

[00091] (3) 밀리초들에서의 최신 오프셋인, 부동 소수점 변수

을 계산한다.

[00092] (4)

로 설정한다. 이것은 조건들이 시간을 통해 변화함에 따라 시간 오프셋의 느린 이동 평균을 발생시킨다. 임의의 인포 패킷들을 수신하기 전에,

를 제로(0)로 초기화한다.

[00093] 모드 1에서,

를 매 인포 패킷마다 업데이트하는 것이 필요하지 않을 수 있다. 분당 하나의 업데이트가 충분할 수 있다. 모드 2에서, 이러한 시간 오프셋은 바람직하게는 매 인포 패킷에 대해 계산될 수 있다.

[00094] "현재 시간"이 참조될 때마다, STB(GMT)의 현재 시간 플러스

값이 적절한 시간 유닛들(즉, "현재 시간"이 초들로 보고되는 경우에,

)로 스케일되는 것으로 가정될 수 있다.

트래픽 관리 클라이언트

[00095] 도 3은 본 발명의 예시적인 실시예에 따른 트래픽 관리 클라이언트(420)의 일 실시예의 프로그래머의 뷰를 도시하는 예시적인 아키텍처 도이다. 도 3은, 클라이언트 디바이스(예를 들어, STB)(400)에 의해 제공되는 하드웨어 및 운영 시스템(O/S)(450)의 다른 성능들과 함께 STB 미들웨어(440)의 소켓 중재 능력들을 활용함으로써 다수의 EBIF 앱들(430)에 대한 트래픽 관리 서비스들을 제공하기 위해 EBIF 사용자 에이전트(410)에 의해 TM 클라이언트(420)가 어떻게 활용될 수 있는지를 도시한다. 더 설명되는 바와 같이, TM 클아이언트(420)는 표준 STREAM 소켓 API들을 활용할 수 있고, 트래픽 스케줄링을 이용한 대역폭 규제를 위해 동기 및 비동기 모드들 둘 다를 제공할 수 있으며, 클라이언트 및 서버 접속들 둘 다를 허용할 수 있으며, 다수의 "가상" 소켓들/포트들을 지원할 수 있으며, 보장된 전달을 제공할 수 있으며, 데이터 압축을 제공할 수 있으며, 어떠한 사전의 대역폭 제한들도 부과하지 않을 수 있다.

네트워크 API들

[00096] 도 4a는 네트워킹 클라이언트에 의해 이용될 수 있는 종래의 HTTP의 TCP/STREAM 소켓 구현을 도시하는 예시적인 흐름도이다. 시작시에(단계(500)),

은 새로운 소켓 id를 획득하기 위해 호출될 수 있다(단계(502)). 다음에, IP 어드레스 및 포트 번호에 의해 정의되는 서버와의 접속이

를 호출함으로써 획득될 수 있다(단계(504)). 요청 스트링이 그 후에 전체 요청을 프로세싱하기 위해 가능하게는

에 대한 다수의 호출들을 요구하면서,

함수에 의해 서버에 송신될 수 있다(단계(508)). 모든 데이터가 송신된 후에(즉, 모두 송신되었는가? = 예(단계(508)), 응답을 대기하기 위해

에 대한 호출이 이루어질 수 있다(단계(510)).

에 관하여(단계들(506, 508)), 전체 HTTP 응답을 리트리브하기 위해(즉, 모두 수신될 때까지 반복하는가? = 예)

에 대한 다수의 호출들이 요구될 수 있다(단계(512)). 마지막으로, 프로세스가 중단한 후에(단계(518)), 접속을 폐쇄하기 위해

가 호출될 수 있다(단계(516)). 추가로, 전체 HTTP 응답이 수신되지 않지만, 접속이 폐쇄되는 것이 발생할 수 있다(단계(514)). 이러한 경우에, 프로세스를 중단하기 위해(단계(518))

가 호출될 수 있다(단계(516)). 이러한 타입의 동기 HTTP 클라이언트를 구현하는 것은 당업자에 의해 알려질 것이다.

[00097] 도 4b 및 4c는 본 발명의 예시적인 실시예에 따른 HTTP의 가상 소켓 구현들의 예시적인 실시예들을 도시한다. 도 4b에서의 흐름도는 동기(블로킹) 버전을 도시한다. 도 4c에서의 흐름도는 비동기(비-블로킹) 버전을 도시한다.

[00098] 이들 도면들에 도시된 바와 같이, 표준 스트림 소켓 API 호출들은 가상 등가물들을 가질 수 있다(예를 들어,

(506)는 프로그래머들이 익숙한 방식으로 스트림 소켓들을 이용하게 할 수 있는

(612)가 된다). 작은 수의 추가적인 함수들이 음영된 블록들에 의해 표시된 바와 같이 존재할 수 있다. 본 발명의 다양한 예시적인 실시예들에 따르면, 모든 업스트림 트래픽은 바람직하게는 네트워크의 현재 로드 조건들에 기초하여 스케줄링될 수 있다. 네트워크 로드가 로우일 때, 즉시가 아니라면, 빠르게 데이터가 송신될 수 있다. 네트워크 로드가 더 높을 때, 지연들이 존재할 수 있다. TM 클라이언트(420)는

(606)의 리턴 값으로부터 예상된 지연을 추정할 수 있으며 진행할 또는 진행하지 않을 방법을 판단하며 다른 태스크들에 대한 중재 사이클들을 이용할 수 있다.

[00099] 표시된 API 호출들은 정적 라이브러리를 통해 제공될 수 있으며 C 헤더 파일 (.h)에서 프로토타입된다. 그와 같은 헤더 파일은 전통적인 스트림 소켓 API들을 그들의 트래픽 관리 아날로그들로 맵핑하는

매크로들일 수 있다. 그와 같은 매크로들은 비동기 프로세싱 및 송신 호출들의 스케줄링을 위해 작은 변경들만을 요구하면서, 트래픽 관리 시스템들 및 방법들로 작동시키기 위해 기존의 소켓 코드를 허용할 것이다.

[000100] 후속하는 단락들은 개시되는 단계들의 문맥에서 도 4b 및 4c에 도시되는 가상 호출들의 상세를 제공한다. 설명되는 모든 API 호출에 대해, 파라미터 및 리턴 타입들은 전통적인 소켓 API들에 이용되는 동일한 타입들을 전형적으로 참조할 것이며, 따라서 본원에 설명되지 않는다. 문자 "v"로 시작하는 명칭들은 본원에 설명되는 시스템들 및 방법들에 특정하다.

등과 가은 표준(즉, 비-TM) 소켓 API들이 또한 이용가능한 것이 가정된다.

및

과 같은 트래픽 관리를 이용할 때 다른 전통적인 소켓 API들이 아날로그들을 갖지 않을 수 있다.

[000101] 도 4b는 본 발명의 예시적인 실시예에 따른 HTTP의 동기적(블로킹) 가상 소켓 구현을 도시하는 예시적인 흐름도이다.

[000102] 프로세스가 시작한 후에(단계(600)), 제 1 호출은 가상 소켓 기술어를 할당하기 위해

일 수 있다(단계(602)). 본 함수에 의해 리턴되는 기술어는

및 다른 함수들에 대한 후속적인 호출들을 위해 이용될 수 있다. TM 클라이언트(420)에서의 구현은 가상 소켓 테이블에서의 새로운 빈 가상 소켓 구조를 할당하는 것과 가상 소켓 기술어로서 그 엔트리의 테이블 인덱스를 리턴하는 것을 포함할 수 있다. 모드 2에서, 이 호출은 또한

의 개방 및 초기화를 야기할 수 있어 인포 패킷들을 청취하기 시작할 수 있다.

[000103] 다음의 단계에서, 요청하는 노드는 TM 서버(210)에 가상 소켓을 접속하기 위해

를 호출할 수 있다(단계(604)).

(604)에 통과하기 위한 관련 파라미터들은 가상 소켓 기술어 및 접속하는 서버의 IP 어드레스 및 포트 번호를 포함할 수 있다. 호출 프로그램이 접속을 위해 이용되는 로컬 포트를 특정하기를 원하는 경우에,

에 대한 호출이 이루어질 수 있다(도 4b에 도시되지 않음).

는 특정된 가상 소켓 기술어를 로컬 IP 어드레스 및 명시적 로컬 포트 번호와 관련시킬 수 있다. 가상 소켓의 포트 번호는 가상 소켓 기술어에 의해 인덱싱되는 가상 소켓 구조 테이블 엔트리에 저장될 수 있다.

는 이전에 소켓 기술어 상에 호출되지 않았다면, 표시되는 소켓 기술어는 로컬 노드의 IP 어드레스 및 랜덤 로컬 포트에 자동으로 바운딩될 수 있다. 그 노드는 어느 로컬 포트가 이용되는지를 주의하지 않는 경향이 있기 때문에, 이것은 호출 노드가 서버가 아닌 경우에 수용가능해야 한다. 일단 가상 소켓이 접속되면,

및

는 데이터를 송신하고 수신하는데 필요에 따라 호출될 수 있다. 서버의 호스트 IP 어드레스 및 포트는

에 의해 인덱싱되는 가상 소켓 구조를 위해 가상 소켓 테이블에 저장될 수 있다.

[000104] 다음에, 데이터 업스트림을 송신하기 위한 예약을 행하기 위해

에 대한 호출(단계(606))이 이루어질 수 있다.

(606)는 가상 소켓 기술어

를 수용할 수 있으며 (

를 이용하여) 메시지를 송신하기 전에 대기할 밀리초들의 수를 리턴할 수 있다.

(606)가 제로를 리턴할 때(즉, 송신할 준비가 되는가? = 예(단계(608)), 메시지는 블로킹되는 최소 확률로 송신될 수 있다. 예약된 슬롯을 대기하는 동안, 호출 프로그램은 다른 태스크들을 수행할 수 있다.

(606)는 예약 상태에 관하여 검사하기 위해 주기적으로 호출될 수 있다.

[000105] 다음의 단계에서,

는

호출에 의해 리턴되는 가상 소켓을 통해 이전에 접속되는 서버에 메시지를 송신하기 위해 이용될 수 있다(단계(612)).

(612)는 접속된 가상 소켓 기술어

를 표시하는 입력, 송신되는 데이터를 포함하는 버퍼에 대한 포인터

, 및 송신할 바이트들의 수

로서의 파라미터들을 수용할 수 있다. 실제로 송신되는 바이트들의 수를 리턴할 수 있다. 도 4a에 도시되는 전통적인

호출과 유사하게(단계(506)),

는 동기적(즉, 블로킹) 호출이며, 모든 데이터가 송신되기 전에(즉, 모두 송신되었는가? = 아니오(단계(614)) 리턴할 수 있다. 따라서,

는

에 대한 추가적인 호출들과 함께 반복적으로 호출될 수 있다(단계들(612 및 614)). 큰 메시지들에 대해, 또는 네트워크가 심하게 로딩될 때, 그렇게 되는 경향이 있을 것이다.

[000106]

(612)가 호출되며 특정된 가상 소켓에 대한 예약이 발견되지 않는 경우에,

(612)는

(606)를 내부적으로 호출할 수 있으며, 예약이 도달할 때까지 블로킹(즉, 슬립)할 수 있으며, 그 후에 송신하기 시작한다.

(612)는 예약없이 호출되는 경우에, 또는

(606)가 제로를 리턴하기 전에,

(606)는 데이터를 송신할 수 있을 때까지 블로킹할 수 있다. 그와 같은 경우들에서, 가능하게는 수 초들인 중간 시간이 낭비될 것이다.

[000107] 업스트림 메시지 스케줄링은 정해진 메시지에 대한

(606)에 대한 제 1 호출에 관하여, 또는 문제의 가상 소켓에 대한 예약이 이루어지지 않을 때

(612)에 대한 호출에 관하여 발생할 수 있다.

(612) API는: (a) 그 가상 소켓에 대한 예약 테이블에 예약이 존재할 때까지, 그리고 (b)

에서의 슬롯 ID는 현재 슬롯 ID를 매칭할 때까지 가상 소켓에 대한 데이터를 실제로 송신하지 않을 수 있다. 메시지 스케줄링 프로세스는 다음과 같이 기능할 수 있다.

[000108]

에 대한 호출이 이루어짐을 가정한다:

[000109] (1) 현재 시간의 슬롯 ID를 계산하며, 여기서

[000110] (2)

가 예약 큐에서의 포지션 X에서 발견되는 경우에,

를 설정하며, 단계 5로 스킵한다. 그렇지 않으면,

[000111] (3)

이면(즉, 큐가 비어있으면),

[000112] (4) 예약 큐에

를 추가한다.

[000113] (5)

의 결과로서

를 리턴한다.

[000114] 도 4b를 되돌려 참조하면,

를 이용하여 모든 데이터가 송신된 후에(즉, 모두 송신되었는가? = 예(단계(614)), 이전에 접속된 가상 소켓을 통해 서버로부터 메시지를 수신하기 위해

에 대한 호출이 이루어질 수 있다(단계(616)).

호출(단계(616))은 접속된 가상 소켓 기술어

를 표시하는 입력 파라미터들, 수신 데이터 버퍼에 대한 포인터

, 및 바이트들에서의 수신 데이터 버퍼의 크기

를 수용할 수 있다. 서버에 대한 가상 접속이 임의의 이유로 폐쇄하는 경우에 제로(0) 또는 실제로 수신되는 바이트들의 수를 리턴할 수 있다. 실제로 수신되는 바이트들의 수가 버퍼의 크기보다 작을 수 있기 때문에, 전제 메시지가 수신될 때까지(즉, 모두 수신되었는가? = 예(단계(618))

(616)가 반복적으로 호출될 수 있다. 모든 데이터가 수신되지 않은 경우(즉, 모두 수신되었는가? = 아니오(단계(618))에 그리고 서버와의 접속이 폐쇄되지 않은 경우에(즉, 접속이 폐쇄되었는가? = 아니오(단계(620)),

는 다시 호출될 수 있다(단계(616)).

[000115]

(616)의 구현은

(616) 경우에 TM 클라이언트(420)가 적절한 ACK 패킷들을 발생시켜야 하며 이들을 TM 서버(210)에 되돌려 송신해야 하는 것을 제외하고,

(612)와 유사할 수 있다. 또한,

(616)는 비동기적으로 동작할 수 있기 때문에, TM 서버(210)로부터 데이터 패킷을 수신하지 않고서

밀리초들이 경과한 후에 또는 제공되는 수신 버퍼가 충전된 때에 호출자에게 리턴해야 한다.

[000116] 도 4b로 리턴하면, 모든 데이터가 수신된 경우에(즉, 모두 수신되었는가? = 예(단계(618)) 또는 서버 접속이 폐쇄된 것으로 결정되는 경우에(즉, 접속이 폐쇄되었는가? = 예(단계(620)), 클라이언트 노드는 가상 소켓을 폐쇄하기 위해

를 호출할 수 있으며(단계(622)) 프로세스가 중단한다(단계(624)). 적은 수의 이용가능한 가상 소켓들이 존재할 수 있기 때문에, 필요하지 않을 때 가상 소켓들을 폐쇄하는 것이 중요하다.

(622)의 구현은

에 의해 인덱싱되는 가상 소켓 테이블에서의 가상 소켓 구조를 자유롭게 하는 것을 수반할 수 있다.

[000117] 도 4b에 도시되는 동기(블로킹) HTTP 트랜잭션은 수신되는 응답을 대기하면서 추가적인 프로세싱을 행하지 않아도 되는 많은 애플리케이션들에 대해 충분할 수 있다. 그러나 데이터를 대기하면서 다른 태스크들을 수행해야 하는 애플리케이션들에 대해, 비동기(비-블로킹) 콜백(callback) 메커니즘은 도 4c에 도시된 바와 같이 구현될 수 있다. 이러한 비동기 메커니즘은 알려진

API와 다를 수 있지만, 사용하고 구현하기가 훨씬 더 간단할 수 있다.

[000118] 이제 도 4c를 참조하면, 초기의 단계들은 도 4b에서의 단계들과 동일하다. 프로세스를 시작할 때(단계(600)),

은 가상 소켓 기술어를 할당하기 위해 호출된다(단계(602)). 그 후에 TM 서버(210)에 가상 소켓을 접속하기 위해

가 호출된다(단계(604)).

[000119] 다음으로, 가상 소켓과 비동기 콜백 함수를 관련시키기 위해

가 호출된다(단계(605)). 이 함수는

을 통해 획득되는 가상 소켓 기술어

및

, 메시지 코드

및 임의의 활동-특정 정보

를 참조하는 콜백 함수에 대한 참조를 수용할 수 있다. 가상 소켓 상의 모든 장래의 활동(예를 들어, 에러들, 예약들, 수신된 데이터 등)은 콜백 함수를 인보크할 것이며 그 활동을 식별하는 적절한

코드를 특정할 것이다.

코드들은:

[000120]

- 실제 에러 코드에 대한 verrno를 검사한다.

[000121]

-

를 통해 개방되는 예약이 이제 개방한다.

를 통해 데이터를 송신한다.

[000122]

- 본 가상 소켓에 대한 데이터가 수신되었다. 그것을 획득하기 위해

를 호출한다.

[000123]

- 새로운 접속이 이러한 가상 소켓 상에 도달하였다. 그것을 획득하기 위해

를 호출한다.

[000124]

(605)의 구현은 가상 소켓 기술에 의해 인덱싱되는 가상 소켓 구조 테이블 엔트리에서 가상 소켓의 콜백 기능을 저장하는 것을 수반할 수 있다. 접속이 설정되고, 메시지가 업스트림으로 송신된 경우에, 패킷 헤더에서의

는 수신하는 가상 소켓을 식별하기 위해 이용될 수 있다. 경보 메시지들에 대해,

및

에 대한 헤더 공간은 TM 서버(210)에 의해 편입(co-opt)될 수 있으며 포트 번호를 저장하기 위해 이용될 수 있다. 이러한 포트는 경보를 수신하기 위해 경계 소켓을 식별하도록 이용될 수 있다(

,

및 패킷 헤더들에 관한 더 많은 정보에 대해 이하의 패킷 포캣들 섹션을 참조한다).

[000125] 도 4c로 계속하면,

가 호출된 후에(단계(605)), 표시된 소켓에 관한 트래픽 예약을 행하기 위해

에 대한 호출이 이루어질 수 있으며(단계(606)), 프로세스는 중단한다(단계(607)).

[000126] 도 4c에 도시된 바와 같이, 각 프로세스를 시작하기 위해 콜백 함수(즉,

)에 의존하여 송신 및 수신 프로세스들은 비동기적이다. 도면에서의 점선 화살표들은 다른 태스크들이 콜백 활성화들 사이에 수행될 수 있을 때 시간의 주기들을 표시한다. 구체적으로, 데이터를 송신하는 프로세스는

에 의해 표시되는 콜백 함수로(단계(610) 시작하며(단계(609)), 그 후에

에 대한 호출이 후속되며(단계(612)), 그 후에 프로세스는 중단한다(단계(613)). 데이터를 수신하기 위한 프로세스는 유사하다. 그 프로세스는 콜백 함수(즉,

(610))로 시작하며(단계(615)), 그 후에 도 4b에 설명되는 동일한 데이터 수신 단계들이 후속된다.

는, 모든 데이터가 수신될 때까지(단계(618)) 또는 서버 접속이 폐쇄될 때까지(단계(620)) 호출(단계(616))될 수 있으며, 그 후에

에 대한 호출(단계(622))이 이루어질 수 있으며 프로세싱이 중단한다(단계(624)).

[000127] 유용할 수 있는 도 4b 또는 4c에 도시되지 않는 2개의 추가적인 기능들은

및

를 포함한다.

호출은 표시된(즉, 통과된) 바운드 가상 소켓

상의 착신 접속들을 청취하기 위해 서버로서 동작하는데 필요한 노드에 의해 이용될 수 있다. 그와 같은 기능은 (예를 들어, 경보 메시지들에 대해) 애플리케이션 서버로부터의 접속을 대기하는 노드들에 대해 적합할 수 있다.

을 호출하기 전에, 가상 소켓을 할당하기 위해 그리고 (각각) 청취하기 위한 포트를 정의하기 위해

및

에 대한 호출들이 이루어질 수 있다. 동기적 청취는 많은 애플리케이션들(예를 들어, OOB 케이블 네트워크에서의 STB들)에서 말이 되지 않기 때문에, 가상 소켓을 비동기로 만들기 위해

에 대한 호출이 필요할 수 있다.

호출은 즉시 리턴할 것이며, 비동기 콜백 함수는 접속이 도달할 때

메시지로 인보크될 것이다.

호출이 정의될 수 있으며 그와 같은 새로운 접속들을 수용하기 위해 이용될 수 있다.

를 통해 포트에 바운드되는 임의의 비동기 가상 소켓은 접속이 도달할 때

메시지들을 수신할 것이다.

호출은 접속을 수용할 수 있으며 데이터를 송신하고 수신하기 위해 이용될 수 있는 새로운 동기적 가상 소켓 기술어를 리턴할 수 있다. 원래의 청취 소켓 기술어인,

는 여전히 청취하면서 변경되지 않은채로 남아있을 수 있다.

에 의해 리턴되는 가상 소켓 기술어는 더 이상 필요하지 않을 때

를 이용하여 폐쇄될 수 있다.

[000128] 본 발명의 예시적인 실시예에 따른 HTTP의 가상 소켓 구현의 다른 예시적인 실시예에서,

(606)에 의해 제공되는 예약 기능들은

(612) 및

(616)에 포함될 수 있으며,

(606) 호출이 제공되지 않는다. 본 실시예에서, (각각) 송신되거나 수신되는 바이트들의 수를 리턴하는

(612) 및

(616)에 더하여, 각 호출은 대역폭 예약을 투명하게 행할 것이며 데이터가 즉시 송신될 수 없거나 수신될 수 없을 때의 경우들에서 송신 또는 수신 슬롯이 이용가능할 ?까지 밀리초들의 수를 나타내는 음의 숫자를 리턴할 것이다. 이것은 도 4b에 도시되는

(606) -

(612) 루프에 도시된 것과 유사한 방식으로 데이터를 수신하도록 대기하면서 클라이언트 노드 상에 추가적인 프로세싱이 발생하게 허용함으로써

(616)의 블로킹 구현들에서의 이용을 위해 유용할 수 있다. 또한 하나의 비-표준 호출(

(606))을 제거함으로써 API를 간략화할 수 있다.

패킷 포맷들

[000129] 단일 파이프 상의 다수 종류들의 트래픽을 관리하기 위해, 본 발명의 예시적인 실시예는 도 5a-5d에 관하여 이하에 특정된 바와 같은 4개의 별개 메시지 패킷 타입들을 정의할 수 있다. 이들은 도 1에 표시되는 TM/UDP 프로토콜을 포함할 수 있다.

인포 패킷

[000130] 도 5a는 예시적인 인포 패킷(700)의 도식적 도시이다. TM 서버(210)는 시스템 로드 조건들 및 타이밍 동기화에 관한 정보를 전달하기 위해 동시에 모든 STB들(400)에 이들 작은 UDP 메시지들을 브로드캐스트할 수 있다. 인포 패킷들(700)은 다음을 포함할 수 있다:

[000131]

(702)(1-바이트) - 유효한 TM 패킷을 식별하는 상수이며, 4개 타입들 중 어느 것인지를 특정할 수 있다. 모든 TM

값들(702)은 필터 마스크로서 이용될 수 있는 높은 순서 6개의 비트들 0xA8을 포함할 수 있다. 낮은 순서 2개의 비트들은 패킷 타입에 의해 변화한다. 인포 패킷들(700)에 대해, 이들 비트들은 인포 패킷(700)

에 대한 값을 만드는 0x00이다.

[000132]

(704)(1-바이트) - 서버 클록에 따라 송신된 패킷의 초를 식별하는 범위 0...119에서의 값. 그 값은 가장 최근의 짝수-넘버링된 분의 시작으로부터의 오프셋일 수 있다.

[000133]

(706)(1-바이트) - 이 패킷을 송신하기 전에 동기화 초에서 경과한 슬롯들의 수(0...124)

[000134]

(708)(2-바이트들) - 모든 발신하는 패킷 상에 부과되는 랜덤 지연을 계산하기 위해 이용될 수 있는 16 비트 숫자.

데이터 패킷

[000135] 도 5b는 예시적인 데이터 패킷(710)의 도시적 도시이다. 업스트림 송신되는 데이터는 각각이 단일 SLOT 내에 전송되도록 충분히 작은, MTU-크기 패킷들로 분해될 수 있다. 다운스트림 데이터는 동일한 패킷 포맷을 이용할 수 있지만, 다운스트림 MTU 크기는 더 클 수 있다. 데이터 패킷들은 다음을 포함할 수 있다:

[000136]

(712)(1-바이트) - 유효한 TM 패킷을 식별하는 상수이며, 4개 타입들 중 어느 것인지를 특정할 수 있다. 데이터 패킷들(710)에 대해

값(712)은

이다.

[000137]

(714)(1-바이트) - 모든 가상 접속과 관련되는 가상 소켓에 대응하는 고유한 접속 ID.

[000138]

(716)(1-바이트) - 이 필드의 값은 다음과 같이 메시지에서의 패킷의 포지션에 의존할 수 있다(플래그들 필드를 참조):

[000139] (1)

이것이 메시지에서의 제 1 패킷이며

패킷들의 수가 > 1인 경우에, 이 값은 메시지에서의 패킷들의 총 수(1...256) 마이너스 1이다(이것은 최대 업스트림 메시지 크기가 256 * (MTU-4), 또는 61,440 바이트들임을 의미한다).

[000140] (2)

이것이 메시지에서의 최종 패킷인 경우에, 이 값은 이러한 패킷의 페이로드의 크기(1...MTU-4) 마이너스 1을 정의한다(이것은 수신부가 최종 패킷을 수신할 때까지 실제 메시지 크기를 알지 못하지만, 패킷에 기초한 추정치가 기껏해야 MTU-5 바이트들, 또는 0.39%를 낭비함을 의미한다).

[000141] (3)

, 이 값은 패킷의 시퀀스 번호 마이너스 1이다.

[000142]

(718)(1 바이트) - 다음의 비트 플래그들을 포함하는 비트 벡터:

[000143]

- 이것이 메시지에서의 제 1 패킷인 경우에 설정한다(예를 들어, = 1).

[000144]

- 이것이 메시지에서의 최종 패킷인 경우에 설정한다(예를 들어, = 1).

[000145]

- 이 패킷이 송신되는 첫 번째가 아닌 경우에 설정한다(예를 들어, = 1)

[000146]

- 이것이 서버 측 상에 발신하는 "경보" 메시지인 경우에 설정한다(예를 들어, = 1).

[000147] 나머지 4개의 플래그 비트들은 장래의 이용을 위해 예약될 수 있다.

[000148] 서버 발신 메시지들(즉, 경보들)에 대해, IP 어드레스는 STB(400)를 식별하기 위해 이용될 수 있다.

(614) 및

(616)에 대한 헤더 공간은 TM 서버(210)가 포트 번호를 저장할 수 있는 2개의 바이트들을 제공하기 위해 조합된다. 포트는 그 후에 포트 바인딩에 기초하여, 어느 가상 접속이 경보를 수신하는지를 식별하기 위해 이용된다. 경보 메시지들은 플래그들 필드(618)에서의 경보 비트를 통해 식별된다. 전체 경보 메시지는 (다운스트림 MTU-5) 바이트들 내에 맞추어야 한다.

[000149]

(616)의 정의들에서 "마이너스 1"에 관하여, 예시적인 메시지는 항상 1과 256개의 패킷들 사이로 이루어지지만, 일 바이트는 0과 255 사이의 정수들을 나타낸다. 따라서

값(616)은 항상 그것이 나타내는 값보다 하나 더 적다.

ACK 패킷

[000150] 도 5c는 예시적인 ACK 패킷(720)의 도식적 도시이다. 데이터 패킷(710)의 수신은 이들 패킷들 중 하나를 되돌려 송신함으로써 확인응답될 수 있다. ACK 패킷들(720)은 다음을 포함할 수 있다:

[000151]

(722)(1-바이트) - 유효한 TM 패킷을 식별하는 상수이며, 4개 타입들 중 어느 것인지를 특정할 수 있다. ACK 패킷들(720)에 대해

값(722)은

이다.

[000152]

(724)(1-바이트) - 수신된 데이터 패킷(710)으로부터의

값(714).

[000153]

(726)(1-바이트) - 제 1 미싱 패킷 전에 지금까지 수신된 메시지의 패킷들의 수.

[000154]

(728)(1-바이트) - 패킷 #

후의 최대 8개 패킷들의 확인응답. 모든 전송된 데이터에 관하여,

가 높은-순서 비트에 의해 확인응답된 후에 제 1 패킷, 및

가 낮은-순서 비트에 의해 확인응답된 후에 제 8 패킷을 갖는, 네트워크 바이트 순서로 있을 수 있다.

[000155]

(729)(2-바이트들) - 모든 발신하는 패킷 상에 부과되는 랜덤 지연을 계산하기 위해 이용되는 16 비트 숫자.

프로브 패킷

[000156] 도 5d는 예시적인 프로브 패킷(730)의 도식적 도시이다. 통상적으로, 최종 패킷을 제외하고, 메시지에서의 모든 데이터 패킷들(710)은 최대 크기 페이로드(MTU-6)를 포함해야 한다. 이것은 패킷 크기를 추정하는 것을 용이하게 한다. 그러나, 로드 정보가 이용가능하지 않을 때, 메시지의 제 1 패킷은 대응하는 ACK에서의 로드 정보를 얻기 위해, 프로브로서 송신되어야 할 수 있다. 프로브 패킷들(730)은 바람직하게는 작을 수 있으며, 하나의 MAC 셀 페이로드(34개의 바이트들) 내에 맞출 수 있다. 그러므로, 프로브 패킷들(730)은 (

=

을 갖는) 메시지의 제 1 데이터 패킷(732)으로서 헤더 정보의 동일한 6개 바이트들을 포함하지만 페이로드를 갖지 않는다.

값(736)은 후속하는 1 내지 256개의 데이터 패킷들만을 카운트하며, 임의의 버퍼 길이 계산들에서 패킷으로서 프로브를 카운트하지 않는다(네트워크 로드를 예측하는데 프로브 데이터의 장래 이용 설명을 위한 TM 서버 섹션을 참조한다).

TM 클라이언트 데이터

[000157] 도 6a-6c는 설명된 API를 지원하기 위해 TM 클라이언트(420)의 예시적인 실시예에 이용될 수 있는 구조들을 도시한다. (도면들에 도시되지 않는) TM 클라이언트(420)에 의해 활용될 수 있는 그들 및 다른 데이터 타입들 및 변수들은 다음과 같을 수 있다:

[000158] (1) 도 6a에 도시된 바와 같은 가상 소켓 구조(810)는 가상 스트림 소켓을 구현하기 위해 필요한 모든 정보를 포함할 수 있다. 이것은 상태 정보(812), 포트 바인딩(813), 비동기 콜백 정보(814), 원격 호스트 IP(815) 및 포트(816), 및 프로세싱되는 현재 메시지들에 관한 정보(817)를 포함할 수 있다.

[000159] (2)

변수는 착신 메시지들에 대해 청취하기 위해 이용되는, 포트

에 바운딩되는 실제 데이터그램 소켓 기술어를 포함할 수 있다. 이러한 소켓은 가능하다면, 클라이언트 노드 에이전트 또는 애플리케이션(예를 들어, EBIF 사용자 에이전트(410))이 활성화인 한 개방 상태로 남아있어야 한다. 그렇지 않으면, 소켓은 개방될 수 있으며 필요에 따라 초기화될 수 있다. 전형적으로 이 소켓은 표준 소켓 API들을 통해 생성된다. 그러나, 일부 구현들에서, 다른 소켓 획득 API들이 제공될 수 있다.

[000160] (3)

변수는

(612)를 통해 패킷 전송들을 스케줄링하기 위해

(606)에 의해 이용되는 송신 확률을 나타내는 값을 포함할 수 있다. 부동-소수점 숫자(즉, 0과 1 사이의 값)로서 확률을 나타내기보다는 오히려, 이 값은 손실 확률과 최근접 정수로 라운딩 업되는 65,536의 프로덕트(product)로서 더 편리하게 표현될 수 있다. 이 변수에 포함되는 값은

(700) 및 ACK 패킷들(720) 둘 다에서 TM 서버(210)에 의해 발송될 수 있다.

[000161] (4) 도 6b에 도시된 바와 같은 가상 소켓 테이블(820)은 S 가상 소켓 구조(810)를 포함하는 테이블(즉, 어레이, 목록 등)일 수 있으며, 여기서 S는 이용가능한 공간에 기초하여 특정되는 구현이지만, 현재 예시적인 실시예에 따라 기껏해야 16이다. 소켓 ID는 TM 패킷 헤더들에서의

(즉, 접속 ID) 필드(714, 724, 734)에 따라, 이 테이블로의 인덱스(예를 들어, 1..S 또는 0..S-1)이다. 소켓 ID는 또한 가상 소켓 기술어로서 알려질 수 있다.

[000162] (5)

변수는 프로그래머들에게 에러들을 보고하기 위해 TM 가상 소켓들에 의해 이용될 수 있다. 이 변수는 표준 소켓 API들에 의해 이용되는

변수에 더해질 수 있다.

[000163] (6) 도 6c에 도시된 바와 같은 예약 큐(800)는 각각이 송신할 패킷을 갖는 가상 소켓(820)을 식별하는, 예약들의 어레이(큐)일 수 있다. 새로운 패킷이 예약 큐(800)에 추가될 때마다 또는 큐에서의 제 1 패킷이 송신될 때마다, 큐에서의 다음 패킷을 송신할 시간이 계산될 수 있으며

에 저장될 수 있다. 이러한 계산은 이하의

의 정의에 주어지며, 여기서

는 계산 시의 슬롯 ID를 지칭한다.

[000164] (7)

변수는 다음 패킷이 송신되는(예약 큐를 참조) 슬롯 ID(또는 등가물)일 수 있다. 새로운

는 ACK(720) 또는

패킷들(700)을 통해 클라이언트에 도달할 때마다,

의 값은 재계산되어야 한다.

[000165] (8)

변수는 클라이언트 노드(예를 들어, STB) 상의 내부 클록 시간(GMT)에 추가될 때, TM 서버(210) 및 다른 클라이언트 노드들과 시간을 동기화하는 시간 오프셋을 표시할 수 있다. 올바르게 슬롯 ID들을 계산하기 위해 그리고 요구될 수 있는 다른 능력들에 대해 정확한 시간들이 필요하다.

메시지들의 보장된 전달

[000166] 다음의 단락들은 메시지들의 보장된 전달을 구현하기 위한 예시적인 실시예에 관하여 더 상세하게 제공한다. 먼저, 특정된 가상 소켓에 대한 예약이 이미 존재하며 예약된 슬롯 ID가 도달된 것으로 가정하면서, 모드 1의 문맥에서

(612)에 관한 상세들이 제공된다. 그 후에 다른 모드들에 대해 필요할 수 있는 추가들의 설명이 존재한다.

[000167] 상기에 주목된 바와 같이,

(612)는 그 BSD 소켓 카운터파트(counterpart)인

(506)와 같이, 하나의 호출에서 전체 메시지를 송신하도록 보장되지 않기 때문에, 메시지(또는 부분적 메시지)가 송신될 때까지 블로킹할 것이다. 이것은

(506)과의 쟁점이 아닐 수 있다. 그러나 본 발명의 다양한 예시적인 실시예들은 슬롯 충돌들을 회피하기 위해 시간을 통해 메시지 패킷들을 확산할 수 있기 때문에, 애플리케이션은 리턴할

(612)를 대기하는 수 초들 동안 블로킹될 수 있다. 이러한 이유로,

(612)는 데이터 패킷에 대한 예약 시간이 큰 경우에 호출자에게 제어를 되돌려 리턴할 것이다. 전체 메시지가 송신되지 않을 때,

(612)는 현재

값에 기초하여 다음의

(612) 호출에 대한 예약을 생성할 수 있다.

[000168] 일 예시적인 구현에서,

(612)는 메시지를 (MTU-5) 바이트들의 패킷들(또는 최종 패킷에 대해 더 적음)로 분해할 수 있으며,

(606)에 의해 스케줄링된 바와 같이 패킷들을 송신할 수 있다.

를 프로세싱하는 것은 다음과 같이 발생할 수 있다:

[000169] (1)

로 설정하고,

으로 설정한다.

[000170] (2)

로 설정한다.

[000171] (3)

,

를 설정하며

를 리턴한다.

[000172] (4)

,

를 설정하며

를 리턴한다.

[000173] (5)

,

밀리초들에 대해 슬립하며, 그 후에 단계 2로 되돌아간다.

[000174] (6)

에 대해 현재 진행중인 메시지가

상태에 있으며, 그 메시지 버퍼는

를 포함하면, 단계 8로 스킵한다.

[000175] (7) 가상 소켓 테이블(도 6b와 관련되는 논의를 참조)에서

에 대한 메시지 진행 데이터를 초기화한다.

[000176] (8)

메시지의 모든 패킷들이 아직 한번도 송신되지 않으면, 송신할 다음 패킷을 구성하고, 그에 따라 가상 소켓 구조를 업데이트하며, 단계 11로 스킵한다.

[000177] (9) 모든 송신된 패킷들이 아직 확인응답되지 않은 경우에, 최저-넘버링된 비확인응답된 패킷을 재구성하고,

플래그 비트를 설정하며, 그에 따라 메시지 구조를 업데이트하며,

를 증가시키며, 단계 11로 스킵한다.

[000178] (10) 가상 소켓의 메시지 정보를 업데이트하며,

를 리턴한다.

[000179] (11) 필요하다면 다음 SLOT 경계를 대기하며, (재)구성된 패킷을 송신한다.

[000180] (12)

를 설정하며, 단계 2로 되돌아간다.

[000181]

(612)의 이러한 정의는

(612)가 프로세싱하는 동안 비동기 시그널링 인터럽트들을 통해

(700) 및 ACK 패킷들(720) 둘 다의 수신이 취급되는 것으로 가정한다. 특히,

패킷들(700)은

(708) 및

을 업데이트하며, ACK 패킷들(720)은

(724)에 의해 정의되는 가상 소켓 구조(810)에서의

(726) 및

(728) 필드들을 업데이트하는 것을 가정한다. ACK 패킷(720)에 의해 모든 데이터 패킷이 확인응답될 필요성은 없다. 사실, ACK들(720)의 빈도수는 서버 로드에서의 변경 레이트(즉,

) 및 시퀀스를 벗어난 패킷들의 수신 레이트에 반비례할 수 있다. 이상적으로, 가벼운 로드 하에서, ACK(720)는 매 제 4 수신된 패킷에 대해 송신될 수 있다. 다양한 예시적인 실시예들에서, 유일한 요건은 ACK 패킷(720)이 메시지의 제 1 및 최종 패킷 둘 다에 대해 발생되어야 하는 것일 수 있다.

[000182] 모드 2에서, 가상 소켓이

(602)으로 개방될 때까지

이 할당되지 않으며 포트

에 바운드되며,

(606)는

(708)를 정의하기 위해

패킷(700)이 수신될 때까지 블로킹할 것을 제외하고, 상기에서 변경들이 존재하지 않는다.

[000183] 모드 3에서,

(606) 및/또는

(612)는

가 디폴트 송신 확률 값임을 가정하면서, 메시지에 대한

패킷(730)을 송신해야 하며, 진행하기 전에 (실제 송신 확률 값을 제공하는) 프로브에 대한 ACK 패킷(720)을 수신해야 한다. 짧은 타임아웃(예를 들어, 3초) 전에 이러한 프로브의 ACK(720)를 수신하는 것의 실패는 호출이 실패하게 야기하며,

에서 적절한 에러를 설정한다.

가상 소켓들

[000184] 다음의 단락들은 가상 소켓들 구현의 예시적인 실시예를 더 설명한다.

[000185] 본 발명의 다양한 예시적인 실시예들에 따른 트래픽 관리는 단일 데이터그램 소켓(즉,

기술어)을 이용하여 다음의 요건들을 충족시키려 노력할 수 있다:

[000186] (1) 다수의 스트림 소켓들의 효과를 모방한다;

[000187] (2) TM 서버(210)로부터 브로드캐스트되는

패킷들(700)을 청취한다; 그리고

[000188] (3) 애플리케이션 서버들로부터 클라이언트 노드(예를 들어, STB(400))에 유니캐스트되는 경보 메시지들을 청취한다. 이것은 모든 3개의 모드들에서 참이다. 유일한 차이는 청취의 시작시에 데이터그램 소켓이 얼마나 길에 유지되는지이다.

[000189]

(612) 및

(616)와 다른 TM 클라이언트 API들은

으로 아무것도 행하지 않을 수 있다. 대신에, 이들은 데이터 패킷들을 송신하거나 수신할 때 후속적으로 이용되는 가상 소켓 테이블(820)(또는 예약들 큐(800))에서 정보를 수정할 수 있다. 예를 들어, ACK 패킷(720) 또는 데이터 패킷(710)이 수신될 때, 패킷에서의 헤더 필드들은 어느 소켓이, 그리고 따라서 어느 콜백 함수가 패킷의 실제 수신자인지를 결정하기 위해 가상 소켓 테이블(820)에서의 데이터와 매칭될 수 있다.

[000190] 할당된

은

(즉, 1962)에 바운딩되며 시그널링 메커니즘을 통해 착신 트래픽에 대해 "청취"한다. 비-TM 패킷들을 필터링 아웃하고, 수신될 수 있는 다양한 패킷 타입들을 적절하게 처리하기 위해 착신 패킷들의

필드(702 712, 722, 732)가 검사된다.

패킷들(700)은 트래픽 보고 및 클라이언트 클록 동기화 섹션들에서 개시된 바와 같이 TM 서버(210) 및 TM 클라이언트(420)에 의해 내부적으로 처리될 수 있다. ACK(720) 및

(710) 패킷들(경보들과 다름)은 패킷이 속하는 가상 소켓 접속을 식별하는

필드(714, 724)(가상 소켓 테이블로의 인덱스)를 포함할 수 있다. 경보 메시지는 플래그 필드 비트, 경보에 의해 식별될 수 있으며,

및

비트들은 2-바이트 포트 번호를 정의하기 위해 조합된다; 그 포트 번호에 바운딩되는 가상 소켓은 메시지의 수신자이다.

[000191] TM 클라이언트(420)는

소켓 상의 활동(또는 에러들)이 존재할 때 다양한 TM 내부 루틴들을 인보크하기 위해 비동기 I/O 시그널링(SIGIO)에 의존할 수 있다. 예를 들어, (

(605)를 통해) 가상 소켓과 관련되는 TM 비동기 콜백 함수는 신호 처리기들에 의해 인보크될 수 있다.

[000192] 데이터를 송신하고 수신하기 위한 다양한 예시적인 실시예들은 메시지들의 보장된 전달 섹션에서 더 상세하게 설명된다.

메시지 데이터 압축

[000193] 케이블 OOB 네트워킹 환경의 하나의 독특한 점은 트래픽의 99%가 HTTP 메시지들로 이루어질 수 있다는 것이다. 따라서, 간단한 정적 압축 방법은 상당한 절감들을 발생시킬 수 있다. 다음과 유사한 정적 테이블-기반된 방식은 전송하기 전에 모든 메시지들을 압축하기 위해 사용될 수 있다. 압축해제는 간단해야 한다.

[000194] 본 압축 방식은 이진 데이터를 손상하지 않도록 의도된다. 따라서 항상 텍스트 데이터를 송신하지는 않을 수 있는 비-HTTP 프로토콜들에 대해 또한 적합할 수 있다.

송신 확률을 계산

[000195] 다음의 단락들은 송신 확률 값을 계산하기 위한 예시적인 방법을 설명한다.

[000196] TM 클라이언트들(420)과의 실제 통신을 처리하는 TM 서버(21) 사이의 인터페이스, 및 대역폭 규제 코드는 단일 API 호출을 이용하여 구현될 수 있다:

[000197]

[000198] TM 서버(420)가 임의의 클라이언트로부터 패킷을 수신할 때마다, 즉시

을 호출해야 한다. 패킷의 크기(즉, 헤더 + 페이로드)는

파라미터에서 전달될 수 있다. 패킷의

는 예상된 값(즉, 이전의 시퀀스 번호 + 1)이 아닌 경우에, 비-제로

값은

로 전달될 수 있으며, 그렇지 않으면 0

값이 본 파라미터에서 전달될 수 있다.

[000199]

의 리턴 값은 0, 또는 양의, 비-제로 정수일 수 있다. 리턴 값이 0인 경우에, 추가적인 동작이 요구되지 않는다. 그러나, 값이 비-제로인 경우에, 리턴 값은 새로운

로서 이용되어야 하며, ACK(720) 및

패킷들(700)을 통해 모든 TM 클라이언트들(420)에 전달될 수 있다.

[000200] 예시적인 실시예에서,

값은 (HFC 노드 당) 타겟 대역폭과 즉시의 장래를 위한 (HFC 노드 당) 예상된 대역폭 사이의 비일 수 있다. 타겟 대역폭은 최대값 바로 아래의 결과를 유지하기 위해 작은 조정 인수(예를 들어, 0.9)에 의해 곱해지는 간단하게 구성되는 (HFC 노드 당) 최대 대역폭이다. 예상되는 대역폭은 더 많은 패킷들을 송신할 각 HFC 노드에서 "활성화" STB들(즉, 클라이언트 노드들)의 수이다. 이것은

로서 추정될 수 있으며, 여기서 P는 SLOT 당 수신되는 패킷들의 계산된 평균 수이며,

는

의 이전 값이다.

[000201] 추가로, 조정 인수 K는 시스템 구성 값들, 및 비정기적 과도 효과들에서의 부정확성들을 처리하기 위해 주기적으로 계산될 수 있다.

인포 패킷들의 브로드캐스트 빈도수

[000202] 다음의 단락들은

패킷들(700)의 브로드캐스트 빈도수를 결정하기 위한 예시적인 방법을 설명한다.

[000203]

패킷(700) 발생의 빈도수는

의 리턴 값에 의해 구동될 수 있다. 이 함수가 비-제로 값을 리턴할 때마다, 새로운

패킷(700)이 브로드캐스트되어야 한다.

패킷들(700) 브로드캐스트들의 너무 빈번하거나 스퓨리어스한(spurious) 발생을 방지하기 위해 주의를 요해야 한다.

[000204] 구체적으로,

은 다른

패킷 브로드캐스트를 통해 전파하기 위해 비-제로

값을 리턴할 수 있다:

[000205] (a) 최종

패킷 브로드캐스트 이후에 10초가 경과하였거나,

[000206] (b) 최종

패킷 브로드캐스트 이후에 적어도 0.5초가 경과하였고

순서를 벗어난(out of order) 패킷들이 보여지거나,

[000207] (c) 최종

패킷 브로드캐스트 이후에 적어도 0.5초가 경과하였고

패킷들/초 레이트가 상향하는 경향이 있다.

[000208] 그렇지 않으면,

은 제로(0)를 리턴할 수 있으며

의 이전 값은 유효하게 남아있다.

대역폭 규제의 시뮬레이션

[000209] 본 섹션은 본 발명의 예시적인 실시예에 따른 대역폭 규제 방법의 예시적인 실시예의 시뮬레이션의 설명을 제시한다. 시뮬레이션이 안내되는 방법의 설명이 도 7a-7c에 도시된 바와 같은 결과들의 설명과 함께 제시된다.

[000210] 시뮬레이션은 QPSK 네트워크의 모델링을 포함하며 TM 서버(210)는 네트워크를 통해 다수의 TM 클라이언트들(420)과 통신한다. QPSK 네트워크 모델은 업스트림 및 다운스트림 스루풋을 모니터하며, 대역폭 제한들을 초과하는 어느 한쪽 방향으로 패킷들을 폐기한다.

[000211] 스루풋이 이론적인 대역폭 제한에 접근함에 따라, 패킷 손실의 확률이 1에 접근한다. 이론적인 최대 패킷 스루풋 업스트림을

로 두고, (TM 헤더들, 및 UDP/IP 헤더들의 28 바이트들을 포함하는) 모든 업스트림 패킷들의 어그리게이트 크기가 S 바이트들(또는

비트들)을 가정하면, 그 후에 다음 패킷이 소실될(그리고 전체적으로 무시되는) 확률은 다음에 의해 주어진다:

. 프로그램적으로, 다음의

조건은 이것을 테스트한다:

[000212] 도 7a-7c에 도시되는 시뮬레이션 결과들에서, 큰(구성가능한) 수의 STB들(400) 및 HFC 노드들(300)이 구성가능한 테스트 기간의 각 초에서 모든 125개의 SLOT들을 위해 시뮬레이팅되며, 1시간으로 설정된다.

[000213] 도 7a는 (HFC 노드(300) 당) 원대역폭(raw bandwidth) 로드가 1시간 시뮬레이션의 각 초에 걸쳐 평균되는 대역폭 규제 없이 네트워크 로드의 시뮬레이션을 도시하는 그래프이다.

[000214] 도 7b는 도 7a에서와 동일한 원대역폭 트래픽에 노출될 때, HFC 노드(300) 당 40 Kbps의 최대값을 위해 구성되는, 대역폭 규제를 갖는 네트워크 로드의 시뮬레이션을 도시하는 그래프이다. 각 경우에, 이제 평균 트래픽 로드가 40 Kbps에서 캡되고(capped) 높은 로딩의 기간들은 몇초 더 긴 것을 주목한다.

[000215] 도 7c는 대역폭 규제를 갖거나 갖지 않는 시뮬레이트된 네트워크 로드들 사이의 차이를 도시하는 그래프이다. 이 그래프는 2개의 이전 그래프들을 덮어씌우며 대역폭 관리된 트래픽에 대한 60-초 실행 평균을 표시하는 라인을 포함한다. 이 라인은 본원에 설명된 바와 같은, 본 발명의 다양한 예시적인 실시예들의 대역폭 규제 양상의 유익한 영향을 도시한다.

[000216] 본원에 개시되는 실시예들, 또는 실시예들의 일부분들은 특정 목적 컴퓨터, 마이크로컴퓨터를 포함하는 컴퓨터 시스템, 미니-컴퓨터, 또는 메인프레임, 예를 들어, 프로그램된 마이크로프로세서, 마이크로-제어기, 주변 집적된 회로 엘리먼트, CSIC(Customer Specific Integrated Circuit) 또는 ASIC(Application Specific Integrated Circuit) 또는 다른 집적된 회로, 논리 회로, 디지털 신호 프로세서, FPGA, PLD, PLA 또는 PAL과 같은 프로그램가능한 논리 디바이스, 또는 본원에 설명되는 프로세스들의 단계들 중 임의의 것을 구현할 수 있는 디바이스들의 장치 또는 임의의 다른 디바이스를 포함하는 널리 다양한 기술들 중 임의의 기술을 활용할 수 있다.

[000217] 본원에 설명되는 동작들 중 임의의 동작을 수행하기 위해 컴퓨터 운영 시스템을 구성하는 명령들의 세트(예를 들어, 컴퓨터 소프트웨어)가 원하는대로, 널리 다양한 매체 또는 매체들 중 임의의 것 상에 포함될 수 있음이 인식될 것이다. 또한, 명령들의 세트에 의해 프로세싱되는 임의의 데이터는 또한 널리 다양한 매체 또는 매체들 중 임의의 것 상에 포함될 수 있다. 즉, 본원에 설명되는 실시예들에 이용되는 데이터 또는 명령들의 세트를 유지하기 위해 활용되는 특정 매체(예를 들어, 메모리)는 예를 들어, 다양한 물리적 형태들 또는 전송들 중 임의의 것을 취할 수 있다. 예시적으로, 매체는 컴팩트 디스크, DVD, 집적된 회로, 하드 디스크, 플로피 디스크, 광학 디스크, 자기 테이프, RAM, ROM, PROM, EPROM, 와이어, 케이블, 파이버, 통신들 채널, 위성 전송들 또는 다른 원격 전송뿐 아니라 컴퓨터에 의해 판독될 수 있는 데이터의 소스 또는 임의의 다른 매체의 형태일 수 있다.

[000218] 컴퓨터 실행하는 실행가능한 컴퓨터 소프트웨어와 같은, 본원에 설명되는 다양한 컴포넌트들은 원격으로 위치될 수 있으며, 하나 또는 그 초과의 컴퓨터 네트워크들을 통한 전자 전송을 통해 서로 통신할 수 있음이 또한 인식될 것이다. 본원에 지칭된 바와 같이, 네트워크는 광역 네트워크(WAN), 로컬 영역 네트워크(LAN), 인터넷과 같은 글로벌 네트워크, 공중 교환 전화 네트워크와 같은 전화 네트워크, 무선 통신 네트워크, 셀룰러 네트워크 인트라넷 등 또는 그의 임의의 조합을 포함할 수 있지만, 이들로 제한되지 않는다. 다양한 예시적인 실시예들에서, 네트워크는 자립형 네트워크로서 또는 서로 협력하여 동작하는, 상기 언급된 하나 또는 임의의 수의 예시적인 타입들의 네트워크들을 포함할 수 있다. 본원의 용어 네트워크의 이용은 단일 네트워크에 네트워크를 제한하도록 의도되지 않는다.

[000219] 본 발명은 넓은 유틸리티 및 애플리케이션에 민감한 것이 당업자에 의해 용이하게 이해될 것이다. 본원에 개시되는 것들과 다른 본 발명의 많은 실시예들 및 적응들뿐 아니라, 많은 변형들, 수정들 및 등가 배치들은 본 발명의 범위 또는 실체로부터 이탈하지 않고서, 본 발명 및 그의 전술한 설명으로부터 명백해지거나 그에 의해 합리적으로 제안될 것이다.

[000220] 전술한 바는 본 발명의 예시적인 실시예들을 예시하고 설명하는 한편, 본 발명이 본원에 개시되는 구성에 제한되지 않음이 이해될 것이다. 본 발명은 그 정신 또는 본질적 속성들로부터 이탈하지 않고서 다른 특정 형태들로 구체화될 수 있다.

Claims

통신 네트워크 대역폭을 규제하기 위한 방법으로서,
중앙집중화 트래픽 관리 서버를 이용하여 네트워크를 통해 데이터 트래픽을 모니터링하는 단계 ―상기 트래픽 관리 서버는 적어도 하나의 클라이언트 노드에 의해 송신되는 착신 패킷들의 샘플을 계속해서 모니터링함―;
네트워크 로드들(loads)을 예측하는 단계 ―상기 트래픽 관리 서버는 착신 패킷들의 빈도수, 변화율, 및 샘플의 컨텐츠에 기초하여 로드 정보를 계산함―;
네트워크 트래픽을 스케줄링하는 단계 ―상기 트래픽 관리 서버 및 상기 적어도 하나의 클라이언트 노드는 데이터 패킷의 향후(upcoming) 전송을 위한 스케줄링된 시간을 결정하기 위해 메시지를 교환함―; 및
데이터를 전송하는 단계 ―상기 적어도 하나의 클라이언트 노드는 상기 스케줄링된 시간에서 상기 네트워크를 통해 상기 데이터 패킷을 전송함―
를 포함하는, 통신 네트워크 대역폭을 조절하기 위한 방법.
제 1 항에 있어서,
필요한 경우에 상기 데이터 패킷을 재전송하는 단계를 더 포함하며, 상기 적어도 하나의 노드는 상기 트래픽 관리 서버로부터 확인응답이 수신되지 않는 경우에 상기 데이터 패킷을 재전송하는, 통신 네트워크 대역폭을 조절하기 위한 방법.
제 1 항에 있어서,
상기 네트워크는 인터랙티브(interactive) 디지털 케이블 텔레비전 네트워크인, 통신 네트워크 대역폭을 조절하기 위한 방법.
제 3 항에 있어서,
상기 케이블 텔레비전 네트워크는, 사용자 데이터그램 프로토콜(UDP)을 통해 하이퍼텍스트 전송 프로토콜(HTTP)을 이용하여 대역 외 채널을 통해 복수의 셋-탑 박스들과 통신하는 강화된 텔레비전 플랫폼 서버를 포함하는, 통신 네트워크 대역폭을 조절하기 위한 방법.
제 4 항에 있어서,
상기 셋-탑 박스들은 EBIF(Enhanced TV Binary Interchange Format) 사용자 에이전트 상에서 실행되는 EBIF을 이용하여 구현되는 인터랙티브 애플리케이션들을 실행하는, 통신 네트워크 대역폭을 조절하기 위한 방법.
제 1 항에 있어서,
상기 트래픽은:
인터랙티브 애플리케이션 통신, 의결(voting) 및 투표(polling) 데이터, 텔레비전 사용 데이터, 사용자 선호도 및 통계들 트래픽, 및 t-커머스 정보 중 적어도 하나를 포함하는, 통신 네트워크 대역폭을 조절하기 위한 방법.
제 1 항에 있어서,
상기 스케줄링하는 단계 및 상기 전송하는 단계는:
상기 트래픽 관리 서버 상의 네트워크 트래픽 조건들에 응답하여 송신-확률 값을 설정하는 단계;
상기 트래픽 관리 서버로부터 상기 적어도 하나의 클라이언트 노드에 상기 송신-확률 값 및 클록 동기화 정보를 전송하는 단계;
랜덤화된 데이터 전송 시간을 계산하기 위해 상기 적어도 하나의 클라이언트 노드에서 상기 송신-확률 값 및 동기화 정보를 활용하는 단계;
계산된 랜덤화된 데이터 전송 시간에서 상기 적어도 하나의 클라이언트 노드에 의해 데이터 패킷을 전송하는 단계;
상기 트래픽 관리 서버에 의해 확인응답 패킷을 발생시키고 이를 상기 적어도 하나의 클라이언트 노드들에 송신하는 단계 ―상기 확인응답은 이전 전송의 성공을 표시하며 다음 전송을 위한 새로운 송신-확률 값을 제공함―; 및
확인응답 패킷이 수신되지 않은 경우, 새로운 데이터 전송 시간에서 상기 적어도 하나의 클라이언트 노드에 의해 상기 데이터 패킷을 재전송하는 단계
를 포함하는, 통신 네트워크 대역폭을 조절하기 위한 방법.
제 7 항에 있어서,
상기 송신-확률 값은 상기 다음 전송에서의 패킷이 송신되어야 하는 시간의 윈도우에 반비례하며, 상기 랜덤화된 데이터 전송 시간은 상기 윈도우 내의 랜덤 시간이며, 상기 확인응답 패킷 및 데이터 패킷의 각각은 상기 윈도우 내의 별개의 타임슬롯 경계들 상에 전송되는, 통신 네트워크 대역폭을 조절하기 위한 방법.
제 7 항에 있어서,
상기 송신-확률 값은 전송 에러들 및 확인응답 타임아웃들 없이 시간이 경과함에 따라 상기 적어도 하나의 클라이언트 노드에서 점진적으로 증가되는, 통신 네트워크 대역폭을 조절하기 위한 방법.
제 7 항에 있어서,
상기 송신 확률은: 전송 에러 및 확인응답 타임아웃 중 적어도 하나에 응답하여 감소되는, 통신 네트워크 대역폭을 조절하기 위한 방법.
제 7 항에 있어서,
상기 트래픽 관리 서버로부터 상기 송신-확률 값 및 클록 동기화 정보를 전송하는 단계는 상기 적어도 하나의 클라이언트 노드에 대한 주기적 브로드캐스트를 통해 이루어지는, 통신 네트워크 대역폭을 조절하기 위한 방법.
제 7 항에 있어서,
상기 트래픽 관리 서버로부터 상기 송신-확률 값 및 클록 동기화 정보를 전송하는 단계는 적어도 하나의 클라이언트 노드에 대한 내로우캐스트(narrowcast)를 통해 이루어지는, 통신 네트워크 대역폭을 조절하기 위한 방법.
제 7 항에 있어서,
상기 트래픽 관리 서버로부터 송신-확률 값 및 클록 동기화 정보를 전송하는 단계는 상기 적어도 하나의 클라이언트 노드가 상기 데이터 패킷을 전송하기 위한 권한을 요청하는 프로브 데이터 패킷을 상기 트래픽 관리 서버에 송신한 후에 발생하는, 통신 네트워크 대역폭을 조절하기 위한 방법.
제 1 항에 있어서,
상기 네트워크는 대역-내(in-band) 케이블 텔레비전, DSL, 또는 이동 광대역 네트워크인, 통신 네트워크 대역폭을 조절하기 위한 방법.
제 1 항에 있어서,
상기 네트워크는 사용자 데이터그램 프로토콜(UDP) 또는 전송 제어 프로토콜(TCP)을 활용하는, 통신 네트워크 대역폭을 조절하기 위한 방법.
제 1 항에 있어서,
상기 트래픽 관리 서버는 트래픽 관리 정보를 포함하는 적어도 하나의 UDP 패킷을 적어도 하나의 TCP 패킷으로 변환하는 UDP-대-TCP 릴레이 서버로서 서빙하는, 통신 네트워크 대역폭을 조절하기 위한 방법.
제 2 항에 있어서,
상기 적어도 하나의 클라이언트 노드 상에 실행하는 트래픽 관리 클라이언트는 클라이언트 애플리케이션들의 지원시에 데이터의 재전송, 데이터의 전송 및 트래픽의 스케줄링을 관리하는, 통신 네트워크 대역폭을 조절하기 위한 방법.
제 17 항에 있어서,
상기 트래픽 관리 클라이언트는 단일 데이터그램 소켓 또는 포트를 이용하면서 다수의 동시적 가상 스트림 소켓들 및 접속들을 제공하는, 상기 클라이언트 애플리케이션에 대한 표준 스트림 소켓 애플리케이션 프로그래밍 인터페이스를 모방하는, 통신 네트워크 대역폭을 조절하기 위한 방법.
제 17 항에 있어서,
상기 데이터를 전송하는 단계 및 재전송하는 단계는, 상기 클라이언트 애플리케이션이 상기 데이터를 송신하기 전에 스케줄링된 데이터 전송 시간을 대기하도록 동기화 방식으로 구현되는, 통신 네트워크 대역폭을 조절하기 위한 방법.
제 17 항에 있어서,
상기 데이터를 전송하는 단계 및 재전송하는 단계는, 상기 네트워크가 데이터 전송을 위해 준비될 때 콜-백(call-back)이 상기 클라이언트 애플리케이션에 대해 상기 트래픽 관리 클라이언트에 의해 발행되도록 비동기 방식으로 구현되는, 통신 네트워크 대역폭을 조절하기 위한 방법.
제 2 항에 있어서,
상기 스케줄링하는 단계, 전송하는 단계 및 재전송하는 단계는 상기 적어도 하나의 클라이언트 노드 상에서 실행하는 적어도 하나의 애플리케이션에 노출되며 사용자를 지향하는(user-facing) 행동을 조정하기 위해 이용되는, 통신 네트워크 대역폭을 조절하기 위한 방법.
제 2 항에 있어서,
상기 데이터를 전송하는 단계 및 재전송하는 단계는 정적 테이블을 이용하여 상기 데이터를 압축하는 단계를 더 포함하며, 스트링 값들을 갖는 복수의 표준 HTTP 메시지 엘리먼트들은 각각 테이블 인덱스를 할당받으며, 인덱스들이 상기 스트링 값들 대신에 전송되며, 상기 스트링 값들은 상기 정적 테이블을 활용함으로써 수신시 재구성되는, 통신 네트워크 대역폭을 조절하기 위한 방법.
제 1 항에 있어서,
외부 이벤트에 사전에 응답하는 대역폭 규제 서버를 더 포함하며, 상기 외부 이벤트는: 하루 중 시간의(time-of-day) 대역폭 로드, 연중 시간의 대역폭 로드 및 뉴스 속보(breaking news) 경보로부터 선택되는, 통신 네트워크 대역폭을 조절하기 위한 방법.
통신 네트워크 대역폭을 규제하기 위한 시스템으로서,
네트워크;
적어도 하나의 클라이언트 노드;
중앙집중화된 트래픽 관리 서버를 포함하며,
상기 중앙집중화된 트래픽 관리 서버는,
상기 네트워크를 통해 데이터 트래픽을 모니터하고 ―상기 트래픽 관리 서버는 상기 적어도 하나의 클라이언트 노드에 의해 송신되는 착신 패킷들의 샘플을 연속적으로 모니터함―;
네트워크 로드들을 예측하고 ―상기 트래픽 관리 서버는 착신 패킷들의 빈도수, 변화율, 및 상기 샘플의 컨텐츠에 기초하여 로드 정보를 계산함―; 및
네트워크 트래픽을 스케줄링하도록 ―상기 트래픽 관리 서버 및 상기 적어도 하나의 클라이언트 노드는 데이터 패킷의 향후 전송을 위한 스케줄링된 시간을 결정하기 위해 메시지를 교환함―
구성되는, 통신 네트워크 대역폭을 조절하기 위한 시스템.