Cisco uBR CMTS의 업스트림 스케줄러 모드 컨피그레이션

다운로드 옵션

PDF (598.6 KB)
다양한 디바이스에서 Adobe Reader로 보기
ePub (574.4 KB)
iPhone, iPad, Android, Sony Reader 또는 Windows Phone의 다양한 앱에서 보기
Mobi (Kindle) (1.8 MB)
Kindle 디바이스에서 보기 또는 다양한 디바이스의 Kindle 앱에서 보기

업데이트:2006년 4월 3일 (월)

문서 ID:69704

편견 없는 언어

본 제품에 대한 문서 세트는 편견 없는 언어를 사용하기 위해 노력합니다. 본 설명서 세트의 목적상, 편견 없는 언어는 나이, 장애, 성별, 인종 정체성, 민족 정체성, 성적 지향성, 사회 경제적 지위 및 교차성에 기초한 차별을 의미하지 않는 언어로 정의됩니다. 제품 소프트웨어의 사용자 인터페이스에서 하드코딩된 언어, RFP 설명서에 기초한 언어 또는 참조된 서드파티 제품에서 사용하는 언어로 인해 설명서에 예외가 있을 수 있습니다. 시스코에서 어떤 방식으로 포용적인 언어를 사용하고 있는지 자세히 알아보세요.

이 번역에 관하여

Cisco는 전 세계 사용자에게 다양한 언어로 지원 콘텐츠를 제공하기 위해 기계 번역 기술과 수작업 번역을 병행하여 이 문서를 번역했습니다. 아무리 품질이 높은 기계 번역이라도 전문 번역가의 번역 결과물만큼 정확하지는 않습니다. Cisco Systems, Inc.는 이 같은 번역에 대해 어떠한 책임도 지지 않으며 항상 원본 영문 문서(링크 제공됨)를 참조할 것을 권장합니다.

소개

이 문서에서는 Cisco uBR(Universal Broadband Router) 시리즈 CMTS(Cable Modem Termination Systems)의 업스트림 스케줄러 모드 컨피그레이션에 대해 설명합니다.

이 문서에서는 IP를 통한 음성 또는 비디오와 같이 레이턴시와 지터에 민감한 업스트림 서비스를 사용하는 고속 Data-over-cable 네트워크의 설계 및 유지 보수를 담당하는 직원을 중점적으로 살펴봅니다.

사전 요구 사항

요구 사항

다음 주제에 대한 지식을 보유하고 있으면 유용합니다.

DOCSIS(Data over Cable Service Interface Specification) 시스템
Cisco uBR 시리즈 CMTS

사용되는 구성 요소

이 문서의 정보는 다음 소프트웨어 및 하드웨어 버전을 기반으로 합니다.

Cisco uBR CMTS
Cisco IOS® 소프트웨어 릴리스 12.3(13a)BC 및 12.3(17a)BC 교육

참고: Cisco IOS Software의 이후 릴리스의 변경 사항에 대한 자세한 내용은 Cisco.com 웹 사이트에서 제공되는 해당 릴리스 정보를 참조하십시오.

표기 규칙

문서 규칙에 대한 자세한 내용은 Cisco 기술 팁 표기 규칙을 참고하십시오.

배경 정보

DOCSIS(Data-over-Cable Service Interface Specifications) 네트워크에서 CMTS는 케이블 모뎀이 만드는 모든 업스트림 전송의 시기와 속도를 제어합니다. 레이턴시, 지터 및 처리량 요구 사항이 서로 다른 여러 종류의 서비스가 최신 DOCSIS 네트워크 업스트림에서 동시에 실행됩니다. 따라서 CMTS에서 케이블 모뎀이 이러한 다양한 서비스 유형을 대신하여 업스트림 전송을 수행할 수 있는 시기를 어떻게 결정하는지 이해해야 합니다.

이 백서에는 다음이 포함됩니다.

DOCSIS의 업스트림 스케줄링 모드 개요(최선형, UGS(Unordered Grant Service) 및 RTPS(Real Time Polling Service) 포함)
Cisco uBR CMTS용 DOCSIS 호환 스케줄러의 작업 및 구성
Cisco uBR CMTS를 위한 새로운 짧은 대기 시간 대기열 스케줄러 작업 및 구성

DOCSIS의 업스트림 스케줄링

DOCSIS 호환 CMTS는 서비스 흐름의 개념을 통해 서로 다른 패킷 스트림 또는 애플리케이션에 대해 서로 다른 업스트림 스케줄링 모드를 제공할 수 있습니다. 서비스 흐름은 데이터의 업스트림 또는 다운스트림 흐름을 나타내며, SFID(Service Flow ID)는 고유하게 식별합니다. 각 서비스 흐름에는 고유한 QoS(Quality of Service) 매개변수(예: 최대 처리량, 최소 보장 처리량 및 우선 순위)가 포함될 수 있습니다. 업스트림 서비스 흐름의 경우 스케줄링 모드를 지정할 수도 있습니다.

각 케이블 모뎀에 대해 서로 다른 유형의 애플리케이션을 수용할 수 있도록 둘 이상의 업스트림 서비스 흐름을 가질 수 있습니다. 예를 들어 웹과 이메일은 하나의 서비스 흐름을 사용할 수 있고, VoIP(Voice over IP)는 다른 서비스를 사용할 수 있으며, 인터넷 게임에서는 또 다른 서비스 흐름을 사용할 수 있습니다. 이러한 각 애플리케이션에 적절한 서비스 유형을 제공하려면 이러한 서비스 흐름의 특성이 달라야 합니다.

케이블 모뎀과 CMTS는 분류자를 사용하여 올바른 유형의 트래픽을 적절한 서비스 플로우로 전달할 수 있습니다. 분류자는 UDP 및 TCP 포트 번호와 같은 패킷 속성을 일치시켜 패킷이 통과할 적절한 서비스 흐름을 결정하는 액세스 목록과 같은 특수 필터입니다.

그림 1에서 케이블 모뎀에는 업스트림 서비스 플로우가 3개 있습니다. 첫 번째 서비스 흐름은 음성 트래픽용으로 예약됩니다. 이 서비스 흐름은 최대 처리량이 낮지만 짧은 레이턴시를 보장하도록 구성됩니다. 다음 서비스 흐름은 일반 웹 및 이메일 트래픽에 대한 것입니다. 이 서비스 흐름은 처리량이 높습니다. 최종 서비스 흐름은 P2P(peer to peer) 트래픽용으로 예약됩니다. 이 서비스 흐름에는 이 애플리케이션의 속도를 조절하기 위한 보다 제한적인 최대 처리량이 있습니다.

그림 1 - 3개의 업스트림 서비스 플로우가 있는 케이블 모뎀

케이블 모뎀이 처음 온라인 상태가 되면 서비스 흐름이 설정 및 활성화됩니다. 케이블 모뎀을 구성하는 데 사용하는 DOCSIS 구성 파일에서 서비스 흐름의 세부 정보를 프로비저닝합니다. DOCSIS 컨피그레이션 파일에서 업스트림 트래픽에 대해 하나 이상의 서비스 흐름 및 다운스트림 트래픽에 대한 다른 서비스 흐름을 프로비저닝합니다. DOCSIS 구성 파일에 지정하는 첫 번째 업스트림 및 다운스트림 서비스 흐름을 기본 서비스 플로우라고 합니다.

케이블 모뎀이 온라인 상태가 된 후 서비스 흐름을 동적으로 생성하고 활성화할 수도 있습니다. 이 시나리오는 일반적으로 VoIP 전화 통화에 속하는 데이터에 해당하는 서비스 흐름에 적용됩니다. 이러한 서비스 흐름은 전화 통화가 시작될 때 생성 및 활성화됩니다. 그런 다음 통화가 종료되면 서비스 흐름이 비활성화되고 삭제됩니다. 필요한 경우에만 서비스 흐름이 존재하는 경우 업스트림 대역폭 리소스 및 시스템 CPU 로드 및 메모리를 저장할 수 있습니다.

케이블 모뎀은 업스트림 전송을 언제든지 만들 수 없습니다. 대신, 모뎀은 한 번에 하나의 케이블 모뎀만 업스트림 채널에 데이터를 전송할 수 있으므로 CMTS의 명령을 기다려야 데이터를 전송할 수 있습니다. 그렇지 않으면 전송이 오버런 및 손상될 수 있습니다. 케이블 모뎀이 CMTS에서 대역폭 할당 MAP 메시지의 형태로 전송할 수 있는 경우에 대한 지침. Cisco CMTS는 케이블 모뎀이 어떤 종류의 전송도 할 수 있을 때 알려 주기 위해 2밀리초마다 MAP 메시지를 전송합니다. 각 MAP 메시지에는 모뎀에 전송 시간을 정확하게 지시하는 정보, 전송 시간, 전송 가능한 데이터 유형 등을 포함합니다. 따라서 케이블 모뎀 데이터 전송이 서로 충돌하지 않고 데이터 손상을 방지합니다. 이 섹션에서는 CMTS가 업스트림에서 전송을 수행할 수 있는 케이블 모뎀 권한을 부여할 시기를 결정하는 몇 가지 방법에 대해 설명합니다.

최선의 노력

최선의 노력 스케줄링은 지연 시간 또는 지터에 대한 엄격한 요구 사항 없이 일반적인 인터넷 애플리케이션에 적합합니다. 이러한 애플리케이션 유형의 예로는 이메일, 웹 브라우징 또는 피어 투 피어 파일 전송이 있습니다. 지연 또는 지터가 보장되는 애플리케이션(예: 음성 또는 VoIP)에는 최선형 스케줄링이 적합하지 않습니다. 이는 병목이 심한 상황에서 최상의 노력 모드에서 이러한 보증을 수행할 수 없기 때문입니다. DOCSIS 1.0 시스템에서는 이 유형의 예약만 허용합니다.

최상의 서비스 흐름은 일반적으로 케이블 모뎀과 연결된 DOCSIS 구성 파일에서 프로비저닝됩니다. 따라서 최상의 서비스 흐름은 일반적으로 케이블 모뎀이 온라인 상태가 되는 즉시 활성화됩니다. DOCSIS 구성 파일에 프로비저닝되는 첫 번째 업스트림 서비스 흐름인 기본 업스트림 서비스 흐름은 최상의 작업 스타일 서비스 흐름이어야 합니다.

다음은 DOCSIS 1.1/2.0 모드에서 최선형 서비스 흐름을 정의하는 가장 일반적으로 사용되는 매개변수입니다.

최대 지속 트래픽 속도(R)

Maximum Consistent Traffic Rate는 이 서비스 플로우를 통해 트래픽이 작동할 수 있는 최대 속도입니다. 이 값은 초당 비트 수로 표시됩니다.
최대 트래픽 버스트(B)

Maximum Traffic Burst(최대 트래픽 버스트)는 업스트림 처리량 제한을 적용하는 토큰 버킷 속도 제한에 적용되는 버스트 크기(바이트)를 나타냅니다. 값을 지정하지 않으면 기본값인 3044가 적용됩니다. 이 값은 두 개의 전체 이더넷 프레임 크기입니다. 최대 지속 트래픽 속도를 유지하려면 이 값을 최소 최대 지속 트래픽 속도 64로 나눈 값으로 설정합니다.
트래픽 우선 순위

이 매개변수는 0(최저)부터 7(최고)까지의 서비스 흐름에서 트래픽의 우선순위를 나타냅니다. 업스트림에서 우선 순위가 높은 서비스 플로우에 대해 보류 중인 모든 트래픽은 우선 순위가 낮은 서비스 플로우에 대한 트래픽보다 먼저 전송하도록 예약됩니다.
최소 예약 비율

이 매개변수는 CIR(Committed Information Rate)과 유사하게 서비스 플로우의 최소 보장 처리량(비트/초)을 나타냅니다. 채널의 모든 서비스 흐름에 대해 예약된 최소 요금이 결합된 경우 해당 채널의 가용 대역폭을 초과할 수 없습니다. 그렇지 않으면 약속된 최저 예약율을 보장하는 것은 불가능하다.
최대 연결 버스트

Maximum Concatenated Burst는 모뎀이 서비스 흐름을 대신하여 만들 수 있는 연결 프레임을 가장 많이 전송하는 바이트 단위의 크기입니다. 이 매개변수에서 알 수 있듯이 모뎀은 한 번의 전송 버스트 내에서 여러 프레임을 전송할 수 있습니다. 이 값을 지정하지 않으면 DOCSIS 1.0 케이블 모뎀과 이전 DOCSIS 1.1 모뎀은 연결된 버스트 크기에 명시적 제한이 설정되어 있지 않다고 가정합니다. DOCSIS 1.1 이상 사양 최신 버전과 호환되는 모뎀은 1522바이트의 값을 사용합니다.

케이블 모뎀에 업스트림 최선형 서비스 흐름 대신 전송할 데이터가 있는 경우 모뎀은 지연 없이 DOCSIS 네트워크로 데이터를 단순히 전달할 수 없습니다. 모뎀은 모뎀이 CMTS에서 배타적 업스트림 전송 시간을 요청하는 프로세스를 거쳐야 합니다. 이 요청 프로세스는 데이터가 동일한 업스트림 채널에 연결된 다른 케이블 모뎀의 전송과 충돌하지 않도록 합니다.

때때로 CMTS는 CMTS가 케이블 모뎀에서 대역폭 요청이라는 특수 메시지를 전송할 수 있도록 하는 특정 기간을 예약합니다. 대역폭 요청은 모뎀이 전송하려는 데이터의 양에 대한 세부 정보를 포함하는 매우 작은 프레임과 데이터를 전송해야 하는 업스트림 서비스 흐름에 해당하는 SID(서비스 식별자)를 포함합니다. CMTS는 SID 번호와 일치하는 내부 테이블을 업스트림 서비스 플로우에 유지 관리합니다.

CMTS는 업스트림에서 다른 이벤트가 예약되지 않은 경우 대역폭 요청 기회를 예약합니다. 다시 말해, 업스트림 스케줄러가 최적 작업 부여 또는 UGS 부여 또는 특정 시점에 부여될 다른 유형의 부여를 계획하지 않은 경우 스케줄러는 대역폭 요청 기회를 제공합니다. 따라서 업스트림 채널이 많이 사용될 경우 케이블 모뎀에서 대역폭 요청을 전송할 기회가 더 적습니다.

CMTS는 업스트림 채널이 얼마나 혼잡하건 상관없이 적은 수의 대역폭 요청 기회가 정기적으로 스케줄링되도록 보장합니다. 여러 케이블 모뎀은 대역폭 요청을 동시에 전송할 수 있으며 서로의 전송을 손상시킬 수 있습니다. 대역폭 요청을 손상시킬 수 있는 충돌 가능성을 줄이기 위해 "백오프 및 재시도" 알고리즘이 적용됩니다. 이 문서의 다음 섹션에서는 이 알고리즘에 대해 설명합니다.

CMTS가 케이블 모뎀에서 대역폭 요청을 받으면 CMTS는 다음 작업을 수행합니다.

CMTS는 대역폭 요청에서 수신된 SID 번호를 사용하여 대역폭 요청이 연결된 서비스 흐름을 검사합니다.
그런 다음 CMTS는 토큰 버킷 알고리즘을 사용합니다. 이 알고리즘은 CMTS가 요청된 대역폭을 부여하는 경우 서비스 흐름이 정해진 최대 지속 속도를 초과할지 여부를 확인하는 데 도움이 됩니다. 토큰 버킷 알고리즘의 계산은 다음과 같습니다.

최대(T) = T * (R / 8) + B

위치:
- Max(T)는 시간 T에 따른 서비스 흐름에서 전송할 수 있는 최대 바이트 수를 나타냅니다.
- T는 시간(초)을 나타냅니다.
- R은 서비스 플로우의 최대 지속 트래픽 속도(비트/초)를 나타냅니다.
- B는 서비스 플로우의 최대 트래픽 버스트(바이트)입니다.
CMTS에서 대역폭 요청이 처리량 제한 내에 있음을 확인하면 CMTS는 대역폭 요청의 세부 정보를 업스트림 스케줄러로 대기시킵니다. 업스트림 스케줄러는 대역폭 요청을 부여할 시기를 결정합니다.

Cisco uBR CMTS는 DOCSIS 호환 스케줄러와 짧은 대기 시간 대기열 스케줄러라는 두 가지 업스트림 스케줄러 알고리즘을 구현합니다. 자세한 내용은 이 문서의 DOCSIS 준수 스케줄러 섹션 및 짧은 대기 시간 대기열 스케줄러 섹션을 참조하십시오.
그런 다음 CMTS는 다음 주기적 대역폭 할당 MAP 메시지에 이러한 세부사항을 포함합니다.
- 케이블 모뎀이 전송될 수 있는 경우
- 케이블 모뎀이 전송될 수 있는 기간.

대역폭 요청 백오프 및 재시도 알고리즘

대역폭 요청 메커니즘은 간단한 "백오프 및 재시도" 알고리즘을 사용하여 대역폭 요청을 동시에 전송하는 여러 케이블 모뎀 간의 충돌을 줄일 수 있지만 완전히 제거할 수는 없습니다.

대역폭 요청을 전송하기로 결정하는 케이블 모뎀은 모뎀이 전송하기 전에 임의의 대역폭 요청 기회가 전달될 때까지 기다려야 합니다. 이 대기 시간은 대역폭 요청의 동시 전송으로 인해 발생할 수 있는 충돌 가능성을 줄이는 데 도움이 됩니다.

데이터 백오프 시작과 데이터 백오프 끝이라는 두 매개 변수가 임의 대기 기간을 결정합니다. 케이블 모뎀은 이러한 매개변수를 UCD(주기적 업스트림 채널 설명자) 메시지의 일부로 학습합니다. CMTS는 각 활성 업스트림 채널을 대신하여 2초마다 UCD 메시지를 전송합니다.

이러한 백오프 매개변수는 "Power of 2" 값으로 표현됩니다. 모뎀은 이러한 매개변수를 2의 거듭제곱으로 사용하여 대역폭 요청을 전송하기 전에 기다리는 시간을 계산합니다. 두 값 모두 0~15의 범위를 가지며 데이터 백오프 끝은 데이터 백오프 시작보다 크거나 같아야 합니다.

케이블 모뎀이 특정 대역폭 요청을 처음 전송하려는 경우 케이블 모뎀은 먼저 0에서 2 사이의 임의의 숫자를 데이터 백오프 시작 - 1의 전원으로 선택해야 합니다. 예를 들어 데이터 백오프 시작이 3으로 설정된 경우 모뎀은 0에서 (2³ - 1) = (8 - 1) = 7 사이의 임의의 숫자를 선택해야 합니다.

그런 다음 케이블 모뎀이 대역폭 요청을 전송하기 전에 선택한 대역폭 요청 전송 기회의 수를 기다려야 합니다. 따라서 모뎀이 이러한 강제 지연으로 인해 다음 사용 가능한 기회에 대역폭 요청을 전송할 수 없지만 다른 모뎀의 전송과 충돌할 가능성이 줄어듭니다.

일반적으로 데이터 백오프 시작 값이 클수록 대역폭 요청 간의 충돌 가능성이 낮습니다. 데이터 백오프 시작 값이 클수록 모뎀이 대역폭 요청을 전송하는 데 더 오래 기다려야 하므로 업스트림 레이턴시가 증가합니다.

CMTS에는 전송된 다음 대역폭 할당 MAP 메시지에 대한 승인이 포함됩니다. 이 확인 표시는 대역폭 요청이 성공적으로 수신되었음을 케이블 모뎀에 알립니다. 이 확인 응답:

모뎀이 전송하도록 할 수 있는 정확한 시점을

또는
대역폭 요청이 수신되었으며 전송 시간이 향후 MAP 메시지에서 결정됨을 나타냅니다.

CMTS가 다음 MAP 메시지에 대역폭 요청에 대한 승인을 포함하지 않을 경우, 모뎀은 대역폭 요청을 수신하지 못한 것으로 결론지을 수 있습니다. 이 상황은 충돌 또는 업스트림 소음으로 인해 또는 요청이 허용되는 경우 서비스 흐름이 지정된 최대 처리량 속도를 초과하기 때문에 발생할 수 있습니다.

두 경우 모두 케이블 모뎀의 다음 단계는 백오프한 후 대역폭 요청을 다시 전송해 보십시오. 모뎀은 임의의 값을 선택하는 범위를 늘립니다. 이를 위해 모뎀은 데이터 백오프 시작 값에 하나를 추가합니다. 예를 들어, 데이터 백오프 시작 값이 3이고 CMTS가 하나의 대역폭 요청 전송을 수신하지 못하면 모뎀은 재전송하기 전에 0~15개의 대역폭 요청 오퍼튜니티 사이의 임의의 값을 기다립니다. 계산은 다음과 같습니다. 23+1 - 1 = 24 - 1 = 16 - 1 = 15

값이 클수록 다른 충돌 가능성이 줄어듭니다. 모뎀에서 추가 대역폭 요청이 손실되면 해당 값이 데이터 백오프 끝과 동일할 때까지 모뎀이 각 재전송에 대해 2의 전력으로 사용되는 값을 계속 증가시킵니다. 2의 힘은 데이터 백오프 종료 값보다 클 수 없습니다.

모뎀은 대역폭 요청을 최대 16번 재전송하며, 그 이후에는 모뎀이 대역폭 요청을 폐기합니다. 이 상황은 극도로 혼잡한 상황에서만 발생합니다.

다음 케이블 인터페이스 명령을 사용하여 Cisco uBR CMTS에서 케이블 업스트림당 데이터 백오프 시작 및 데이터 백오프 종료 값을 구성할 수 있습니다.

케이블 업스트림 포트 ID 데이터 백오프 데이터 백오프 시작 데이터 백오프 엔드

Cisco에서는 데이터 백오프 시작 및 데이터 백오프 엔드 매개 변수에 대한 기본값(3 및 5)을 유지할 것을 권장합니다. Best Effort 스케줄링 시스템의 경합 기반 특성은 최선형 서비스 플로우의 경우 정확 또는 보장된 업스트림 레이턴시 또는 지터 레벨을 제공할 수 없음을 의미합니다. 또한, 병목이 심한 경우 최상의 서비스 흐름을 위해 특정 수준의 처리량을 보장하는 것이 불가능할 수 있습니다. 그러나 우선 순위 및 최소 예약 속도와 같은 서비스 흐름 속성을 사용할 수 있습니다. 이러한 속성을 통해 서비스 흐름은 혼잡한 조건에서 원하는 수준의 처리량을 달성할 수 있습니다.

백오프 및 재시도 알고리즘의 예

이 예에서는 동일한 업스트림 채널에 연결된 A, B, C 및 D라는 네 개의 케이블 모뎀으로 구성됩니다. t₀이라는 동일한 순간에서 모뎀 A, B, C는 업스트림에서 일부 데이터를 전송하기로 결정합니다.

여기서 데이터 백오프 시작은 2로 설정되고 데이터 백오프 끝은 4로 설정됩니다. 모뎀이 대역폭 요청을 처음 전송하기 전에 간격을 선택하는 간격의 범위는 0에서 3입니다. 계산은 다음과 같습니다.

(22 - 1) = (4 - 1) = 3개 간격

세 개의 모뎀에서 t₀부터 대기하도록 선택할 수 있는 대역폭 요청 기회의_수입니다.

모뎀 A: 3
모뎀 B: 2
모뎀 C: 3

모뎀 A와 모뎀 C는 동일한 대기 기회를 선택합니다.

모뎀 B는 t₀ 이후에 나타나는 두 개의 대역폭 요청 기회를 기다립니다. 그런 다음 모뎀 B는 CMTS가 수신하는 대역폭 요청을 전송합니다. 모뎀 A와 모뎀 C는 모두 3개의 대역폭 요청 기회가 t₀ 이후 전달될 때까지 기다립니다. 모뎀 A와 C는 동시에 대역폭 요청을 전송합니다. 이러한 두 대역폭 요청이 충돌하여 손상됩니다. 따라서 어떤 요청도 CMTS에 성공적으로 도달하지 못합니다. 그림 2는 이 일련의 이벤트를 보여줍니다.

그림 2 - 대역폭 요청 예 1부

다이어그램 상단의 회색 막대는 시간 t₀ 이후 케이블 모뎀에서 사용할 수 있는 일련의 대역폭 요청 기회를 나타냅니다. 색상 화살표는 케이블 모뎀에서 전송하는 대역폭 요청을 나타냅니다. 회색 막대 내의 색상 상자는 CMTS에 성공적으로 도달하는 대역폭 요청을 나타냅니다.

CMTS의 다음 MAP 메시지 브로드캐스트에는 모뎀 B에 대한 부여가 포함되지만 모뎀 A와 C에 대한 지침이 없습니다. 이는 모뎀 A와 C에 대역폭 요청을 재전송해야 함을 나타냅니다.

두 번째 시도에서 모뎀 A와 모뎀 C는 선택할 간격의 범위를 계산할 때 사용할 2의 전원을 늘려야 합니다. 모뎀 A와 모뎀 C는 0에서 7 사이의 임의의 간격을 선택합니다. 다음은 계산입니다.

(22+1 -1) = (23 - 1) = (8 - 1) = 7 간격

모뎀 A와 모뎀 C가 재전송할 필요성을 인식하는 시간은 t₁이라고 가정합니다. 또한 모뎀 D라는 다른 모뎀이 일부 업스트림 데이터를 동일한 순간(t₁)에 전송하기로 결정한다고 가정합니다. 모뎀 D는 처음 대역폭 요청 전송을 하려고 합니다. 따라서 모뎀 D는 데이터 백오프 시작 및 데이터 백오프 끝(0에서 3 [(22 - 1) = (4 - 1) = 3 간격)에 원래 값을 사용합니다.

세 개의 모뎀은 시간대별로 대기할 이러한 대역폭 요청 기회의 수를_{선택합니다}.

모뎀 A: 5
모뎀 C: 2
모뎀 D: 2

모뎀 C와 D는 모두 t₁ 이후 나타나는 두 개의 대역폭 요청 기회를 기다립니다. 모뎀 C와 D는 동시에 대역폭 요청을 전송합니다. 이러한 대역폭 요청이 충돌하므로 CMTS에 도달하지 않습니다. 모뎀 A를 사용하면 5개의 대역폭 요청 기회를 통과할 수 있습니다. 그런 다음 모뎀 A는 CMTS가 수신하는 대역폭 요청을 전송합니다. 그림 3은 모뎀 C와 D의 전송과 모뎀 A의 전송에 대한 성공 수신 간의 충돌을 보여줍니다. 이 그림의 시작 시간 참조는 t₁입니다.

그림 3 - 대역폭 요청 예 2부

CMTS의 다음 MAP 메시지 브로드캐스트에는 모뎀 A에 대한 부여가 포함되지만 모뎀 C 및 D. 모뎀 C와 D에 대한 지침은 포함되어 있지 않으므로 대역폭 요청을 재전송할 필요가 있습니다. 모뎀 D가 대역폭 요청을 두 번째로 전송하려고 합니다. 따라서 모뎀 D는 데이터 백오프 시작 + 1을 대기 간격 범위 계산에 사용할 2의 전력으로 사용합니다. 모뎀 D는 0에서 7 사이의 간격을 선택합니다. 계산은 다음과 같습니다.

(22+1 - 1) = (23 - 1) = (8 - 1) = 7 간격

모뎀 C가 대역폭 요청을 세 번째로 전송하려고 합니다. 따라서 모뎀 C는 대기할 간격 범위를 계산하기 위해 데이터 백오프 시작 + 2를 2의 전력으로 사용합니다. 모뎀 C는 0에서 15 사이의 간격을 선택합니다. 계산은 다음과 같습니다.

(22+2 - 1) = (24 - 1) = (16 - 1) = 15개 간격.

여기서 2의 힘은 데이터 백오프 종료 값(4개)과 동일합니다. 이 업스트림 채널의 모뎀에 대해 두 값의 힘을 사용할 수 있는 최고 수준입니다. 다음 대역폭 요청 전송 주기에서 두 모뎀은 대기할 대역폭 요청 기회의 수를 선택합니다.

모뎀 C: 9
모뎀 D: 4

모뎀 D는 4개의 대역폭 요청 기회가 전달되기를 기다리므로 대역폭 요청을 전송할 수 있습니다. 또한 모뎀 C는 이제 9개의 대역폭 요청 기회에 대한 전송을 지연하므로 모뎀 C도 대역폭 요청을 전송할 수 있습니다.

그러나 모뎀 C가 전송을 할 때 인그레스 노이즈의 큰 버스트가 전송을 방해하므로 CMTS가 대역폭 요청을 수신하지 못합니다(그림 4 참조). 따라서 모뎀 C는 CMTS가 전송하는 다음 MAP 메시지에서 부여를 볼 수 없습니다. 이렇게 하면 모뎀 C가 대역폭 요청의 네 번째 전송을 시도합니다.

그림 4 - 대역폭 요청 예 3부

모뎀 C가 이미 데이터 백오프 종료 값 4에 도달했습니다. 모뎀 C는 대기할 임의의 간격 수를 선택하는 데 사용되는 범위를 늘릴 수 없습니다. 따라서 모뎀 C는 다시 한 번 임의 범위를 계산하기 위해 4를 2의 전원으로 사용합니다. 모뎀 C는 이 계산에 따라 0~15개의 간격을 사용합니다.

(24 - 1) = (16 - 1) = 15개 간격.

네 번째 시도에서 모뎀 C는 경합 또는 노이즈가 없는 상태에서 대역폭 요청 전송을 성공적으로 수행할 수 있습니다.

이 예에서 모뎀 C의 다중 대역폭 요청 재전송은 혼잡한 업스트림 채널에서 발생할 수 있는 상황을 보여줍니다. 또한 이 예에서는 최선형 스케줄링 모드와 관련된 잠재적인 문제와 패킷 레이턴시 및 지터의 엄격한 제어 수준이 필요한 서비스에 최선형 스케줄링이 적합하지 않은 이유를 보여줍니다.

트래픽 우선 순위

CMTS에서 여러 서비스 흐름에서 보류 중인 대역폭 요청이 여러 개 있을 경우, CMTS는 각 서비스 흐름의 트래픽 우선순위를 확인하여 먼저 대역폭을 부여할 트래픽 우선순위를 결정합니다.

CMTS는 서비스 흐름의 대역폭 요청이 우선 순위가 더 낮은 서비스 흐름에서 전송되기 전에 우선 순위가 더 높은 모든 보류 중인 요청에 전송 시간을 부여합니다. 혼잡한 업스트림 조건에서 일반적으로 낮은 우선 순위 서비스 흐름에 비해 높은 우선 순위 서비스 플로우의 처리량이 더 높습니다.

중요한 사실은 우선 순위가 높은 최선형 서비스 흐름은 대역폭을 신속하게 수신할 가능성이 높지만 서비스 흐름은 여전히 대역폭 요청 충돌 가능성이 있다는 것입니다. 이러한 이유로 트래픽 우선순위는 서비스 흐름의 처리량 및 레이턴시 특성을 향상시킬 수 있지만 트래픽 우선 순위는 여전히 서비스 보장을 필요로 하는 애플리케이션에 제공하는 적절한 방법은 아닙니다.

최소 예약 비율

Best Effort 서비스 흐름은 최소 예약 요금을 받아 준수할 수 있습니다. CMTS는 지정된 최소 예약 속도의 서비스 플로우가 우선순위에 관계없이 다른 모든 최선형 서비스 플로우보다 우선적으로 대역폭을 수신하도록 보장합니다.

이 방법은 프레임 릴레이 네트워크와 유사한 일종의 CIR(Committed Information Rate) 스타일 서비스를 제공하기 위한 시도입니다. CMTS에는 특정 업스트림에서 연결된 모든 서비스 흐름의 결합된 최소 예약 속도가 업스트림 채널의 가용 대역폭 또는 그 비율을 초과할 수 없도록 하는 허용 제어 메커니즘이 있습니다. 업스트림 포트 명령별로 다음 메커니즘을 활성화하면 됩니다.

[no] 케이블 업스트림 upstream-port-id admission-control max-reservation-limit

max-reservation-limit 매개변수의 범위는 10~1000%로, 이는 CIR 스타일 서비스에서 사용할 수 있는 원시 업스트림 채널 처리량과 비교하여 서브스크립션 레벨을 나타냅니다. 최대 예약 제한을 100보다 큰 값으로 구성할 경우 업스트림은 지정된 백분율 제한에 따라 CIR 스타일 서비스를 초과 등록할 수 있습니다.

CMTS는 업스트림 포트가 사용 가능한 업스트림 채널 대역폭의 구성된 최대 예약 제한 비율을 초과할 경우 새로운 최소 예약 속도 서비스 플로우를 설정하지 못하도록 허용하지 않습니다. 최소 예약된 속도 서비스 흐름은 여전히 대역폭 요청의 잠재적인 충돌 영향을 받습니다. 따라서 최소 예약 속도 서비스 흐름은 특히 극심한 정체 상황에서 특정 처리량에 대한 진정한 보장을 제공할 수 없습니다. 다시 말해, CMTS가 케이블 모뎀에서 필요한 모든 대역폭 요청을 수신할 수 있는 경우 CMTS는 최소 예약 속도 서비스 흐름이 특정 업스트림 처리량을 보장할 수 있는 경우에만 보장할 수 있습니다. 서비스 흐름을 최선형 서비스 흐름이 아닌 RTPS(실시간 폴링 서비스) 서비스 흐름으로 만드는 경우 이 요구 사항을 달성할 수 있습니다. 자세한 내용은 RTPS(Real Time Polling Service) 섹션을 참조하십시오.

피기백 대역폭 요청

업스트림 Best Effort 서비스 흐름에서 프레임을 높은 속도로 전송할 경우 대역폭 요청을 별도의 대역폭 요청을 전송하는 대신 업스트림 데이터 프레임으로 대역폭 요청을 피그백할 수 있습니다. 다음 대역폭 요청에 대한 세부 정보는 업스트림에서 CMTS로 전송되는 데이터 패킷의 헤더에 추가됩니다.

즉, 대역폭 요청이 경합 대상이 아니므로 요청이 CMTS에 도달할 가능성이 훨씬 높습니다. 피기백 대역폭 요청의 개념은 업스트림 전송에 프레임이 걸리는 시간이 줄어들기 때문에 이더넷 프레임이 최종 사용자의 고객 구내 장비(CPE)에 도달하는 데 걸리는 시간을 단축합니다. 이는 모뎀이 백오프를 통해 다시 대역폭 요청 전송 프로세스를 시도할 필요가 없기 때문에, 이 프로세스는 지연될 수 있습니다.

대역폭 요청의 피기백은 일반적으로 이 시나리오에서 발생합니다.

케이블 모뎀이 프레임(예: X)을 전송하기 위해 기다리는 동안 업스트림에서 CPE에서 다른 프레임(예: Y)을 수신하여 업스트림에서 전송합니다. 케이블 모뎀이 허용하는 것보다 더 많은 업스트림 시간을 사용하므로 케이블 모뎀에서 새 프레임 Y의 바이트를 전송에 추가할 수 없습니다. 대신 모뎀은 프레임 X의 DOCSIS 헤더에 있는 필드를 채워 프레임 Y에 필요한 전송 시간을 나타냅니다.

CMTS는 프레임 X를 수신하고 Y를 대신하여 대역폭 요청의 세부사항도 수신합니다. 가용성에 따라 CMTS는 Y를 대신하여 모뎀의 추가 전송 시간을 부여합니다.

매우 보수적인 관점에서 대역폭 요청 전송과 대역폭 할당 수신, 데이터 전송 시간을 할당하는 MAP 확인 사이에 5밀리초만 경과하면 됩니다. 즉, 피기백이 발생하려면 케이블 모뎀이 CPE에서 서로 5ms 이내의 범위에서 프레임을 수신해야 합니다.

이는 G.711과 같은 일반적인 VoIP 코덱이 일반적으로 프레임 간 기간을 10 또는 20ms로 사용하기 때문에 주목할 만합니다. 최상의 서비스 흐름을 통해 작동하는 일반적인 VoIP 스트림은 피기백의 이점을 활용할 수 없습니다.

연결

업스트림 최선형 서비스 흐름이 프레임을 높은 속도로 전송하면 케이블 모뎀은 일부 프레임을 함께 연결하고 프레임을 동시에 전송할 수 있는 권한을 요청할 수 있습니다. 이를 연결이라고 합니다. 케이블 모뎀은 연결 프레임 그룹의 모든 프레임을 대신하여 하나의 대역폭 요청만 전송해야 하므로 효율성이 향상됩니다.

연결은 모뎀이 대역폭 요청을 전송하기로 결정할 때 연결 시 케이블 모뎀 내에 여러 프레임을 대기시켜야 한다는 점을 제외하면 색소 회유와 유사한 상황에서 발생하는 경향이 있습니다. 이것은 연결성이 피기백보다 평균 프레임 속도가 더 높은 경향이 있다는 것을 의미합니다. 또한 두 메커니즘 모두 최선의 노력을 기울이는 트래픽의 효율성을 높이기 위해 일반적으로 함께 작동합니다.

서비스 플로우에 대해 구성할 수 있는 Maximum Concatenated Burst 필드는 서비스 플로우가 전송할 수 있는 연결된 프레임의 최대 크기를 제한합니다. 또한 cable default-phy-burst 명령을 사용하여 업스트림 채널 변조 프로필에서 연결된 프레임의 크기와 최대 버스트 크기를 제한할 수도 있습니다.

연결(Concatenation)은 Cisco uBR 시리즈 CMTS의 업스트림 포트에서 기본적으로 활성화됩니다. 그러나 [no] cable upstream port-id concatenation [docsis10] cable interface 명령을 사용하여 업스트림 포트별로 연결을 제어할 수 있습니다.

docsis10 매개변수를 구성하는 경우 이 명령은 DOCSIS 1.0 모드에서 작동하는 케이블 모뎀에만 적용됩니다.

이 명령을 변경하면 케이블 모뎀이 CMTS에서 다시 등록되어야 변경 사항이 적용됩니다. 영향을 받는 업스트림의 모뎀을 재설정해야 합니다. 케이블 모뎀은 온라인으로 전환하는 과정에서 모뎀이 등록을 수행하는 지점에서 연결이 허용되는지 여부를 학습합니다.

조각화

큰 프레임은 업스트림에서 전송하는 데 시간이 오래 걸립니다. 이 전송 시간을 serialization 지연이라고 합니다. 특히 큰 업스트림 프레임은 전송하는 데 너무 오래 걸릴 수 있으므로 시간이 중요한 서비스(예: VoIP)에 속하는 패킷을 위험하게 지연시킬 수 있습니다. 이는 특히 연결된 대형 프레임에 적용됩니다. 이러한 이유로 DOCSIS 1.1에서는 큰 프레임을 작은 프레임으로 분할하여 서로 다른 버스트를 전송하기 위해 분할할 수 있도록 단편화가 도입되었으며, 각 프레임은 전송 시간이 단축됩니다.

단편화를 사용하면 전체 큰 프레임의 전송을 기다릴 필요 없이, 시간이 많이 걸리는 작은 프레임을 큰 프레임의 조각 간에 인터리빙할 수 있습니다. 각 프래그먼트와 함께 사용해야 하는 추가 DOCSIS 헤더 세트로 인해 여러 프래그먼트로 프레임을 전송하는 것이 한 버스트에서 프레임을 전송하는 것보다 약간 덜 효율적입니다. 그러나 프래그먼트화가 업스트림 채널에 더해지는 유연성은 오버헤드를 정당화합니다.

DOCSIS 1.0 모드에서 작동하는 케이블 모뎀은 조각화를 수행할 수 없습니다.

조각화는 Cisco uBR 시리즈 CMTS의 업스트림 포트에서 기본적으로 활성화됩니다. 그러나 [no] cable upstream port-id fragmentation cable interface 명령을 사용하여 업스트림 포트별로 조각화를 활성화하거나 비활성화할 수 있습니다.

명령을 적용하려면 케이블 모뎀을 재설정할 필요가 없습니다. Cisco에서는 항상 프래그먼트화를 활성화하는 것이 좋습니다. 프래그먼트화는 일반적으로 CMTS가 대규모 데이터 프레임이 시간이 짧은 민감한 프레임 또는 특정 주기적인 DOCSIS 관리 이벤트의 전송을 방해할 수 있다고 판단하는 경우에 발생합니다.

DOCSIS 1.1/2.0 케이블 모뎀을 강제로 [no] cable upstream port-id fragment-force [threshold number-of-fragments] cable interface 명령으로 모든 큰 프레임을 분할할 수 있습니다.

기본적으로 이 기능은 비활성화되어 있습니다. 컨피그레이션에서 임계값 및 프래그먼트 수에 대한 값을 지정하지 않으면 임계값은 2000바이트로 설정되고 프래그먼트 수가 3으로 설정됩니다. fragment-force 명령은 전송에 대해 서비스 흐름 요청이 지정된 임계값 매개변수와 비교하는 바이트 수를 제공합니다. 요청 크기가 임계값보다 큰 경우, CMTS는 "프래그먼트 수"의 서비스 흐름에 동일한 크기의 부품을 부여합니다.

예를 들어, 특정 업스트림 프래그먼트 힘의 경우 임계값은 2000바이트, 프래그먼트 수는 3으로 활성화된다고 가정합니다. 그런 다음 3000바이트 버스트 전송 요청이 도착한다고 가정합니다. 3000바이트가 임계값인 2000바이트보다 크므로 부여를 프래그먼트화해야 합니다. 프래그먼트의 수가 3으로 설정되면 전송 시간은 각각 1000바이트의 세 개의 균등하게 크기가 조정됩니다.

개별 프래그먼트의 크기가 사용 중인 케이블 라인 카드 유형의 기능을 초과하지 않도록 주의하십시오. MC5x20S 라인 카드의 경우 가장 큰 개별 프래그먼트는 2000바이트를 초과해서는 안 되며, MC28U, MC5x20U 및 MC5x20H를 비롯한 다른 라인 카드의 경우 가장 큰 개별 프래그먼트는 4000바이트를 초과해서는 안 됩니다.

요청되지 않은 UGS(Grant Service)

UGS(Unsolicited Grant Service)는 대역폭 요청을 전송하기 위해 케이블 모뎀이 필요하지 않은 업스트림 서비스 흐름에 대한 정기적인 권한 부여를 제공합니다. 이 서비스 유형은 일정한 간격으로 고정 크기 프레임을 생성하고 패킷 손실을 허용하지 않는 애플리케이션에 적합합니다. VoIP가 대표적인 예입니다.

UGS 스케줄링 시스템을 T1 또는 E1 회로와 같은 TDM(Time Division Multiplexing) 시스템의 시간 슬롯과 비교합니다. UGS는 보장된 처리량과 레이턴시를 제공하며, 이는 클라이언트가 주기적으로 대역폭을 요청하거나 경쟁할 필요 없이 전송할 고정 주기적 간격의 지속적인 스트림을 제공합니다. 음성 트래픽은 일반적으로 고정 크기의 정기 데이터의 연속 스트림으로 전송되기 때문에 이 시스템은 VoIP에 적합합니다.

UGS는 최선형 스케줄링 모드에서 지연, 지터 및 처리량에 대한 보장이 없기 때문에 고안되었습니다. 최적 작업 스케줄링 모드는 특정 시간에 특정 프레임을 전송할 수 있다는 보장을 제공하지 않으며, 정체 시스템에서 특정 프레임을 전혀 전송할 수 있다는 보장이 없습니다.

UGS 스타일 서비스 흐름은 VoIP 베어러 트래픽을 전달하는 데 가장 적합한 서비스 흐름이지만 웹, 이메일 또는 P2P와 같은 일반적인 인터넷 애플리케이션에 적합하지 않은 것으로 간주됩니다. 이는 기존 인터넷 애플리케이션이 고정된 주기적 간격으로 데이터를 생성하지 않고 실제로 데이터를 전혀 전송하지 않는 데 상당한 시간을 투자할 수 있기 때문입니다. UGS 서비스 흐름을 사용하여 기존 인터넷 트래픽을 전달할 경우 애플리케이션이 전송을 잠시 중지할 때 서비스 흐름은 상당 기간 사용되지 않을 수 있습니다. 이로 인해 업스트림 대역폭 리소스의 낭비를 나타내는 사용되지 않는 UGS 부여(바람직하지 않음) 문제가 발생합니다.

UGS 서비스 플로우는 일반적으로 DOCSIS 구성 파일에서 프로비저닝되는 대신 필요할 때 동적으로 설정됩니다. 통합 VoIP 포트가 있는 케이블 모뎀은 일반적으로 모뎀이 VoIP 전화 통화가 진행 중인 것을 감지하면 CMTS에 적절한 UGS 서비스 흐름을 생성하도록 요청할 수 있습니다.

이 컨피그레이션에서는 DOCSIS 컨피그레이션 파일에서 UGS 서비스 플로우를 구성하지 않는 것이 좋습니다. 케이블 모뎀이 해당 서비스를 사용하든 사용하지 않든 온라인 상태이면 UGS 서비스 플로우가 활성 상태로 유지되기 때문입니다. UGS 서비스 플로우는 케이블 모뎀을 대신하여 업스트림 전송 시간을 지속적으로 예약하므로 이 컨피그레이션은 업스트림 대역폭을 낭비합니다. UGS 서비스 흐름을 동적으로 생성 및 삭제하여 필요할 때 UGS가 활성화되도록 하는 것이 훨씬 좋습니다.

다음은 UGS 서비스 흐름을 정의하는 가장 일반적으로 사용되는 매개변수입니다.

Unsolicited Grant Size (G)—각 주기적 부여의 크기(바이트)입니다.
Nominal Grant Interval (I) - 부여 사이의 간격(마이크로초)입니다.
Allened Grant Jitter (J) - 정확히 주기적 부여에서 마이크로초 단위로 허용된 변형이 됩니다. 다시 말해, CMTS가 UGS 부여를 정시에 예약하려고 할 때 CMTS가 갖는 이점입니다.

UGS 서비스 흐름이 활성 상태인 경우(I)밀리초마다 CMTS는 서비스 흐름이 Unsolicited Grant Size(G) 바이트로 전송할 기회를 제공합니다. CMTS가 정확히 1밀리초마다(I)밀리초마다 부여를 제공하는 것이 이상적이지만, 최대 (J)밀리초까지는 지연될 수 있습니다.

그림 5는 지정된 허용 크기, 허용 간격 및 허용 지터를 사용하여 UGS 부여를 할당하는 방법을 보여 주는 타임라인을 보여줍니다.

그림 5 - 주기적 UGS 부여를 보여주는 일정

녹색 패턴화된 블록은 CMTS가 UGS 서비스 흐름에 업스트림 전송 시간을 할당하는 시간을 나타냅니다.

실시간 폴링 서비스(RTPS)

RTPS(Real Time Polling Service)는 정기적인 비경합 기반 대역폭 요청 기회를 제공하므로 서비스 흐름에서 대역폭 요청을 전송하는 데 전용 시간을 사용할 수 있습니다. RTPS 서비스 흐름만 이 유니캐스트 대역폭 요청 기회를 사용할 수 있습니다. 다른 케이블 모뎀은 대역폭 요청 충돌을 일으킬 수 없습니다.

RTPS는 가변 길이 프레임을 반주기적인 기준으로 생성하며 안정적인 최소 처리량이 필요한 애플리케이션에 적합합니다. IP를 통한 비디오 텔레포니 또는 멀티 플레이 온라인 게임이 대표적인 예입니다.

RTPS는 VoIP 신호 트래픽에도 사용됩니다. VoIP 신호 트래픽을 매우 짧은 레이턴시 또는 지터로 전송할 필요는 없지만, VoIP는 상당한 시간 내에 CMTS에 도달할 가능성이 높습니다. 최선형 스케줄링 대신 RTPS를 사용하는 경우 반복되는 대역폭 요청 충돌로 인해 음성 신호 처리가 크게 지연되거나 삭제되지 않도록 보장할 수 있습니다.

RTPS 서비스 흐름은 일반적으로 다음 특성을 갖습니다.

Nominal Polling Interval(명목상 폴링 간격) - 유니캐스트 대역폭 요청 기회 간의 간격(마이크로초)입니다.
Allowed Poll Jitter - 정확히 주기적인 폴링에서 마이크로초 단위로 허용된 변형이 표시됩니다. 다시 한 번 말씀드리지만, CMTS가 RTPS 유니캐스트 대역폭 요청 기회를 제시간에 예약하려고 할 때 얻을 수 있는 이점입니다.

그림 6은 RTPS 폴링이 지정된 명목상 폴링 간격 및 허용되는 폴링 지터와 함께 할당되는 방법을 보여 주는 타임라인을 보여줍니다.

그림 6 - 주기적인 RTPS 폴링을 보여 주는 타임라인

녹색 패턴화된 작은 블록은 CMTS가 유니캐스트 대역폭 요청 기회에 대한 RTPS 서비스 흐름을 제공하는 시간을 나타냅니다.

CMTS가 RTPS 서비스 흐름을 대신하여 대역폭 요청을 받으면 CMTS는 "최선형" 서비스 흐름의 요청과 동일한 방식으로 대역폭 요청을 처리합니다. 즉, 위 매개변수 외에 최대 지속 트래픽 속도 및 트래픽 우선 순위 등의 속성이 RTPS 서비스 플로우 정의에 포함되어야 합니다. RTPS 서비스 흐름에는 일반적으로 서비스 흐름과 연결된 트래픽이 커밋된 대역폭 보장을 받을 수 있도록 최소 예약 트래픽 속도가 포함됩니다.

UGS-AD(Uninsolicited Grant Service with Activity Detection)

UGS-AS(Uninsolicited Grant Service with Activity Detection)는 UGS-AS가 실제로 패킷을 전송해야 하는 경우에만 서비스 흐름에 UGS 스타일 전송 시간을 할당합니다. CMTS에서 케이블 모뎀이 특정 기간 동안 프레임을 전송하지 않았음을 탐지하면 CMTS는 UGS 스타일 부여 대신 RTPS 스타일 대역폭 요청 기회를 제공합니다. CMTS가 서비스 플로우가 대역폭 요청을 수행하는 것을 이후에 탐지하면 CMTS는 서비스 흐름을 UGS 스타일 권한 부여로 되돌리고 RTPS 스타일 대역폭 요청 기회 제공을 중지합니다.

UGS-AD는 일반적으로 VAD(Voice Activity Detection)를 사용한 VoIP 트래픽이 전달되는 상황에서 사용됩니다. 음성 활동 탐지는 UGS-AD가 사용자의 음성에서 일시 중지를 탐지하면 VoIP 엔드포인트에서 VoIP 프레임 전송을 중지합니다. 이러한 동작은 대역폭을 절약할 수 있지만 음성 품질 문제를 일으킬 수 있습니다. 특히, 최종 당사자가 대화를 재개하기 시작한 후 VAD 또는 UGS-AD 활동 탐지 메커니즘이 약간 활성화되면 더욱 그렇습니다. 이 경우 사용자가 침묵 후 대화를 다시 시작할 때 팝업이나 클릭 소리가 발생할 수 있습니다. 따라서 UGS-AD는 널리 구축되지 않습니다.

CMTS가 비활성 UGS-AD 서비스 흐름을 UGS 모드에서 RTPS 모드로 전환하는 기간을 설정하려면 cable service flow inactivity-threshold-in-seconds 전역 CMTS 컨피그레이션 명령을 실행합니다.

threshold-in-seconds 매개변수의 기본값은 10초입니다. UGS-AD 서비스 흐름은 일반적으로 RTPS 서비스 흐름과 관련된 UGS 서비스 흐름의 특성 및 공칭 폴링 간격 및 허용되는 폴링 지터 특성을 배치합니다.

비실시간 폴링 서비스(nRTPS)

nRTPS(Non Real Time Polling Service) 스케줄링 모드는 기본적으로 RTPS와 동일하지만 일반적으로 파일 전송과 같은 비대화형 서비스와 연결되어 있습니다. 비실시간 구성 요소는 유니캐스트 대역폭 요청 기회에 대한 공칭 폴링 간격이 정확히 정규적이지 않거나 초당 1회 미만의 속도로 발생할 수 있음을 나타낼 수 있습니다.

일부 케이블 네트워크 운영자는 RTPS 서비스 흐름 대신 nRTPS를 사용하여 음성 신호 트래픽을 전달할 수 있습니다.

스케줄링 알고리즘

DOCSIS 준수 스케줄러와 짧은 대기 시간 대기열 스케줄러의 세부 사항에 대해 논의하기 전에 업스트림 스케줄러의 특성을 확인하기 위해 수행해야 하는 단점을 이해해야 합니다. 스케줄러 알고리즘에 대한 논의는 주로 UGS 스케줄링 모드에 중점을 두지만 RTPS 스타일 서비스에도 동일하게 적용됩니다.

UGS 서비스 플로우를 예약하는 방법을 결정할 때 유연한 옵션은 많지 않습니다. 일정 관리기에서 UGS 서비스 흐름의 허용 크기 또는 허용 간격을 변경할 수 없습니다. 이러한 변경 때문에 VoIP 호출이 완전히 실패하기 때문입니다. 그러나 지터를 변경하면 통화 대기 시간이 증가하더라도 통화가 작동합니다. 또한 업스트림에서 허용되는 최대 통화 수를 수정해도 개별 통화 품질에 영향을 주지 않습니다. 따라서 많은 수의 UGS 서비스 흐름을 예약할 때 다음 두 가지 주요 요소를 고려하십시오.

지터
업스트림당 UGS 서비스 플로우 용량

지터

허용 허용 지터는 UGS 또는 RTPS 서비스 흐름의 특성 중 하나로 지정됩니다. 그러나 일부 서비스 흐름의 동시 지원은 극히 적은 허용 지터와 매우 많은 지터를 사용하는 다른 서비스 흐름의 동시 지원은 비효율적일 수 있습니다. 일반적으로 업스트림에서 서비스 흐름이 발생하는 지터 유형에 대해 균일한 선택을 해야 합니다.

낮은 수준의 지터가 필요한 경우 일정 부여 시 일정 관리기는 유연하지 않고 유연해야 합니다. 따라서 스케줄러는 업스트림에서 지원되는 UGS 서비스 플로우 수에 제한을 두어야 합니다.

지터 버퍼 기술이 높은 수준의 지터를 보완할 수 있기 때문에 일반 소비자 VoIP에 지터 레벨이 항상 매우 낮을 필요는 없습니다. 최신 적응형 VoIP 지터 버퍼는 150ms 이상의 지터를 보완할 수 있습니다. 그러나 VoIP 네트워크는 패킷의 레이턴시에 발생하는 버퍼링의 양을 추가합니다. 레이턴시가 높으면 VoIP 환경이 더 나빠질 수 있습니다.

업스트림당 UGS 서비스 플로우 용량

채널 폭, 변조 체계 및 오류 교정 강도 같은 물리적 레이어 특성은 업스트림의 물리적 용량을 결정합니다. 그러나 업스트림에서 지원할 수 있는 동시 UGS 서비스 흐름의 수는 스케줄러 알고리즘에 따라 달라집니다.

매우 낮은 지터 레벨이 필요하지 않을 경우 스케줄러의 경직성을 완화하여 업스트림에서 동시에 지원할 수 있는 더 많은 UGS 서비스 플로우를 지원할 수 있습니다. 지터 요구 사항을 완화하면 업스트림에서 비음성 트래픽의 효율성을 높일 수 있습니다.

참고: 서로 다른 스케줄링 알고리즘으로 특정 업스트림 채널이 다양한 수의 UGS 및 RTPS 서비스 흐름을 지원할 수 있습니다. 그러나 이러한 서비스는 DOCSIS 시스템에서 업스트림 용량의 100%를 사용할 수 없습니다. 이는 업스트림 채널이 케이블 모뎀이 CMTS와의 초기 연결을 위해 사용하는 초기 유지 관리 메시지, 케이블 모뎀이 CMTS와의 연결을 유지할 수 있도록 하는 스테이션 유지 관리 keepalive 트래픽 등 DOCSIS 관리 트래픽에 일부 할당해야 하기 때문입니다.

DOCSIS 호환 스케줄러

DOCSIS 호환 스케줄러는 Cisco uBR CMTS에서 업스트림 서비스를 예약하기 위한 기본 시스템입니다. 이 스케줄러는 UGS 및 RTPS 서비스 플로우 환경을 최소화하도록 설계되었습니다. 그러나 이 스케줄러는 업스트림당 동시 UGS 통화 수를 최적화하기 위해 일정 수준의 유연성을 유지할 수 있습니다.

DOCSIS 호환 스케줄러는 UGS 서비스 플로우에 대해 업스트림 시간을 미리 할당합니다. 다른 대역폭 할당이 예약되기 전에 CMTS는 활성 UGS 서비스 플로우에 속하는 권한 부여에 대해 향후 시간을 따로 설정하여 다른 유형의 서비스 플로우 또는 트래픽이 UGS 권한 부여를 대체하지 않고 심각한 지터를 발생시키지 않도록 합니다.

CMTS가 Best Effort 스타일 서비스 플로우를 대신하여 대역폭 요청을 수신하는 경우 CMTS는 각 UGS 부여의 적시에 스케줄링에 영향을 미치지 않도록 사전 할당된 UGS 부여를 중심으로 최적의 서비스 플로우에 대한 전송 시간을 예약해야 합니다.

구성

DOCSIS 호환 스케줄러는 Cisco IOS Software 릴리스 12.3(9a)BCx 및 이전 버전에서 사용 가능한 유일한 업스트림 스케줄러 알고리즘입니다. 따라서 이 스케줄러에는 활성화할 구성 명령이 필요하지 않습니다.

Cisco IOS Software 릴리스 12.3(13a)BC 이상의 경우 DOCSIS 호환 스케줄러는 두 가지 대체 스케줄러 알고리즘 중 하나이지만 기본 스케줄러로 설정됩니다. 다음 일정 유형 중 하나, 전체 또는 일부에 대해 DOCSIS 호환 스케줄러를 활성화할 수 있습니다.

UGS
RTPS
NRTPS

케이블 업스트림 포트 스케줄링 유형 [nrtps]을 사용하여 이러한 스케줄링 유형 각각에 대해 DOCSIS 호환 스케줄러를 명시적으로 활성화할 수 있습니다. | rtps | ugs] mode docsis cable interface 명령

DOCSIS 호환 스케줄러의 사용은 기본 컨피그레이션의 일부입니다. 따라서 기본이 아닌 낮은 대기 시간 대기열 스케줄러 알고리즘에서 다시 변경하는 경우에만 이 명령을 실행해야 합니다. 자세한 내용은 Low Latency Queuing Scheduler 섹션을 참조하십시오.

입학 통제

DOCSIS 규정 준수 스케줄러의 뛰어난 장점은 이 스케줄러가 UGS 서비스 플로우가 업스트림을 초과 구독하지 않도록 한다는 것입니다. 새 UGS 서비스 플로우를 설정해야 하며, 여유 공간이 없기 때문에 스케줄러가 사전 보조금 일정을 수행할 수 없음을 발견한 경우 CMTS는 새 UGS 서비스 플로우를 거부합니다. VoIP 트래픽을 전달하는 UGS 서비스 플로우가 업스트림 채널을 초과 구독하도록 허용되면 모든 VoIP 통화의 품질이 크게 저하됩니다.

DOCSIS 준수 스케줄러가 UGS 서비스 플로우가 업스트림을 초과 구독하지 않도록 하는 방법을 시연하려면 이 섹션의 그림을 참조하십시오. 그림 7, 8 및 9는 대역폭 할당 시간 라인을 보여줍니다.

이러한 모든 그림에서 패턴화된 색상 섹션은 케이블 모뎀이 UGS 서비스 플로우를 대신하여 보조금을 받는 시간을 보여줍니다. 이 시간 동안에는 다른 케이블 모뎀에서 다른 업스트림 전송이 발생하지 않습니다. 타임 라인의 회색 부분은 아직 할당되지 않은 대역폭입니다. 케이블 모뎀은 이 시간을 사용하여 대역폭 요청을 전송합니다. CMTS는 나중에 이 시간을 사용하여 다른 유형의 서비스를 예약할 수 있습니다.

그림 7 - DOCSIS 호환 스케줄러 3개의 UGS 서비스 플로우 사전 예약

동일한 허용 크기 및 부여 간격의 UGS 서비스 흐름을 두 개 더 추가합니다. 그러나 스케줄러에서는 미리 예약하는 데 문제가 없습니다.

그림 8 - DOCSIS Compliant Scheduler Pre-schedule 5 UGS 서비스 플로우

계속 진행하여 UGS 서비스 플로우를 두 개 더 추가하면 사용 가능한 모든 업스트림 대역폭을 채웁니다.

그림 9 - UGS 서비스 플로우가 사용 가능한 모든 업스트림 대역폭 사용

스케줄러는 여기에서 더 이상의 UGS 서비스 흐름을 허용할 수 없습니다. 따라서 다른 UGS 서비스 플로우가 활성화하려고 하면 DOCSIS 준수 스케줄러는 추가 권한 부여를 위한 공간이 없음을 인식하고 해당 서비스 플로우를 설정하지 못하게 합니다.

참고: 이 일련의 그림에서 볼 수 있듯이 업스트림에 UGS 서비스 플로우를 완전히 채울 수는 없습니다. 스케줄러는 스테이션 유지 관리 keepalives 및 best effort 데이터 트래픽과 같은 다른 중요한 유형의 트래픽을 수용해야 합니다. 또한 DOCSIS 호환 스케줄러와의 초과 서브스크립션을 방지하는 보증은 모든 서비스 흐름 스케줄링 모드(UGS, RTPS 및 nRTPS)가 DOCSIS 호환 스케줄러를 사용하는 경우에만 적용됩니다.

DOCSIS 호환 스케줄러를 사용할 때는 명시적 허용 제어 컨피그레이션이 필요하지 않지만, Cisco에서는 업스트림 채널 사용률이 최선의 노력 트래픽에 부정적인 영향을 미칠 수 있는 수준으로 올라가지 않도록 하는 것이 좋습니다. 또한 상당한 시간 동안 업스트림 채널 사용률이 75%를 초과해서는 안 됩니다. 이는 Best Effort 서비스가 훨씬 더 높은 레이턴시와 더 느린 처리량을 경험하기 시작하는 업스트림 사용률 수준입니다. 업스트림 활용도와 상관없이 UGS 서비스는 여전히 작동합니다.

특정 업스트림에서 허용되는 트래픽의 양을 제한하려면 UGS, RTPS, NRTPS, UGS-AD에 대한 허용 제어를 구성하거나 글로벌, 케이블 인터페이스 또는 업스트림 명령에 따라 최선형 서비스 흐름을 구성합니다. 가장 중요한 매개변수는 exclusive-threshold-percent 필드입니다.

cable [upstream upstream-number] admission-control us-bandwidth
scheduling-type UGS|AD-UGS|RTPS|NRTPS|BE minor minor-threshold-percent 
major major-threshold-percent exclusive exclusive-threshold-percent
[non-exclusive non-excl-threshold-percent]

매개 변수는 다음과 같습니다.

[업스트림 <업스트림 번호>]: 가 케이블 인터페이스 대신 특정 업스트림에 명령을 적용하거나 전역적으로 적용하려는 경우 이 매개변수를 지정합니다.
<UGS|AD-UGS|RTPS|NRTPS|BE>: 이 매개변수는 수락 제어를 적용할 서비스 흐름의 예약 모드를 지정합니다.
<하위 임계값 퍼센트>: 이 매개변수는 작은 경보가 네트워크 관리 스테이션으로 전송되는 구성된 스케줄링 유형별로 업스트림 사용률의 백분율을 나타냅니다.
<주 임계값 퍼센트>: 이 매개변수는 주요 경보가 네트워크 관리 스테이션으로 전송되는 구성된 스케줄링 유형별로 업스트림 사용률의 백분율을 지정합니다. 이 값은 <minor-threshold-percent> 매개 변수에 대해 설정한 값보다 커야 합니다.
<배타적 임계값 퍼센트>: 이 매개변수는 지정된 스케줄링 유형에 대해 독점적으로 예약된 업스트림 활용도의 퍼센트를 나타냅니다. <non-excll-threshold-percent>에 대한 값을 지정하지 않을 경우 이 값은 이 서비스 흐름 유형에 대한 최대 사용률 제한을 나타냅니다. 이 값은 <major-threshold-percent> 값보다 커야 합니다.
<비예외 임계값 퍼센트>: 이 매개변수는 다른 스케줄링 유형이 아직 사용하지 않는 한 이 스케줄링 유형에서 사용할 수 있는 <exclusive-threshold-percent> 위의 업스트림 활용률 퍼센트를 나타냅니다.

예를 들어, UGS 서비스 흐름을 총 가용 업스트림 대역폭의 60%로 제한한다고 가정합니다. 또한 네트워크 관리 스테이션에서 UGS 서비스 플로우로 인한 업스트림 사용률 비율이 40% 이상 증가하면 경보와 50% 이상 전송해야 한다는 알림을 받았다고 가정합니다. 다음 명령을 실행합니다.

케이블 허용 제어 us-bandwidth scheduling-type UGS minor 40 major 50 exclusive 60

프래그먼트화를 사용하여 최선의 노력 트래픽 예약

DOCSIS 규정 준수 스케줄러는 사전 할당된 UGS 또는 RTPS 부여를 중심으로 최선의 노력 트래픽을 스케줄링합니다. 이 섹션의 그림은 이 동작을 보여줍니다.

그림 10 - Best Effort Grants Pending 스케줄링

그림 10은 업스트림에는 세 개의 UGS 서비스 플로우가 있으며, 이는 허용 크기와 허용 간격이 미리 예약되어 있음을 보여줍니다. 업스트림은 세 개의 개별 서비스 플로우(A, B 및 C)를 대신하여 대역폭 요청을 수신합니다. 서비스 플로우 A는 중간 양의 전송 시간을 요청하고 서비스 플로우 B는 적은 양의 전송 시간을 요청하고 서비스 플로우 C는 많은 양의 전송 시간을 요청합니다.

각 최상의 서비스 흐름에 동일한 우선 순위를 부여합니다. 또한 CMTS가 A, B, C 순으로 이러한 각 부여에 대한 대역폭 요청을 수신한다고 가정합니다. CMTS는 먼저 해당 부여에 대한 전송 시간을 동일한 순서로 할당합니다. 그림 11은 DOCSIS 호환 스케줄러가 이러한 권한을 할당하는 방법을 보여줍니다.

그림 11 - 고정 UGS 서비스 플로우 부여를 중심으로 예약된 Best Effort 보조금

스케줄러는 A와 B에 대한 보조금을 UGS의 처음 두 블록 간의 간격으로 함께 짜낼 수 있습니다. 그러나, C에 대한 보조금은 사용 가능한 어떤 차액보다 크다. 따라서 DOCSIS 호환 스케줄러는 UGS 부여의 세 번째 블록에서 C에 대한 부여를 C1과 C2라는 두 개의 작은 부여로 단편화합니다. 조각화는 UGS 부여에 대한 지연을 방지하며 이러한 부여가 최선의 노력 트래픽이 일으키는 지터의 대상이 되지 않도록 합니다.

단편화는 데이터 전송과 관련된 DOCSIS 프로토콜 오버헤드를 약간 증가시킵니다. 전송된 각 추가 프래그먼트에 대해 추가 DOCSIS 헤더 집합도 전송해야 합니다. 그러나 프래그먼트화가 없으면 스케줄러는 고정 UGS 부여 간에 최선의 노력을 효율적으로 인터리빙할 수 없습니다. DOCSIS 1.0 모드에서 작동하는 케이블 모뎀에는 조각화가 발생할 수 없습니다.

우선 순위

DOCSIS 호환 스케줄러는 할당이 속한 서비스 흐름의 우선순위를 기준으로 대기열에 할당 대기 중인 권한 부여를 배치합니다. DOCSIS 우선 순위는 0이 가장 낮고 7이 가장 높습니다. 이러한 각 우선 순위에는 연결된 대기열이 있습니다.

DOCSIS 호환 스케줄러는 엄격한 우선순위 대기열 처리 메커니즘을 사용하여 다른 우선순위의 부여가 전송 시간에 할당되는 시기를 결정합니다. 즉, 우선 순위가 높은 대기열에 저장된 모든 부여는 우선 순위가 낮은 대기열에 부여되기 전에 전달되어야 합니다.

예를 들어, DOCSIS 준수 스케줄러가 A, B, C, D, E 및 F 순서로 짧은 기간 내에 5개의 부여를 수신한다고 가정합니다. 스케줄러는 각 부여를 부여 서비스 흐름의 우선순위에 해당하는 대기열에 대기시킵니다.

그림 12 - 우선 순위가 다른 보조금

DOCSIS 호환 스케줄러는 그림 12에 패턴화된 블록으로 나타나는 사전 예약된 UGS 부여에 대한 최선형 부여를 예약합니다. DOCSIS 준수 스케줄러가 수행하는 첫 번째 작업은 가장 높은 우선순위 대기열을 확인하는 것입니다. 이 경우 우선순위 7 대기열에는 예약 가능한 권한이 있습니다. 스케줄러는 전달을 진행하며 부여 B 및 E에 대한 전송 시간을 할당합니다. 권한 부여가 사전 할당된 UGS 부여 시기를 방해하지 않도록 조각화가 E에 필요합니다.

그림 13 - Scheduling Priority 7 Grants

스케줄러는 모든 우선순위 7이 수신 전송 시간을 부여하도록 합니다. 그런 다음 스케줄러는 우선순위 6 대기열을 확인합니다. 이 경우 우선순위 6 큐는 비어 있으므로 스케줄러는 부여 C가 포함된 우선순위 5 큐로 이동합니다.

그림 14 - Scheduling Priority 5 부여

그런 다음 모든 큐가 비어 있을 때까지 스케줄러는 낮은 우선 순위 대기열을 통해 비슷한 방식으로 진행합니다. 예약할 수 있는 많은 권한이 있는 경우 DOCSIS 호환 스케줄러가 모든 보류 중인 부여에 대한 전송 시간 할당을 완료하기 전에 새 대역폭 요청이 CMTS에 도달할 수 있습니다. 이 예에서 CMTS가 우선순위 6의 대역폭 요청 G를 수신한다고 가정합니다.

그림 15 - 우선순위 6 부여가 대기열에 있음

A, F 및 D는 새로 대기열에 추가된 부여 G보다 더 오래 대기하지만 DOCSIS 준수 스케줄러는 G의 우선 순위가 높으므로 전송 시간을 G에 할당해야 합니다. 즉, DOCSIS 호환 스케줄러의 다음 대역폭 할당은 G, A, D가 됩니다(그림 16 참조).

그림 16 - 스케줄링 우선순위 6 및 우선순위 2 부여

스케줄링할 다음 부여는 평균 시간 동안 대기열 시스템에 더 높은 우선순위 부여가 없다고 가정할 경우 F입니다.

DOCSIS 호환 스케줄러에는 예시에 언급되지 않은 대기열이 두 개 더 있습니다. 첫 번째 큐는 케이블 모뎀을 온라인으로 유지하기 위해 정기 스테이션 유지 관리 keepalive 트래픽을 예약하는 데 사용되는 큐입니다. 이 대기열은 케이블 모뎀에서 CMTS 주기적 keepalive 트래픽을 전송할 기회를 예약하는 데 사용됩니다. DOCSIS 호환 스케줄러가 활성 상태이면 이 대기열이 다른 모든 대기열보다 먼저 제공됩니다. 두 번째는 CIR(Minimum Reserved Rate)이 지정된 서비스 흐름에 할당된 권한 부여에 대한 대기열입니다. 스케줄러는 커밋된 속도가 있는 서비스 흐름이 필요한 최소 처리량을 받도록 하기 위해 이 CIR 대기열을 우선순위 8 대기열로 처리합니다.

조각화 불가 DOCSIS 1.0 허가

이전 섹션의 예에서, 사전 할당된 UGS 부여에서 지터가 유발되지 않도록 하기 위해 여러 개의 조각으로 승인을 조각화해야 하는 경우가 있습니다. DOCSIS 1.0 케이블 모뎀은 UGS 트래픽이 많은 업스트림 세그먼트의 DOCSIS 1.0 모드에서 작동하는 케이블 모뎀에 문제가 될 수 있습니다. 왜냐하면 DOCSIS 1.0 케이블 모뎀은 너무 커서 다음 번 사용 가능한 전송 기회에 맞지 않기 때문입니다.

스케줄러가 해당 순서로 새 부여 A와 B를 수신한다고 가정하는 또 다른 예가 있습니다. 또한 두 허가 모두 우선 순위가 동일하지만 DOCSIS 1.0 모드에서 작동하는 케이블 모뎀에 대한 B를 허용한다고 가정합니다.

그림 17 - DOCSIS 1.1 및 DOCSIS 1.0 승인 보류 중

스케줄러는 먼저 A를 부여할 시간을 할당하려고 시도합니다. 그런 다음 스케줄러는 B를 부여하기 위해 사용 가능한 다음 전송 기회를 할당하려고 시도합니다. 그러나 A와 다음 UGS 부여 블록 간에 프래그먼트화되지 않은 상태로 유지할 수 있는 B가 없습니다(그림 18 참조).

그림 18 - DOCSIS 1.0 Grant B Deferred

이러한 이유로, B 부여는 B가 들어갈 수 있는 UGS 교부금의 두 번째 블록 이후로 연기됩니다. 이제 UGS 부여의 두 번째 블록 앞에 사용되지 않은 공간이 있습니다. 케이블 모뎀은 이 시간을 사용하여 대역폭 요청을 CMTS로 전송하지만 이는 대역폭을 비효율적으로 사용하는 것을 의미합니다.

이 예제를 다시 살펴보고 스케줄러에 2개의 UGS 서비스 흐름을 추가합니다. 부여 A는 조각화될 수 있지만, 보조금 B가 너무 커서 UGS 보조금 블록 간에 맞출 수 없기 때문에 단편화 불가능한 부여 B를 예약할 수 있는 기회가 없습니다. 이 경우 권한 부여 B와 연결된 케이블 모뎀은 업스트림에서 큰 프레임을 전송할 수 없습니다.

그림 19 - DOCSIS 1.0 Grant B를 예약할 수 없음

일정 관리기에서 UGS 권한 부여의 공간을 확보하기 위해 단순히 푸시하거나 UGS 권한 블록을 약간 지연하도록 허용할 수 있지만, 이 작업으로 인해 UGS 서비스 흐름에서 잡음이 발생합니다. 잡음을 최소화하려는 경우 이는 허용되지 않는 솔루션입니다.

DOCSIS 규정 준수 스케줄러는 프래그먼트화 불가능한 대규모 DOCSIS 1.0 부여를 통해 이 문제를 해결하기 위해 DOCSIS 1.0 케이블 모뎀이 전송할 수 있는 가장 큰 프레임만큼 업스트림 시간 블록을 주기적으로 미리 예약합니다. 스케줄러는 UGS 서비스 플로우가 예약되기 전에 이를 수행합니다. 이 시간은 일반적으로 약 2000바이트의 업스트림 전송에 해당하며 "Unfragmentable Block" 또는 "UGS free block"이라고 합니다.

DOCSIS 호환 스케줄러는 프래그먼트할 수 없는 트래픽에 할당된 시간에 UGS 또는 RTPS 스타일 부여를 배치하지 않으므로 대규모 DOCSIS 1.0 부여를 예약할 수 있는 기회가 항상 있습니다. 이 시스템에서는 단편화 불가능한 DOCSIS 1.0 트래픽에 대한 시간 예약을 통해 업스트림에서 동시에 지원할 수 있는 UGS 서비스 플로우의 수를 줄입니다.

그림 20은 조각화 불가능한 블록(파란색)과 동일한 부여 크기와 부여 간격의 4개의 UGS 서비스 흐름을 보여줍니다. UGS 부여는 파란색 분할 가능 블록 영역에서 예약할 수 없으므로 이 업스트림에 동일한 부여 크기와 부여 간격의 다른 UGS 서비스 흐름을 추가할 수 없습니다.

그림 20 - Unfragmentable 블록: 추가 UGS 승인 불가

프래그먼트할 수 없는 블록이 UGS 부여 기간보다 덜 자주 예약되지만, 이 블록은 모든 UGS 부여 블록 사이에서 할당되지 않은 대역폭의 공간을 자체 만큼 크게 만드는 경향이 있습니다. 이를 통해 단편화할 수 없는 대규모 지원 계획을 수립할 수 있는 충분한 기회가 제공됩니다.

Grant A 및 DOCSIS 1.0 Grant B의 예로 돌아가서 프래그먼트할 수 없는 블록이 있는 경우 DOCSIS 호환 스케줄러는 이제 UGS 부여의 첫 번째 블록 이후에 부여 B를 성공적으로 스케줄링할 수 있습니다.

그림 21 - 단편화 불가능한 블록 사용을 통한 보조금 스케줄링

DOCSIS 1.0 부여 B가 성공적으로 예약되었지만 부여 A와 UGS 부여의 첫 번째 블록 사이에는 아직 사용되지 않은 공간이 약간 남아 있습니다. 이 간격은 대역폭의 최적 상태가 아님을 나타내며 UGS 서비스를 구축할 때 DOCSIS 1.1 모드 케이블 모뎀을 사용해야 하는 이유를 보여줍니다.

케이블 default-phy-burst

기본적으로 Cisco uBR CMTS에서 케이블 모뎀이 전송할 수 있는 최대 버스트는 2000바이트입니다. 가장 큰 업스트림 버스트 크기에 대한 이 값은 DOCSIS 호환 스케줄러가 사용하는 프래그먼트할 수 없는 블록의 크기를 계산하는 데 사용됩니다.

케이블 인터페이스당 cable default-phy-burst max-bytes-allowed-in-burst 명령을 사용하여 최대 버스트 크기를 변경할 수 있습니다.

<max-bytes-allowed-in-burst> 매개 변수의 범위는 0~4096바이트이며 기본값은 2000바이트입니다. 기본값을 변경할 경우 이 값을 설정해야 하는 방법에 대한 몇 가지 중요한 제한이 있습니다.

MC5x20S 라인 카드의 케이블 인터페이스의 경우 이 매개변수를 기본값인 2000바이트 이상으로 설정하지 마십시오. MC28U, MC5x20U 및 MC5x20H 라인 카드를 포함한 다른 모든 라인 카드 유형의 경우 이 매개변수를 최대 4000바이트로 설정할 수 있습니다.

DOCSIS 또는 802.1q 오버헤드를 포함하여 케이블 모뎀이 전송해야 하는 가장 큰 단일 이더넷 프레임 크기보다 <max-bytes-allowed-in-burst> 매개 변수를 설정하지 마십시오. 즉, 이 값은 약 1540바이트보다 작아야 합니다.

<max-bytes-allowed-in-burst>를 특수 값 0으로 설정하면 CMTS는 이 매개변수를 사용하여 업스트림 버스트의 크기를 제한하지 않습니다. 업스트림 버스트 크기를 DOCSIS 구성 파일의 최대 연결 버스트 설정 또는 케이블 업스트림 fragment-force 명령과 같은 적절한 제한으로 제한하려면 다른 변수를 구성해야 합니다.

케이블 default-phy-burst를 수정하여 최대 업스트림 버스트 크기를 변경하면 UGS 프리 블록의 크기도 그에 따라 수정됩니다. 그림 22는 케이블 default-phy-burst 설정을 줄이면 UGS 사용 가능 블록의 크기가 줄어들어 DOCSIS 호환 스케줄러가 업스트림에서 더 많은 UGS 호출을 허용할 수 있음을 보여줍니다. 이 예에서는 케이블 default-phy-burst를 기본 설정인 2000에서 낮은 설정인 1600으로 줄여 하나 이상의 UGS 서비스 흐름이 활성화될 수 있는 공간을 확보합니다.

그림 22 - Default-phy-burst를 줄이면 단편할 수 없는 블록 크기가 감소합니다.

cable default-phy-burst 명령을 사용하여 허용되는 최대 버스트 크기를 줄이면 한 버스트 내에서 연결할 수 있는 프레임 수가 줄어들기 때문에 최적 트래픽을 위해 업스트림의 효율성을 약간 줄일 수 있습니다. 이러한 감소로 인해 업스트림에 더 많은 수의 UGS 서비스 플로우가 활성 상태일 때 프래그먼트화 수준이 증가할 수 있습니다.

연결 버스트 크기를 줄이면 최선형 서비스 흐름에서 데이터 업로드 속도에 영향을 줄 수 있습니다. 이는 여러 프레임을 한 번에 전송하는 것이 각 프레임에 대한 대역폭 요청을 전송하는 것보다 빠르기 때문입니다. 연결 수준이 감소하면 케이블 모뎀이 업스트림 방향으로 이동하는 많은 수의 TCP ACK 패킷을 연결하는 능력이 저하되어 다운로드 속도가 저하될 수 있습니다.

업스트림에 적용된 케이블 변조 프로필의 "긴" IUC에 구성된 최대 버스트 크기가 가장 큰 업스트림 버스트 크기를 결정할 수 있습니다. 이 오류는 변조 프로필의 최대 버스트 크기가 케이블 default-phy-burst 값(바이트)보다 작은 경우 발생할 수 있습니다. 이것은 드문 시나리오이다. 그러나 기본값인 2000바이트에서 케이블 default-phy-burst 매개변수를 늘리면 "long" IUC 구성에서 최대 버스트 크기를 확인하여 버스트를 제한하지 않는지 확인합니다.

업스트림 버스트 크기에 대한 또 다른 제한 사항은 한 버스트에서 최대 255개의 미니슬롯을 전송할 수 있다는 것입니다. 미니슬롯 크기가 최소 8바이트로 설정된 경우 이 오류가 발생할 수 있습니다. 미니슬롯은 DOCSIS 네트워크에서 업스트림 전송의 최소 단위이며 일반적으로 8 또는 16바이트에 해당합니다.

단편화할 수 없는 슬롯 지터

업스트림에서 더 많은 동시 UGS 흐름을 허용하기 위해 DOCSIS 준수 스케줄러를 조정하는 또 다른 방법은 일정 관리기에서 단편화할 수 없는 많은 노력 트래픽이 UGS 서비스 플로우에 소량의 지터를 유입하도록 허용하는 것입니다. 케이블 업스트림 업스트림 번호 unfrag-slot-jitter limit val cable interface 명령을 사용하여 이 작업을 수행할 수 있습니다.

이 명령에서 <val>은(는) 마이크로초 단위로 지정되며 기본값은 0입니다. 즉, DOCSIS 호환 스케줄러의 기본 동작은 단편화 불가능한 권한 부여를 허용하지 않아 UGS 및 RTPS 서비스 플로우에 지터가 발생하는 것을 의미합니다. 긍정적 단편화 불가 슬롯 지터가 지정된 경우 DOCSIS 호환 스케줄러는 UGS 부여를 예약해야 하는 시점부터 최대 <val>마이크로초까지 UGS 부여를 지연하여 지터가 발생할 수 있습니다.

이는 지정된 마이크로초 수에 해당하는 길이로 단편화되지 않은 블록 크기를 줄이는 것과 동일한 효과를 갖습니다. 예를 들어 default-phy-burst(2000바이트)의 기본값을 유지하고 단편화할 수 없는 슬롯 지터에 대해 1000마이크로초 값을 지정하면 단편화되지 않은 블록이 줄어듭니다(그림 23 참조).

그림 23 - Non-zero Unfragmentable Slot Jitter는 조각화 불가능한 블록 크기를 줄입니다.

참고: 1000마이크로초 시간이 해당하는 바이트 수는 업스트림 채널이 채널 너비 및 변조 체계 설정을 통해 작동하도록 구성된 속도에 따라 달라집니다.

참고: DOCSIS 규정 준수 스케줄러는 프래그먼트할 수 없는 슬롯 지터를 사용하여 업스트림에서 지원하는 UGS 부여 수를 기본 phy-burst를 줄이는 것과 유사한 방식으로 늘릴 수 있습니다.

참고: 큰 DOCSIS 1.1 허가 A와 함께 업스트림에서 예약할 수 있는 큰 DOCSIS 1.0 허가 B가 있는 예로 돌아갑니다. 단편화할 수 없는 슬롯 지터를 1000마이크로초로 설정합니다. DOCSIS 호환 스케줄러는 이 섹션의 그림과 같이 작동합니다.

주: 먼저 스케줄러는 부여 A에 대한 전송 시간을 할당합니다. 이렇게 하려면 스케줄러가 부여를 부여 A₁ 및 A₂로 프래그먼트화하여 UGS 부여의 첫 번째 블록 전후에 할당이 맞도록 합니다. B 부여를 예약하기 위해 스케줄러는 A₂를 구성이 불가능한 슬롯 지터 1000마이크로초 이상의 UGS 부여 다음 블록에 지연 없이 부여한 후 프래그먼트화 가능 블록을 여유 공간에 맞출 수 있는지 결정해야 합니다. 이 수치는 스케줄러가 A₂를 부여하기 위해 B를 부여하면 다음 UGS 트래픽 블록이 1500마이크로초 이상 지연되거나 푸시되는 것을 보여줍니다. 따라서 일정 관리기에서 권한 부여 A₂ 바로 뒤에 부여 B를 배치할 수 없습니다.

그림 24 - Grant A2 옆에서 Grant B를 예약할 수 없습니다.

DOCSIS 호환 스케줄러의 다음 단계는 다음 사용 가능한 간격이 허가 B를 수용할 수 있는지 확인하는 것입니다. 그림 25는 스케줄러가 UGS 부여 두 번째 블록 뒤에 부여 B를 배치하면 세 번째 블록이 1000마이크로초 단위로 구성된 단편화할 수 없는 구성된 슬롯 지터 이상으로 지연되지 않음을 보여줍니다.

그림 25 - UGS 보조금 두 번째 블록 이후에 예약된 Grant B

이 시점에 부여 B를 삽입해도 UGS 부여에 허용되지 않는 지터가 발생하지 않는다는 사실을 알고 있는 DOCSIS 호환 스케줄러는 부여 B를 삽입하고 다음 UGS 부여 블록을 약간 지연시킵니다.

그림 26 - Unfragmentable Grant B가 예약되어 있으며 UGS 부여 지연

명령 출력 표시

show interface cable interface-number mac-scheduler upstream-number 명령을 사용하여 DOCSIS 호환 스케줄러의 현재 상태를 평가할 수 있습니다. 다음은 MC28U 라인 카드가 있는 Cisco uBR7200VXR에 표시된 이 명령의 출력의 예입니다.

uBR7200VXR# show interface cable 3/0 mac-scheduler 0
     DOCSIS 1.1 MAC scheduler for Cable3/0/U0
     Queue[Rng Polls] 0/128, 0 drops, max 1
     Queue[CIR Grants] 0/64, 0 drops, max 0
     Queue[BE(7) Grants] 1/64, 0 drops, max 2
     Queue[BE(6) Grants] 0/64, 0 drops, max 0
     Queue[BE(5) Grants] 0/64, 0 drops, max 0
     Queue[BE(4) Grants] 0/64, 0 drops, max 0
     Queue[BE(3) Grants] 0/64, 0 drops, max 0
     Queue[BE(2) Grants] 0/64, 0 drops, max 0
     Queue[BE(1) Grants] 0/64, 0 drops, max 0
     Queue[BE(0) Grants] 1/64, 0 drops, max 1
     Req Slots 36356057, Req/Data Slots 185165
     Init Mtn Slots 514263, Stn Mtn Slots 314793
     Short Grant Slots 12256, Long Grant Slots 4691
     ATDMA Short Grant Slots 0, ATDMA Long Grant Slots 0
     ATDMA UGS Grant Slots 0
     Awacs Slots 277629
     Fragmentation count 41
     Fragmentation test disabled
     Avg upstream channel utilization : 26%
     Avg percent contention slots : 73%
     Avg percent initial ranging slots : 2%
     Avg percent minislots lost on late MAPs : 0%
     Sched Table Rsv-state: Grants 0, Reqpolls 0
     Sched Table Adm-State: Grants 6, Reqpolls 0, Util 27%
     UGS    : 6 SIDs, Reservation-level in bps 556800
     UGS-AD : 0 SIDs, Reservation-level in bps 0
     RTPS   : 0 SIDs, Reservation-level in bps 0
     NRTPS  : 0 SIDs, Reservation-level in bps 0
     BE     : 35 SIDs, Reservation-level in bps 0
     RTPS   : 0 SIDs, Reservation-level in bps 0
     NRTPS  : 0 SIDs, Reservation-level in bps 0
     BE     : 0 SIDs, Reservation-level in bps 0

이 섹션에서는 이 명령의 출력 각 행에 대해 설명합니다. 이 섹션에서는 일반적인 DOCSIS 업스트림 스케줄링 개념을 이미 잘 알고 있다고 가정합니다.

케이블 3/0/U0용 DOCSIS 1.1 MAC 스케줄러

명령 출력의 첫 번째 행은 데이터가 관련된 업스트림 포트를 나타냅니다.
Queue[Rng Polls] 0/128, 0 삭제, 최대 1

이 줄은 스테이션 유지 관리 keepalive 또는 DOCSIS 준수 스케줄러에 다양한 기회를 제공하는 대기열의 상태를 보여줍니다. 0/128은 현재 대기열에 보류 중인 최대 128개의 범위 지정 기회 중 0이 있음을 나타냅니다.

Drops 카운터는 이 큐가 이미 꽉 찼기 때문에(즉, 128개의 보류 중인 범위 지정 기회) 범위 지정 기회를 대기열에 넣을 수 없는 횟수를 나타냅니다. 여기서 드롭은 온라인에서 매우 많은 수의 케이블 모뎀을 사용하는 업스트림에서 발생할 수 있으며 UGS 또는 RTPS 서비스 흐름이 활성화된 경우 발생할 수 있습니다. 이 대기열은 DOCSIS 준수 스케줄러가 실행될 때 가장 높은 우선 순위로 처리됩니다. 따라서 이 대기열의 삭제는 가능성이 매우 낮지만 업스트림 채널의 심각한 오버서브스크립션을 나타낼 가능성이 높습니다.

max 카운터는 show interface cable mac-scheduler 명령이 마지막으로 실행된 이후 이 대기열에 있는 최대 요소 수를 나타냅니다. 이상적으로는 가능한 0에 가깝게 유지해야 합니다.
Queue[CIR Grants] 0/64, 0 삭제, 최대 0

이 줄은 최소 예약된 트래픽 비율이 지정된 서비스 흐름에 대한 승인을 관리하는 큐의 상태를 표시합니다. 즉, 이 대기열 서비스는 CIR(Committed Information Rate) 서비스 플로우에 대해 부여됩니다. 0/64는 현재 대기열에 보류 중인 최대 64개의 권한 중 0이 있음을 나타냅니다.

Drops 카운터는 이 큐가 이미 꽉 찼기 때문에 CIR 부여를 대기열에 넣을 수 없는 횟수(즉, 대기열에 있는 64개의 부여)를 나타냅니다. UGS, RTPS 및 CIR 스타일 서비스가 업스트림에 초과 구독할 경우 여기에서 드롭이 누적될 수 있으며, 더 엄격한 승인 제어의 필요성을 나타낼 수 있습니다.

max 카운터는 show interface cable mac-scheduler 명령을 마지막으로 실행한 이후 이 큐의 최대 허용 수를 나타냅니다. 이 대기열은 두 번째로 높은 우선 순위를 가지므로 DOCSIS 준수 스케줄러는 스케줄러 서비스가 최상의 작업 대기열보다 먼저 이 대기열의 요소에 대한 시간을 할당합니다.
Queue[BE(w) Grants] x/64, y drops, max z

다음 8개 항목은 우선 순위 7~0 서비스 흐름에 대한 권한 부여를 관리하는 큐의 상태를 보여줍니다. 이러한 항목의 필드는 CIR 대기열 항목의 필드와 같은 의미를 갖습니다. 이 그룹에서 제공되는 첫 번째 대기열은 BE(7) 대기열이며, 마지막 대기열은 BE(0) 대기열입니다.

우선 순위가 높은 트래픽이 모든 업스트림 대역폭을 소비하거나 UGS, RTPS 및 CIR 스타일 서비스 흐름을 사용하여 업스트림의 초과 서브스크립션이 발생하는 경우 이러한 대기열에서 삭제가 발생할 수 있습니다. 이는 대량 서비스 플로우의 DOCSIS 우선 순위를 재평가해야 하거나 업스트림에서 더 엄격한 승인 제어가 필요함을 나타낼 수 있습니다.
Req 슬롯 36356057

이 행은 업스트림이 활성화된 이후 광고된 대역폭 요청 기회 수를 나타냅니다. 이 수치는 지속적으로 증가해야 합니다.
Req/데이터 슬롯 185165

이름이 이 필드에 업스트림에서 광고된 요청 또는 데이터 기회 수가 표시된다고 제안하지만, 이 필드에는 CMTS가 고급 스펙트럼 관리 기능을 용이하게 하기 위해 광고한 기간 수가 표시됩니다. 이 카운터는 MC28U 및 MC520 스타일 라인 카드의 업스트림에 대해 증가할 것으로 예상됩니다.

요청/데이터 기회는 대역폭 요청 기회와 동일합니다. 단, 케이블 모뎀이 이러한 기간에 소량의 데이터 버스트를 전송할 수도 있습니다. Cisco uBR 시리즈 CMTS는 현재 실제 요청/데이터 기회를 예약하지 않습니다.
MTN 슬롯 초기화 514263

이 행은 업스트림이 활성화된 이후 광고된 초기 유지 관리 기회 수를 나타냅니다. 이 수치는 지속적으로 증가해야 합니다. CMTS와의 연결을 처음 시도하는 케이블 모뎀은 초기 유지 관리 기회를 사용합니다.
STN MTN 슬롯 314793

이 라인은 업스트림에서 제공되는 스테이션 유지 보수 유지 보수 유지 보수 또는 다양한 기회 수를 나타냅니다. 업스트림에 온라인으로 케이블 모뎀이 있는 경우 이 수치는 계속 증가해야 합니다.
Short Grant Slots 12256, Long Grant Slots 4691

이 라인은 업스트림에서 제공된 데이터 부여 수를 나타냅니다. 업스트림 데이터를 전송하는 케이블 모뎀이 있는 경우 이러한 수치는 계속 증가해야 합니다.
ATDMA Short Grant 슬롯 0, ATDMA Long Grant 슬롯 0, ATDMA UGS Grant 슬롯 0

이 줄은 업스트림의 ATDMA(Advanced Time Division Multiple Access) 모드에서 제공되는 데이터 부여 수를 나타냅니다. DOCSIS 2.0 모드에서 작동하는 케이블 모뎀이 있고 업스트림 데이터를 전송하는 경우 이러한 수치는 계속 증가해야 합니다. ATDMA는 UGS 트래픽을 개별적으로 고려합니다.
Awacs 슬롯 277629

이 줄은 고급 스펙트럼 관리 전용 기간 수를 표시합니다. 고급 스펙트럼 관리를 수행하려면 CMTS는 각 케이블 모뎀에서 짧은 전송을 수행해야 하는 시간을 정기적으로 예약해야 내부 스펙트럼 분석 기능이 각 모뎀의 신호 품질을 평가할 수 있습니다.
조각화 수 41

이 줄은 업스트림 포트가 수신하도록 예약된 총 프래그먼트 수를 표시합니다. 예를 들어 세 부분으로 조각화된 프레임은 이 카운터가 3씩 증가하게 됩니다.
조각화 테스트 사용 안 함

이 선은 test cable fragmentation 명령이 호출되지 않았음을 나타냅니다. 프로덕션 네트워크에서는 이 명령을 사용하지 마십시오.
평균 업스트림 채널 사용률: 26%

이 행은 업스트림 데이터 전송별 현재 업스트림 채널 사용률을 보여줍니다. 이는 ATDMA Short, ATDMA Long 및 ATDMA UGS 승인을 통해 이루어지는 전송을 포함합니다. 이 값은 매초마다 롤링 평균으로 계산됩니다. Cisco에서는 피크 사용 시간 동안 이 값이 연장하여 75%를 초과하지 않는 것이 좋습니다. 그렇지 않으면 엔드 유저는 최상의 노력 트래픽으로 성능 문제를 인식하기 시작할 수 있습니다.
평균 경합 슬롯 비율: 73%

이 행은 대역폭 요청 전용 업스트림 시간의 백분율을 보여 줍니다. 이는 업스트림의 여유 시간과 동일하므로 평균 업스트림 채널 사용률 증가에 따라 감소합니다.
평균 초기 범위 슬롯 비율: 2%

이 선은 케이블 모뎀이 CMTS와의 초기 연결을 설정하려고 시도할 때 사용하는 초기 범위 지정 기회에 전용 업스트림 시간의 백분율을 나타냅니다. 이 값은 항상 총 활용률 중 낮은 비율을 유지해야 합니다.
지연 MAP에서 손실된 평균 미니슬롯 비율: 0%

이 줄은 CMTS가 시간 내에 케이블 모뎀에 대역폭 할당 MAP 메시지를 전송할 수 없으므로 예약되지 않은 업스트림 시간의 백분율을 나타냅니다. 이 매개변수는 항상 0에 근접해야 하지만 CPU 로드가 매우 높은 시스템에서 더 큰 값을 표시하기 시작할 수 있습니다.
예약된 테이블 rsv-state: 보조금 0, 요청 0

이 줄은 DOCSIS 호환 스케줄러에서 사전 할당되었지만 아직 활성화되지 않은 UGS 스타일 서비스 흐름(부여) 또는 RTPS 스타일 서비스 흐름(요청)의 수를 표시합니다. 이는 로드 밸런싱을 통해 기존 UGS 또는 RTPS 서비스 흐름을 사용하여 케이블 모뎀을 업스트림 간에 이동할 때 발생합니다. 이 그림은 LLQ 스케줄러가 아닌 DOCSIS 호환 스케줄러를 사용하는 승인에만 적용됩니다.
예약된 테이블 ADM-상태: Grants 6, Requestions 0, Util 27%

이 줄은 이 업스트림에 대한 DOCSIS 호환 스케줄러에서 UGS 스타일 서비스 흐름(부여) 또는 RTPS 스타일 서비스 흐름(요청) 수를 나타냅니다. Util은 이러한 서비스 플로우에서 사용 가능한 총 업스트림 대역폭의 예상 사용률입니다. 이 그림은 LLQ 스케줄러가 아닌 DOCSIS 호환 스케줄러를 사용하는 승인에만 적용됩니다.
<예약 유형>: x SID, 예약 레벨(bps)

이 줄은 업스트림에 있는 <Scheduling-type> 서비스 흐름 또는 SID의 수와 이러한 서비스 플로우가 예약한 초당 대역폭 양을 나타냅니다. 최선형 및 RTPS 스타일 서비스 플로우의 경우 서비스 플로우에 최소 예약 속도가 구성된 경우에만 대역폭이 예약됩니다.

DOCSIS 호환 스케줄러의 장점 및 단점

DOCSIS 호환 스케줄러의 목표는 UGS 및 RTPS 스타일 서비스 플로우의 지터를 최소화하고 단편화할 수 없는 DOCSIS 1.0 버스트를 수용하는 것입니다. 이러한 목표를 달성하기 위해 DOCSIS 규정 준수 스케줄러가 수행하는 이점은 업스트림당 지원되는 최대 UGS 서비스 플로우 수가 DOCSIS 업스트림이 물리적으로 지원할 수 있는 이론상의 최대값보다 적으며, 최선의 노력 트래픽은 조각화의 영향을 받을 수 있다는 것입니다.

DOCSIS 준수 스케줄러는 업스트림에서 이론상 최대 동시 UGS 서비스 플로우 수보다 약간 적은 수의 동시 UGS 서비스 흐름을 지원하며, 다른 스케줄링 구현에서는 업스트림당 더 많은 UGS 서비스 플로우를 지원할 수 있지만, 트레이드오프에 주력해야 합니다.

예를 들어 어떤 스케줄러도 업스트림 채널의 최대 100% 대역폭을 사용하고 동시에 DOCSIS 1.0 모뎀에서 분할 가능한 대규모 연결 프레임을 지원하는 지터리스 UGS 서비스 흐름을 지원할 수 없습니다. DOCSIS 호환 스케줄러의 설계에는 두 가지 중요한 사항을 이해해야 합니다.

75%는 가장 바람직한 업스트림 활용률입니다.

Cisco는 업스트림이 UGS 서비스 플로우로 인한 활용률을 포함하여 75% 이상의 활용률을 지속적으로 실행할 경우 최선의 노력 트래픽 성능이 눈에 띄게 영향을 받기 시작한다는 것을 발견했습니다. 즉, UGS 및 VoIP 시그널링이 업스트림의 75% 이상을 소비할 경우, 최선형 서비스 플로우를 통해 전달되는 모든 정상적인 IP 트래픽이 추가 레이턴시에 시달리고 처리량과 응답 시간이 현저히 감소합니다. 높은 활용률 수준에서 이러한 성능 저하는 대부분의 최신 다중 액세스 네트워크 시스템(예: 이더넷 또는 무선 LAN)에서 공유하는 속성입니다.
일반적으로 구축된 업스트림 채널 너비가 3.2MHz인 경우 DOCSIS 호환 스케줄러는 UGS 서비스 플로우가 업스트림 채널의 약 75%를 활용할 수 있도록 합니다. 이러한 서비스 흐름은 G.711 VoIP 통화를 전달합니다.

이 두 가지 포인트는 DOCSIS 호환 스케줄러가 구축되었을 때 고려된 설계 고려 사항에 대한 몇 가지 정보를 제공합니다. DOCSIS 호환 스케줄러는 일반적인 UGS 서비스 플로우(G.711)와 가장 일반적으로 구축된 채널 너비가 3.2MHz인 경우 업스트림 당 통화가 약 75% 사용률 표시에서 적용되도록 설계되었습니다. 이는 스케줄러가 성공적으로 지터를 최소화하고 업스트림에서 적절한 수의 UGS 서비스 플로우를 허용하는 것을 의미합니다.

다시 말해, DOCSIS 규정 준수 스케줄러는 프로덕션 DOCSIS 네트워크에서 제대로 작동하도록 설계되었으며, UGS 서비스 플로우가 업스트림 대역폭의 비현실적으로 높은 비율을 사용하도록 허용하지 않습니다. 이 시나리오는 실험실 테스트 시나리오에서 발생할 수 있습니다.

DOCSIS 호환 스케줄러를 조정하여 업스트림당 UGS 통화 수를 늘릴 수 있습니다. 그러나 UGS 지터 및 최선의 노력 트래픽 효율성이 저하됩니다. 이를 위해 케이블 default-phy-burst 매개변수를 최소 권장 설정 1540바이트로 줄여야 합니다. 추가 통화 밀도가 필요한 경우 케이블 업스트림 unfrag-slot-jitter를 2000마이크로초 등의 값으로 설정합니다. 그러나 Cisco는 일반적으로 프로덕션 네트워크에 대해서는 이러한 설정을 권장하지 않습니다.

DOCSIS 호환 스케줄러의 또 다른 장점은 CMTS 운영자가 UGS 및 RTPS 스타일 서비스 흐름에 대한 승인 제어를 명시적으로 구성하는 데 필요한 의무 요건이 없다는 것입니다. 이는 사전 할당 스케줄링 방법으로 우발적인 초과 서브스크립션 가능성이 제거되기 때문입니다. 이러한 경우에도 Cisco는 운영자가 피크 시간 동안 연장된 기간 동안 업스트림 전체 사용률이 75%를 초과하지 않도록 보장하도록 제안합니다. 따라서 Cisco는 모범 사례로서 입학 통제 구성을 권장합니다.

DOCSIS 규정 준수 스케줄러의 한 가지 단점은 UGS 부여의 고정 위치에 UGS 사용률이 높을 때 BEST Effort의 단편화가 필요할 수 있다는 것입니다. 일반적으로 프래그먼트화는 심각한 성능 문제를 일으키지는 않지만, 모범 사례 트래픽에 대한 레이턴시가 약간 증가하고 업스트림 채널에 있는 프로토콜 오버헤드가 증가합니다.

또 다른 단점은 DOCSIS 1.0 케이블 모뎀이 프래그먼트할 수 없는 대규모 업스트림 전송을 하려는 경우 미리 예약된 UGS 보조금 블록 간의 적절한 간격이 표시되기 전에 지연이 발생할 수 있다는 것입니다. 따라서 DOCSIS 1.0 업스트림 트래픽의 레이턴시가 증가하고 사용 가능한 업스트림 전송 시간이 최적화되지 않을 수 있습니다.

마지막으로, DOCSIS 규정 준수 스케줄러는 모든 UGS 서비스 흐름이 동일한 권한 부여 크기와 부여 간격을 공유하는 환경에서 가장 잘 작동하도록 설계되었습니다. 즉, 일반적인 Packetcable 1.0 기반 시스템에서 발생하는 것과 같이 모든 VoIP 통화가 동일한 코덱을 공유합니다(예: 10ms 또는 20ms 패킷화 G.711). 각기 다른 권한 부여 간격과 크기가 있는 경우 DOCSIS 준수 스케줄러에서 많은 수의 UGS 서비스 흐름을 지원하는 용량이 업스트림에서 감소합니다. 또한 일정 관리기가 UGS 서비스 흐름을 서로 다른 기간과 크기로 인터리빙하려고 할 때 일부 부여에 대해 매우 적은 양의 지터(2ms 미만)가 발생할 수 있습니다.

PCMM(PacketCable MultiMedia) 네트워크가 더욱 널리 보급됨에 따라 다양한 패킷 생성 간격을 가진 다양한 VoIP 코덱에 대해 더 일반적이 되어 동시에 작동할 수 있습니다. 이 환경 유형은 Low Latency Queuing Scheduler에 자신을 빌려줄 수 있습니다.

짧은 대기 시간 대기열 스케줄러

LLQ(Low Latency Queuing) 스케줄러는 Cisco IOS Software 릴리스 12.3(13a)BC에 도입되었습니다. LLQ는 Cisco uBR CMTS에서 업스트림 서비스를 예약하는 대체 방법입니다. 이 스케줄러는 업스트림에서 동시에 지원할 수 있는 UGS 및 RTPS 스타일 서비스 흐름의 수를 최대화하고 UGS 서비스 플로우가 있을 때 최선형 트래픽의 효율성을 향상하도록 설계되었습니다. LLQ 스케줄러는 UGS 및 RTPS 서비스 플로우의 지터와 관련하여 어떠한 보증도 하지 않습니다.

DOCSIS 규정 준수 스케줄러 섹션에 대해 설명하면 DOCSIS 규정 준수 스케줄러는 UGS 및 RTPS 스타일 서비스 플로우에 대해 전송 시간을 미리 미리 할당합니다. 이는 레거시 TDM(Time Division Multiplexing) 시스템이 특정 레이턴시와 지터 수준을 보장하기 위해 서비스에 대역폭을 할당하는 방식과 유사합니다.

최신 패킷 기반 네트워크에서 낮은 레이턴시 큐잉은 라우터가 우선순위가 높은 서비스(예: 음성 및 비디오)와 연결된 패킷을 다른 낮은 우선 순위 패킷보다 먼저 네트워크에서 전달할 수 있도록 하는 방법입니다. 또한 중요한 트래픽에 대해 레이턴시와 지터가 최소화되도록 최신 라우터에서 사용하는 방법입니다.

지터 및 레이턴시와 관련하여 TDM 기반 시스템에 "보증", LLQ 기반 시스템에 "최소화"라는 단어를 사용합니다. 지연 시간 및 지터에 대한 보장은 바람직하지만 이러한 시스템은 대개 유연성이 떨어지며 재구성도 어렵고 일반적으로 네트워크 상황의 변화에 쉽게 적응할 수 없다는 것이 대체적인 것입니다.

엄격한 보증을 제공하는 대신 레이턴시와 지터를 최소화하는 시스템은 네트워크 조건의 변화에 따라 지속적으로 최적화하기 위한 유연성을 제공할 수 있습니다. 짧은 대기 시간 대기열 스케줄러는 패킷 라우터 기반 LLQ 시스템과 유사한 방식으로 작동합니다. 이 시스템은 UGS 부여를 위한 사전 예약된 시스템 할당 대신 스케줄링해야 할 시점에 "가능한 한 빨리" 권한 부여를 스케줄링합니다.

UGS 서비스 플로우를 허용하는 접근 방식은 가능한 한 빨리 할당되어야 하지만 완벽한 주기성으로 반드시 할당되어야 하는 것은 아닙니다. 이 시스템은 엄격한 지터 보증을 통해 UGS 용량을 늘리고 최선형 데이터 조각화를 보장합니다.

구성

Cisco IOS Software 릴리스 12.3(13a)BC 이상의 경우 LLQ 스케줄러는 두 가지 대체 스케줄러 알고리즘 중 하나입니다. 다음 일정 모드 중 하나, 모두 또는 일부에 대해 LLQ를 활성화할 수 있습니다.

UGS
RTPS
NRTPS

LLQ 스케줄러는 기본적으로 활성화되지 않습니다. 필요한 업스트림 스케줄링 유형에 대해 LLQ 스케줄러를 명시적으로 설정해야 합니다. 케이블 업스트림 업스트림 포트 스케줄링 유형 사용 [nrtps | rtps | ugs] mode llq cable interface 명령

일반적으로 원하는 스케줄링 모드인 경우 나열된 모든 스케줄링 모드에 대해 LLQ 스케줄러를 활성화할 수 있습니다. 다음은 한 가지 유형의 스케줄링 모드에만 LLQ 스케줄링을 활성화하되 다른 유형에 대해 DOCSIS 호환 스케줄러를 유지하려는 상황의 예입니다.

RTPS 서비스 플로우는 지터에 대한 엄격한 요구 사항은 없지만 UGS 서비스 플로우는 마찬가지입니다. 이 경우 RTPS 서비스 플로우용 LLQ 스케줄러를 활성화하고 UGS용 DOCSIS 호환 스케줄러를 유지할 수 있습니다.

LLQ 스케줄러 작업

LLQ 스케줄러는 DOCSIS 호환 스케줄러의 우선순위 대기열 기능과 동일한 방식으로 작동하며, 다른 모든 대기열보다 우선하는 특수 LLQ(low latency queue)를 추가합니다.

LLQ 스케줄러는 모든 활성 UGS(및 RTPS) 스타일 서비스 흐름 대신 타이머를 시작합니다. 타이머가 "허용 간격"마다 한 번 꺼지도록 설정됩니다. 타이머가 만료될 때마다 UGS 부여가 LLQ 대기열에서 대기됩니다. 이 부여는 우선 순위가 가장 높은 LLQ 대기열에 배치되므로, 사용 가능한 공간이 있는 가능한 다음 순간에 부여가 예약됩니다.

이 섹션의 다이어그램에는 동일한 허용 간격을 가진 3개의 활성 UGS 서비스 플로우가 있는 시스템의 예가 나와 있습니다. 그림 27은 UGS 서비스 흐름의 타이머를 UGS-1에서 UGS-3으로 왼쪽에 표시합니다. 노란색 화살표는 시계 방향으로 이동합니다. 노란색 화살표가 빨간색 점을 향해 위로 이동하면 UGS 부여가 LLQ 대기열에 추가됩니다. 또한 익숙한 8개의 우선 순위 대기열 0~7과 모든 우선 순위를 차지하는 새 LLQ 대기열을 볼 수 있습니다. 마지막으로, 오른쪽에는 업스트림에서 할당이 예약되는 방법을 설명하는 대역폭 할당 시간 줄이 있습니다. 더 명확하게 하기 위해 대역폭 할당 시간 줄에 "현재 시간" 포인터가 포함됩니다. 이 포인터는 예제가 진행되는 동안 타임라인을 따라 앞으로 이동합니다.

그림 27 - 낮은 레이턴시 대기열 처리 시스템

첫 번째 이벤트는 왼쪽 상단에 있는 UGS-1 타이머가 만료된다는 것입니다. 해당 부여가 LLQ 대기열에서 대기됩니다. 동시에 우선순위 2가 있는 A라는 최선의 노력 허용이 대기열에 추가됩니다.

그림 28 - UGS-1 및 우선순위 2 부여 A에 대한 부여가 대기열에 있음

이제 LLQ 스케줄러는 보류 중인 부여에 우선 순위 순서대로 전송 시간을 할당합니다. 전송 시간을 수신하는 첫 번째 부여는 LLQ 대기열에서 대기하는 UGS-1에 대한 부여입니다. A는 다음과 같습니다.

그림 29 - UGS-1 부여 및 Grant A가 할당된 전송 시간

다음 이벤트는 UGS-2 타이머가 만료되고 UGS-2 서비스 흐름에 대한 권한 부여가 LLQ 대기열에서 대기되도록 하는 것입니다. 동시에 우선순위 0 부여 B는 대기열에 있고 우선순위 6 부여 C는 대기열에 추가됩니다.

그림 30 - UGS-2 타이머가 만료됩니다. Grants B 및 C가 대기열에 있음

LLQ 스케줄러는 권한 부여 우선순위에 따라 전송 시간을 다시 한 번 할당합니다. 즉, 스케줄러가 UGS-2에 대한 권한 부여에 시간을 할당한 다음, 권한 부여 C에 대해 마지막으로 권한 부여 B에 시간을 할당합니다.

그림 31 - UGS-2, C 및 B가 할당된 전송 시간

일정 관리기에 대한 최선의 노력 부여 없이 잠시 동안 일정 관리기를 입력한다고 가정합니다. UGS 타이머는 각각 몇 번 더 만료됩니다. 이제 스케줄러가 UGS 서비스 플로우에 권한을 할당하는 기간을 확인할 수 있습니다. 그들은 간격이 균일한 것 같다. 대역폭 할당 타임라인에서 권한 부여가 서로 이와 같은 방식으로 나타날 때 심각한 지터가 발생하지 않는다고 가정합니다.

그림 32 - UGS-1, UGS-2 및 UGS-3은 다양한 보조금을 받습니다. 허용 D가 대기됨

그림 32는 다음 UGS-2 부여를 위한 이상적인 위치를 나타냅니다. UGS-2가 이 지점에 보조금을 줄 수 있는 경우 UGS-2는 보조금에 대한 지터를 경험하지 않습니다. LLQ 대기열에서 다음 UGS-2 부여를 대기시킬 시간이 남아 있습니다.

그림 32는 매우 큰 우선순위 0 부여 D가 우선순위 0 대기열에 방금 들어갔음을 나타냅니다. LLQ 스케줄러가 수행하는 다음 작업은 부여 D에 대한 전송 시간을 예약하는 것입니다.

그림 33에 이 시나리오가 표시됩니다. UGS-2에 대한 다음 부여가 대기되는 지점까지 시간을 조금 앞으로 돌립니다.

그림 33 - 전송 시간 부여 D. UGS-2에 대한 권한 부여가 대기열에 있음

Grant D는 다음 UGS-2 부여가 0개의 지터에 대해 예약되어야 하는 시점에 예약되어 있는 것 같습니다. 이제 LLQ 스케줄러가 UGS-2에 대한 부여 후 또는 D가 프래그먼트화되지 않은 이유를 LLQ 스케줄러가 그 시점에 허가 D를 스케줄링하고 승인 D를 지연시키지 않는 이유는 무엇일까요? LLQ 스케줄러는 UGS 서비스 흐름에 대한 전송 시간을 미리 할당하지 않습니다. 따라서 LLQ 스케줄러는 UGS 부여가 대역폭 할당 시간 라인에 배치될 위치를 미리 알지 못합니다. LLQ 스케줄러는 LLQ 큐에서 대기될 때까지 UGS 부여에 대해 알지 못합니다. 이 예에서는 UGS-2에 대한 권한 부여가 대기열에 들어갈 때까지 권한 부여 D가 이미 예약되어 있습니다.

LLQ 스케줄러는 다음 사용 가능한 기회에 UGS-2에 대한 부여를 예약하지만, 이 부여는 이상적인 위치로부터 약간 지연되며, 이는 이 특정 부여가 일부 지터를 경험한다는 의미입니다.

그림 34 - UGS-2에 대한 할인이 지연되고 지터 경험 부여

DOCSIS 호환 스케줄러는 이 지터를 피할 수 있었지만, LLQ 스케줄러는 소량의 지터를 희생하여 허가 D의 지연 또는 단편화를 방지합니다. VoIP 엔드포인트의 지터 버퍼는 이 지터를 쉽게 보완할 수 있습니다.

여러 서비스 플로우에 대한 LLQ 타이머가 동시에 만료되고 UGS가 LLQ 큐 내에서 대기 중인 다른 UGS 권한 뒤에 대기할 때 지터가 발생할 수 있는 또 다른 상황입니다. LLQ 스케줄러는 이러한 발생 가능성을 최소화하도록 설계되었습니다. 스케줄러는 서비스 플로우 타이머의 만료 시간을 자동으로 분산시킵니다.

DOCSIS 호환 스케줄러에 따라 LLQ 스케줄러에는 예제에 언급되지 않은 대기열이 두 개 더 있습니다. 대기열:

첫 번째 큐는 케이블 모뎀을 온라인으로 유지하기 위해 정기 스테이션 유지 관리 keepalive 트래픽을 예약하는 데 사용됩니다. 이 큐는 LLQ 큐 바로 다음에 제공됩니다.
두 번째는 최소 예약 비율(CIR 서비스 흐름)을 사용하여 서비스 흐름에 할당된 권한 부여의 대기열입니다. 이 CIR 대기열은 커밋된 속도가 있는 서비스 흐름이 필요한 최소 처리량을 받도록 하기 위해 "우선순위 8" 대기열로 처리됩니다.

입학 통제

DOCSIS 호환 스케줄러와 달리 LLQ 스케줄러는 UGS 및 RTPS 서비스 플로우를 사용하여 업스트림의 실수로 초과 가입을 중지하는 사전 예약 시스템을 사용하지 않습니다. 따라서 LLQ 스케줄러를 사용하는 업스트림에서 업스트림 허용 제어를 명시적으로 구성해야 합니다. 이 컨피그레이션은 UGS 서비스 흐름의 총 업스트림 대역폭이 정상 한도를 초과하지 않도록 합니다.

Cisco는 일반적으로 피크 사용 기간 동안 연장된 기간에 대해 업스트림 채널의 사용률이 75%를 초과하지 않도록 권장합니다. 예를 들어, UGS 트래픽이 업스트림 대역폭의 75% 이상을 소비할 경우, 최선형 데이터는 과도한 레이턴시 및 처리량 성능 문제로 인해 문제가 발생하기 시작합니다.

CMTS 운영자가 최선의 노력 트래픽에 부정적인 결과를 수용할 수 있다면 UGS 서비스 플로우가 가용 업스트림 대역폭의 75% 이상을 소비하도록 허용할 수 있습니다. 그러나 업스트림 채널의 레이어 2 관리 트래픽에 미치는 영향도 고려해야 합니다. 초기 및 스테이션 유지 관리 메시징(케이블 모뎀 keepalives)에 대한 시간을 허용해야 합니다. 이를 고려하지 않고 UGS 트래픽이 대역폭의 약 100%를 소비한다면 케이블 모뎀이 온라인 상태가 되거나 오프라인 상태가 될 수 있습니다.

다음은 승인 제어를 위한 컨피그레이션의 예입니다. 이 예에서는 특정 업스트림의 UGS 서비스 플로우를 업스트림에서 사용 가능한 대역폭의 50%로 제한합니다. 이 명령의 형식은 30% 및 40%의 소용량 및 주요 임계값에 도달하면 구성된 네트워크 관리 스테이션에 SNMP 트랩을 전송합니다. 명령은 다음과 같습니다.

케이블 업스트림 업스트림 번호 허용 제어 us-bandwidth scheduling-type UGS minor 30 major 40 exclusive 50

승인 제어 구성 방법은 이 문서의 DOCSIS Compliant Scheduler 섹션 아래에 있는 Admission Control 섹션을 참조하십시오.

명령 출력 표시

show interface cable interface-number mac-scheduler upstream-number 명령을 실행하여 LLQ 스케줄러의 현재 상태를 측정합니다.

다음은 이 명령의 출력의 예입니다. DOCSIS 호환 스케줄러가 작동 중일 때와 다른 명령 출력의 일부는 굵은 텍스트로 표시됩니다.

uBR7200VXR# show interface cable 5/0 mac-scheduler 0
     DOCSIS 1.1 MAC scheduler for Cable5/0/U0
     Queue[Rng Polls] 0/128, 0 drops, max 1
     Queue[CIR Grants] 0/64, 0 drops, max 2
     Queue[BE(7) Grants] 0/64, 0 drops, max 0
     Queue[BE(6) Grants] 0/64, 0 drops, max 0
     Queue[BE(5) Grants] 0/64, 0 drops, max 0
     Queue[BE(4) Grants] 0/64, 0 drops, max 0
     Queue[BE(3) Grants] 0/64, 0 drops, max 2
     Queue[BE(2) Grants] 0/64, 0 drops, max 0
     Queue[BE(1) Grants] 0/64, 0 drops, max 0
     Queue[BE(0) Grants] 0/64, 0 drops, max 5
     Queue[LLQ Grants] 0/64, 0 drops, max 3
     Req Slots 165488850, Req/Data Slots 871206
     Init Mtn Slots 1727283, Stn Mtn Slots 1478295
     Short Grant Slots 105668683, Long Grant Slots 52721
     ATDMA Short Grant Slots 0, ATDMA Long Grant Slots 0
     ATDMA UGS Grant Slots 0
     Awacs Slots 1303668
     Fragmentation count 11215
     Fragmentation test disabled
     Avg upstream channel utilization : 6%
     Avg percent contention slots : 91%
     Avg percent initial ranging slots : 3%
     Avg percent minislots lost on late MAPs : 0%
     Sched Table Rsv-state: Grants 0, Reqpolls 0
     Sched Table Adm-State: Grants 0, Reqpolls 0, Util 1%
     UGS    : 3 SIDs, Reservation-level in bps 278400
     UGS-AD : 0 SIDs, Reservation-level in bps 0
     RTPS   : 0 SIDs, Reservation-level in bps 0
     NRTPS  : 0 SIDs, Reservation-level in bps 0
     BE     : 14 SIDs, Reservation-level in bps 0
     r4k ticks in 1ms 600000
     Total scheduling events 5009
     No search was needed 5009
     Previous entry free 0
     Next entry free 0
     Could not schedule 0
     Recovery failed 0
Curr time 1341 entry 61
Entry 188, Bin 13
    SID: 416 IUC: 5, size_ms: 17 size_byte: 232 Frag: N Inval: 20
    type 8, perfect time ref 188, skew from ref 0, priority 10
    position 188, bin 13
Entry 188, Bin 14
    SID: 414 IUC: 5, size_ms: 17 size_byte: 232 Frag: N Inval: 20
    type 8, perfect time ref 188, skew from ref 0, priority 10
    position 188, bin 14
Entry 192, Bin 12
    SID: 415 IUC: 5, size_ms: 17 size_byte: 232 Frag: N Inval: 20
    type 8, perfect time ref 192, skew from ref 0, priority 10
    position 192, bin 12

이 출력의 일반 텍스트 행에 대한 설명은 DOCSIS 호환 스케줄러의 명령 출력 표시 섹션을 참조하십시오.

다음은 show 명령 출력의 굵은 줄에 대한 설명입니다.

Queue[LLQ Grants] 0/64, 0 삭제, 최대 3

이 라인은 케이블 업스트림 스케줄링 유형 [nrtps]에 지정된 서비스 플로우 유형에 대한 권한 부여를 관리하는 LLQ 대기열의 상태를 표시합니다. | rtps | ugs] mode llq 명령 0/64는 현재 대기열에 보류 중인 최대 64개의 권한 중 0이 있음을 나타냅니다.

Drops 카운터는 이 큐가 이미 꽉 찼기 때문에(즉, 64개의 부여가 대기열에 있을 때) 스케줄러가 UGS 부여 또는 RTPS 폴링을 대기열에서 대기할 수 없는 횟수를 나타냅니다. 이 대기열에서 드롭이 발생하는 경우 업스트림이 UGS 또는 RTPS 서비스 플로우에 초과 가입되어 있으며 더 엄격한 승인 제어를 적용해야 한다는 것이 가장 일반적인 설명입니다.

max 카운터는 show interface cable mac-scheduler 명령을 마지막으로 실행한 이후 이 큐에 있는 최대 권한 부여 수를 나타냅니다. 이 대기열이 있는 경우 나열된 모든 대기열의 우선 순위가 가장 높습니다.
1ms 600000의 r4k 틱

이 필드는 LLQ 스케줄러가 LLQ 대기열에 부여가 높은 정밀도로 배치되도록 하기 위해 사용하는 내부 타이밍 변수를 나타냅니다.
총 예약 이벤트 5009

이 줄은 이 업스트림에 대해 show interface cable mac-scheduler 명령을 마지막으로 실행한 이후 LLQ 스케줄러가 권한 부여를 대기하려고 시도하는 횟수를 나타냅니다. 이 카운터는 show 명령을 실행할 때마다 재설정됩니다.
검색 필요 없음 5009

LLQ 스케줄러가 권한 부여를 대기열에 추가한 후 LLQ 스케줄러는 다음에 권한 부여가 대기열에 배치될 때 대비하여 서비스 흐름 타이머를 재설정하려고 시도합니다. 타이머 재설정에 문제가 없으면 이 카운터가 증가합니다. 이 카운터는 Total 일정 이벤트 카운터와 동일한 값을 갖는 것이 좋습니다.
이전 항목 사용 가능 0, 다음 항목 사용 가능 0

이러한 카운터는 현재 Cisco IOS Software 릴리스에서 증가하지 않습니다. 이러한 카운터는 항상 0으로 유지됩니다.
0을(를) 예약할 수 없습니다. 복구 실패 0

이 줄은 LLQ 스케줄러가 서비스 흐름의 부여 타이머를 올바르게 설정할 수 없는 횟수를 나타냅니다. 이는 LLQ 스케줄러가 매우 적은 권한 부여 간격의 매우 많은 권한 부여를 처리하는 경우에만 발생합니다. 이러한 카운터는 프로덕션 네트워크에서 증가하지 않을 가능성이 높습니다. 이러한 카운터의 증가분을 통해 UGS 및 RTPS 서비스 플로우가 업스트림에서 물리적으로 사용 가능한 것보다 더 많은 대역폭을 소비함을 나타낼 수 있습니다. 이 시나리오에서는 적절한 admission control 명령을 구현해야 합니다.
현재 시간 1341 항목 61

이 선은 LLQ 스케줄러의 내부 타이머를 밀리초 단위로 표시합니다. 여기에 나열된 "항목"이 서비스 플로우 통계에 나열된 "항목" 필드와 같으면 부여가 LLQ 대기열에서 대기됩니다.

이러한 통계는 LLQ 스케줄러가 처리하는 모든 서비스 흐름에 대해 반복됩니다. 이 예에서는 세 가지 서비스 플로우가 있습니다.

항목 188, 저장함 13

"Entry" 값이 이전 항목의 "entry" 필드와 같으면 이 서비스 흐름의 타이머가 만료되고 부여가 LLQ 큐로 이동합니다. 이 필드는 서비스 흐름에 권한 부여가 대기열에 있을 때마다 재설정됩니다.
SID: 416

LLQ 스케줄러 일정을 부여하는 서비스 흐름의 SID(서비스 식별자)입니다.
IUC: 5

이 서비스 흐름에 속하는 부여에 대해 MAP 메시지에서 광고되는 간격 사용 코드입니다. 이는 거의 항상 "Short data"의 경우 5이고, "Long Data"의 경우 6이고, UGS 스타일 서비스 흐름이 사용 중인 경우 "Advanced PHY UGS"의 경우 11입니다. RTPS 스타일 서비스 흐름의 경우 이 값은 항상 "요청"에 대해 1입니다.
크기(_ms): 17 size_byte: 232

미니슬롯의 부여 크기, 그 뒤에 부여 크기(바이트)가 옵니다. 미니슬롯은 DOCSIS 네트워크에서 업스트림 전송의 최소 단위이며 일반적으로 8 또는 16바이트에 해당합니다.
프레임: N

부여가 분할 가능한지 여부를 나타냅니다. 현재 이 값은 항상 N으로 설정됩니다.
호출: 20

허용 또는 폴링 간격(밀리초)입니다.
유형 8

8은 이 서비스 흐름이 UGS임을, 10은 RTPS를, 11은 NRTPS를 나타냅니다.
완벽한 시간 참조 188

이 부여를 예약해야 하는 이상적인 시간입니다. 이는 일반적으로 상단의 "Entry"와 동일합니다. 그렇지 않을 경우, 더 엄격한 입학 통제를 필요로 하는 업스트림이 심하게 혼잡한 것으로 나타났습니다.
ref 0에서 기울이기

이 부여가 예약된 시점과 부여가 계획되어야 하는 시기 사이의 차이입니다. 이는 "Entry"와 "perfect time ref"의 차이점입니다. 따라서 이 값은 일반적으로 0이어야 합니다.
우선 순위 10

Cisco IOS Software의 현재 릴리스에서 이 값은 항상 10으로 설정되지만 향후에 달라질 수 있습니다.
위치 188, bin 13

이 필드는 이 목록의 맨 위에 있는 "Entry, Bin"과 같아야 합니다.

LLQ 스케줄러의 장점 및 단점

LLQ 스케줄러의 목표는 업스트림 채널의 UGS 및 RTPS 용량을 늘리고 최선형 트래픽의 효율성을 높이는 것입니다. LLQ 스케줄러가 이러한 목표를 달성하기 위해 수행하는 이점은 이 스케줄러가 UGS 및 RTPS 서비스 플로우 지터에 명시적으로 보증을 제공하지 않는다는 것입니다. 대신, LLQ 스케줄러는 지터를 최소화하기 위한 보기를 통해 UGS 부여 및 RTPS 폴링을 가능한 한 이상적인 시간에 가깝게 스케줄링합니다.

또한 LLQ 스케줄러는 DOCSIS 호환 스케줄러보다 다양한 권한 부여 간격과 권한 부여 크기로 여러 UGS 서비스 흐름을 더 잘 처리할 수 있습니다. 이 기능은 서로 다른 유형의 VoIP 통화 및 다른 애플리케이션이 모두 하나의 업스트림 채널에서 동시에 제공되는 PCMM 환경에서 유용할 수 있습니다.

LLQ 스케줄러는 LLQ 스케줄러가 보조금 조각화의 가능성을 줄여주기 때문에 LLQ 스케줄러는 최선의 노력 트래픽을 더 효율적으로 스케줄링합니다. 단편화할 수 없는 DOCSIS 1.0 버스트를 계획할 때 LLQ 스케줄러는 DOCSIS 호환 스케줄러와 같은 UGS 부여 또는 RTPS 폴링 앞에서 사용되지 않는 대역폭의 간격을 생성하지 않습니다. 따라서 사용 가능한 업스트림 시간을 더 효과적으로 사용할 수 있습니다.

일반적으로 DOCSIS 호환 스케줄러를 사용할 때보다 LLQ 스케줄러를 사용할 때 UGS 지터가 더 높지만 일반적인 DOCSIS 또는 PacketCable 기반 네트워크에서 LLQ 스케줄러 지터 레벨은 VoIP 엔드포인트 지터 버퍼 기술의 용량 내에 있습니다. 따라서 올바르게 설계된 VoIP 네트워크에서 LLQ 스케줄러를 사용할 경우 VoIP 통화 품질에 큰 영향을 미치지 않습니다.

대규모 업스트림 버스트에서 발생하는 지터를 제한할 수 있습니다. 이를 위해 케이블 default-phy-burst 매개변수를 기본값인 2000바이트 이하로 유지해야 합니다. 시스템이 800kHz 또는 채널 폭이 더 작은 등 특별히 느린 업스트림 채널을 사용하는 경우 케이블 업스트림 fragment-force 명령을 사용하여 큰 버스트를 더 작은 버스트로 분할하도록 강요하면 지터가 더 감소될 수 있습니다.

LLQ 스케줄러를 사용하는 경우 업스트림 채널의 초과 서브스크립션 가능성을 방지하려면 케이블 허용 제어를 구성해야 합니다. 업스트림에서 물리적으로 처리할 수 있는 것보다 더 많은 활성 UGS 서비스 플로우가 처리되므로 업스트림의 모든 UGS 서비스 플로우에서 음성 품질이 저하됩니다. 극단적인 경우에는 케이블 모뎀이 오프라인 상태이고 새 케이블 모뎀이 온라인 상태가 될 수 없다는 것을 의미합니다. Cisco는 CMTS 운영자가 긴 기간 동안 업스트림 포트의 전체 업스트림 사용률이 75%를 초과하지 않도록 허용 제어를 구성하는 것이 좋습니다.

결론

Cisco uBR 시리즈 DOCSIS CMTS 제품은 두 가지 대체 업스트림 스케줄링 알고리즘을 제공하므로 다양한 네트워크 조건을 충족할 수 있습니다.

낮은 지터에 최적화된 DOCSIS 호환 스케줄러는 균일한 VoIP 코덱이 있는 일반적인 Packetcable 1.x 음성 시스템에 가장 적합하며, UGS 서비스 플로우에 의한 업스트림 채널 사용률의 표준 레벨이 필요한 경우에 적합합니다.

Low Latency Queuing 스케줄러는 UGS 서비스 플로우, 향상된 최선의 노력 트래픽 효율성, 다양한 부여 간격 및 부여 크기와 함께 UGS 및 RTPS 서비스 흐름을 사용하는 시스템에 의한 업스트림 사용률의 정상보다 높은 레벨을 지원하도록 설계되었습니다.

부록 A: 미니슬롯

미니슬롯은 DOCSIS 업스트림에서 가장 작은 전송 단위입니다. 케이블 모뎀이 CMTS에 대역폭 요청을 전송하여 업스트림 전송 시간을 요청하면 모뎀은 바이트 또는 밀리초 단위가 아닌 미니슬롯 단위로 요청합니다. 또한 대역폭 할당 MAP 메시지가 모뎀이 전송할 수 있는 시간 및 기간을 알려 주는 경우 미니슬롯 단위로 해당 정보가 포함됩니다.

하나의 버스트에서 모뎀이 전송할 수 있는 최대 미니슬롯 수는 255개입니다. 미니슬롯 크기는 DOCSIS 틱 단위로 지정됩니다. DOCSIS 틱은 6.25 마이크로초 시간에 해당합니다.

업스트림 포트에 대해 미니슬롯 크기를 틱 단위로 설정하려면 케이블 업스트림 <upstream-number> 미니슬롯 크기 [1 | 2 | 4 | 8 | 16 | 32 | 64 | 128] cable interface 명령

특정 업스트림 채널 너비는 특정 미니슬롯 크기만 허용됩니다. 이 표에서는 DOCSIS 업스트림 채널 폭 대비 유효한 미니슬롯 크기를 보여 주고, 유효한 설정을 가진 미니슬롯의 모듈화 체계 기호의 길이를 보여 줍니다.

참고: X 표시는 잘못된 조합을 나타냅니다.

	200킬로헤르츠	400킬로헤르츠	800킬로헤르츠	1.6메가헤르츠	3.2메가헤르츠	6.4메가헤르츠
미니슬롯 크기(눈금)
1	X	X	X	X	X	32
2	X	X	X	X	32	64
4	X	X	X	32	64	128
8	X	X	32	64	128	256
16	X	32	64	128	256	X
32	32	64	128	256	X	X
64	64	128	256	X	X	X
128	128	256	X	X	X	X

미니슬롯당 전송된 바이트 수를 계산하려면 미니슬롯당 기호에 구성된 변조 체계에 대한 기호당 비트 수를 곱합니다. 이 표에 표시된 대로 서로 다른 변조 체계가 기호당 비트 수를 전송합니다.

DOCSIS 1.1 TDMA 변조 체계	기호당 비트 수
QPSK	2
16-QAM	4

DOCSIS 2.0 ATDMA 변조 체계	기호당 비트 수
8-QAM	3
32-QAM	5
64-QAM	6

예를 들어, 1.6MHz 채널 폭과 미니슬롯 크기가 4 틱(ticks)인 경우 첫 번째 표를 사용하여 미니슬롯당 32개의 심볼에 도달할 수 있습니다. QPSK 기호에 2비트가 포함되어 있으므로 두 번째 표를 사용하여 이 숫자를 바이트로 변환합니다. 이 예에서 미니슬롯 하나는 미니슬롯당 32개의 기호 * 기호당 2비트 = 미니슬롯당 64비트 = 미니슬롯당 8바이트에 해당합니다.

케이블 모뎀이 전송하도록 요청할 수 있는 최대 미니슬롯 수는 255개입니다. 따라서 이 예에서는 모뎀이 만들 수 있는 최대 버스트(바이트)는 255미니슬롯 * 미니슬롯당 8바이트 = 2040바이트입니다.

이 그림(바이트)은 사후 전달 오류 수정 및 사후 물리적 레이어 오버헤드 그림입니다. 오류 수정 및 기타 DOCSIS PHY 레이어 오버헤드는 업스트림 채널을 통과할 때 이더넷 프레임 길이에 약 10~20%를 추가합니다. 정확한 숫자를 도출하려면 업스트림 포트에 적용된 변조 프로파일을 사용합니다.

이 문서의 이전 섹션에서 케이블 모뎀의 최대 버스트 크기에 대한 제한 중 하나가 케이블 default-phy-burst 명령에 구성된 값이라고 설명했기 때문에 이에 대한 논의는 매우 중요합니다. 이 예에서 cable default-phy-burst 명령이 4000바이트로 설정된 경우 제한 계수 또는 버스트 크기는 케이블 default-phy-burst 값이 아니라 255개 미니슬롯 제한(2040바이트 - 오버헤드 제외)입니다.

show controller cable interface-number upstream-number 명령을 사용하여 업스트림에 대해 서로 다른 미니슬롯 크기 표현식을 관찰할 수 있습니다. 예를 들면 다음과 같습니다.

uBR7200VXR# show controller cable 5/0 upstream 0
 Cable5/0 Upstream 0 is up
  Frequency 20.600 MHz, Channel Width 1.600 MHz, QPSK Symbol Rate 1.280 Msps
  This upstream is mapped to physical port 0
  Spectrum Group 1, Last Frequency Hop Data Error: NO(0)
  MC28U CNR measurement : better than 40 dB
  US phy MER(SNR)_estimate for good packets - 36.1280 dB
  Nominal Input Power Level 0 dBmV, Tx Timing Offset 3100
  Ranging Backoff Start 3, Ranging Backoff End 6
  Ranging Insertion Interval automatic (60 ms)
  US throttling off
  Tx Backoff Start 3, Tx Backoff End 5
  Modulation Profile Group 41
  Concatenation is enabled
  Fragmentation is enabled
  part_id=0x3138, rev_id=0x03, rev2_id=0x00
  nb_agc_thr=0x0000, nb_agc_nom=0x0000
  Range Load Reg Size=0x58
  Request Load Reg Size=0x0E
  Minislot Size in number of Timebase Ticks is = 8
  Minislot Size in Symbols = 64
  Bandwidth Requests = 0x338C
  Piggyback Requests = 0x66D
  Invalid BW Requests= 0xD9
  Minislots Requested= 0x756C2
  Minislots Granted  = 0x4E09
  Minislot Size in Bytes = 16
  Map Advance (Dynamic) : 2482 usecs
  UCD Count = 8353

미니슬롯이 16바이트 또는 가장 허용되는 값과 같도록 미니슬롯 크기를 설정하는 것이 좋습니다. 16바이트의 미니슬롯 크기는 케이블 모뎀에 최대 255 * 16 = 4096바이트의 포스트 FEC 버스트를 생성할 수 있는 기능을 제공합니다.

부록 B: MAP 고급

CMTS는 정기적으로 대역폭 할당 MAP이라는 특수 메시지를 생성하여 모뎀이 업스트림 채널에서 전송을 수행할 수 있는 시간을 케이블 모뎀에 정확하게 알려줍니다. MAP 메시지를 전달하는 전기 신호는 CMTS에서 연결된 모든 케이블 모뎀으로 HFC(Hybrid Fiber Coax) 네트워크를 통해 물리적으로 전파하는 데 시간이 매우 오래 걸립니다. 따라서 모뎀이 메시지를 수신할 수 있도록 MAP 메시지를 일찍 전송해야 하며 지정된 시간에 CMTS에 도달할 수 있도록 업스트림 전송을 만들 수 있어야 합니다.

MAP 고급 시간 또는 MAP 미리 보기 시간은 CMTS가 MAP 메시지를 생성하는 시간과 MAP에서 주문한 첫 번째 전송을 CMTS에서 수신해야 하는 시간 간의 차이를 나타냅니다. 이 시간은 DOCSIS 시스템에 있는 이러한 지연의 조합을 나타냅니다.

CMTS가 소프트웨어에서 MAP 메시지를 구성하고 다운스트림 전송 회로에서 메시지를 대기열에 넣고 처리하는 데 걸리는 시간. 이 구성 요소의 가치는 다양한 플랫폼과 아키텍처에 따라 다르며 일반적으로 고정적인 값입니다.
정격 노이즈를 방지하기 위해 정방향 오류 수정 목적으로 사용되는 다운스트림 인터리빙 함수가 추가하는 레이턴시입니다. 이 값을 변경하려면 다운스트림 인터리버 매개변수를 변경합니다.
CMTS에서 케이블 모뎀으로 HFC 네트워크를 통해 전기 신호가 이동하는 데 걸리는 시간입니다. DOCSIS는 CMTS와 케이블 모뎀 간의 최대 단방향 이동 시간을 800마이크로초로 지정합니다. 이 값은 케이블 플랜트의 물리적 길이에 따라 달라집니다. 다운스트림 변조 구성표와 업스트림 채널 폭 및 변조 구성표도 이 값에 영향을 줍니다.
케이블 모뎀이 수신된 MAP 메시지를 처리하고 업스트림 전송을 준비할 수 있는 시간입니다. 이는 DOCSIS 사양의 지침에 따라 200마이크로초를 더한 업스트림 인터리버 지연을 초과할 수 없습니다. 실제로 이 시간은 케이블 모뎀의 제조, 모델 및 펌웨어 버전에 따라 최대 300마이크로초 또는 최대 100마이크로초입니다.

그림 35 - MAP 고급 시간의 구성 요소

맵 고급 시간은 CMTS가 케이블 모뎀이 전송을 수행하려고 하는 시간과 모뎀이 전송을 수행할 수 있는 시간 사이의 최소 지연을 나타내므로 업스트림 전송 지연에 큰 영향을 미칠 수 있습니다. 따라서 업스트림 레이턴시를 줄이기 위해 맵 고급 시간을 최소화합니다.

혼잡한 업스트림에서 다른 요소도 업스트림 레이턴시에 영향을 줍니다. 예를 들어, 백오프 및 재시도 대역폭 요청 알고리즘으로 인해 발생하는 지연 및 보류 중인 권한 부여의 대기열 처리가 서로 지연됩니다.

그림 36은 CMTS에서 생성하는 MAP과 업스트림에서 해당 데이터 수신 간의 관계를 보여줍니다.

그림 36 - MAP 생성과 업스트림 데이터 수신 간의 관계

인터페이스 깊이

맵 선점 시간의 첫 번째 요인은 충동 노이즈 보호에 사용되는 다운스트림 인터베이버입니다. 다음 표에서는 다양한 인터리버 탭 및 인터리버 증가 설정에 대해 다운스트림 전송에 추가된 대기 시간을 보여 줍니다.

참고: 탭 크기가 클수록 오류 교정이 더 강력해지지만, 대기 시간이 클수록 좋습니다.

I(탭 수)	J(증분)	레이턴시 64-QAM	레이턴시 256-QAM
8	16	220마이크로미터	150마이크로미터
16	8	480마이크로미터	330마이크로미터
32	4	980마이크로미터	680마이크로미터
64	2	2,000마이크로미터	1,400마이크로미터
128	1	4,000마이크로미터	2,800마이크로미터
12(유로DOCSIS)	17(유로DOCSIS)	430마이크로미터	320마이크로미터

케이블 다운스트림 인터리브 깊이 [8]로 인터리버 매개변수를 설정할 수 있습니다. | 16 | 32 | 64 | 128] cable interface configuration 명령

참고: I(탭 수)의 값이 지정되고 표에 표시된 J(증가)의 고정 해당 값이 자동으로 적용됩니다. 또한 EuroDOCSIS(Annex A) 모드의 경우 인터페이스 매개변수는 I = 12, J = 17에서 고정됩니다. I의 기본값은 32이며 J의 기본값은 4입니다.

왕복 시간

CMTS와 케이블 모뎀 간의 전기 왕복 시간을 조정할 수 있는 선 시간 매핑에 기여하는 두 번째 요인은 다양합니다. CMTS와 케이블 모뎀 간의 물리적 거리와 케이블 모뎀에 내재된 처리 지연이 이 값에 영향을 미칩니다.

DOCSIS 사양은 시스템에서 CMTS와 가장 먼 케이블 모뎀 간에 허용되는 최대 단방향 전파 시간을 800마이크로초까지만 허용해야 합니다. 이는 케이블 모뎀 처리 지연을 제외하고 약 1600마이크로초의 왕복 시간을 의미합니다.

진공 상태에서 빛의 속도는 초당 약 186,000마일(초당 300,000킬로미터)이며 파이버용 전파 속도는 일반적으로 0.67로 인용됩니다. 따라서 CMTS와 케이블 모뎀 간의 최대 허용가능한 단방향 거리는 대략 다음과 같습니다.

	Distance = Velocity * Time

       		 = (186,000 miles/sec * 0.67) * 800 microseconds

       		 = 100 miles or 161 kilometers.

DOCSIS 사양에 따르면 케이블 모뎀 처리 지연은 200마이크로초 이상 업스트림 인터리빙 지연을 초과해서는 안 됩니다. 그러나 드물지만, 일부 구형 케이블 모뎀 브랜드는 MAP 메시지를 처리하는 데 최대 300마이크로초가 걸릴 수 있습니다. 더 강력한 CPU를 사용하는 새로운 유형의 케이블 모뎀은 MAP 메시지를 처리하는 데 100마이크로초 이하가 걸릴 수 있습니다.

케이블 모뎀이 평균적으로 DOCSIS 사양을 준수하는 것으로 가정합니다. 따라서 최대 왕복 시간은 1600 + 200 = 1800마이크로초여야 합니다.

대부분의 케이블 시스템은 100마일 보다 훨씬 짧습니다. 따라서 CMTS는 CMTS와 가장 먼 케이블 모뎀 간의 전기 라운드 트립 시간이 최대값인 1800마이크로초라고 항상 가정하는 것이 최적적이지 않습니다.

예상 최대 예상 전기 왕복 시간을 대략적으로 추정하려면 CMTS와 케이블 모뎀 간의 파이버 거리를 추가하고 마일당 16마이크로초(km당 10마이크로초)를 곱합니다. 그런 다음 모든 코엑스의 거리를 추가하고 그 값에 마일 당 12.4마이크로초(km 당 7.6마이크로초)을 곱합니다. 그런 다음 200마이크로초 처리 지연을 추가합니다.

예를 들어, CMTS와 가장 먼 케이블 모뎀 사이에 총 20마일의 파이버와 1마일의 코엑을 가진 HFC 세그먼트는 다음과 같은 전기 왕복 지연 시간을 예상할 수 있습니다.

20 miles * 16 microseconds/mile + 1 mile * 12.4 microseconds/mile + 200 microseconds
 
= 320 microseconds + 12.4 microseconds + 200 microseconds

= 532.4 microseconds

이 그림에는 업스트림 및 다운스트림 채널 특성 및 모뎀 처리 시간의 변동으로 인한 추가적인 지연이 포함되지 않습니다. 따라서 MAP 고급 시간을 계산할 때 이 값을 사용하는 것은 적합하지 않습니다.

시스템에서 왕복 시간을 결정하는 더 정확한 방법은 show cable modem 명령의 출력에 표시된 케이블 모뎀의 "타이밍 오프셋"을 확인하는 것입니다.케이블 모뎀이 CMTS와의 통신을 유지하기 위해 사용하는 범위 프로세스의 일부로서 CMTS는 각 케이블 모뎀의 왕복 시간을 계산합니다. 이 왕복 시간은 show cable modem 명령 출력(1/10.24MHz = 97.7나노초)에서 타이밍 오프셋 또는 범위 오프셋 단위라고 하는 "타이밍 오프셋"으로 나타납니다. 모뎀의 타이밍 오프셋을 마이크로초 단위로 변환하려면 값에 25/256을 곱하거나 값을 대략 10으로 나눕니다.

다음은 show cable modem 명령 출력에서 다양한 모뎀의 시간 오프셋을 마이크로초 값으로 변환하는 예입니다.

참고: 마이크로초 값은 기울임꼴로 표시됩니다.

uBR7200VXR# show cable modem
MAC Address    IP Address   I/F       MAC         Prim RxPwr Timing  Num BPI
                                      State       Sid  (dB)  Offset  CPE Enb
00aa.bb99.0859 4.24.64.28   C5/1/U0   online(pt)  16   0.00  2027     0   Y  (198μs)
00aa.bb99.7459 4.24.64.11   C5/1/U0   online(pt)  17   1.00  3528     0   Y  (345μs)
00aa.bbf3.7258 4.24.64.31   C5/1/U0   online(pt)  18   0.00  2531     0   Y  (247μs)
00aa.bbf3.5658 4.24.64.39   C5/1/U0   online(pt)  19   0.00  6030     0   Y  (589μs)

이 경우 가장 멀리 있는 모뎀이 6030의 타이밍 오프셋이 있는 마지막 모뎀입니다. 이는 왕복 시간 6030 * 25/256 = 589마이크로초와 같습니다.

정적 MAP 고급

HFC 네트워크의 길이가 100마일 미만임을 알고 있는 시스템에서는 MAP 고급 시간을 계산할 때 표준 1800마이크로초 미만의 최대 왕복 시간을 사용하도록 CMTS를 구성할 수 있습니다.

CMTS가 MAP 고급 계산에서 라운드 트립 시간에 사용자 정의 값을 사용하도록 하려면 cable map-advance static max-round-trip-time cable interface 명령을 실행합니다.

최대 왕복 시간 범위는 100~2000마이크로초입니다. 최대 왕복 시간에 대해 값을 지정하지 않으면 기본값인 1800마이크로초가 적용됩니다.

참고: static 키워드를 dynamic 키워드로 대체할 수 있습니다. 다음 섹션을 참조하십시오.

지정된 왕복 시간이 다운스트림 채널에서 모뎀 라운드 트립 시간을 케이블링하는 가장 큰 CMTS보다 큰지 확인합니다. 케이블 모뎀의 왕복 시간이 최대 왕복 시간에 지정된 시간보다 길면 모뎀은 온라인 상태로 유지하기가 어려울 수 있습니다. 이러한 모뎀에 MAP 메시지에 응답할 시간이 충분하지 않아 CMTS와 통신할 수 없기 때문입니다.

마이크로초로 변환된 케이블 모뎀의 시간 오프셋이 지정된 최대 왕복 시간을 초과하면 모뎀에 잘못된 타이밍 오프셋 플래그가 표시됩니다. 이 오프셋 플래그는 show cable modem 명령 출력에서 케이블 모뎀의 타이밍 오프셋 옆에 느낌표(!)로 나타납니다. 이 상황은 최대 왕복 시간 매개변수가 너무 낮게 설정되어 있거나 케이블 모뎀에 시간 오프셋이 불안정하고 시간이 지남에 따라 계속 증가하는 문제가 있는 경우 발생할 수 있습니다.

예를 들면 다음과 같습니다.

uBR7200VXR# show cable modem
MAC Address    IP Address   I/F      MAC         Prim RxPwr  Timing  Num BPI
                                     State       Sid  (dB)   Offset  CPE Enb
00aa.bb99.0859 4.24.64.28   C5/1/U0  online(pt)  16   0.00  2027     0   Y  (198μs)
00aa.bb99.7459 4.24.64.11   C5/1/U0  online(pt)  17   1.00  3528     0   Y  (345μs)
00aa.bbf3.7258 4.24.64.31   C5/1/U0  online(pt)  18   0.00  2531     0   Y  (247μs)
00aa.bbf3.5658 4.24.64.39   C5/1/U0  online(pt)  19   0.00  !5120    0   Y  (500μs)

이 예에서는 cable map-advance static 500 명령을 지정합니다. 그러나 케이블 인터페이스에 연결된 케이블 모뎀 중 하나의 타이밍 오프셋이 500마이크로초 이상(500 * 256/25 = 5120 타이밍 오프셋 단위와 동일).

마지막 케이블 모뎀의 타이밍 오프셋은 잘못된 타이밍 오프셋 플래그인 "!"으로 표시됩니다. 이 값은 실제 시간 오프셋이 훨씬 더 높을 수 있지만 허용되는 최대값인 5120단위로도 고정됩니다. 이 케이블 모뎀은 오프라인 상태가 되어 성능이 저하될 수 있습니다.

타이밍 오프셋이 최대 왕복 시간 이하로 떨어지더라도 케이블 모뎀에 대해 잘못된 타이밍 오프셋 플래그가 설정된 상태로 유지됩니다. 플래그를 지우는 유일한 방법은 show cable modem 목록에서 모뎀을 일시적으로 제거하는 것입니다. 이를 위해 clear cable modem mac-address delete 명령을 사용할 수 있습니다. 또는 케이블 인터페이스 또는 업스트림 포트를 재설정할 수 있습니다.

업스트림 단위로 정적 맵 고급 알고리즘의 작업을 관찰하려면 show controller cable interface-number upstream upstream number 명령을 실행합니다. 예를 들면 다음과 같습니다.

uBR7200VXR# show controller cable 5/0 upstream 0
 Cable5/0 Upstream 0 is up
  Frequency 20.600 MHz, Channel Width 1.600 MHz, QPSK Symbol Rate 1.280 Msps
  This upstream is mapped to physical port 0
  Spectrum Group is overridden
  US phy MER(SNR)_estimate for good packets - 36.1280 dB
  Nominal Input Power Level 0 dBmV, Tx Timing Offset 2037
  Ranging Backoff automatic (Start 0, End 3)
  Ranging Insertion Interval automatic (60 ms)
  US throttling off
  Tx Backoff automatic (Start 0, End 3)
  Modulation Profile Group 43
  Concatenation is enabled
  Fragmentation is enabled
  part_id=0x3138, rev_id=0x03, rev2_id=0x00
  nb_agc_thr=0x0000, nb_agc_nom=0x0000
  Range Load Reg Size=0x58
  Request Load Reg Size=0x0E
  Minislot Size in number of Timebase Ticks is = 16
  Minislot Size in Symbols = 128
  Bandwidth Requests = 0x6ECEA
  Piggyback Requests = 0xDE79
  Invalid BW Requests= 0x63D
  Minislots Requested= 0x8DEE0E
  Minislots Granted  = 0x7CE03
  Minislot Size in Bytes = 32
  Map Advance (Static) : 3480 usecs
  UCD Count = 289392

Map Advance (Static) 필드에는 3480마이크로초 단위의 맵 고급 시간이 표시됩니다. 다운스트림 인터리버 특성이나 max-round-trip-time 매개변수를 변경하면 변경 사항이 정적 맵 고급 값에 반영됩니다.

동적 MAP 고급

고정 MAP 고급 계산을 사용하여 MAP 고급 시간을 최적화하려면 CMTS 운영자가 케이블 세그먼트에서 가장 큰 왕복 시간을 수동으로 결정해야 합니다. 다운스트림 또는 업스트림 채널 특성이 변경되거나 플랜트 조건이 변경되면 최대 왕복 시간이 크게 변경될 수 있습니다. 시스템 조건의 변화를 수용하기 위해 구성을 지속적으로 업데이트하는 것은 어려울 수 있습니다.

동적 MAP 고급 알고리즘은 이 문제를 해결합니다. 동적 MAP 고급 알고리즘은 정기적으로 show cable modem 목록을 스캔하여 가장 큰 초기 범위 지정 타이밍 오프셋을 가진 모뎀을 검색한 다음 이 값을 자동으로 사용하여 MAP 고급 시간을 계산합니다. 따라서 CMTS는 항상 가능한 가장 낮은 맵 고급 시간을 사용합니다.

케이블 모뎀의 초기 범위 지정 시간 오프셋은 모뎀이 온라인 상태가 되는 지점에서 모뎀이 보고하는 시간 오프셋입니다. 대부분의 경우 show cable modem 명령 출력에서 볼 수 있듯이 이 옵션은 진행 중 시간 오프셋에 가깝습니다. 그러나 일부 유형의 케이블 모뎀은 시간 오프셋에서 매우 큰 값으로 위로 나타나는 데 문제가 있습니다. 이렇게 하면 맵 고급 시간 계산이 왜곡될 수 있습니다. 따라서 모뎀이 온라인 상태일 때만 업데이트되는 초기 범위 지정 시간 오프셋만 사용됩니다. 케이블 모뎀의 초기 범위 지정 타이밍 오프셋 및 진행 중인 타이밍 오프셋을 보려면 show cable modem verbose 명령을 실행합니다. 예를 들면 다음과 같습니다.

uBR7200VXR# show cable modem 00aa.bbf3.7858 verbose
MAC Address                         : 00aa.bbf3.7858
IP Address                          : 4.24.64.18
Prim Sid                            : 48
Interface                           : C5/1/U0
Upstream Power                      : 39.06 dBmV (SNR = 36.12 dB)
Downstream Power                    : 14.01 dBmV (SNR = 35.04 dB)
Timing Offset                       : 2566
Initial Timing Offset               : 2560
Received Power                      :  0.00 dBmV
MAC Version                         : DOC1.1
QoS Provisioned Mode                : DOC1.1
Enable DOCSIS2.0 Mode               : Y
Phy Operating Mode                  : tdma
Capabilities                        : {Frag=Y, Concat=Y, PHS=Y, Priv=BPI+}
Sid/Said Limit                      : {Max US Sids=16, Max DS Saids=15}
Optional Filtering Support          : {802.1P=N, 802.1Q=N}
Transmit Equalizer Support          : {Taps/Symbol= 1, Num of Taps= 8}
Number of CPE IPs                   : 0(Max CPE IPs = 16)
CFG Max-CPE                         : 32
Flaps                               : 4(Mar 13 21:13:50)
Errors                              : 0 CRCs, 0 HCSes
Stn Mtn Failures                    : 0 aborts, 1 exhausted
Total US Flows                      : 1(1 active)
Total DS Flows                      : 1(1 active)
Total US Data                       : 321 packets, 40199 bytes
Total US Throughput                 : 129 bits/sec, 0 packets/sec
Total DS Data                       : 28 packets, 2516 bytes
Total DS Throughput                 : 0 bits/sec, 0 packets/sec
Active Classifiers                  : 0 (Max = NO LIMIT)
DSA/DSX messages                    : permit all
Total Time Online                   : 1h00m

이 예에서 진행 중인 시간 오프셋(2566)은 초기 범위 지정 시간 오프셋(2560)보다 약간 높습니다. 이러한 값은 약간 다를 수 있습니다. 그러나 값이 몇 백 개 이상의 단위로 다르면 케이블 모뎀의 시간 오프셋 제어에 문제가 있을 수 있습니다.

동적 맵 고급 계산을 활성화하려면 cable map-advance dynamic safety-factor max-round-trip-time cable interface 명령을 실행합니다.

안전 계수 매개변수 범위는 100~2,000마이크로초입니다. 이 매개변수는 신호 전달의 예기치 않은 지연을 고려할 수 있도록 MAP 사전 시간에 추가됩니다. 기본값은 1000마이크로초 입니다. 그러나 케이블 플랜트 또는 업스트림 또는 다운스트림 채널 특성이 크게 변경되지 않는 안정적인 케이블 시스템의 경우 500마이크로초 등의 낮은 값을 사용합니다.

max-round-trip-time 매개변수의 범위는 100~2000마이크로초입니다. 이 매개변수는 케이블 세그먼트에 연결된 케이블 모뎀의 시간 오프셋에 대한 상한값으로 사용됩니다. 기본값은 1800마이크로초 입니다. 마이크로초로 변환된 케이블 모뎀의 시간 오프셋이 지정된 최대 왕복 시간을 초과하면 잘못된 타이밍 오프셋 플래그로 표시됩니다.

케이블 시스템의 길이가 100마일(100마일)보다 훨씬 작다는 것을 알고 있고 세그먼트에 연결된 케이블 모뎀의 최대 정상 시간 오프셋이 무엇인지 알고 있는 경우 max-round-trip time 매개변수를 기본값이 아닌 값으로 설정합니다.

show controller cable interface-number upstream-number 명령을 사용하여 업스트림 단위로 동적 맵 고급 알고리즘의 작업을 확인합니다. 예를 들면 다음과 같습니다.

uBR7200VXR# show controller cable 5/0 upstream 0
 Cable5/0 Upstream 0 is up
  Frequency 20.600 MHz, Channel Width 1.600 MHz, QPSK Symbol Rate 1.280 Msps
  This upstream is mapped to physical port 0
  Spectrum Group 1, Last Frequency Hop Data Error: NO(0)
  MC28U CNR measurement : better than 40 dB
  US phy MER(SNR)_estimate for good packets - 36.1280 dB
  Nominal Input Power Level 0 dBmV, Tx Timing Offset 3100
  Ranging Backoff Start 3, Ranging Backoff End 6
  Ranging Insertion Interval automatic (60 ms)
  US throttling off
  Tx Backoff Start 3, Tx Backoff End 5
  Modulation Profile Group 41
  Concatenation is enabled
  Fragmentation is enabled
  part_id=0x3138, rev_id=0x03, rev2_id=0x00
  nb_agc_thr=0x0000, nb_agc_nom=0x0000
  Range Load Reg Size=0x58
  Request Load Reg Size=0x0E
  Minislot Size in number of Timebase Ticks is = 8
  Minislot Size in Symbols = 64
  Bandwidth Requests = 0x338C
  Piggyback Requests = 0x66D
  Invalid BW Requests= 0xD9
  Minislots Requested= 0x756C2
  Minislots Granted  = 0x4E09
  Minislot Size in Bytes = 16
  Map Advance (Dynamic) : 2482 usecs
  UCD Count = 8353

[Tx 타이밍 오프셋] 값은 타이밍 오프셋 단위로 업스트림에 연결된 모든 케이블 모뎀의 가장 큰 타이밍 오프셋을 표시합니다. 이 값을 사용하여 MAP 고급 시간을 계산합니다. Map Advance (Dynamic)(맵 고급(동적)) 필드에는 결과 맵 고급 시간이 표시됩니다. 이 값은 Tx 타이밍 오프셋이 변경되거나, safety-value가 수정되거나, 다운스트림 인터리버 특성이 변경된 경우 달라질 수 있습니다.

동적 MAP 고급 알고리즘은 케이블 모뎀이 초기 범위 조정 시간 오프셋을 CMTS에 올바르게 보고하는지 여부에 따라 달라집니다. 안타깝게도, 일부 케이블 모뎀의 제조업체와 모델은 초기 범위의 시간 오프셋을 실제 값보다 훨씬 낮은 값으로 보고합니다. 모뎀에서 0에 가깝거나 음수 값에 가까운 시간 오프셋을 표시할 때 이를 확인할 수 있습니다.

%UBR7200-4-BDTXOFFSET과 유사한 오류 메시지: 케이블 모뎀 00ff.0bad.caf3에 대해 잘못된 타이밍 오프셋 -2가 탐지된 경우 이러한 케이블 모뎀에 나타날 수 있습니다. 이러한 유형의 케이블 모뎀은 DOCSIS를 준수하는 방식으로 시간 오프셋을 보고하지 않으며, 동적 맵 고급 알고리즘은 모든 케이블 모뎀에서 MAP 메시지를 수신하고 응답할 수 있는 시간을 보장하는 맵 고급 시간을 올바르게 계산할 수 없습니다.

이러한 케이블 모뎀이 케이블 세그먼트에 있는 경우 동적 MAP 고급 알고리즘을 비활성화하고 고정 MAP 고급 알고리즘으로 돌아갑니다. 일부 케이블 모뎀에 음수 시간 오프셋이 표시되는 이유는 무엇입니까? 를 참조하십시오. 자세한 내용을 참조하십시오.

Cisco uBR CMTS의 업스트림 스케줄러 모드 컨피그레이션

다운로드 옵션

편견 없는 언어

이 번역에 관하여

목차

개정 이력

이 문서가 도움이 되셨습니까?

지원 문의

이 문서가 적용되는 제품