Extend 채널을 위해, headend 와의 물리적 통신 link 를 제공하는 장치(pod or host)는 링크 device 로 부르게 된다. pod module 은 qpsk 모뎀의 링크 device 이다. host 는 high speed host modem 의 링크 device 이다. extend channel support 리소스는 extend channel 에 data들을 송수신 할 인터렉티브한 application을 만들 것이다.

모든 host 는 pod 를 위해 qpsk 를 지원하기 위해 필요한 hardware 에 downstream oob channel 을 제공하는 것을 요구 한다.
pod 는 적절하게 host 에 의해 요청되거나 하나 이상의 데이터 플로우를 통하여, host 에 이 채널에 받게되는 데이터들을 전송할 것이다.
어떤 경우에서, pod 는 그것 자신으로 그것(ex: EMMs) 을 사용하는 것에 의해 qpsk downstream oob 채널에 받게되는 데이터들을 끝낼 것이다.
다른 경우에서는 그것은 host 에 중요하지 않다고 알려진 function 과 discard 되는 데이터를 실행할 수도 있다.

시스템 아키텍쳐들은 extend channel support 리소스를 사용하는 두가지의 다른 방법을 제공한다.

1. application 은 qpsk 모뎀을 거쳐 headend 로 부터 옮겨지던 host 와 데이터이다.
2. application 은 호스트의 high speed host modem 을 거쳐 headend 로 부터 옮겨지던 pod 모듈과 data 이다.

이 리소스는 2개의 버전이 있다. DOCSIS 모뎀이 없는 버전1과 DOCSIS 모뎀이 있는 버전2이다. 버전2는 모든 버전1을 지원한다.

테이블 섹션이 긴 형태(section_syntax_indicator flag 가 1 로 세팅이되므로해서 지시된), 32비트 CRC 가 존재한다. 이것은 또한 짧은 형태의 섹션이 있다. (section_syntax 지시자에 의해 0 이 세팅된) si_base_PID(0xffc) 를 전달한다.
mpeg-2 crc 가 사전에 셋팅된다고 알져진 테이블 섹션들을 위해, pod 모듈은 테이블 섹션 레벨이 32비트 crc를 사용하는 테이블 섹션인지 또는, 다른 protocol layer 의 32비트 crc 를 검사한다. crc 체크를 통과하는 메세지들만 host 에 전송된다.
pod 모듈은 완성되지 않았거나, crc 체크의 실패를 한 테이블 섹션은 삭제한다.

32 비트의 crc 는 si_base_PID (0x1ffc) 이외의 pid 값들과 관련있는 짧은 형태의 섹션들에서 있을지도 또한 없을지도 모른다. 그리고 pod 모듈은 어떤 체크가 없는 호스트에게 이 섹션을 보낼 수도 있다. 이 경우 host 는 이 섹션에 대해 확인에 대해 책임이 있다.

다음은 host 와 pod 에 다음의 필요한 것들을 요구한다.

1. pod 모듈 인터페이스는 최소 동시에 6개 mpeg_section service_type 플로우를 지원해야 한다.
2. pod 모듈 인터페이스는 최소 하나의 ip_u service_type 플로우를 지원해야 한다.
3. 만일 service information virtual channel table 이 하나 또는 그 이상의 서비스를 oob 로 전달하는 것으로 정의되면, pod 모듈은 하나 이상의 추가된 mpeg_section 타입의 flow 들을 지원한다.
4. 만일 host 가 dsg 를 지원하면, 그것은 하나의 dsg service_type flow 를 지원한다.
5. 호스트가 unicast ip flow 를 지원하면, dhcp 사용해서, pod 모듈사용하는 ip 주소를 얻을 수 있다. 호스트는 dhcp 메세지를 만드는 new_flow_req() 의 pod 모듈에 의해 옵션 파라미터가 지원된다. 그리고 어떤 옵션이든지 필요하거나 요구한다.
6. pod 모듈과 host 는 오직 한번에 하나의 new_flow_req() 수송을 지원하기를 요청한다. pod 모듈과 host 는 반드시 new_flow_cnf() 와 함께 status_field(0x04)를 addtional 한 new_flow_req()받게 될 때 보낸다.

interactive application 은 반드시 delete_flow_req() 로 등록된 data flow 를 지운다. link 디바이스는 delete_flow_cnf() 를 delete_flow_req() 의 응답으로 보낸다.

link 디바이스는 lost_flow_ind() 에 의해 잃었던 등록된 데이터 flow 를 가리킨다. application 은 lost_flow_ind()의 응답으로 lost_flow_cnf 를 함께 보낸다.

version2 의 extended channel support 리소스에서는 3개가 추가되었다.

호스트는 inquire_dsg_mode() 를 통해서 어떤것이 우선권이 있는지 물어볼 수 있다.

pod 는 네트워크를 통해 host에 우선권이 있는 사용할 수 있는 모드를 알려주는데 set_dsg_mode()를 사용할 것이다.
이 메세지는 inquire_dsg_mode 에 대응하여 보내진다. 메세지 또는 그것이 자발적인 메세지로 보낼지도 모른다.
pod 가 우선권이 있는 사용할 수 있는 모드를 결정하는 방법은 ca/pod 시스템 판매인의 소유이다.

1. 호스트 또는 pod가 lnquire_dsg_mode 와 set_dsg_mode 메세지를 지원하지 않을 때
2. pod 가 네트워크 오류 때문에 우선권이 있는 모드로 가지 못했을 때

경우 a 는 하위 호환성을 보증하기 위해, advanced 호스트는 oob_mode 의 기본적으로 사용할 수 있는 초기화를 할 것이다.
경우 b 는 pod 모듈이 우선권이 있는 oob_mode 통보해야 한다.

만일 사용할 수 있는 모드가 dsg_mode 또는 one-way_mode 라면, pod module 은 최고 8개의 이더넷 mac address 들과 dsg tunnel packet 으로 부터 지워지는 헤더 바이트의 수를 제공할 것이다.

dsg 또는 one-way mode 에서 host 는 dsg_max_address의 무엇이든 이더넷 수신 어드레스가 매칭이 했던 ip 패킷을 필터링해야 하고, 이 패킷으로 부터 헤더 바이트 의 지시하는 수를 지운다. drx 핀을 가로질러, 나란히 bit-stream 을 만들어야 한다.